Java Reference
In-Depth Information
This list, when done in that order, has been referred to as the classic
“waterfall” model—each step is done in its entirety (or largely so) before
proceeding on to the next step.
Or at least that's the ideal which programmers have often pursued.
The problem is that the process involves people, and people, especially
those responsible for the requirements, a) are sometimes unimaginative and 2)
keep changing their minds. They start out with some requirements, based on
what they think they're going to need. But they just aren't imaginative enough
to think of how terrible their system will be for the average user. They also keep
changing their minds as to what they want.
1
The “iterative” approach has been tried as a way to address this problem.
Rather than wait for all requirements to be spelled out perfectly, with the itera-
tive approach you jump right in with what you do know, build that, but expect
changes to come. The sooner you get a working product or prototype into the
hands of the users, the sooner you'll get feedback on what works, what doesn't,
and what is really wanted (“what works” is used here not in the testing sense,
but in the usability sense).
Note, however, that in the iterative approach, one still gathers require-
ments, develops designs for the code and the tests, develops them, tests (and
fixes) the code, and releases it. It's just that one does that on a much smaller
and more rapid basis. You get something runnable sooner, and continue to
modify it.
Some people will complain that this makes for more expensive rework,
but we (and others) would disagree. You are refining the process. Your reworks
are less expensive than if you went to the work of building the entire system
only to have some key requirement(s) change—there can be a lot more
“wasteage” there.
Be aware, however, that the iterative approach is
not
just “whipping the
horses to run faster.” It is not just the waterfall model run at high speed. Rather,
it is using the early iterations of the product as a sort of a “living” requirements
specification, one that you can show to people and that they can try out, in real-
world scenarios, and on which they can give feedback. Don't expect to be able
to compile complete requirements, but don't give up on talking to your end
1. Did you notice that we tried to hint at that ever-enjoyable mid-project shifting of require-
ments as we went from a) to 2), changing our numbering scheme midway? Minimal humor,
admittedly, but if you've lived it, you understand.
