Chapter 9. The Transition Phase

In this chapter, we introduce the fourth and final phase of the RUP lifecycle, the Transition Phase (see Figure 9.1). While you read this chapter, remember that you need to decide how formally you want to capture artifacts: This could be done in your head, on a whiteboard, or in a model or document.

Figure 9.1. The Transition Phase. The Transition phase is the fourth and last phase of the RUP lifecycle; it has a well-defined set of objectives and is concluded by the Product Release Milestone. Use these objectives to help you decide which activities to carry out and which artifacts to produce.

You ended the Construction phase with the deployment of a fully functional beta version of the system, including the installer, supporting documentation, and training material. But you know that this beta version is not the final product and that it still requires fine-tuning of functionality, performance, and overall quality.

The focus of the Transition phase is to ensure that the software fully addresses the needs of its users. The Transition phase normally spans one or two iterations that include testing the product in preparation for release and making minor adjustments based on user feedback. At this point in the lifecycle, all major structural issues should have been worked out, and user feedback should focus mainly on fine-tuning, configuration, installation, and usability issues. More complex projects may have several iterations in Transition, with each iteration producing a more refined, deployable version of the system. Often in Transition you may have to complete some feature that had been postponed to meet some earlier deadline.

It should be noted that the Transition phase in the RUP approach differs radically from traditional development, primarily because you enter the phase with a reasonably stable, integrated, and tested version of the system. Conversely, in the traditional waterfall approach, the final integration phase often starts with major breakage ”sometimes you cannot even compile the whole system, interfaces between subsystems are not compatible, or the system crashes frequently, resulting in major rework for your team and several weeks' delay before the system is up and running and ready to test. The introduced delays result in a large portion of management time being spent on resetting and renegotiating expectations from key stakeholders.