1、Designation: E 1340 05An American National StandardStandard Guide forRapid Prototyping of Information Systems1This standard is issued under the fixed designation E 1340; the number immediately following the designation indicates the year oforiginal adoption or, in the case of revision, the year of l
2、ast revision. A number in parentheses indicates the year of last reapproval. Asuperscript epsilon (e) indicates an editorial change since the last revision or reapproval.1. Scope1.1 This guide covers a rapid prototyping method fordeveloping information systems that is particularly relevant tosystems
3、 for the healthcare sector. Intended readers of this guideare people who develop information systems, and students andteachers of system development methods.1.2 Rapid prototyping is an approach to developing infor-mation systems which produce a working model more quicklythan conventional approaches.
4、 Where conventional methodsconcentrate on preparing Requirements and design documentsthat describe the needed system, rapid prototyping methodsconcentrate on preparing a working prototype. Users anddevelopers learn the functional requirements and an appropri-ate system design by interacting with a s
5、eries of prototypes,each of which is rapidly produced from a starting framework orfrom an earlier version. A prototype can evolve into anoperational system, it can serve as an exact behavioral speci-fication of an operational system, or it can be used to explorethe feasibility of a new idea or desig
6、n which can be incorpo-rated in a larger system. The method is rapid in preparing eachversion of the prototype, but the overall time required forsystem development may be more or less than the timerequired with conventional methods.1.3 Rapid prototyping is most appropriate when the Re-quirements or
7、design for a system are not well understood, orwhen experimentation is required to explore some aspect ofsystem behavior. It is not appropriate in hazardous settings, orwhen the requirements are well understood.1.4 The guide recommends use of prototyping tools, but it isnot a standard for the tools
8、themselves. It does not coverexecutable specification tools. Transforming a prototype that isused to clarify Requirements into an operational system isdiscussed briefly in Section 8 and in detail in other referencedstandards (see 2.1).1.5 This standard does not purport to address all of thesafety co
9、ncerns, if any, associated with its use. It is theresponsibility 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.2. Referenced Documents2.1 ANSI Standards:ANSI/MIL-STD-1815A Ada Programming Lan
10、guage2ANSI X3.9 Programming Language FORTRAN2ANSI X3.159 Programming Language C2ANSI/X11.1 MUMPS Programming Language2ANSI/IEEE 610.12 Glossary of Software Engineering Ter-minology2ANSI/IEEE 770 X3.97 Pascal Programming Language2ANSI/IEEE 830 Recommended Practice for Software Re-quirement Specificat
11、ions3ANSI/IEEE 1016 Recommended Practice for Software De-sign Descriptions3ANSI/IEEE 1058 Standard for Software Project Manage-ment Plans3ANSI/IEEE 1059 Guide for Software Verification and Vali-dation Plans3ANSI/IEEE 1063 User Documentation for Computer Soft-ware3ANSI/IEEE 1074 Software Life Cycle P
12、rocesses32.2 ISO Standards:IS 12207 Information Technology-Software Life Cycle Pro-cessesIS 15288 System Life Cycle ProcessesIS 15440 Guide for Life Cycle ProcessesIS 11756 MUMPS Programming Language3. Terminology3.1 DefinitionsFor definitions of terms relating to infor-mation systems, refer to ANDI
13、P4and ANSI/IEEE 610.12.3.1.1 fourth generation language, na high-level computerlanguage that incorporates data structures and procedures for aspecific problem domain.1This guide is under the jurisdiction of ASTM Committee E31 on HealthcareInformatics and is the direct responsibility of Subcommittee
14、E31.25 on HealthcareData Management, Security, Confidentiality, and Privacy.Current edition approved May 1, 2005. Published June 2005. Originallyapproved in 1990. Last previous edition approved in 1996 as E 1340 96.2Available from American National Standards Institute (ANSI), 25 W. 43rd St.,4th Floo
15、r, New York, NY 10036.3Available from Institute of Electrical and Electronics Engineers, Inc. (IEEE),445 Hoes Ln., P.O. Box 1331, Piscataway, NJ 08854-1331.4American National Dictionary for Information Processing Systems, Informa-tion Processing Systems Technical Report X3/TR-1-82, Dow Jones-Irwin,
16、Home-wood, IL.1Copyright ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959, United States.3.1.2 prototype, nan original or model from which asystem is copied.3.1.3 prototype, vto create an original or model.3.1.4 prototyping, nthe activities that create an orig
17、inal ormodel.3.1.5 rapid prototyping, nan iterative method for devel-oping prototypes of components, subsystems, or completecomputerized systems, in which the time between successiveversions of the prototype is short.3.1.6 RP, nrapid prototyping.3.1.7 third generation language, na procedural high-le
18、velcomputer language, such as COBOL, FORTRAN, or Pascal.4. Significance and Use4.1 Rapid Prototyping (RP) is a specific Life Cycle Modelused to develop an information system which produces aworking model of the system very quickly. The RP processshown in Fig. 1 has many similarities, and some differ
19、encesfrom the conventional system (Waterfall Life Cycle Model)development process shown in Fig. 2. RP replaces the Require-ments and Design processes of the conventional method withan iterative process of prototype refinement. Where the phasesof the conventional method produce a set of documents tha
20、tdescribe the system, RP produces a prototype. The prototype istested and refined through several iterations, with intenseinteraction between system users and developers. RP is anexperimental approach to system development which providesa learning device, the prototype, for users and developers. Apr
21、ototype can be used as a tool for clarifying Requirements forthe operational system, as a means of evaluating a designapproach, or as a developing series of versions of the opera-tional system. A prototype is sometimes used as an exactbehavioral specification for an operational system which re-place
22、s it. Quality characteristics are often sacrificed during RPfor the sake of rapid development and low cost; robustness,efficiency, generality, portability, and maintainability are com-monly ignored but none of these aspects need to be neglected.However, documentation needed to use the system cannot
23、beignored but none of these aspects need to be neglected. A“Throwaway” prototype is used specifically to define Require-ments which are used to implement a final system. An“Evolutionary” prototype is a prototypical system used forongoing refinement of Requirements while operational ver-sions at spec
24、ific milestones are used in production settings.4.1.1 Rapid in RP means that the time between successiveversions of the prototype is relatively short. It should be shortenough that (1) both users and developers can remember howeach version relates to the previous one without written notes,(2) user r
25、equirements do not change significantly while aversion is being developed, (3) the prototyping team willremain in the project through the RP phase, and (4) total timeto develop the system is acceptable. (Expected project durationFIG. 1 Rapid Prototyping of An Information SystemE1340052should be stat
26、ed in the project management planning docu-ment. See Section 6 and ANSI/IEEE 1058 and ANSI/IEEE1074.) A few days between versions is adequate and a fewweeks may be acceptable. If the time needed to produce a newversion is longer, then it may be necessary to produce thatversion using a conventional s
27、ystem development method withfull documentation of requirements and design (see AppendixX3).4.1.2 RP integrates analysis, design and construction, anddefines Requirements during the process. It is especiallyappropriate for dealing with problems which are not wellunderstood or are rapidly changing. T
28、he prototype focusescommunication between users and developers.4.2 For large systems, a RP approach can be used at a highlevel to explore the overall system architecture or feasibility. Itcan also be used to develop subsystems and components whoserequirements are not fully understood (see Section 11
29、). RP isespecially well suited for developing user-system interfaces.4.2.1 What to PrototypeThe ill-structured system devel-opment problems that yield best to RP include:4.2.1.1 Decision support systems in areas where the state ofknowledge changes rapidly, for example, research or clinicalpractice,4
30、.2.1.2 Systems whose users need to access and organizedata in ways not foreseen when the system is created, forexample, 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, and4.2.1.5 User-
31、system interfaces.4.2.2 Ways to use RPThree ways that are widely used are(1) evolutionary, ( 2) experimental, and (3) build-and-replace.In evolutionary prototyping, the developers rapidly produce aninitial version as a framework to learn user requirements, andthen satisfy the requirements incrementa
32、lly through a series ofversions to produce the operational system. In experimentalprototyping, the developers explore the feasibility of selectedcapabilities or components with a series of versions that serveto test concepts and designs. In build-and-replace prototyping,the developers assemble a ser
33、ies of versions to establish whatthe system should do and how it should do it, then theprototype is used as a behavioral specification for building theoperational system. Build-and-replace is sometimes calledthrow-away prototyping, but the prototype should not bethrown away.A RAPID PROTOTYPING METHO
34、D5. Introduction5.1 The following sections describe a system developmentmethod that uses RP. It is based on, and shares some featureswith, the methods described inANSI/IEEE 1074 and other ISOand IEEE standards which are listed in 2.1 (See IS 15440).Instead of producing documents that describe Requir
35、ements(ANSI/IEEE 830, Section 7), or Designs (ANSI/IEEE 1016)for the required system, this method produces a prototype ofthe system and refines it through an iterative process ofanalysis, synthesis, and evaluation.6. Project Definition6.1 In any system development project, whether done by RPor conve
36、ntional means, it is important to have a definition ofwhat is to be accomplished, when, where, why, by whom, andfor about how much effort. It is also important to identifyeveryone who must be satisfied with the results, and especiallyeveryone who will use the system. These things are determinedin th
37、e preliminary discussions and negotiations about a project.A written statement of them is a Project Management Plan(PMP, seeANSI/IEEE 1058) document.AProject ManagementPlan is an agreement among everyone involved with a project.Agreement on project goals is essential for project success.6.2 A Projec
38、t Management Plan must be in writing. Awritten document is concrete and changes to it are explicit anddocumented.Awritten PMP does not drift like a verbal one.Asnew people become involved with the project, they can readthe original document and can either become parties to it orrenegotiate it.6.3 Th
39、e PMP document should be brief, and structuredpreferably no more than a few pages. If it exceeds severalpages, provide a one page summary.6.4 The PMP document should state what is to be proto-typed and it should be specific about the goals of the project. IfFIG. 2 Conventional Development of An Info
40、rmation SystemE1340053a prototype is to be developed to learn the true requirements fora system, the project definition should say so. If a prototype isto explore feasibility of a new idea or design, that should bestated. The PMP document should say whether the prototype isto evolve into an operatio
41、nal version, or is to be replaced by anoperational version which is to be rebuilt from scratch. If thisis not known at the start of the project, then the PMP shouldstate the criteria for deciding.6.5 The PMP document should briefly say what functionsthe prototype is to perform. It should clarify and
42、 limit the scopeof the project, the prototype, and the system that is to be basedon the prototype.6.6 Everyone involved with the project should indicateagreement by signing the PMP document, or the one pagesummary of it.7. Tool Selection7.1 The PMP and the users preliminary statements aboutwhat the
43、system needs to do, guide the developers in selectingappropriate RP tools. The initial choice is crucial because itimmediately constrains what can be accomplished. By select-ing the right tools, the developers minimize the time and effortrequired for each RP cycle and maximize the likelihood ofsucce
44、ss. If the wrong tools are selected, then the project may beimmediately doomed to failure. Most of the tools discussed inthis section are software tools, that is, computer programs, butthe principles also apply to hardware tools.7.2 Good tools for RP share the following characteristics:7.2.1 They he
45、lp produce the prototype quickly,7.2.2 They allow changes to the prototype to be madequickly,7.2.3 They are general enough to permit more than onesolution to most problems,7.2.4 They encourage developers to try different ap-proaches,7.2.5 They are used interactively,7.2.6 The person using them need
46、not be a highly trainedspecialist,7.2.7 They simulate real time, and7.2.8 They are available for use now rather than proposed orpromised for future use.7.3 RP languages:7.3.1 Many fourth generation languages are appropriate forRP. A good RP language uses the natural terminology of theproblem domain,
47、 and it incorporates enough knowledge aboutprogramming to eliminate most of the need to write proce-dures. A good RP language should incorporate concepts whichare in general use by the people who are to use it. It shouldprovide high-level data constructs that are appropriate to theproblem.7.3.2 The
48、user-system interface for a good RP languageshould incorporate features which allow development teammembers to use descriptive techniques that they use withhuman colleagues, that is, graphic, tabular, and other non-verbal techniques.7.3.3 Tools that make the job easy for an inexperiencedperson may b
49、e tedious for a skilled system engineer. Thereshould be a terse dialog mode for the experienced user who canabstract more features than the inexperienced user.7.3.4 Good languages for RP are usually directly executedor interpreted in some fashion. The ideal language for anevolutionary prototype would fit the problem domain, wouldhave an interpretive processor with good diagnostic facilities,and would be compilable (for efficiency of the operationalversion).7.3.5 If the prototype is to evolve into the operationalsystem, then the RP language should have reasonable effi-ciency.
