Update 27-Apr-2003

Waterfall Model

Figure 1.

The waterfall model is the classical model of development for both hardware and software. This model is frequently called the conventional model. The project is expected to progress down the (primary) path through each of the phases (requirements, design, coding and unit test, integration, and maintenance) of development, with deliverables (software requirements specification, design documents, actual code and test cases, final product, product updates) at each stage.

Work products (called deliverables) flow down the primary, stepwise path of normal development. The reverse flow represents iterative changes applied to a prior deliverable, the need for which has been only recognized in the next phase or even later. This is a natural consequence of the uncertainly associated with all development activity. Such changes are called rework and will require that not only some portion of the prior phase be repeated but the current one as well.

Incremental Model

Figure 2.

The incremental life cycle model was one of the first variations to be derived from the waterfall model. The assumption behind the model is that the requirements can be segmented into an incremental series of the products, each of which is developed somewhat independently.

Incremental Waterfall Model

Figure 3.

In addition to the benefits that arise from being variation of the waterfall model, the incremental model has the following advantages: (1) Less cost and time is required to make the first delivery. (2) Less risk is incurred to develop the smaller systems represented by the increments. (3) User requirement changes may decrease because of the quicker time to first release. (4) Incremental funding is allowed; that is, only one or two increments might be funded when the program starts.

However, if the incremental model is inappropriate or misused, it has the following disadvantages: (1) Fielding of initial increments may destabilize later increments through unplanned levels of user change requests. (2) If requirements are not as stable or complete as thought earlier, increments might be withdrawn from service, reworked, and re-released. (3) Managing the resulting cost, schedule, and configuration complexity may exceed the capabilities of the organization.

Evolutionary Model

Figure 4.

The next logical step in life cycle development is the evolutionary model, which explicitly extends the incremental model to the requirements phase. Fig.4 illustrates this, showing that the first build increment is used to refine the requirement s for a second build increment.

The advantages of the evolutionary model are as follows: (1) The model can be used when the requirements cannot or will not be specified. (2) The user can experiment with the system to improve the requirements. (3) Greater user/acquirer involvement is required than in the waterfall method.

The disadvantages are: (1) Use of the method is exploratory in nature and therefore constitutes a high-risk endeavor. Strong management is required. (2) This method is used as an excuse for hacking to avoid documenting the requirements or design, even if they are well understood. (3) Users/acquirers do not understand the nature of the approach and can be disappointed when results are unsatisfactory.

Spiral Model

Figure 5.

The main features of the spiral model are:

Planning, Analysis, Development, and Testing are repeated on each iteration.

User acceptance testing will be started only after source code is ready.

Mapping of the Activities and Multiple Releases

Figure 6.

Mapping of the Activities and Multiple releases (Builds) is shown on Fig. 6.

See US Military MIL-STD-498 standard for further information.