Concepts: Iteration Topics Why Iterate? What is an Iteration? Iteration and Phases Iteration pattern: Incremental Lifecycle Iteration pattern: Evolutionary Lifecycle Iteration pattern: Incremental Delivery Lifecycle Iteration pattern: "Grand Design" Lifecycle Iteration pattern: Hybrid Strategies   Why Iterate? Traditionally, projects have been organized to go through each discipline in sequence, once and only once. This leads to the waterfall lifecycle: This often results in an integration 'pile-up' late in implementation when, for the first time, the product is built and testing begins. Problems which have remained hidden throughout Analysis, Design and Implementation come boiling to the surface, and the project grinds to a halt as a lengthy bug-fix cycle begins. A more flexible (and less risky) way to proceed is to go several times through the various development disciplines, building a better understanding of the requirements, engineering a robust architecture, ramping up the development organization, and eventually delivering a series of implementations that are gradually more complete. This is called an iterative lifecycle. Each pass through the sequence of process disciplines is called an iteration. Therefore, from a development perspective the software lifecycle is a succession of iterations, through which the software develops incrementally. Each iteration concludes with the release of an executable product. This product may be a subset of the complete vision, but useful from some engineering or user perspective. Each release is accompanied by supporting artifacts: release description, user documentation, plans, and so on, and updated models of the system. The main consequence of this iterative approach is that the sets of artifacts, described earlier, grow and mature over time, as shown in the following diagram. Information set evolution over the development phases.   What is an Iteration? An iteration encompasses the development activities that lead to a product release-a stable, executable version of the product, together with any other peripheral elements necessary to use this release. So a development iteration is in some sense one complete pass through all the disciplines: Requirements, Analysis & Design, Implementation, and Test, at least. It is like a small waterfall project in itself. Note that evaluation criteria are established when each iteration is planned. The release will have planned capability which is demonstrable. The duration of an iteration will vary depending on the size and nature of the project, but it is likely that multiple builds will be constructed in each iteration, as specified in the Integration Build Plan for the iteration. This is a consequence of the continuous integration approach recommended in the Rational Unified Process (RUP): as unit-tested components become available, they are integrated, then a build is produced and subjected to integration testing. In this way, the capability of the integrated software grows as the iteration proceeds, towards the goals set when the iteration was planned. It could be argued that each build itself represents a mini-iteration, the difference is in the planning required and the formality of the assessment performed. It may be appropriate and convenient in some projects to construct builds on a daily basis, but these would not represent iterations as the RUP defines them-except perhaps for a very small, single person project. Even for small multi-person projects (for example, involving five people building 10,000 lines of code), it would be very difficult to achieve an iteration duration of less than a week. Release A release can be internal or external. An internal release is used only by the development organization, as part of a milestone, or for a demonstration to users or customers. An external release (or delivery) is delivered to end users. A release is not necessarily a complete product, but can just be one step along the way, with its usefulness measured only from an engineering perspective. Releases act as a forcing function that drives the development team to get closure at regular intervals, avoiding the "90% done, 90% remaining" syndrome. Iterations and releases allow a better usage over time of the various specialties in the team: designers, testers, writers, and so forth. Regular releases let you break down the integration and test issues and spread them across the development cycle. These issues have often been the downfall of large projects because all problems were discovered at once during the single massive integration step, which occurred very late in the cycle, and where a single problem halts the whole team. At each iteration, artifacts are updated. It is said that this is a bit like "growing" software. Instead of developing artifacts one after another, in a pipeline fashion, they are evolving across the cycle, although at different rates. Minor milestone Each iteration is concluded by a minor milestone, where the result of the iteration is assessed relative to the objective success criteria of that particular iteration.   Iteration and Phases Each iteration within a phase results in an executable release of the system. Each phase in the RUP can be further broken down into iterations. An iteration is a complete development loop resulting in a release (internal or external) of an executable product, a subset of the final product under development, which grows incrementally from iteration to iteration to become the final system.   Iteration pattern: Incremental Lifecycle "The incremental strategy determines user needs, and defines the system requirements, and then performs the rest of the development in a sequence of builds. The first build incorporates parts of the planned capabilities, the next build adds more capabilities, and so on until the system is complete." [DOD94] The following iterations are characteristic: a short Inception iteration to establish scope and vision, and to define the business case a single Elaboration iteration, during which requirements are defined, and the architecture established several Construction iterations during which the use cases are realized and the architecture fleshed-out several Transition iterations to migrate the product into the user community This strategy is appropriate when: The problem domain is familiar. Risks are well-understood. The project team is experienced.   Iteration pattern: Evolutionary Lifecycle "The evolutionary strategy differs from the incremental in acknowledging that user needs are not fully understood, and all requirements cannot be defined up front, they are refined in each successive build." [DOD94] The following iterations are characteristic: a short Inception iteration to establish scope and vision, and to define the business case several Elaboration iterations, during which requirements are refined at each iteration a single Construction iteration, during which the use cases are realized and the architecture is expanded upon several Transition iterations to migrate the product into the user community This strategy is appropriate when: The problem domain is new or unfamiliar. The team is inexperienced.   Iteration pattern: Incremental Delivery Lifecycle Some authors have also phased deliveries of incremental functionality to the customer [GIL88]. This may be required where there are tight time-to-market pressures, where delivery of certain key features early can yield significant business benefits. In terms of the phase-iteration approach, the transition phase begins early on and has the most iterations. This strategy requires a very stable architecture, which is hard to achieve in an initial development cycle, for an "unprecedented" system. The following iterations are characteristic: a short Inception iteration to establish scope and vision, and to define the business case a single Elaboration iteration, during which a stable architecture is baselined a single Construction iteration, during which the use cases are realized and the architecture fleshed-out several Transition iterations to migrate the product into the user community This strategy is appropriate when: The problem domain is familiar: the architecture and requirements can be stabilized early in the development cycle there is a low degree of novelty in the problem The team is experienced. Incremental releases of functionality have high value to the customer.   Iteration pattern: "Grand Design" Lifecycle The traditional waterfall approach can be seen as a degenerated case in which there is only one iteration in the construction phase. It is called "grand design" in [DOD94]. In practice, it is hard to avoid additional iterations in the transition phase. The following iterations are characteristic: a short Inception iteration to establish scope and vision, and to define the business case a single very long Construction iteration, during which the use cases are realized and the architecture fleshed-out several Transition iterations to migrate the product into the user community This strategy is appropriate when: a small increment of well-defined functionality is being added to a very stable product the new functionality is well-defined and well-understood The team is experienced, both in the problem domain and with the existing product   Iteration pattern: Hybrid Strategies In practice few projects strictly follow one strategy. You often end up with a hybrid, some evolution at the beginning, some incremental building, and multiple deliveries. Among the advantages of the phase-iteration model is that it lets you accommodate a hybrid approach, simply by increasing the length and number of iterations in particular phases: For complex or unfamiliar problem domains, where there is a high degree of exploration: increase the number of iterations in the elaboration phase and its length. For more complex development problems, where there is complexity translating the design into code: increase the number of iterations in the construction phase and its length. To deliver software in a series of incremental releases: increase the number of iterations in the transition phase and its length. © Copyright IBM Corp. 1987, 2004. All Rights Reserved.

Rational Unified Process