浅谈 CMMI · Albert's Stack

实践域简称	实践域名称	实践过程总数	Level1	Level2	Level3	Level4	Level5
CAR	原因分析域解决方案	11	1	2	5	2	1
CM	配置管理	7	1	6
DAR	决策分析与解决方案	8	2	5	1
EST	估算	6	1	3	2
GOV	治理	7	1	4	2
II	实施设施	7	1	2	3	1
MPM	管理性能与度量元	22	2	6	6	5	3
MC	监督和控制	10	2	4	4
OT	组织级培训	9	1	2	6
PR	同行评审	6	1	4	1
PLAN	策划	15	2	8	4	1
PAD	过程资产开发	11	1	3	7
PCM	过程管理	12	3	2	6	1
PQ	过程质量保证	6	1	4	1
PI	产品集成	10	1	6	3
RDM	需求开发与管理	14	1	6	7
RSK	风险和机会管理	8	1	2	5	1
SAM	供应商合同管理	10	3	4	2
TS	技术解决方案	10	1	3	6
VV	验证与确认	7	2	3	2
合计		196	29	79	73	10	4

本表用于说明 CMMI 各实践域在不同成熟度等级下的过程分布情况，帮助理解三级、五级评审所覆盖的范围。

3. CMMI 评审过程

3.1 评审准备

项目准备：选择 3–5 个代表性项目参与评审
文档准备：补齐并完善项目相关文档（注意：部分文档可裁剪，部分为必需项）
人员准备：确定参评项目人员名单
统一理解：参评人员需熟悉对应文档内容

3.2 评审方式

评审以会议形式进行
评审团通常由：
- 1 名主评审
- 3–4 名同行专家组成
采用一问一答的方式展开

3.3 评审核心逻辑

评审过程可以概括为三个步骤：

问 → 答 → 查

问：评审团询问项目的实际执行过程
答：项目成员结合项目情况进行回答
查：评审团依据回答内容检查对应项目文档

3.4 评审总结

在所有抽查项目和人员完成后进行总结
评审团会指出：
- 研发流程中的优势
- 存在的不足
通常情况下，都能正常通过评审，并且评审后会有评审报告，且会给出改进建议。

4. CMMI3 评审案例 - 需求开发与管理（RDM）

实践域简称	过程描述	中文翻译
RDM	1.1 Record requirements.	记录需求
RDM	2.1 Elicit stakeholder needs, expectations, constraints, and interfaces or connections.	引导干系人的需要、期望、约束、接口或连接。
RDM	2.2 Transform stakeholder needs, expectations, constraints, and interfaces or connections into prioritized customer requirements.	转换干系人的需要、期望、约束、接口或连接为排列了优先级的客户需求
RDM	2.3 Develop an understanding with the requirements providers on the meaning of the requirements.	和需求提供者关于需求的含义达成一致的理解
RDM	2.4 Obtain commitment from work effort participants that they can address the requirements.	从工作投入的参与者处获得他们对需求可实现的承诺
RDM	2.5 Develop, record, and maintain bidirectional traceability among requirements, activities, and work products.	建立、记录、维护需求与活动、工作产品之间的双向可跟踪性
RDM	2.6 Ensure that plans, activities, and work products remain consistent with requirements.	确保计划、活动和工作产品与需求保持一致
RDM	3.1 Develop and keep requirements updated for the solution and its components in accordance with the organizational process.	根据组织级的过程，开发和保持更新解决方案和其构件需求
RDM	3.2 Develop operational concepts and scenarios.	定义操作概念和场景
RDM	3.3 Allocate the requirements to be implemented.	分配待实现的需求
RDM	3.4 Identify, develop, and keep updated interface or connection requirements.	识别、定义、保持更新接口与连接需求
RDM	3.5 Ensure that requirements are necessary and sufficient.	确保需求是必要的和充分的
RDM	3.6 Balance stakeholder needs and constraints.	平衡干系人的需要和约束
RDM	3.7 Validate requirements to ensure the resulting solution will perform as intended in the target environment.	确认需求以确保最终的解决方案可以在目标环境中运行

上表所示为 CMMI 中需求开发与管理（RDM）实践域的过程要求。每一条过程要求可以理解为一项规范性约束，用于说明在需求阶段应当完成的事项。

在实际评审过程中，评审官通常会围绕这些过程要求，按照 “提问 → 说明 → 核查” 的方式展开评审。

4.1 例一：RDM 1.1 记录需求

评审官提问
- 请问贵方如何开展需求记录，确保需求可追溯、无遗漏？
项目方回答
- 我们建立标准化需求记录机制，通过需求文档、需求规格说明书，对项目全周期各类需求进行统一记录。
评审官后续行为
- 要求项目方明确需求文档的存放位置、管理主体及更新机制；
- 随机抽查对应项目文档，核查其完整性、规范性；
- 对照回答核查文档中需求记录的完整性、可追溯性，验证机制落地效果。

4.2 例二：RDM 2.3 与需求提供者就需求含义达成一致理解

评审官提问
- 请问贵方如何确保项目团队与需求提供者对需求含义达成一致，避免理解偏差？
项目方回答
- 我们建立需求共识确认机制，将相关文档提交需求提供者审核，通过可追溯方式确认双方达成一致。
评审官后续行为
- 要求项目方定位核心文档，确认其完整性及更新痕迹；
- 核查文档中需求提供者的确认记录，验证确认行为有效性；
- 追问确认时间及流程位置，核查确认环节是否规范。

5. 总结

CMMI 是什么？ 能力成熟度模型集成，用于评估和改进企业过程能力。
CMMI 怎么评？ 通过项目人员与项目文档的一致性来验证过程执行情况。
CMMI 有用吗？ 提升企业规范性与对外竞争能力（有利于竞标），但不能替代实际管理判断。