Construction and Its Iterations

The number of iterations required for Construction varies from project to project, but in most cases Construction has more iterations (usually two to four) than any other phase (see the section Determining the Number of Iterations, in Chapter 12).

So what goes into each of the iterations? Iteration planning is largely driven by the parts of use cases that should be implemented. You want to implement the use cases that are most essential to customers, as well as those associated with the most technical risk. Especially in the first iteration, and to some extent the second, start with only partial implementation of use cases (that is, implement only some of the scenarios within the use case) to drive out quickly as much risk as possible and to get a reasonable implementation before detailing the use cases. Once you have decided which use cases to implement, or partially implement, identify which components need to collaborate to provide the use-case functionality; these are the components that must be further designed, implemented, and tested within that iteration. This identification provides you with a better understanding of the time required to implement the use cases and whether, based on available resources, the scope of work needs to be changed for the given iteration.

Let's assume that you have 15 use cases and your project has three iterations in Construction. How do you proceed? Table 8.1 shows a possible plan, starting with what has been achieved coming into Construction (results at the end of Elaboration) and what is done in each of the three Construction iterations.

Table 8.1. Progress Made Prior to and Through Construction Iterations. The requirements, components, and the testing of the system evolve in each iteration. By the end of the Construction phase, you have the first operational version (beta release) of the system.

Requirements

Components

Tests

End of Elaboration

  • 15 UCs identified

  • 8 UCs described in detail, 4 with some depth, 3 just briefly

  • 18 main components identified

  • 4 have 50% of the code implemented, including all interfaces

  • 10 have interfaces plus minimal logic implemented (approximately 10 “20% of final code)

  • Lower layers in a layered architecture have been almost completely implemented

  • Implemented code has been unit-tested

  • Initial performance- and load-test of architecture has been done, primarily driven by architecturally significant UCs

  • Functionality of 4 architecturally significant UCs has been properly tested

End of the first iteration in Construction

  • 12 UCs described in detail, 3 with some depth

  • 18 main components identified (one was not needed due to elimination of a UC)

  • 10 have been almost completely implemented

  • 8 have 50% of the code implemented, including all interfaces

  • 8 have interfaces plus minimal logic implemented (approximately 10 “20% of final code)

  • Lower layers in a layered architecture have been completely implemented

  • Implemented code has been unit-tested

  • Performance- and load-test of the system are continued to ensure architecture has not been compromised

  • Functional testing of UCs is done as they are completed

End of second iteration in Construction

  • 1 of the 3 UCs not yet described is scoped out due to time constraints

  • Other 14 UCs described in detail

  • 18 main components identified (one was not needed due to elimination of a UC)

  • 10 have been almost completely implemented

  • 8 have 50% of the code implemented, including all interfaces

  • implemented code has been unit-tested

  • Performance- and load-test of the system is continued to ensure architecture has not been compromised

  • Functional testing of UCs is done as they are completed

End of third and last iteration in Construction

  • 14 UCs described in detail

  • 18 main components identified

  • System is fully functional; you have a beta release

  • All 18 components have been almost completely implemented (fine-tuning and bug fixing will take place during Transition)

  • Implemented code has been unit-tested

  • Performance- and load-test of the system are continued to ensure architecture has not been compromised

  • Functional testing of UCs is done as they are completed



The Rational Unified Process Made Easy(c) A Practitioner's Guide to Rational Unified Process
Programming Microsoft Visual C++
ISBN: N/A
EAN: 2147483647
Year: 2005
Pages: 173

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net