2.4 快速原型化方法

通常，原型是指模拟某种产品的原始模型。在软件开发中，原型是一个软件早期可运行的版本，它反映最终系统的部分重要特性。如果在获得一组基本需求说明后，通过快速分析构造出一个小型软件系统，满足用户的基本要求，使得用户可在试用原型系统的过程中可以亲身感受并受到启发，做出反应和评价，然后开发者根据用户的意见对原型加以改进。随着不断试验、纠错、使用、评价和修改，获得新的原型版本，如此周而复始，逐步减少分析和通信中的误解，弥补不足之处，进一步确定各种需求细节，适应需求的变更，从而提高最终产品的质量。利用原型化技术，可为软件的开发提供一种完整、灵活、近似动态的规格说明方法。

2.4.1 原型的分类

软件原型化方法是在研究需求分析阶段的方法和技术中产生的，它主要针对传统方法面临的困难，因此，也面向软件开发的其他阶段。由于软件项目的特点和运行原型的目的不同，原型有3种不同的作用类型。

（1）探索型。这种原型的目的是要弄清对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。它主要针对开发目标模糊，用户和开发者对项目都缺乏经验的情况。

（2）实验型。这种原型用于大规模开发和实现之前，应考核方案是否合适，规格说明是否可靠。

（3）演化型。这种原型的目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型演化成最终系统。它将原型化方法的思想扩展到软件开发的全过程，适于满足需求的变动。

由于运用原型的目的和方式不同，在使用原型时可采取以下两种不同的策略：

（1）废弃策略。先构造一个功能简单而且质量要求不高的模型系统，针对这个模型系统反复进行分析修改，形成比较好的设计思想，据此设计出更加完整、准确、一致、可靠的最终系统。系统构造完成后，原来的模型系统就废弃不用了。探索型和实验型的原型一般属于这种策略。

（2）追加策略。先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断扩充修改，逐步追加新要求，最后发展为最终系统。它对应演化型的原型。

采用什么形式、什么策略主要取决于软件项目的特点，以及支持原型开发的工具和技术。要根据实际情况的特点加以决策。

原型系统不同于最终系统，它需要快速实现，投入运行。因此，必须注意功能和性能上的取舍。可以忽略一切暂时不必关心的部分，力求原型的快速实现。但要能充分体现原型的作用，满足评价原型的需求。要根据构造原型的目的，明确规定对原型进行考核和评价的内容，如界面形式、系统结构、功能或模拟性能等。构造出来的原型可能是一个忽略了某些细节或功能的整体系统结构，也可以仅仅是一个局部，如用户界面、部分功能算法程序或数据库模式等。总之，在使用原型化方法进行软件开发之前，必须明确使用原型的目的，从而决定分析与构造内容的取舍。

2.4.2 原型类型的选择

1984 年，Boar 提出一系列选择原型化方法的因素。如果是在需求分析阶段要使用原型化方法，必须从系统结构、逻辑结构、用户特征、应用约束、项目管理和项目环境等多方面来考虑，以决定是否采用原型化方法。

（1）系统结构。联机事务处理系统，相互关联的应用系统适合用原型化方法，而批处理、批修改等结构不适宜用原型化方法。

（2）逻辑结构。有结构的系统，如操作支持系统、管理信息系统、记录管理系统等适合用原型化方法，而基于大量算法的系统不适宜用原型化方法。

（3）用户特征。不满足于预先做系统定义说明，愿意为定义和修改原型投资，不易肯定详细需求，愿意承担决策的责任，准备积极参与的用户是适合使用原型的用户。

（4）应用约束。对已经运行系统的补充，不能用原型化方法。

（5）项目管理。只有项目负责人愿意使用原型化方法，才适合用原型化方法。

（6）项目环境。需求说明技术应当根据每个项目的实际环境来选择。

当系统规模很大、要求复杂、系统服务不清晰时，在需求分析阶段先开发一个系统原型是很值得的。特别是当性能要求较高时，在系统原型上先做一些试验也是很必要的。

1992年，Andriole给出6个问题，用来帮助选择原型化方法。表2.1指明了对这些问题的典型答案和对使用原型化方法的建议。

2.4.3 原型开发过程

1.原型构造要求

原型不同于最终的系统，两者在功能范围上的区别是最终系统要实现软件需求的全部功能，而原型只实现经过选择的部分功能。最终系统对每个软件需求都要求详细实现，而原型仅仅是为了试验和演示用的，部分功能需求可以忽略或模拟实现。因此，在构造原型时，必须注意功能、性能的取舍，忽略一切暂时不关心的部分以加速原型的实现，同时又要充分体现原型的作用，满足评价原型的要求。

2.原型的特征分类

根据原型的目的和方式不同，构造原型内容的取舍不同。在构造原型之前，必须明确使用原型的目的，从而解决分析和构造内容的取舍，还要根据构造原型的目的确定考核、评价原型的内容。

原型特征有如下类型：

（1）系统的界面形式，即用原型来解决系统人机交互界面的结构。

（2）系统的总体结构，即用原型来确定系统的体系结构。

（3）系统的主要处理功能和性能，即用原型来实现系统的主要功能和性能。

（4）数据库模式，即用原型来确定系统的数据库结构。

3.原型生存周期

原型的开发和使用过程称为原型生存周期。图 2.21（a）是原型生存周期的模型，图2.21（b）是模型的细化。

1）快速分析

在分析人员和用户的紧密配合下，快速确定软件系统的基本要求。根据原型所要体现的特性（界面形式、处理功能、总体结构或模拟性能等），描述基本规格说明，以满足开发原型的需要。

快速分析的关键是要注意选取分析和描述的内容，围绕使用原型的目标，集中力量，确定局部的需求说明，从而尽快开始构造原型。当系统规模很大、要求复杂、系统服务不清晰时，在需求分析阶段先开发一个系统原型是很值得的。特别是当性能要求比较高时，在系统原型上先做一些试验也是很必要的。

2）构造原型

在快速分析的基础上，根据基本规格说明，尽快实现一个可运行的系统。为此需要强有力的软件工具的支持，如采用非常高级的语言实现原型，引入以数据库为核心的开发工具等；并忽略最终系统在某些细节上的要求，如安全性、健壮性、异常处理等。此时应主要考虑原型系统应充分反映待评价的特性，暂时忽略一切次要内容。

例如，如果构造原型的目的是确定系统输入界面的形式，可以利用输入界面自动生成工具，由界面形式的描述和数据域的定义立即生成简单的输入模块，而暂时不考虑参数检查、值域检查和后处理工作，从而尽快把原型提供给用户使用。如果要利用原型确定系统的总体结构，可借助菜单生成器迅速实现系统的程序控制结构，而忽略转储、恢复等维护功能，使用户能够通过运行菜单来了解系统的总体结构。

初始原型的质量对于原型生存周期后续步骤的成败是至关重要的。如果它有明显的缺陷，会带给用户一种不好的思路；如果为追求完整而做得太大，就会增加修改的工作量。因此，应当有一个好的初始原型。

3）运行和评价原型

这是频繁通信、发现问题、消除误解的重要阶段。其目的是验证原型的正确程度，进而开发新的模型并修改原有的需求。它必须通过所有相关人员的检查、评价和测试。

由于原型忽略了许多内容，它集中反映了要评价的特性，外观看起来可能会有些残缺不全。用户要在开发者的指导下试用原型，在试用过程中考核评价原型的特性，分析其运行结果是否满足规格说明的要求，以及规格说明的描述是否满足用户的愿望。纠正过去交互中的误解和分析中的错误，增补新的要求，并为满足因环境变化或用户的新设想而引起的系统需求变动而提出的全面的修改意见。

为了鼓励用户评价原型，应当充分解释原型的合理性，但不要为它辩护，以求能广泛征求用户的意见，在交互中达到完善。

在演示/评价/修改的迭代初期，达到的主要目的是：原型通过用户进行验收；总体检查，找出隐含的错误；在操作原型时，使用户感到熟悉和舒适。

而在迭代的后期，要达到的主要目的是：应发现丢失和不正确的功能；测试思路和提出建议；改善/系统界面。

开发者不应认为提供了完整的模型就等于系统的成功。因为即使开发过程完全正确，用户还是可以提出一些有意义的修改意见，这不能看成对开发者的批评，而是在开发过程中的一种自然的现象。原型化的目标是鼓励改进和创造，而不仅是保持某种设想。

4）修正和改进

根据修改意见进行修改。若原型运行的结果未能满足规格说明中的需求，反映出对规格说明存在不一致的理解或实现方案不够合理。若因为严重的理解错误而使正常操作的原型与用户要求相违背时，有可能会产生废品。如果发现是废品应当立即放弃，不能凑合。大多数原型不合适的部分可以修正，以成为新模型的基础。如果规格说明不准确（有多义性或者未反映用户要求）、不完整（有遗漏）、不一致，或者需求有改变或增加，则应首先修改并确定规格说明，然后再重新构造或修改原型。

如果用修改原型的过程代替快速分析，就形成了原型开发的迭代过程。开发人员和用户在一次次的迭代过程中不断将原型完善，以接近系统的最终要求。

在修改原型的过程中会产生各种积极或消极的影响，为了控制这些影响，应当有一个词典，用以定义应用的信息流及各个系统成分之间的关系。另外，在用户积极参与的情况下，保留改进前后的两个原型，一旦用户需要可以退回，而且贯穿演示两个可供选择的对象有助于决策。

5）判定原型完成

经过修改或改进的原型，得到参与者的一致认可，则原型开发的迭代过程可以结束。为此，应判断有关应用的实质是否已经掌握，迭代周期是否可以结束等。判定的结果有两个不同的转向，一个是继续迭代验证，另一个是进行详细说明。

6）判断原型细部是否说明

判断组成原型的细部是否需要严格地加以说明。原型化方法允许对系统必要成分进行严格且详细的说明。例如，将需求转化为报表，给出统计数字等。这些不能通过模型进行说明的成分，必要的话，需要提供说明，并利用屏幕进行讨论和确定。

7）原型细部的说明

对于那些不能通过原型说明的所有项目，仍需要通过文件加以说明。下面是一些较明显的项目，如系统的输入、系统的输出、系统的转化、系统的逻辑功能、数据库组织、系统的可靠性、用户地位等。原型化对完成严格的规格说明是有帮助的，如输入、输出记录都可以通过屏幕进行统计和讨论。

注释：严格说明的成分要作为原型化方法的模型编入词典，以得到一个统一且连贯的规格说明提供给开发过程。

8）判定原型效果

考察用户新加入的需求信息和细部说明信息，看其对模型效果有什么影响？是否会影响模块的有效性？如果模型效果受到影响，甚至导致模型失效，则要进行修正和改进。

9）整理原型和提供文档

整理原型的目的是为进一步开发提供依据，原型的初期需求模型就是一个自动的文档。