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.
The incremental model allows different parts of the system to be developed separately, each with its own life cycle iteration. Each iteration includes a requirements analysis, design, implementation and testing phase. The first iteration usually produces a working version of the system on which subsequent iterations build. The incremental model provides a more flexible and less costly alternative to the waterfall model in which changes to the scope or requirements of the project can be more easily accomodated. Each iteration can be completed relatively quickly, and is easier to manage. Like the waterfall model, however, each phase of each iteration must be completed before the next phase can commence, and the overall system architecture may be poorly defined in the early stages of the project.
Like the waterfall model, each phase of the V-Shaped life cycle must be completed before the next phase begins. In this model, however, there is much more emphasis on testing. Test procedures are developed early in the life cycle. System testing is designed to assess whether the requirements determined during the requirements analysis phase have been met. Integration testing is developed during the high-level design phase, which focuses on the overall system architecture, and unit testing is planned to assess the success of the low-level design phase, which concentrates on individual system components. Life cycle execution proceeds down the left-hand side of the V, and at the same time the test plan for each phase is developed. Once the implementation phase has been completed, execution proceeds up the right hand side of the V, and the test plan for each phase is completed in turn.
Like the waterfall model, the V-shaped model is easily understood and has well defined phases with specific deliverables. The chances of success are probably higher than for the waterfall model due to the development of test plans early in the cycle, especially where projects are relatively small and the requirements are well understood. This model lacks the flexibility of the incremental model however, with no intermediate prototypes produced. The model does not specify what course of action should be taken if significant problems emerge during the testing phases.
The spiral model is similar in many ways to the incremental model, with more emphasis on risk analysis. The project passes repeatedly through the four phases of planning, risk analysis, development and evaluation. System requirements are gathered during the planning phase and alternative solutions are generated. The risk analysis phase identifies the risk associated with each alternative solution (for example, the likelihood of a cost overrun or prohibitive operating costs). The development phase results in a prototype, which is then thoroughly evaluated in the evaluation stage before the next iteration of the spiral is undertaken. The cycle continues its iterations until the evaluation phase determines that the system requirements have been met in full (or until an unacceptable level of risk forces the project to be terminated).
The cost of the project increases as the spiral goes through successive iterations. The high degree of risk analysis and the production of a prototype system early in the life cycle makes this a good option for large and complex projects, although it can be potentially costly, and the level of expertise required for the critical risk analysis phase means that it is not really suited to smaller projects.
This article is an aggregation of two articles on the subject of life cycle models first published on the TechnologyUK.net website in January 2009.