通过

CMMI 背景信息

  • 项目

“CMMI: Guidelines for Process Integration and Product Improvement”（《CMMI：过程集成和产品改进指南》）是由软件工程研究院发布的面向开发的能力成熟度模型集成 (CMMI) 的权威指南。该手册专门介绍面向开发的 CMMI (CMMI-DEV) 1.3 版本，该版本是截至撰稿之时的最新 CMMI 产品套件内的模型之一。 该模型极其稳定，并且应将在 2010 年后很长一段时间内保持最新。 此外，“CMMI Distilled: A Practical Introduction to Integrated Process Improvement”（《CMMI 精选：集成过程改进实践入门》）也是有关该主题的通俗易懂的实用手册。 有关上述两本手册的详细信息，请参阅本主题后面的其他资源。

1987 年，CMMI 项目作为能力成熟度模型 (CMM) 诞生于卡内基梅隆大学研究中心，即软件工程研究院。 该中心由美国国防部门建立和赞助。 软件 CMM 于 1991 年首次发布，它基于七十年代末到八十年代初之间开展的软件开发项目的诸多关键成功因素。 此外，International Business Machines (IBM) Corporation 所开展的研究以及二十世纪质量保证先驱 Philip Crosby 和 W. Edwards Deming 也为该模型提供了大量信息。 能力成熟度模型这个名称和阶段表示中的五个级别（如本主题后文所述）均从 Crosby 的生产成熟度模型创作而来。 CMM 主要应用于防御程序，已被普遍采用且经过了多次修订和迭代。 CMM 的成功将其开发工作拓展到了软件以外的各个领域。 新模型的持续繁衍使人眼花缭乱，因此美国政府斥资开展了一个涉及 200 多名行业和学术专家的两年期项目，其目标是建立一个集成了系统工程、软件工程和产品开发的可扩展框架。 CMMI 由此而诞生。

对于 CMMI-DEV，请务必意识到它是一个模型。 而不是一个要遵循的过程或规定。 它是一系列已被公认为软件开发和系统工程领域的宝贵财富的组织行为。 为何采用此类模型？ 其用途是什么？ 应如何以最佳方式使用它？ 这些正是有关 CMMI 的关键问题，可能也是最容易产生误解的问题。

为何采用模型？

如果没有组织运作方式、所需功能以及这些功能的交互方式的模型，将很难改进我们的工作。 模型有助于我们了解组织中的离散元素，并且可帮助我们组织语言和讨论需要改进的地方以及如何完成改进。 模型有下列优点：

  • 提供一种有助于交流的通用框架和语言

  • 利用多年经验

  • 有助于用户在专注于改进时铭记宏伟蓝图

  • 通常配备有培训师和顾问支持

  • 可提供有助于解决争执的标准

CMMI 模型的用途是什么？

本教程将告知你该模型的用途在于：对组织过程的成熟度进行评估，并提供过程改进指南以改进产品。 当与软件工程研究院的人员直接交流时，你将获悉 CMMI 是一个风险管理模型，用于指示组织管理风险的能力。 这种指示是组织有可能履行其承诺或提供可吸引市场关注的高质量产品的见证。 另一种观点是：该模型提供了组织在压力下的表现的良好指标。 一个高度成熟化的高性能组织将从容应对充满压力的意外事件，并进行响应和调整，然后继续向前迈进。 一个欠成熟的低性能组织在面对压力时往往会惊慌失措、盲目地采取回避措施，或者抛弃所有过程并恢复到混乱不堪的局面。

CMMI 尚未被证明是组织的经济绩效的良好指标。 尽管高度成熟化的组织可能会更好地管理风险，并进行更准确的预测，但事实证明较成熟的公司会规避风险。 这种规避行为会使公司缺乏创新或带有明显的官僚主义的痕迹，从而导致较长的前置时间，并使产品缺乏竞争力。 欠成熟的公司往往更富有创新意识和创造力，但却混乱无序且不可预测。 其成果的实现往往是个人或管理人员才干不凡的结果。

应如何以最佳方式使用 CMMI 模型？

该模型的设计初衷是用作过程改进计划的基础，而它在评估方面的使用仅仅是作为评估改进的支持系统。 此用途目前成败各半。 人们很容易将该模型误认作一个过程定义，并会尝试照搬它，而不会将其看作一幅标识现有过程中需要弥补的不足的地图。 过程区域是 CMMI 的基本构造块，用于定义目标以及实现这些目标通常所采用的多个活动。 例如，过程与产品质量保证就是一个过程区域。 再如，配置管理。 请务必明确过程区域并非是过程。 一个过程可能跨多个过程区域，而一个过程区域可能会涉及多个过程。

CMMI-DEV 实际上是两个共享相同基础元素的模型。 第一个模型（即最熟悉的一个模型）为阶段表示模型，它显示了映射到 5 个组织成熟度之一的 22 个过程区域。 组织评估将对组织运营所在的级别进行评估，该级别将指示组织管理风险的能力，进而指示其履行承诺的能力。

CMMI 分阶段表示形式

级别 4 和 5 通常称为高成熟度。 较成熟和欠成熟的组织之间通常会有明显差异：前者展现量化管理和优化行为，后者仅仅是勉强运营或照搬已建立的过程。 较成熟的组织很少改动过程，并且常常使用主要指标作为统计上的防御管理方法的一部分。 因此，较成熟的组织往往能够更准确地预测新信息并更快做出响应（假定没有其他官僚主义行为作祟）。 欠成熟的组织往往会展现不凡才干，较成熟的组织可能会在面临压力时盲目照搬过程，并且无法意识到更改过程可能是一种更合适的响应举措。

第二个模型（即连续表示）单独处理 22 个过程区域中每个过程区域内的功能，使组织能够根据过程调整其改进工作，以便创造最大业务价值。 此种表示更符合 Crosby 的原始模型。 根据此模型进行评估将生成功能概况，而不是一个数字。 当然，由于大多数行政管理人员都对组织成熟度有所了解，因此可以将连续模型评估的结果映射到 5 个阶段。

CMMI 连续表示形式

使用阶段模型作为过程改进程序的基础可能会十分危险，因为实现人员可能会忘记 CMMI 不是一个过程或工作流模型，而只提供过程和工作流要实现的目标。 实现这些目标将使组织更加成熟，并提高事件按计划进行的可能性。 最大的失败模式可能是：将达到某个级别作为目标，而创建过程和基础结构的目的仅仅是为了通过评估。 任何过程改进活动的目标都应当是可衡量的改进，而不是一个数字。

在指导过程改进方面，连续模型在一定程度上看似取得了更大的成功，某些咨询公司仅选择围绕连续模型提供指导。 最明显的区别在于，围绕连续模型设计的过程改进程序并没有由成熟度确定的虚假目标。 此外，在连续模型最可能利用组织的经济优势的领域，该模型毫无疑问地更适用于在这些领域进行过程改进。 因此，采用连续模型的组织更有希望收到基于 CMMI 模型的计划的积极反馈。 而且，积极反馈更可能促进一整套有效改进。

CMMI 模型的元素

CMMI 模型分为 22 个过程区域，下表列出了这些过程区域：

首字母缩写词

过程区域

CAR

原因分析及解决方案

CM

配置管理

DAR

决策分析及解决方案

IPM

集成项目管理

MA

度量与分析

OID

组织创新与部署

OPD

组织过程定义

OPF

组织过程焦点

OPP

组织过程性能

OT

组织培训

PI

产品集成

PMC

项目监视与控制

PP

项目计划

PPQA

过程与产品质量保证

QPM

量化项目管理

RD

要求定义

REQM

要求管理

RSKM

风险管理

SAM

供应商协议管理

TS

技术解决方案

VER

确认

VAL

验证

在阶段表示中，过程区域根据每个阶段进行映射，如下图所示。

显示处理区域的阶段表示形式

在连续表示中，过程区域映射到功能分组中，如下图所示。

显示处理区域的连续表示形式

每个过程区域都由所需组件、预期组件和信息性组件组成。 实际上，只需要所需组件即可满足根据该模型进行评估的需求。 所需组件即为每个过程区域的特定目标和一般目标。 预期组件是针对每个特定目标和一般目标的特定实践和一般实践。 请注意，由于预期组件仅仅是一种预期，而不是必需的，这表示特定实践或一般实践可以用等效实践取而代之。 提供预期实践的目的是为了指导实现人员和评估人员。 如果选择了备选实践，实现人员将负责向评估人员提供相应建议，并论证备选实践的合理性。 信息性组件提供的详细信息有助于实现人员开始使用由 CMMI 模型指导的过程改进计划。 信息性组件包括部分一般实践和特定实践，还包括典型工作产品。

请一定要了解，只有一般目标和特定目标才是必需的。 所有其他内容都仅作为指南提供。 CMMI 文献中提供的预期组件和信息性组件的示例往往源自大型防御系统集成项目。 这些项目由卡内基梅隆大学软件工程研究院的赞助公司和支持公司运营。 这些项目可能无法反映你的组织所开展的项目类型，也无法反映行业最新趋势，例如，敏捷软件开发方法的问世。

其他资源

有关详细信息，请参阅以下 Web 资源：

请参见

概念

适用于 Visual Studio ALM 的 MSF for CMMI process improvement