目前有代表性的软件需求分析方法除了面向数据流的结构化分析方法外，还有面向数据结构的 Jackson 方法、面向对象的方法和原型法等。由于原型法（Prototyping）改变了传统的系统的分析、
61 设计和实现三个顺序阶段的观点及自顶向下的开发模式，降低了软件需求的风险，因此该软件开发
过程模型可作为获取需求技术并得到广泛的应用。
3.4.1 原型在需求分析中的作用 3.4.1.1 原型的概念
通常，原型是指模拟某种产品的原始模型。在软件开发中，原型（prototype）则是软件的一个 早期可运行的版本，它反映最终系统的部分重要功能和特性。是将系统主要功能和接口通过快速开 发，制作为“软件样机”，以可视化的形式展现给用户，以征求用户意见，从而明确无误地确定用 户需求。同时，原型也可用于征求内部意见，作为分析和设计的接口之一，便于沟通。
3.4.1.2 原型的作用和特点
如前所述，需求分析的难点是构造一个完整准确的规格说明。特别是对于一些大型的软件项目，
在开发的早期，当系统分析员与用户一同确定需求时，用户往往对系统只有一个模糊的想法，不能 确定真正需要什么，很难完全准确地表达对系统的全面要求。尤其是随着开发工作向前推进，需求 还常常会发生变化，同时，对系统运行的效果，只能通过对它的逻辑上的推断，达到各方对系统的 共同理解，而不是在实际运行中判断评价。所以尽管采取多种方法，仍很难保证所构造的规格说明 能将系统的各个方面都描述的完整、准确、一致，并与实际环境相符。
而原型法可在获得一组基本需求说明后，通过快速分析构造出一个可运行的、满足用户基本要 求的软件系统框架。通过运行原型系统，使得用户通过亲身感受得到启发，提出具体的要求和评价。
然后开发者根据用户的意见对原型加以改进。随着不断运行原型、评价和修改，获得新的原型版本。
如此周而复始，逐步澄清模糊和误解，明确各种需求细节，适应需求的变更，从而提高了最终产品 的质量。所以原型法是最准确、最有效的一种需求分析技术。
原型应该具备的第一个特性是“快速”。快速原型的目的是尽快向用户提供一个可在计算机上 运行的目标系统的模型，以便使用户和开发者尽可能快地达成对目标系统应该“做什么”的共识。
所以，构造原型所做的需求往往是不足的，此时的原型会有某些缺陷，但只要这些缺陷对原型功能 的损害不严重，不会使用户对产品的行为产生误解，就可以忽略。
原型应该具备的第二个特性是“易于修改”。如果原型的第一版不是用户所需要的，就必须根 据用户的意见迅速地修改它，构建出原型的第二版，以更好地满足用户需求。在实际开发软件产品 时，原型的“修改－试用－反馈”过程可能重复多遍，如果修改耗时过多，势必延误软件开发时间。
3.4.1.3 软件原型的分类
虽然软件原型化方法是在研究分析阶段的方法和技术中产生的，但它更针对传统方法所面临的 困难。因此，原型化方法也面向软件开发的其他阶段。根据软件项目的特点和运行原型的不同目的，
原型有两种不同的类型。
（1）废弃（throwaway）型：先构造一个功能简单而且质量要求不高的模型系统，针对这个模 型系统反复进行分析修改，形成比较好的设计思想，据此设计出更加完整、准确、一致、可靠的最 终系统。系统构造完成后，原来的模型系统就被废弃。
（2）追加（addon）型：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的 核心，然后通过不断地扩充修改，逐步追加新要求，最后发展成为最终系统。
采用什么形式主要取决于软件项目的特点和开发者的素质，以及支持原型开发的工具和技术，
应根据实际情况的特点加以决策。
62
3.4.1.4 构建原型的方法及工具
原型系统不同于最终系统，它需要快速实现，投入运行。因此，必须注意功能和性能上的取舍。
在忽略一切暂时不必关心的部分，快速实现原型时，要能充分地体现原型的作用，满足评价原型的 需求。要根据构造原型的目的，明确规定对原型进行考核和评价的内容，如界面形式、系统结构、
功能或模拟性能等。构造出来的原型可能是一个忽略了某些细节或功能的整体系统结构，也可以仅 仅是一个局部，如用户界面、部分功能算法程序或数据库模式等。总之，在使用原型化方法进行软 件开发之前，必须明确使用原型的目的，从而决定分析与构造内容的取舍。对原型的基本要求包括：
（1）体现主要的功能。
（2）提供基本的界面风格。
（3）展示比较模糊的部分，以便于确认或进一步明确，防患于未然。
（4）原型最好是可运行的，至少在各主要功能模块之间能够建立相互连接。
为了快速地构建和修改原型，通常使用下述 3 种方法和工具。
1．第四代技术
第四代技术包括众多数据库查询和报表语言、程序和应用系统生成器以及其他非常高级的非过 程语言。第四代技术使得软件工程师能够快速地生成可执行的代码，因此，它们是较理想的快速原 型工具。
2．可重用的软件构件
另外一种快速构建原型的方法，是使用一组已有的软件构件（也称为组件）来装配（而不是从 头构造）原型。软件构件可以是数据结构（或数据库），或软件体系结构构件（即程序），或过程构 件（即模块）。必须把软件构件设计成能在不知其内部工作细节的条件下重用。应该注意，现有的 软件也可以被用作“新的或改进的”产品的原型。
3．形式化规格说明和原型环境
在过去的 20 多年中，人们已经研究出许多形式化规格说明语言和工具，用于替代自然语言规 格说明技术。今天，形式化语言的倡导者正在开发交互式环境，以便可以调用自动工具把基于形式 语言的规格说明翻译成可执行的程序代码，用户能够使用可执行的原型代码去进一步精化形式化的 规格说明。
3.4.2 快速原型开发过程
原型的开发和使用过程叫做原型生存期。图 3-19 给出了原型法开发过程，下面分别对过程中 的关键步骤进行讨论。
1．快速分析
在分析者和用户的紧密配合下，快速确定软件系统的基本要求。根据原型所要体现的特性（或 界面形式，或处理功能，或总体结构，或模拟性能等），描述基本规格说明，以满足开发原型的需 要。快速分析的关键是要注意选取分析和描述的内容，围绕使用原型的目标，集中力量，确定局部 的需求说明，从而尽快开始构造原型。
2．构造原型
在快速分析的基础上，根据基本规格说明，尽快实现一个可运行的系统。为此需要强有力的软 件工具的支持，并忽略最终系统在某些细节上的要求，如安全性、健壮性、异常处理等。主要考虑 原型系统应充分反映的待评价的特性。
63
图 3-19 原型法开发过程
提交一个初始原型所需要的时间，根据问题的规模、复杂性、完整程度的不同而不同。一般在 3～6 周提交一个系统的初始原型，最大限度不能超过两个月，两个月后提交的应是一个系统而不 是一个原型。
3．运行和评价原型
这是频繁通信、发现问题、消除误解的重要阶段。由于原型忽略了许多内容，它集中反映了要 评价的特性，外观看起来可能会有些残缺不全。用户要在开发者的指导下试用原型，在试用的过程 中考核评价原型的特性，分析其运行结果是否满足规格说明的要求，以及规格说明的描述是否满足 用户的愿望。纠正误解和错误，增补新的要求，并为满足因环境变化或用户的新设想而引起系统需 求的变动并提出全面的修改意见。
4．修正和改进
根据修改意见进行修改。大多数原型不合适的部分可以修正，使之成为新模型的基础。如果 是由于规格说明不准确（有多义性或者未反映用户要求）、不完整（有遗漏）、不一致，或者需求 有所变动或增加，则首先要修改并确定规格说明，然后再重新构造或修改原型。但若出现因为严 重的理解错误而使正常操作的原型与用户要求相违背时，有可能会产生废品，应当立即放弃，而 不能再凑合。
64
如果用修改原型的过程代替快速分析，就形成了原型开发的迭代过程。开发者和用户在一次次 的迭代过程中不断将原型完善，以接近系统的最终要求。
在修改原型的过程中会产生各种各样的积极的或消极的影响，为了控制这些影响，应当有一个 词典，用以定义应用的信息流以及各个系统成分之间的关系。另外，在用户积极参与的情况下，保 留改进前后的两个原型，一旦用户需要时可以退回，而且贯穿地演示两个可供选择的对象，有助于 决策。
5．判定原型完成
经过修改或改进原型，达到参与者一致认可，则原型开发的迭代过程可以结束。为此，应判断 有关应用的实质是否已经掌握，迭代周期是否可以结束等。判定的结果有两个不同的转向，一是继 续迭代验证，一是进行详细说明。
6．判断原型细部是否说明
判断组成原型的细部是否需要严格地加以说明。原型化方法允许对系统必要成分进行严格地详
判断组成原型的细部是否需要严格地加以说明。原型化方法允许对系统必要成分进行严格地详