The Waterfall Model is the classic Software Development model. The model consists of several distinct phases, which proceed in sequence with little to no overlap. It is so named because work flows from one phase to another in a downward fashion, like a waterfall.
The phases, and activities performed during the phases, typically consist of the following.
Phases and Activities of the Waterfall Model of Software Development
| Phase | Activites |
|---|---|
| Requirements | Document all business requirements |
| Design | Design the software architecture and user interface |
| Development | Develop the software per the design and business requirements |
| Testing | Verify that the software meets the design and business requirements |
| Release | Release the software into production |
| Maintenance | Fix bugs, add features, improve performance, etc. |
This model is similar to what is often used in manufacturing and engineering, and works well when the requirements gathered at the beginning of the project do not change (or change very little). The model became popular for software development for a number of reasons, including its structured approach, clear delineation of roles and responsibilities, and suitability to estimation and scheduling. Perhaps most importantly, it forces the development team and the business team to agree on the details and scope of the project before any code is written. This last feature is especially important for development teams that are working on a fixed budget or schedule; changes to the documented and signed-off business requirements would necessarily add cost, time or both to the project.
In practice, however, it is seldom the case that the business and project requirements can be correctly captured in the early phases. Frequently the business requirements or processes will change during the course of the project. When the customer finally has a chance to see and interact with the software, near the end of the development phase, it is very common to find that a business requirement was not correctly or adequately documented. The customer may also find that once they have had a chance to interact with the software, that they become aware of a multitude of changes for improvement. Changes at this stage of the project are very costly because the change must start in the requirements phase and then trickle down to the current phase. The Agile Model of Software Development, by comparison, maintains a tight feedback loop with the customer through frequent releases of working software.