1999 by CRC Press LLC

chapter thirty-one
Prototyping
William S. Davis and David C. Yen
Contents
31.1 Purpose
31.2 Strengths, weaknesses, and limitations
31.3 Inputs and related ideas
31.4 Concepts
31.4.1 The prototyping process
31.4.2 Prototyping versus conventional approaches
31.5 Key terms
31.6 Software
31.7 References
31.1 Purpose
A prototype is a working physical model of a system or a subsystem.
Generally, the analysts (or information consultants) objective is to gather
information about the users requirements from the bottom up by allowing
the user to interact with the prototype. In effect, the prototype serves as a
preliminary version of the system or component from which requirements
are extracted and on which subsequent versions are based.
31.2 Strengths, weaknesses, and limitations
A prototype is an excellent tool for analyzing and designing an interactive
application and/or a user interface and to support object-oriented system
development. During the analysis stage, prototyping can be used to replace
or supplement logical modeling, particularly when the users are uncomfort-
able with abstract models. Prototyping is valuable on projects with long
development times because the user gets to see something physical.
Prototyping is an excellent tool when the requirements are highly uncertain
or too abstract to specify, or when no comparable system has been previ-
ously developed. Generally, if reaching a solution calls for simulation, exper-
imentation, or incremental evaluation, prototyping might be a reasonable
choice.
Creating a large, complex system from the bottom up can be very diffi-
cult, and integrating subsystem prototypes can prove almost impossible
because there is no clear way (short of a parallel top-down logical or data
model) to visualize subsystem relationships. Prototyping is not a good
choice for algorithm-driven projects that involve heavy calculation.
Prototyping can bias the systems analysis process in subtle ways.
Because the prototype is developed on a computer, the system will almost
certainly be implemented on a computer and manual alternatives are
unlikely to be considered. Because it is a working model, people will
inevitably think of the prototype as the solution. A related danger is that
the system will never be developed properly because the prototype seems
too good.
Prototypes generally lack security, auditing, and other controls (Chapter
77), and data integrity may be difficult to ensure. Additionally, prototypes
are often inefficient and difficult to maintain. For example, it is difficult to
trace the ripple effects that result from modifying a prototype, and that
affects maintainability. Economy of scale is another problem; prototypes that
test well sometimes fail when the number of users is dramatically increased.
31.3 Inputs and related ideas
Before creating a prototype, it is necessary to at least partially define the prob-
lem and gather preliminary information (Part II). Also, it may be necessary to
perform a preliminary analysis (Part IV) and/or create logical models to help
plan and (later) to supplement the prototype. Aprototype is an excellent tool
for analyzing and designing an interactive application and/or a user inter-
face (Chapter 48) and to support object-oriented system development
(Chapters 29 and 66). During the analysis stage, prototyping can be used to
replace or supplement logical modeling (Chapters 24, 26, and 28). Variations
on the standard prototyping approach include evolutionary prototyping,
incremental prototyping, and middle-out prototyping (Chapter 72).
31.4 Concepts
Prototyping is a powerful, bottom up alternative or supplement to logical
modeling. The basic idea is to build a reasonably complete, working,
1999 by CRC Press LLC
physical model (or prototype) of the system. As a minimum, the analyst can
use screen painters, menu builders, and report generators to prepare a slide
show of sample screens (Chapter 46), dialogues (Chapter 49), and reports
(Chapter 47). In a more complete prototype, preliminary working versions
of the systems programs are created using a fourth-generation language,
spreadsheets, database software, or a similar end-user tool.
31.4.1 The prototyping process
The prototyping process can be viewed as a loop (Figure 31.1). Following
problem definition and preliminary analysis, a first draft of the prototype is
created. The user then interacts with the prototype and identifies its
strengths and weaknesses. Assuming that the first draft is less than totally
acceptable, the prototype is modified to reflect the users suggestions and
the user interacts with the new, improved version. The refine-and-test cycle
continues until the user is satisfied that the prototype meets his or her
requirements.
During the refine-and-test cycle, the emphasis is on quick turnaround,
with changes made on the spot or within at most a few days. Instead of con-
ceptualizing needs, the users work with and react to the prototype and the
analyst observes and interprets their reactions. To many people, manipulat-
ing a working model seems more natural than answering questions in an
interview or trying to link an abstract model to reality.
Sometimes, the prototyping process continues until a finished system
emerges. Usually, however, the purpose of the prototype is to clarify the sys-
tems requirements. The tasks and queries performed by the prototype
demonstrate what the system must do and translate into processes. Screens,
dialogues, menus, reports, files, and databases map to the required logical
data structures. Once the requirements are defined (Chapter 35), design
begins and the prototype is discarded.
Variations on the standard prototyping approach include evolutionary
prototyping, incremental prototyping, and middle-out prototyping
(Chapter 73).
31.4.2 Prototyping vs. conventional approaches
Conventional systems analysis and design relies on various models of the
system, and the logical analysis and physical design stages are clearly dis-
tinguished. Prototypes, in contrast, are generally created using a fourth-
generation language or an application generator using a mix of program-
ming and systems analysis skills because analysis, design, and program-
ming activities are often intermixed and difficult to distinguish.
Prototyping is (by its very nature) iterative. The process starts with a set
of partial requirements, and new or expanded requirements are contin-
uously incorporated into the system based on user feedback. Consequently,
1999 by CRC Press LLC
1999 by CRC Press LLC
Figure 31.1 Prototyping is a cyclic process.
the requirements can be viewed as floating, or dynamic. In contrast, con-
ventional systems analysis and design calls for a full and complete set of
requirements, and the requirements are typically frozen at the end of each
stage in the system development life cycle.
31.5 Key terms
Application generator (generator, program generator) A program
that starts with information in graphical, narrative, list, or some other
logical form and generates the appropriate source or executable code.
Fourth-generation language A non-procedural language that gener-
ates the appropriate source or executable code from a programmers
definition or description of a logical operation.
Prototype Apreliminary, working, physical model of a system, a sub-
system, or a program.
Prototyping The act of creating a prototype.
31.6 Software
Many CASE products support prototyping. Screen painters, menu builders,
report generators, fourth-generation languages, executable specification
languages, spreadsheets, and database management programs are popular
prototyping tools.
31.7 References
1. Boar, B., Application Prototyping. A Requirements Strategy for the 80s, John Wiley
& Sons, New York, 1984.
2. Brathwaite, K. S., Applications Development Using CASE Tools, Academic Press,
San Diego, CA, 1990.
3. Davis, W. S., Business Systems Analysis and Design, Wadsworth, Belmont, CA,
1994.
1999 by CRC Press LLC