软件原型方法探讨

在进行需求分析时，总会遇到这样几种情况：
（1）客户说不清楚需求；
（2）由于政策，业务原因，需要对需求进行变动；
（3）分析人员或客户理解有误。
这些情况往往是在完成编码时暴露出来的。直接的后果就是要求程序人员返工，重新编码。为了赶进度，要求程序员加班加点的干，造成手下人员怨声载道。如果反复如此，就会直接打击大家对这个项目的信心，使这个项目趋于失败。
怎样才能避免这样的情况发生呢？
    我认为用户应该尽早地介入项目是其中的关键因素。但是我们也不应该忘记一点就是用户不太懂电脑技术，你和他们讲uml的术语：什么用例，什么类图，什么活动图，效果肯定不会太好。我们需要令外一种和用户更方便的交互方法，这就是软件原型方法。

1.软件原型方法概述
在软件开发过程中，原型是软件的一个早期运行的版本，它最终反映系统的部分重要特性。如果在获得一组基本需求说明后，通过快速分析构造出一个小型的软件系统，满足用户的基本要求。使得用户可在试用原型的过程中得到亲身感受和受到启发，做出反应和评价。然后开发者根据用户的意见对原型加以改进。

2.软件原型方法处理方式
　　原型方法的处理方式基本上有2种不同类型，即抛弃型和演化型。
如果用户认为这个版本和用户的期望有较大偏差，那么就可以抛弃原型。在取得用户更明确需求基础上重新开始设计与开发；如果用户认为这个版本和用户的期望比较吻合，那么就在原型的基础上继续开发，并获取新的需求。
原型系统不同于最终系统，他要求快速实现，投入运行。所以，必须注意功能上和性能上的取舍

3.原型方法基本要求
对原型的基本要求包括：
* 体现主要的功能；
* 提供基本的界面风格；
* 各主要功能模块之间能够建立相互连接。

4.原型方法实施的关键
我认为原型方法实施的关键是需要专门的需求分析人员，他既要懂业务，又要懂技术，还要和用户关系比较好。
主要职责：
能把业务问题转化为技术问题，避免程序员对业务问题不了解，做无用的编码
能把用户的不合理要求，用委婉的方法给用户解释，让用户放弃不切实际的想法。
了解客户的心理，能把用户急需的功能和急需的解决的问题先整理出来。

5. 原型方法和其它方法或过程的关系
　　生命周期法中并不包括原型，或者说没有明确提供原型的概念和定义。原型可以认为是需求分析中的一个子部分。另外，应该说原型方法是对生命周期法的有益补充和完善。
　　RUP中是最优化的统一软件过程，但RUP中似乎没有提到原型，RUP的核心过程是在迭代中精化。我个人的见解是，原型非常类似于第一次迭代的过程和结果。实际上，如果把原型看作为第一轮交付的成果，那么原型的很多不利之处，诸如花费前期成本等等，这些担心都将变得不复存在。
　　XP方法对原型非常推崇，这是因为XP方法非常强调需求的重要性，甚至要求客户参与开发过程。但原型方法和XP也有区别。XP是分批交付，先做一个几个功能点的版本，完成后再每个开发周期往上面加其它功能点，而原型法一般要求做出比较完整，能覆盖主要功能点的粗略的版本。XP方法仁者见仁，智者见智，不一而举。

6. 如何避免项目团队做原型的时候出现部分人员闲置
　　在项目管理中，对人力资源的调配应和项目进展相匹配。实际上在用户接触到原型制作的同时，可以进行项目计划、架构设计、技术培训以及技术难点攻关等等。如果从广义上理解原型的话，架构设计者甚至可以设计出一种用户开发团队使用的所谓框架原型，包含了主要的设计成分、模板和示例。比较理想的结果是，当原型完成后，需求分析、架构设计和界面风格设计都趋于完成，从这一点可以看到，原型方法可以作为快速软件开发的重要手段。

 本文欢迎转载，但转载时请注明出处

 

 

我觉得不要化太多的精力在原型上，这可能会造成项目成本的浪费，原型完全可以借鉴既有项目或一些框架来完成，目的是完善用户需求。

XP一点都不推崇原型。XP的逐次交付和原型法完全不同，原型对质量没有要求，对形式也没有要求，只要能达成沟通需求的目的皆可，XP的每一次迭代都是同样的高质量要求。


这需要由经验丰富的架构师领衔.有希望达到这样理想的结果。

不赞同你的看法。在很多情况下，软件的开发都是摸着石头过河，前期我们不知道会有怎样的“额外需求”，如运营方面的需求、市场方面的需求，以及项目本身功能完善方面的需求，我们无法预知。因此，采用原型开发模式恰到好处。

RUP每一次迭代是需要交付可运行的软件的，它只是原型的一部分，也是系统的一部分，而不是全部

所谓逐次交付和进化式原型可以认为是一样的。