Last Update: July 26th, 2016
The waterfall software development model (a variety of iterative software development, one of the approaches to software or web development project) describes a linear development method that is often considered the classic approach to the software development life cycle. It was first formally described by Dr. Winston W. Royce back in 1970.
This is a sequential model, used to create different kinds of software, where project development is seen as flowing steadily downwards (like a waterfall) through the phases of software development requirements analysis, UI design, software implementation, project verification, and software maintenance.
The process itself can be divided into different phases, depending on the IT project or other web development requirements.
The main idea of the waterfall model is that software development proceeds from one phase to the next step in a purely sequential manner or way. For example, the wed development team first completes requirements and when all the desired requirements are fully completed, reviewed and approved, the IT team proceeds to GIU design phase.
So, the waterfall model means that the programming team should move to a next following step only when previous phase is completed and everything is approved. However in some model modifications some slight or major variations and even changes may be included.
The most important advantage of the waterfall idea is that it allows for departmentalization and managerial control. In the common practice a schedule with deadlines for each phase of project development is made and a product can proceed through the process of developing under the created schedule.
The next argument for the waterfall software development model is that it puts solid requirements on the project documentation (design documents and requirements specs) as well as the source code. And if any of team members left the project less knowledge would be lost in comparison to a project with less designed and documented methodologies.
Waterfall development model implies that a fully working design document should be present, so that a new team member or even the entire new team will easily familiarize themselves with a project by reading the documents.
In common practice waterfall methodologies result in a project schedule with 20-40% of the time invested for the first two phases, 30-40% of the time to coding, and the rest dedicated to testing and implementation. The actual project organization needs to be highly structured. Most medium and large projects will include a detailed set of procedures and controls, which regulate every process on the project.
In theory, such process leads to the project being delivered on time because of detailed plan for each phase created previously.
However, in practice it’s often impossible to follow the pure waterfall model, because it does not consider the inevitable changes and revisions that become necessary in the development process. Also, many specialists argue on the waterfall model as a bad idea in practice, generally because of the inability to perfect one stage of a software product, before moving to another stage and learning something new from them for any non-trivial project.
For example, customers may not be sure of what requirements exactly they want before they see a working prototype and can comment upon it; they may change their requirements constantly after seeing a result of development, and program designers and implementers may have little or no control over this. If customers change their requirements after a design document is finished, then the document must be modified to correspond to the new requirements.
Also, project designers may not be aware of future implementation or development difficulties when writing a design for an unimplemented software product. For example, it may become clear on the implementation phase that a particular area of product functionality is extraordinarily difficult to implement.
In this situation, it is better to revise and change the design document rather to persist in using a conception, that was made based on incorrect predictions and that does not consider the newly discovered problem areas. This is one of the reasons, why the waterfall model isn’t commonly used in agile software development.
See our article on agile software development ecosystems to learn more about software development methodologies!
The most significant weakpoint of the waterfall software development model is the possibility that a poor or wrong design choice will not be discovered until the final stages of implementating or testing.
The risk of this happening will increase as the project duration and size go up. Even competent people make simple mistakes and considering the solid waterfall timetable, mistakes made in the design or requirements documents may not be discovered until half of a year of programming have been completed and the system is being tested.
From our point of view the waterfall model in its pure form can be successfully used either on small projects or on trivial projects, where all requirements are known before the project starts and they won’t change over the time.
For example, in mobile games development industry all requirements are usually developed and perfected before the project starts, what allows the development team to work on the pure waterfall model. However if there is even a miserable chance that the project is non-trivial or there are non-completed requirements the waterfall model won’t be the best one to work on.