Day23-05｜5.1.5 软件能力成熟度模型：让组织从“靠人交付”走向“可预测改进”

本文对应《系统架构设计师教程（第2版）》第5章“软件工程基础知识”5.1.5“软件能力成熟度模型”。软件能力成熟度模型（Capability Maturity Model，CMM）及其后续的 CMMI，为评价和改进组织的软件过程能力提供了分层框架。它关注的不是某个项目是否偶然成功，而是组织能否持续、稳定、可度量地完成软件开发、维护和交付。系统架构师需要理解成熟度模型如何影响需求、架构、质量、配置、风险、度量和持续改进。

一、学习目标与考试定位

完成本节后，应能够解释软件过程能力和成熟度的含义，掌握 CMM/CMMI 阶段式成熟度等级的基本思想，理解初始级、可重复级、已定义级、已管理级和优化级的特征；能够区分过程域、能力等级、成熟度等级、评估和认证；能够分析组织从个人英雄式开发走向制度化和量化管理的路径；能够在案例题中识别成熟度问题并提出改进方案；能够在论文中把过程改进与架构治理、质量指标和项目结果联系起来。

软考题目常考的不是某个英文名称，而是“某组织处于什么状态”“下一步应该建设什么过程能力”“为什么流程文件很多但项目仍然失控”。高分答案要避免把成熟度等同于文档数量或管理层级，而应关注过程是否被定义、执行、度量、控制并持续改进，是否真正改善了交付结果。

二、软件过程能力与成熟度

过程能力表示组织按照既定过程稳定完成预期结果的能力。成熟度表示组织过程从无序、依赖个人经验逐步发展为制度化、标准化、可度量和持续优化的程度。低成熟度组织可能有优秀个人和成功项目，但成功不可预测、难以复制；高成熟度组织并不意味着每个项目都没有问题，而是能够用数据发现问题、分析原因、采取措施并持续改进。

需要区分项目层面和组织层面。一个项目临时建立的流程不代表组织具有稳定能力；一个组织有标准过程，也不代表每个项目无需裁剪。成熟度模型强调组织过程资产、项目执行、管理机制和结果反馈之间的关系。

可以用下面的演化链理解成熟度：

个人经验驱动 → 基本项目管理 → 组织标准过程 → 量化管理 → 持续优化

三、CMM/CMMI 阶段式成熟度等级

1. 初始级

过程通常是临时和无序的，项目成功主要依靠个人能力和英雄式行为。需求、进度、成本、质量和风险管理缺乏稳定方法，类似项目之间难以复用经验。面对人员变动、需求变化或规模扩大时，结果容易失控。

2. 可重复级

组织建立了基本项目管理纪律，能够根据以往成功项目的经验重复类似做法。常见重点包括需求管理、项目计划、项目监控、供应商管理、质量保证和配置管理。此阶段的目标不是让所有过程高度标准化，而是先建立承诺、跟踪和控制能力。

3. 已定义级

组织建立并维护统一的软件过程，项目在组织标准过程基础上进行裁剪。过程、角色、活动、输入输出、模板、度量和培训更加明确，项目之间能够共享过程资产。架构设计、需求、测试、风险和配置等活动不再完全依赖个人记忆。

4. 已管理级

组织和项目使用度量数据对过程进行定量管理，能够识别波动、建立基线、预测结果和控制偏差。质量、进度、成本、性能和缺陷等指标被用于决策，而不是只在项目结束后做统计。量化管理要求数据可信、口径一致、采集成本可接受，不能为了“达标”制造指标。

5. 优化级

组织持续关注过程改进、缺陷预防、创新技术和根因分析，能够根据数据和变化主动优化过程。改进不是一次性的制度发布，而是通过试点、度量、反馈、推广和复盘形成闭环。优化级也要防止盲目追逐新工具，创新必须与业务价值、质量和风险结果联系。

四、过程域和能力等级

CMMI 可以采用阶段式表示或连续式表示。阶段式表示关注组织整体成熟度等级，便于形成分阶段改进路线；连续式表示关注某个过程域的能力等级，组织可以根据业务优先级逐步提升特定能力。两种表示关注点不同，不能把过程域能力等级与组织成熟度等级简单等同。

过程域是相互关联的实践集合，围绕某类目标组织，例如需求管理、项目计划、项目监控、配置管理、过程与产品质量保证、测量与分析、风险管理、技术解决方案、验证和确认等。不同版本模型的具体过程域和术语可能存在差异，考试应以教材和题干版本为准。理解的重点是：过程域要有目标、实践、角色、产物和客观证据。

五、成熟度建设的关键过程

1. 需求管理

建立需求获取、分析、确认、基线、变更和追踪机制，保证需求与设计、实现、测试和交付保持一致。架构师尤其要识别架构驱动需求和质量属性，把性能、安全、可靠性、可维护性等要求变成可验证场景。

2. 项目计划与监控

依据范围、任务分解、依赖、资源、估算和风险建立计划，并通过实际数据跟踪偏差。计划不是一次性排期表，要支持滚动更新和预测。架构任务、技术验证、环境准备、数据迁移和性能测试不能被遗漏在计划之外。

3. 配置管理

对源代码、需求、架构文档、接口、数据库脚本、部署配置、测试数据和基础设施进行版本、基线、变更和审计管理。配置管理的目的不是增加审批，而是确保任何交付物都可追溯、可重建、可回滚。

4. 质量保证与验证确认

质量保证关注过程是否符合要求，验证确认关注产品是否正确、是否满足用户和业务目标。架构评审、代码评审、自动化测试、性能测试、安全测试、验收和生产验证都应有明确准则和证据。

5. 风险管理

识别技术、需求、人员、供应商、进度、安全、合规和运维风险，评估可能性和影响，指定责任人和处置策略。成熟度提高后，组织不仅在项目开始时列风险，还会利用历史数据和指标预测风险，并在重大变更时自动触发复评。

6. 测量与分析

指标应服务于决策，例如需求变更率、缺陷发现阶段、缺陷逃逸率、构建成功率、发布失败率、平均恢复时间、技术债务规模和架构依赖变化。指标要有定义、数据源、采集频率、责任人、基线和使用场景，不能只追求数量好看。

六、成熟度模型对架构工作的启示

低成熟度组织中，架构师经常被迫充当“救火英雄”：临时排查性能、手工修复配置、口头传递设计意图。提升成熟度后，架构知识进入组织过程资产，通过架构模板、决策记录、参考架构、评审清单、接口规范和培训复用。架构活动也从个人判断逐步走向可审查、可度量和可演化。

架构治理可建立以下机制：重大系统必须进行架构驱动需求识别；高风险方案必须做原型和评审；关键决策记录备选方案、理由和影响；设计、代码、测试和部署保持追踪；架构偏离需要变更审批或例外记录；运行指标和事故复盘反馈到架构改进；技术债务进入计划并设定偿还目标。

七、过程改进不能落入形式主义

常见失败是先编写大量流程文件，要求每个项目填表，却不解决实际瓶颈。过程改进应从业务结果和痛点出发，例如发布失败多，就改进配置、自动化测试和回滚；缺陷总在上线后发现，就把验证前置并完善完成定义；架构决策反复争论，就建立决策记录和评审机制；需求不断返工，就改善需求确认、原型和追踪。

过程应适度裁剪。小项目不需要复制大型组织的全部审批，但必须保留与风险相匹配的需求、配置、测试和发布证据。流程越重不一定越成熟，真正的成熟度体现为过程能稳定产生预期结果，并且组织可以用数据和反馈改进过程。

八、案例分析：从个人英雄到组织能力

某软件公司有一位资深架构师，项目几乎都依赖他解决接口、性能和发布问题。他离职后，项目延期、缺陷增加，团队无法恢复生产环境。公司随后建立大量文档模板，但开发人员认为填写表格浪费时间，项目质量没有明显改善。

问题首先在于关键知识没有进入组织过程资产，架构决策、接口约束、部署方法和故障经验都停留在个人头脑中；其次是过程改进从文档出发，没有针对需求追踪、配置管理、测试自动化、培训和责任机制；再次是没有用结果指标验证改进是否有效。

改造可以分阶段实施。可重复级先建立需求基线、项目计划、配置管理、质量保证和风险登记，确保项目基本可控；已定义级建立架构决策记录、参考架构、接口规范、评审清单和培训，允许项目根据规模裁剪；已管理级统一缺陷、发布、恢复和性能指标，建立基线并分析偏差；优化级通过事故根因分析、技术债务治理和自动化创新减少重复问题。

验收指标包括关键架构决策可追溯率、关键组件文档覆盖率、人员替换后的恢复时间、发布失败率、缺陷逃逸率、架构违规数量和事故复发率。只有指标改善且团队能够独立交付，才能证明成熟度真正提高。

九、评估与改进路线

成熟度评估要准备组织政策、项目计划、需求和变更记录、架构与设计、测试报告、配置基线、度量数据、培训记录、质量审计和改进证据。评估不是为了寻找“谁做错了”，而是确认过程是否定义、执行、管理和有效。

改进路线应选择少量高价值过程域试点，明确当前基线、目标状态、措施、责任人、资源、周期和验证指标。试点成功后总结经验并推广，再进入下一轮改进。若一次性要求全组织达到最高等级，容易产生大量形式化材料和抵触，反而削弱改进效果。

十、课后练习

练习一：单项选择

某组织的项目成功主要依赖少数专家，项目之间无法稳定复用经验，最符合的成熟度特征是（ ）。

A. 初始级；B. 已定义级；C. 已管理级；D. 优化级。

答案：A。过程临时、依赖个人、结果不可预测是初始级的典型特征。

练习二：简答题

请比较阶段式表示和连续式表示的关注点。

参考答案：阶段式表示关注组织整体成熟度，按照从初始到优化的路径推进，便于形成统一路线和对外沟通；连续式表示关注具体过程域的能力等级，组织可以根据业务优先级选择先提升某些能力。二者的评价视角和使用方式不同，过程域能力等级不能直接等同于组织整体成熟度等级。

练习三：案例分析

某公司要求所有项目严格执行统一流程，文档数量增加，但发布失败率和线上缺陷没有下降。请分析原因并提出改进措施。

参考答案：流程可能脱离实际痛点，重文档轻结果；项目没有真正执行或缺少客观证据；过程域之间没有形成闭环，需求、架构、测试、配置和发布相互脱节；指标只统计文档而没有衡量质量和交付结果。应从发布失败和缺陷逃逸的根因入手，改进配置基线、自动化构建、测试前置、发布验证和回滚；对流程进行裁剪，明确输入输出、责任和最小证据；建立缺陷发现阶段、发布失败率、恢复时间、变更失败率等指标；通过试点、度量、复盘和推广持续优化，而不是继续增加表单。

十一、论文素材

论文可写：项目初期团队依赖个人经验，需求变更、架构决策、配置和发布缺少统一管理。为提升软件过程能力，我先建立需求基线、架构评审、风险登记、配置管理和质量保证等基本项目纪律；随后沉淀参考架构、决策记录、接口规范和过程资产，并允许不同项目按规模和风险裁剪；在稳定运行后统一缺陷、发布、性能和恢复指标，建立基线并分析偏差；对重复故障开展根因分析，推动自动化测试、持续交付和技术债务偿还。最终通过缺陷逃逸率、发布失败率、平均恢复时间和架构违规数验证过程改进效果。

十二、今日复盘

CMM/CMMI 的核心不是文件越多越成熟，而是组织能否持续产生可预测、可度量、可改进的结果。五级成熟度体现从个人经验、基本项目管理、组织标准过程、量化管理到持续优化的演化；阶段式表示关注组织整体，连续式表示关注过程域能力。架构师应把架构决策、质量属性、风险、配置、测试和技术债务纳入过程资产与指标闭环。下一篇进入 5.2.1 需求获取。