UML – RUP和软件工程

统一过程方法是一个庞大和复杂的知识体系，它几乎囊括了软件开发这一生产过程所需要的知识的方方面面。但同时，也正由于统一过程的复杂和庞大，使他学习起来很困难：要在实际项目中实施统一过程也非常困难，统一过程也是迄今为止最重量级的软件方法。统一过程是一种追求稳定的软件方法，它追求开发稳定架构，控制变更，立足于长期战略，适用于指导大中型软件产品的开发。由于统一过程是一种重量级的方法，因此实施统一过程是高成本的，是一个组织战略的选择，而不仅仅是某一项目的战术选择。实施统一过程不但需要在初期投入庞大的学习成本，也需要在实施过程中投入庞大的管理成本。那我们为什么要投入那么多成本来实施统一过程呢?

一方面是出于提高软件成熟度的需要。我们知道CMM只规定了每个成熟度等级的评估标准，但没有规定如何做才能达到这一标准，与其耗费更大的成本去搜索自己的软件过程，不如采用统一过程这种已经集成了软件活动最佳实践的成熟的软件过程。实际上能够实施统一过程大致已经相当于达到了CMM二级到三级的水平。

另一方面是出于提高软件技术水平和质量的需要。我们知道要生产一个好的软件产品，必须保证需求、分析、设计、质量等工作。统一过程由于集成了面向对象方法、UML语言、核心工作流、工作模板和过程指导等需要知识，使得软件生产工作能够i利用这些成熟的知道来提高组织内整体软件认识水平和开发人员的软件素质，借此来提高软件产品的技术水平和质量。

再一方面，统一过程适于开发稳定的架构，它通过不断的演进来逐步推进软件产品，这一特点使得它特别适合长期战略的软件产品。例如那些长期立足于做某一行业，希望做精做深，做行业整体解决方案的组织。

但统一过程由于太庞大和复杂，相对于轻量级的敏捷方法，例如著名的XP（极限编程）方法来说，显得死板和难以实施。统一过程不但不能快速适应需求的变化，而且变更一个需求要经历复杂的过程和许多额外的工作。对于较小的组织和项目来说，使用统一过程的确有些费力不讨好，也因此招来了许多质疑。

其实这种质疑大可不必，轻量级的敏捷方法和重量级的统一过程都是非常优秀的软件方法，只是它们各有各的适用范围。轻量级的XP方法追求在变化中用最快速的方法适应变更，用小的管理成本保障软件质量。对于中小型公司和中小型软件来说，XP的确是非常有效的软件方法，它能大大降低管理、开发成本和技术风险。不过对于大型公司和大型项目来说，XP就不适用了，这时RUP却非常适合。因为对大型项目来说，一个项目有可能经历几年甚至几十年的时间，涉及几千甚至几万人，如果没有一个稳定的架构，在朝令夕改的方式下项目是不可能顺利实施下去的。

你能想象洛克西德马丁公司用XP的方法来开发F-35战斗机会是一个什么情形吗？没有人清楚地知道将来飞机的整体是什么样，好不容易设计出来机翼，另一个小组说我们决定改变一下气动外形，你们再重构一下吧；没有人知道最后飞机的性能怎么样，反正也造一架出来，要是摔了找找原因，改进改进，重构一下，再造一架……再摔了，没关系，咱们拥抱变更，再造就是了……

显然对这种大型产品来说XP方法是不可接受的，而RUP的稳步推进的方法却正好适合。那XP什么情况下适用呢？如果你是一个杂货店的老板，刚开业不知道什么样的商品受欢迎，没关系，先各进一小批货，卖上一段时间，受欢迎的货品多进，不受欢迎的不进，随时向顾客做一些调查，顾客喜欢什么商品就进什么，不断改进、最后一定会顾客盈门的。这时如果这个老板采用统一过程的方法，先做商业分析、客户关系分析、消费曲线分析……还没开业呢，估计就破产了，或者好不容易做出了一个商业策略，客户兴趣已经改变了。

另外，RUP和XP也不是非此即彼的关系，比如造F35的过程中，对整体飞机来说，用RUP是适合的，具体到零部件倒是大可XP一把，先在风洞里试验试验，不符合条件就更换了再试，最后只要得到最适合的零部件就OK了。

RUP和UML是分离的，所以完全可以根据自己的实际情况来决定采用哪种软件方法，而采用哪种软件方法其实并不妨碍使用UML来做软件的分析和设计。