ASTM E1340-96
(Guide)Standard Guide for Rapid Prototyping of Computerized Systems
Standard Guide for Rapid Prototyping of Computerized Systems
SCOPE
1.1 This guide covers a rapid prototyping method for developing computerized systems. Intended readers of this guide are people who develop computerized systems, and students and teachers of system development methods.
1.2 Rapid prototyping is an approach to developing computerized systems which produces a working model more quickly than conventional approaches. Where conventional methods concentrate on preparing functional requirements and functional 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 functional requirements or functional 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 This 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.
General Information
Relations
Standards Content (Sample)
NOTICE: This standard has either been superseded and replaced by a new version or withdrawn.
Contact ASTM International (www.astm.org) for the latest information
An American National Standard
Designation:E1340–96
Standard Guide for
Rapid Prototyping of Computerized Systems
This standard is issued under the fixed designation E 1340; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (e) indicates an editorial change since the last revision or reapproval.
1. Scope 2. Referenced Documents
1.1 This guide covers a rapid prototyping method for 2.1 ASTM Standards:
developing computerized systems. Intended readers of this E 622 Guide for Developing Computerized Systems
guide are people who develop computerized systems, and E 625 Guide for Training Users of Computerized Systems
students and teachers of system development methods. E 627 Guide for Documenting Computerized Systems
1.2 Rapid prototyping is an approach to developing com- E 731 Guide for the Selection and Acquisition of Commer-
puterized systems which produces a working model more cially Available Computerized Systems
quickly than conventional approaches. Where conventional E 919 Specification for Software Documentation for a
methods concentrate on preparing functional requirements and Computerized System
functional design documents that describe the needed system, E 1013 Terminology Relating to Computerized Systems
rapid prototyping methods concentrate on preparing a working E 1029 Guide for Documentation of Clinical Laboratory
prototype. Users and developers learn the functional require- Computer Systems
ments and an appropriate system design by interacting with a 2.2 ANSI Standards:
series of prototypes, each of which is rapidly produced from a ANSI/MIL-STD-1815A Ada Programming Language
starting framework or from an earlier version.Aprototype can ANSI/X3.9 Programming Language FORTRAN
evolve into an operational system, it can serve as an exact ANSI/X3.159 Programming Language C
behavioral specification of an operational system, or it can be ANSI/X11.1 MUMPS Programming Language
used to explore the feasibility of a new idea or design which ANSI/IEEE 729 Glossary of Software Engineering Termi-
can be incorporated in a larger system. The method is rapid in nology
preparing each version of the prototype, but the overall time ANSI/IEEE 770 X3.97 Pascal Programming Language
required for system development may be more or less than the ANSI/IEEE 1063 User Documentation for Computer Soft-
time required with conventional methods. ware
1.3 Rapid prototyping is most appropriate when the func-
3. Terminology
tional requirements or functional design for a system are not
well understood, or when experimentation is required to 3.1 Definitions—For definitions of terms relating to com-
puterizedsystems,refertoTerminologyE 1013,IEEE729,and
explore some aspect of system behavior. It is not appropriate in
hazardous settings, or when the requirements are well under- ANDIP.
3.1.1 fourth generation language, n—a high-level computer
stood.
1.4 Theguiderecommendsuseofprototypingtools,butitis language that incorporates data structures and procedures for a
specific problem domain.
not a standard for the tools themselves. It does not cover
executable specification tools.Transforming a prototype that is 3.1.2 prototype, n—an original or model from which a
system is copied.
used to clarify requirements into an operational system is
discussed briefly in Section 8 and in detail in other referenced 3.1.3 prototype, v—to create an original or model.
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 appro-
priate safety and health practices and determine the applica-
bility of regulatory limitations prior to use.
Annual Book of ASTM Standards, Vol 14.01.
Available from American National Standards Institute, 11 W. 42nd St., 13th
Floor, New York, NY 10036.
1 4
This guide is under the jurisdiction of ASTM Committee E31 on Healthcare Available from the Institute of Electrical and Electronics Engineers, Inc., 345
Informatics and is the direct responsibility of Subcommittee E31.23 on Modeling E. 47th Street, New York, NY 10017.
for Health Informatics. American National Dictionary for Information Processing Systems, Informa-
Current edition approved Oct. 10, 1996. Published December 1996. Originally tion Processing Systems Technical Report X3/TR-1-82, Dow Jones-Irwin, Home-
published as E 1340 – 90. Last previous edition E 1340 – 91. wood, IL.
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959, United States.
E1340–96
3.1.4 prototyping, n—the activities that create an original or a tool for clarifying functional requirements for the operational
model. system, as a means of evaluating a design approach, or as a
3.1.5 rapid prototyping, n—an iterative method for devel- developing series of versions of the operational system. A
oping prototypes of components, subsystems, or complete prototype is sometimes used as an exact behavioral specifica-
computerized systems, in which the time between successive tion for an operational system which replaces it. Quality
versions of the prototype is short. characteristics are often sacrificed during RP for the sake of
3.1.6 RP, n—rapid prototyping. rapid development and low cost; robustness, efficiency, gener-
3.1.7 third generation language, n—a procedural high-level ality, portability, and maintainability are commonly ignored.
computer language, such as COBOL, FORTRAN, or Pascal. However, documentation needed to use the system cannot be
ignored.
4. Significance and Use
4.1.1 Rapid in RP means that the time between successive
4.1 Rapid Prototyping (RP) is a way to develop a comput- versions of the prototype is short. It should be short enough
erized system which produces a working model of the system that (1) both users and developers can remember how each
very quickly. The RP process shown in Fig. 1 has many version relates to the previous one without written notes, (2)
similarities, and some differences from the conventional sys- user requirements do not change significantly while a version
tem development process shown in Fig. 2. RP replaces the is being developed, (3) the prototyping team will remain in the
functional requirements and functional design phases of the project through the RPphase, and ( 4) total time to develop the
conventional method with an iterative process of prototype system is acceptable. (Expected project duration should be
refinement. Where the phases of the conventional method stated in the project definition agreement. See Section 6 and
produce a set of documents that describe the system, RP Guide E 622, Section 6.) A few days between versions is
produces a prototype. The prototype is tested and refined adequate and a few weeks may be acceptable. If the time
through several iterations, with intense interaction between needed to produce a new version is longer, then it may be
system users and developers. RP is an experimental approach necessary to produce that version using a conventional system
to system development which provides a learning device, the development method (for example, Guide E 622) with full
prototype, for users and developers.Aprototype can be used as documentation of requirements and design (seeAppendix X3).
FIG. 1 Rapid Prototyping of a Computerized System
E1340–96
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.
A RAPID PROTOTYPING METHOD
5. Introduction
5.1 The following sections describe a system development
method that uses RP. It is based on, and shares some features
with, the method described in Guide E 622 and other ASTM
standards which are listed in 2.1. Instead of producing docu-
ments that describe functional requirements (Guide E 622,
Section 7), functional design (Guide E 622, Section 8), and
implementation design (Guide E 622, Section 9) for the re-
quired system, this method produces a prototype of the system
andrefinesitthroughaniterativeprocessofanalysis,synthesis,
and evaluation.
6. Project Definition
6.1 Inanysystemdevelopmentproject,whetherdonebyRP
or conventional means, it is important to have a definition of
what is to be accomplished, when, where, why, by whom, and
for about how much effort. It is also important to identify
FIG. 2 Conventional Development of a Computerized System
everyone who must be satisfied with the results, and especially
everyonewhowillusethesystem.Thesethingsaredetermined
in the preliminary discussions and negotiations about a project.
4.1.2 RP integrates analysis, design and construction, and
A written statement of them is a project definition document.
defines requirements during the process. It is especially appro-
Guide E 622, Section 6 says that a project definition is an
priate for dealing with problems which are not well under-
agreement among everyone involved with a project. Agree-
stood. The prototype focuses communication between users
ment on project goals is essential for project success.
and developers.
6.2 A project definition should be in writing. A written
4.2 For large systems, a RP approach can be used at a high
document is concrete and changes to it are explicit. A written
level to explore the overall system architecture or feasibility. It
project definition does not drift like a verbal one. As new
canalsobeusedtodevelopsubsystemsandcomponentswhose
requirements are not fully understood (see Section 11). RP is people become involved with the project, they can read the
original document and can either become parties to it or
especially well suited for developing user-system interfaces.
renegotiate it.
4.2.1 What to Prototype—The ill-structured system devel-
6.3 The project definition document should be brief, pref-
opment problems that yield best to RP include:
4.2.1.1 Decision support systems in areas where the state of erably no more than one page. If it exceeds two pages, provide
a one page summary.
knowledge changes rapidly, for example, research or clinical
practice, 6.4 The project definition document should state what is to
4.2.1.2 Systems whose users need to access and organize be prototyped and it should be specific about the goals of the
data in ways not foreseen when the system is created, for project. If a prototype is to be developed to learn the true
example, strategic decision support, requirements for a system, the project definition should say so.
4.2.1.3 Systems that consist entirely of software, If a prototype is to explore feasibility of a new idea or design,
4.2.1.4 Instructional or experimental systems, and that should be stated in the project definition. The project
4.2.1.5 User-system interfaces. definition document should say whether the prototype is to
4.2.2 Ways to use RP—Three ways that are widely used are evolve into an operational version, or is to be replaced by an
(1) evolutionary, ( 2) experimental, and (3) build-and-replace. operational version which is to be rebuilt from scratch. If this
In evolutionary prototyping, the developers rapidly produce an is not known at the start of the project, then the project
initial version as a framework to learn user requirements, and definition should state the criteria for deciding.
E1340–96
6.5 The project definition document should briefly say what 7.3.5 If the prototype is to evolve into the operational
functionstheprototypeistoperform.Itshouldclarifyandlimit system, then the RP language should have reasonable effi-
the scope of the project, the prototype, and the system that is to ciency. MUMPS (ANSI X11.1), LISP, and APL are widely
be based on the prototype. used RP languages. These languages make RP easier than
strongly typed languages like Pascal (ANSI/IEEE 770 X3.97)
6.6 Everyone involved with the project should indicate
agreement by signing the project definition document, or the and Ada (ANSI/MIL-STD 1815A).
one page summary of it. 7.3.6 General purpose third generation programming lan-
guageslikeFORTRAN(ANSIX3.9)andC(ANSIX3.159)are
not appropriate for RPunless powerful libraries can be used to
7. Tool Selection
eliminate the bulk of the programming effort. These languages
7.1 The project definition and users’ preliminary statements
may be useful if the prototype is to evolve into an operational
about what the system needs to do, guide the developers in
system, but they are not appropriate for RPunless a large body
selecting appropriate RP tools. The initial choice is crucial
of code is available and well-suited for reuse in the prototype.
because it immediately constrains what can be accomplished.
These languages may also be useful in an environment where
By selecting the right tools, the developers minimize the time
the prototype can use several languages, and language selec-
and effort required for each RP cycle and maximize the
tion is less critical.
likelihood of success. If the wrong tools are selected, then the
7.4 RP is especially useful for developing user-system
project may be immediately doomed to failure. Most of the
interfaces, even when other system functions are developed by
tools discussed in this section are software tools, that is,
a conventional approach. Mock-ups and simulators are power-
computer programs, but the principles also apply to hardware
ful tools for exploring how people will use a system to
tools.
accomplish their tasks. The interface between a system and its
7.2 Good tools for RP share the following characteristics:
users can determine whether the system is accepted and
7.2.1 They help produce the prototype quickly,
successful.Tools for prototyping user-system interfaces should
7.2.2 They allow changes to the prototype to be made
allow system developers to describe dialog attributes and style
quickly,
in plain language. These kinds of tools are useful for RP of
7.2.3 They are general enough to permit more than one
user-system interfaces:
solution to most problems,
7.4.1 Screen managers, screen layout simulators, and forms
7.2.4
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.