本文对 CMMI 和 RUP 的结合进行了全方位的探索：为什么这么做？如何开始？将会面临哪些挑战？以及 RUP-CMMI Mapping 的 Wipro 插件程序如何能够为您所在机构的过程提供支持？请参见本文结尾处的 Webinar 链接。 在利用 CMMI® (Capability Maturity Model® Integration) 创造商业利益成为许多公司的关键目标的同时，削减定义周期和 “快速跟踪” 实施却是难于定义或描述的。CMMI 由于其架构的规模和复杂性，已经让许多公司望而却步；它涉及到 22 个过程域和 43 个特定目标。除此之外，尽管有一些方法能够将 CMMI 和敏捷方法结合起来，但是采用更加敏捷实践的尝试看起来同该框架并不太一致。 有相当多的标准支持过程管理系统的设置。每一个标准都提供一组开发和交付高质量软件应用程序的最佳实践。诸如 CMMI 这样的过程模型提供设置一个过程框架和测量其性能和成熟度的指导。与此同时，像 IBM® Rational Unified Process® 这样的架构提供可以被进一步定制的过程定义。 CMMI 所描述的是软件开发方法 “是什么”，而 RUP 的目标则是具体到 “如何做”。也就是说，CMMI 提供设置过程架构的指导，并且测量其性能和成熟度，而 RUP 提供可复用的过程定义，并且能够在 CMMI 的指导下逐行定制。 在本文中，我们将探索 RUP 和 CMMI 相结合的可能性，使其最大限度的协同工作，最小限度的冗余，并且处理它们共同定义的过程中的任何一个差异。那些将这两个架构结合起来的公司，将会从它们所提供的过程指导和评估能力方面获益匪浅。为了从这一结合中充分得到收益，现存的差异就需要被处理。 为什么要将 CMMI 和 RUP 结合起来？为什么一直执行 RUP 的公司需要关注另一款过程模型，例如 CMMI 呢？为了回答这个问题，您既需要理解 RUP 也需要理解 CMMI。这些标准有很多共同之处，也表现出许多独特的性质，这些性质使得公司将过程定义在这两种过程模型的基础上都十分有价值。 我们从总结 CMMI 和 RUP 分别 “是什么” 开始。就其关键方面而言，CMMI 是：
图1描绘了 CMMI 的结构。 
图1：CMMI 的结构 就其关键方面而言，RUP 是：
图2描绘了 RUP 的结构。 
图2：RUP 的结构，正如 RUP 产品本身所描述的那样 一个基于 RUP 和 CMMI 的结合的过程架构能够帮助企业最大限度的从这两种高价值的过程标准中获益：RUP 作为强大的而且已经被证明的软件开发最佳实践，有助于访问开发过程和关注它们的持续提高——所有这些都是基于一个预先打包并且可以复用的插件程序的支持，我们将在下面对其加以讨论。 RUP 定义了那些能够在项目团队之间易于配置的过程。使用 RUP 执行 CMMI 能够有助您在交付高质量软件的过程中对 RUP 过程进行控制和监测。 应用 RUP/CMMI 过程架构的优势包括：
映射 RUP 和 CMMI为了避免在定义 RUP 和 CMMI 结合过程架构中的冗余，分层比较这两个过程模型是很重要的。辨认出它们之间的差异能够有助于确保最终的架构能够处理您开发周期中的所有方面。 尤其是对于 CMMI 层次3来说，43 个特定目标需要被映射到 RUP 工作流和活动中。当差异被辨认出来后，来自 CMMI 的元素就能够补充 RUP 过程来消除这种差异。表1中对两个过程的元素做了逐一的比较，这是识别差异和创建所缺少的元素来补充 RUP 的第一步。 表 1: CMMI 和 RUP 元素的比较
在定义以上映射的操作中，我们将 CMMI 视作一个参考，并且将 RUP 过程映射到 CMMI 上。基于对每一个过程域的考虑，相似的映射应该在该级上被执行，如果有可能的话，由一组专家负责执行作用于软件开发和维护的 RUP 和 CMMI。更好的做法是指派两组专家去执行该映射，一组负责 CMMI-to-RUP 透视图，另一组负责 RUP-to-CMMI 透视图，然后通过集中讨论对它们之间的显著区别加以处理。 表2描绘了与 RUP 相关的 CMMI 层次2和层次之间的映射和 “差异分析”。 表 2: RUP 和 CMMI 的映射结果
表3更加详细的显示了从一个 CMMI 过程域到 RUP 的映射的结果 表 3: 一个 CMMI 过程域的详细映射结果
RUP 到 CMMI 映射的更深一层限定了定义过程资产的映射。在这一层上，小心的分辨 RUP 中的差异是十分重要的，因为在结合这两个框架方面，这是典型的“真金火炼”。表 4 是一个需要在 RUP 中被创建或者增强的过程元素的快照，它用来处理同 CMMI 的兼容性问题。 表 4: 是 RUP 适应 CMMI 的额外的元素
图3描绘了如何将 RUP 资产插入到 CMMI 技术解决方案过程域中。 
图3：将 RUP 资产插入到 CMMI 技术解决方案过程域中 图 4 显示了修改过程资产的截图，它以 RUP 的格式定义。 
图4：新的 RUP 过程资产的截图 在 RUP/CMMI 结合中面临的挑战及其解决方案通常，希望执行 RUP 和 CMMI 的企业最终定义了单独的过程架构。许多企业使用一组 RUP 过程用于开发（往往配置 RUP 过程资产完全使用“现有的过程”）。然而，为了和 CMMI 兼容，他们定义了单独的 RUP 过程。这就在过程文档中产生了冗余，并且给 RUP 和 CMMI 的执行都提出了挑战。 增强您现已存在的 RUP 过程框架的一个更加有效的解决方案是，使其同 CMMI 的最佳实践相符合。如同上面的 CMMI-RUP 映射中所描绘的那样，RUP 几乎覆盖 CMMI 所要求的 80% 的过程域。所以问题来了，如何才能最好的处理其余的 20% 从而使得 RUP 完整起来并且同 CMMI 透视图向符合呢？ 面向 IBM Rational Method Composer 的 RUP-CMMI 映射的 Wipro 插件程序能够处理本文中所讨论的 RUP/CMMI 结合的需要。它提供了经过验证的程序、最佳实践、模板、指导、以及其他来自 RUP 的过程资产，用基于上面所描绘的差异分析的额外的架构元素对其加以补充。该插件程序充分借鉴了 Wipro 在遵从 CMMI Maturity Level 3 要求方面所积累的经验和过程成熟度。 图5描绘了包括在插件程序中的若干资产。 
图5：针对 RUP-CMMI 映射的 Wipro 插件程序 如果需要的话，这些架构元素能够被进一步增强或者修改，以适合公司的特定需要。Rational Method Composer 的过程创造能力在执行定制和管理方面，提供了额外的灵活性。 参考资料学习
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||