Software Engineering - Team Exercises
These are the exercises to explore and apply lecture topics
in group break-out sessions.
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
Users and Use Cases
- 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
Modeling and Prototyping
- 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?
- do you understand the structure they will impose on your implementation?
- 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
Quality and Quality Assurance
- 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
User Interface Design
- 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?
Routine Level Design
- 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?
Architectural, Class, and Behavioral Patterns
- Consider an interesting problem
- ideally one in your own project w/non-trivial information or flow control
- consider patterns that might speak to this problem
- 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?
- Do you have a need that no pattern seems to address?
- Be prepared to discuss your results
Software Robustness
- 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, impact, recoverability
- for the top 2-3 problems on your list:
- describe how you would recognize/ascertain that each had occurred
- describe an appropriate recovery or containment strategy
- Be prepared to discuss your results
Integration and Testing Strategy
- 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?
- no external functionality is required, I can test this alone
- an easily built simulation could provide all of the required functionality
- do initial testing with a simulation, but add additional test cases
after the real components are available
- 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
System Testing
- 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
Personal Experiences w/Good and Bad Code
- 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
Code Ownership
- 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
Assessing our Processes
- Consider the processes you have used:
- which were fairly clearly agile?
- which were fairly clearly up-front planning?
- which seemed consistent with either?
- Consider how well they served you:
- which of these processes worked very well? Why?
- which of these processes worked poorly? Why?
- What might you have done differently:
- what might have been better performed in a more agile fashion?
- what might have been better performed in a more disciplined/structured fashion?
Share your Pair-Programming Experiences
- Have you done "Pair Programming?"
- where ... class? internship? personal projects?
- What roles did you use?
- how were they chosen ... assigned, evolved, found?
- What did you learn?
- about pair programming
- new design, coding, testing, debugging skills?
- about yourself?
Scheduling and Status Tracking
- 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?