The Waterfall Model

The "waterfall" model is a sequential software development model suggested by W. W. Royce in which development is seen as flowing steadily downwards (like a waterfall) through a number of phases. In most system life cycles based on Royce's original model, the sequence of phases used is similar to that shown in the diagram below.

To follow the waterfall model, you proceed from one phase to the next in a purely sequential manner. You should move to the next phase only when the current phase is complete. The phases of development are discrete, and do not allow for jumping back and forth, or any overlap between the phases, although there are modified versions of the waterfall model that are not so rigid.

The waterfall model is widely used (for example, by those involved in producing software for the US Department of Defense and NASA). The central idea behind the waterfall model is that time spent early on in a project making sure that the requirements and design phases are absolutely correct will save more time and effort later. Requirements should therefore be set in stone before design is started, and the program's design should be perfect before work begins on the implementation phase.

The model places much emphasis on documentation, and proponents of the model claim that its advantages include simplicity and structure. The model progresses in a linear fashion through discrete, logical phases, and is easy to understand. It also provides recognisable "milestones" in the development process. Perhaps for these reasons, it is often used as a first example of a development model in software engineering texts. It is argued that the waterfall model is suited to projects that are stable (i.e. whose requirements are unlikely to change significantly) and where the system designers are able to evaluate potential problems before implementation begins.

Critics of the waterfall model argue that it is impossible, for any non-trivial project, to get one phase of the lifecycle perfected before moving on to the next phase. For example, clients may not be aware of their exact requirements until they see a working prototype, or they may change their requirements constantly, necessitating frequent changes in design. Furthermore, problems encountered during the implementation phase may be better solved by revisiting the design phase than by trying to work around the problems using the original design. The idea behind the waterfall model is "measure twice, cut once". This idea tends to fall apart, however, when what is being measured is constantly changing due to changes in requirements, or the emergence of major unforeseen problems. The counter-argument is that experienced designers may have worked on similar systems already, and can thus anticipate many of the problems that might arise.

Many modified waterfall models have emerged which address some of the criticisms of the original model. Royce's own final model allowed for the results of the testing phase to be fed back into the design phase, and problems from the design stage phase to be fed back into the requirements specification phase. Overlapping the stages makes this kind of feedback possible, but also makes it difficult to determine exactly when a particular phase is complete.