Concepts:
Iteration
Topics
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.
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 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. For an explanation of why,
see Guidelines: Software Development Plan.
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.
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.
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
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
© 1987 - 2001 Rational Software Corporation
| 
Disciplines >
Project Management >
Concepts >
