软件测试与可靠性评估方法研究

　　3.3 实现需求

　　当前的软件开发过程常常采用迭代方式进行开发，逐步求精，以降低风险和成本。对迭代的次数，每次迭代的里程碑，要实现的目标，及可提交的成果必须有可验证的清晰的计划。项目管理是一种艺术，迭代规划及里程碑定义都是一种挑战、一种艺术，但项目管理不在本文讨论范围。

　　3.4 需求变更

　　需求变更是正常的，也是难免的，应允许用户和开发团队自身对需求进行变更。变更处理的关键在于跟踪和控制，如何使产生的影响应得到控制，这属于配置管理的内容，也不在本文讨论范围。
原型在软件过程中的定位如下图所示：

图1 软件原型的定位

　　实际上我们可以把原型看得更为广义一些。任何用户或者内部演示的材料，都可以看作为原型。例如，如果你的产品是某种通用的或者行业解决方案，虽然你其实还没有产品，但先做出一个原型，再加一个漂亮的白皮书，就可以在市场上进行预销售了。

　　对于抛弃型和演化型原型来说，也不是绝对的。演化型原型中必然会不断抛弃一些内容，而抛弃型原型，尽管在完成历史使命后不再使用，但很多思想以及部分设计还是可以继承的。

　　4 原型方法的一般过程

　　基于原型方法在整个需求过程中的地位，我们需要把原型法和需求处理放在一起进行讨论。采用原型法的一般过程如下图所示：

图2：原型法的处理过程

　　在上图中已经清楚地描述了原型的处理过程，值得一提的是，原型不仅用于给用户或者最终用户进行评议，同时完全可以在公司内部组织评议，看看我们周围吧，多数程序员对技术的兴趣远远高于对需求的兴趣，因此其对系统的理解并不会比市场人员或者项目经理理解的深多少。这里的公司内部人员角色可以包括很多，系统分析员/程序员自身、项目经理、部门经理、用户代表、领域专家、测试人员等等，不同的角色往往会在其不同立场对系统提出中肯的意见来。

　　另外值得注意的是界面设计的引入。我们认为将界面风格在原型阶段即进行基本确定是一种优化的做法，因为软件前期对界面的确定可以避免后期开发时对界面进行统一调整所带来的不必要的成本花费，良好的界面也可以使客户增加对系统的好感，当然，但愿用户不要只是欣赏界面而忽略了他们对系统功能的思考。要知道，如果仅仅是让用户看到美观的界面，那么整个原型几乎是白做了。
　5 使用原型方法的相关问题探讨

　　5.1 为什么要采用原型法？

　　原型对一个项目取得成功具有重要的意义。俗话说：隔行如隔山，实际上软件公司很难保证其制作的软件正好就是用户所需要的，用户也很难一次性把其真实的要求完全提交，开始阶段提出的往往只是对系统的期望，和比较模糊的设想而已。而原型系统为用户提供了一个靶子，看着原型系统，用户往往就能进一步提出他们的真正想法。显然软件公司明确用户需求的最佳方式就是为用户提供原型并由用户进行评价。

　　也许，跳过原型可以节省时间和前期成本，但你应该注意到，跳过原型的话，后期变更的成本会明显增加。

　　5.2 为什么在需求说明书之外需要原型？

　　1）眼见为实，文字具有歧义性，不同的人理解都不相同；

　　2）最终用户往往在看到一套可运行的系统的基础上，才可能提出其真实的意见，如果到最终提交时才看到 这样的系统就为时太晚。这也是以前无数软件开发留下的教训；

上一页  [1] [2] [3] [4] [5] [6] 下一页

【责编:Luzi】