The granddaddy of all lifecycle models is the waterfall model. Although it has many problems, it serves as the basis for other, more effective lifecycle models, so it's presented first in this chapter. In the waterfall model, a project progresses through an orderly sequence of steps from the initial software concept through system testing. The project holds a review at the end of each phase to determine whether it is ready to advance to the next phase—for example, from requirements analysis to architectural design. If the review determines that the project isn't ready to move to the next phase, it stays in the current phase until it is ready.

The waterfall model is document driven, which means that the main work products that are carried from phase to phase are documents. In the pure waterfall model, the phases are also discontinuous—they do not overlap. Figure 7-1 shows how the pure waterfall lifecycle model progresses.

The pure waterfall model performs well for product cycles in which you have a stable product definition and when you're working with well-understood technical methodologies. In such cases, the waterfall model helps you to find errors in the early, low-cost stages of a project. It provides the requirements stability that developers crave. If you're building a well-defined maintenance release of an existing product or porting an existing product to a new platform, a waterfall lifecycle might be the right choice for rapid development.

The pure waterfall model helps to minimize planning overhead because you can do all the planning up front. It doesn't provide tangible results in the form of software until the end of the lifecycle, but, to someone who is familiar with it, the documentation it generates provides meaningful indications of progress throughout the lifecycle.

Figure 7-1. The pure waterfall model. The waterfall model is the most well-known lifecycle model and provides good development speed in some circumstances. Other models, however, often provide greater development speed.

The waterfall model works well for projects that are well understood but complex, because you can benefit from tackling complexity in an orderly way. It works well when quality requirements dominate cost and schedule requirements. Elimination of midstream changes eliminates a huge and common source of potential errors.

The waterfall model works especially well if you have a technically weak staff or an inexperienced staff because it provides the project with a structure that helps to minimize wasted effort.

The disadvantages of the pure waterfall model arise from the difficulty of fully specifying requirements at the beginning of the project, before any design work has been done and before any code has been written.

Developers complain about users who don't know what they want, but suppose the roles were reversed. Imagine trying to specify your car in detail to an automotive engineer. You tell the engineer that you want an engine, body, windows, steering wheel, accelerator pedal, brake pedal, emergency brake, seats, and so on. But can you remember to include everything that an automotive engineer will need to know to build your car?

Suppose you forget to specify that you need back-up lights that turn on when the car goes into reverse. The engineer goes away for 6 months and returns with a car with no back-up lights. You say, "Oh boy, I forgot to specify that the car needs back-up lights that turn on automatically when I shift into reverse."

The engineer goes ballistic. "Do you know what it's going to cost to take the car apart to connect wiring from the transmission to the rear of the car? We have to redesign the rear panel on the car, put in wiring for the brake lights, add another sensor to the transmission—this change will take weeks, if not months! Why didn't you tell me this in the first place?"

You grimace; it seemed like such a simple request…

Understandable mistake, right? A car is a complicated thing for an amateur to specify. A lot of software products are complicated too, and the people who are given the task of specifying software are often not computer experts. They can forget things that seem simple to them until they see the working product. If you're using a waterfall model, forgetting something can be a costly mistake. You don't find out until you get down to system testing that one of the requirements was missing or wrong.

Thus, the first major problem with the waterfall model is that it isn't flexible. You have to fully specify the requirements at the beginning of the project, which may be months or years before you have any working software. This flies in the face of modern business needs, in which the prize often goes to the developers who can implement the most functionality in the latest stage of the project. As Microsoft's Roger Sherman points out, the goal is often not to achieve what you said you would at the beginning of the project, but to achieve the maximum possible within the time and resources available (Sherman 1995).

Some people have criticized the waterfall model for not allowing you to back up to correct your mistakes. That's not quite right. As Figure 7-1 suggests, backing up is allowed, but it's difficult. A different view of the waterfall model that might put the matter into better perspective is the salmon lifecycle model, shown in Figure 7-2.

You're allowed to swim upstream, but the effort might kill you! At the end of architectural design, you participated in several major events that declared you were done with that phase. You held a design review, and you signed the official copy of the architecture document. If you discover a flaw in the architecture during coding and debugging, it's awkward to swim upstream and retrofit the architecture.

Figure 7-2. Another depiction of the waterfall model—the salmon lifecycle model. It isn't impossible to back up using the waterfall model, just difficult.

The waterfall lifecycle model has several other weaknesses. Some tools, methods, and activities span waterfall phases; those activities are difficult to accommodate in the waterfall model's disjoint phases. For a rapid-development project, the waterfall model can prescribe an excessive amount of documentation. If you're trying to retain flexibility, updating the specification can become a full-time job. The waterfall model generates few visible signs of progress until the very end. That can create the perception of slow development—even if it isn't true. Customers like to have tangible assurances that their projects will be delivered on time.

In summary, the venerable pure waterfall model's weaknesses often make it poorly suited for a rapid-development project. Even in the cases in which the pure waterfall model's strengths outweigh its weaknesses, modified waterfall models can work better.