Rapid Prototyping (RP) is a specific Life Cycle Model used to develop an information system which produces a working model of the system very quickly. The RP process shown in Fig. 1 has many similarities, and some differences from the conventional system (Waterfall Life Cycle Model) development process shown in Fig. 2. RP replaces the Requirements and Design processes of the conventional method with an iterative process of prototype refinement. Where the phases of the conventional method produce a set of documents that describe the system, RP produces a prototype. The prototype is tested and refined through several iterations, with intense interaction between system users and developers. RP is an experimental approach to system development which provides a learning device, the prototype, for users and developers. A prototype can be used as a tool for clarifying Requirements for the operational system, as a means of evaluating a design approach, or as a developing series of versions of the operational system. A prototype is sometimes used as an exact behavioral specification for an operational system which replaces it. Quality characteristics are often sacrificed during RP for the sake of rapid development and low cost; robustness, efficiency, generality, portability, and maintainability are commonly ignored but none of these aspects need to be neglected. However, documentation needed to use the system cannot be ignored but none of these aspects need to be neglected. A "Throwaway" prototype is used specifically to define Requirements which are used to implement a final system. An "Evolutionary" prototype is a prototypical system used for ongoing refinement of Requirements while operational versions at specific milestones are used in production settings.

Rapid in RP means that the time between successive versions of the prototype is relatively short. It should be short enough that (1) both users and developers can remember how each version relates to the previous one without written notes, (2) user requirements do not change significantly while a version is being developed, (3) the prototyping team will remain in the project through the RP phase, and (4) total time to develop the system is acceptable. (Expected project duration should be stated in the project management planning document. See Section 6 and ANSI/IEEE 1058 and ANSI/IEEE 1074.) A few days between versions is adequate and a few weeks may be acceptable. If the time needed to produce a new version is longer, then it may be necessary to produce that version using a conventional system development method with full documentation of requirements and design (see Appendix X3).

RP integrates analysis, design and construction, and defines Requirements during the process. It is especially appropriate for dealing with problems which are not well understood or are rapidly changing. The prototype focuses communication between users and developers.

For large systems, a RP approach can be used at a high level to explore the overall system architecture or feasibility. It can also be used to develop subsystems and components whose requirements are not fully understood (see Section 11). RP is especially well suited for developing user-system interfaces.

What to Prototype-The ill-structured system development problems that yield best to RP include:

Decision support systems in areas where the state of knowledge changes rapidly, for example, research or clinical practice,

Systems whose users need to access and organize data in ways not foreseen when the system is created, for example, strategic decision support and exploration of cognitive processes,

Systems that consist entirely of software,

Instructional or experimental systems, and

User-system interfaces.

Ways to use RP-Three ways that are widely used are (1) evolutionary, ( 2) experimental, and (3) build-and-replace. In evolutionary prototyping, the developers rapidly produce an initial version as a framework to learn user requirements, and then satisfy the requirements incrementally through a series of versions to produce the operational system. In experimental prototyping, the developers explore the feasibility of selected capabilities or components with a series of versions that serve to test concepts and designs. In build-and-replace prototyping, the developers assemble a series of versions to establish what the system should do and how it should do it, then the prototype is used as a behavioral specification for building the operational system. Build-and-replace is sometimes called throw-away prototyping, but the prototype should not be thrown away.