Waterfall model
The Waterfall model is a structured process primarily used in software development, characterized by a sequential flow through clearly defined phases. Typically, it encompasses six main steps: determining requirements, designing the system, implementing the product, testing, deploying, and maintaining the software. This model emphasizes completing each phase in order before moving on to the next, which aims to streamline the development process and prevent unnecessary revisions that can arise from incomplete planning.
Originating in the mid-twentieth century, the Waterfall model was introduced to create a more organized approach to software engineering, though it has been criticized for its rigidity. Unlike more flexible methodologies, such as Agile, which allow for iterative feedback and adjustments throughout development, the Waterfall model requires adherence to a linear progression.
While proponents appreciate its focus and clarity, critics argue that its strict structure can hinder adaptability, particularly in a fast-evolving technological landscape where user needs and requirements may shift during development. Overall, the Waterfall model is a foundational concept in software engineering, providing a framework that, despite its limitations, remains influential in guiding product development.
On this Page
Waterfall model
The waterfall model, also known as the waterfall approach, is a type of process used to conceive, develop, and create a product. While the process can apply to many different projects, the term is rarely used outside of software development. The approach consists of a series of phases, intended to help focus developers. The division into phases helps prevent developers from spending time and effort on one part of the project that could be rendered obsolete based on decisions about another part of it.
While there are different variations of the approach, the most common version has six steps in its process: determining requirements, designing a system's framework, implementing the product, testing it, deploying or releasing it to the public, and maintaining and adjusting it after release. The waterfall name refers to the nature of the process. The phases are usually arranged vertically, and the process encourages developers to only move on to the next phase once the current one is complete.
Background
Since the mid-twentieth century, rapid advances in technology have pushed engineers to design new computer software quickly and efficiently, while ensuring that the product clearly improves on its predecessors. To help focus development, engineers created processes that helped guide production through different phases.
In 1956, Herbert Benington discussed multiphase development cycles to create software. Winston Royce wrote an article that outlined the waterfall model in 1970. The actual term waterfallwas applied later. Royce referred to the model unfavorably, saying it was ineffective for software development.
The waterfall model is often contrasted—usually unfavorably—with other approaches, particularly the agile model. The primary difference is that the agile model does not restrict development cycles to forward movement. An order may be encouraged in some versions of the agile approach, but developers can go back to a previous phase if they feel that is warranted.
The primary advantages to a waterfall model are restraint and focus. It encourages developers to establish a vision and goals, then stick to them. The rigid, one-way structure is designed to prevent developers from continually making adjustments and additions without ever progressing toward completion. The waterfall model accounts for the business aspect of software development: while creativity, ingenuity, and technical knowledge are required to create products, they must ultimately be profitable to provide the developers funding to continue their work. The approach is designed to keep developers moving forward and staying within their objective. It also encourages thorough work, defining phases for product testing and responding to customer feedback.
However, many developers and engineers have stated their preference for other approaches. The disadvantage of the waterfall model is that it is an uncompromising system for a very unpredictable process. Software development often works with the newest technology, and exactly what it can and cannot do is not always clear without experimentation. Developers may learn something in the designing phase that could completely change the scope of the product. They may have a hard time defining user requirements because neither they nor the user know what possibilities are available.
Users collectively form a very large group with many differing wants and opinions. Even if a product is designed that exactly fulfills what the team determined were user requirements, users may react to it in an unexpected way. The ability to receive and adjust to user feedback at different stages of the process is extremely valuable.
Opponents of the waterfall model criticize its usefulness to the business side of development. Technology advances so quickly that something may come along that makes a product obsolete before it releases. In an agile approach, developers could use new advances to benefit the product, but the strict nature of the waterfall model would require them to take an undesirable product to market, or cancel the development and start a new product from scratch. While many developers agree that the phases outlined in the waterfall model are important, they do not support the need to carry out one at a time without any overlap.
Overview
Most versions of the waterfall model consist of six phases. The first is requirements determination. In this phase, developers and their financers figure out what needs their product is going to meet, what features it will have, how much time they have to release it, how much production will cost, and other factors.
The second step is design. This phase examines the technical aspects of the product. With the requirements established, developers examine what specifications a product would need to achieve what they are setting out to create. In this phase, developers analyze available hardware and determine the best way to work with it. They also try to determine how users will access and operate the software.
In the implementation phase, developers construct the software. While the first two phases largely involve planning, implementation is focused on creating. Depending on the complexity of the product, this phase may be broken into many smaller phases. By the end of this phase, the developers should have completed a working product. It may only be accessible to a very small, private group at first, but it should meet most requirements laid out in the first phase at this point.
The fourth phase is testing, or verification. Here, the developers put the product through numerous scenarios to see how it performs. This begins with installation, ensuring that the product interacts with the hardware it was designed for without any problems. The developers then analyze the range of functions that the product was designed to achieve. They also try to determine the product's limitations, anticipating different ways that users may put stress on it.
During the deployment phase, the product is released to the public. While this stage requires less work on the developers' part, they still play an important role in the process. They stay informed about customer feedback on the product, learning what demographics it succeeded and failed with, and whether it met, failed, or exceeded expectations. They also stay aware of any complaints of problems or bugs. These are ideally all caught during the previous phase, but rushed schedules, complicated systems, or unforeseen actions by users can lead to previously undetected problems. A team that is aware of feedback can address problems quickly and minimize backlash.
The final phase is maintenance. Using customer feedback, developers work to improve the product, fixing errors, expanding its capabilities, and helping it more efficiently perform its designed functions. Unlike many other products, software can be improved and updated without additional cost to the consumer, making this phase particularly important and expected.
Bibliography
"Definition of 'Waterfall Model.'" The Economic Times, economictimes.indiatimes.com/definition/waterfall-model. Accessed 24 Oct. 2024.
Hoory, Leeron, and Cassie Bottorff. "What Is Waterfall Methodology? Here’s How It Can Help Your Project Management Strategy." Forbes, 15 Oct. 2024, www.forbes.com/advisor/business/what-is-waterfall-methodology/. Accessed 24 Oct. 2024.
Hughey, Douglas. "The Traditional Waterfall Approach." University of Missouri-St. Louis, 2009, www.umsl.edu/~hugheyd/is6840/waterfall.html. Accessed 24 Oct. 2024.
Lotz, Mary. "Waterfall vs. Agile: Which Is the Right Development Methodology for Your Project?" Segue Technologies, 5 July 2018, www.seguetech.com/waterfall-vs-agile-methodology/. Accessed 24 Oct. 2024.
Lutkevich, Ben, and Sarah Lewis. "Waterfall Model." Tech Target, Nov. 2022, www.techtarget.com/searchsoftwarequality/definition/waterfall-model. Accessed 24 Oct. 2024.
Paredes, Rob. "Waterfall Methodology: The Pros and Cons." Safety Culture, 6 June 2024, safetyculture.com/topics/waterfall-methodology/. Accessed 24 Oct. 2024.
"What Is Waterfall Model?" ToolsQA, 18 Oct. 2021, www.toolsqa.com/software-testing/waterfall-model/. Accessed 24 Oct. 2024.
Wood, Colin. "Connecticut Forges a More Flexible Framework for State IT Projects." State Scoop, 18 Dec. 2017, statescoop.com/connecticut-forges-a-more-flexible-framework-for-state-it-projects. Accessed 24 Oct. 2024.