【国外标准】 Standard Guide for Rapid Prototyping of Information Systems (Withdrawn 2017)

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. 1.1 This guide covers a rapid prototyping method for developing information systems that is particularly relevant to systems for the healthcare sector. Intended readers of this guide are people who develop information systems, and students and teachers of system development methods. 1.2 Rapid prototyping is an approach to developing information systems which produce a working model more quickly than conventional approaches. Where conventional methods concentrate on preparing Requirements and design documents that describe the needed system, rapid prototyping methods concentrate on preparing a working prototype. Users and developers learn the functional requirements and an appropriate system design by interacting with a series of prototypes, each of which is rapidly produced from a starting framework or from an earlier version. A prototype can evolve into an operational system, it can serve as an exact behavioral specification of an operational system, or it can be used to explore the feasibility of a new idea or design which can be incorporated in a larger system. The method is rapid in preparing each version of the prototype, but the overall time required for system development may be more or less than the time required with conventional methods. 1.3 Rapid prototyping is most appropriate when the Requirements or design for a system are not well understood, or when experimentation is required to explore some aspect of system behavior. It is not appropriate in hazardous settings, or when the requirements are well understood. 1.4 The guide recommends use of prototyping tools, but it is not a standard for the tools themselves. It does not cover executable specification tools. Transforming a prototype that is used to clarify Requirements into an operational system is discussed briefly in Section 8 and in detail in other referenced standards (see 2.1). 1.5 This standard does not purport to address all of the safety concerns, if any, associated with its use. It is the responsibility of the user of this standard to establish appropriate safety and health practices and determine the applicability of regulatory limitations prior to use.