由于瀑布模型的特点（文档是主体），很多的问题在最后才会暴露出来，为了解决这些问题的风险是巨大的。"在迭代式生命周期中，您需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件，这样就可以核实是否已经降低了目标风险。"（RUP）

快速原型（Rapid Prototype）模型是我喜欢采用的另一种模型。快速原型模型在功能上等价于产品的一个子集。注意，这里说的是功能上。瀑布模型的缺点就在于不够直观，快速原型法就解决了这个问题。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。这个产品只是实现部分的功能（最重要的）。它最重要的目的是为了确定用户的真正需求。在我的经验中，这种方法非常的有效，原先对计算机没有丝毫概念的用户在你的原型面前往往口若悬河，有些观点让你都觉得非常的吃惊。在得到用户的需求之后，原型将被抛弃。因为原型开发的速度很快，设计方面是几乎没有考虑的，如果保留原型的话，在随后的开发中会为此付出极大的代价。至于保留原型方面，也是有一种叫做增量模型是这么做的，但这种模型并不为大家所接受，不在我们的讨论之内。

上述的模型中都有自己独特的思想，其实现在的软件组织中很少说标准的采用那一种模型的。模型和实用还是有很大的区别的。

软件生命周期模型的发展实际上是体现了软件工程理论的发展。在最早的时候，软件的生命周期处于无序、混乱的情况。一些人为了能够控制软件的开发过程，就把软件开发严格的区分为多个不同的阶段，并在阶段间加上严格的审查。这就是瀑布模型产生的起因。瀑布模型体现了人们对软件过程的一个希望：严格控制、确保质量。可惜的是，现实往往是残酷的。瀑布模型根本达不到这个过高的要求，因为软件的过程往往难于预测。反而导致了其它的负面影响，例如大量的文档、繁琐的审批。因此人们就开始尝试着用其它的方法来改进或替代瀑布方法。例如把过程细分来增加过程的可预测性。这个方面的讨论我们会在第5小节中继续

5、RUP和XP

RUP是瑞理（Rational）公司经过不断的实践和理论总结发展出来的一套软件开发统一过程（Unified Process）的思想集和方法集。还记得我们在第一章的那张图吗，那就是RUP的核心图。RUP把软件开发过程分成4个阶段（Phases）和9个核心工作流程（Core Workflows），通过一次次的迭代（Iterations），完成整个的软件生命周期。RUP可以把软件开发过程分到非常细小的单位，每个角色（Workers）都参与活动（Activities），产生出工件（Artifacts）。由于精密的控制，所以RUP可以胜任于超大型的项目开发。虽然RUP定义了很多微小的活动，但是由于CASE工具的使用，它并不会像传统瀑布模型那样陷入文档的海洋中。RUP通过适当的剪裁，同样可以试用于较小型的项目。

XP（Extreme Programming），极端编程。不过好像并没有这样翻译的（听上去像是计算机领域的极右组织）。它是由Kent Beck大师提出的。大师在经历传统软件开发的痛苦之后，希望能够找到一种优秀的软件开发方法。大师总结了大量的软件的成功和失败的因素之后，提出了改进软件开发方法的四个要素：沟通（communication）、简单化（simplicity）、反馈（feedback）、勇气（courage）。这形成了XP的核心价值观。在经历了数年的发展，XP在软件开发的各方面都发展出了众多的方法来支持软件开发。

制定了大量的规则的RUP方法被称为重量级（Heavyweight）的方法，而像XP这样只制定少量的规则来规范行为的方法被称为轻量级（Lightweight）的方法（实际上，现在有一种倾向称这种方法为Agile方法的）。近来，也看到一些文章在讨论两种方法孰优孰劣。例如：XP兴起，RUP不适合中国国情等。我想，这和以前大家讨论C++和Java谁好的性质是一样的。方法都有两面性，只有最适合的方法，没有最好的方法。我在实践中也感觉到，国外的理论确实不能照搬于中国，毕竟中国人的人文环境和国外相差太大了。不过，RUP不适合的，我想，XP也未必会适合。如果说，有人把RUP的一整套东西生搬硬套，导致了最后项目失败的结果的话。这种行为无异于刻舟求剑。

在我看来，RUP就像是一个软件工程思想和方法的大百科全书。在其中，你可以看到诸子百家的论调，可以了解软件工程的整个演化过程。RUP是很值得你投入大量时间去研究的东西的。一个武林高手走进了少林寺的藏经阁，你可以想想，那是一种什么景象。XP，更强调团队的充分交流，最大限度的发挥人的创造力。它并不制定大量的规则来限制人的行动（必要的规范是必须遵守的），开发的团队中的每一个人都能自由的发挥想象力，毕竟，软件是创造性的劳动（这听起来像是共产主义实现了一般）。至少，国内的公司都应该学习XP的一条规则：一周只工作40小时。相比较之下，RUP比较适合大企业、大项目，因为大的团队往往需要法制；XP适合于小团队，比较能够发挥小团队的创造力。但是在实际中，也有例外的情况。例如XP方法的第一个项目就是克莱斯勒公司的一个名为C3的大型项目。

在现实中，RUP和XP应用于目前中国的软件企业都有一定的难度。有一些来信来问我，RUP真的适合中国的企业吗？我会直接告诉他们肯定不适合。对RUP这个庞然大物来说，很难去评定它的优和劣。关键在于它裁减以后的样子。我看到过一篇文章，是讨论如何将RUP裁减适合XP思想的方法的。所以RUP的使用要很小心。一个高明的铁匠用铁锤可能可以打出一把好兵器，如果是普通人搞不好就会砸到脚。

提升企业的内力值并不是一两天的事情，这需要长期的投入和锲而不舍的努力。大刀阔斧的引进一整套流程并不是不行，只是猛药伤身这个道理大家也应该懂得。很多年轻有为的软件界人士希望在自己公司中引入先进的开发理念，但是在真正实施时，往往会被碰得头破血流，也有这方面的原因存在。对他们，我是很佩服的。

6、结语

虽然该章的名称为需求过程，其中却花了一些篇幅来讨论软件工程中的概念。主要的目的是为了大家能够从整体的角度来理解需求过程，而不要把