Waterfall Model
The waterfall model is a software development model describing a naive approach to software development in which development is seen as flowing strictly linearly through the phases of requirements analysis, design, implementation, testing, and maintenance.
The term was first introduced in 1970 by W. W. Royce. Many are unaware that in the original article, Royce advocated using the steady flow repeatedly, in an iterative way. The term has thus instead come to be used as the name for the methodology of following a straightforward single flow - an approach which has been discredited for use as a real world process. In real software development methodologies, the flow very seldom proceeds in a purely linear fashion. Iterations, by going back to or adapting results of the precedent stage, are common. Despite the fact that the waterfall model has never been advocated by software development methodologists it is seen to emerge naturally in companies lacking expertise and experience in software development methodologies.
A straight application of the waterfall model requires that all software requirements are established before design begins, then all the design is done before any coding starts. Once the design is completely finished, coding starts until completion. Then all testing is performed before the application is delivered. The Waterfall Model is document driven. Each step of the process yields artifacts that are documents. For example, when Requirements Analysis has been completed, there is a Requirements Document created. Before coding starts, there must be a set of Design Documents. Documents produced during one step are needed for the next step and possibly for later steps. For example, the Requirements Document is needed for design, the next step. Later, the Requirements Document is needed to ensure that the developed product meets the requirements during Acceptance Testing.
Managers like the waterfall model because progress is observable and measurable. The transitions between steps become project milestones that indicate progress made. Documents are apparently tangible evidence of progress. However, note that the belief that we can monitor progress in this simple-minded way is an illusion. This is one of the weaknesses of the waterfall model. It has repeatedly proven to be very easy to produce very impressive documents that eventually prove to be incomplete, inconsistent, hard to consult, or otherwise worthless.
Due to the widespread changing nature of all artifacts produced in software development projects, the waterfall model is impractical. For example, requirements are extremely likely to change at any stage of development of the project. Experience has demonstrated that the coding phase is a steady source of requirements changes (as the software parts are being developed and partially used, unforeseen requirements emerge). Using the waterfall model, any change in requirements requires the updating and re-verification off the whole set of requirements.
A factor that aggravates this problem is that, in the waterfall model, there is an important accumulation of unstable information at each phase. For example, requirements are unstable because they cannot easily be verified by the users without a real-life demonstration of the application. Applying change in a complex system always involve a ripple effect of changes. For example, applying change to a function or class is likely to itself require changes in the neighbouring functions or classes and so on. Similarly, a change in one requirement, or the addition of a new requirement, is likely to affect other related requirements.
Another kind of ripple effect can be seen as a "downstream wave" of change. As all phases are linearly connected, changes "upstream" are inevitably inducing changes "downstream", e.g. a change in requirements is very likely to require changes in design, which have to be reflected in the existing code, and as code is changed, so do test cases have to be redesigned, added or otherwise changed. So the more "upstream" the change happens, the more important is the effect of the "downstream wave".
The name “waterfall model” suggests that there is no going back: once a phase is completed, the documentation for that phase must not be altered. An early modification to the original waterfall model was to allow feedback between consecutive steps. For example, during coding, you could modify the program design but not the system design. But even allowing retroactive changes to existing artifacts does not solve the main problem of accumulation of information. When going back, changes have to be applied on very large and complex documents, which is in most cases a complex and costly operation. The waterfall is not a good model in most cases. However, this model is a very good generic representation of all the phases to undertake to develop good software. All the phases presented in the waterfall model are present in one form or another in all other models. The waterfall model was the first attempt to describe a process for software development.
Perceived advantages of the waterfall model
- Good progress tracking due to clear development stages.
- Milestones and deliverables can be clearly identified.
- Project Management and control is facilitated by the need to complete each stage before moving to the next.
- However, note that these advantages are often an illusion, and falling into these illusions often result in eventual catastrophe.
Real world disadvantages
- Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.
- The lifecycle can take so long that the original requirements may no longer be valid by the time the system is implemented.
- Estimating time and costs is difficult for each stage.
- Lack of resource management flexibility: each phase requires a large number of specialists (e.g. requirements, design, coding specialists), that are dismissed at the end of each phase.
- Too much unstable information is accumulated at each stage. Further change requests will be difficult to apply.
- Valuable feedback is concentrated at the end, when the application is tested and delivered.
