The waterfall model is a sequential design process model which was developed for software development; that is to create software. It is called as such because the model develops systematically from one phase to other in a downward fashion (sometimes with some overlap) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance, like a waterfall.Tight control with time schedules is maintained over the life of the project through the use of extensive written documentation. This is sometimes called as traditional or conventional software development methodology as well.
1. Progress is easy to track with formal reviews.
2. Easy to understand.
3. Easy to use because of systematic flowing.
4. Ideal for supporting less experienced project teams.
5. The orderly sequence of development steps and strict controls for ensuring the adequacy of documentation and design reviews helps ensure the quality.
6. Conserves resources.
7. Supports less experienced project managers.
8. Reliable since systematic way of completing each phase.
1. It has a rigid design and inflexible procedure.
2. It has a top-down procedure.
3. One phase must be completed before the next phase starts.
4. Time consuming since whether it’s correct or not earlier phase must be completed in order to jump in to next phase.
5. Real projects rarely follow the sequential flow that the model proposes.
6. Does not accommodate natural uncertainty very well.
7. Impossible to integrate feedback from one phase to another.
8. No phase can be repeated.
9. Project progresses forward, with only slight movement backward.
10. Little room for use of iteration.
11. Depends upon early identification and specification of requirements, yet users may not be able to clearly define what they need early in the project.
12. Requirements inconsistencies, missing system components.
13. Problems are often not discovered until system testing.
14. System performance cannot be tested until the system is almost fully coded.
15. Difficult to respond to changes.
16. Written specifications are often difficult for users to read and thoroughly appreciate.
17. Promotes the gap between users and developers with clear division of responsibility.
18. Cost of change increases with the time.
19. We don’t realize any value until the end of the project.
20. Carries risk.
22. Unexpected development needs can arise.
Situations where most appropriate
1. If the requirements are very clear.
2. Project is for development of a mainframe-based system.
3. Project is large with a complete requirement specification document.
4. Project has clear objectives.
5. Pressure does not exist for immediate implementation.
6. User community is fully knowledgeable in the business.
7. Team members may be inexperienced.
8. Team composition is unstable.
9. Project manager may not be fully experienced.
10. Resources need to be conserved.
11. When developing a transaction-oriented batch system.
12. Expensive projects.
13. Has a clear solution.
14. When we have comprehensive requirements.
Situations where least appropriate
1. Uncertainty about requirements and goals.
2. Web Information Systems primarily due to the pressure of implementing a WIS project quickly.
3. Real-time systems because requirements change rapidly in those.
4. Event-driven systems.
5. Leading-edge applications.
Reference : SELECTING A DEVELOPMENT APPROACH. (2005). 3rd ed. [ebook] Centers for Medicare and Medicaid Services, pp.1-10. Available at: https://www.cms.gov/Research- Statistics-Data- and-Systems/CMS- Information-Technology/XLC/Downloads/SelectingDevelopmentApproach.pdf [Accessed 6 Feb. 2017].