Concepts: Alternate Lifecycle Patterns

Topics

Incremental Lifecycle

"The incremental strategy determines user needs, and defines the system requirements, and then performs the rest of the development in a sequence of builds. The first build incorporates parts of the planned capabilities, the next build adds more capabilities, and so on until the system is complete." [DOD94]

The following iterations are characteristic:

a short Inception iteration to establish scope and vision, and to define the business case
a single Elaboration iteration, during which requirements are defined, and the architecture established
several Construction iterations during which the use cases are realized and the architecture fleshed-out
several Transition iterations to migrate the product into the user community

This strategy is appropriate when:

The problem domain is familiar
Risks are well-understood
The project team is experienced

Evolutionary Lifecycle

"The evolutionary strategy differs from the incremental in acknowledging that user needs are not fully understood, and all requirements cannot be defined up front, they are refined in each successive build." [DOD94]

The following iterations are characteristic:

a short Inception iteration to establish scope and vision, and to define the business case
several Elaboration iterations, during which requirements are refined at each iteration
a single Construction iteration, during which the use cases are realized and the architecture fleshed-out
several Transition iterations to migrate the product into the user community

This strategy is appropriate when:

The problem domain is new or unfamiliar
The team is inexperienced

Incremental Delivery Lifecycle

Some authors have also phased deliveries of incremental functionality to the customer [GIL88]. This may be required where there are tight time-to-market pressures, where delivery of certain key features early can yield significant business benefits.

In terms of the phase-iteration approach, the transition phase begins early on and has the most iterations. This strategy requires a very stable architecture, which is hard to achieve in an initial development cycle, for an "unprecedented" system.

The following iterations are characteristic:

a short Inception iteration to establish scope and vision, and to define the business case
a single Elaboration iteration, during which a stable architecture is baselined
a single Construction iteration, during which the use cases are realized and the architecture fleshed-out
several Transition iterations to migrate the product into the user community

This strategy is appropriate when:

The problem domain is familiar
- the architecture and requirements can be stabilized early in the development cycle
- there is a low degree of novelty in the problem
The team is experienced
Incremental releases of functionality have high value to the customer

"Grand Design" Lifecycle

The traditional waterfall approach can be seen as a degenerated case in which there is only one iteration in the construction phase. It is called "grand design" in [DOD94]. In practice, it is hard to avoid additional iterations in the transition phase.

The following iterations are characteristic:

a short Inception iteration to establish scope and vision, and to define the business case
a single very long Construction iteration, during which the use cases are realized and the architecture fleshed-out
several Transition iterations to migrate the product into the user community

This strategy is appropriate when:

a small increment of well-defined functionality is being added to a very stable product
the new functionality is well-defined and well-understood
The team is experienced, both in the problem domain and with the existing product

Hybrid Strategies

In practice few projects strictly follow one strategy. You often end up with a hybrid, some evolution at the beginning, some incremental building, and multiple deliveries. Among the advantages of the phase-iteration model is that it lets you accommodate a hybrid approach, simply by increasing the length and number of iterations in particular phases:

For complex or unfamiliar problem domains, where there is a high degree of exploration: increase the number of iterations in the elaboration phase and its length.
For more complex development problems, where there is complexity translating the design into code: increase the number of iterations in the construction phase and its length.
To deliver software in a series of incremental releases: increase the number of iterations in the transition phase and its length.

Rational Unified Process 5.1 (build 43)