da paper

Waterfall (Traditional)

  • sequential design process, rigid and linear
  • progress is seen as flowing steadily downwards
  • phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance.
  • Royce's phases: requirements, analysis, design, coding, testing, operations
  • one should move to a phase only when its preceding phase is reviewed and verified, and there is no turning back
  • places emphasis on documentation (such as requirements documents and design documents)
  • inflexible and costly (a bug found in later phases of development costs more)


  • It is argued that the waterfall model can be suited to projects where requirements and scope are fixed, the product itself is firm and stable, and the technology is clearly understood.[12]
  • Project requirements can be stated unambiguously and comprehensively.
  • Team members are inexperienced.
When not:

  • When requirements changes frequently
  • When there's a need for immediate implementation

  • The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce,[3][4]

  • The earliest use of the term "waterfall" may have been a 1976 paper by Bell and Thayer.[6]

Incremental (and Iterative?)

  • The product is decomposed into a number of components, each of which is designed and built separately (termed as builds)
  • Each component is delivered to the client when it is complete.
  • applies the waterfall model incrementally.[1]
  • The series of releases is referred to as “increments”
  • After the first increment, a core product is delivered, which can already be used by the customer.
  • Based on customer feedback, a plan is developed for the next increments, and modifications are made accordingly.
  • Customer can respond to features and review the product for any needful changes.
  • As additional functionality is added to the product, problems may arise related to system architecture which were not evident in earlier prototypes.
  • allows developers to take advantage of what was learned during development of earlier parts or versions of the system
  • A series of mini-Waterfall are performed, where all phases of the Waterfall development model are completed for a small part of the system, before proceeding to the next increment
  • Stakeholders can be given concrete evidence of project status throughout the life cycle.
  • το σκέτο incremental έχεις κοινές αδυναμ ίες με το μοντέλο του καταρράκτη: θα πρέπει οι απαιτήσεις και η αρχιτεκτονική να είναι σχετικά σταθερές και να μην υπόκεινται σε συνεχείς αλλαγές

  • Large projects where requirements are not well understood or are changing due to external changes, changing expectations, budget changes or rapidly changing technology.

When not:
  • Very small projects of very short duration.