One of the issues that teams oftentimes struggle with when adopting the
Unified Process (UP), is the
iterative and incremental nature of developing software. Many teams, upon seeing
the four phases of the RUP (Inception,
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.
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.
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.
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.
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 (just as we see in agile methods such as
eXtreme Programming and
Disciplined Agile Delivery (DAD)). 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.