ASTM E1340-05(2010)
(Guide)Standard Guide for Rapid Prototyping of Information Systems (Withdrawn 2017)
Standard Guide for Rapid Prototyping of Information Systems (Withdrawn 2017)
SIGNIFICANCE AND USE
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 on...
SCOPE
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 co...
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
Designation: E1340 − 05 (Reapproved 2010) An American National Standard
Standard Guide for
Rapid Prototyping of Information Systems
This standard is issued under the fixed designation E1340; 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 (´) indicates an editorial change since the last revision or reapproval.
1. Scope responsibility of the user of this standard to establish appro-
priate safety and health practices and determine the applica-
1.1 This guide covers a rapid prototyping method for
bility of regulatory limitations prior to use.
developing information systems that is particularly relevant to
systemsforthehealthcaresector.Intendedreadersofthisguide
2. Referenced Documents
are people who develop information systems, and students and
teachers of system development methods.
2.1 ANSI Standards:
1.2 Rapid prototyping is an approach to developing infor- ANSI/MIL-STD-1815A Ada Programming Language
mation systems which produce a working model more quickly ANSI X3.9 Programming Language FORTRAN
than conventional approaches. Where conventional methods ANSI X3.159 Programming Language C
concentrate on preparing Requirements and design documents ANSI/X11.1 MUMPS Programming Language
that describe the needed system, rapid prototyping methods ANSI/IEEE 610.12 Glossary of Software Engineering Ter-
concentrate on preparing a working prototype. Users and minology
developers learn the functional requirements and an appropri- ANSI/IEEE 770 X3.97 Pascal Programming Language
ate system design by interacting with a series of prototypes, ANSI/IEEE 830 Recommended Practice for Software Re-
eachofwhichisrapidlyproducedfromastartingframeworkor quirement Specifications
from an earlier version. A prototype can evolve into an ANSI/IEEE 1016 Recommended Practice for Software De-
sign Descriptions
operational system, it can serve as an exact behavioral speci-
fication of an operational system, or it can be used to explore ANSI/IEEE 1058 Standard for Software Project Manage-
ment Plans
the feasibility of a new idea or design which can be incorpo-
rated in a larger system. The method is rapid in preparing each ANSI/IEEE 1059 Guide for Software Verification and Vali-
dation Plans
version of the prototype, but the overall time required for
system development may be more or less than the time ANSI/IEEE 1063 User Documentation for Computer Soft-
required with conventional methods. ware
ANSI/IEEE 1074 Software Life Cycle Processes
1.3 Rapid prototyping is most appropriate when the Re-
quirements or design for a system are not well understood, or 2.2 ISO Standards:
when experimentation is required to explore some aspect of IS 12207 Information Technology-Software Life Cycle Pro-
system behavior. It is not appropriate in hazardous settings, or cesses
IS 15288 System Life Cycle Processes
when the requirements are well understood.
IS 15440 Guide for Life Cycle Processes
1.4 Theguiderecommendsuseofprototypingtools,butitis
IS 11756 MUMPS Programming Language
not a standard for the tools themselves. It does not cover
executable specification tools. Transforming a prototype that is
3. Terminology
used to clarify Requirements into an operational system is
discussed briefly in Section 8 and in detail in other referenced 3.1 Definitions—
standards (see 2.1). 3.1.1 For definitions of terms relating to information
systems, refer to ANDIP and ANSI/IEEE 610.12.
1.5 This standard does not purport to address all of the
safety concerns, if any, associated with its use. It is the
Available from American National Standards Institute (ANSI), 25 W. 43rd St.,
This guide is under the jurisdiction of ASTM Committee E31 on Healthcare 4th Floor, New York, NY 10036, http://www.ansi.org.
Informatics and is the direct responsibility of Subcommittee E31.25 on Healthcare Available from Institute of Electrical and Electronics Engineers, Inc. (IEEE),
Data Management, Security, Confidentiality, and Privacy. 445 Hoes Ln., P.O. Box 1331, Piscataway, NJ 08854-1331, http://www.ieee.org.
Current edition approved March 1, 2010. Published August 2010. Originally American National Dictionary for Information Processing Systems, Informa-
approved in 1990. Last previous edition approved in 2005 as E1340–05. DOI: tion Processing Systems Technical Report X3/TR-1-82, Dow Jones-Irwin,
10.1520/E1340-05R10. Homewood, IL.
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United States
E1340 − 05 (2010)
3.1.2 fourth generation language, n—a high-level computer of the conventional method produce a set of documents that
language that incorporates data structures and procedures for a describe the system, RPproduces a prototype.The prototype is
specific problem domain.
tested and refined through several iterations, with intense
interaction between system users and developers. RP is an
3.1.3 prototype, n—an original or model from which a
experimental approach to system development which provides
system is copied.
a learning device, the prototype, for users and developers. A
3.1.4 prototype, v—to create an original or model.
prototype can be used as a tool for clarifying Requirements for
3.1.5 prototyping, n—the activities that create an original or
the operational system, as a means of evaluating a design
model.
approach, or as a developing series of versions of the opera-
3.1.6 rapid prototyping, n—an iterative method for devel-
tional system. A prototype is sometimes used as an exact
oping prototypes of components, subsystems, or complete
behavioral specification for an operational system which re-
computerized systems, in which the time between successive
places it. Quality characteristics are often sacrificed during RP
versions of the prototype is short.
for the sake of rapid development and low cost; robustness,
efficiency, generality, portability, and maintainability are com-
3.1.7 RP, n—rapid prototyping.
monly ignored but none of these aspects need to be neglected.
3.1.8 third generation language, n—a procedural high-level
However, documentation needed to use the system cannot be
computer language, such as COBOL, FORTRAN, or Pascal.
ignored but none of these aspects need to be neglected. A
4. Significance and Use “Throwaway” prototype is used specifically to define Require-
ments which are used to implement a final system. An
4.1 Rapid Prototyping (RP) is a specific Life Cycle Model
“Evolutionary” prototype is a prototypical system used for
used to develop an information system which produces a
ongoing refinement of Requirements while operational ver-
working model of the system very quickly. The RP process
sions at specific milestones are used in production settings.
shown in Fig. 1 has many similarities, and some differences
from the conventional system (Waterfall Life Cycle Model) 4.1.1 Rapid in RP means that the time between successive
versions of the prototype is relatively short. It should be short
development process shown in Fig. 2. RPreplaces the Require-
ments and Design processes of the conventional method with enough that (1 ) both users and developers can remember how
an iterative process of prototype refinement. Where the phases each version relates to the previous one without written notes,
FIG. 1 Rapid Prototyping of An Information System
E1340 − 05 (2010)
4.2.1.1 Decision support systems in areas where the state of
knowledge changes rapidly, for example, research or clinical
practice,
4.2.1.2 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 cogni-
tive processes,
4.2.1.3 Systems that consist entirely of software,
4.2.1.4 Instructional or experimental systems, and
4.2.1.5 User-system interfaces.
4.2.2 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.
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
FIG. 2 Conventional Development of An Information System
with, the methods described inANSI/IEEE 1074 and other ISO
and IEEE standards which are listed in 2.1 (See IS 15440).
Instead of producing documents that describe Requirements
(2) user requirements do not change significantly while a
(ANSI/IEEE 830, Section 7), or Designs (ANSI/IEEE 1016)
version is being developed, (3) the prototyping team will
for the required system, this method produces a prototype of
remain in the project through the RP phase, and (4 ) total time
the system and refines it through an iterative process of
to develop the system is acceptable. (Expected project duration
analysis, synthesis, and evaluation.
should be stated in the project management planning docu-
ment. See Section 6 and ANSI/IEEE 1058 and ANSI/IEEE
6. Project Definition
1074.) A few days between versions is adequate and a few
6.1 Inanysystemdevelopmentproject,whetherdonebyRP
weeks may be acceptable. If the time needed to produce a new
or conventional means, it is important to have a definition of
version is longer, then it may be necessary to produce that
what is to be accomplished, when, where, why, by whom, and
version using a conventional system development method with
for about how much effort. It is also important to identify
full documentation of requirements and design (see Appendix
everyone who must be satisfied with the results, and especially
X3).
everyone who will use the system.These things are determined
4.1.2 RP integrates analysis, design and construction, and
in the preliminary discussions and negotiations about a project.
defines Requirements during the process. It is especially
A written statement of them is a Project Management Plan
appropriate for dealing with problems which are not well
(PMP,seeANSI/IEEE1058)document.AProjectManagement
understood or are rapidly changing. The prototype focuses
Plan is an agreement among everyone involved with a project.
communication between users and developers.
Agreement on project goals is essential for project success.
4.2 For large systems, a RP approach can be used at a high
level to explore the overall system architecture or feasibility. It 6.2 A Project Management Plan must be in writing. A
canalsobeusedtodevelopsubsystemsandcomponentswhose written document is concrete and changes to it are explicit and
requirements are not fully understood (see Section 11). RP is documented.Awritten PMPdoes not drift like a verbal one.As
especially well suited for developing user-system interfaces. new people become involved with the project, they can read
4.2.1 What to Prototype—The ill-structured system devel- the original document and can either become parties to it or
opment problems that yield best to RP include: renegotiate it.
E1340 − 05 (2010)
6.3 The PMP document should be brief, and structured members to use descriptive techniques that they use with
preferably no more than a few pages. If it exceeds several human colleagues, that is, graphic, tabular, and other non-
pages, provide a one page summary. verbal techniques.
7.3.3 Tools that make the job easy for an inexperienced
6.4 The PMP document should state what is to be proto-
person may be tedious for a skilled system engineer. There
typed and it should be specific about the goals of the project. If
shouldbeatersedialogmodefortheexperienceduserwhocan
aprototypeistobedevelopedtolearnthetruerequirementsfor
abstract more features than the inexperienced user.
a system, the project definition should say so. If a prototype is
7.3.4 Good languages for RP are usually directly executed
to explore feasibility of a new idea or design, that should be
or interpreted in some fashion. The ideal language for an
stated.The PMPdocument should say whether the prototype is
evolutionary prototype would fit the problem domain, would
to evolve into an operational version, or is to be replaced by an
have an interpretive processor with good diagnostic facilities,
operational version which is to be rebuilt from scratch. If this
and would be compilable (for efficiency of the operational
is not known at the start of the project, then the PMP should
version).
state the criteria for deciding.
7.3.5 If the prototype is to evolve into the operational
6.5 The PMP document should briefly say what functions
system, then the RP language should have reasonable effi-
theprototypeistoperform.Itshouldclarifyandlimitthescope
ciency. MUMPS (ANSI/X11.1, IS 11756), LISP, Pyton, Ruby,
of the project, the prototype, and the system that is to be based
Perl, Scheme, PHP, and APL are widely used RP languages.
on the prototype.
These languages make RPeasier than strongly typed languages
6.6 Everyone involved with the project should indicate like Pascal (ANSI/IEEE 770 X3.97) and Ada (ANSI/MIL-
STD-1815A).
agreement by signing the PMP document, or the one page
summary of it. 7.3.6 General purpose third generation programming lan-
guageslikeFORTRAN(ANSIX3.9)andC(ANSIX3.159)are
7. Tool Selection
not appropriate for RPunless powerful libraries can be used to
eliminate the bulk of the programming effort. These languages
7.1 The PMP and the users’ preliminary statements about
may be useful if the prototype is to evolve into an operational
what the system needs to do, guide the developers in selecting
system, but they are not appropriate for RPunless a large body
appropriate RP tools. The initial choice is crucial because it
of code is available and well-suited for reuse in the prototype.
immediately constrains what can be accomplished. By select-
These languages may also be useful in an environment where
ing the right tools, the developers minimize the time and effort
the prototype can use severa
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.