What is Waterfall?

The term "Waterfall" refers to a traditional software development methodology where the project is defined sequentially and through clear project phases. This is a common approach to large-scale projects where little change is expected to the overall project plan. This is a distinct approach from Agile project planning, which is designed to accommodate rapid changes to the schedule.

Waterfall Quote

What Is Waterfall Methodology?

Waterfall Model

The Waterfall Model was the first Process Model to be introduced. It is also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases. Waterfall model is the earliest SDLC approach that was used for software development and is the most popular version of the systems development life cycle (SDLC) for software engineering and IT projects. It proceeds through a sequential, single direction process that flows like a waterfalls.

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 Defense 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.

The Waterfall Model illustrates the software development process in a linear sequential flow; hence it is also referred to as a linear-sequential life cycle model. This means that any phase in the development process begins only if the previous phase is complete. In this method, you determine what to build, plan the build, work out a schedule, obtain your resources, assign resources, develop the product, hand it off to a test team, work out the bugs, and then release it. Along the way the marketing team creates some “buzz” in anticipation of the product, and sales people convince customers that the new product will solve all of their problems.

This guide will detail the key components of Waterfall including its phases, advantages and disadvantages and definitions of two important structures leveraged in Waterfall: work breakdown structures and the critical path method. In addition, you’ll find helpful resources to help you create effective Waterfall charts for your next project.

Waterfall Product Development

There are many ways to think of how to employ a methodology and many points along a project at which to choose different methods to get different kind of work done. There are also different kinds of project methods in use depending upon your country of origin. In the U.K., the majority of project professionals adhere to a PRINCE2 methodology, an acronym for PRojects IN Controlled Environments, which addresses the larger questions of cost, time, resources, etc. Whereas in the U.S., a number of certified project managers follow the Project Management Institute’s PMBOK Guide for formal project management practice. It’s a book that collects the processes used in classic project management, with fundamental practices needed to achieve organizational results.

On a more tactical level, in both of those methodologies, the projects tend to adhere to the Waterfall method of planning project schedules according to a fixed, cascading plan. It is a classic model, one in which the executives and stakeholders on the project will want to see fixed costs and schedules, typically used for large infrastructure projects such as bridges, tunnels, construction and manufacturing.

Waterfall Model Design

Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure success of the project. In "The Waterfall" approach, the whole process of software development is divided into separate phases. In Waterfall model, typically, the outcome of one phase acts as the input for the next phase sequentially.

Following is a diagrammatic representation of different phases of waterfall model.

Waterfall Flow Diagram

The sequential phases in Waterfall model are:

  • Requirements: All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification doc.

  • Design: The requirement specifications from first phase are studied in this phase and system design is prepared. System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture.

  • Development: With inputs from system design, the system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality which is referred to as Unit Testing.

  • Testing: All the units developed in the Design phase are integrated into a system after testing of each unit. Post integration the entire system is tested for any faults and failures.

  • Deployment: Once the functional and non-functional testing is done, the product is deployed in the customer environment or released into the market.

  • Maintenance: There are some issues which come up in the client environment. To fix those issues patches are released. Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the customer environment.

All these phases are cascaded to each other in which progress is seen as flowing steadily downwards (like a waterfall) through the phases. The next phase is started only after the defined set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model". In this model phases do not overlap.

Waterfall Model Application

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.

What Is a Work Breakdown Structure?

A work breakdown structure (WBS) is a visual tool used to create, define, and track a project deliverable and all of its subsequent components. A WBS is a decomposed visual of a total scope of work that determines the project objectives, the steps needed to complete the objectives, and the desired outcome or product.

By focusing more on the individual deliverables as opposed to the method to achieve these tasks, unnecessary work, risk, and wasted time is eliminated from the equation. The focus is shifted from a large project towards a deconstructed task list, helping teams accomplish their goals faster and more efficiently.

What Is the Critical Path Method?

The critical path method, a project management technique that came to the forefront in the 1950s, gives companies the ability to identify the success that hinges on completing the tasks of the project effectively. This method determines the sequence of successive activities that will affect the duration and successful completion of a project.

The CPM helps to determine how a delay or setback in a project will affect the entirety of the proposed plan, deeming certain tasks as critical because of the more detrimental consequences in failure of timely completion. Most projects have only one critical path, but some can have multiple critical paths that must be followed and maintained in order to stick to the predetermined timeline.

Waterfall Model Pros & Cons

Advantage

The advantage of waterfall development is that it allows for departmentalization and control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process model phases one by one.

Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order.

Disadvantage

The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-documented or thought upon in the concept stage.



The following table lists out the pros and cons of Waterfall model:

Pros Cons
  • Simple and easy to understand and use.

  • Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.

  • Phases are processed and completed one at a time.

  • Works well for smaller projects where requirements are very well understood.

  • Clearly defined stages.

  • Well understood milestones.

  • Easy to arrange tasks.

  • Process and results are well documented.
  • No working software is produced until late during the life cycle.

  • High amounts of risk and uncertainty.

  • Not a good model for complex and object-oriented projects.

  • Poor model for long and ongoing projects.

  • Not suitable for the projects where requirements are at a moderate to high risk of changing. So risk and uncertainty is high with this process model.

  • It is difficult to measure progress within stages.

  • Cannot accommodate changing requirements.

  • Adjusting scope during the life cycle can end a project.

  • Integration is done as a "big-bang. At the very end, which doesn't allow identifying any technological or business bottleneck or challenges early.

Iterative Waterfall Model

As mentioned above, one of the disadvantages of the Model is that it does not allow for much reflection or revision; to get around this Waterfall can also be applied in an iterative manner.

An iterative life cycle model does not attempt to start with a full specification of requirements. Instead, development begins by specifying and implementing just part of the software, which can then be reviewed in order to identify further requirements. This process is then repeated, producing a new version of the software for each cycle of the model.

For each cycle of the model shown above, a decision has to be made as to whether the software produced by the cycle will be discarded, or kept as a starting point for the next cycle (sometimes referred to as incremental prototyping). Eventually a point will be reached where the requirements are complete and the software can be delivered, or it becomes impossible to enhance the software as required, and a fresh start has to be made.

The iterative life cycle model can be likened to producing software by successive approximation. Drawing an analogy with mathematical methods that use successive approximation to arrive at a final solution, the benefit of such methods depends on how rapidly they converge on a solution.

The key to successful use of an iterative software development life cycle is rigorous validation of requirements, and verification (including testing) of each version of the software against those requirements within each cycle of the model.

The first three phases of the Iterative Waterfall Model is in fact an abbreviated form of the Waterfall Model of development. Each cycle of the model produces software that requires testing at the unit level, for software integration, for system integration and for acceptance. As the software evolves through successive cycles, tests have to be repeated and extended to verify each version of the software.

But one thing to keep in mind is that in the Iterative Waterfall Model the team is doing the same thing but they are treating each story as a miniature project. They do all the analysis for one story, then all the design for one story, then all the coding and testing for one story. This is an iterative waterfall process and should not be confused with an agile process.

Iterative Waterfall Flow Diagram
Iterative Waterfall Example

Let's look at a simple example to illustrate iterative waterfall. When we work iteratively we create rough product or product piece in one iteration, then review it and improve it in next iteration and so on until it’s finished. When we're creating a painting, in the first iteration the whole painting is sketched roughly, then in the second iteration colors are filled and in the third iteration finishing is done. Hence, in iterative model the whole product is developed step by step.

When to use iterative model:

  • Requirements of the complete system are clearly defined and understood.

  • When the project is big.

  • Major requirements must be defined; however, some details can evolve with time.



The following table lists out the pros and cons of Iterative Waterfall model:

Pros Cons
  • In iterative model we can only create a high-level design of the application before we actually begin to build the product and define the design solution for the entire product. Later on we can design and built a skeleton version of that, and then evolved the design based on what had been built.

  • In iterative model we are building and improving the product step by step. Hence we can track the defects at early stages. This avoids the downward flow of the defects.

  • In iterative model we can get the reliable user feedback. When presenting sketches and blueprints of the product to users for their feedback, we are effectively asking them to imagine how the product will work.

  • In iterative model less time is spent on documenting and more time is given for designing.
  • Each phase of an iteration is rigid with no overlaps.

  • Costly system architecture or design issues may arise because not all requirements are gathered up front for the entire lifecycle.




These articles were in part originally published by TutorialsPoint.com
Copyright 2016 © TutorialsPoint.com
3rd Floor, Vamsiram's Jyothi Celestia, Kavuri Hills, Phase-2, Madhapur, Hyderabad, INDIA-500081