Prototyping: Kinds of Prototypes

As the systems analyst presenting a prototype of the information system, you are keenly interested in the reactions of users and management to the prototype. You want to know in detail how they react to working with the prototype and how good the fit is between their needs and the prototyped features of the system. Reactions are gathered through observation, interviews, and feedback sheets (possibly questionnaires) designed to elicit each person’s opinion about the prototype as he or she interacts with it.

Information gathered in the prototyping phase allows the analyst to set priorities and redirect plans inexpensively, with a minimum of disruption. Because of this feature, prototyping and planning go hand-in-hand.

Kinds of Prototypes

The word prototype is used in many different ways. Rather than attempting to synthesize all these uses into one definition or trying to mandate one correct approach to the somewhat controversial topic of prototyping, we illustrate how each of several conceptions of prototyping may be usefully applied in a particular situation, as shown in the figure illustrated below.

Patched-Up Prototype

The first kind of prototyping has to do with constructing a system that works but is patched up or patched together. In engineering this approach is referred to as breadboarding: creating a patched-together, working model of an (otherwise microscopic) integrated circuit.

An example in information systems is a working model that has all the necessary features but is inefficient. In this instance of prototyping, users can interact with the system, getting accustomed to the interface and types of output available. The retrieval and storage of information may be inefficient, however, because programs were written rapidly with the objective of being workable rather than efficient.

Nonoperational Prototype

The second conception of a prototype is that of a nonworking scale model that is set up to test certain aspects of the design. An example of this approach is a full-scale model of an automobile that is used in wind tunnel tests. The size and shape of the auto are precise, but the car is not operational. In this case only features of the automobile essential to wind tunnel testing are included.

A non-working scale model of an information system might be produced when the coding required by the applications is too extensive to prototype but when a useful idea of the system can be gained through the prototyping of the input and output only. In this instance, processing, because of undue cost and time, would not be prototyped. Users could still make decisions on the utility of the system, based on their use of prototyped input and output.

First-Of-A-Series Prototype

A third conception of prototyping involves creating a first fullscale model of a system, often called a pilot. An example is prototyping the first airplane of a series, then seeing if it flies before building a second. The prototype is completely operational and is a realization of what the designer hopes will be a series of airplanes with identical features.

This type of prototyping is useful when many installations of the same information system are planned. The full-scale working model allows users to experience realistic interaction with the new system, but it minimizes the cost of overcoming any problems that it presents. For example, when a retail grocery chain intends to use electronic data interchange (EDI) to check in suppliers’ shipments in a number of outlets, a full-scale model might be installed in one store so users could work through any problems before the system is implemented in all the others.

Selected Features Prototype

A fourth conception of prototyping concerns building an operational model that includes some, but not all, of the features that the final system will have. An analogy would be a new retail shopping mall that opens before the construction of all shops is complete.

When prototyping information systems in this way, some, but not all, essential features are included. For example, users may view a system menu on a screen that lists six features: add a record, update a record, delete a record, search a record for a key word, list a record, or scan a record. In the prototyped system, however, only three of the six may be available for use, so that the user may add a record (feature 1), delete a record (feature 3), and list a record (feature 5). User feedback can help analysts understand what is working and what isn’t. It can also help with suggestions on what features to add next.

When this kind of prototyping is done, the system is accomplished in modules so that if the features that are prototyped are evaluated by users as successful, they can be incorporated into the larger, final system without undertaking immense work in interfacing. Prototypes done in this manner are part of the actual system. They are not just a mock-up as in nonoperational prototyping considered previously. Unless otherwise mentioned, all further references to prototyping in this chapter refer to the selected-features prototype.

Prototyping as an Alternative to the SDLC

Some analysts argue that prototyping should be considered as an alternative to the SDLC. Recall that the SDLC, introduced in Chapter 1, is a logical, systematic approach to follow in the development of information systems.

Complaints about going through the SDLC process center around two interrelated concerns. The first concern is the extended time required to go through the development life cycle. As the investment of analyst time increases, the cost of the delivered system rises proportionately.

The second concern about using the SDLC is that user requirements change over time. During the long interval between the time that user requirements are analyzed and the time that the finished system is delivered, user requirements are evolving. Thus, because of the extended development cycle, the resulting system may be criticized for inadequately addressing current user information requirements.

A corollary of the problem of keeping up with user information requirements is the suggestion that users cannot really know what they do or do not want until they see something tangible. In the traditional SDLC, it often is too late to change an unwanted system once it is delivered.

To overcome these problems, some analysts propose that prototyping be used as an alternative to the SDLC. When prototyping is used in this way, the analyst effectively shortens the time between ascertainment of human information requirements and delivery of a workable system. In addition, using prototyping instead of the traditional SDLC might overcome some of the problems of accurately identifying user information requirements.

Drawbacks to supplanting the SDLC with prototyping include prematurely shaping a system before the problem or opportunity being addressed is thoroughly understood. Also, using prototyping as an alternative may result in producing a system that is accepted by specific groups of users but that is inadequate for overall system needs.

The approach we advocate here is to use prototyping as a part of the traditional SDLC. In this view prototyping is considered as an additional, specialized method for ascertaining users’ information requirements as they interact with prototypes and provide feedback for the analyst.

Contents