数字化 IT 从业者知识体系 | 软件交付与协作 —— CMMI

本文作者：何文强 — CODING 高级解决方案架构师 具有一线互联网、物联网独角兽、全国股份制银行、新型智慧交通等跨行业从业经历，历任 Java 开发高级工程师、DevOps 技术专家、高级研发经理等职，对微服务、敏捷、DevOps、容器技术有深刻的理解和丰富的实践。

‍能力成熟度模型集成（英语：Capability Maturity Model Integration，简称 CMMI 或“希迈”）是一种改进过程的方法，其目的是协助提升组织的绩效。

“CMMI”目前致力于三个感兴趣的区域：

• 产品和服务开发——希迈开发方面（英文：CMMI for Development，简称 CMMI-DEV）
• 服务创建、管理和交付——希迈服务方面（英文：CMMI for Service，简称 CMMI-SVC）
• 产品和服务采购——希迈采购方面（英文：CMMI for Acquisition，简称 CMMI-ACQ）

接下来针对“希迈开发方面”进行分享。

CMMI 发展背景

CMMI 模型最初是为美国国防部评估其软件承包商的质量和能力而创建的，现已扩展到软件工程之外，以帮助世界各地的任何行业的组织了解其当前的能力和性能水平，并提供指导以优化业务成果。

软件过程改进的问题：

• 不能集中其不同过程改进的能力以取得更大成绩；
• 要进行一些重复的培训、评估和改进活动，因而增加了许多成本；
• 遇到不同模型中有一些对相同事物说法不一致，或活动不协调，甚至相抵触；
• 针对上诉这些问题，美国国防部与耐基梅隆大学的软件工程学院合作开发了 CMM 框架。

CMMI 发展历程

1984 年在美国国防部的支持下，卡内基美隆大学（CMU）成立了软件工程学院（SEI），同年，美国国防部委托 SEI 和美国国防工业协会（NDIA）共同进行一项研究，用于评估国防部委托的外部软件公司的软件开发能力。

1987 年，CMM 初稿完成，这是关于 CMM/CMMI 的第一个成熟度框架，该框架提供了软件过程评估和软件能力评价两种评估方法和软件成熟度问题单。

1991 年，SEI 将软件过程成熟度框架进化为软件能力成熟度模型（简称 SW-CMM），并发布了最早的 SW-CMM 1.0 版。经过两年的试用，1993 年 SEI 正式发布了 SW-CMM 1.1 版，这是目前使用最为广泛的版本。

2000 年，SEI 发布 CMMI V1.0，CMM 已经演化为 CMMI。2002 年，SEI 发布 CMMI-SE/SW V1.1 （CMMI for System Engineering and Software Engineering）。

2006 年，SEI 发布 CMMI V1.2。2011 年，SEI 发布 CMMI V1.3 版本，这是目前使用最多的 CMMI 版本。

2018 年，CMMI 研究院正式发布 CMMI 2.0 中文版。

CMMI 原则

强调高层管理者的支持。过程改进往往也是由高层管理者认识和提出的，大力度的一致支持是过程改进的关键。

仔细确定改进目标，首先应该对给定时间内的所能完成的改进目标进行正确的估计和定义并制定计划。选择能够达到的目标和能够看到对组织的效益。

选择最佳实践，应该基于组织现有的软件活动和过程财富，参考其他标准模型，取其精华去其糟粕，得到新的实践活动模型。

过程改进要与组织的商务目标一致，与发展战略紧密结合。

CMMI-DEV 过程域（22 个）

• 需求管理（REQM）

管理需求和识别需求与计划项目之间的差异性。

• 项目计划（PP）

评估计划参数，指定内外任务，开发项目管理计划。

• 项目跟踪与监控（PMC）

监控项目过程和绩效以防和项目计划相违背；当实际的情况与期望数值有明显差异时，应采取纠正行动。

• 配置管理（CM）

建立和维护基线及其完整性、追踪和控制工作产品的变化。

• 供应商协议管理（SAM）

监督供应商的工作产品与过程，追踪供应商的进展与绩效，适当地修订供应商协议；执行验收审查与测试供应商所产生的产品组件。

• 软件过程与产品质量保证（PPQA）

客观地评价过程和相关产品工作是否严格适用于过程描述、标准和程序。

• 度量与分析（MA）

排列信息识，别需求项目、组织或企业目标的度量目标和活动，并为其提供度量结果。

• 需求开发（RD）

收集项目干系人需求，规划产品和产品组件，分析和确认这些需求。

• 技术解决（TS）

在产品或产品组件中描述迭代循环周期，选择解决方案和开发实现设计。

• 确认（VAL）

为合法检查故障选择产品和产品组件；选择检查方法；建立和维护检查程序、标准和在确保产品和产品组件满足最终用户需求的实际操作环境。

• 验证（VER）

建立和维护检查方法、程序、标准和环境，以及执行同级评审和检验选择的产品。

• 产品集成（PI）

开发产品集成策略，程序和环境；确保产品组件间的界面兼容性；组装产品组件；实现此产品和产品组件。

• 集成项目管理（IPM）

从始至终地建立和维护项目的过程定义，在项目管理中运用项目过程定义和相关人员协作。

• 组织过程焦点（OPF）

为让过程变得有价值，及计划、执行和部署过程改进，决定过程改进的时机。

• 组织过程定义（OPF）

建立和维护一些列标准过程价值，通过组织增加组织过程有价值的资产，以及为团队制定规则。

• 组织培训（OT）

从战略上识别组织培训需求，并提供培训。

• 风险管理（RSKM）

定义一个有风险的管理策略，识别、分析和减轻风险。

• 决策分析与解决方案（DAR）

根据能识别出与制定标准差别的官方过程评价选择性地分析可能的决定，同时也可以为哪些决定需要改进的过程评价提供指导。

• 组织过程性能（OPP）

为组织的一系列标准过程建立和维护过程绩效基线和过程绩效模型。

• 量化项目管理（QPM）

运用统计学、其他定量技术和历史数据，建立质量和过程绩效目标、排列项目的过程定义、选择子过程理解过程绩效、监控子过程和项目绩效、执行总过程从分析原因到描述过程绩效缺陷。

• 组织性能管理（OPM）

利用统计学和其他定量技术分析组织的经营绩效，目的是决定绩效的不足，识别和部署过程和为过程绩效目标提供帮助的改进技术。

• 原因分析与解决方案（CAR）

定义和系统地描述选择结果的原因分析。

CMMI-DEV 模型的表示法

在 CMMI 中，每一种 CMMI 学科模型都有两种表示方法：阶段式表示法和连续式表示法。

不同的表示法具有不同的结构。连续式表示法强调的是单个过程域的能力，从过程域的角度考察极限和度量结果的改善，其关键术语是“能力”，阶段式表示法强调的是组织的成熟度，从过程域集合的角度考察整个组织的过程成熟度阶段，其关键术语是“成熟度”。

连续性表述

连续表示的优点是提供了灵活性。用户可根据具体的改进目标来选择需要实现的过程域及其实现次序。

• 不完整级：部分执行。未实现流程区域的一个或多个特定目标。
• 已执行级：它是满足流程区域中所有特定目标的不完整过程。
• 已管理级：这是一个已执行流程，具有支持流程所需的基础结构，以便根据组织策略中的计划和定义执行流程，雇用技术熟练的人员具备必要的知识，涉及所有相关利益相关者，并监控、控制和审查流程。
• 已定义级：它是一个托管流程，根据组织标准流程集根据其定制指南进行定制，并为组织改进提供产品、措施等。
• 量化管理级：它是使用统计技术控制的已定义过程。
• 优化级：这是一个定量管理的过程，通过定量了解流程中常见的变异原因而得到改进。

连续性表述过程域

每个过程域之间不是独立个体，是存在关系的，为了支持连续性表述 CMMI 将过程域分为项目管理、过程管理、工程管理和支持 4 种类型。

项目管理

• 需求管理（REQM）
• 项目计划（PP）
• 项目跟踪与监控（PMC）
• 供应商协议管理（SAM）
• 风险管理（RSKM）
• 集成项目管理（IPM）
• 量化项目管理（QPM）

过程管理

• 组织过程焦点（OPF）
• 组织过程定义（OPD）
• 组织过程性能（OPP）
• 组织培训（OT）

工程管理

• 需求开发（RD）
• 技术解决（TS）
• 验证（VER）
• 确认（VAL）
• 产品集成（PI）

支持

• 配置管理（CM）
• 过程域产品质量保证（PPQA）
• 度量与分析（MA）
• 决策分析与解决方案（DAR）
• 原因分析与解决方案（CAR）

阶段性表述

阶段表示是从 CMM 模型继承而来，已经过多年的实践检验。它提供了一个明确的、被证实的过程改进路径，遵循这条路径不需要过多的讨论和争论。而且由于它的明确性和统一性，有助于进行跨组织的比较。

初始级：软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。

• 过程处于混沌状态，有时候只是一些无秩序的习惯；
• 过程性能依赖于个人能力和英雄行为；
• 一旦指派最优秀的人员执行任务时，高质量和出色表现是有可能的；
• 过程性能不可预测；
• 没有有效的实施管理活动。

已管理级：建立了基本的 项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。

• 项目管理是有纪律的；
• 组织方针建立并遵照执行；
• 项目计划和过程描述已经文档化并执；
• 在整个生命周期指派了职责和权利；
• 纪律保证现有惯例在多种压力情况下得以维持；
• 工作任务和工作产品对于管理者在定义上的点是可见的。

已定义级：已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。

• 建立了组织的标准软件过程；
• 建立了负责组织的软件过程活动和机构；
• 项目定义的软件过程；
• 项目进展和状态的可见性；
• 组织的软件能力均衡、一致；
• 具有受到维护的过程描述；
• 能为本组织的过程资源贡献工作成果、度量项目以及其他过程改进信息。

量化管理级：分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。

• 过程性能的可预见性；
• 使用统计和其他量化技术来控制项目和已选择的子系统的性能；
• 组织与项目针对质量与过程绩效建立量化目标，并使用他们当做管理过程的准则。

优化级：过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。每个等级都被分解为 过程域，特殊目标和特殊实践，通用目标、通用实践和共同特性。

• ‍‍‍‍‍‍‍‍关注管理和改进组织性能；
• 建立组织量化过程改进目标；
• 持续改进过程绩效；

阶段性表述过程域‍‍‍‍‍‍‍‍

阶段式表述提供由成熟度第 1 级到第 5 级的改进路径，包含达成每一个成熟度等级过程域的目标。为了支持阶段式表述，群组成熟度指出实行哪些域以达成每一个成熟度等级。

已管理级

• 需求管理（REQM）
• 项目计划（PP）
• 项目跟踪与监控（PMC）
• 配置管理（CM）
• 软件过程域产品质量保证（PPQA）
• 供应商协议管理（SAM）
• 度量与分析（MA）

已定义级

• 需求开发（RD）
• 技术解决（TS）
• 确认（VAL）
• 验证（VER）
• 产品集成（PI）
• 集成项目管理（IPM）
• 组织过程焦点（OPF）
• 组织过程定义（OPD）
• 组织培训（OT）
• 风险管理（RSKM）

量化管理级

• 组织过程性能（OPP）
• 量化项目管理（QPM）

优化级

• 组织性能管理（OPM）
• 原因分析与解决方案

阶段性表述模型总结

连续性表述 VS 阶段性表述

能力与成熟度等级对照表

过程域对照表

CMMI 优势与不足

优势

• 过程改进能扩展到整个企业；
• 各模块间不一致的矛盾得到解决；
• 大型组织中可节省费用；
• 鼓励沟通和交流；
• 提升企业整体管理水平；
• 满足特殊工程（国防）的要求。

不足

• 文档依赖严重；
• 缺少循序渐进；
• 实施成本较高；
• 流程复杂冗余。

《数字化 IT 从业者知识体系》背景

数字化和可持续发展是中国企业未来发展的两大主题，掌握数字化知识，具备数字化能力，应用数字化技术是我们 IT 从业者未来核心竞争力所在。《数字化 IT 从业者知识体系》的初衷是为 IT 从业者提供的系统性的数字化知识体系，内容涵盖管理实践、工程实践、技术实践三个层次，涉及软件开发方法、应用技术架构、应用部署与管理、软件交付与协作四大方面。

在接下来的《数字化 IT 从业者知识体系》系列文章，何文强将从软件开发方法、应用技术架构、应用部署与管理、软件交付与协作四个方面，为大家进行逐一分享介绍：

1. 软件开发方法主要包括瀑布、敏捷、精益等；

2. 应用技术架构主要包括微服务架构、服务网格架构、无服务器架构、分布式多运行架构等；

3. 应用部署与管理主要包括但不限于虚拟化技术、容器技术与容器编排等；

4. 软件交付与协作主要包括但不限于 CMMI、ITIL、DevOps 等。

相信该知识体系有利于 IT 从业者构建丰富的技术体系、全面的技术视野和系统的能力建设。欢迎大家前往《数字化 IT 从业者知识体系》话题进行详细阅读。