1

Waterfall Model Guide

These days there is a strong push for Agile Management, as opposed to Waterfall. Personally at Castellan
Systems we believe that the agility should be applied to the project development lifecycle rather than the project
management. A strong project management process is equally, if not more, appropriate to an "Agile"
environment. The more agile or dynamic a project environment is, the more important strong project
management principles and processes are. In a fast moving project environment things can go wrong very
quickly and if the project management disciplines are not strongly applied these problems may not be picked up
until it's too late.

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.

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

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.

CASTELLAN SYSTEMS | Waterfall Model Guide

2

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.

CASTELLAN SYSTEMS | Waterfall Model Guide

 3

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
nonfunctional 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

CASTELLAN SYSTEMS | Waterfall Model Guide

4

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. • No working software is produced until late
during the life cycle.
• Easy to manage due to the rigidity of the
model. Each phase has specific deliverables • High amounts of risk and uncertainty.
and a review process.
• Not a good model for complex and object-
• Phases are processed and completed one at oriented projects.
a time.
• Poor model for long and ongoing projects.
• Works well for smaller projects where
requirements are very well understood. • Not suitable for the projects where
requirements are at a moderate to high risk
• Clearly defined stages. of changing. So risk and uncertainty is high
with this process model.
• Well understood milestones.
• It is difficult to measure progress within
• Easy to arrange tasks. stages.

• Process and results are well documented. • 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.

CASTELLAN SYSTEMS | Waterfall Model Guide

 5

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.

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.

CASTELLAN SYSTEMS | Waterfall Model Guide

6

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- • Each phase of an iteration is rigid with no
level design of the application before we overlaps.
actually begin to build the product and define
the design solution for the entire product. • Costly system architecture or design issues
Later on we can design and built a skeleton may arise because not all requirements are
version of that, and then evolved the design gathered up front for the entire lifecycle.
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.

Acknowledgements

These articles were in part originally published by [Link]

Copyright 2016 © [Link]

3rd Floor, Vamsiram's Jyothi Celestia, Kavuri Hills, Phase-2, Madhapur, Hyderabad, INDIA-500081

CASTELLAN SYSTEMS | Waterfall Model Guide