Unified Process Lifecycle

Throughout this book you will see references to the Unified Process lifecycle. This is the lifecycle used in RUP and OpenUP, and all other processes part of the Unified Process family. It is one of several lifecycles supported in the EPF. Even though the practices in this book typically apply to any iterative lifecycle, they work particularly well with the Unified Process lifecycle.

The Unified Process lifecycle divides a project into four phases: Inception, Elaboration, Construction, and Transition.

The lifecycle describes the time dimension of project, that is, how a project is divided into phases and iterations. It divides a project into four phases: Inception, Elaboration, Construction, and Transition, each ending with a well-defined milestone.^[18] Each phase has specific objectives:

^[18] See Kroll 2003 for an in-depth overview of what is done in each phase.

1. Inception. Establish the scope of the system, including a good understanding of what system to build, by reaching a high-level understanding of the requirements. Mitigate many of the business risks and produce the business case for building the system and a vision document to get buy-in from all stakeholders on whether or not to proceed with the project. This is similar to what many agile processes refer to as Iteration 0.

2. Elaboration. Reduce major risks to enable cost and schedule estimates to be updated and to get buy-in from key stakeholders. Mitigate major technical risks by taking care of many of the most technically difficult tasks. Design, implement, test, and baseline an executable architecture, including subsystems, their interfaces, key components, and architectural mechanisms such as how to deal with interprocess communication or persistency. Address major business risks by defining, designing, implementing, and testing key capabilities, which are validated with the customer. Do not define and analyze all requirements at this time, as doing so would lead to waterfall development. Detail and analyze only the requirements required to address the above risks.

3. Construction. Undertake a majority of the implementation as you move from an executable architecture to the first operational version of your system. Deploy several internal and alpha releases to ensure that the system is usable and addresses user needs. End the phase by deploying a fully functional beta version of the system, including installation and supporting documentation and training material (although the system will likely still require fine-tuning of functionality, performance, and overall quality).

4. Transition. Ensure that software addresses the needs of its users by testing the product in preparation for release and making minor adjustments based on user feedback. At this point in the lifecycle, user feedback focuses mainly on fine-tuning, configuration, installation, and usability issues; all the major structural issues should have been worked out much earlier in the project lifecycle.

Each phase contains one or more iterations, each producing a product increment.

Each phase contains one or more iterations (see Figure 1.3), which focus on producing a product increment, that is, the working code and other deliverables necessary to achieve the business objectives of that phase. There are as many iterations as it takes to adequately address the objectives of that phase, but no more. If objectives cannot be adequately addressed within the planned phase, another iteration should be added to the phase, but this will delay the project. To avoid such a delay, make sure that each iteration is sharply focused on just what is needed to achieve the business objectives of that phase, but no less. For example, focusing too heavily on requirements in Inception is counterproductive; so is not involving stakeholders.

Figure 1.3. The Unified Process Lifecycle.

Each of the four phases in the Unified Process lifecycle consists of one or several iterations. Each iteration builds on the result of previous iterations, delivering a product increment one step closer to the final release. Product increments should include working software, with a possible exception being the product increments produced in the Inception phase for new applications.

The Unified Process lifecycle provides a great deal of flexibility. Product increments may be internal only and may be demonstrated or deployed only to select project stakeholders. Other product increments may also be released for use by customers. For example, some projects benefit from the deployment of several product increments to the production environment, which allows end users to adopt the most critical capabilities more rapidly. You can do this by rapidly moving into the Transition phase and having several Transition iterations, each deploying a release into the production environment (see Figure 1.4).

Figure 1.4. Incremental Delivery Using the Unified Process Lifecycle.

Projects that deliver product increments into the production environment often rapidly move into the Transition phase. Once in Transition, they deliver a new product increment to production at the end of each iteration. The milestone at the end of the Construction phase aims at ensuring that all pieces are together so that the system can be deployed. You should pass this management milestone before undertaking deployments into the production environment.