The Internet Encyclopedia (Volume 3)

P1: 61

Nyberg WL040/Bidgoli-Vol III-Ch-11 July 11, 2003 11:49 Char Count= 0

136 PROTOTYPING

each module, followed by coding and testing of the mod-

ule itself. As development progresses, the completed mod-

ules are integrated and tested as larger and larger subsets

of the system’s overall functionality are implemented. The

integrated system is tested on the use case scenarios in the

requirements specification to ensure that the system be-

haves as expected in all possible operating environments.

As defects are discovered, updates to the system should

be carried out using a version-control system to check-

point stable working versions of the system. Once the sys-

tem has been delivered to the customer, new releases of

the software can be developed and delivered in a similar

manner, using previously frozen versions of the system as

a baseline.

THE ROLE OF PROTOTYPING IN

SOFTWARE DEVELOPMENT

A typical prototype system will involve some level of de-

velopment in all of the life-cycle activities (requirements,

analysis, design, implement, and testing). How much em-

phasis is given to each life-cycle activity depends on the

type of prototype to be constructed and the goals of the

prototyping exercise. This section describes the different

approaches to prototyping and provides some reasons

that prototyping can be a useful first step in system de-

velopment.

Approaches to Prototyping

The software components created in a prototyping exer-

cise may or may not be part of a full-scale implementation,

but a prototype should demonstrate some subset of the de-

sired functionality and user interface. Prototypes can be

classified into two broad categories: evolutionary proto-

types and throwaway prototypes (Pressman, 2001). Each

approach has specific advantages and disadvantages, de-

pending on the goals of the prototyping exercise.

Throwaway Prototyping

Athrowaway prototypeis constructed to demonstrate a

simulated capability or user interface, but the software is

not intended for use in the final system. Throwaway pro-

totypes can be constructed quickly, using scripting lan-

guages (e.g., PERL, Javascript) that may not be suitable

for large-scale production. The advantage of a throwaway

prototype is that it can be done quickly as a “proof of

concept”; such prototypes can be very useful to stimulate

discussion with the customer regarding detailed require-

ments. However, time spent on a throwaway prototype

typically does not result in code that can be reused in a

full-scale system, so excessive effort spent on a throwaway

prototype can be wasteful.

Evolutionary Prototyping

Building anevolutionary prototypeinvolves the analysis,

design, and implementation of software modules that are

intended for use in the final version of the system when

it is constructed. An evolutionary prototype might there-

fore require a significant amount of development (both in

time and in programming resources). The advantage of

an evolutionary prototype is that “no code is wasted”; it is

assumed that most of the effort put into the prototype will

result in reusable code that will become part of the final

system. However, an early investment in reusable code

might not be justified, if the requirements or technology

are not yet well understood.

Prototyping PROs and CONs

In an effort to streamline development schedules and

minimize development costs, a project manager may be

tempted to re-use code built during a throwaway proto-

typing exercise. This can wreak havoc on the development

of a full-scale system, because a throwaway prototype may

have been coded quickly, with no attention to proper anal-

ysis, design, or careful implementation. The platform used

for a throwaway prototype may be completely inappro-

priate for a full-scale production system. For example, a

throwaway prototype might be constructed using PERL

scripts, flat data files, and hand-coded HTML, where a

production-quality system might require the use of a ses-

sion architecture, a relational database, and dynamically

generated Web pages. Another characteristic of proto-

types is that they almost always leave out certain functions

or capabilities of the full-scale system. A prototype design

that encompasses only a subset of the desired functional-

ity may not be easy to extend to a full implementation. For

example, a prototype which delivers Web content in a sin-

gle language might not utilize a design that supports easy

extension for multilingual content; if the full-scale system

requires localization for several countries and languages,

it will be necessary to re-design the data architecture for

a full-scale system. In general, if the requirements aren’t

well understood at the outset, or the technology is new

for the development team, then a throwaway prototype

is appropriate, but management must be sensitive to the

risks associated with reuse.

On the other hand, it may be tempting to declare that

all prototyping will be of the evolutionary variety, so that

“no effort will be wasted.” This is a mistake if the problem

or the technology isn’t well understood, because the analy-

sis and design may incorporate defects or misunderstand-

ings that should be resolved before a full-scale system is

built. When the team is experienced with the problem do-

main and the software technology, this risk is reduced,

but it can be difficult to guarantee future reuse before

construction and test of an initial system. When a new

category of system is constructed for the fist time, proto-

typing becomes part of a “generate and test” paradigm for

system design; design ideas are formulated and initial sys-

tems constructed as a means of evaluating tentative design

decisions. In general, when the requirements aren’t well

documented, it is usually more appropriate to construct

a throwaway prototype that can serve as the basis for a

customer review and discussion regarding the emerging

requirements and system design.

Why Do We Do Prototyping?

There are a variety of reasons to construct a prototype;

most involve a desire to better understand the problem

domain, the user’s requirements, the technology to be

used, or the trade-offs inherent in various system de-

sign choices (technology, architecture, etc.). Prototyping