Waterfall Model

The common metaphor of building a house is often used to describe the traditional approach to application development. The builder first gathers information from the customer about his or her needs and desires, determines what needs to be built, designs the structure, and constructs it from the plans. The builder must ensure that the building holds together and that all the components, from the electricity and plumbing to the doorbell, are fully functional. The customer then tests everything to ensure that all elements meet expectations. Even after the customer moves into the new home, the builder must occasionally come back to fix minor problems.

The stages of building a house are similar to the stages of the Waterfall Model of application development. As shown in Figure 4.1, the tightly defined Waterfall Model is an orderly, highly structured process based on the following well-defined development steps:

• Gathering system and software requirements
• Analysis
• Program design
• Coding and unit testing
• System integration
• System testing
• Operation acceptance

Each step is completed and thoroughly documented before the next step can begin.

Figure 4.1 Waterfall Model

Strict use of the Waterfall Model is declining. Following this model causes several problems throughout the product life cycle, which are summarized below.

• Extra time Typically more time than was initially scheduled is needed to integrate subsystems into a complete, working application.
• Late design changes Design flaws that require significant changes to the product are discovered late in the software coding process. Rarely is tangible design validation performed in the project's early stages.
• Inadequate risk resolution The project's risks are not resolved until late in the product life cycle.
• Lack of requirement revisions The project's requirements must be stated and frozen at the first stages of the development process. Often, the project's stakeholders don't completely understand the business and product requirements at the beginning of project. With most software projects, requirements are clarified and changed throughout the project, which dramatically increases product cost and delays ship times. If the changes are not integrated into the product, the stakeholders don't think the product they receive is the one they requested.
• Limited opportunities for input The traditional practice allows a single review process to finalize each project stage. This single opportunity to voice concerns and suggest changes produces an over-sensitized focus on details that can lead to adversarial relationships between project stakeholders.
• Lack of review The first four stages of the Waterfall Model are paper-based exercises, and to prove that the project is progressing, reams of paper may be produced as each stage is completed. As volumes of system documentation are presented, the most understood portions are often the ones that are reviewed, while the more complex portions are simply assumed to be correct.