EUP

The Iterative Nature of the Unified Process

Follow @scottwambler on Twitter!

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


Iterations

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.

Changing Requirements

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.