4 原型方法的一般过程
基于原型方法在整个需求过程中的地位，我们需要把原型法和需求处理放在一起进行讨论。
在上图中已经清楚地描述了原型的处理过程，值得一提的是，原型不仅用于给用户或者最终用户进行评议，同时完全可以在公司内部组织评议，看看我们周围吧，多数程序员对技术的兴趣远远高于对需求的兴趣，因此其对系统的理解并不会比市场人员或者项目经理理解的深多少。这里的公司内部人员角色可以包括很多，系统分析员/程序员自身、项目经理、部门经理、用户代表、领域专家、测试人员等等，不同的角色往往会在其不同立场对系统提出中肯的意见来。
另外值得注意的是界面设计的引入。我们认为将界面风格在原型阶段即进行基本确定是一种优化的做法，因为软件前期对界面的确定可以避免后期开发时对界面进行统一调整所带来的不必要的成本花费，良好的界面也可以使客户增加对系统的好感，当然，但愿用户不要只是欣赏界面而忽略了他们对系统功能的思考。要知道，如果仅仅是让用户看到美观的界面，那么整个原型几乎是白做了。
5 使用原型方法的相关问题探讨
5.1 为什么要采用原型法？
原型对一个项目取得成功具有重要的意义。俗话说：隔行如隔山，实际上软件公司很难保证其制作的软件正好就是用户所需要的，用户也很难一次性把其真实的要求完全提交，开始阶段提出的往往只是对系统的期望，和比较模糊的设想而已。而原型系统为用户提供了一个靶子，看着原型系统，用户往往就能进一步提出他们的真正想法。显然软件公司明确用户需求的最佳方式就是为用户提供原型并由用户进行评价。
也许，跳过原型可以节省时间和前期成本，但你应该注意到，跳过原型的话，后期变更的成本会明显增加。
5.2 为什么在需求说明书之外需要原型？
1）眼见为实，文字具有歧义性，不同的人理解都不相同；
2）最终用户往往在看到一套可运行的系统的基础上，才可能提出其真实的意见，如果到最终提交时才看到这样的系统就为时太晚。这也是以前无数软件开发留下的教训；
3）便于发现问题，及时纠正；
4）便于进一步展开，并取得用户的细节需求；
5）体现原型的其它功能：便于公司内部如经理、市场部等对软件提出意见，便于开发人员对整个产品达成统一认识，等等。对内部人员来说，同样地，一套形象的原型也远胜过一堆专业术语文字；也就是说，原型对软件公司内部也十分重要。这些评价工作无形之中改进了项目质量。
5.3 原型方法有什么风险？
任何方法都是有利有弊，在我们可以探讨一下原型方法可能存在的风险。以下是一般软件公司所担心的风险：需要付出前期进度和人力成本；由于程序员对问题的不了解而效率低下，受客户牵制而在原型上反复修改；因为仓促设计而做不利于进一步在其基础上继续开发；由于过早展示原型给客户，使得客户可能提高其期望值，并提出更多离谱的要求，等等。
值得一提的是原型方法的主要价值之一就是尽早揭示软件中可能存在的风险及不确定因素，尤其是关于用户需求一致性方面的风险。
5.4 原型方法和其它方法或过程的关系如何，是否一致？
生命周期法中并不包括原型，或者说没有明确提供原型的概念和定义。原型可以认为是需求分析中的一个子部分。另外，应该说原型方法是对生命周期法的有益补充和完善。
RUP中是最优化的统一软件过程，但RUP中似乎没有提到原型，RUP的核心过程是在迭代中精化。我个人的见解是，原型非常类似于第一次迭代的过程和结果。实际上，如果把原型看作为第一轮交付的成果，那么原型的很多不利之处，诸如花费前期成本等等，这些担心都将变得不复存在。
XP方法对原型非常推崇，这是因为XP方法非常强调需求的重要性