原型法

原型方法的选择
任何要创建动态可视显示、和人员用户有很多的交互、或要
求必须以演化方式开发的算法或组合处理等的应用软件是原 型方法的候选者 。 开发项目的性质将对原型方法的功效有很大影响，项目开发 团队愿意并能够使用原型方法吗？有原型工具可用吗？开发 者有使用原型方法的经验吗？
原型评价
这个原型所实现的功能与你所期望的一致吗？ 有遗漏的功能吗？ 你能考虑一下这个原型所没有涉及到的一些出错情况吗？ 有多余的功能吗？ 这些功能导航的逻辑性和完整性如何？ 有更简单的方法来完成这一任务吗？
软件原型可能是:
工作模型或静态设计 很详细的屏幕草图或简单草图 真实功能的可视化显示或一部分 仿真或模拟
原型有多种含义
参与建立原型的人可以有不同的期望
例如，一个飞机原型实际上可以飞翔—它是真实飞机的雏形。 相反，一个软件原型通常仅仅是真实系统的一部分或一个模 型，并且它可能根本不能完成任何有用的事。 本章将研究各种类型的软件原型、它们在需求开发中的应用 以及如何使原型成为软件开发过程中有效的组成部分
垂直
• 实现并发展核心的客户/服务器功能层和通信层 • 实现并优化核心算法
书面原型和电子原型
在许多情况下，一个可执行的原型未必可以获取所需的用于 解决关于需求不确定性的信息。 书面原型（ paper prototype）（有时也叫低保真原型）是一 种廉价、快速并且不涉及高技术的方法，它可以把一个系统 某部分是如何实现的呈现在用户面前。 书面原型有助于判断用户和开发者在需求上是否达成共识。 他们可以使你在开发产品代码前，对各种可能的解决方案进 行试验性的并且低风险的尝试。
3）软件需求主要包括：功能需求、界面需求、性能需求、环境需求、可靠 性需求、安全保密需求、资源使用需求、软件成本消耗与开发进度需求 和目标需求。原型法中的原型难以表达软件的后七项需求； 4）原型法强调用户和开发人员不断对原型进行不断修改和补充，直到用户 感到满意为止。在时间紧和任务重的大型MIS项目中，这种情况实际难 以保证，特别是在用户单位和开发单位距离较远时。
6、不能随意地增加功能。 7、不要从水平原型的性能推测最终产品的性能。 8、在原型屏幕显示和报表中使用合理的模拟数据。 9、不要期望原型可以代替需求文档。
原型法有以下缺陷
1）原型的设计和修改工作量大，增加了系统的开发成本；
2）由于用户不关心或不理解原型的概念和实现，而且存在较大期望，使得 与实际系统差别较大的原型增加了需求分析人员与用户的交流难度；无 论是水平原型，还是垂直原型都不能反映实际系统的全貌；
简化原型法
简化原型法需求分析的第一个阶段 :
系统的边界 系统处理的业务 与其它系统的接口 工程的进度控制 培训安排
简化原型法需求分析的第二个阶段
需求调查准备 需求调查分析 进行需求评审
候选原型方法的因素：软件应用领域、软件应用复杂性、客户特征、以及 项目特征。 为了导出快速原型，可采用第四代技术、可复用软件构件、形式化规约和 原型环境。 抛弃式原型和进化式原型。 垂直型原型和水平型原型。 选择一些合适的人从恰当的角度评价原型。 原型法是一种减少软件项目失败风险的技术。然而，原型法又引入了自身 的风险。 原型法成功的因素。
原型法
一个令人不悦的经历
“用户以不适合为理由拒绝了他们开发的整个产品。在产品发布 之前，用户并没有见过用户界面，他们发现界面和潜在的需 求都存在问题。”
软件原型是一种技术，你可以利用这种技术减少客户对产品不 满意的风险。来自用户的早期反馈可以使开发小组正确理解 需求，并知道如何最好地实现这些需求。
为什么建立原型
需求中还有一部分对客户或开发者仍然不明确或不清晰。不 解决这些问题，那么必然在用户产品视图和开发者对于开发 什么产品的理解之间存在期望差距。通过阅读文本需求或研 究分析模型，很难想象软件产品在特定的环境中如何运行。 原型可以使新产品实在化，为使用实例带来生机，并消除你 在需求理解上的差异。 阅读一份冗长无味的软件需求规格说明，用户通常更愿意尝 试建立有趣的原型。
水平原型也称为行为原型
用来探索预期系统的一些特定行为，并达到细化需求的目的。水平原型通 常只是功能导航，并未真实实现功能。主要用在用户界面上。
垂直原型也称为结构化原型
实现了一部分功能。主要用在复Leabharlann Baidu的算法实现上。
选择适当的原型方法
在软件开发过程中使用原型法的一些可能的方法
软件原型的典型应用
抛弃型 水平 • 澄清并精化使用实例和功能需求 • 查明遗漏的功能 • 探索用户界面方法 • 证明技术的可行性 演化型 • 实现核心的使用实例 • 根据优先级，实现附加的使用实例 • 开发并精化We b站点
书面原型所包括的工具
纸张、索引卡、粘贴纸、塑料板、白板和标记器。
电子原型（ electronic prototype）
一个基于计算机的原型，该原型凝结了开发者的许多辛劳。
原型评价
通过建立脚本使用户遵从一系列步骤并且回答一些特定的问题 以获取所需要的信息，这样你可以提高原型评价的有效性。 在每个任务之后，脚本将为评价者提供特定的与任务有关的问 题。此外，你可以询问以下一般性的问题： • 这个原型所实现的功能与你所期望的一致吗？ • 有遗漏的功能吗？ • 你能考虑一下这个原型所没涉及的一些出错情况吗？ • 有多余的功能吗？ • 这些导航对于你意味着怎样的逻辑性和完整性？ • 有更简单的方法来完成这一任务吗？
原型开发的原则
你的项目计划中应包括原型风险。安排好开发、评价和可能的修改原型 的时间。 计划开发多个原型，因为你很少能一次成功。 尽快并且廉价地建立抛弃型原型。用最少的投资开发那些用于回答问题 和解决需求的不确定性的原型。不要努力去完善一个抛弃型原型的用户 界面。 在抛弃型原型中不应含有代码注释、输入数据有效性检查、保护性编码 技术，或者错误处理的代码。 对于已经理解的需求不要建立原型。 不能随意地增加功能。当一个简单的抛弃型原型达到原型目的时，就不 应该随便扩充它的功能。 不要从水平原型的性能推测最终产品的性能。原型可能没有运行在最终 产品所处的特定环境中，并且你开发原型的工具与开发产品的工具在效 率上是存在差异的。 在原型屏幕显示和报表中使用合理的模拟数据。那些评价原型的用户会 受不现实数据的影响而不能把原型看成真正产品的模型。 不要期望原型可以代替需求文档。原型只是暗示了许多后台功能，因此 必须把这些功能写入软件需求规格说明，使之完善、详细并且可以有案 可询。
原型法成功的因素
软件原型法提供了一套强有力的技术，它可以缩短开发进度， 增加用户的满意程度，生产出高质量的产品并且可以减少需 求错误和用户界面的缺陷。
为了帮助你在需求开发过程中建立有效的原型， 请遵循如下原则：
1、你的项目计划中应包括原型风险。安排好开发、评价和可 能的修改原型的时间。 2、计划开发多个原型，因为你很少能一次成功。 3、尽快并且廉价地建立抛弃型原型。用最少的投资开发那些 用于回答问题和解决需求的不确定性的原型。不要努力去完 善一个抛弃型原型的用户界面。 4、在抛弃型原型中不应含有代码注释、输入数据有效性检查、 保护性编码技术，或者错误处理的代码。 5、对于已经理解的需求不要建立原型。
原型是“什么”和“为什么”要原型
一个软件原型是所提出的新产品的部分实现。使用原型有三个
主要目的： 明确并完善需求原型作为一种需求工具。 探索设计选择方案原型作为一种设计工具。 发展为最终的产品原型作为一种构造工具。
建立原型的主要原因
为了解决在产品开发的早期阶段不确定的问题。利用这些不 确定性来判断系统中哪一部分需要建立原型和希望从用户对 原型的评价中获得什么。 对于发现和解决需求中的二义性，原型也是一种很好的方法。 二义性和不完整性使开发者对所开发的产品产生困惑，建立 一个原型有助于说明和纠正这些不确定性。 用户、经理和其他非技术项目风险承担者发现在确定和开发 产品时，原型可以使他们的想象更具体化。原型比开发者常 用的技术术语更易于理解。
候选原型方法的因素：
软件应用领域 软件应用复杂性 客户特征 以及项目特征
原型需求分析法的特点
循环往复 螺旋式上升 遵循了人们认识事物的规律. 将系统调查、系统分析和系统设计合而为一。
原型可以把新系统的一个模型或一个部分摆在用户的面前， 可以激活他们的思维，并促进需求对话。
对原型的早期反馈有助于涉众对理解系统需求达成共识，从 而减小客户不满意的风险。 原型(prototype)有多种含义，并且参与原型制作活动的人可 以有完全不同的期望。
使用原型法进行需求分析的流程
(1)快速分析，弄清用户的基本信息需求
(2)构造原型，开发初始原型系统 (3)用户和开发人员共同评价原型
原型的种类
抛弃式原型
将开发原型看做是沟通工具，永远也不会将一次式原型引入正式运行环境 中。主要解决需求的不确定性，二义性，不完整性等。
进化式原型
会在未来的系统中包含的原型。这种方法能够将最大量的工作投入到正式 系统中。
评价原型
原型的评价者必须是所期望的用户群的代表。
评价组必须从使用原型中功能的用户类里挑选出具有经验 和经验不足的用户。 在把原型呈递给评价者时，应注意原型不包括要在以后真 正产品开发中实现的所有的业务逻辑。
原型法的最大风险
原型法是一种减少软件项目失败风险的技术。
原型法又引入了自身的风险。 最大的风险是用户或者经理看到一个正在运行的原型从而以 为产品即将完成。