The "classic" waterfall model, despite recent bad press, has served the software engineering community well for many years. Understanding its strengths and flaws improves the ability to assess other, often more effective life cycle models that are based on the original.
In the earliest days of software development, code was written and then debugged. It was common to forego planning altogether and, starting with a general idea of the product, informally design, code, debug, and test until the software was ready for release. The process looked something like the one in Figure 4-8. There are several things "wrong" with such a process (or lack thereof). Primarily, because there was no formal design or analysis, it is impossible to know when you are done. There is no way to assess whether the requirements or the quality criteria have been satisfied.
Figure 4-8. "Do Until Done" Process Model
Figure 4-8. "Do Until Done" Process Model
The waterfall model was first identified in 1970 as a formal alternative to the code-and-fix software development method prevalent at the time. It was the first to formalize a framework for software development phases, placing emphasis on up-front requirements and design activities and on producing documentation during early phases.
Execution of the waterfall model begins at the upper left of Figure 4-9 and progresses through the orderly sequence of steps. It assumes that each subsequent phase will begin when activities in the current phase have been completed. Each phase has defined entry and exit criteria: inputs and outputs. Internal or external project deliverables are output from each phase, including documentation and software. Requirements analysis documents are passed to system engineers, who hand off high-level design documents to software architects, who hand off detailed specifications to coders, who hand off code to testers.
Figure 4-9. Classic Waterfall Model with Feedback
Transition from one phase to the next is accomplished by passing a formal review, a way to provide customers insight into the development process and to check on product quality. Typically, passing the review indicates an agreement among the project team members and the customer that the phase has ended and the next one can begin. The end of a phase is a convenient place for a project milestone.
In conjunction with certain phase completions, a baseline is established that "freezes" the products of the development at that point. If a need is identified to change these products, a formal change process is followed to make the change.
At critical points on the waterfall model, baselines are established, the last of which is the product baseline. This final baseline is accompanied by an acceptance review.
Other software development life cycles have evolved from attempts to optimize the waterfall model. Software prototyping helps provide the complete understanding of the requirements; the incremental and spiral models allow the phases identified in the classic waterfall to be revisited repeatedly before declaring a product to be final.
The salient attributes of the waterfall model are that it is a formal method, a type of top-down development, composed of independent phases executed sequentially and subject to frequent review.
A Brief Description of the Phases in the Waterfall Model
The following is a brief description of each phase of the waterfall model, from concept exploration through retirement, including the integration phases:
® Concept exploration— Examines requirements at the system level, to determine feasibility.
® System allocation process— May be skipped for software-only systems. For systems that require the development of both hardware and software, the required functions are mapped to software or hardware based on the overall system architecture.
® Requirements process— Defines software requirements for the system's information domain, function, behavior, performance, and interfaces. (Where appropriate, this includes the functional allocation of system requirements to hardware and software.)
® Design process— Develops and represents a coherent, technical specification of the software system, including data structures, software architecture, interface representations, and procedural (algorithmic) detail.
® Implementation process— Results in the transformation of the software design description to a software product. Produces the source code, database, and documentation constituting the physical transformation of the design. If the software product is a purchased application package, the major activities of implementation are the installation and testing of the software package. If the software product is custom developed, the major activities are programming and testing code.
® Installation process— Involves software being installed, checked out, and formally accepted by the customer, for the operational environment.
® Operation and support process— Involves user operation of the system and ongoing support, including providing technical assistance, consulting with the user, recording user requests for enhancements and changes, and handling corrections or errors.
® Maintenance process— Concerned with the resolution of software errors, faults, failures, enhancements, and changes generated by the support process. Consists of iterations of development, and supports feedback of anomaly information.
® Retirement process— Removing an existing system from its active use, by either ceasing its operation or replacing it with a new system or an upgraded version of the existing system.
® Integral tasks— Involves project initiation, project monitoring and control, quality management, verification and validation, configuration management, document development, and training throughout the entire life cycle.
Strengths of the Waterfall Model
We can see that the waterfall model has many strengths when applied to a project for which it is well suited. Some of these strengths are:
• The model is well known by nonsoftware customers and end-users (it is often used by other organizations to track nonsoftware projects).
• It tackles complexity in an orderly way, working well for projects that are well understood but still complex.
• It is easy to understand, with a simple goal—to complete required activities.
• It is easy to use as development proceeds one phase after another.
• It provides structure to a technically weak or inexperienced staff.
• It provides requirements stability.
• It provides a template into which methods for analysis, design, code, test, and support can be placed.
• It works well when quality requirements dominate cost and schedule requirements.
• It allows for tight control by project management.
• When correctly applied, defects may be found early, when they are relatively inexpensive to fix.
• It is easy for the project manager to plan and staff.
• It allows staff who have completed their phase activities to be freed up for other projects.
• It defines quality control procedures. Each deliverable is reviewed as it is completed. The team uses procedure to determine the quality of the system.
• Its milestones are well understood.
• It is easy to track the progress of the project using a timeline or Gantt chart—the completion of each phase is used as a milestone.
Weaknesses of the Waterfall Model
We can also note weakness of the model when it is applied to a project for which it is not well suited:
® It has an inherently linear sequential nature—any attempt to go back two or more phases to correct a problem or deficiency results in major increases in cost and schedule.
® It does not handle the reality of iterations among phases that are so common in software development because it is modeled after a conventional hardware engineering cycle.
® It doesn't reflect the problem-solving nature of software development. Phases are tied rigidly to activities, not how people or teams really work.
® It can present a false impression of status and progress—"35 percent done" is a meaningless metric for the project manager.
® Integration happens in one big bang at the end. Wth a single pass through the process, integration problems usually surface too late. Previously undetected errors or design deficiencies will emerge, adding risk with little time to recover.
® There is insufficient opportunity for a customer to preview the system until very late in the life cycle. There are no tangible interim deliverables for the customer; user responses cannot be fed back to developers. Because a completed product is not available until the end of the process, the user is involved only in the beginning, while gathering requirements, and at the end, during acceptance testing.
® Users can't see quality until the end. They can't appreciate quality if the finished product can't be seen.
® It isn't possible for the user to get used to the system gradually. All training must occur at the end of the life cycle, when the software is running.
® It is possible for a project to go through the disciplined waterfall process, meet written requirements, but still not be operational.
® Each phase is a prerequisite for succeeding activities, making this method a risky choice for unprecedented systems because it inhibits flexibility.
® Deliverables are created for each phase and are considered frozen—that is, they should not be changed later in the life cycle of the product. If the deliverable of a phase changes, which often happens, the project will suffer schedule problems because the model did not accommodate, nor was the plan based on managing a change later in the cycle.
® All requirements must be known at the beginning of the life cycle, yet customers can rarely state all explicit requirements at that time. The model is not equipped to handle dynamic changes in requirements over the life cycle, as deliverables are "frozen." The model can be very costly to use if requirements are not well known or are dynamically changing during the course of the life cycle.
® Tight management and control is needed because there is no provision for revising the requirements. ® It is document-driven, and the amount of documentation can be excessive.
® The entire software product is being worked on at one time. There is no way to partition the system for delivery of pieces of the system. Budget problems can occur because of commitments to develop an entire system at one time. Large sums of money are allocated, with little flexibility to reallocate the funds without destroying the project in the process.
® There is no way to account for behind-the-scenes rework and iterations.
Because of its weaknesses, application of the waterfall model should be limited to situations in which the requirements and the implementation of those requirements are very well understood.
The waterfall model performs well for product cycles with a stable product definition and well-understood technical methodologies.
If a company has experience in building a certain genre of system—accounting, payroll, controllers, compilers, manufacturing—then a project to build another of the same type of product, perhaps even based on existing designs, could make efficient use of the waterfall model. Another example of appropriate use is the creation and release of a new version of an existing product, if the changes are well defined and controlled. Porting an existing product to a new platform is often cited as an ideal project for use of the waterfall.
In all fairness, critics of this model must admit that the modified version of the waterfall is far less rigid than the original, including iterations of phases, concurrent phases, and change management. Reverse arrows allow for iterations of activities within phases. To reflect concurrence among phases, the rectangles are often stacked or the activities within the phases are listed beneath the rectangles showing the concurrence. Although the modified waterfall is much more flexible than the classic, it is still not the best choice for rapid development projects.
Waterfall models have historically been used on large projects with multiple teams and team members.
Was this article helpful?