Software Engineering | Failure of Waterfall model
Waterfall model is also known as traditional waterfall software life cycle model. It is very simple to understand and use. In the waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases.
Classical waterfall model divides the life cycle into a set of phases. The waterfall model considers that one phase can be started after completion of the previous phase, which is the output of one phase will be the input to the next phase. Due to this the development process can be considered as a sequential flow in the waterfall. Here the phases do not overlap with each other.
Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the CS Theory Course at a student-friendly price and become industry ready.
This model divides the life cycle of a software development process into the phases as shown in the figure.
Reasons for failure waterfall model:
The traditional waterfall model suffers from various shortcomings, basically we can’t use it in real projects, but we use other software development lifecycle models which are based on the classical waterfall model.
There are some reasons which are given below due to this waterfall model fails.
- One way street:
This model is just like the one-way street. Once phase X is completed and next phase Y has started then there is no way to going back on the previous phase. This is one of the issues to the failure of the waterfall model.
The waterfall model has lacked an overlapping among phase.The waterfall model recommends that new phase can start only after the completion of the previous phase. But in real projects, this can’t be maintained. To increase the efficiency and reduce the cost, phases may overlap.
The waterfall model has lacked interaction among phase. Users have little interaction with project them. This feedback is not taken during development. After a development process starts, changes can not accommodate easily.
- Support delivery of system:
The waterfall model does not support delivery of system in pieces. After a development process starts, changes cannot accommodate easily.
- Feedback path:
The waterfall model has no feedback path. In the traditional waterfall model evolution of software from one phase to another phase is like a waterfall. The waterfall model assumes that no error is ever committed by developers during any phases. Hence, it does not incorporate any mechanism for error correction.
- Not Flexible:
Difficult to accommodate change requests. The waterfall model assumes that all the customer requirements can be completely and correctly defined at the beginning of the project, but actually customers’ requirements keep on changing with time. After the requirements specification phase is completed difficult to accommodate any change requests.