Waterfall
Table of Contents
Introduction
The Waterfall approach takes the seven phases of SDLC (see chapter 2) and moves through them sequentially, one phase at a time.
Waterfall is not iterative. Teams should not go back to a phase they have already completed.
This is where the waterfall image comes from, it requires team flow through each phase without going back up.
Elakala Waterfall 1 - Licensed under CC BY-SA 3.0 US. Attribution: http://www.ForestWander.com
The waterfall approach has its roots in the engineering and construction industries. It has proved to be an effective way of completing large physical infrastructure projects.
Waterfall strengths
Waterfall's strengths are derived from its roots in construction and engineering:
- Time spent in early phases (planning) saves time and money later
- It emphasises documentation - knowledge is not in someone’s head
- Structured approach
- Clear milestones (each phase is a milestone)
- The client has clear expectations (size, cost, timeline, etc…)
Waterfall weaknesses
Waterfall's weaknesses come from its non-iterative approach to designing software (the fact you can't go back to revise work completed in an earlier phase).
- Requirements aren’t always clear at the beginning of a project, so very hard to define in early phases
- Requirements can change based on designs or even final product. Waterfall does not allow for this
- It is difficult to anticipate technical issues
Therefore, waterfall is inflexible (it is not good at responding to change). Possible sources of change:
- New tools / technologies
- Customers
- Competitors