History of Waterfall Model

History of Waterfall Model by
Sanni Orahachi Rosemary

Waterfall model is regarded as one of the O.G.s of software development
methodologies. It’s commonly known as a strict process that doesn’t allow any
changes to occur, which kind of gives it a reputation for not being the most
ideal approach. But without it, we wouldn’t have other methods such
as Agile and Scrum.
In this presentation, I will provide an overview of Waterfall model, its pros and
cons, and also discuss when it’s best to use it.
What is a Waterfall model?

Waterfall model is one of the most traditional software development
methodologies. It follows a linear, sequential design approach where progress
flows downwards in one direction, like a waterfall (hence the name!).
A project is delivered through a set of ordered stages and until all activity
within the current stage has been completed and approved, advancing to the
next stage or any later stages is not possible.
Known for its emphasis on documentation, Gantt charts and resource

scheduling and allocation are popular Waterfall project management tools.
The history of Waterfall model

The Waterfall methodology has its origins within the manufacturing and
construction industries, to which you could ascribe its stringent process. Due
to the structured physical environments, the process leaves little room for
changes as any changes made would result in high costs. (Think about it, once
you construct a building, it would be pretty difficult to go back and make
changes.)
It was first formally introduced as a method for software development in an

article written by Dr. Winston W. Royce in 1970, however, the term “Waterfall”
wasn’t used. A paper written in 1976 by T.E. Bell and T.A. Thayer is when the
term may have been first used.
The Six Stages of Falling Water

There are six phases within the Waterfall methodology. You can only move
onto the next phase once the current one is completed, reviewed, and
approved.
In Royce’s original model, the phases are:
1. System and software requirements
2. Analysis
3. Design
4. Coding
5. Testing
6. Operations
Since then, there have been variations on the model depending on project
context and requirements. The most common model used is the following:
1. Requirement analysis
The first phase is about collecting information that pertains to the project’s
requirements. The purpose of the product and its function is defined.
Conducting brainstorming sessions are a common way to ensure the scope
and requirements are understood by everyone on the team. The result is
typically a requirements document that defines what the application should
do, but not how it should do it.
2. System Design
This next phase involves creating the design according to the requirements of
the first phase i.e. using technical design requirements, such as programming
language, data layers, services, etc. The purpose of this phase is to select
hardware and system requirements, and to also make clear of the overall
system architecture. This is also when the software code that is written in the
next stage is created.
3. Implementation
This phase is where the programs (actual source codes), which are known as
units, are finally written. They are individually developed and tested for their
functionality, a process that is known as Unit Testing. They are then integrated
into the following phase.
4. System testing
By this phase, the software has been designed and needs to go through
testing to determine any errors or issues within the application that needs to
be resolved. The testing phase of Waterfall model is imperative as it can
ensure the customer is not confronted by any difficulties during the
installation of the software. It is not uncommon for this phase to cause a
“necessary repeat” of the previous coding phase, in order for previous bugs to
be properly squashed.
5. System Deployment
Once the product has been tested, it is then distributed into the customer
environment.
6. Maintenance
The maintenance phase involves making adjustments to the system to

improve performance. The modifications are per the requests from the
customer or any faults detected during the live use of the product. The
customer is also provided consistent support and maintenance for the
developed software.
The Pros and Cons of Waterfall model
Knowing the benefits and drawbacks of the Waterfall method can help you to
recognize its value and when it’s best to use it.
Pros:
Progress measuring
With clearly defined start and end points, measuring progress can be rather
straightforward in Waterfall model. The full scope of work is known in advance
which also helps.
Simple structure
When compared with other project management methodologies, Waterfall is
rather intuitive. There are six phases to follow which are set in sequential
order. There are specific deliverables and a review process. This
methodological approach offers a simple structure for any newcomers to
follow. While some argue this is a burden rather than a benefit, the fact
remains that the waterfall model forces the project, to be extraordinarily
disciplined in its design and structure.
Early Design Changes

While it can be difficult to make design changes later in the process, the
waterfall approach lends itself well to alterations early in the life cycle. This is
great when fleshing out the specification documents in the first couple stages
with the development team and clients, as alterations can be made
immediately and with minimal effort, since no coding or implementation has
actually taken place up to that point.
Clear information transfer

The emphasis on documentation makes it easier for project team members to
ease into the process. The idea is to have information accessible is so that if a
team member was to leave during the development process, their
replacement can pick up where they left off because of its clear concrete, well-
suited stages that everyone on the team can understand and prepare for.
Cons:
High risks involved
Because testing the product design or architecture happens at the end of the
development process, there’s a greater chance of technical risks happening.
When a test in stage five reveals a fundamental flaw in the design of the
system, it not only requires a dramatic leap backward in stages of the process,
but in some cases, can be often lead to a devastating realization regarding the
legitimacy of the entire system.
No room for innovation

One of the biggest downfalls of Waterfall model is its inflexibility for changes
happening within the development process. This makes it difficult for new
ideas to be welcomed and included.
Lack of customer involvement

Following the Waterfall method means there will be little room for customer
feedback and involvement. While this may not be a hindrance to every project,
there are certain industries where customer feedback plays a vital role in the
end result.
When to use Waterfall project

management
Waterfall project management often gets a bad rap. It’s notable for being
stringent and inflexible which is not ideal for software development that
requires a lot of frequent changes. That’s why you often see it being
compared and contrasted to Agile project management.
The Waterfall methodology is best suited for projects that are clearly defined
and require structure and strict deadlines. The project scope and requirements
should be set, the product is solid, and the technology used is well understood
by the project team members. As it leaves little room for changes, it makes it
unsuitable for project that involve unexplored territory and uncertainty.
In other words, it’s great for projects that have been done many times over
where the prospect of surprises during development are slim.

History of Waterfall Model

Uploaded by

Copyright:

Available Formats

History of Waterfall Model

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

History of Waterfall Model

Uploaded by

Copyright:

Available Formats

History of Waterfall Model by

Sanni Orahachi Rosemary

What is a Waterfall model?

Known for its emphasis on documentation, Gantt charts and resource

The history of Waterfall model

It was first formally introduced as a method for software development in an

The Six Stages of Falling Water

In Royce’s original model, the phases are:

1. System and software requirements

The maintenance phase involves making adjustments to the system to

Early Design Changes

Clear information transfer

No room for innovation

Lack of customer involvement

When to use Waterfall project

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.