Communicating the Iterative Nature of the Unified Process
|
|
Communicating the Iterative Nature of the Unified Process |
|
 |
One of the issues that teams oftentimes struggle with when adopting the Unified Process (UP), including the Rational Unified Process (RUP) and the Enterprise Unified ProcessTM (EUP), is the iterative and incremental nature of developing software. Many teams, upon seeing the four phases of the RUP (Inception, Elaboration, Construction, and Transition) and the two additional phases of the EUP (Production and Retirement) assume, perhaps subconsciously, that it is serial in nature. While this in part is true, we like to say that the UP is serial in the large and iterative in the small, delivering incremental releases over time. People coming from a waterfall background often associate the four phases of the RUP with Requirements, Design, Coding, Integration and Testing. Nothing could be further from the truth. |
Software development using the UP proceeds via a series of iterations. Each
iteration is serial in nature, wherein the team performs requirements, analysis,
design, coding, etc. in basically (but not completely) a serial pattern. At end
of each iteration, the team has completed developing a portion of the system
under development. It is a living, breathing, tested, working portion of the
system. It may be even be deployed for end-users to use. This portion is built
upon during subsequent iterations until the entire system has been developed.
Note that the Inception iteration(s) may differ in the tasks they perform. They
do not typically entail design or coding or deliver a working portion of the
system. Instead, iterations in Inception concentrates on identify the vision
that the stakeholders have for the entire project in order to achieve consensus
on what is to be done.
Iterations are relatively short in nature, on the order of weeks rather than
months. This helps to address one of the main drawbacks of the waterfall
methodology: changing requirements.
Requirements
will change during the lifetime
of a project. With a waterfall approach, where all
the requirements are identified and signed off at the beginning of the project,
changes in requirements force the waterfall approach to be "short-circuited".
That is, even though the requirements portion of the project has ended, more
requirements work must be done. Many waterfall methodologies allow for this by
modifying the waterfall approach to account for this. The problem that this
raises is that it cuts down the effectiveness of the premise of the waterfall
approach: the requirements can be identified once and then work can concentrate
on the design. If the design team has to constantly receive and react to changes
to the "signed off" requirements, they are losing one of the main benefits of
the waterfall approach: stable requirements to work from. Not only that but much
of the requirements effort may have to be redone if flaws are discovered in the
early stages of design that require much of the requirements to be re-addressed.
On UP projects, requirements can change, too. How do small iterations help
address this? Each iteration starts by identifying and analyzing requirements.
This happens right before design begins, not in some phase that occurred months
ago. If any clarification / changes need to be made during design, the
requirements specifiers are there and can address them. And if the clarification
/ changes affect subsequent requirements, well, work hasn't even begun on them
yet so there's no cost to "re-work" them.
Most importantly, however, my experience is that changing requirements are best
handled in UP by embracing change (this philosophy is adopted from
eXtreme Programming and
Agile Modeling). Change is EXPECTED
on projects and planned for. It is assumed that it is not possible to identify
100% of the requirements and to get them exactly right at the beginning of a
project. Subsets of requirements are identified, analyzed, designed, coded and
tested by team in a small window of time. Changes necessary due to discoveries
during analysis, design, coding, etc. are all incorporated during either the
current or subsequent iterations. And because end users can actually see, feel,
and work with the product as it is being developed, they develop a much better
understanding of what it is they will get and how it meets their needs.
One technique to convey the importance of the iterative approach of a UP project is to change
the UP diagram a bit to put the Iterations on top instead of on the bottom of
the diagram.
Figure 1. Iterations-based lifecycle of the Enterprise Unified Process (EUP)
v2004.
The iterations are now “on top of the world” and more readily apparent. This helps people to think in terms of iterations instead of phases and helps them to avoid the waterfall mindset.
|
|
|
|
The Enterprise Unified Process: Extending the Rational Unified Process by Scott W. Ambler, John Nalbone, and Michael Vizdos. Whereas the RUP defines a software development lifecycle, the EUP extends it to cover the entire information technology (IT) lifecycle. The extensions include two new phases, Production and Retirement, and several new disciplines: Operations and Support and the seven enterprise disciplines (Enterprise Business Modeling, Portfolio Management, Enterprise Architecture, Strategic Reuse, People Management, Enterprise Administration, and Software Process Improvement). |
|
|
Copyright ©
2004-2007
Scott W. Ambler |
