Topics

Why iterate? To top of page

Traditionally, projects have been organized to go through each workflow 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 workflows, 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 workflows is called an iteration.

Thus, 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.

What is an iteration? To top of page

An iteration encompasses the development activities that lead to a product release - a stable, executable versions of 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 workflows: requirements workflow, analysis and design workflow, implementation workflow, test workflow, at least. It is like a small waterfall project in itself.

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, etc. 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  To top of page

In the Rational Unified Process, each of the phases is subdivided into iterations.

Different kinds of iterations To top of page

The objectives of the different phases vary, and therefore the actual nature of the iterations will vary from phase to phase, even if they go roughly through the same activities.

Inception phase To top of page

Elaboration phase To top of page

Construction phase To top of page

Display Rational Unified Process using frames

 

© Rational Software Corporation 1998 Rational Unified Process 5.1 (build 43)