Waterfall model

In software development,[1] it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction (downwards like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment, and maintenance.

[4] The first known presentation describing the use of such phases in software engineering was held by Herbert D. Benington at the Symposium on Advanced Programming Methods for Digital Computers on 29 June 1956.

In 1983, Benington republished his paper with a foreword explaining that the phases were on purpose organized according to the specialization of tasks, and pointing out that the process was not in fact performed in a strict top-down fashion, but depended on a prototype.

[8][9][10] However, he commented that it had major flaws stemming from how testing only happened at the end of the process, which he described as being "risky and [inviting] failure".

[8] Royce's five additional steps (which included writing complete documentation at various stages of development) never took mainstream hold, but his diagram of what he considered a flawed process became the starting point when describing a "waterfall" approach.

[13][better source needed] In 1985, the United States Department of Defense adopted the waterfall model in the DOD-STD-2167 standard for working with software development contractors.

Simulations allow for testing and refining the design, identifying potential issues or bottlenecks, and making informed decisions about the system's functionality and performance.

[citation needed] In the same paper Royce also advocated large quantities of documentation, doing the job "twice if possible" (a sentiment similar to that of Fred Brooks, famous for writing the Mythical Man Month — an influential book in software project management — who advocated planning to "throw one away"), and involving the customer as much as possible (a sentiment similar to that of extreme programming).