Waterfall model

From Wikipedia, the free encyclopedia

Jump to: navigation, search

The waterfall model is a sequential software development process, 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 unmodified "waterfall model". Progress flows from the top to the bottom, like a
waterfall.
Software development process
Activities and steps
Requirements · Specification
Architecture · Design
Implementation · Testing
Deployment · Maintenance
Methodologies
Agile · Cleanroom ·
Iterative · RAD · RUP · Spiral
Waterfall · Lean
V-Model · TDD
Supporting disciplines
Configuration management
Documentation
Quality assurance (SQA)
 Project management
User experience design
Tools
Compiler · Debugger · Profiler
GUI designer · Integrated development
environment
v•d•e

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 development—to
describe a critical view of a commonly used software practice.[2]

Contents
[hide]

• 1 Model
• 2 Supporting arguments
• 3 Criticism
• 4 Modified models
• 5 See also
• 6 References
• 7 Further reading

• 8 External links

[edit] Model
In Royce's original waterfall model, the following phases are followed in order:

1. Requirements specification
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA Validation)
 6. Installation
7. Maintenance

The waterfall model proceeds from one phase to the next in a sequential manner. For
example, one first completes requirements specification, which after sign-off are
considered "set in stone." When requirements are completed, one proceeds to design. The
software in question is designed and a blueprint is drawn for implementers (coders) to
follow—this design should be a plan for implementing the requirements given. When the
design is complete, an implementation of that design is made by coders. Towards the
later stages of this implementation phase, separate software components produced are
combined to introduce new functionality and reduced risk through the removal of errors.

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.

[edit] 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 (BDUF) and the waterfall model:
time spent early on making sure requirements and design are absolutely 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.

[edit] Criticism
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.

[edit] 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.