Prototyping

Prototyping

31.1 Purpose

A prototype is a working physical model of a system or a subsystem. Generally, the analyst’s (or information consultant’s) objective is to gather information about the user’s 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 uncomfortable 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 previously developed. Generally, if reaching a solution calls for simulation, experimentation, or incremental evaluation, prototyping might be a reasonable choice.

Creating a large, complex system from the bottom up can be very difficult, 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 problem 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. A prototype is an excellent tool for analyzing and designing an interactive application and/or a user interface (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, 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 system’s 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 user’s 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 conceptualizing needs, the users work with and react to the prototype and the analyst observes and interprets their reactions. To many people, manipulating 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 system’s 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 distinguished. Prototypes, in contrast, are generally created using a fourth-generation language or an application generator using a mix of programming and systems analysis skills because analysis, design, and programming 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 continuously incorporated into the system based on user feedback. Consequently, the requirements can be viewed as floating, or dynamic. In contrast, conventional 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.

Figure 31.1  Prototyping is a cyclic process.

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 generates the appropriate source or executable code from a programmer’s definition or description of a logical operation.

Prototype —

A preliminary, working, physical model of a system, a subsystem, 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.