Software Engineering - Team Exercises

These are the exercises to explore and apply lecture topics in group break-out sessions.

When you leave the lecture to go into your discussion groups, keep this in a browser window to guide you as you work through the exercise.

Teams and Projects

share your thoughts on
- general product concepts
- relevant experiences and strengths
- implementation tools and technologies
discuss
- how well it might meet the P2-P4 architectural, design, and testing requirements
- how prepared you are to design and implement it
- potential schedule and timezone issues
feel free to move between rooms

identify distinct classes of your users
- what usefully distinguishes each sub-class?
identify key goals/operations for each
- who are the participants in this operation?
- diagram these as UML use cases
be prepared to share with the class
- why you chose those classification criteria
- how well/completely these use cases captures your program

consider user facing functionality where understanding/usability might be an issue (5-7 minutes)
- how would you mock-up what?
- whom would you ask to use it how?
consider new technologies (e.g. languages, tool kits, APIs, services) that you are planning to use (5-7 minutes)
- what might be hard to master, or might not do what you need?
- what things to you need to be assured of before you can safely base your plans on each?
- what is the simplest project that would answer each question?
be prepared to share what you discover

Define important quality attributes for your product (other than code-correctness) based on your competitive research and user interviews.
Refine those definitions to be measurable statements, and suggest a means of testing each.
Suggest things you can do (in your design and development process) to ensure each.
Be prepared to share your results

Consider your application
- enumerate the key information content elements
- enumerate the key user goals/tasks
in that context
- identify natural task based navigation paths
- identify natural content structure relationships
- note the information to be gathered or displayed on each path
be prepared to share with the class
- what was obvious and/or simple (not a problem)?
- what was not obvious/simpe, and what did you decide?

Consider a non-trivial component in your product:
- what non-obvious aspect must developers/reviewers understand?
Consider design representations:
- UML diagrams (e.g. use case, state, interaction, swim-lane)
- Doxygen/PyDoc/etc
- decision tables
- simple prose?
Answer:
- What story are you trying to tell, and why is that the right story?
- Which form would best tell, and why?
- Once this story has been told, is the component now fairly clear?
- What other component/story in your project would demand a different choice?

Consider an interesting problem
- ideally one in your own project
- consider patterns that might speak to this problem
Sketch a solution without resourse to design patterns
Sketch a solution using the chosen design pattern
- how well did it address your problem?
- how easy was it to apply this pattern to your problem?
- does this cause you to think of changes to your architecture?
Be prepared to discuss your results

Consider an at-risk component in your project
- something that does things that might reasonably fail, more interesting problems than bad user input
- interacts with external services that might refuse, fail or be unavailable
- complex process whose success has many pre-requisites
suggest a list different things that might give rise to a fault (incorrect or undexpected result).
- rank each by likelihood and impact
for the top 2-3 problems on your list:
- describe how you would determine that each had occurred
- describe an appropriate recovery or containment strategy
Be prepared to discuss your results

Consider each component you have chosen for phases 3 and 4.
- what portions of its functionality is dependent on other components?
- how thoroughly can this component be tested in isolation?
Consider building a dummy (test) module for the required external functionality.
- how completely and accurately could you simulate those other components?
- how would you control the behavior of those simulations to enable the desired testing?
- how easy would it be to build those simulations?
What approach makes the most sense?
1. no external functionality is required, I can test this alone
2. an easily built simulation could provide all of the required functionality
3. do initial testing with a simulation, but add additional test cases after the real components are available
4. this component cannot reasonably be built and tested until others are available.
What demo would you plan to give? And if you are not planning on completing enough components for a fully functional product, what dummy component(s) would you have to build in order to give a compelling demonstration of the functionality you did implement?
Be prepared to discuss your results

Consider the unit test cases for your chosen components
- what whole-product functionality is not yet well exercised?
- what additional system test cases should you add to cover them?
- might you also have installation, security or other beyond the code issues?
Consider the computation, major I/O, and external services you use
- might any operations involve significant costs/delays?
- how might you measure (and track) delays due to those causes?
- does this cause you to consider design and/or testing changes?
Be prepared to discuss your results

each persion identify personal experiences of:
- code you found very difficult to understand
- code you found very easy to understand
note:
- the factors that made them so
- how they came to have been done that way
Be prepared to discuss your examples and conclusions

Consider:
- when is code personal property?
- when is code community property?
- how do we deal with code and people moving between communities?
How do we balance:
- creators' prerogative
- the benefits that follow from uniformity
- acceptance of diversity
Be prepared to discuss your conclusions/positions

Consider your P1-4 plans, and how things actually went:
- tasks not recognized or greatly under-estimated?
- work where commitments were misunderstood?
- tasks that slipped significantly?
Consider your project management practices:
- Did the team generally know how everyone was doing?
- Were problems promptly recognized?
- How prompt and effective were responses?
In retrospect:
- How reasonable and useful were the chosen milestones?
- Were there additional tasks (or milestones) that should have been called out?
- What team processes worked well?
- What would you now do differently? How?
What from this would you like to share with the class?