CMMI 原则和价值

项目
06/09/2015

由 david J。 Anderson. David J. Anderson 是两本书的作者，“软件工程的敏捷管理：运用业务结果约束的理论” 2003 年发布的 [1] 和“Kanban：您的技术业务的成功发展更改” 2010 年发布的 [2]。他是于 1997 至 1999 年间，在新加坡创建敏捷软件开发方法，即功能驱动的开发的团队的成员。他是 2005 年度相互依赖声明定义的敏捷项目管理原则的作者之一。 David 创建了 CMMI 过程改进的 MSF，并且从软件工程研究院合作创作技术说明，“CMMI 或 Agile: 为何不是接受两个!” [3] 他是学习软件和系统联合会的副总裁，http://www.leanssc.org，并主管一家国际管理培训和咨询公司，David J。 anderson & 关联公司，http://www.agilemanagement.net 帮助技术企业通过更好地管理指令和决策以改善其性能。

2012 年 1 月

Anderson 描述如何查看组织通过 CMMI 透镜为管理者、过程工程师和所有包含客户、投资者、主导主体和审计员的外部利益干系人提供有价值的答案。

应用于

Application Lifecycle Management — 应用程序生命周期管理，CMMI

Introduction

The Meaning of Organizational Maturity

Inspiration for the CMMI Model

CMMI is a Model

Understanding CMMI Made Simple

CMMI Appraisals

原始能力成熟度模型 (CMM) 在 1991 年首次发布。十年以后，发展成为 Capability Maturity Model Integration (CMMI)。 CMMI 现在是三个表示某个星座（当它们知道时），并且本文专门引用 CMMI 开发星座 (CMMI-DEV)。 CMM 所开发的更好地帮助美国国防部了解软件项目的大的失败在大型政府购买程序中。基于 CMM 的评估用于确定政府协定的“健身”。随后基于 CMMI 发展成为定义评估方案。

组织成熟度的概念遗迹争论。例如，如何评估组织的成熟度？和组织是否正确具有与其个人的行为和事件不同的行为? 此概念组织中估价在特定成熟度，对于功能指示符提供可靠的工作为政府是连续的辩论问题。但是，我仍然相信并支持 CMMI，并相信通过 CMMI 透镜查看组织能够为管理者、过程工程师和所有包含客户、投资者、主导主体和审计员的外部利益干系人提供有价值的答案。

组织成熟度的含义

CMMI 中的成熟度用于表示在做出决策时估计和管理风险和所判断的方法和功能。术语“成熟”实际上正在使用在此意义上相对于个人的其常见用法。例如，保险人可以告诉我们 18 岁的男性相比 55 岁的女性更容易遭遇车祸。为八年以上的男可以显示更差的判断，当判断处理的决策通信工具时并可以具有足够的体验关于足够估计在特定解决方案涉及的风险。这可能导致某位 55 岁的妇女可避免的故障。保险公司尤其擅长评估风险，因为他们收集统计数据和关联证据。

CMMI 的一大问题是术语“成熟度”的已知贬义性质。总是假定成熟度高比成熟度低更好。应始终继续处理该更大的到期日期。如果我们以个别条款来考虑这个，则它并不总是有意义。保险公司可能会为更成熟的设置更廉价的汽车保险；但是，一个轮式赛车车队可能评估活力和承担风险。对于赛车车队，撞车也是业务的一部分。实际上，从不崩溃的驱动程序应将激发。

此处所需的成熟度级别的消息应与条件和上下文匹配。更多并不一定更好，但是，可以精确标识和估计组织成熟度有助于评估企业在做出项目和产品决策时是否能够管理风险和执行相应的判断。

在成熟级别和实现的可能或交付预期结果之间有强相关性。成熟度较高的组织应具有提供接近所需结果的一个非常有利的机会。这包括可能评估的成熟度和功能，以及可实现的结果，然后相应设置目标。根据预期，较不成熟的组织不大可能达成目标并不大可能交付预期结果。在某一丰富的较不成熟的组织可以通过运气和繁琐的工作的组合实现异常性能时，此硬币的反面是成熟度较高的组织可能会成为风险规避，并只设置易达成的目标。

用于 CMMI 模型的灵感。

原始 CMM 由瓦茨·汉弗莱开发，并首次出现（没有 CMM 名称）在其管理软件进程的书中[4]。灵感来自 20 世纪生产质量保证移动和 Joseph Juran, W 的作品。爱德华兹戴明和菲利浦克劳士比。术语“成熟度模型”和五个级别均从 Crosby 的生产成熟度模型创作而来。但是，必须将 CMM 视为想法的真实集合。术语“功能”几乎从 Deming 创作而来。

Deming 使用具有可能比单词的公共语言了解更深的运行的非常具体的含义的术语“功能”。更准确地说，“功能”可能会被视为系统或系统中的操作的“自然原理”。 Deming 鼓励管理器“确定功能”和统计地进行分析。他开发了“深厚知识”系统 (System of Profound Knowledge)[5]，其目的是用作决策框架，帮助经理对系统设计进行适当干预。 Deming 是真正的系统思想家。在这种情况下，单词“系统”通过人员意味着执行进程。不希望表示技术或任何自动化。

Deming 认为，并编译证据，建议多达 95% 的系统的性能来自系统的设计和不来自工作在系统中的个人的功能。换句话说，为了创建改进，则必须在更改处理上是一个焦点，其中的系统人员工作，而不是在提高各个性能的一个焦点。因此，他相信目标、目标管理，诱导海报或性能较差的惩罚个体。

因此 Deming 提供了一个具有“深厚知识”系统的功能模型，因此，Crosby 提供了一个成熟模型。 Humphrey 追求整合这些概念，并将其引用到软件工程领域，其成果即是能力成熟度模型。

如果专注于评估和因政府合约追求质量成熟度等级，大部分能力建模和 Deming 的影响会从大多数 CMM 和 CMMI 语言中消失。但是，在成熟度较高的情况下定义的过程区域中，可以清楚看到 Deming 的影响。

CMMI 始终应为鼓励在组织的持续改进区域性的诞生框架，因此，始终应为系统考虑方法。与 CMMI 的根中的精益有非常明显的相似之处。

CMMI 是“模型”

CMMI 是了解的组织成熟度和功能的设计。它不是标准，也不是软件开发或项目管理进程定义。本文内容中描述的泛型实践引用该进程的功能，并没有任何给定项目或开发期间产品。例如，下表提到的计划，是指进程实现计划，而不是项目或产品配送计划。

该 CMMI 模型包含 22 个过程区域，和任何组织应继续处理的三个一般目标。

3 个泛型目标如下所示：

22 个过程区域封送到 4 类别：工程，项目管理，进程管理，并且支持。每个过程区域包括一到三个特定目标和所有三个一般目标。对于每个目标，通常有望使用多种做法来实现该目标。在实践中，可能建议部分实践。 CMMI 只需要或建议目标。希望在 CMMI 模型目标中定义的实践，但不强制。如果不存在，必须用等效替换实践替换它们。下表将显示分组过程区域：

组织焦点	过程区域
工程	要求制定技术解决方案产品集成确认验证
项目管理	项目计划项目监督与控制集成管理项目供应商协议管理要求管理风险管理量化项目管理
进程管理	组织过程焦点组织过程定义组织培训组织过程性能组织创新与部署
支持	配置管理过程与产品质量保证度量与分析决策分析及解决方法原因分析及解决方案

该原则非常简单：如果组织会表现出函数已在每个中的目标和，则他们可以添加具有在特定过程区域。

过程区域也分组为各成熟度，为描述的成熟提供简短方法。虽然分组过程区域在多个级别到级别遗迹争论，在最后二十年中组织的观察是模型当前版本 1.3（考虑 CMMI 时 CMM的有效版本 2）通常是正确的。成熟度低且混乱无序的组织会先在成熟级别 2 中定义的进程区域中开发功能，然后在更高级别定义的进程区域中开发功能。

下表将分组过程区域显示到级别。

成熟度	过程区域
5	CAR – 原因分析及解决方案 OPM – 组织绩效管理
4	OPF – 组织过程性能 QPM – 量化项目管理
3	RD–要求制定 TS – 技术解决方案 PI – 产品集成 VER – 确认 VAL – 验证 IPM - 集成管理项目 RSKM – 风险管理 OPF – 组织过程焦点 OPD - 组织过程定义 OT – 组织培训 DAR – 决策分析及解决方法过程与产品质量保证
2	CM – 配置管理 MA – 度量与分析 SAM – 供应商协议管理 PP – 项目计划 PMC – 项目监督与控制 RM – 要求管理
1	在模型级别 1 内不具有过程区域。级别 1 表示未定义进程，该进程不具有通过了解生成其的进程来定义进程或重复结果的内省或功能。在技术上，在 CMMI 评估中，不实现过程区域的目标是模型级别 2 的组织是模型级别 1。这样出现的组织过程将技术上查看作为模型级别1，即使它们逐渐成熟的离未定义 chaos 远。

下表在该主题中的专业术语或每个进程区域的目标中显示概览：

过程区域	用途
CAR – 原因分析及解决方案	调查异常进程问题的根本原因（特殊原因变体，使用 W。爱德华兹戴明的术语），并建议和实现处理更改防止冗余。请注意处理异常行为量化地了解，稳定的进程。每天描述可能会被视为风险管理 (RSKM) 的一部分而不是 CAR。
CM– 配置管理	不仅仅是源代码版本控制，此过程区域涵盖与系统环境、组件配置、平台、中间件、应用程序和文档相关的所有管理。能够成功生成和部署中的工作的代码以下过程区域。
DAR - 决策分析及解决方法	对于在项目或产品开发中的所有关键决策，需要显示考虑到的一组替代项或选项，因此使用了上下文元素评估不同选项的适用性。记录该选项的决策和原因。
IPM - 集成管理项目	CMMI 模型内的项目管理的第二级别暗指某组织可能能够同时管理多个依赖项目。这通常通过使用程序或组合管理办公室实现。
MA – 度量与分析	收集处理数据，项目和产品性能。基于数据以报表形式生成指标和指示。
OPD - 组织过程定义	该组织应有一个或多个在上下文中定义的过程定义。上下文会描述风险配置文件。每个项目可以为该风险和从组织目录选择的过程定义评估，然后正确地定制。
OPF – 组织过程焦点	该组织应认为该进程定义定义并影响功能，提高功能是通过提高的进程进行主要驱动。因此，该组织主动管理其过程定义和监视器（使用 PPQA 过程区域）确保这些定义如下。
OPM – 组织绩效管理	此过程区域封装根据其预期功能统计了解交付过程的程度的概念。可估计更改预期的处理增强功能，并考虑的进程的基本设计基础是否不反映这些预测中观察过程的结果模型，则更改为过程定义做出了。组织通过其进程管理其性能，以满足其业务需要。
OPF – 组织过程性能	此过程区域封装通常被称为“基准”的性能比较概念。OPP 来基准数据中创建过程模型来启用比较。这向组织提供了回答诸如“为[此特定项目]我们应在三个产品团队中选择哪个团队？”之类的问题的能力。
组织培训	在特定实践的各个功能对于进程性能和系统功能是很重要的。有强劲性能的一种良好行为系统将具有强培训能力来减少在本地实践水平的能力中的变化。
产品集成	功能集成多个组件构成一个完整产品和管理需要的组件使它成为可能。
项目监督与控制	收集有关正在进行的项目的数据，将其与计划、投影和模拟比较，并根据数据采取适当措施。
项目计划	基于要求的估计、模拟和分析来计划项目。
过程与产品质量保证	过程主要是符合审核功能。只打算演示正在操作设计的系统。当实际上未按照本意遵循当前进程时，帮助避免潜在的管理错误，改变进程以纠正问题。
量化项目管理	这是 CMMI 模型中的第三级项目管理（最高级别）。它表示统计声音，用于计划、监视和管理项目的定量方法。
要求制定	有一个定义，可重复请求、协调、分析和文档要求的过程。
要求管理	要求对整个项目生命周期中进行跟踪，并且在理想情况下，所提供的配置和原始要求请求之间存在端到端的可跟踪性。
风险管理	虽然整个 CMMI 模型可以显示为用于管理风险的结构，此过程区域特殊地址，“事件驱动风险”或特殊原因变体和每天意外的可能性和影响。此过程区域需要降低风险、缓解措施、应变计划、问题管理和解决方案。
供应商协议管理	能够管理外部供应商，定义协议，管理协定和采用预期产品或服务装运。
技术解决方案	相对于软件体系结构、设计和编码，需要全部技能。
验证	参考客户需求进行接收测试。
确认	针对设计进行测试（技术解决方案中）。查找以确保要生成的产品是作为预想的、设计的，并以此种方法收集，以满足用户需求和其环境中的工作。

对于每个过程区域，可评估功能水平。四个能力等级在 CMMI v1.3 中定义：

0. 不完整

1. 已执行

2. Managed

3. 已定义

如果每个特定目标都实现，并且某些一般目标也实现，则特定过程区域的功能将被估价为 1 级 –已执行的。功能级别 1 表示团队成员了解如何执行并执行它。但是，如果从统计角度分析，特定做法不一定显示出稳定性。遵从实践，但是仍缺乏一致性。功能级别 2 表示团队了解其工作原理并有一些性能工作可预测并且会表现出统计控件技能的级别。可能是培训或协作工作实践就地可以生成大于团队成员的一致性。功能级别 3 表示这种技巧和功能的精通开发将实现该目标的新增功能和改进的技术。级别 3 功能指示所有统计分析都需要在对基础技术或实践的每次显式更改后重新基线。

了解 CMMI Made Simple

该 CMMI 模型基本上，指出其执行的新和非成熟的组织，首先，将在开发工作的函数的管理配置和源代码管理，收集有关项目的数据和工作，计划项目，跟踪要求，监视进度并根据比较实际数据的措施计划。这是成熟度 2 的精髓。

当到期日期第 2 级功能排列就绪，该组织及其人员转移其注意力到其他考虑，因此，定义要求功能，测试，体系结构和设计，集成和定义过程，以便可以重复启动形成。因为内容稳定多，了解区域性和管理方式影响性能如何合并和需要系统思维方法提供进一步的性能改进的希望的领悟。事情变得更加稳定和日常问题，如计划和项目监控成为了第二个性质，在做决定之前是时候考虑风险管理和分析备选项和选项。协调多个依赖项和共享资源的改进的主导可以形成。可能会出现培训计划、指导方案、师徒辅导方案或简单程式化的协同工作，以提高能力和提升整体绩效水平。如果需要，某个内部审核或处理质量保证功能可能形成。所有这些是成熟度 3 的精髓。

当组织在内置的成熟度 3 运行时，内容运行与钟表器相似。该组织提供其承若，并被视为非常可靠。高级信任在与客户的关系上显示。高级经理开始提出问题（如“为进一步改进我应向什么位置投资？”和“哪个团队生成最好的经济绩效？”管理层开始对功能和性能形成更深入的了解，并意识到它们可以使用模拟和统计分析改进产品质量、促进客户交付和提升满意度。管理决策现在是完全客观的以及具有统计数据作支撑。这是成熟度 4 组织的精髓。对于大多数高级经理，成熟度级别 4 表示他们的理想状态。所有运行与钟表器相似，并且具有比较性能数据并可以根据具有高级准确性的承诺发送。极大地提高经济绩效和组织的性能是高度可预知的。

成熟级别 5 行为通常在组织实际达到级别 5 很久之前出现。通常，在成熟度为 3 的组织中会查看到根本原因的分析。它为何使用第 5 级功能，是不是根源分析使用定量数据已完成并为统计上的防御。还可能在该组织可能真正被认为为成熟级别 5 之前引发进程创新的规范化流程的问世和部署的提高。在第 5 级，制度化过程提高并已来回了灌输给组织的区域性。区域性是一个始终质询该生成和查找已增强功能、改进的产品质量和改进的经济绩效。

CMMI 评估

由评估建立的 CMMI 成熟评级。具有执行评估的标准过程，SCAMPI – 针对过程改进的标准 CMMI 评估方法。对这进行介绍以便带给该过程某些重复性以及对其结果的信心。评估中严格的三个级别被称为类 A、B 和 C，类 A 是最严格的。选件类 A 评估对于为公共记录或美国国防部可接受要求的模型级别分级是必需的。

所有类 A 评估和大多数类 B 和 C 评估由软件工程研究院授权的 CMMI 评估人员执行。这些顾问在授权给实践前已通过完整的培训计划。某些评估人员是通过附加、培训被指定为 CMMI 较成熟主管评估人员。寻求模型级别 4 或 5 的评估的组织，必须依靠高成熟度的主要评估人员参与处理。

评估寻求证据进行实践实现在 CMMI 的过程区域中的目标。组织运行项目的组合并可能分成多个业务，复杂的公式用于决定有多少个项目必须评估范围。这样做的目的是确保项目样本集的公平复盖率，演示该组织具有每个要求的进程区域内的制度化功能。评估人员将确定要基于此公式评估的项目。

在每个项目内评估，必须收集演示做法的证据，需要显示在过程区域内的足够功能，已经完成。对于每种做法，评估人员都会寻求确凿的证据，此类证据称为项目 (artifact)，通常存在于记录性证据如计划、源代码、设计和架构文档中。此外，查找确定。确定通常是传闻证据，例如讨论工作进行的人员，例如描述参与计划会议的轶事。评价通过采访项目涉及人员集合的确保。确定可以增强记录性证据或反驳它，导致评估师对文档有效性表示怀疑。

CMMI 评估不是该很有用 CMMI 模型所需的。 CMMI 帮助软件开发组织了解其功能和截止日期对他们的客户和其他外部利益干系人所需的比较。大致了解组织将 CMMI 模型映射到何处提供了一种评估组织在压力下的反应能力和应对异常的能力的方法。观察到的执行成熟度高的活动却没有执行低成熟度行为的坚实基础的组织，通常是不可预知的。也就是，当呈现高成熟行为且这是值得推荐时，这些较成熟实践不是可靠的，因为它们不是在坚实的基础上生成的。

CMMI 评估通常用作方式验证组织过程改进计划。这将产生“通过测试”的压力。焦点将成为遵循各过程区域内的做法并显示相关证据的演示之一。可以是来自非常重要的焦点丢失 – 显示针对客户期望的功能 – 并通过显式管理操作提高该功能。 “通过考试”的这一焦点通常在组织内导致明显的副作用和功能障碍。因此，CMMI 开发了该行业中的批评者的一个强主体。在我i坚信 CMMI 模型有效且为组织内的管理人员提供有价值的见解（会改善功能、性能以及提高用户满意度）时这是个遗憾。

[1] Anderson, David J.，软件工程的敏捷管理：运用业务结果约束的理论，Prentice Hall PTR，2003 年。

[2]Anderson, David J.，Kanban：您的技术业务成功的发展更改，Blue Hole Press，2010 年。

[3] Glazer、Hillel 和 Jeff Dalton、David J.。 Anderson, Michael D. Konrad, Sandra Shrum, CMMI 或 Agile：为什么不接受两个！，软件工程研究院，2008 年 11 月

[4] Humphrey, Watts S.，管理软件进程，专业的 Addison Wesley，1989 年。

[5] Deming，W。爱德华兹，行业的新经济，政府，培训，第 2 个编辑，MIT 按，2000

通过