Page 60 -

CHAPTER 2 THE PROCESS 31

FIGURE 2.5
The prototyping
paradigm
Listen to Build/revise
customer mock-up

Customer
test drives
mock-up

a prototype. The prototype is evaluated by the customer/user and used to refine
requirements for the software to be developed. Iteration occurs as the prototype is
tuned to satisfy the needs of the customer, while at the same time enabling the devel-
When your customer
has a legitimate need oper to better understand what needs to be done.
but is clueless about Ideally, the prototype serves as a mechanism for identifying software requirements.
the details, develop a If a working prototype is built, the developer attempts to use existing program frag-
prototype as a first
step. ments or applies tools (e.g., report generators, window managers) that enable work-
ing programs to be generated quickly.
But what do we do with the prototype when it has served the purpose just
described? Brooks [BRO75] provides an answer:

In most projects, the first system built is barely usable. It may be too slow, too big, awkward
in use or all three. There is no alternative but to start again, smarting but smarter, and build
a redesigned version in which these problems are solved . . . When a new system concept
or new technology is used, one has to build a system to throw away, for even the best plan-
ning is not so omniscient as to get it right the first time. The management question, there-
fore, is not whether to build a pilot system and throw it away. You will do that. The only
question is whether to plan in advance to build a throwaway, or to promise to deliver the
throwaway to customers . . .

The prototype can serve as "the first system." The one that Brooks recommends
we throw away. But this may be an idealized view. It is true that both customers and
developers like the prototyping paradigm. Users get a feel for the actual system and