Information Technology Reference
In-Depth Information
Fig. 1.2 A model of the
waterfall life cycle
Analysis
Design
Implementation
Testing
Deployment
with no need for modifications or additional functionality beyond the initial
product specification, then the classical model would be an easy choice. In prac-
tice, however, perfection is often a difficult goal to achieve. Regardless of the
energy spent trying to avoid or account for them, miscommunications, misun-
derstandings, mistakes due to human error, and changes in requirements will
occur; and problems will result. When this occurs, the only solution is often to
correct the error through a change in the product. The failure to allow proper
flexibility for this sort of change is a major weakness of the waterfall model.
The strict sequential structure of the waterfall model attempts to prohibit
simultaneous work on different stages. Thus, if a problem that was created in an
early development phase is not discovered until a later stage in the development
process, the problem must either be ignored or the entire development process
must be altered. In the latter case, the earlier development phase, which has been
'signed off' as complete, must now be reopened, and the life cycle must essentially
be rewound to this phase. When the problem is corrected, development must
continue from that early phase, in order to ensure that all of the proceeding work
accommodates for the changes made. For this reason, errors discovered in later
phases are extremely time consuming and expensive to fix, as they can require a
full overhaul of the project (Sommerville
2004
).
In addition to its inflexibility, the waterfall model's reliance on step-by-step
development means that no tangible product is available for assessment by the
client until late in the development process. This lack of feedback fails to ensure
that the product which is being developed is compatible with the desires of the
client. The discovery of such a mismatch, like the identification of any other
design flaw, at such a late stage in the process can require time-consuming and
costly
backtracking
through
the
entire
development
process
(Stiller
and
LeBlanc
2002
).
The unpredictability of human error combined with the size and cost of many
software engineering projects have made strict use of the waterfall model a risky
endeavor. Many of the aspects that originated with this life cycle model, however,
have become staples of more secure and flexible development paradigms. The
development phases that Royce put forth are still used in nearly every software life
