Waterfall Model is the least complicated, oldest and most commonly used process model. In this model, every phase of the life cycle is finalized prior to the beginning of a fresh phase. It’s actually the 1st engineering approach of software development. The waterfall model offers a organized and step by step way of software development and it’s much better than the build and fix approach. However, in this model, full requirements should be available at the time of beginning of the project, however in real practice, the requirements continue to develop throughout various phases. The water fall model can support the new requirements solely in maintenance phase. Furthermore, it doesn’t include any type of risk assessment. In waterfall model, a functional model of software is unavailable. Hence, there isn’t any strategy to assess the issues of software in between different phases.
Watch a video Waterfall Model and its Phases
In original waterfall model, the following phases are followed in order:
- Requirements specification
- Construction (AKA implementation or coding)
- Testing and debugging (AKA Validation)
Criticism of Waterfall Model
Many debate the waterfall model is actually a poor concept in practice-believing it not possible for any non-trivial project to complete a phase of a software product’s lifecycle flawlessly prior to heading to another phase and gaining knowledge from them. For instance, customers might not know specifically what requirements they want before looking at a functional model and commenting on it. They might alter their demands constantly. Designers and programmers may have minimal control over this. If customers adjust their requirements after the design is finished, the design has to be altered to allow for the latest requirements. This effectively means invalidating a great deal of working hours, meaning elevated cost, particularly when a substantial amount the project’s resources has already been committed to Big Design Up Front.