Actions

Waterfall Model

Definition of Waterfall Model

The waterfall model is a classical model used in system development life cycle to create a system with a linear and sequential approach. It is termed as waterfall because the model develops systematically from one phase to another in a downward fashion. This model is divided into different phases and the output of one phase is used as the input of the next phase. Every phase has to be completed before the next phase starts and there is no overlapping of the phases.[1]

The waterfall methodology is composed of seven non-overlapping stages:

  • Requirements: Potential requirements, deadlines and guidelines for the project are analyzed and placed into a functional specification. This stage handles the defining and planning of the project without mentioning specific processes.
  • Analysis: The system specifications are analyzed to generate product models and business logic that will guide production. This is also when financial and technical resources are audited for feasibility.
  • Design: A design specification document is created to outline technical design requirements such as programming language, hardware, data sources, architecture and services.
  • Coding/Implementation: The source code is developed using the models, logic and requirements designated in the prior stages. Typically, the system is designed in smaller components, or units, before being implemented together.
  • Testing: This is when quality assurance, unit, system and beta tests take place to report issues that may need to be resolved. This may cause a forced repeat of the coding stage for debugging. If the system passes the tests, the waterfall continues forward.
  • Operation/Deployment: The product or application is deemed fully functional and is deployed to a live environment.
  • Maintenance: Corrective, adaptive and perfective maintenance is carried out indefinitely to improve, update and enhance the final product. This could include releasing patch updates or releasing new versions.[2]


The Waterfall Model
source: Tech Talk


History of the Waterfall Method[3]

Waterfall is a logical pattern to follow - plan, build, test, and release in sequence. The history of Waterfall stems from Winston W. Royce’s 1970 article from the Proceedings of IEEE WESCON, Managing the Development of Large Software Systems. Royce’s article was probably the first discussion of Waterfall in software development, though the word “waterfall” does not appear anywhere in the article. The formal term was introduced in Thomas E. Bell’s and T.A. Thayer’s 1976 paper from the Proceedings of the 2nd International Conference on Software Engineering, Software requirements: Are they really a problem?. As has been noted in many places, however, Royce’s paper did not praise the method. In fact, he described it in unflattering terms, calling it flawed and inviting failure in many ways. He went on to discuss a more iterative approach, perhaps the foundation of what would become an Agile approach.

Bell and Thayer’s paper discusses a change in approach from a bottom-up to a top-down in the development of software requirements, referencing the adoption of this approach in MIL STD 490/483 (MIL STD 490 discusses specifications practices and MIL STD 483 discusses Configuration Management Practices for Systems). The paper is mainly concerned with examining the approaches empirically to determine which works best. Ultimately, the paper declares that “over the last ten years more structure and discipline has been adopted, and practitioners have concluded that a top-down approach is superior to the bottom-up approach of the past.” The term “waterfall” is used in direct reference to Winston Royce’s paper.

Despite the flaws described by Royce, Waterfall became a preferred method in 1985 when the Department of Defence issued DOD-STD-2167A, Defense Systems Software Development. It described the software development cycle as follows:

  • Software Requirements Analysis
  • Preliminary Design
  • Detailed Design
  • Coding and Unit Testing
  • Computer Software Component (CSC) Integration and Testing
  • CSCI Testing

The forward states that “this standard is intended to be dynamic and responsive to the rapidly evolving software technology field. As such, this standard should be selectively applied and tailored to fit the unique characteristics of each software acquisition program.” However, the requirement was laid out in black and white and followed religiously.

The Waterfall method began to fade from popular use when industry leaders became frustrated with its inflexibility and developed the Agile Manifesto. Since then, more and more companies have adopted Agile, but many businesses still cling to Waterfall, and for good reason. Waterfall has its faults, but it also has its benefits and in the right environment, can be the best practice.


Waterfall Model - Application[4]

Every software developed is different and requires a suitable SDLC approach to be followed based on the internal and external factors. Some situations where the use of Waterfall model is most appropriate are −

  • Requirements are 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 project is short.


Criticism of the Waterfall Method[5]

  • Clients may not know exactly what their requirements are before they see working software and so change their requirements, leading to redesign, redevelopment, and retesting, and increased costs.
  • Designers may not be aware of future difficulties when designing a new software product or feature, in which case it is better to revise the design than persist in a design that does not account for any newly discovered constraints, requirements, or problems.
  • Organisations may attempt to deal with a lack of concrete requirements from clients by employing systems analysts to examine existing manual systems and analyse what they do and how they might be replaced. However, in practice, it is difficult to sustain a strict separation between systems analysis and programming. This is because implementing any non-trivial system will almost inevitably expose issues and edge cases that the systems analyst did not consider.
  • In response to the perceived problems with the pure waterfall model, modified waterfall models were introduced, such as "Sashimi (Waterfall with Overlapping Phases), Waterfall with Subprojects, and Waterfall with Risk Reduction".
  • Some organizations, such as the United States Department of Defense, now have a stated preference against waterfall-type methodologies, starting with MIL-STD-498, which encourages evolutionary acquisition and Iterative and Incremental Development.
  • While advocates of agile software development argue the waterfall model is an ineffective process for developing software, some sceptics suggest that the waterfall model is a false argument used purely to market alternative development methodologies.
  • Rational Unified Process (RUP) phases acknowledge the programmatic need for milestones, for keeping a project on track, but encourage iterations (especially within Disciplines) within the Phases. RUP Phases are often referred to as "waterfall-like".
  1. Defining - What is the Waterfall Model Economic Times
  2. What are the stages of the Waterfall Model? Techtarget
  3. A History of the Waterfall Method Smartsheet
  4. When Can the Waterfall Model be Applied? Tutorials Point
  5. Criticism of the Waterfall Method Wikipedia