Waterfall model: Application

- [Narrator] When Waterfall projects started failing, many organizations treated this failure as if this was a failure in a production factory. So, they tried to fix their waterfall approaches by adding more comprehensive documentation. Having a well-documented software system is good, but documentation by itself adds no value to the stakeholders. Also, many software teams resorted to maintaining comprehensive checklists to make sure they were producing systems of high quality. Checklists, such as coding standards, and architectural reviews are helpful, but you cannot produce a single recipe book for building software. So more time should be spent on delivering working software features early and often, and eliciting customer feedback. Are there situations where the waterfall approach may be applicable? Waterfall may still work fine for very simple and small systems. Enhancements to software systems in an ongoing maintenance phase might work with the waterfall model. This is specifically applicable if the development team has good domain knowledge, and both business and technical stakeholders are good at working with each other. The waterfall approach may be applicable to mission-critical systems, where you need gated checks to avoid catastrophic failures. An example is a software system where a defect can cause human casualty. Comprehensive documentation is also very applicable here.