Java Reference
In-Depth Information
In an ideal world the waterfall model has a lot of appeal: You figure out what to do;
then you figure out how to do it; then you do it; then you verify that you did it right;
then you hand the product to the customer. When rigidly applied, though, the
waterfall model simply did not work. It was very
difficult to come up with a perfect
requirement specification. It was quite common
to discover in the design phase that
the requirements were inconsistent or that a small change in the requirements would
lead to a system that was both easier to design and more useful for the customer, but
the analysis phase was over, so the designers had no choiceČthey had to take the
existing requirements, errors and all. This problem would repeat itself during
implementation. The designers may have thought they knew how to solve the
problem as efficiently as possible, but when the design was actually implemented, it
turned out that the resulting program was not as fast as the designers had thought. The
next transition is one with which you are surely familiar. When the program was
handed to the quality assurance department for testing, many bugs were found that
would best be fixed by reimplementing, or maybe even redesigning, the program, but
the waterfall model did not allow for this. Finally, when the customers received the
finished product, they were often not at all happy with it. Even though the customers
typically were very involved in the analysis phase, often they themselves were not
sure exactly what they needed. After all, it can be very difficult to describe how you
want to use a product that you have never seen before. But when the customers
started using the program, they began to realize what they would have liked. Of
course, then it was too late, and they had to live with what they got.
531
532
The spiral model of software development describes an iterative process in which
design and implementation are repeated.
