CMMI – 快速指南
CMMI – 快速指南
SEI CMMI – 概述
过程改进是持续改进。我们永远无法达到完美。在本教程中，我们将学习 CMM，它是一个不断发展和改进的模型，其重点始终是做得更好。我们的触及范围应该总是超出我们的掌握范围。
什么是 CMM？
-
CMM代表ç apability中号aturity中号奥德尔。
-
侧重于来自各种知识体系的基本实践和过程的要素。
-
描述常识、高效、行之有效的经商方式（您应该已经这样做了）——而不是一种全新的方法。
-
CMM 是一种评估和衡量组织软件开发过程成熟度的方法。
-
CMM 以 1 到 5 的等级衡量软件开发过程的成熟度。
-
CMM v1.0 由美国匹兹堡卡内基梅隆大学的软件工程研究所 (SEI) 开发。
-
CMM 最初是为软件开发和维护而开发的，但后来它被开发为 –
-
系统工程
-
供应商采购
-
集成产品和工艺开发
-
人 CMM
-
软件获取
-
CMM 示例
-
People CMM – 开发、激励和留住项目人才。
-
软件 CMM – 增强以软件为中心的开发和维护能力。
什么是成熟度？
定义各不相同，但成熟的过程通常被认为是 –
-
定义明确，
-
可重复，
-
测量，
-
经过分析，
-
改进，和
-
有效的。
糟糕但成熟的流程与根本不成熟一样糟糕！
CMM 通过定义一组实践并提供改进它们的通用框架来帮助解决成熟度问题。CMM 的重点是确定关键过程领域和可能构成规范软件过程的示范性实践。
不成熟与成熟的组织
一个不成熟的组织将具有以下特征 –
-
项目期间即兴创作的过程
-
已批准的流程被忽略
-
被动，而不是主动
-
不切实际的预算和时间表
-
为进度而牺牲质量
-
没有客观的质量衡量标准
相比之下，成熟组织的特征如下 –
-
组间沟通与协调
-
工作按计划完成
-
与流程一致的做法
-
根据需要更新流程
-
明确定义的角色/职责
-
管理层正式承诺
什么是CMMI？
CMM集成项目的成立是为了解决使用多个CMM的问题。CMMI 产品团队的任务是将三个源模型组合成一个单一的改进框架，以供追求企业范围过程改进的组织使用。这三个源模型是 –
-
软件能力成熟度模型 (SW-CMM) – v2.0 草案 C。
-
电子工业联盟临时标准 (EIA/IS) – 731 系统工程。
-
集成产品开发能力成熟度模型 (IPD-CMM) v0.98。
CMM 集成
-
构建一组初始的集成模型。
-
根据经验教训改进源模型的最佳实践。
-
建立一个框架以实现未来模型的集成。
CMM和CMMI的区别
CMM 是特定学科中成熟实践的参考模型，如系统工程 CMM、软件 CMM、人员 CMM、软件获取 CMM 等，但它们很难在需要时集成。
CMMI 是 CMM 的继任者，并演变为一套更成熟的指南，并结合了 CMM 各个学科（软件 CMM、人员 CMM 等）的最佳组件而构建。可应用于产品制造、人员管理、软件开发等。
CMM 仅描述软件工程，而 CMM 集成描述软件和系统工程。CMMI 还整合了集成流程和产品开发以及供应商采购。
CMMI 和业务目标
CMMI 的目标非常明显。它们如下 –
-
生产优质产品或服务– CMMI 模型中的过程改进概念源自 Deming、Juran 和 Crosby 质量范式：优质产品是质量过程的结果。CMMI 非常关注与质量相关的活动，包括需求管理、质量保证、验证和确认。
-
为股东创造价值– 成熟的组织比成熟度较低的组织更有可能做出更好的成本和收入估计，然后按照这些估计执行。CMMI 支持高质量的产品、可预测的计划和有效的测量，以支持管理层做出准确和可辩护的预测。这种过程成熟度可以防止在投资者眼中削弱组织价值的项目绩效问题。
-
提高客户满意度– 使用根据客户需求进行验证的高质量产品来满足成本和进度目标是提高客户满意度的一个很好的公式。CMMI 通过强调计划、监控和测量以及更强大的流程带来的改进的可预测性来解决所有这些因素。
-
增加市场份额– 市场份额是多种因素的结果，包括优质的产品和服务、名称识别、定价和形象。客户喜欢与以履行承诺而闻名的供应商打交道。
-
获得全行业的卓越认可– 建立卓越声誉的最佳方法是在项目中始终如一地表现出色，在成本和进度参数范围内提供优质的产品和服务。拥有符合 CMMI 要求的流程可以提高这种声誉。
SEI CMMI 模型 – 学科
CMM 集成是一种集成了多个学科/知识体系的模型。当前，在选择 CMMI 模型时，您可以使用四种知识体系。
系统工程
系统工程涵盖完整系统的开发，其中可能包括也可能不包括软件。系统工程师专注于将客户需求、期望和约束转化为产品解决方案，并在产品的整个生命周期内支持这些产品解决方案。
软件工程
软件工程涵盖了软件系统的开发。软件工程师专注于将系统的、规范的和可量化的方法应用于软件的开发、操作和维护。
集成产品和工艺开发
集成产品和过程开发 (IPPD) 是一种系统方法，可在产品的整个生命周期内实现相关利益相关者的及时协作，以更好地满足客户的需求、期望和要求。支持 IPPD 方法的过程与组织中的其他过程相结合。
如果项目或组织选择 IPPD，则它会与用于生产产品的其他最佳实践（例如，与系统工程相关的那些）同时执行 IPPD 最佳实践。也就是说，如果一个组织或项目希望使用 IPPD，它必须在 IPPD 之外选择一个或多个学科。
供应商采购
随着工作变得更加复杂，项目经理可能会使用供应商来执行项目特定需要的功能或对产品进行修改。当这些活动很关键时，项目将从增强的源分析和在产品交付前监控供应商活动中受益。在这些情况下，供应商采购纪律涵盖从供应商处采购产品。
与 IPPD 最佳实践类似，必须结合用于生产产品的最佳实践来选择供应商采购最佳实践。
CMMI学科选择
选择学科可能是一个困难的步骤，取决于组织想要改进的内容。
-
如果您正在改进系统工程流程，例如配置管理、测量和分析、组织流程重点、项目监控和控制、流程和产品质量保证、风险管理、供应商协议管理等，那么您应该选择系统工程 (SE)纪律。系统工程的学科扩展受到特别重视。
-
如果您正在改进集成产品和流程开发流程，例如集成团队、集成组织环境，那么您应该选择 IPPD。IPPD 的学科扩展受到特别重视。
-
如果您正在改进您的源选择流程，例如集成供应商管理，那么您应该选择供应商采购 (SS)。供应商采购的纪律放大受到特别重视。
-
如果您正在改进多个学科，那么您需要在与这些学科相关的所有领域上工作，并注意这些学科的所有学科放大。
我们将在后续章节中讨论与 CMMI 实现相关的不同领域。
SEI CMMI – 表示
CMMI 的结构如下 –
- 成熟度级别（分阶段表示）或能力级别（连续表示）
- 过程域
- 目标：通用和特定
- 共同特征
- 实践：通用和特定
本章将讨论两种 CMMI 表示，其余主题将在后续章节中介绍。
表示允许组织追求不同的改进目标。组织可以采用以下两种改进路径之一。
阶段性代表
分阶段表示是软件 CMM 中使用的方法。它是一种使用预定义过程域集来定义组织改进路径的方法。此改进路径由称为成熟度级别的模型组件描述。成熟度级别是一个明确定义的进化平台，以实现改进的组织流程。
CMMI 分阶段表示
-
提供经过验证的改进序列，每一个都是下一个的基础。
-
允许通过使用成熟度级别在组织之间进行比较。
-
提供从 SW-CMM 到 CMMI 的轻松迁移。
-
提供总结评估结果并允许在组织之间进行比较的单一评级。
因此，阶段式表示法基于经过验证的流程分组和排序以及相关的组织关系，为组织改进提供了一个预定义的路线图。你不能偏离步骤的顺序。
CMMI 分级结构
下图说明了 CMMI 分阶段模型结构。
连续表示
连续表示是 SECM 和 IPD-CMM 中使用的方法。这种方法允许组织选择特定的过程域并基于它进行改进。连续表示使用能力级别来表征相对于单个过程域的改进。
CMMI 连续表示
-
允许您选择最能满足组织业务目标并降低组织风险领域的改进顺序。
-
支持在逐个过程域的基础上跨组织和组织之间进行比较。
-
提供从 EIA 731（和其他具有连续表示的模型）到 CMMI 的轻松迁移。
因此，持续代表为组织选择改进过程以及所需改进量提供了灵活性。
CMMI 连续结构
下图说明了 CMMI 连续模型结构。
连续与分阶段表示
| Continuous Representation | 阶段性代表 |
|---|---|
|
Process areas are organized by process area categories. |
过程域按成熟度级别组织。 |
|
Improvement is measured using capability levels. Capability levels measure the maturity of a particular process across an organization; it ranges from 0 through 5. |
改进是使用成熟度级别来衡量的。成熟度级别衡量组织中一组流程的成熟度：范围从 1 到 5。 |
|
There are two types of specific practices: base and advanced. All specific practices appear in the continuous representation. |
只有一种类型的特定实践。不使用基本和高级实践的概念。所有特定实践都出现在分阶段表示中，除非相关的基础高级实践对出现在连续表示中，在这种情况下，只有高级实践出现在分阶段表示中。 |
|
Capability levels are used to organize the generic practices. |
通用功能用于组织通用实践。 |
|
All generic practices are included in each process area. |
仅包括 2 级和 3 级通用实践。 |
|
Equivalent staging allows determination of a maturity level from an organization’s achievement profile. |
不需要等效机制来支持连续表示，因为每个组织都可以使用分阶段表示选择要改进的内容和改进的程度。 |
哪种表示方式更好？
每种表示都有其优势，一些组织使用这两种表示来解决其改进计划中不同时间的特定要求。
组织成熟度是阶段性表示的重点，而过程域能力是持续性表示的重点。
组织成熟度和过程域能力是相似的概念。它们之间的区别在于，组织成熟度与整个组织的一组过程域有关，而过程域能力处理与单个过程域或特定实践相关的一组过程。
下图描述了这两种演示。在此图中，ML表示成熟度级别，PA表示过程区域。
CMMI – 成熟度级别
成熟度级别是实现成熟软件过程的明确定义的进化平台。每个成熟度级别都为持续过程改进提供了一个基础层。
具有分阶段表示的 CMMI 模型具有由数字 1 到 5 指定的五个成熟度级别。它们是 –
- 最初的
- 管理
- 已定义
- 量化管理
- 优化
CMMI 分阶段表示成熟度级别
下图显示了 CMMI 分阶段表示中的成熟度级别。
现在我们将了解有关每个成熟度级别的详细信息。下一节将列出与这些成熟度级别相关的所有过程域。
成熟度级别详细信息
成熟度级别由一组预定义的过程域组成。成熟度级别通过适用于每个预定义过程域集的特定和通用目标的实现来衡量。以下部分详细描述了每个成熟度级别的特征。
成熟度 1 级初始
在成熟度级别 1，流程通常是临时的和混乱的。组织通常不提供稳定的环境。在这些组织中的成功取决于组织中人员的能力和英雄气概，而不是使用经过验证的流程。
成熟度级别为 1 的组织通常会生产有效的产品和服务；然而，他们经常超出项目的预算和时间表。
成熟度 1 级组织的特点是倾向于过度承诺、在危机时期放弃流程，并且无法重复过去的成功。
成熟度 2 级管理
在成熟度级别 2，组织已经实现了成熟度级别 2 过程域的所有特定和通用目标。换言之，组织的项目已确保需求得到管理，过程得到计划、执行、测量和控制。
成熟度级别 2 所反映的过程纪律有助于确保在压力时期保留现有实践。当这些实践到位时，项目将根据其文件化计划执行和管理。
在成熟度级别 2，管理需求、流程、工作产品和服务。工作产品的状态和服务的交付在定义的点对管理层可见。
在相关利益相关者之间建立承诺，并根据需要进行修订。工作产品由利益相关者审查并受到控制。
工作产品和服务满足其指定的要求、标准和目标。
成熟度级别 3 定义
在成熟度级别 3，组织已经实现了分配给成熟度级别 2 和 3 的过程域的所有特定和通用目标。
在成熟度级别 3，过程被很好地表征和理解，并在标准、程序、工具和方法中进行描述。
成熟度级别 2 和成熟度级别 3 之间的一个重要区别是标准、过程描述和程序的范围。在成熟度级别 2，标准、过程描述和程序在过程的每个特定实例中（例如，在特定项目上）可能完全不同。
在成熟度级别 3，项目的标准、过程描述和程序是从组织的标准过程集裁剪出来的，以适应特定的项目或组织单位。组织的标准过程集包括成熟度级别 2 和成熟度级别 3 所涉及的过程。因此，除了裁剪指南允许的差异外，在整个组织中执行的过程是一致的。
另一个关键区别是，在成熟度级别 3，流程的描述通常比成熟度级别 2 更详细、更严格。在成熟度级别 3，使用对流程活动的相互关系的理解和对流程活动的详细测量，可以更主动地管理流程。过程、工作产品和服务。
成熟度 4 级量化管理
在成熟度级别 4，组织已经实现了分配给成熟度级别 2、3 和 4 的过程域的所有特定目标以及分配给成熟度级别 2 和 3的通用目标。
在成熟度级别 4，选择对整体过程性能有显着贡献的子过程。这些选定的子过程使用统计和其他定量技术进行控制。
质量和过程性能的定量目标被建立并用作管理过程的标准。定量目标基于客户、最终用户、组织和流程实施者的需求。质量和过程性能以统计术语来理解，并在过程的整个生命周期内进行管理。
对于这些过程，收集并统计分析过程性能的详细测量。识别过程变异的特殊原因，并在适当的情况下纠正特殊原因的来源，以防止未来发生。
质量和过程绩效度量被纳入组织的度量存储库，以支持未来基于事实的决策。
成熟度级别 3 和成熟度级别 4 之间的一个关键区别是过程性能的可预测性。在成熟度级别 4，过程的性能使用统计和其他定量技术进行控制，并且是可定量预测的。在成熟度级别 3，流程只能在质量上进行预测。
成熟度 5 级优化
在成熟度级别 5，组织已经实现了分配给成熟度级别 2、3、4 和 5 的过程域的所有特定目标以及分配给成熟度级别 2 和 3的通用目标。
基于对过程中固有变异的常见原因的定量理解，过程不断得到改进。
此级别侧重于通过渐进式和创新技术改进来持续改进过程性能。
为组织建立量化的过程改进目标，不断修订以反映不断变化的业务目标，并用作管理过程改进的标准。
已部署的过程改进的效果根据量化的过程改进目标进行测量和评估。定义的过程和组织的标准过程集都是可衡量的改进活动的目标。
优化敏捷和创新的流程取决于与组织的业务价值和目标保持一致的授权员工的参与。通过寻找加速和共享学习的方法，可以增强组织快速响应变化和机遇的能力。流程的改进本质上是每个人都必须扮演的角色，从而形成持续改进的循环。
成熟度级别 4 和成熟度级别 5 之间的一个关键区别是所处理的过程变异类型。在成熟度级别 4，过程关注解决过程变化的特殊原因并提供结果的统计可预测性。尽管过程可能会产生可预测的结果，但结果可能不足以实现既定目标。在成熟度级别 5，过程关注解决过程变异的常见原因和改变过程（即改变过程性能的手段）以提高过程性能（同时保持统计可预测性）以实现既定的量化过程改进目标.
不应跳过成熟度级别
每个成熟度级别都为下一级别流程的有效实施提供了必要的基础。
-
如果没有较低级别提供的纪律，较高级别的流程成功的机会就会减少。
-
在嘈杂的过程中，创新的效果可能会被掩盖。
较高成熟度级别的流程可能由较低成熟度级别的组织执行，存在无法在危机中持续应用的风险。
成熟度级别和过程域
这是为软件组织定义的所有相应过程域的列表。对于不同的组织，这些过程域可能是不同的。
本节提供相关过程域的名称。有关这些过程域的更多详细信息，请参阅 CMMI 过程域章节。
| Level | 重点 | 关键过程区 | 结果 |
|---|---|---|---|
| 5
Optimizing |
持续过程改进 |
组织创新与部署 因果分析和解决 |
最高质量/最低风险 |
| 4
Quantitatively Managed |
量化管理 |
组织过程绩效 量化项目管理 |
更高质量/更低风险 |
| 3
Defined |
流程标准化 |
需求开发 技术方案 产品集成 确认 验证 组织过程焦点 组织过程定义 组织培训 集成项目管理（带有 IPPD 附加功能） 风险管理 决策分析和解决 集成组合（仅限 IPPD） 组织。集成环境（仅限 IPPD） 集成供应商管理（仅限 SS） |
中等质量/中等风险 |
| 2
Managed |
基本项目管理 |
需求管理 项目计划 项目监控 供应商协议管理 测量与分析 工艺和产品质量保证 配置管理 |
低质量/高风险 |
| 1
Initial |
过程是非正式的和临时的 | 最低质量/最高风险 |
CMMI – 能力水平
能力水平是一个明确定义的演化平台，描述了组织相对于过程域的能力。能力级别由过程域的相关特定和通用实践组成，可以改进与该过程域相关的组织过程。每个级别都是持续过程改进的基础层。
因此，能力水平是累积的，即较高的能力水平包括较低水平的属性。
在具有连续表示的 CMMI 模型中，有六个由数字 0 到 5 指定的能力级别。
- 0 – 不完整
- 1 – 执行
- 2 – 管理
- 3 – 定义
- 4 – 量化管理
- 5 – 优化
每个能力级别的简短描述如下 –
能力等级 0：不完整
“不完整过程”是未执行或部分执行的过程。过程域的一个或多个特定目标未得到满足，并且该级别不存在通用目标，因为没有理由将部分执行的过程制度化。
这相当于分阶段表示中的成熟度级别 1。
能力级别 1：已执行
能力级别 1 过程是预期执行所有能力级别 1 特定和通用实践的过程。性能可能不稳定，可能无法满足质量、成本和进度等特定目标，但可以完成有用的工作。这只是过程改进的一个开始，或一小步。这意味着您正在做某事，但您无法证明它确实对您有用。
能力级别 2：管理
管理过程是为单个项目、组或独立过程计划、执行、监视和控制以实现给定目的。管理流程可以实现流程的模型目标以及其他目标，例如成本、进度和质量。正如此级别的标题所示，您正在积极管理组织中的工作方式。您有一些持续收集并应用于您的管理方法的指标。
注意– 在 CMMI 的所有级别收集和使用度量，在分阶段和连续表示中。认为组织可以等到能力级别 4 才能使用这些度量标准是一种严重的谬论。
能力等级 3：定义
能力级别 3 过程的特征是“定义过程”。定义的过程是一个受管理的（能力级别 2）过程，它根据组织的剪裁指南从组织的标准过程集剪裁而成，并将工作产品、度量和其他过程改进信息提供给组织过程资产。
能力等级 4：量化管理
能力级别 4 过程的特征是“量化管理过程”。定量管理过程是一个定义的（能力级别 3）过程，它使用统计和其他定量技术进行控制。质量和过程性能的定量目标被建立并用作管理过程的标准。质量和过程性能以统计术语来理解，并在过程的整个生命周期内进行管理。
能力级别 5：优化
优化过程是一种量化管理的过程，它基于对过程固有过程变异的常见原因的理解而得到改进。它侧重于通过渐进式和创新性改进来持续改进过程性能。定义的过程和组织的标准过程集都是改进活动的目标。
能力级别 4 侧重于为过程性能建立基线、模型和测量。能力级别 5 侧重于研究整个组织或整个企业的绩效结果，找出工作完成方式（所使用的流程）中出现问题的常见原因，并解决流程中的问题。修复将包括更新流程文档和涉及注入错误的培训。
在连续表示中组织过程域
| Category | 工艺区 |
|---|---|
| Project Management |
|
| Support |
|
| Engineering |
|
| Process Management |
|
CMMI – 关键过程领域
过程域是一个领域中的一组相关实践，当它们共同实施时，可以满足一组被认为对在该领域进行重大改进很重要的目标。所有 CMMI 过程域对于连续表示和阶段表示都是通用的。
持续表示使组织能够通过选择最有利于组织及其业务目标的那些过程域或一组相互关联的过程域来选择其过程改进工作的重点。尽管由于过程域之间的依赖关系，组织可以选择的内容有一些限制，但组织在选择方面有相当大的自由度。
一旦您选择了过程域，您还必须选择您希望改进与这些过程域相关的过程的程度（即，选择适当的能力级别）。能力水平以及通用目标和实践，支持各个过程域中的过程改进。
相反，您将看到分阶段表示鼓励您始终在它们所属的成熟度级别的上下文中查看过程域。过程域按成熟度级别进行组织以强化这一概念。当您使用一个过程域时，您将使用整个过程域，即所有目标和所有实践。
CMMI 过程域 (PA) 可以分为以下四类，以了解它们之间的交互和链接，而不管其定义的级别如何：
-
流程管理
-
项目管理
-
工程
-
支持
每个过程域都由一组目标和实践定义。有两类目标和实践 –
-
通用目标和实践– 它们是每个过程域的一部分。
-
特定目标和实践– 它们特定于给定的过程区域。
当公司的过程涵盖该过程域的所有通用和特定目标和实践时，该过程域就得到满足。
通用目标和实践
通用目标和实践是每个过程域的一部分。
符号– GG –> 通用目标和 GP –> 通用实践
-
GG 1 实现特定目标
-
GP 1.1 执行特定实践
-
-
GG 2 将管理流程制度化
-
GP 2.1 建立组织政策
-
GP 2.2 计划流程
-
GP 2.3 提供资源
-
GP 2.4 分配责任
-
GP 2.5 培训人员
-
GP 2.6 管理配置
-
GP 2.7 确定并让相关利益相关者参与进来
-
GP 2.8 监视和控制过程
-
GP 2.9 客观评估依从性
-
GP 2.10 与上级管理人员的审查状态
-
-
GG 3 将既定流程制度化
-
GP 3.1 建立定义的过程
-
GP 3.2 收集改进信息
-
-
GG 4 将量化管理流程制度化
-
GP 4.1 建立过程的定量目标
-
GP 4.2 稳定子流程性能
-
-
GG 5 制度化优化流程
-
GP 5.1 确保持续的过程改进
-
GP 5.2 纠正问题的根本原因
-
共同特征
共同特征是表明关键过程域的实施和制度化是否有效、可重复和持久的属性。下面列出了五个共同特征 –
-
执行承诺 –执行承诺描述了组织必须采取的行动，以确保流程建立并持续下去。执行承诺通常涉及建立组织政策和高级管理人员的支持。
-
执行能力 –执行能力描述了项目或组织中必须存在的先决条件，才能胜任地实施软件过程。执行能力通常涉及资源、组织结构和培训。
-
执行的活动–执行的活动描述了实施关键过程域所需的角色和程序。执行的活动通常涉及制定计划和程序、执行工作、跟踪工作，并在必要时采取纠正措施。
-
测量和分析– 测量和分析描述了测量过程和分析测量值的需要。测量和分析通常包括可以用来确定所执行活动的状态和有效性的测量示例。
-
验证实施– 验证实施描述了确保活动按照已建立的流程执行的步骤。验证通常包括管理层和软件质量保证的审查和审计。
执行的公共特性活动中的实践描述了建立过程能力必须实施的内容。其他实践作为一个整体构成了组织可以将“已执行活动”共同特征中描述的实践制度化的基础。
详细过程区域
CMMI 包含 22 个过程域，表明了公司过程所涵盖的产品开发方面。
因果分析和解决
-
它是成熟度级别 5 的支持过程域。
目的
因果分析和解决(CAR)的目的是确定缺陷和其他问题的原因，并采取措施防止它们在未来发生。
目标的具体做法
-
SG 1 确定缺陷原因
-
SP 1.1 选择缺陷数据进行分析
-
SP 1.2 分析原因
-
-
SG 2 解决缺陷的原因
-
SP 2.1 实施行动建议
-
SP 2.2 评估变更的影响
-
SP 2.3 记录数据
-
配置管理
-
它是成熟度级别 2 的支持过程域。
目的
配置管理(CM)的目的是使用配置识别、配置控制、配置状态核算和配置审计来建立和维护工作产品的完整性。
目标的具体做法
-
SG 1 建立基线
-
SP 1.1 识别配置项
-
SP 1.2 建立配置管理系统
-
SP 1.3 创建或发布基线
-
-
SG 2 跟踪和控制变更
-
SP 2.1 跟踪变更请求
-
SP 2.2 控制配置项
-
-
SG 3 建立诚信
-
SP 3.1 建立配置管理记录
-
SP 3.2 执行配置审计
-
决策分析和解决
-
它是成熟度级别 3 的支持过程域。
目的
决策分析和解决(DAR)的目的是使用正式评估过程分析可能的决策，该过程根据既定标准评估已确定的替代方案。
目标的具体做法
-
SG 1 评估替代方案
-
SP 1.1 建立决策分析指南
-
SP 1.2 建立评估标准
-
SP 1.3 确定替代解决方案
-
SP 1.4 选择评估方法
-
SP 1.5 评估备选方案
-
SP 1.6 选择解决方案
-
综合项目管理 + IPPD
-
它是成熟度级别 3 的项目管理过程域。
目的
综合项目管理 + IPPD (IPM)的目的是根据从组织的标准流程集裁剪出来的综合和定义的流程来建立和管理项目以及相关干系人的参与。
目标的具体做法
-
SG 1 使用项目定义的过程
-
SP 1.1 建立项目的定义过程
-
SP 1.2 使用组织过程资产来规划项目活动
-
SP 1.3 建立项目的工作环境
-
SP 1.4 整合计划
-
SP 1.5 使用综合计划管理项目
-
SP 1.6 为组织过程资产做出贡献
-
-
SG 2 与相关利益相关者协调和合作
-
SP 2.1 管理利益相关者的参与
-
SP 2.2 管理依赖
-
SP 2.3 解决协调问题
-
IPPD添加 –
-
SG 3 应用 IPPD 原则
-
SP 3.1 建立项目的共同愿景
-
SP 3.2 建立综合团队结构
-
SP 3.3 为集成团队分配需求
-
SP 3.4 建立综合团队
-
SP 3.5 确保接口团队之间的协作
-
测量与分析
它是成熟度级别 2 的支持过程域。
目的
测量和分析(MA)的目的是开发和维持用于支持管理信息需求的测量能力。
目标的具体做法
-
SG 1 调整测量和分析活动
-
SP 1.1 建立测量目标
-
SP 1.2 指定措施
-
SP 1.3 指定数据收集和存储程序
-
SP 1.4 指定分析程序
-
-
SG 2 提供测量结果
-
SP 2.1 收集测量数据
-
SP 2.2 分析测量数据
-
SP 2.3 存储数据和结果
-
SP 2.4 交流结果
-
组织创新与部署
它是成熟度级别 5 的过程管理过程域。
目的
组织创新和部署(OID)的目的是选择和部署增量和创新改进，以显着改进组织的流程和技术。改进支持源自组织业务目标的组织质量和过程绩效目标。
目标的具体做法
-
SG 1 选择改进
-
SP 1.1 收集和分析改进建议
-
SP 1.2 识别和分析创新
-
SP 1.3 试点改进
-
SP 1.4 选择部署改进
-
-
SG 2 部署改进
-
SP 2.1 规划部署区域
-
SP 2.2 管理部署
-
SP 2.3 衡量改进效果
-
组织过程定义 + IPPD (OPD)
它是成熟度级别 3 的过程管理过程域。
目的
的目的组织过程定义+ IPPD（OPD）是建立和保持一个可用集合组织过程资产。
目标的具体做法
-
SG 1 建立组织过程资产
-
SP 1.1 建立标准流程
-
SP 1.2 建立生命周期模型描述
-
SP 1.3 建立剪裁标准和指南
-
SP 1.4 建立组织的测量库
-
SP 1.5 建立组织的过程资产库
-
IPPD添加 –
-
SG 2 启用 IPPD 管理
-
SP 2.1 建立赋能机制
-
SP 2.2 为集成团队建立规则和指南
-
SP 2.3 平衡团队和内部组织的职责
-
组织过程焦点
它是成熟度级别 3 的过程管理过程域。
目的
组织过程聚焦(OPF)的目的是基于对组织过程和过程资产的当前优势和劣势的透彻理解来计划和实施组织过程改进。
目标的具体做法
-
SG 1 确定过程改进机会
-
SP 1.1 建立组织过程需求
-
SP 1.2 评估组织的过程
-
SP 1.3 确定组织的过程改进
-
-
SG 2 计划和实施过程改进活动
-
SP 2.1 建立过程行动计划
-
SP 2.2 实施过程行动计划
-
-
SG 3 部署组织流程资产并整合经验教训
-
SP 3.1 部署组织过程资产
-
SP 3.2 部署标准流程
-
SP 3.3 监控实施
-
SP 3.4 将与过程相关的经验合并到组织过程资产中
-
组织过程绩效
它是成熟度级别 4 的过程管理过程域。
目的
组织过程绩效(OPP)的目的是建立和保持对组织标准过程集绩效的定量理解，以支持质量和过程绩效目标，并提供过程绩效数据、基线和模型，以支持质量和过程绩效目标。量化管理组织的项目。
目标的具体做法
-
SG 1 建立绩效基准和模型
-
SP 1.1 选择进程
-
SP 1.2 建立过程绩效测量
-
SP 1.3 建立质量和过程绩效目标
-
SP 1.4 建立过程绩效基准
-
SP 1.5 建立过程性能模型
-
组织培训
它是成熟度级别 3 的过程管理过程域。
目的
组织培训(OT)的目的是培养人们的技能和知识，使他们能够有效地履行职责。
目标的具体做法
-
SG 1 建立组织培训能力
-
SP 1.1 建立战略培训需求
-
SP 1.2 确定哪些培训需求是组织的责任
-
SP 1.3 制定组织培训战术计划
-
SP 1.4 建立培训能力
-
-
SG 2 提供必要的培训
-
SP 2.1 提供培训
-
SP 2.2 建立培训记录
-
SP 2.3 评估培训效果
-
产品集成
它是成熟度级别 3 的工程过程域。
目的
产品集成(PI)的目的是从产品组件组装产品，确保集成后的产品正常运行，并交付产品。
目标的具体做法
-
SG 1 准备产品集成
-
SP 1.1 确定积分顺序
-
SP 1.2 建立产品集成环境
-
SP 1.3 建立产品集成程序和标准
-
-
SG 2 确保接口兼容性
-
SP 2.1 审查接口描述的完整性
-
SP 2.2 管理接口
-
-
SG 3 组装产品组件并交付产品
-
SP 3.1 确认产品组件已准备好进行集成
-
SP 3.2 组装产品组件
-
SP 3.3 评估组装的产品组件
-
SP 3.4 包装和交付产品或产品组件
-
项目监控
它是成熟度级别 2 的项目管理过程域。
目的
项目监控(PMC)的目的是了解项目的进度，以便在项目绩效与计划显着偏离时采取适当的纠正措施。
目标的具体做法
-
SG 1 根据计划监控项目
-
SP 1.1 监控项目规划参数
-
SP 1.2 监控承诺
-
SP 1.3 监控项目风险
-
SP 1.4 监控数据管理
-
SP 1.5 监控利益相关者的参与
-
SP 1.6 进行进度审查
-
SP 1.7 进行里程碑审查
-
-
SG 2 管理关闭纠正措施
-
SP 2.1 分析问题
-
SP 2.2 采取纠正措施
-
SP 2.3 管理纠正措施
-
项目计划
它是成熟度级别 2 的项目管理过程域。
目的
项目计划(PP)的目的是建立和维护定义项目活动的计划。
目标的具体做法
-
SG 1 建立估计
-
SP 1.1 估算项目范围
-
SP 1.2 建立工作产品和任务属性的估计
-
SP 1.3 定义项目生命周期
-
SP 1.4 确定工作量和成本的估计
-
-
SG 2 制定项目计划
-
SP 2.1 制定预算和时间表
-
SP 2.2 识别项目风险
-
SP 2.3 数据管理计划
-
SP 2.4 项目资源计划
-
SP 2.5 所需知识和技能的计划
-
SP 2.6 计划利益相关者的参与
-
SP 2.7 制定项目计划
-
-
SG 3 获得对计划的承诺
-
SP 3.1 审查影响项目的计划
-
SP 3.2 协调工作和资源级别
-
SP 3.3 获得计划承诺
-
工艺和产品质量保证
它是成熟度级别 2 的支持过程域。
目的
的目的，过程和产品质量保证（PPQA）是提供人员和管理人员提供客观洞察过程和相关工作产品。
目标的具体做法
-
SG 1 客观评估流程和工作产品
-
SP 1.1 客观评估流程
-
SP 1.2 客观评估工作产品和服务
-
-
SG 2 提供客观洞察力
-
SP 2.1 沟通并确保解决不合规问题
-
SP 2.2 建立记录
-
量化项目管理
它是成熟度级别 4 的项目管理过程域。
目的
该目的量化项目管理（QPM）过程域是定量管理项目的定义过程，以实现该项目的建立质量和过程绩效目标。
目标的具体做法
-
SG 1 量化管理项目
-
SP 1.1 确立项目目标
-
SP 1.2 组合定义的过程
-
SP 1.3 选择将被统计管理的子流程
-
SP 1.4 管理项目绩效
-
-
SG 2 统计管理子流程性能
-
SP 2.1 选择度量和分析技术
-
SP 2.2 应用统计方法来理解变化
-
SP 2.3 监控所选子流程的性能
-
SP 2.4 记录统计管理数据
-
需求开发
它是成熟度级别 3 的工程过程域。
目的
需求开发(RD)的目的是生成和分析客户、产品和产品组件的需求。
目标的具体做法
-
SG 1 开发客户需求
-
SP 1.1 引出需求
-
SP 1.2 开发客户需求
-
-
SG 2 开发产品需求
-
SP 2.1 建立产品和产品组件要求
-
SP 2.2 分配产品组件需求
-
SP 2.3 确定接口要求
-
-
SG 3 分析和验证需求
-
SP 3.1 建立操作概念和场景
-
SP 3.2 建立所需功能的定义
-
SP 3.3 分析需求
-
SP 3.4 分析需求以实现平衡
-
SP 3.5 验证要求
-
需求管理
它是成熟度级别 2 的工程过程域。
目的
需求管理(REQM)的目的是管理项目产品和产品组件的需求，并识别这些需求与项目计划和工作产品之间的不一致。
目标的具体做法
-
SG 1 管理需求
-
SP 1.1 了解需求
-
SP 1.2 获得对需求的承诺
-
SP 1.3 管理需求变更
-
SP 1.4 维护需求的双向可追溯性
-
SP 1.5 识别项目工作和需求之间的不一致
-
风险管理
它是成熟度级别 3 的项目管理过程域。
目的
风险管理(RSKM)的目的是在潜在问题发生之前识别它们，以便可以在产品或项目的整个生命周期中根据需要计划和调用风险处理活动，以减轻对实现目标的不利影响。
目标的具体做法
-
SG 1 准备风险管理
-
SP 1.1 确定风险来源和类别
-
SP 1.2 定义风险参数
-
SP 1.3 建立风险管理策略
-
-
SG 2 识别和分析风险
-
SP 2.1 识别风险
-
SP 2.2 评估、分类和确定风险优先级
-
-
SG 3 降低风险
-
SP 3.1 制定风险缓解计划
-
SP 3.2 实施风险缓解计划
-
供应商协议管理
它是成熟度级别 2 的项目管理过程域。
目的
供应商协议管理(SAM)的目的是管理从存在正式协议的供应商处采购产品。
目标的具体做法
-
SG 1 建立供应商协议M
-
SP 1.1 确定获取类型
-
SP 1.2 选择供应商
-
SP 1.3 建立供应商协议
-
-
SG 2 满足供应商协议
-
SP 2.1 执行供应商协议
-
SP 2.2 监控选定的供应商流程
-
SP 2.3 评估选定的供应商工作产品
-
SP 2.4 接受所收购的产品
-
SP 2.5 过渡产品
-
技术方案
它是成熟度级别 3 的工程过程域。
目的
技术解决方案(TS)的目的是设计、开发和实施针对需求的解决方案。解决方案、设计和实施包括产品、产品组件和与产品相关的生命周期过程，无论是单独的还是适当的组合。
目标的具体做法
-
SG 1 选择产品组件解决方案
-
SP 1.1 制定替代解决方案和选择标准
-
SP 1.2 选择产品组件解决方案
-
-
SG 2 开发设计
-
SP 2.1 设计产品或产品组件
-
SP 2.2 建立技术数据包
-
SP 2.3 使用标准设计界面
-
SP 2.4 执行制造、购买或重用分析
-
-
SG 3 实施产品设计
-
SP 3.1 实现设计
-
SP 3.2 开发产品支持文档
-
验证
它是成熟度级别 3 的工程过程域。
目的
验证(VAL)的目的是证明产品或产品组件在放置在其预期环境中时满足其预期用途。
目标的具体做法
-
SG 1 准备验证
-
SP 1.1 选择要验证的产品
-
SP 1.2 建立验证环境
-
SP 1.3 建立验证程序和标准
-
-
SG 2 验证产品或产品组件
-
SP 2.1 执行验证
-
SP 2.2 分析验证结果。
-
确认
它是成熟度级别 3 的工程过程域。
目的
验证(VER)的目的是确保选定的工作产品满足其指定的要求。
目标的具体做法
-
SG 1 准备验证
-
SP 1.1 选择工作产品进行验证
-
SP 1.2 建立验证环境
-
SP 1.3 建立验证程序和标准
-
-
SG 2 执行同行评审
-
SP 2.1 准备同行评审
-
SP 2.2 进行同行评审
-
SP 2.3 分析同行评审数据
-
-
SG 3 验证选定的工作产品
-
SP 3.1 执行验证
-
SP 3.2 分析验证结果
-
对 1.2 版所做的更改
此处仅考虑对过程域集进行的那些更改。有关全面的详细信息，请访问SEI 主页。
-
以下过程领域已被删除（均在成熟度级别 3） –
-
整合组织环境 (OEI)
-
集成团队 (IT)
-
集成供应商管理 (ISM)
-
-
在现有的过程域中添加了以下内容 –
-
IPM 。取消了 SG3 和 SG4，添加了新的 SG3（所有 IPPD PA）
-
奥普。添加了 SG，将其转换为 IPPD PA
-
OPF。从 SG 中提取了两个 SP，并与两个新的 SP 一起创建了 SG3
-
要求。SP3.5 更名为验证需求
-
山姆。SP2.1 被淘汰，SG2 中添加了两个新的 SP
-
TS 。SP1.2 被淘汰
-
VER 。SP3.2 更名为分析验证结果
-
CMMI – 评估
CMMI 评估是由训练有素的专业人员团队使用评估参考模型作为确定组织优势和劣势的基础对一个或多个流程进行的检查。
评估需要计划。在计划对组织进行评估时，确定组织单位的范围、要包括的学科、评估团队是由组织内部成员还是外部成员组成、要包括的项目、要面试的个人以及类型或必要的评估等级。
评估考虑 CMMI 中定义的三类模型组件 –
-
必需– 仅限特定和通用目标。
-
预期– 仅限特定和通用实践。
-
信息性– 包括子实践和典型的工作产品。
SEI 发布了两份 CMMI 评估指导文件 –
-
CMMI (ARC) 的评估要求– 它包含对 A 类、B 类和 C 类三类评估方法的要求。这些要求是定义每类评估方法的规则。
-
用于过程改进的标准 CMMI 评估方法 (SCAMPI) – 方法描述文件 (MDD) 是目前唯一批准的 A 级评估方法。
SCAMPI 是目前唯一获得批准的 CMMI A 类评估方法。也就是说，SCAMPI 满足 ARC A 类评估方法的所有要求，并已获得 SEI 批准。
CMMI 评估方法分为三类：A 类、B 类和 C 类。
SCAMPI A 级评估
SCAMPI A 级评估通常在组织实施了许多重要的流程改进并需要相对于 CMMI 对其流程进行正式基准测试时进行。SCAMPI A 是唯一提供 CMMI 成熟度级别或能力级别评级的评估方法。
您可以期待 SCAMPI A 的以下结果 –
-
成熟度级别评级或能力级别评级。
-
描述您的组织过程相对于 CMMI 的优势和劣势的结果。
-
就组织的关键过程问题达成共识。
-
组织可以继续使用的评估数据库，以监控过程改进进度并支持未来的评估。
SCAMPI B 级评估
当组织需要评估其实现目标 CMMI 成熟度水平的进度时，需要 SCAMPI B，但成本低于 SCAMPI A。SCAMPI B 评估提供详细的发现并表明评估的实践被评为令人满意的可能性在 SCAMPI A 评估中实施。
SCAMPI B 类评估是三种 SEI 评估方法之一，可帮助组织以相对较高的置信度了解其软件和系统工程过程相对于 CMMI 的状态。当组织需要准确评估其朝着目标 CMMI 成熟度级别的进度时，通常会执行 SCAMPI B。
您可以期待 SCAMPI B 的以下结果 –
-
描述您的组织过程相对于 CMMI 的优势和劣势的详细调查结果。
-
实践特征表明所检查的实践满足目标并满足 CMMI 意图的可能性。
-
就组织的关键过程问题达成共识。
-
组织可以继续使用的 FIDO 数据库，以监控流程改进进度并支持未来的评估。
SCAMPI C级评估
SCAMPI C 评估比 SCAMPI A 和 B 评估更短、更灵活，用于解决各种特殊需求，从快速差距分析到确定组织对 SCAMPI A 的准备情况。
SCAMPI C 类评估是 SEI 评估方法套件中最不正式的一种，非常灵活，可以满足各种需求。通常比 A 类和 B 类评估的持续时间短得多，SCAMPI C 评估通常出于以下原因进行 –
-
提供与 CMMI 相关的组织过程的快速差距分析。
-
在实施之前评估新流程的充分性。
-
监控流程的实施。
-
确定组织对 SCAMPI A 的准备情况。
-
支持选择供应商。
您可以期待 SCAMPI C 的以下结果 –
-
描述评估过程的优势和劣势的结果。根据评估范围和策略，结果可能会映射到相关的 CMMI 组件。
-
总结评估过程相对于 CMMI 的充分性的特征。
-
推荐的过程改进措施。
-
FIDO 数据库，组织可以继续使用该数据库来监控流程改进进度并支持未来的评估。
评估班特征
每个类别都通过与方法应用相关的严格程度来区分。A级最严格，B级稍微不严格，C级最不严格。下表给出了每个类中方法之间预期差异的一些想法。
| Characteristics | A级 | B级 | C级 |
|---|---|---|---|
| Amount of objective evidence gathered | 高的 | 中等的 | 低的 |
| Rating generated | 是的 | 不 | 不 |
| Resource needs | 高的 | 中等的 | 低的 |
| Team size | 大 | 中等的 | 小的 |
| Data sources (instruments, interviews, and documents) | 需要所有三个数据源 | 只需要两个数据源（一个必须是访谈） | 只需要一个数据源 |
| Appraisal team leader requirement | 授权首席评估师 | 授权的首席评估师或经过培训且经验丰富的人员 | 受过培训和有经验的人 |
SCAMPI 基础知识
SCAMPI 是首字母缩写词，代表标准 CMMI 过程改进评估方法。SCAMPI 评估必须由 SEI 授权的 SCAMPI 首席评估师领导。SCAMPI 由 SCAMPI 产品套件支持，其中包括 SCAMPI 方法描述、成熟度问卷、工作辅助工具和模板。
目前，SCAMPI 是唯一可以提供评级的方法，也是 SEI 认可的唯一方法，也是组织最感兴趣的方法。
SCAMPI 基于以前方法的经验，包括 –
-
CBA IPI – 基于 CMM 的内部过程改进评估。
-
SCE – 软件能力评估。
-
EIA/IS 732.2 – 名为系统工程评估方法的临时国际标准。
-
SDCE – 软件开发能力评估。
-
FAA 评估方法。
CMMI 参与者 – 角色职责
本章讨论参与过程改进工作的主要参与者。但是，您的组织可能需要更多或更少的组。
请注意，根据组织的规模和流程改进 (PI) 工作的复杂性，一个人可以同时或连续履行其中的许多角色。
流程改进
流程改进工作通常需要以下个人和团体 –
-
PI Sponsor – 组织中负责监督整个 PI 工作的人。此人通常有权分配资金和人员。此人通常在首长级或以上级别。
-
PI Champion – 这是 PI 工作的公关人员，可能担任也可能不担任 EPG 负责人。此人推销 PI 的想法、方法和结果。
-
工程流程组 (EPG) 主管– 此人领导审核流程的组。此人将任务分配给 EPG 成员，监督他们的工作，并计划 EPG 的日常职责。
-
EPG 成员– 这些人作为委员会成员在 EPG 中任职。他们负责确保编写并遵循流程改进文档。他们还负责生成指标以跟踪流程改进过程。他们领导 PAT。
-
流程行动团队 (PAT) – 这些团队生成流程改进文档、政策、流程、程序、章程和行动计划。
-
过渡合作伙伴– 通常是一两个外部顾问，以帮助建立、计划、领导和监控组织流程改进的进展。这些人带来了来自其他几个组织和行业的流程改进经验。
CMMI – 总结
本教程涵盖了由以下组件组成的 CMMI 结构 –
- 成熟度级别（分阶段表示）或能力级别（连续表示）
- 过程域
- 目标：通用和特定
- 共同特征
- 实践：通用和特定
我们已经涵盖了所有成熟度级别和能力级别。此外，我们讨论了所有关键过程领域和相关的通用目标、特定目标、共同特征和实践。
稍后，我们向您简要介绍了 CMMI Appraisals，并向您展示了不同的 Appraisal Classes。
接下来是什么？
SEI CMMI 是一个大课题，一个小教程是无法解释的。因此，我们强烈建议您浏览其他 CMMI 资源并收集有关此主题的更多信息。这些资源在 CMMI 资源一章中列出。
请将您的反馈发送至[email protected]
CMMI – 术语表
| A | B | C | D | E | F | G | H | I | J | K |
| L | M | N | O | P | Q | R | S | T | U | V |
| W | X | Y | Z |
执行能力– CMMI 模型过程域的一个共同特征，具有阶段性表示，将与确保项目和/或组织拥有所需资源相关的通用实践分组。
验收标准– 产品或产品组件必须满足才能被用户、客户或其他授权实体接受的标准。
验收测试– 进行正式测试以使用户、客户或其他授权实体能够确定是否接受产品或产品组件。
Achievement profile – 在连续表示中，过程域列表及其相应的能力级别代表组织在每个过程域中的进展，同时推进能力级别。
收购– 通过合同获得收购实体承诺投资以获得产品和服务的任何离散行动或拟议行动的过程。
采购策略– 基于对供应来源、采购方法、需求规范类型、合同或协议类型以及相关采购风险的考虑，获取产品和服务的具体方法。
充分– CMMI 中出现充分、适当和需要，以允许各级管理人员和从业人员根据组织的业务目标来解释特定和通用的目标和实践。例如，风险管理过程领域的通用实践指出：“为执行风险管理过程、开发工作产品和提供过程服务提供足够的资源。” 可以通过人数、必须监控风险的人员等来满足足够的要求。
高级实践– 在连续表示中，所有具有两个或更高能力级别的特定实践。
协议/合同要求– 与收购相关的所有技术和非技术要求。
分配的需求– 对较低级别的架构元素或设计组件征收较高级别要求的全部或部分性能和功能的要求。
替代实践– 一种替代 CMMI 模型中包含的一个或多个通用或特定实践的实践，该实践在满足与模型实践相关的通用或特定目标方面达到等效效果。替代实践不一定是通用或特定实践的一对一替代。
评估– 评估是由训练有素的专业人员团队使用评估参考模型作为确定优势和劣势的基础对一个或多个过程进行的检查。
评估结果– 确定评估范围内最重要的问题、问题或机会的评估结论。它至少包括基于有效观察的优势和劣势。
评估参与者– 在评估期间参与提供信息的组织单位成员。
评估评级– 在 CMMI 评估材料中使用，评估团队分配给 (1) CMMI 目标或过程域，(2) 过程域的能力级别，或 (3) 组织的成熟度级别的值单元。评级是通过为所采用的评估方法制定定义的评级过程来确定的。
评估参考模型– 在 CMMI 评估材料中使用的 CMMI 模型，评估团队将实施的流程活动与该模型相关联。
评估范围–评估边界的定义，包括组织限制和 CMMI 模型限制。
评估团队负责人– 领导评估活动并满足评估方法定义的经验、知识和技能资格标准的人。
适当– 请参阅适当的定义。
根据需要– 请参阅足够的定义。
评估– 评估是组织为了过程改进而对自己进行的评估。
过程变异的可分配原因– 在 CMMI 中，使用术语“过程变异的特殊原因”代替“过程变异的可分配原因”以确保一致性。这两个术语的定义相同。
审计– 对工作产品或工作产品集的独立检查，以确定是否满足要求。
基本度量– 实体的独特属性或特征以及量化它的方法。
基础实践– 在连续表示中，能力级别为 1 的所有特定实践。
基线– 术语基线通常用于表示这样的参考点。基线是系统在开发生命周期中适当点的批准快照。基线为定义后续更改建立了正式基础。没有这条线或参考点，变化的概念就毫无意义。
业务目标– 高级管理层制定的战略，旨在确保组织的持续存在并提高其盈利能力、市场份额和其他影响组织成功的因素。
能力评估– 由训练有素的专业团队进行的评估，用作选择供应商、合同监督或奖励的鉴别器。评估用于帮助决策者做出更好的采购决策，提高分包商的绩效，并为采购组织提供洞察力。
能力水平– 在单个过程域内实现过程改进。能力级别由过程域的适当的特定和通用实践定义。
能力级别配置文件– 在连续表示中，过程域列表及其相应的能力级别。当概要文件代表组织在通过能力级别前进时每个过程域的进展时，它可能是一个成就概要文件。或者，当该配置文件代表过程改进的目标时，该配置文件可能是目标配置文件。
能力成熟度模型– 能力成熟度模型 (CMM) 包含一个或多个学科的有效流程的基本要素。它还描述了从临时的、不成熟的流程到具有改进质量和有效性的规范、成熟流程的渐进式改进路径。
Capable process – 能够满足其指定的产品质量、服务质量和过程性能目标的过程。
因果分析– 分析缺陷以确定其原因。
变更管理– 明智地使用手段对产品或服务进行变更或提议的变更。
CMMI 评估剪裁– 在评估方法中选择用于特定情况的选项。评估剪裁的目的是帮助组织将方法的应用与其业务目标保持一致。
CMMI 模型组件– 构成 CMMI 模型的任何主要架构元素。CMMI 模型的一些主要元素包括特定实践、通用实践、特定目标、通用目标、过程域、能力级别和成熟度级别。
CMMI 模型剪裁– 使用CMMI 模型的子集使其适用于特定应用程序。模型裁剪的目的是帮助组织将模型的应用与其业务目标保持一致。
CMMI 产品套件– 该术语已用于完整的 CMMI 框架。
承诺执行– CMMI 模型过程域的一个共同特征，具有分阶段表示，将与创建策略和确保赞助相关的通用实践分组。
过程变异的常见原因– 由于过程组件之间的正常和预期相互作用而存在的过程变异。
操作概念– 对实体使用或操作方式的一般描述。
配置审计– 为验证配置项是否符合指定标准或要求而进行的审计。
配置基线– 在产品或产品组件生命周期中的特定时间正式指定的配置信息。配置基线，加上这些基线的批准更改，构成了当前的配置信息。
配置控制– 配置管理的一个要素，包括在正式建立配置标识后对配置项的更改的评估、协调、批准或不批准以及实施。
配置控制委员会– 一组负责评估和批准或不批准对配置项的提议更改，并确保已批准更改的实施。
配置标识– 配置管理的一个要素，包括为产品选择配置项，为其分配唯一标识符，并在技术文档中记录其功能和物理特性。
配置项– 指定用于配置管理并在配置管理过程中被视为单个实体的工作产品的集合。
配置管理– 应用技术和行政指导和监督的学科，以 (1) 识别和记录配置项的功能和物理特性，(2) 控制对这些特性的更改，(3) 记录和报告更改处理和实施状态， (4) 验证是否符合规定的要求。[IEEE 标准 610.1990]
CMMI 模型– 由于 CMMI 框架可以根据使用它的组织的需求生成不同的模型，因此有多个 CMMI 模型。因此，短语“CMMI MODEL”可以是许多信息集合中的任何一个。短语“CMMI 模型”是指可以从 CMMI 框架生成的一个、一些或整个可能模型的集合。
配置状态会计– 配置管理的一个元素，包括记录和报告有效管理配置所需的信息。此信息包括已批准配置标识的列表、对配置的提议更改状态以及已批准更改的实施状态。
连续表示– 一种能力成熟度模型结构，其中能力级别提供了在每个指定过程域内进行过程改进的推荐顺序。
纠正措施– 用于纠正情况、消除错误或调整条件的行为或行为。
COTS – 可以从商业供应商处购买的物品。
客户– 客户是负责接受产品或授权付款的个人、项目、组织、团体等。客户在项目外部，但不一定在组织外部。当我们讨论需求收集或引出时，术语客户也用作变量。
数据管理–数据共享和管理的原则、流程和系统。
缺陷密度– 每单位产品尺寸的缺陷数（例如，每 1000 行代码的问题报告）。
定义的过程– 作为改进的一部分要遵循的一组定义的步骤。
衍生度量– 由两个或多个基本度量的数学函数产生的数据。
派生要求– 未在客户要求中明确说明，但从 (1) 从上下文要求（例如，适用的标准、法律、政策、通用实践和管理决策）或 (2) 从需要指定的要求中推断出的要求一个产品组件。在产品或系统组件的分析和设计过程中也可能出现派生需求。
设计审查– 对设计进行正式、记录、全面和系统的检查，以评估设计要求和设计满足这些要求的能力，并识别问题并提出解决方案。
开发– 在整个 CMMI 中使用的开发意味着维护活动和开发活动。经验表明，如果一个组织追求卓越的工程设计，最佳实践应该应用于开发和维护项目。
开发计划– 指导、实施和控制一个或多个产品的设计和开发的计划。
指导实施– CMMI 模型过程域的一个共同特征，具有阶段性表示，将与管理过程性能、管理其工作产品的完整性以及涉及相关利益相关者相关的通用实践分组。
学科放大– 为解释特定学科（例如，系统工程或软件工程）的模型信息提供指导的模型组件称为“学科放大”。必要时将学科放大添加到其他模型组件。它们很容易找到，因为它们出现在页面的右侧，并且有一个标题，表明它们所涉及的学科（例如，“对于软件工程”）。
文档– 文档是数据的集合，无论记录在何种介质上。它通常具有永久性，可以被人类或机器读取。文件包括纸质文件和电子文件。
Enterprise – Enterprise 用于指代非常大的公司，这些公司由位于许多不同地点的许多组织和不同的客户组成。
进入标准– 在努力成功开始之前必须存在的状态。
等效分期– 等效分期是目标分期，使用定义的连续表示创建，以便可以将使用目标分期的结果与分阶段表示的成熟度级别进行比较。
退出标准– 在努力成功结束之前必须存在的状态。
预期的 CMMI 组件– CMMI 组件，解释可以做什么来满足所需的 CMMI 组件。模型用户可以明确地实现预期的组件或实现这些组件的等效替代实践。特定和通用实践是预期的模型组件
发现– 查看评估结果。
正式评估流程– 在决策分析和解决流程领域，请参阅介绍性说明中“正式评估流程”的定义。
功能分析– 检查定义的功能以识别完成该功能所需的所有子功能；识别功能关系和接口（内部和外部）并在功能架构中捕获它们；上层性能要求的向下流动，并将这些要求分配给下层的子功能。
功能架构–功能的分层安排、它们的内部和外部（聚合本身的外部）功能接口和外部物理接口、它们各自的功能和性能要求，以及它们的设计约束。
通用目标–通用目标被称为“通用”，因为相同的目标陈述出现在多个过程域中。在分阶段表示中，每个过程域只有一个通用目标。过程域中通用目标的实现意味着在计划和实施与该过程域相关的过程中改进了控制，从而表明这些过程是否可能有效、可重复和持久。通用目标是必需的模型组件，用于评估以确定是否满足过程域。
通用实践–通用实践提供制度化以确保与过程域相关的过程有效、可重复和持久。通用实践按通用目标和共同特征分类，是 CMMI 模型中的预期组件。（过程域中仅出现通用实践标题、声明和详细说明。）
通用实践阐述– 在特定实践之后，出现适用于过程域的通用实践标题和声明。在每个通用实践陈述之后，可以以纯文本形式出现带有标题“详细说明”的详细说明。通用实践详细说明提供了关于如何为过程域解释通用实践的信息。如果没有详细说明，则通用实践的应用是显而易见的，无需详细说明。
目标– “目标”是必需的 CMMI 组件，可以是通用目标或特定目标。当您在 CMMI 模型中看到“目标”一词时，它总是指模型组件（例如，通用目标、特定目标）。
不完整的流程– 未执行或仅部分执行的流程（也称为能力级别 0）。过程域的一个或多个特定目标没有得到满足。
独立组– 在过程和产品质量保证过程域中，请参阅介绍性说明中对“独立组”的讨论。
信息性 CMMI 组件– 帮助模型用户了解模型所需和预期组件的 CMMI 组件。这些组件可能包含示例、详细说明或其他有用的信息。子实践、注释、参考文献、目标标题、实践标题、来源、典型工作产品、学科放大和通用实践阐述是信息模型组件。
制度化– 组织作为其企业文化的一部分而经常遵循的根深蒂固的经营方式。
集成产品和流程开发– 一种系统的产品开发方法，可在整个产品生命周期内实现相关利益相关者的及时协作，以更好地满足客户需求。
集成团队– 一群具有互补技能和专业知识的人，他们致力于及时协作交付指定的工作产品。集成团队成员提供适合工作产品所有阶段的技能和倡导，并共同负责交付指定的工作产品。一个集成的团队应该包括来自组织、学科和职能部门的授权代表，这些代表与工作产品的成功息息相关。
接口控制– 在配置管理中，(1) 识别与一个或多个组织提供的两个或多个配置项的接口相关的所有功能和物理特性的过程，以及 (2) 确保对这些特性的拟议更改进行评估并在实施前获得批准。[IEEE 828-1983]。
首席评估师– 在 CMMI 产品套件中使用，已获得授权机构认可的人员，可以担任特定评估方法的评估团队负责人。
生命周期模型– 将产品的生命周期划分为多个阶段，指导项目从识别客户需求到产品报废。
经理– 项目经理是负责计划、指导、控制、构建和激励项目的人。他或她可以向在其职责范围内执行项目任务或活动的人员提供技术和行政指导和控制。项目经理最终对客户负责。
成熟度水平– 跨预定义的一组过程域的过程改进程度，其中实现了该组中的所有目标。
协议备忘录– 两方或多方之间具有约束力的谅解或协议文件。
Natural bounds – 由过程性能测量反映的固有过程，有时称为“过程的声音”。诸如控制图、置信区间和预测区间之类的技术用于确定变异是由于常见原因（即过程是可预测的或“稳定的”）还是由于某些可以并且应该被识别和识别的特殊原因造成的移除。
非开发项目– 在采购或开发过程中当前使用之前开发的供应项目。此类项目可能需要稍作修改才能满足其当前预期用途的要求。
非技术要求– 影响如何获得产品或服务的合同条款、承诺、条件和条款。示例包括要交付的产品、交付的商业现货 (COTS) 非开发项目 (NDI) 的数据权利、交付日期和具有退出标准的里程碑。其他非技术要求包括培训要求、站点要求和部署计划。
目标– 术语目标在 CMMI 中以日常意义使用；这是我们要完成的目标或目标。
客观证据– 用于 CMMI 评估材料、定性或定量信息、记录或事实陈述，这些信息与项目或服务的特征或过程要素的存在和实施有关，它们基于观察、测量或测试，哪些是可验证的。
客观评估– 根据使审查者的主观性和偏见最小化的标准审查活动和工作产品。客观评估的一个例子是由独立的质量保证部门根据要求、标准或程序进行的审计。
观察– 在 CMMI 评估材料中使用的书面记录，代表评估团队成员对在评估数据收集活动中看到或听到的信息的理解。书面记录可以采用陈述的形式，也可以采用其他形式，只要保留信息内容即可。
操作概念– 对实体使用或操作方式的一般描述。
操作场景– 对想象中的事件序列的描述，包括产品与其环境和用户的交互，以及产品组件之间的交互。操作场景用于评估系统的要求和设计，以及验证和验证系统。
优化过程– 基于对过程中固有变异的常见原因的理解而改进的定量管理过程。专注于通过渐进式和创新性改进来持续改进过程性能范围的过程。
组织– 组织是一种结构，在这种结构中，人们将一个或多个项目作为一个整体进行集体管理，其项目共享一名高级经理并在相同的政策下运作。
组织的业务目标– 由高级管理层制定的战略，以确保组织的持续存在并提高其盈利能力、市场份额和其他影响组织成功的因素。
组织成熟度– 组织明确和一致地部署记录、管理、测量、控制和持续改进的过程的程度。组织成熟度可以通过评估来衡量。
组织政策– 通常由高级管理层制定的指导原则，组织采用该原则来影响和确定决策。
组织单位– 作为评估对象的组织部分（也称为评估的组织范围）。组织单位部署一个或多个流程，这些流程具有连贯的流程上下文并在一组连贯的业务目标内运行. 组织单位通常是较大组织的一部分，但在小型组织中，组织单位可能是整个组织。
外包– 通过合同获得收购实体承诺投资以获得产品和服务的任何离散行动或提议行动的过程。
Peer review – 同行进行的审查，以找出可交付成果中的缺陷。
性能参数– 用于指导和控制渐进式发展的有效性度量和其他关键度量。
执行的过程– 使用已识别的输入工作产品（也称为能力级别 1）完成所需工作以生成已识别的输出工作产品的过程。过程域的特定目标得到满足。
计划过程– 由描述和计划记录的过程。描述和计划应协调一致，计划应包括标准、要求、目标、资源、任务等。
流程– 人们用来开发和维护系统及相关产品的一组活动、方法、实践和转换。
过程行动计划– 在组织过程焦点过程域中，请参阅介绍性说明中“过程行动计划”的定义。
流程行动团队– 负责为组织制定和实施流程改进行动计划中记录的流程改进活动的团队。
流程和技术改进– 在组织创新和部署过程域中，请参阅介绍性说明中对“流程和技术改进”的讨论。
过程领域– 过程领域是一个领域中的一组相关实践，当集体执行时，可以满足一组被认为对在该领域进行重大改进很重要的目标。所有 CMMI 过程域对于连续表示和阶段表示都是通用的。在阶段式表示中，过程域是按成熟度级别组织的。
过程资产– 组织认为对实现过程域目标有用的任何东西。
流程资产库– 可供组织或项目使用的流程资产资产集合。
过程属性– 适用于任何过程的过程能力的可测量特征。
流程能力– 通过遵循流程可以实现的预期结果范围。
过程背景– 评估输入中记录的一组因素，这些因素影响评估评级的判断和可比性。这些包括但不限于被评估的组织单位的规模；组织单位的人口统计数据；产品或服务的应用纪律；产品或服务的规模、重要性和复杂性；以及产品或服务的质量特征。
流程定义– 定义和描述流程的行为。流程定义的结果是流程描述。
流程描述– 为实现给定目的而执行的一组活动的书面表达，提供流程主要组件的操作定义。该文档以完整、精确和可验证的方式详细说明了流程的要求、设计、行为或其他特征。它还可能包括确定是否满足这些规定的程序。过程描述可以在活动、项目或组织级别找到。
流程元素–流程的基本单位。一个过程可以根据子过程或过程元素来定义。一个子流程可以进一步分解；流程元素不能。每个过程元素都包含一组密切相关的活动（例如，估算元素、同行评审元素）。可以使用待完成的模板、待提炼的抽象或待修改或使用的描述来描绘过程元素。流程元素可以是活动或任务。
过程组– 一组专家，可促进组织使用的过程的定义、维护和改进。
流程改进– 旨在提高组织流程的绩效和成熟度的活动计划，以及此类计划的结果。
过程改进目标– 建立的一组目标特征，用于指导以特定的可衡量方式改进现有过程的努力，无论是在结果产品特性（例如，质量、性能、符合标准等）方面还是在方式方面在其中执行过程（例如，消除冗余过程步骤、合并过程步骤、改进循环时间等）
过程改进计划– 在组织过程焦点过程域中，请参阅介绍性注释中“过程改进计划”的定义。
过程测量– 一组定义、方法和活动，用于对过程及其产生的产品进行测量，以便表征和理解过程。
流程所有者– 负责定义和维护流程的人员（或团队）。在组织层面，流程所有者是负责标准流程描述的个人（或团队）；在项目级别，流程所有者是负责描述已定义流程的个人（或团队）。因此，一个流程可能有多个不同责任级别的所有者。
流程绩效– 通过遵循流程获得的实际结果的衡量标准。它的特点是过程测量（例如工作量、周期时间和缺陷去除效率）和产品测量（例如可靠性、缺陷密度和响应时间）。
流程绩效基线– 通过遵循流程获得的实际结果的记录特征，用作比较实际流程绩效与预期流程绩效的基准。
过程性能模型– 过程及其工作产品的属性之间关系的描述，这些属性是从历史过程性能数据中开发出来的，并使用从项目中收集的过程和产品测量进行校准，并用于预测要通过以下方式实现的结果过程。
流程剪裁– 为特定目的制作、更改或调整流程描述。例如，项目根据组织的标准过程集裁剪其定义的过程，以满足项目的目标、约束和环境。
产品– 产品可被视为遵循流程的任何有形输出或服务，旨在交付给客户或最终用户。产品也可以是根据合同交付给客户的任何工作产品。
产品组件– 产品组件通常是产品的低级组件，并被集成以“构建”产品。产品组件可能是交付给客户的产品的一部分，或者用于产品的制造或使用。例如，对于那些生产手机电池的公司来说，手机电池就是一种产品。对于那些制造和交付手机的公司来说，电池是一个产品组件。
产品基线– 在配置管理中，最初批准的技术数据包（包括软件的源代码清单）在其生命周期的生产、操作、维护和后勤支持期间定义配置项。
产品组件要求– 产品组件要求提供产品组件的完整规范，包括配合、形式、功能、性能和任何其他要求。
产品生命周期– 工作产品是由生命周期过程产生的任何工件，也可以称为生命周期工作产品。生命周期工作产品可以包括需求规范、接口规范、架构规范、项目计划、设计文档、单元测试计划、集成和系统测试计划、制造产品组装过程等过程。
项目– 项目是一组受管理的相互关联的资源，可为客户或最终用户提供一个或多个产品。资源集有明确的开始和结束，并按计划运行。
产品线– 一组产品共享一组通用的、可管理的功能，以满足选定市场或任务的特定需求。
与产品相关的生命周期过程– 在产品生命周期的一个或多个阶段（即从概念到处置）与产品相关的过程，例如制造和支持过程。
产品需求– 将客户需求细化为开发人员的语言，将隐式需求转化为显式派生需求。
程序– (1) 一个项目。(2) 相关项目和支持它们的基础设施的集合，包括目标、方法、活动、计划和成功措施。
项目经理– 项目经理是负责计划、指导、控制、构建和激励项目的人。他或她可以向在其职责范围内执行项目任务或活动的人员提供技术和行政指导和控制。项目经理最终对客户负责。随着项目的规模、多样性和复杂性的变化，项目经理承担不同的角色和职责。
项目进度和绩效– 项目在实施项目计划方面取得的成果，包括工作量、成本、进度和技术绩效。
项目定义过程– 在集成项目管理过程域中，请参阅介绍性说明和建立项目定义过程特定实践中“项目定义过程”的定义。
原型– 产品或产品组件的初步类型、形式或实例，用作后期阶段或产品的最终完整版本的模型。
质量– 产品、产品组件或过程的一组固有特性满足客户要求的能力。
质量保证– 一种有计划的和系统的方法，用于确保管理层采用定义的标准、实践、程序和过程方法。
质量控制– 用于满足质量要求的操作技术和活动。
定量目标– 表示为定量测量的所需目标值。
定量管理过程– 使用统计和其他定量技术控制的定义过程。产品质量、服务质量和过程性能属性在整个项目中都是可测量和控制的。
参考模式– 用作测量某些属性的基准的模型。
相关利益相关者– 相关利益相关者用于指定被确定参与特定活动并包含在适当计划（例如项目计划）中的利益相关者。
必需的 CMMI 组件– CMMI 组件对于在给定的过程域中实现过程改进至关重要。这些组件用于评估以确定过程能力。特定目标和通用目标是必需的模型组件。
要求– (1) 用户解决问题或实现目标所需的条件或能力。(2) 为满足合同、标准、规范或其他正式规定的文件，产品或产品组件必须满足或拥有的条件或能力。(3) 条件或能力的书面表示，如 (1) 或 (2)。
需求分析– 基于对客户需求、期望和约束的分析确定产品特定的性能和功能特性；操作概念；人员、产品和流程的预计使用环境；和有效性的措施。
需求获取– 使用系统技术，如原型和结构化调查，主动识别和记录客户和最终用户的需求。
需求管理– 管理项目收到或产生的所有需求，包括技术和非技术需求以及组织对项目征收的需求。
需求可追溯性– 需求与其源需求、实施和验证之间关联的证据。
投资回报– 产出（产品）的收入与生产成本的比率，这决定了组织是否从执行生产某物的行动中受益。
风险分析–风险的评估、分类和优先级排序。
风险识别– 一种有组织的、彻底的方法，用于在实现目标的过程中寻找可能的或现实的风险。
风险管理– 一个有组织的分析过程，用于识别可能导致损害或损失的因素（识别风险），评估和量化识别的风险，并制定并在需要时实施适当的方法来预防或处理可能导致风险的原因重大损害或损失。
风险管理策略– 一种有组织的技术方法，用于识别可能导致损害或损失的因素（识别风险），评估和量化识别的风险，并制定并在需要时实施适当的方法来预防或处理可能导致重大风险伤害或损失。通常，风险管理是针对项目、组织或产品开发组织单位执行的。
根本原因– 根本原因是缺陷的来源，如果将其移除，则缺陷会减少或消除。
高级经理– 在 CMMI 中使用的术语高级经理是指组织中足够高级别的管理角色，该人的主要关注点是组织的长期健康和成功，而不是短期项目和合同的顾虑和压力。高级经理可能负责监督可能包含许多由项目经理管理的项目的项目群。
软件工程– (1) 将系统的、规范的、可量化的方法应用于软件的开发、操作和维护。(2) 研究方法如 (1)。
征集– 准备征集包和选择供应商（承包商）的过程。
招标包– 描述技术和非技术要求的正式文件，用于请求投标邀请（投标）和提案请求（提案），或请求能力声明和报价（报价）。否则，它被用作选择一个或多个供应来源以提供产品或服务的基础。
过程变异的特殊原因– 特定于某些瞬态环境而不是过程的固有部分的缺陷原因。
特定目标– 特定目标适用于过程域并解决描述为满足过程域而必须实施的内容的独特特征。特定目标是必需的模型组件，用于评估以帮助确定过程域是否得到满足。
特定实践– 特定实践是一项被认为对实现相关特定目标很重要的活动。特定实践描述了预期导致实现过程域特定目标的活动。具体做法是预期的模型组件。
稳定过程– 过程变异的所有特殊原因已被消除并防止再次发生的状态，以便仅保留过程过程变异的常见原因。
分阶段表示– 一种模型结构，其中实现一组过程域的目标建立了成熟度级别；每个级别为后续级别奠定基础。
利益相关者– 利益相关者是受项目结果影响或可能影响项目活动或产出的团体或个人。
标准流程– 指导在组织中建立通用流程的基本流程的操作定义。标准过程描述了预期被纳入任何已定义过程的基本过程元素。它还描述了这些过程元素之间的关系（例如，排序和接口）。
工作说明 – 完成项目所需的合同工作的描述。
统计可预测性– 使用统计和其他定量技术控制的定量过程的性能。
统计过程控制– 基于统计的过程分析和过程性能测量，将识别过程性能变化的常见和特殊原因，并将过程性能保持在限制范围内。
统计技术– 采用统计方法（例如，统计过程控制、置信区间、预测区间）的分析技术。
统计管理过程– 由基于统计的技术管理的过程，其中分析过程，确定过程变化的特殊原因，并将性能包含在明确定义的范围内。
优势– 在 CMMI 评估材料中使用，是 CMMI 模型实践的示范或值得注意的实施。
子流程– 作为更大流程一部分的流程。
供应商– (1) 交付产品或执行被收购服务的实体。(2) 个人、合伙企业、公司、法人、协会或其他服务机构与采购方签订协议（合同），以根据协议（合同）。
维持– 用于确保产品可由其最终用户或客户在操作上使用的流程。Sustainment 确保维护完成后，无论产品是否被客户或最终用户使用，产品都处于可操作状态。
系统工程– 管理将一组客户需求、期望和约束转换为产品解决方案并在整个产品生命周期中支持该解决方案所需的全部技术和管理工作的跨学科方法。这包括技术性能测量的定义、工程专业的集成以建立产品架构，以及平衡成本、性能和进度目标的支持生命周期过程的定义。
剪裁指南– 剪裁流程制作、更改或调整流程描述，通常在组织级别进行描述，以用于特定项目。对于大多数组织，一个组织过程定义不能或不会被所有项目 100% 遵循。通常需要一些适应。然后，裁剪指南描述什么可以修改，什么不能修改，并确定允许修改的过程组件。
目标概况– 在连续表示中，过程域列表及其相应的能力水平代表过程改进的目标。
Target staging – 在连续表示中，一系列目标配置文件描述了组织要遵循的过程改进路径。
技术数据包– 如果此类信息适用于产品和产品组件的类型，则可能包括以下项目的集合。
技术要求– 要获得或开发的产品或服务的属性（属性）。
测试程序– 设置、执行和评估给定测试结果的详细说明。
贸易研究– 基于标准和系统分析对替代方案进行评估，以选择实现既定目标的最佳替代方案。
培训– 在组织培训过程域中，请参阅 .training 的定义。在介绍性说明中。
单元测试– 测试单个硬件或软件单元或相关单元组。
验证– 验证表明所提供的产品（或将提供的产品）将满足其在操作环境中的预期用途。验证确保“您构建了正确的东西”。
验证– 验证包括针对所有选定要求（包括客户、产品和产品组件要求）验证产品和中间工作产品。验证本质上是一个增量过程。它从对需求的验证开始，通过对不断发展的工作产品的验证进行，最后在对已完成产品的验证中达到高潮。验证处理工作产品是否正确反映了指定的要求。验证可确保“您构建正确”。
验证实施– CMMI 模型过程域的一个共同特征，具有分阶段表示，将与更高级别管理层审查相关的通用实践分组，并对过程描述、程序和标准的符合性进行客观评估。
版本控制– 基线的建立和维护以及基线更改的识别，使返回到以前的基线成为可能。
弱点– CMMI 评估材料中使用的一种或多种 CMMI 模型实践的无效或缺乏实施。
工作分解结构– 工作要素及其相互之间以及与最终产品之间关系的安排。
工作产品– 术语工作产品在整个 CMMI 产品套件中使用，表示流程产生的任何工件。这些工件可以包括文件、文档、产品的一部分、服务、流程、规范和发票。被视为工作产品的过程的示例包括产品的制造过程、培训过程和处置过程。工作产品和产品组件之间的一个关键区别是工作产品不需要被设计或成为最终产品的一部分。
工作产品和任务属性– 用于帮助估计项目工作的产品、服务和项目任务的特征。这些特征包括诸如尺寸、复杂性、重量、形式、配合或功能等项目。它们通常用作推导其他项目和资源估算（例如，工作量、成本、进度）的一种输入
CMMI – 首字母缩略词
这是按字母顺序排列的所有 CMMI 首字母缩略词的列表。
| Acronym | 展开形式 |
|---|---|
| ARC | CMMI的评估要求 |
| CAF | CMM评估框架 |
| CAR | 因果分析和解决（过程域） |
| CAU | 驾驶舱航电升级 |
| CBA IPI | 基于 CMM 的内部过程改进评估 |
| CBT | 基于计算机的培训 |
| CCB | 配置控制板 |
| CM | 配置管理（过程域） |
| CMM | 能力成熟度模型 |
| CMMI | 能力成熟度模型集成 |
| CMMI-SE/SW | 系统工程和软件工程的能力成熟度模型集成 |
| CMMI-SE/SW/IPPD | 系统工程、软件工程以及集成产品和过程开发的能力成熟度模型集成 |
| CMMI-SE/SW/IPPD/SS | 系统工程、软件工程、集成产品和流程开发以及供应商采购的能力成熟度模型集成 |
| COTS | 商业现货 |
| CPM | 关键路径法 |
| DAR | 决策分析和解决（过程域） |
| EIA | 电子产业联盟 |
| EIA/IS | 电子工业联盟临时标准 |
| FAA | 美国联邦航空管理局 |
| FAA-iCMM | 美国联邦航空管理局综合能力成熟度模型 |
| GG | 通用目标 |
| GP | 通用实践 |
| IDEAL | 发起、诊断、建立、行动、学习 |
| IEEE | 电气和电子工程师学会 |
| INCOSE | 国际系统工程委员会 |
| IPD-CMM | 集成产品开发能力成熟度模型 |
| IPM | 集成项目管理（过程域） |
| IPPD | 集成产品和工艺开发 |
| IPT | 综合产品团队 |
| ISM | 集成供应商管理（过程域） |
| ISO | 国际标准化组织 |
| ISO/IEC | 国际标准化组织和国际电工委员会 |
| IT | 集成团队（过程域） |
| KSLOC | 数千源代码行 |
| MA | 测量和分析（过程域） |
| MOA | 协议备忘录 |
| NDI | 非发育项目 |
| NDIA | 国防工业协会 |
| OEI | 集成的组织环境（过程域） |
| OID | 组织创新和部署（过程域） |
| OPD | 组织过程定义（过程域） |
| OPF | 组织过程焦点（过程域） |
| OPP | 组织过程绩效（过程域） |
| OT | 组织培训（过程域） |
| OUSD/AT&L | 国防部、采购、技术和后勤部副部长办公室 |
| P-CMM | 人员能力成熟度模型 |
| PA | 工艺区 |
| PAIS | 过程评价信息系统 |
| PASS | 主要航电软件系统 |
| PERT | 计划评审技术 |
| PI | 产品集成（过程域） |
| PMC | 项目监控（过程域） |
| PP | 项目计划（过程域） |
| PPQA | 过程和产品质量保证（过程域） |
| QFD | 质量功能展开 |
| QPM | 定量项目管理（过程域） |
| RD | 需求开发（过程域） |
| REQM | 需求管理（过程域） |
| RSKM | 风险管理（过程域） |
| SA-CMM | 软件获取能力成熟度模型 |
| SAM | 供应商协议管理（过程域） |
| SCAMPI | 过程改进的标准 CMMI 评估方法 |
| SDMP | 软件开发管理计划 |
| SE | 系统工程 |
| SE-CMM | 系统工程能力成熟度模型 |
| SEC | 软件执行委员会 |
| SECAM | 系统工程能力评估模型 |
| SECM | 系统工程能力模型 |
| SEI | 软件工程学院 |
| SE/SW | 系统工程与软件工程 |
| SEPG | 软件工程过程组 |
| SG | 具体目标 |
| SP | 具体做法 |
| SPMN | 软件项目经理网络 |
| SS | 供应商采购 |
| STSC | 软件技术支持中心 |
| SW | 软件工程 |
| SW-CMM | 软件能力成熟度模型 |
| TS | 技术解决方案（过程域） |
| VAL | 验证（过程区） |
| VER | 验证（过程域） |
| WBS | 工作分解结构 |
