The waterfall model is a sequential design process, used in software development processes, in

which progress is seen as flowing steadily downwards (like a waterfall) through the phases of
conception, initiation, analysis, design, construction, testing, production/implementation and
maintenance.
The waterfall development model originates in the manufacturing and construction industries:
highly structured physical environments in which after-the-fact changes are prohibitively costly,
if not impossible. Since no formal software development methodologies existed at the time, this
hardware-oriented model was simply adapted for software development.[1]
Contents

1 History

2 Model

3 Supporting arguments

4 Criticism

5 See also

6 References

7 External links

History

The first known presentation describing use of similar phases in software engineering was held
by Herbert D. Benington at Symposium on advanced programming methods for digital
computers on 29 June 1956.[2] This presentation was about the development of software for
SAGE. In 1983 the paper was republished with a foreword by Benington pointing out that the
process was not in fact performed in a strict top-down fashion, but depended on a prototype.[1]
The first formal description of the waterfall model is often cited as a 1970 article by Winston W.
Royce,[3][4] although Royce did not use the term waterfall in that article. Royce presented this
model as an example of a flawed, non-working model; which is how the term is generally used in
writing about software developmentto describe a critical view of a commonly used software
development practice.[5]
The earliest use of the term "waterfall" may have been a 1976 paper by Bell and Thayer.[6]
In 1985, the United States Department of Defense captured this approach in DOD-STD-2167A,
their standards for working with software development contractors, which stated that "the
contractor shall implement a software development cycle that includes the following six phases:
Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing".[7]

Model

In Royce's original waterfall model, the following phases are followed in order:
1. System and software requirements: captured in a product requirements
document
2. Analysis: resulting in models, schema, and business rules
3. Design: resulting in the software architecture
4. Coding: the development, proving, and integration of software
5. Testing: the systematic discovery and debugging of defects
6. Operations: the installation, migration, support, and maintenance of complete
systems

Thus the waterfall model maintains that one should move to a phase only when its preceding
phase is reviewed and verified.
Various modified waterfall models (including Royce's final model), however, can include slight
or major variations on this process.[3] These variations included returning to the previous cycle
after flaws were found downstream, or returning all the way to the design phase if downstream
phases deemed insufficient.
Supporting arguments

Time spent early in the software production cycle can avoid costs at later stages, for example a
problem found in the early stages (such as requirements specification) is cheaper to fix than the
same bug found later on in the process (by a factor of 50 to 200).[8]
In common practice waterfall methodologies result in a project schedule with 2040% of the
time invested for the first two phases, 3040% of the time to coding, and the rest dedicated to
testing and implementation. The actual project organization needs to be highly structured. Most
medium and large projects will include a detailed set of procedures and controls, which regulate
every process on the project.[9]
A further argument for the waterfall model is that it places emphasis on documentation (such as
requirements documents and design documents) as well as source code. In less thoroughly
designed and documented methodologies, knowledge is lost if team members leave before the
project is completed, and it may be difficult for a project to recover from the loss. If a fully
working design document is present (as is the intent of Big Design Up Front and the waterfall
model), new team members or even entirely new teams should be able to familiarize themselves
by reading the documents.[10]

The waterfall model provides a structured approach; the model itself progresses linearly through
discrete, easily understandable and explainable phases and thus is easy to understand; it also
provides easily identifiable milestones in the development process. It is perhaps for this reason
that the waterfall model is used as a beginning example of a development model in many
software engineering texts and courses.[11]
It is argued that the waterfall model can be suited to projects where requirements and scope are
fixed, the product itself is firm and stable, and the technology is clearly understood.[12]
Criticism

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.[13]
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.[14]
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".[8]
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.[15]
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.[16]
his is a list of approaches, styles, and philosophies in software development not included in the
category tree of software development philosophies. It contains also software development
processes, software development methodologies and single practices, principles and laws.
Contents

1 Software development philosophies

2 Miscellany

3 Programming paradigm

4 Software development methodology

5 Software development processes

6 Software metrics

7 References

8 See also

Software development philosophies

Software development philosophies
Programming principles
Programming rules of thumb
List of software development philosophies
Acceptance test-driven development
After the Software Wars
Agile Manifesto
Agile software development
Behavior-driven development
Best practice
The Cathedral and the Bazaar
Comment programming
Cowboy coding
Design-driven development
Domain-driven design
Extreme programming
Formal methods
Hollywood principle
Homesteading the Noosphere
Integration competency center
Iterative and incremental development
Kanban (development)
KISS principle
Lean integration

Lean software development

Lightweight methodology
The Magic Cauldron (essay)
Micro-innovation
Minimalism (computing)
Planning poker
PM Declaration of Interdependence
Release early, release often
Retrenchment (computing)
Rule of least power
Secure by design
Slow programming
Specification by example
SWAT Team (process model)
Test double
Continuous test-driven development
Test-driven development
Test-Driven Development by Example
There's more than one way to do it
Top development
Transformation Priority Premise
Unix philosophy
Waterfall model
Worse is better
You aren't gonna need it
Miscellany
This section may be in need of reorganization to comply with
Wikipedia's layout guidelines. Please help by editing the article to make
improvements to the overall structure. (November 2013)

Abstraction principle (programming)

Alignment of authority and responsibility

Big Design Up Front (BDUF)

Black box engineering

Brooks's law

Cathedral and the Bazaar (see also Release early, release often (RERO))

Chief programmer team

CMMI

Code and fix

Cone of Uncertainty

Continuous integration

Control tables

Convention over configuration

Conway's Law

Cowboy coding

Dependency injection

Design by Contract (DbC)

Design for Test (DFT)

Don't repeat yourself (DRY) or Duplication is Evil (DIE) or Once and Only Once
(OAOO), Single Point of Truth (SPoT), Single Source Of Truth (SSOT)

Easier to Ask Forgiveness than Permission (EAFP)

Encapsulation (computer science)

Evolutionary prototyping

Free software license

General Responsibility Assignment Software Patterns (GRASP)

Hofstadter's law

Hollywood Principle

Information Hiding

Interface (computer science)

Interface (object-oriented programming)

Inversion of control

Joint application design, aka JAD or "Joint Application Development"

Kaizen

Literate Programming

Microsoft Solutions Framework (MSF)

Model-driven architecture (MDA)

MoSCoW Method

Naked Objects

Open source

Principle of least astonishment (POLA/PLA)

Principle of good enough (POGE)

Project triangle

Program optimization

Protocol (object-oriented programming)

Rapid prototyping

Refactoring

Release early, release often (RERO) - see also The Cathedral and the Bazaar

Responsibility-driven design (RDD)

the Right thing, or the MIT approach, as contrasted with the New Jersey style,
Worse is better.

Secure by design

Separation of concerns (SoC)

Service-oriented modeling

Software craftsmanship

Software System Safety

Spiral model

Stepwise Refinement

Team Software Process (TSP)

Type-Generic-Profile (TGP) definition at Wards Wiki

Ubuntu philosophy

Unix philosophy

V-Model

Wheel and spoke model

The Zen of Python

Programming paradigm

Agent-oriented programming

Aspect-oriented Programming (AOP)

Modular programming

Object-Oriented Programmi

ng (OOP)

Functional Programming (FP)

Software development methodology

Agile Unified Process (AUP)

Dynamic Systems Development Method (DSDM)

Constructionist design methodology (CDM)

Crystal Clear

Extreme Programming (XP)

Iterative and incremental development

Kanban

Lean software development

Open Unified Process

Pair programming

Rapid application development (RAD)

Rational Unified Process (RUP)

Scrum

Structured Systems Analysis and Design Method (SSADM)

Unified Process (UP)

Software development processes

Behavior-driven development (BDD)

Design-driven development (D3)

Domain-Driven Design (DDD)

Feature Driven Development (FDD)

Test-driven development (TDD)

User-centered design (UCD)

Software metrics

Cohesion (computer science)

Coupling (computer programming)

References

Don't Make Me Think (book by Steve Krug about human computer interaction
and web usability)

See also

Anti-pattern

Design pattern

Programming paradigm

Software development methodology

Software development process

[hide]

Software engineering

Fields

Computer programming

Requirements engineering

Software deployment

Software design

Software maintenance

Software testing

Systems analysis

Formal methods

Concepts

Data modeling

Enterprise architecture

Functional specification

Modeling language

Orthogonality

Programming paradigm

Software

Software archaeology

Software architecture

Software configuration management

Software development methodology

Software development process

Software quality

Software quality assurance

Software verification and validation

Structured analysis

Agile

Aspect-oriented

Object orientation

Orientati
ons

Ontology

Service orientation

SDLC

Models

Developmen
tal

Agile

EUP

Executable UML

Incremental model

Iterative model

Prototype model

RAD

UP

SPICE

CMMI

Data model

ER model

Function model

Information model

Metamodeling

Other

Object model

Systems model

View model

IDEF

UML

SysML

Languages

Software
engineer
s

Kent Beck

Grady Booch

Fred Brooks

Barry Boehm

Ward Cunningham

Tom DeMarco

Edsger W. Dijkstra

Martin Fowler

C. A. R. Hoare

Watts Humphrey

Michael A. Jackson

Ivar Jacobson

Stephen J. Mellor

Bertrand Meyer

David Parnas

Winston W. Royce

James Rumbaugh

Paula George Tompkins

Niklaus Wirth

Edward Yourdon

Victor Basili

Computer science

Computer engineering

Project management

Risk management

Systems engineering

Related
fields

Category

Commons

Categories:

Software development philosophies

Software engineering

Navigation menu

Create account

Log in

Article

Talk

Read

Edit

View history