Transition Iterations and Development Cycles

Transition and Iterations

The Transition phase ranges from being very straightforward to extremely complex, depending on the kind of product (see Figure 9.2). A new release of an existing desktop product may be very simple, merely requiring some minor bug fixes that can be done in one iteration. The replacement of an air-traffic control system may be extremely complex, however, requiring several iterations in which additional features and integrations with other systems need to be added, and complex cutover activities need to take place to transition the business from using the old system to the new system. This transition can include running old and new systems in parallel, migrating data, training users, and adjusting business processes.

Figure 9.2. Number of Iterations in Transition. The number of iterations required in Transition varies: For a simple system requiring primarily minor bug fixing, one iteration may suffice. For a complex system, such as an air-traffic control system, several iterations may be required to add features and perform complex cutover activities to transition the business from using the old system to using the new system.

Activities performed in Transition iterations depend on the project goal(s). Most projects have a reasonably simple Transition, working on fixing bugs ; the primary focus is implementation and testing. Occasionally, new features may have to be added, and the iteration is then similar to a Construction phase iteration in that it requires some work on requirements, analysis and design, and so on.

When developing commercial products, and sometimes applications for wide internal use, you have to address packaging, production, marketing, and potential rollout to a sales and support organization. This is described in more detail in the section Objective 4: Prepare for Launch: Packaging, Production, and Marketing Rollout.

When developing applications that require a lot of new hardware, such as large financial processing systems, or require conversion of data from old to new systems, you have to address the activities described in the section Objective 3: Prepare Deployment Site and Convert Operational Databases.

Very complex projects may require an incremental delivery approach, each deployment providing an increasingly more complete and higher quality version of the system. This approach may be necessary if the only way to fine-tune the system is with feedback from actual system usage. This method is common for large-scale management information systems, or command and control systems, with distributed deployment and complex hardware requiring multiple systems to be integrated and fine- tuned together. Transition iterations for such projects would look very much like the final iteration or final two iterations in Construction (see Chapter 8), with the added complexity of having to manage multiple deployments. Describing the complexity of these types of projects is outside the scope of this book.

Transition and Development Cycles

By the end of Transition, the phase objectives should have been met, and the project should be in a position to be closed. For some projects, the end of the current lifecycle may coincide with the start of another lifecycle, leading to the next generation of the same product. For other projects, the end of Transition may coincide with a complete delivery of the artifacts to a third party, who may be responsible for operations, maintenance, and enhancements of the delivered system.

One pass through the four RUP phases (Inception, Elaboration, Construction, and Transition) is a Development Cycle : At the end of Transition you have completed a development cycle (see Figure 9.3). Each development cycle produces a generation of the software. Unless the product "dies," it will evolve into its next generation by repeating the same sequence of Inception, Elaboration, Construction, and Transition phases, but with a different emphasis on the various phases, as required for the new project goals. These subsequent cycles are called evolution cycles (see also Chapter 12).

Figure 9.3. Development Cycles. A Development Cycle consists of one pass through the four RUP phases, usually broken down into five to nine iterations, and followed by another Development Cycle (evolution cycle). In many cases, the Inception phase of the evolution cycle overlaps with the Transition phase of the existing cycle.

There is often an overlap between two development cycles, where the Inception phase of the next development cycle overlaps with the Transition phase of the existing one. You may choose not to have an overlap or to have a bigger overlap, but by starting the next development cycle much earlier than the current Transition phase, you introduce a substantial amount of complexity, requiring mature development organizations with advanced Configuration Management processes.

Whereas major evolution of a system should be undertaken as a project using a RUP lifecycle and its four phases, many systems simply enter into another mode in which operations, support, and routine maintenance are provided on an ongoing basis, mostly driven by external requests and not with any predefined phases and milestones. A bug-fix release can take the shape of a very simple iteration, similar to what you would do in Transition, running through a few of the RUP activities in implementation, testing, and deployment. ^[1]

^[1] See Kruchten 2000b.