Introduction to Lifecycle Models: The Waterfall Model

Software Lifecycle Models

Software lifecycle models identify the key activities in the development of a software system and their relationships to one another. This is distinct from development methodologies, which prescribe detailed approaches for each of the key activities. For example, a lifecycle model may state that there is an activity called "design" which follows another called "requirements analysis"; a methodology will specify how the activity of design is supposed to be carried out.

Code-Fix

The most primitive lifecycle model is often referred to as Code-Fix. This is the approach adopted by most students for solving assigned programming problems (raise your hand if guilty). The code-fix approach consists of:

1. writing some code which (one hopes) will solve the problem;
2. attempting to compile and execute the code;
3. fixing any errors which are detected; and
4. repeating until the solution is deemed "good enough"

Or, put more simply: Code, Fix, repeat. This approach is generally effective enough for small problems where the solution is "obvious". It fails spectacularly for any software system large enough to be interesting in the "real world".

Waterfall Model

The Waterfall Model was originally developed in the early 1970s in an attempt to provide some structure to large-scale software development. It was refined over the next decade until it reached the form presented here. The Waterfall approach is still used successfully in many large software development projects and has been institutionalized in several software development standards (some of which we will see later in the course). The Waterfall Model is illustrated in figure 1. As can be seen, the model consists of eight primary activities, executed in a sequential order. The activities are:

System Feasibility

Initial decision as to whether the system should be built at all, and if so, in what form.

Software Plans and Requirements

Development of a complete specification of the system's required attributes.

Product Design

Development of a complete specification of the system's modules, their interrelationships, and other documentation.

Detailed Design

Development of the complete specification of each module's internal structure.

Coding

Creation of the software source code for each module.

Integration

Assembly of the modules to form a completed system.

Implementation

The system installed on the target platform and operational for the customer.

Operations and Maintenance

The ongoing use, refinement and modification of the system.

Each of these activities is deemed complete once a verification or validation activity is completed. These ensure that the product of each activity satisfies its goals. Validation activities ensure that the product will meet its intended mission ("doing the right thing") while verification activities ensure that the product meets a previously developed specification ("doing the thing right"). A key issue here is requirements traceability which refers to the tracking of identified requirements through to their ultimate satisfaction.

Configuration Management

The products of each activity are normally maintained via a configuration management system, the goal of which is to provide a definitive version of any of the products at any time. Such a definitive version is called a baseline; each is established at a milestone (typically the completion of an activity). The milestone baseline process typically works as:

1. An initial version of the activity's product is developed
2. This version is verified or validated, and development is iterated until a satisfactory version is obtained
3. A formal product review determines whether the product is satisfactory and the next activity can begin. If not, back to step 1.
4. Once the product is satisfactory it is "baselined" and put under configuration management.

Advantages of baselining:

1. Changing a baseline requires agreement of all interested parties;
2. This tends to stabilize the product; and
3. There is always a definitive version of each product.

Economic Rationale

The economic rationale for the Waterfall Model rests on two premises:

1. To achieve a successful product, we must successfully complete all the activities anyway.
2. Any different order will produce a less successful product.

Premise 1 appears to hold, at least for large systems. The rationale for Premise 2 is presented in figure 2. In short, it is generally much more expensive to repair an error in the activities normally found later in the cycle. This is particularly true for large products where the variance can be a factor of 100. Thus, it makes sense to eliminate the errors as rigorously as possible in the earlier activities.

Incremental Development

One refinement of the Waterfall Model is incremental development, illustrated at figure 3. In this approach, part of the Product Design stage is the identification of suitable product increments which can be developed one at a time. Typically these represent useful subsets of the total product functionality. For example, increment 1 might include all of the "must have" features, increment 2 all of the "should have" features, and increment 3 all of the "nice to have" features. At the end of each increment we have a functioning software system, deliverable to the user, satisfying some subset of the total requirement.

This approach is valuable because:

• It is easier to build and validate a subset of the requirements than it is to do the whole thing. ("Every large, functional software system was once a small, functional software system.")
• Feedback from both the users and the development process itself can be used to refine successive increments.

One other nice feature of the approach is that it tends to flatten the required staffing curve. A comparison of the staffing curve for a strict Waterfall project with that of an incremental Waterfall project is found at figure 4.

"Advancemanship"

Another refinement of the Waterfall Model is to begin work on "future" activities before the "current" activity is complete. The aim of this is to prepare the way for the beginning of the main effort on the "future" activity. This can include:

• the definition of detailed objectives and plans;
• the creation of early documentation (e.g., a draft user manual might be prepared during the product design phase, allowing the users to get a better feel for the properties of the developed system)
• the development of scaffolding; extra products developed to make the main effort go smoothly. This can include dummy components or "stubs", miniature data files, test data generators, etc.

Reference

Chapter 4 of Boehm, Barry W. Software Engineering Economics. Prentice-Hall, 1981

© Greg Phillips, 1998