2/28/2010 Waterfall model - Wikipedia, the free e…

Waterfall model
From Wikipedia, the free encyclopedia

The waterfall model is a sequential design process, often 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 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.

The first formal description of the waterfall model is

often cited as a 1970 article by Winston W.
Royce,[1] though Royce did not use the term
"waterfall" in this article. Royce presented this
model as an example of a flawed, non-working
model (Royce 1970). This, in fact, is how the term
is generally used in writing about software The unmodified "waterfall model". Progress flows from the
development—to describe a critical view of a top to the bottom, like a waterfall.
commonly used software practice.[2]

Software development process

Activities and steps
Contents
Requirements · Specification
1 Model Architecture · Design
2 Supporting arguments Implementation · Testing
3 Criticism
Deployment · Maintenance
4 Modified models
5 See also Methodologies
6 References Agile · Cleanroom · Iterative
7 Further reading
RAD · RUP · Spiral
8 External links
Waterfall · XP · Lean
Scrum · V-Model · TDD
Model Supporting disciplines
Configuration management
In Royce's original waterfall model, the following phases are
Documentation
followed in order:
Quality assurance (SQA)
1. Requirements specification Project management
2. Design User experience design
en.wikipedia.org/wiki/Waterfall_model 1/5
2/28/2010 Waterfall model - Wikipedia, the free e…
3. Construction (AKA implementation or coding) Tools
4. Integration
5. Testing and debugging (AKA Validation) Compiler · Debugger · Profiler
6. Installation GUI designer · IDE
7. Maintenance

Thus the waterfall model maintains that one should move to a phase only when its preceding phase is completed and
perfected. However, there are various modified waterfall models (including Royce's final model) that may include
slight or major variations upon this process.

Supporting arguments
Time spent early in the software production cycle can lead to greater economy at later stages. McConnell shows
that a bug found in the early stages (such as requirements specification or design) is cheaper in money, effort, and
time, to fix than the same bug found later on in the process. ([McConnell 1996], p. 72, estimates that "...a
requirements defect that is left undetected until construction or maintenance will cost 50 to 200 times as much to fix
as it would have cost to fix at requirements time.") To take an extreme example, if a program design turns out to be
impossible to implement, it is easier to fix the design at the design stage than to realize months later, when program
components are being integrated, that all the work done so far has to be scrapped because of a broken design.

This is the central idea behind Big Design Up Front and the waterfall model: time spent early on making sure
requirements and design are correct saves you much time and effort later. Thus, the thinking of those who follow the
waterfall process goes, make sure each phase is 100% complete and absolutely correct before you proceed to the
next phase. Program requirements should be set in stone before design begins (otherwise work put into a design
based on incorrect requirements is wasted). The program's design should be perfect before people begin to
implement the design (otherwise they implement the wrong design and their work is wasted), etc.

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 designed and documented methodologies, should
team members leave, much knowledge is lost and may be difficult for a project to recover from. Should a fully
working design document be 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.

As well as the above, some prefer the waterfall model for its simple approach and argue that it is more disciplined.
Rather than what the waterfall adherent sees as chaos, 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 markable 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.

It is argued that the waterfall model and Big Design up Front in general can be suited to software projects that are
stable (especially those projects with unchanging requirements, such as with shrink wrap software) and where it is
possible and likely that designers will be able to fully predict problem areas of the system and produce a correct
design before implementation is started. The waterfall model also requires that implementers follow the well-made,
complete design accurately, ensuring that the integration of the system proceeds smoothly.

Criticism
en.wikipedia.org/wiki/Waterfall_model 2/5
2/28/2010 Waterfall model - Wikipedia, the free e…

Many argue the waterfall model is a bad idea in practice—believing it impossible for any non-trivial project to finish
a phase of a software product's lifecycle perfectly before moving to the next phases and learning from them. For
example, clients may not know exactly what requirements they need before reviewing a working prototype and
commenting on it. They may change their requirements constantly. Designers and programmers may have little
control over this. If clients change their requirements after the design is finalized, the design must be modified to
accommodate the new requirements. This effectively means invalidating a good deal of working hours, which means
increased cost, especially if a large amount of the project's resources has already been invested in Big Design Up
Front.

Designers may not be aware of future implementation difficulties when writing a design for an unimplemented
software product. That is, it may become clear in the implementation phase that a particular area of program
functionality is extraordinarily difficult to implement. In this case, it is better to revise the design than persist in a
design based on faulty predictions, and that does not account for the newly discovered problems.

Even without such changing of the specification during implementation, there is the option either to start a new
project from scratch, "on a green field", or to continue some already existing, "a brown field" (from construction
again). The waterfall methodology can be used for continuous enhancement, even for existing software, originally
from another team. As well as in the case when the system analyst fails to capture the customer requirements
correctly, the resulting impacts on the following phases (mainly the coding) still can be tamed by this methodology,
in practice: A challenging job for a QA team.

Steve McConnell, in Code Complete, (a book that criticizes widespread use of the waterfall model) refers to
design as a "wicked problem"—a problem whose requirements and limitations cannot be entirely known before
completion. The implication of this is that it is impossible to perfect one phase of software development, thus it is
impossible if using the waterfall model to move on to the next phase.

David Parnas, in A Rational Design Process: How and Why to Fake It, writes:[3]

“Many of the [system's] details only become known to us as we progress in the [system's]
implementation. Some of the things that we learn invalidate our design and we must backtrack.”

Expanding the concept above, the project stakeholders (non-IT personnel) may not be fully aware of the
capabilities of the technology being implemented. This can lead to what they "think is possible" defining expectations
and requirements. This can lead to a design that does not use the full potential of what the new technology can
deliver, or simply replicates the existing application or process with the new technology. This can cause substantial
changes to the implementation requirements once the stakeholders become more aware of the functionality available
from the new technology. An example is where an organization migrates from a paper-based process to an
electronic process. While key deliverables of the paper process must be maintained, benefits of real-time data input
validation, traceability, and automated decision point routing may not be anticipated at the early planning stages of
the project.

The idea behind the waterfall model may be "measure twice; cut once," and those opposed to the waterfall model
argue that this idea tends to fall apart when the problem constantly changes due to requirement modifications and
new realizations about the problem itself. A potential solution is for an experienced developer to spend time up front
on refactoring to consolidate the software, and to prepare it for a possible update, no matter if such is planned
already. Another approach is to use a design targeting modularity with interfaces, to increase the flexibility of the
software with respect to the design.

en.wikipedia.org/wiki/Waterfall_model 3/5
2/28/2010 Waterfall model - Wikipedia, the free e…

Modified models
In response to the perceived problems with the pure waterfall model, many modified waterfall models have been
introduced. These models may address some or all of the criticisms of the pure waterfall model.[citation needed]
Many different models are covered by Steve McConnell in the "lifecycle planning" chapter of his book Rapid
Development: Taming Wild Software Schedules.

While all software development models bear some similarity to the waterfall model, as all software development
models incorporate at least some phases similar to those used in the waterfall model, this section deals with those
closest to the waterfall model. For models that apply further differences to the waterfall model, or for radically
different models seek general information on the software development process.

See also
Agile software development
Big Design Up Front
Chaos model
Iterative and incremental development
Iterfall development
Rapid application development
Software development process
Spiral model
System Development Methodology
V-model
Dual Vee Model
List of software development philosophies

References
1. ^ Wasserfallmodell > Entstehungskontext (http://cartoon.iguw.tuwien.ac.at/fit/fit01/wasserfall/entstehung.html) ,
Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. Accessed on line November 28,
2007.
2. ^ Conrad Weisert, Waterfall methodology: there's no such thing! (http://www.idinews.com/waterfall.html)
3. ^ "A Rational Design Process: How and Why to Fake It" (http://www.cs.tufts.edu/~nr/cs257/archive/david-
parnas/fake-it.pdf) , David Parnas (PDF file)

Further reading
This article was originally based on material from the Free On-line Dictionary of Computing, which is
licensed under the GFDL.

McConnell, Steve (2006). Software Estimation: Demystifying the Black Art. Microsoft Press. ISBN 0-
7356-0535-1.
McConnell, Steve (2004). Code Complete, 2nd edition. Microsoft Press. ISBN 1-55615-484-4.
McConnell, Steve (1996). Rapid Development: Taming Wild Software Schedules. Microsoft Press.
ISBN 1-55615-900-5.
en.wikipedia.org/wiki/Waterfall_model 4/5
2/28/2010 Waterfall model - Wikipedia, the free e…
Parnas, David, A rational design process and how to fake it (PDF)
(http://users.ece.utexas.edu/~perry/education/SE-Intro/fakeit.pdf) An influential paper which criticises the
idea that software production can occur in perfectly discrete phases.
Royce, Winston (1970), "Managing the Development of Large Software Systems"
(http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf) , Proceedings of IEEE
WESCON 26 (August): 1–9, http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf.
"Why people still believe in the waterfall model" (http://tarmo.fi/blog/2005/09/09/dont-draw-diagrams-of-
wrong-practices-or-why-people-still-believe-in-the-waterfall-model/)
The standard waterfall model for systems development
(http://web.archive.org/web/20050310133243/http://asd-
www.larc.nasa.gov/barkstrom/public/The_Standard_Waterfall_Model_For_Systems_Development.htm)
NASA webpage, archived on Internet Archive March 10, 2005.
Parametric Cost Estimating Handbook (http://cost.jsc.nasa.gov/PCEHHTML/pceh.htm) , NASA webpage
based on the waterfall model, archived on Internet Archive March 8, 2005.

External links
Understanding the pros and cons of the Waterfall Model of software development
(http://articles.techrepublic.com.com/5100-10878_11-6118423.html?part=rss&tag=feed&subj=tr)
"Waterfall model considered harmful" (http://www.it-director.com/technology/productivity/content.php?
cid=7865)
Project lifecycle models: how they differ and when to use them (http://www.business-
esolutions.com/islm.htm)
Going Over the Waterfall with the RUP (http://www-
128.ibm.com/developerworks/rational/library/4626.html) by Philippe Kruchten
CSC and IBM Rational join to deliver C-RUP and support rapid business change
(http://www.ibm.com/developerworks/rational/library/3012.html)
wiki:WaterFall
Retrieved from "http://en.wikipedia.org/wiki/Waterfall_model"
Categories: Software development process | Design

This page was last modified on 23 February 2011 at 15:08.

Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply.
See Terms of Use for details.
Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.

en.wikipedia.org/wiki/Waterfall_model 5/5