Software Engineering

  • Plan vs course change

  • The waterfall model is often considered out of date

  • Not an inflexible process but often created an inflexible instance (process vs people)

  • Planning allows for more oversight and control

When to use:

  • Requirements very well documented, clear and fixed

  • Product definition is stable

  • Technology is understood and is not dynamic

  • There are no ambiguous requirements

  • Ample resources with required expertise are available to support the product

  • The product is short


  • Simple and easy to understand and use

  • Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process

  • Phases are processed and completed one at a time

  • Works well for smaller projects where requirements are very well understood

  • Clearly defined stages

  • Well understood milestones

  • Easy to arrange tasks

  • Process and results are well documented

  • Iteration occurs within activities


  • No working software is produced until late during the life cycle

  • High amounts of risk and uncertainty

  • Not a good model for complex and object-oriented project

  • Poor model for long and ongoing projects

  • Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and uncertainty is high with this process model

  • It is difficult to measure progress within stages

  • Can’t accommodate changing requirements

  • Adjusting scope during the life cycle can end a project

  • Integration is done as a “big-bang” at the very end, which doesn’t allow identifying any technological or business bottleneck or challenges early