引子

人们在谈起软件过程时，RUP和CMMI是两个出现率最高的两个词，可二者之间的区别与联系并没有多少人对此很明白。

我比较赞同这样的观点，RUP是一个可裁剪的成熟的软件过程框架，而CMMI是一套可裁剪的过程评估标准体系。二者在目的上虽有区别（一个指导，一个评价），但其内在还是有很多联系的：

    * 它们共同集合了几十年来软件界成功组织或项目的最佳实践检验和方法；
    * 它们都具有框架性的特点，目的是为了可裁剪以适用于不同项目、组织甚至领域；

RUP和CMMI都可以用来指导软件过程改进，然而我看到国内多数软件企业偏向于使用CMMI。这并不能说明CMMI比RUP谁更适合指导过程改进，多半是因为ISO给中国企业遗留下来的一种习惯。

诚然，任何行业都信赖于用某种标准来衡量自己（也需要一个统一的标准来衡量），若是达到较高级别的认证，就好像给企业盖上“免检”的标签，成为他们招揽客户时炫耀的资本。

如果要把RUP和CMMI打个比喻，我觉得Crazy English和CET就能体现二者的关系。

当然，二者并不是对立的（如上联系的描述），我倾向于二者的结合，用Crazy English指导自己学习英语，并用CET评价自己的英语水平。

我们不必浪费时间在选择用哪个来改进过程的问题，挑一个你看着顺眼的理解其精髓，因地制宜的应用就是了，最忌讳“拿来”、“硬套”。

一废话起来，我就不容易收住。正题如下，这是转载于UMLChina的一篇文章（他也是转载的：P），也许能回答如标题所问“用CMMI丈量RUP,结果会是怎样”？

大家自己看吧！

RUP的CMMI成熟度2级评估
Markus Grundmann, Consultant, IT Process Optimization
< /TABLE>

　　本文来自于 Rational Edge：这篇文章探讨了IBM Rational统一过程（现在可以作为IBM Rational Method Composer的一部分获得）在帮助软件开发组织获得更高过程成熟度中的作用。它评估了RUP对处于Capability Maturity Model Integration (CMMI)第二级所定义的过程领域的团队的帮助，并指出了为填补空白RUP所需要被补充的领域。

　　现代软件开发的高速度为开发团队造成了一些严峻的挑战：

    * 需求在项目的生存周期中不断变化。
    * 你不能第一次就得到正确的模型，例如，就像你在造一座桥时。
    * 采用最新技术的项目也无法依赖于已证明的技术。

　　正如Standish Group在他们的问题报告（Chaos Report）中指出，这些问题对项目的成功率有巨大影响。1如图1所示，尽管在1994到2000年间，项目的成功率提高了75%，在2000年仍然只有28%的项目如期发布。


图1：来自Standish的软件开发项目成功率Chaos Report 2001
< P>　　IBM Rational统一过程，即RUP，起源于应对上述挑战的一组最佳实践。它帮助软件开发组织决定哪些角色可以最好地执行特定活动，并定义了一组工件（如，成果）来支持这些活动。此外，它为这些元素间的互动和依赖性建立模型，因此也为项目带来更多透明性。

　　RUP采用了面向执行的方法并给出了详细的指导，一些过程改进框架对其进行了补充，比如ISO 9000:2000，eSourcing Capability Model for Service Providers (eSCM)，以及Capability Maturity Model Integration (CMMI)，这些框架在更为笼统的意义下工作。它们强调通过结构化一个组织来实现过程驱动的质量，而把如何执行过程的细节问题留给每个组织。< /P>

　　本文借助“软件功能成熟度模型集成”（Capability Maturity Model Integration for Software (CMMI-SW 1.1)）的评估功能探讨了RUP在帮助组织实现更高的过程质量中的作用。

　　CMMI

　　CMMI通过提供更好的预测性和更高的效率，并最终导致更低的成本和更满意的客户来帮助组织提高竞争力。在CMMI过程改进首期进行的公司（如 Siemens，JP Morgan，Chase和Lockheed Martin）中收集的数据告诉我们，支持一个主要过程改进需要项目涉及的2%到10%的工程能量。但是实现CMMI的收益足够补偿这一努力，如卡内基梅隆大学软件工程研究院 (SEI)发布的调查2所显示的。改进百分比的中心分布如下：

    * 成本降低20%
    * 计划实现程度提高37%
    * 生产力提高67%
    * 缺陷减少50%
    * 客户满意度提高14%

　　 当然，一个CMMI实现需要额外的工程和过程相关的消耗。但是，研究表明，正面效果显然超过了这些消耗：实现的投资回报通常达到5：1。

　　使用CMMI来评估RUP为组织提供了一种将RUP与其它过程和过程模型进行比较的手段，以发现RUP在作为单独过程使用时需要改进之处。经理还可以使用这一评估来发现他们可能有效地使用RUP作为对其组织当前过程的补充的地方。

　　CMMI成熟度2级评估

　　CMMI提供了两种架构表述方式：“连续式”和“阶段式”。

　　连续式的版本将CMMI过程领域分为四个子过程域：

    * 过程管理
    * 项目管理
    * 工程
    * 支持

　　在这个评估中，我将使用阶段式的版本，它按成熟度级别对过程领域进行划分，而这正是本文的着眼点。成熟度级别的定义如下：

　　初始级：过程是浑沌不可描述的。这导致了不可预测性，且过程是不可重复和被动的。

　　受管理级：项目的过程被定义，但是基本是被动的。项目团队确实从涉众处获得承诺，且工作状态对管理是可见的。
　　已定义级：根据组织的过程资产调整过程。相互关系被更好地理解，输出被更为详细地度量，过程管理是前摄的，且结果在性质上是可预测的。
< BR>　　定量管理级：过程通过统计数据被控制和度量，因此结果在数量上是可预测的。

　　持续优化级：过程指出了过程变化的原因并做出自我调整。它包括定义成功因素和把它们加入组织的过程资产中。

　　成熟度级别被定义为过程领域的一个特定集合；每个过程领域组合了一组通过实践实现的目标。这里的评估将把RUP视为实现2级的一个助手。这一级定义的需求包含了最重要的项目管理领域，且是获得更高成熟度级别的先决条件。这里的评估将指出RUP的优点和缺点以及要实现CMMI 2级需要改进的领域。

　　我将使用的方法是一个A类评估方法，它是由SEI开发的，名为过程改进的标准CMMI评估方法（SCAMPI）。A类方法最大限度地实现需求并产生过程比较需要的比率。使用SCAMPI方法——一个“现实”的方法，需要与执行过程和评估工作结果的人进行对话。当仅仅把RUP作为一个产品评估时这些对话是不可能的，而评估RUP实现的单独一个实例会造成失真，因为组织通常会按照它们的组织和具体项目需要调整RUP。因此，在分析这一评估的结果时，我们必须想象一种中立的环境，在这里RUP没有经过被某个组织调整而是在“经典”配置下执行的。

CMMI 2级包含下列过程领域：

    * 需求管理
    * 项目策
    * 项目监督和控制
    * 供应商合同管理
    * 度量和分析
    * 过程和产品质量保
    * 配置管理

　　每个过程领域包含一个或多个目标，你可以通过实现过程领域的实践达到这些目标。实践——CMMI的最小单位，表达了一个目标需求。

　　根据SCAMPI，一个实践可以四种不同程度实现：

　　完全实现：针对这一实践的元素被完成，且没有实质性缺陷。

　　大部分实现：针对这一实践的元素被完成，但是存在一些缺陷。

　　部分实现：针对这一实践的主要元素有所缺失，但是覆盖了实践一部分的元素作为副产品被实现；这一方法有其弱点。

　　尚未实现：实践需求没有实现。
< BR>　　SCAMPI将一个实践定义为完成的如果它至少是“大部分实现”的。如果所有实践都完成了，相应的目标也就达到了；如果所有目标都达到了，过程领域就被覆盖了。你通过实现所有过程领域目标和一般目标实现成熟度级别。例如，一个2级的一般目标是：

　　制度化一个被管理的过程
　　一般目标适用于多个过程领域，因此被分别对待。但是实现它们是必须的。

　　RUP的CMMI成熟度级别2评估

　　表格1-6显示了RUP对CMMI成熟度级别2的六个过程领域的覆盖。

表1：RUP对需求管理过程领域的覆盖

表2：RUP对项目策划过程领域的覆盖

表3：RUP对项目监督和控制过程领域的覆盖

表4：RUP对度量和分析过程领域的覆盖

表5：RUP对过程和产品质量保证过程领域的覆盖

表6：RUP对配置管理过程领域的覆盖

　　两个可以补充RUP的过程领域

　　除去上面讨论的过程领域，我们应该注意到RUP并没有提供对供应商协议过程领域和制度化一个被管理过程的一般目标的足够覆盖。使用RUP的组织可以在这些领域中使用CMMI作为RUP的补充。

　　供应商协议管理

　　RUP没有为供应商协议管理领域过程提供实现。由于强调的是软件开发，RUP假定组织将开发整个产品。这是一个弱点，因为依赖于已证实的解决方案可能比完全自主开发更好；你可以集成现成即用的(COTS)产品或部件同时再创造一个为客户带来价值的新产品。通常，这还可以帮助降低开发成本和缩短发布时间。表7显示了CMMI的供应商协议管理过程领域下的实践；使用RUP的组织可以使用CMMI来补充RUP的指导。

　　表7：RUP对供应商协议管理过程领域的覆盖

　　制度化一个被管理的过程

　　RUP也没有考虑员工培训，因为它将重点放在了项目上而不是周边的组织需要上。尽管它包含了一个涉及员工的活动，它很少谈及职位应该为拥有所需要的技术，经验和能力的人占有。表8显示了CMMI制度化一个被管理的过程这一过程领域下的实践。同样，使用RUP的组织可以使用CMMI来补充RUP的指导。

　　表8：RUP对制度化一个被管理的过程这一过程领域的覆盖

　　结论

　　尽管RUP覆盖了CMMI对成熟度2级97%的需求，如果实现时没有其它任何补充实践，它实际上并不能在这一级别上工作。这是由于它没有包括2级的两个过程领域，而它们包含了项目实现中基本的最佳实践。

　　当然，一个使用RUP的项目可能由于与这两个过程领域完全无关的原因失败，但是在CMMI评估中定义的领域内对RUP加以补充是组织可以借助防止失败的一个手段。请注意我不是要求经理们传达任务——建立大量文档和执行不需要的活动——只为实现CMMI标准。一个项目的最终目标是满足客户的需要，而像CMMI之类的框架是设计来帮助你实现这一目标的。在实际情况中，执行活动和建立工件应该只在它们是项目需要时发生。< /P>

　　幸运的是，RUP是建立在一个可扩展的，允许你通过使用插件来使过程适应你的需要的构架上的。一些现有插件已经解决了我前面提出的一些需要。例如，COTS插件可以用于实现缺失的供应商协议管理。

　　你还可以通过最近为IBM Rational Method Composer解决方案发布的一组工具来实现更多过程领域实践。它们允许RUP的工具驱动定制化并支持插件开发。你可以使用这些工具基于本文的评估，为其它你定义的需求，或将RUP集成到一个现有的，相关主题的组织过程开发插件。

　　组织可能希望额外的实现是单独的插件的形式，这样它们可以从组织过程资产中选择针对具体项目的具体需要（比如，需要哪些技能，COTS是不是一种可能，等等）以及形式化程度的过程组件作为插件。

　　尽管RUP并不需要补充来实现成熟度级别2，我还是推荐组织通过遵从CMMI标准获得更好项目结果。它的公开构架使你能够复用你现有的合作过程。作为一个过程模型属性，这种公开性是一个关键因素，因为它导致无缝集成，当通讯改变过程或过程改进发生时，无缝集成是一个重要优势。RUP 还带有对通过插件和已植入的定制化集成子过程必要的工具，这对寻找最佳开发过程的组织来说也是一个巨大的优势。

　　注释

　　1成功的项目 = 那些按时并在预算内发布的项目。

　　http://www.sei.cmu.edu/cmmi/results.html

　　参考资料

　　您可以参阅本文在 developerWorks 全球站点上的 英文原文。

　　关于作者

　　作为IT Process Optimization的一名顾问，Markus Grundmann曾在IBM研究和开发部进行网格计算的研究，并在Pinnacle Systems从事面向对象开发和构架方面的研究。在其在IBM Rational从事过程集成工作的同时，他完成了商业信息科学的硕士学习。你可以通过他的网站www.MarkusGrundmann.de与他取得联系。

感谢LZ，好文章。好东西