Best Practice: Develop Iteratively
To mitigate risks, develop incrementally in
an iterative fashion. Each iteration results in an executable release.
Topics
A project using iterative development has a lifecycle consisting of
several iterations. An iteration incorporates a loosely sequential set of
activities in business modeling, requirements, analysis and design,
implementation, test, and deployment, in various proportions depending on where
in the development cycle the iteration is located. Iterations in the inception
and elaboration phases focus on management, requirements, and design activities;
iterations in the construction phase focus on design, implementation, and test;
and iterations in the transition phase focus on test and deployment. Iterations
should be managed in a timeboxed
fashion, that is, the schedule for an iteration should be regarded as fixed, and
the scope of the iteration's content actively managed to meet that schedule.
An initial design is likely to be flawed with respect to its key requirements.
Late discovery of design defects results in costly over-runs and, in some cases,
even project cancellation.
All projects have a set of risks involved. The earlier in the lifecycle
you can verify that you've avoided a risk, the more accurate you can make
your plans. Many risks are not even discovered until you've attempted
to integrate the system. You will never be able to predict all risks regardless
of how experienced the development team is.
In a waterfall lifecycle, you can't verify
whether you have stayed clear of a risk until late in the lifecycle.
In an iterative lifecycle, you select
what increment to develop in an iteration based on a list of key risks. Since
the iteration produces a tested executable, you can verify whether
you have mitigated the targeted risks or not.
An iterative approach is generally superior to a linear or waterfall approach
for many different reasons.
- Risks are mitigated earlier, because elements are integrated
progressively.
- Changing requirements and tactics are accommodated.
- Improving and refining the product is facilitated, resulting in a more
robust product.
- Organizations can learn from this approach and improve their process.
- Reusability is increased.
A customer once said: "With the waterfall approach, everything looks
fine until near the end of the project, sometimes up until the middle of
integration. Then everything falls apart. With the iterative approach, it is
very difficult to hide the truth for very long."
Project managers often resist the iterative approach, seeing it as
endless hacking. In the Rational Unified Process, the interactive
approach is very controlled; iterations are planned in number, duration, and
objective. The tasks and responsibilities of the participants are defined.
Objective measures of progress are captured. Some rework does take place from
one iteration to the next, but this, too, is carefully controlled.
An iterative approach lets you mitigate risks earlier, because many risks are only
addressed and discovered during integration. As you unroll the early iteration, you go through all
disciplines,
exercising many aspects of the project: tools, off-the-shelf software, people
skills, and so on. Perceived risks may prove not to be risks, and new,
unsuspected risks will show up.
Integration is not one "big bang" at the end—elements are
incorporated progressively. In reality, the iterative approach is an almost continuous integration. What used
to be a long, uncertain, and difficult time—taking up to 40% of the total
effort at the end of a project—and what was hard to plan accurately, is
divided into
six to nine smaller integrations that start with far fewer elements to
integrate.
The iterative approach lets you take into account changing requirements as
they will
normally change along the way.
Changes in requirements and requirements "creep" have always been
primary sources of trouble for a project,
leading to late delivery, missed schedules, unsatisfied customers, and
frustrated developers. Twenty-five years ago, Fred Brooks wrote: "Plan to throw one
away, you will anyhow." Users will change their mind along the way. This
is human nature. Forcing users to accept the system as they
originally imagined it is wrong. They change their minds because the context is
changing—they learn more about the environment and the technology, and they see
intermediate demonstration of the product as it's being developed.
An iterative lifecycle provides management with a way of making tactical changes to the
product. For
example, to compete with existing products, you may decide to
release a reduced-functionality product earlier to counter a move by a
competitor, or you may adopt another vendor for a given technology.
Iteration also allows for technological changes along the way. If some technology changes or becomes a
standard as new technology
appears, the project can take advantage of it. This is particularly the case
for platform changes and lower-level infrastructure changes.
An iterative approach results in a more robust architecture because errors are corrected over
several iterations. Early flaws are detected as the product matures during the early
iterations. Performance bottlenecks are discovered and can be reduced, as
opposed to being discovered on the eve of delivery.
Developing iteratively, as opposed to running tests once toward the end of the
project, results in a more thoroughly tested product. Critical functions have had many opportunities to be
tested over
several iterations, and the tests themselves, and any test software, have had
time to mature.
Developers can learn along the way, and the various competencies and
specialties are more fully employed during the whole lifecycle.
Rather than waiting a long time just making plans and honing their skills,
testers start testing early, technical writing starts early, and so on.
The need for additional training or external help can be detected in the early
iteration assessment reviews.
The process itself can be improved and refined as it develops. The assessment at the end of an iteration not only looks at the status of
the project from a product-schedule perspective, but also analyzes what needs
to be changed in the organization and the process to perform better in the next
iteration.
An iterative lifecycle facilitates reuse. It's easier to identify common parts as they
are partially designed or implemented, compared to having to identify all
commonality up front.
Identifying and developing reusable parts is difficult. Design reviews in
early iterations allow software architects to identify unsuspected, potential reuse,
and subsequent iterations allow them to further develop and mature this common
code.
Using an iterative approach makes it easier to take advantage of commercial-off-the-shelf products. You have several iterations to select them, integrate them, and validate
that they fit with the architecture.
Copyright
© 1987 - 2001 Rational Software Corporation
| 
Overview >
Best Practices >
