21.2. From Iteration 1 to 2
When iteration 1 ends, the following should be accomplished:
All the software has been vigorously tested: unit, acceptance, load, usability, and so on. The idea in the UP is to do early, realistic, and continuous verification of quality and correctness, so that early feedback guides the developers to adapt and improve the system, finding its “true path.”
Customers have been regularly engaged in evaluating the partial system, to obtain feedback for adaptation and clarification of requirements. And the customers get to see early visible progress with the system.
The system, across all subsystems, has been completely integrated and stabilized as a baselined internal release.
In the interest of brevity, many activities concluding iteration 1 and initiating iteration 2 are skipped, since the emphasis of this presentation is an introduction to OOA/D. Comments on a few of the myriad activities that are skipped include:
At the start of the new iteration, use a CASE tool to reverse-engineer UML diagrams from the source code of the last iteration (the results are part of the UP Design Model). These can be printed in large size on a plotter and posted on the walls of the project room, as a communication aid to illustrate the starting point of the logical design for the next iteration.
Usability analysis and engineering for the UI is underway. This is an extraordinarily important skill and activity for the success of many systems. However, the subject is detailed and non-trivial, and outside the scope of this book.
Database modeling and implementation is underway.
Near the end of the prior iteration, requirements for the next are chosen.
Another two-day (for example) requirements workshop occurs, in which more use cases are written in their fully dressed format. During elaboration, while perhaps 10% of the most risky requirements are being designed and implemented, there is a parallel activity to deeply explore and define perhaps 80% of the use cases for the system, even though most of these requirements won't be implemented until construction.
Participants will include a few developers (such as the software architect) from the first iteration, so that the investigation and questioning during this workshop is informed from the insights (and confusions) gained from actually quickly building some software. There's nothing like building some software to discover what we really don't know about the requirements—this is a key idea in the UP and iterative development.
Simplifications in the Case Study
In a skillful UP project, the requirements chosen for the early iterations are organized by risk and high business value, so that the high-risk issues are identified and resolved early. However, if this case study exactly followed that strategy, it would not be possible to help explain fundamental ideas and principles of OOA/D in the early iterations. Therefore, some license is taken with the prioritization of requirements, preferring those that support the educational goals, rather than project risk goals.