E1340-1996用快速原型法开发计算机化系统(中文版
- 格式：pdf
- 大小：581.15 KB
- 文档页数：17
E1340-1996标准指南用快速原型法开发计算机化系统1范围1.1本指南介绍了一种开发计算机化系统的方法--快速原型法。
本指南的既定读者为开发计算机化系统的科技工作者和从事系统开发方法教学的教师和学生。
1.2快速原型法是开发计算机化系统的一种方法，它产生活动模型的速度要比传统方法快得多。
传统方法侧重于功能要求的准备和对所需系统进行描述的功能设计文件，而快速原型法侧重于工作原型的制作。
通过与一系列原型（样机）相结合，使用者和开发者可以了解功能要求和相关的系统设计，而每一原型都是从一个起始构架或从一个较早版本快速产生的。
一个原型可以发展成一个功能系统，它可以充当一个可操作系统的一个严格的行为规范，它也可以用于探索一个新创意或设计的可行性，融入一个更大的系统。
这种方法对原型的每个版本制作速度快，但是系统开发需要的总体时间可能比传统方法需要的时间多也可能比传统方法需要的时间少。
1.3当一个系统的功能要求或功能设计没有被很好地理解的时候，或当需要通过实验来探索系统行为的某些方面时，快速原型法是最适合的方法。
快速原型法不适合于危险设置或要求能被很好理解的情况。
1.4本指南建议使用原型制作工具，但它本身不是这些工具的一个标准。
本指南不包含可执行的规范化工具。
将一个用于澄清要求的原型转化成一个可操作系统的问题主要在第8节讨论并在其他引用标准中细化（见2.1）。
1.5本标准并不致力于所有与安全相关的问题，如果有，也只是关系到标准的使用。
在使用前建立适当的安全卫生细则并确定法规限制条件的适用性是本标准使用者的责任。
2引用文件2.1ASTM标准E622计算机化系统开发指南E625计算机化系统使用者培训指南E627计算机化系统文件制作指南E731市场上可买到的计算机化系统的选择和采购指南E919计算机化系统的软件资料技术要求E1013与计算机化系统相关的术语E1029临床实验室计算机系统的文件记录指南2.2ANSI标准ANSI/MIL-STD-1815A ADA编程语言ANSI/X3.9FORTRAN编程语言ANSI/X3.159C编程语言ANSI/X11.1MUMPS编程语言ANSI/IEEE729软件工程术语表ANSI/IEEE770X3.97PASCAL编程语言ANSI/IEEE1063用于计算机软件的用户文件3术语3.1定义与计算机化系统相关的术语的定义参见E1013的术语、IEEE729的术语和ANDIP词典。
3.1.1fourth generation language/第四代语言，名词，对一个具体问题域加入数据结构和程序的一种高级计算机语言。
3.1.2prototype/原型，名词，供复制系统的原作或模型。
3.1.3prototype/原型开发，动词，创建一个原作或模型。
3.1.4prototyping/原型开发活动，名词，创建一个原作或模型的活动。
3.1.5rapid prototyping/快速原型法，名词，用于组件、子系统或完整计算机化系统的原型开发的一种迭代法，这种方法开发出原型的版本与版本之间相隔的时间短。
3.1.6RP，名词，即快速原型法。
3.1.7third generation language/第三代语言，名词，一种程序性的高级计算机语言，比如COBOL、FORTRAN、或Pascal语言。
4意义和使用4.1快速原型法（RP）是开发计算机化系统的一种方式，它能非常快地产生系统的一个活动模型。
图1所示的R P过程和图2所示的传统的系统开发过程有许多相似之处也有某些不同之处。
RP采用一个原型精炼迭代过程代替了传统方法的功能要求和功能设计阶段，在传统方法产生一套对系统进行描述的文件的阶段RP产生一个原型。
通过几次迭代，让系统的使用者和开发者进行充分的交流，使原型得到测试和精炼。
RP是系统开发的一种实验性方法，它给使用者和开发者提供一个学习装置—原型。
一个原型可被用作为澄清可操作系统功能要求的一个工具，被用作为对一种设计方法进行评价的方法，或被用于可操作系统系列版本的开发。
一个原型有时也用作为替代它的一个可操作系统的一个严格的行为规范。
为了快速开发和降低成本，在RP过程中经常牺牲质量特征，稳定性、效率、通用性、轻便性、和可维护性通常也被忽略。
但是，使用系统所需要的文件不能被忽略。
4.1.1RP中的‘快速’意味着原型的连续版本之间相隔的时间短。
这个时间间隔宜足够短，使①使用者和开发者都能记得一个版本与前一版本之间有怎样的关系，而不需要打开笔记；②在一个版本的开发过程中用户要求不会有明显的改变；③原型开发活动这一术语贯穿项目的整个RP阶段；④使开发系统的总时间是可以接受的。
（宜在定义项目的协议中规定预期的项目开发时间。
见第6节和E622的第6节）。
版本与版本之间隔几天就足够了，隔几个星期也可能是可以接受的。
如果产生一个新版本需要的时间较长，那么它可能需要采用一种传统的系统开发方法（例如指南E622）和全部要求和设计文件来产生这个版本（见附录X3）。
图1：开发一个计算机化系统的快速原型法图2：传统的计算机化系统开发4.1.2RP综合分析、设计/构建、和定义了过程中的要求。
这特别适合于处理没有很好理解的问题。
原型开发注重使用者和开发者之间的交流。
4.2对于大型系统，RP方法可以在一个高层次上使用，用以探索整个系统的构造或可行性。
它还可以用于开发要求没有被完全理解的子系统和组件（见第11节）。
RP特别适合于使用者-系统界面的开发。
4.2.1原型开发开发些什么？最适合于RP的构建有问题的系统的开发问题包括：4.2.1.1知识状态变化快的领域的决策支持系统，例如研究或临床医学领域的，4.2.1.2在系统被创建时需要使用者以不可预见的方式存取和组织数据的系统，例如战略决策支持，4.2.1.3完全由软件组成的系统，4.2.1.4指导性或实验性的系统，和4.2.1.5使用者-系统界面。
4.2.2使用RP的方式—被广泛使用的三种RP方式是①改良，②实验，③建立和替代。
在改良型原型开发活动中，开发者快速建立一个作为了解使用者要求的框架的初始版本，然后通过一系列的版本逐渐满足这些要求，产生可操作的系统。
在实验型原型开发活动中，开发者探索所选能力或用作为测试概念和设计的组件的一系列版本的可行性。
在建立-替代模式的原型开发活动中，开发者通过对一系列版本进行组合，来确定系统宜做什么和宜怎样做，然后将原型用作为建立可操作系统的一个行为规范。
建立-替代模式有时也被称为放弃型原型开发活动，只是原型是不宜放弃的。
一种快速原型开发方法5引言5.1以下章节描述使用RP的系统开发方法。
它根据并分享指南E622和列在2.1中的其他ASTM标准的某些成分。
代替产生描述所要求系统功能要求（指南E622第7节）、功能设计（指南E622第8节）、和执行设计（指南E622第9节）的文件，这种方法产生系统的一个原型并通过迭代法分析、综合、和评价对它进行精炼。
6项目定义6.1在任何系统开发项目中，不管是采用RP方法还是采用传统方法，对要做什么、什么时候做、在哪里做、为什么做、由谁做、和大约需要多少工作量有一个明确的定义都是很重要的。
确定每个人必须满足的结果，尤其是将使用系统的每个人，同样很重要。
这些事情在项目的初步讨论和谈判中被确定下来，对它们的书面说明既是一个项目定义文件。
指南E622第6节中说项目定义是包含在一个项目中的每个人之间的一种协议。
就项目目标达成协议对于项目的成功是不可缺少的。
6.2项目定义宜采用书面形式。
书面文件是实在的，要修改它也很明显。
书面的项目定义不要书写得像口语的形式。
作为项目中加入的新人，他们要能读懂原来的文件并且成为项目的一份子，否则就要对项目进行重新谈判。
6.3项目定义文件宜简明扼要，最好不要多于一页。
如果它超过两页，就要提供只有一页的摘要。
6.4项目定义文件宜说明要进行原型开发的内容是什么并宜具体说明项目目标。
如果一个原型开发是为了了解一个系统的真实要求，项目定义宜进行这样的说明。
如果一个原型是为了探索一个新创意或设计的可行性，也宜在项目定义中说明。
项目定义文件宜说明是要将原型发展成可操作的版本，还是要采用从零开始重建的一个可操作版本将它替代。
如果在项目开始的时候不清楚这一点，项目定义宜说明其决定准则。
6.5项目定义文件宜简要说明原型要完成什么功能，宜阐明和限制项目、原型和要以原型为基础的系统的范围。
6.6与项目有联系的每一个人宜通过在项目定义文件上或在项目定义文件的摘要页上签字表明已经同意。
7工具选择7.1项目定义和用户关于需要系统做什么的初步说明指导开发者选择适合的RP工具。
最初的选择至关重要，因为它直接限制了能完成什么任务。
通过选择正确的工具，开发者可以将每轮RP需要的时间和工作量降至最低和将成功的可能性最大化。
如果选择了错误的工具，项目可能注定会失败。
这个阶段讨论最多的工具是软件工具，即计算机程序，但这些原则也适用于硬件工具。
7.2好的工具应具备以下特征：7.2.1有助于原型的快速产生，7.2.2允许对原型进行快速修改，7.2.3对于大多数问题，它们通常都有一个以上的解决方案，7.2.4它们能鼓励开发者尝试不同的途径，7.2.5它们能够以人机交互方式使用，7.2.6使用它们的人不需要是久经锤炼的专家，7.2.7它们能实时模拟，7.2.8现在就可以应用，而不是现在才提出或将来才可以应用。
7.3RP语言7.3.1许多第四代语言都适合用于RP。
好的RP语言采用问题领域的自然术语，并融入了足够的编程知识以便省去大多数写入过程。
好的RP语言宜融入要使用它的人们通常使用的概念。
它宜提供适合于问题的高级数据结构。
7.3.2好的RP语言的使用者-系统界面宜融入允许开发团队成员使用他们与人类同事使用的描述性方法，即使用图形、表格、和其他不用语言的交流方法。
7.3.3让缺乏经验的人容易上手的工具对于系统工程师来说可能是单调乏味的，因此宜为能够比没有经验的使用者提取更多特征的有经验的使用者提供简洁的对话方式。
7.3.4用于RP的好的语言通常是以某种方式直接执行的或直接解释的。
用于一个该进的原型的理想的语言宜与问题的领域相适合，宜具备一个解释处理程序和好的诊断设施，并宜是可编译的（对于可操作版本的效率）。
7.3.5如果原型要发展成可操作系统，那么RP语言宜具备合理的效率。
MUMPS(AMSI X11.1)、LISP、和APL是广泛使用的RP语言。
使用这些语言比使用Pascal （ANSI/IEEE770X3.97）和Ada（ANSI/MIL-STD1815A）之类的强类型语言使RP更容易。
7.3.6通用FORTRAN语言(ANSI X3.9)和C语言(ANSI X3.159)之类的第三代编程语言不适合于RP，除非可以运用强大的程序库来减轻编程的工作量。
