The waterfall model is the process of performing the typical software development life cycle (SDLC) phases in sequential order. Each phase is completed before the next is started, and the result of each phase drives subsequent phases. Compared to alternative SDLC methodologies such as Agile, it is among the least iterative and flexible, as progress flows largely in one direction (like a waterfall) through the phases of conception, requirements analysis, design, construction, testing, deployment, and maintenance. The waterfall model is the earliest SDLC methodology. When first adopted, there were no recognized alternatives for knowledge-based creative work.
History 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. This presentation was about the development of software for SAGE. In 1983, Benington republished his paper with a foreword explaining that the phases were on purpose organised 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. Although the term "waterfall" is not used in the paper, the first formal, detailed diagram of the process is often cited as coming from a 1970 article by Winston W. Royce. 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". The rest of his paper introduced five steps which he felt were necessary to "eliminate most of the development risks" associated with the unaltered waterfall approach. 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. The earliest use of the term "waterfall" may have been in a 1976 paper by Bell and Thayer. In 1985, the United States Department of Defense adopted the waterfall model in the DOD-STD-2167 standard for working with software development contractors. This standard referred for iterations of a software development to "the sequential phases of a software development cycle" and stated that "the contractor shall implement a software development cycle that includes the following six phases: Software Requirement Analysis, Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing".
Phases The model describes a linear sequence of steps. Although various different versions can be found, the following describes the essence.
Preliminary analysis Conduct a preliminary analysis, consider alternative solutions, estimate costs and benefits, and submit a preliminary plan with recommendations.
Conduct preliminary analysis: Identify the organization's objectives and define the nature and scope of the project. Ensure that the project fits with the objectives. Consider alternative solutions: Alternatives may come from interviewing employees, clients, suppliers, and consultants, as well as competitive analysis. Cost-benefit analysis: Analyze the costs and benefits of the project.
Systems analysis, requirements definition Decompose project goals into defined functions and operations. This involves gathering and interpreting facts, diagnosing problems, and recommending changes. Analyze end-user information needs and resolve inconsistencies and incompleteness:
Collect facts: Obtain end-user requirements by document review, client interviews, observation, and questionnaires. Scrutinize existing system(s): Identify pros and cons. Analyze the proposed system: Find solutions to issues and prepare specifications, incorporating appropriate user proposals.
Systems design At this step, desired features and operations are detailed, including screen layouts, business rules, process diagrams, pseudocode, and other deliverables.
Development Write the code.
Integration and testing Assemble the modules in a testing environment. Check for errors, bugs, and interoperability.
Acceptance, installation, deployment Put the system into production. This may involve training users, deploying hardware, and loading information from the prior system.
Maintenance Monitor the system to assess its ongoing fitness. Make modest changes and fixes as needed. This helps maintain the quality of the system. Continual monitoring and updates ensure the system remains effective and high-quality.
Evaluation The system and the process are reviewed. Relevant questions include whether the newly implemented system meets requirements and achieves project goals, whether the system is usable, reliable/available, properly scaled and fault-tolerant. Process checks include review of timelines and expenses, as well as user acceptance.
Disposal At end of life, plans are developed for discontinuing the system and transitioning to its replacement. Related information and infrastructure must be repurposed, archived, discarded, or destroyed, while appropriately protecting security.
… excerpt ends here. Continue reading the full article.
