软件需求工程讲义第四讲需求分析(1).ppt

3.2.5 原型评价 通过建立脚本使用户遵从一系列步骤并且回答一些特定的问题以获取所需要的信息，这样你可以提高原型评价的有效性。这些活动是对一般的询问“告诉我，你对这个原型的看法如何”的有价值的补充。你可以从使用实例和原型描述的功能中获得评价脚本。这一脚本可以让用户执行特定的任务并且指导他们评价你觉得最不确定的原型部分。在每个任务之后，脚本将为评价者提供特定的与任务有关的问题。 这个原型所实现的功能与你所期望的一致吗? 有遗漏的功能吗? 你能考虑一下这个原型所没涉及的一些出错情况吗? 有多余的功能吗? 这些导航对于你意味着怎样的逻辑性和完整性? 有更简单的方法来完成这一任务吗? * 1）务必让一些合适的人从恰当的角度评价原型。 原型的评价者必须是所期望的用户群的代表。 评价组必须从使用原型中功能的用户类里挑选出具有经验和经验不足的用户。 在把原型呈递给评价者时，应注意原型不包括要在以后真正产品开发中实现的所有的业务逻辑。 2）由于用户界面原型可用性的正式测试工作量庞大，所以除了让用户自己评价原型然后把他们的想法告诉你以外，通过实际观察用户使用原型以获得更多的信息。 要注意用户所指出那些原型部分。 善于发现与原型的方法相冲突的用户所习惯的应用程序的操作规范。 寻找那些有疑惑的用户，他们不知道该如何做才能达到满意的程度。 * 当用户在评价原型时，让用户尽量把自己的想法大胆地讲出来，这样才能真正理解他们想什么，并且能够发现原型表示的不合理的需求部分。努力创造一个公平的环境，这样可使评价者畅所欲言，表达他们的想法和所关心的事物，要避免用户在评价原型时诱导用户用设计好的特定方法执行一些功能。 3）把从原型评价中获得的信息编写成文档。 对于一个水平原型，用所收集的信息精化软件需求规格说明中的需求。 如果原型评价得出一些用户界面设计的决策或者特定交互技术的选择，那么把这些结论和你如何实现都记录下来。 没有用户参与决策，分析者就必须不断地回溯，将造成不必要的时间浪费。 对于一个垂直原型，记录好所实施的评价以及评价结果，从而做出关于所探索的不同技术方法可行性的决策。 * 3.2.6 原型法的最大风险 原型法是一种减少软件项目失败风险的技术。然而，原型法又引入了自身的风险。最大的风险是用户或者经理看到一个正在运行的原型从而以为产品即将完成。 如果你正在演示或评价一个抛弃型原型，无论它与真正的产品是如何相像，它决不会达到产品的使用程度： 它仅是一个模型，一种模拟或一次实验。 处理风险承担者的期望是成功原型法的一个关键因素，因此要保证那些见到原型的人理解为什么要建立原型并且怎样建立原型。 决不能把抛弃型原型当作可交付的产品。由于原型在设计和编码中并没有考虑到软件质量和容错性，因此交付原型可导致项目的延期完成。 * 不要因为害怕提交不成熟产品而阻碍建立原型，必须让用户明白你不会交付原型，甚至不会将它称之为软件。控制这种风险的一种方法是利用书面原型而不是电子原型。评价书面原型的人决不会误认为产品已经完成开发并可以交付了。另一种可能的方法是使用不同于在真正开发时所用的原型法工具，这将有助于你抵抗“已完成’’原型开发并可把它当作产品交付的压力。 在原型评价期间，继续处理那些期望。如果评价者看到原型可以对一个模拟的数据库查询响应甚快，那么他们可能期望在最终的软件产品中也具有同样惊人的性能。在对最终产品的行为进行模拟时，要考虑现实中的时间延迟(这可以使原型不易被看作可即将交付的产品)。 * 3.2.7 原型法成功的因素 软件原型法提供了一套强有力的技术，它可以缩短开发进度，增加用户的满意程度，生产出高质量的产品并且可以减少需求错误和用户界面的缺陷。为了帮助开发者在需求开发过程中建立有效的原型，请遵循如下原则： 项目计划中应包括原型风险。安排好开发、评价和可能的修改原型的时间。 计划开发多个原型，因为你很少能一次成功。 尽快并且廉价地建立抛弃型原型。用最少的投资开发那些用于回答问题和解决需求的不确定性的原型。不要努力去完善一个抛弃型原型的用户界面。 在抛弃型原型中不应含有代码注释、输入数据有效性检查、保护性编码技术，或者错误处理的代码 * 对于已经理解的需求不要建立原型。 不能随意地增加功能。当一个简单的抛弃型原型达到原型目的时，就不应该随便扩充它的功能。 不要从水平原型的性能推测最终产品的性能。原型可能没有运行在最终产品所处的特定环境中，并且你开发原型的工具与开发产品的工具在效率上是存在差异的。 在原型屏幕显示和报表中使用合理的模拟数据。那些评价原型的用户会受不现实数据的影响而不能把原型看成真正产品的模型。 不要期望原型可以代替需求文档