Java Reference
In-Depth Information
13.6.1
Waterfall model
In the waterfall model, several phases of software development are done in a fixed sequence:
■
analysis of the problem
■
design of the software
■
implementation of the software components
■
unit testing
■
integration testing
■
delivery of the system to the client
If any phase fails, we might have to step back to the previous phase to fix it (for example, if
testing shows failure, we go back to implementation), but there is never a plan to revisit earlier
phases.
This is probably the most traditional, conservative model of software development, and it has
been in widespread use for a long time. However, numerous problems have been discovered
with this model over the years. Two of the main flaws are that it assumes that developers un-
derstand the full extent of the system's functionality in detail from the start and that the system
does not change after delivery.
In practice, both assumptions are typically not true. It is quite common that the design of a
system's functionality is not perfect at the start. This is often because the client, who knows the
problem domain, does not know much about computing, and because the software engineers,
who know how to program, have only limited knowledge of the problem domain.
13.6.2
Iterative development
One possibility to address the problems of the waterfall model is to use early prototyping and
frequent client interaction in the development process. Prototypes of the systems are built that
do not do much but give an impression of what the system would look like and what it would
do, and clients comment regularly on the design and functionality. This leads to a more circular
process than the waterfall model. Here, the software development iterates several times through
an
analysis-design-prototype implementation-client feedback
cycle.
Another approach is captured in the notion that good software is not designed, it is
grown
. The
idea behind this is to design a small and clean system initially and get it into a working state in
which it can be used by end users. Then additional features are gradually added (the software
grows) in a controlled manner, and “finished” states (meaning states in which the software is
completely usable and can be delivered to clients) are reached repeatedly and fairly frequently.
In reality, growing software is, of course, not a contradiction to designing software. Every
growth step is carefully designed. What the software growth model does not try to do is design
the complete software system right from the start. Even more, the notion of a complete software
system does not exist at all!
The traditional waterfall model has as its goal the delivery of a complete system. The software
growth model assumes that complete systems that are used indefinitely in an unchanged state
Search WWH ::
Custom Search