Waterfall model: advantages and limitations

The waterfall model is the classical linear sequential life cycle model in which the fundamental activities are carried out as separate phases, one after another, like water falling down steps. The output of each phase (a signed-off document) is the input to the next.

 Requirements analysis and definition
        |
        v
 System and software design
        |
        v
 Implementation and unit testing
        |
        v
 Integration and system testing
        |
        v
 Operation and maintenance

Advantages

• Simple and easy to understand; easy for beginners and managers.
• Clear phases and milestones, so planning, scheduling and progress tracking are easy.
• Good documentation is produced at every phase; useful for maintenance and new staff.
• Works well when requirements are well understood and stable.
• Fits fixed-price contracts and organisations that need formal sign-offs.
• Discipline: design is done before coding, testing has a defined place.
• Suitable for large systems engineering projects where software is part of a bigger system built at several sites.

Various software development models

1. Waterfall (linear sequential) model
2. V-model
3. Incremental model
4. Prototyping model (throwaway and evolutionary)
5. Evolutionary development
6. Spiral model
7. RAD (Rapid Application Development) model
8. Component-based software engineering (reuse-oriented) model
9. Rational Unified Process (RUP)
10. Agile models (Extreme Programming, Scrum)
11. Formal methods (cleanroom) model

Limitations of the waterfall model in detail

1. Requirements must be fixed at the start. Customers rarely know all requirements at the beginning, and the model has no natural way to handle the uncertainty that exists at the start of most projects.

2. Difficult to accommodate change. Once a phase is signed off, going back is costly. A requirement change late in the project may require redoing design, code and tests. In practice, problems are often "frozen" or worked around in the code, giving a badly structured system.

3. Working software appears late. The customer sees a working version only near the end. If there is a misunderstanding in requirements, it is discovered very late, when correction is most expensive.

4. Late testing; high risk. Testing comes after all coding, so design faults and integration problems appear at the end of the project. There is no explicit risk analysis.

5. Inflexible partitioning into stages. Real projects do not follow a strict sequence; activities overlap and feed back into each other. Forcing a strict sequence does not reflect reality.

6. Blocking states. Some team members must wait for others to finish the previous phase (for example, testers wait for coding), wasting time.

7. Little customer involvement after requirements, so the delivered system may not match what users actually need, causing low acceptance.

8. Not suitable for long, complex, object-oriented or high-risk projects, or for projects where requirements are likely to change (such as new web or mobile products).

9. Heavy documentation effort, which can be slow and costly for small projects.

Example: a university decides to build an online admission system using waterfall. Requirements are frozen in month 1. In month 6, during testing, the university changes its admission rules and wants online payment added. Because design and code are already complete, these changes need major rework, and the deadline for admissions is missed.

For these reasons, waterfall is used mainly when requirements are well understood and unlikely to change; otherwise iterative models such as incremental, spiral or agile are preferred.