ASTM E1340 - 05(2010) Standard Guide for Rapid Prototyping of Information Systems (Withdrawn 2017).pdf

1、Designation: E1340 05 (Reapproved 2010) An American National StandardStandard Guide forRapid Prototyping of Information Systems1This standard is issued under the fixed designation E1340; the number immediately following the designation indicates the year oforiginal adoption or, in the case of revisi

2、on, the year of last revision. A number in parentheses indicates the year of last reapproval. Asuperscript epsilon () 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 re

3、levant tosystems 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 conventi

4、onal approaches. 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 inte

5、racting with a series 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 n

6、ew idea or design 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 R

7、e-quirements or 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 standar

8、d for the tools 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

9、 of thesafety concerns, 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

10、 Programming Language2ANSI 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-quir

11、ement Specifications3ANSI/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 Softw

12、are Life Cycle Processes32.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 Definitions3.1.1 For definitions of terms relating to informationsy

13、stems, refer to ANDIP4and ANSI/IEEE 610.12.1This guide is under the jurisdiction of ASTM Committee E31 on HealthcareInformatics and is the direct responsibility of Subcommittee E31.25 on HealthcareData Management, Security, Confidentiality, and Privacy.Current edition approved March 1, 2010. Publish

14、ed August 2010. Originallyapproved in 1990. Last previous edition approved in 2005 as E134005. DOI:10.1520/E1340-05R10.2Available from American National Standards Institute (ANSI), 25 W. 43rd St.,4th Floor, New York, NY 10036, http:/www.ansi.org.3Available from Institute of Electrical and Electronic

15、s Engineers, Inc. (IEEE),445 Hoes Ln., P.O. Box 1331, Piscataway, NJ 08854-1331, http:/www.ieee.org.4American National Dictionary for Information Processing Systems, Informa-tion Processing Systems Technical Report X3/TR-1-82, Dow Jones-Irwin,Homewood, IL.Copyright ASTM International, 100 Barr Harbo

16、r Drive, PO Box C700, West Conshohocken, PA 19428-2959. United StatesNOTICE: This standard has either been superseded and replaced by a new version or withdrawn.Contact ASTM International (www.astm.org) for the latest information13.1.2 fourth generation language, na high-level computerlanguage that

17、incorporates data structures and procedures for aspecific problem domain.3.1.3 prototype, nan original or model from which asystem is copied.3.1.4 prototype, vto create an original or model.3.1.5 prototyping, nthe activities that create an original ormodel.3.1.6 rapid prototyping, nan iterative meth

18、od for devel-oping prototypes of components, subsystems, or completecomputerized systems, in which the time between successiveversions of the prototype is short.3.1.7 RP, nrapid prototyping.3.1.8 third generation language, na procedural high-levelcomputer language, such as COBOL, FORTRAN, or Pascal.

19、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 differencesfrom the conventional system (Waterfall Life Cycle

20、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 thatdescribe the system, RP produces a prototype. The proto

21、type 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. Aprototype can be used as a tool for clarifying Requirement

22、s 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-places it. Quality characteristics are often sacrificed durin

23、g 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 beignored but none of these aspects need to be neglected

24、. 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 specific milestones are used in production settings.4.1.1 Ra

25、pid 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,FIG. 1 Rapid Prototyping of An Information SystemE1340 05 (2010)2

26、(2) user requirements 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 durationshould be stated in the project management planning docu-men

27、t. 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 system development method withfull documentatio

28、n 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. The prototype focusescommunication between user

29、s 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). RP isespecially well suited for developing

30、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.2.1.2 Systems whose users need to access and

31、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-system interfaces.4.2.2 Ways to use RPThree wa

32、ys 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 incrementally through a series ofversions to produce the

33、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 series of versions to establish whatthe system sho

34、uld 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 METHOD5. Introduction5.1 The following sections desc

35、ribe 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 Requirements(ANSI/IEEE 830, Section 7), or Designs (A

36、NSI/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 conventional means, it is important to have a defini

37、tion 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 the preliminary discussions and negotiations abou

38、t 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 Project Management Plan must be in writing. Awritten

39、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.FIG. 2 Conventional Development of An Information Sys

40、temE1340 05 (2010)36.3 The 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. Ifa prototype is to

41、 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 operational version, or is to be replaced by an

42、operational 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 limit the scopeof the project, the pro

43、totype, 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 system needs to do, guide the developer

44、s 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 ofsuccess. If the wrong tools are selected, th

45、en 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 help produce the prototype quickly,7.2.2

46、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 differentapproaches,7.2.5 They are used interactively,7.2.6 The person using them need not be a highly trainedspecialist,7.2.7 T

47、hey 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, and it incorporates enough knowledge abo

48、utprogramming 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 user-system interface for a good RP langu

49、ageshould 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 be 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 f