3 原型在软件过程的地位

　　软件的根本目的是实现用户的需求，提供用户日常使用，解决用户工作中有所不便的问题，提高其工作效率，改进质量，加强管理控制，最终直接或间接地提高其效益。因此软件开发本质上就是需求的处理和实现，而软件原型对需求确定来说具有非常重要的意义。原型方法包括2个基本过程，即原型制作和原型评价。
如果从需求角度看软件过程，我们不妨可以把软件过程这样划分：

　　3.1 需求收集和分析

　　搜集需求得到需求说明书，了解软件要做什么，做成什么样，解决用户什么问题。

　　这时候软件公司以书面文档方式提出，例如需求问询表等。

　　3.2 提供原型并进行评价

　　制定原型开发计划，根据用户需求及不确定的高风险部分进行原型开发，在内部进行原型评价，请客户进行原型评价，以保证确实反映了用户的真正想法。

　　3.3 实现需求

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

　　3.4 需求变更

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

图1 软件原型的定位

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

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

　　4 原型方法的一般过程

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

图2：原型法的处理过程

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

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

。