简介：基于CMMi（软件能力成熟度模型集成）框架并结合敏捷开发经验编写而成的《软件质量管理体系》V1.0版正式文档，面向软件企业研发管理者、质量工程师与过程改进人员。全文共分总则、项目管理、技术实现过程和支撑过程四篇，涵盖立项管理、结项管理、项目计划、项目监控、风险管理、需求管理、技术预研、SCRUM过程、用户验收、技术评审、配置管理、质量保证、培训管理、服务与维护共14个控制域，基本可满足CMMi 3级管理体系要求。文档既保留CMMi在项目规划、监控与风险治理方面的成熟规范，又通过SCRUM的迭代与黑箱管理思路增强开发环节的灵活性与创造力，形成从立项、开发、评审到维护的闭环管理思路，可为软件企业推进质量管理体系落地、敏捷与CMMi融合改进提供可直接参考的模板与行动准则。资源为1个doc格式文档，大小388KB，已有585人学习，适合需要建立或完善软件质量体系的团队查阅与借鉴。
1. CMMI 软件质量管理体系：为什么它是一套运行规则，而不只是一摞文档
假设你拿到一个命名为「[全套]CMMi软件质量管理体系.doc」的文档包，里面通常是方针、规程、模板和一堆评审检查表。这批文件的典型价值有两个：一是作为组织内部过程标准的蓝本，二是拿去支撑CMMI正式评估。反直觉的现实是，CMMI评估员打分时并不按文档厚度给分，而是按项目现场的证据给分。过程定义再完整，实际项目里需求追踪矩阵没人维护、变更不走基线，评估照样不过。所以这套体系解决的不是「文档怎么写」，而是「软件过程怎么运行」：需求从提出到交付如何被追踪，计划偏差如何被看见，缺陷数据如何回哺开发过程。它适合从作坊式开发走向规范化的研发团队，也适合准备做正式评估、需要对外提供成熟度等级证明的组织。
2. 先把 CMMI 体系拆开：过程域、成熟度等级与文件分层
2.1 分清成熟度 ML 和过程域能力 CL
CMMI 文档资料里最容易被混用的一套概念是 ML 和 CL。ML 是 Maturity Level，衡量组织整体成熟度，从 1 到 5 逐级上升；CL 是 Capability Level，衡量单个过程域的能力等级，从 0 到 3。一个组织整体可能停在 ML2，但配置管理这个过程域已经能做到 CL3。做体系文件时，第一件事就是在文件头声明「本体系依据 CMMI-DEV v1.3 的成熟度等级推进」，并且在年度目标里写清楚组织正在冲击哪一级，不要把过程域能力等级写进成熟度等级描述里。
成熟度等级 2 级关注的是项目层面的受控：需求管理、项目计划、项目监控、供应商协议管理、度量与分析、过程和产品质量保证、配置管理，共七个过程域。成熟度等级 3 级往上再叠加需求开发、技术解决方案、验证、确认、组织过程定义、组织培训、集成项目管理、风险管理、决策分析和解决方案等工程与组织类过程域。成熟度等级 4 级和 5 级则把重心移到量化管理和优化上。
| 成熟度等级 | 关键特征 | 评估时的关注点 |
|---|---|---|
| ML2 受管级 | 每个项目有计划、需求受控、有基线 | 项目是否「说到做到」 |
| ML3 已定义级 | 组织有标准流程，项目按裁剪使用 | 实际流程与组织标准是否一致，差异是否有据 |
| ML4 量化管理级 | 用数据管理过程与质量 | 控制图、过程性能基线的使用是否真实 |
| ML5 优化级 | 基于数据分析做持续改进 | 缺陷根因分析是否形成闭环 |
2.2 从 v1.3 到 v2.0：模型演进对文档结构的影响
CMMI v1.3 把过程域按过程管理、项目管理、工程、支持四类组织，总数十余个，是过去十年国内企业做资质认证的主流版本。CMMI v2.0 把术语换成了实践域和视图，比如开发视图面向软件和系统开发团队，服务视图面向运维团队。换模型不是换名字那么简单：v1.3 强调文档化的过程定义和角色职责，v2.0 更强调价值交付和业务绩效指标的关联。评估时如果还按老办法把每个过程域逐一写成文档，评估员会追问每份文档和绩效之间的关联。
对大多数仍持有 v1.3 资质的团队，除非评估到期需要换版，否则不必马上迁移。但新写的体系文件建议在术语上向 v2.0 靠拢，避免三五年后文档全部重写。常见做法是保留「过程文件加记录证据」的主体架构，把 v1.3 的 PA 分类表保留为附录，正文按「业务能力、支撑活动、监控活动」来组织内容。我一般会做一张映射表，左边是 v2.0 的实践域，右边是 v1.3 的对应过程域，这样评估员查证据时能快速定位，内部同事也不会因为术语变化产生理解偏差。
2.3 体系文件四层结构：方针、规程、模板、记录
无论模型怎么变，落到磁盘上的体系文件都需要一个清晰的分层。推荐按四层组织：质量方针只有一页纸，写清楚质量目标、适用范围、违规处理权限；规程描述跨角色的过程流，比如变更管理规程、配置管理规程；模板统一过程和文档格式；记录保存实际执行产生的评审记录、变更记录、缺陷数据，这是评估时最重要的证据。
创建目录的实用命令：
mkdir -p cmmi-system/{01-policy,02-procedures,03-templates,04-records,05-metrics} cd cmmi-system && find . -maxdepth 1 -type d | sort这里 mkdir 用花括号展开一次建五个目录，把方针、规程、模板、记录和度量库分开；find 只是确认目录结构。目录名统一用英文小写加连字符，跨平台复制和 CI 路径解析都不容易出问题。第 05-metrics 目录放过程性能数据和度量报表，这个目录会直接对接后面量化管理部分的统计脚本。
| 目录 | 对应内容 | 典型文件 |
|---|---|---|
| 01-policy | 质量方针 | 组织质量方针.md |
| 02-procedures | 项目计划、配置管理、评审、缺陷管理等规程 | PP-procedure.md |
| 03-templates | 计划模板、评审检查表、需求追踪矩阵 | traceability-matrix.xlsx |
| 04-records | 评审记录、变更记录、验证记录 | review-record/2025-01.md |
| 05-metrics | 度量分析报告、过程性能基线 | defect-scatter.csv |
这样的结构让评估员按「规程—模板—记录」链条找证据，一条需求从提出到验证，证据链在三分钟之内就能拉通。
3. 把 CMMI 落到项目上：裁剪、评审与度量的最小闭环
3.1 用裁剪表把过程域切到项目规模上
一个 20 人团队和一个 200 人产品线共用一套规程，必然会有人抱怨流程过重。CMMI 体系本身允许裁剪，但裁剪必须有记录：哪个项目裁掉了哪个过程域，基于什么理由，由谁批准。这恰恰是很多组织在评估现场翻车的地方——项目用了简化流程，但没有裁剪记录，评估员只能记一条不符合项。
我一般会在项目启动阶段让项目经理填写一张裁剪表，用 YAML 作为配置项放进项目仓库：
project: 订单中心重构 duration_months: 6 team_size: 12 processes: - pa: PP tailoring: full reason: "" - pa: SAM tailoring: not_applicable reason: 无外部供应商，全部自研 - pa: PI tailoring: simplified reason: 单体应用，用 CI 流水线代替阶段性集成评审 approvals: - role: qm name: 质量经理 status: approved - role: epg name: 过程改进组 status: approved这个文件让裁剪行为可审计：pa 字段对应过程域简写，tailoring 描述执行力度是 full、simplified 还是 not_applicable，reason 必须写理由，approvals 里至少要有质量经理和过程改进组的批准。评估员看到这个文件，就知道组织不是没有标准，而是按规则剪裁了标准。注意，裁剪不是把模板里的章节删掉，而是把某个过程域在项目中的落地方式写清楚，比如把正式产品集成评审裁剪为流水线自动集成加每周集成站会，但执行证据仍然要留。
提示：裁剪记录建议纳入配置管理库，与项目计划一起评审。否则评估现场要解释「为什么这个项目没有过程域 X 的证据」时，会非常被动。
3.2 项目的三条过程纪律：计划、评审、缺陷归零
CMMI 在项目层最常用的三个过程是项目计划、项目监控和验证，对应到日常就是：计划评审、技术评审和缺陷分析。一套能运行的过程不要求很多仪式，只需要三个固定动作：里程碑做计划偏差分析，需求变更时更新追踪矩阵，每个迭代做一次缺陷根因分析。
| 实践 | 最低频率 | 必须留下的证据 |
|---|---|---|
| 项目计划评审 | 每个里程碑 | 计划基线、估算依据、评审记录 |
| 需求追踪矩阵更新 | 每次需求变更 | 双向追踪关系、变更历史 |
| 同行评审 | 每个特性合并前 | 检查表、缺陷记录、评审人签字 |
| 缺陷根因分析 | 每迭代或每月 | 分析记录、改进措施、负责人 |
常见误区是把评审开成了进度同步会。评审会的输入应该是评审对象和检查表，而不是「大家看看还有什么问题」。检查表按需求完整性、设计一致性、可验证性三条线设计，每条线下放五到八个可勾选的项。一个评审记录至少要包含：评审对象版本、参与人及角色、结论（通过、有条件通过、不通过）。有了这三项，事后追溯才有意义，评估员追问某个缺陷为什么漏检时，也有据可查。
3.3 把过程要求固化到 CI 里：让机器先卡一道
过程纪律光靠人记不长久。常见做法是把能自动化的检查放进持续集成：需求追踪矩阵格式校验、缺陷单必填字段、代码规范扫描、构建产物完整性。下面是一个合并请求阶段的质量门禁示例：
name: quality-gate on: pull_request: types: [opened, synchronize] jobs: gate: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: check traceability format run: python scripts/check_matrix.py --required REQM,TS,VER - name: check code style run: make lint - name: verify review checklist run: test -f docs/review-checklist.md这条流水线把 CMMI 对验证过程的实践翻译成了可执行卡点：check_matrix 检查需求追踪矩阵里 REQM、TS、VER 三类条目是否齐全并带状态；make lint 对应工程过程域里对产品质量的要求；checklist 文件存在性检查则强制开发者在合并前完成评审记录准备。流程设计的原则是能自动的不要人工，但也要避免所有质量数据都被自动化掩盖：同行评审中对设计逻辑的讨论机器替代不了，评估员恰恰会追问这一类人工判断的痕迹。
4. 量化管理怎么算：缺陷密度、缺陷消除率与过程性能基线
4.1 用 GQM 选指标，而不是堆指标
ML4 要求组织建立量化管理对象，但很多团队一上来就列三四十个指标，最后没人用。GQM（Goal-Question-Metric）是解决这个问题的经典方法：先从目标拆出问题，再从问题定义度量。目标不要写「提高质量」这种大词，要写「降低线上缺陷」这种可验证的描述。
| 目标 | 问题 | 指标 | 数据来源 |
|---|---|---|---|
| 降低线上缺陷 | 线上缺陷占全部缺陷的比例是否在下降 | 缺陷逃逸率、线上缺陷密度 | 缺陷库、发布单 |
| 缩短需求交付周期 | 需求从评审到上线的时间消耗在哪 | 各阶段平均前置时间 | 项目管理工具、变更记录 |
| 提升评审有效性 | 评审发现的缺陷是否值得投入 | 评审缺陷率、评审速度 | 评审记录、缺陷库 |
先选两到三个目标，每个目标下保留两个指标。指标定义要写清楚分子分母、统计口径、数据来源、采集频率。如果两个系统里对「缺陷」的统计口径不一致，后面算出来的基线没有任何意义。这一步对应 CMMI 的度量与分析过程域，项目启动时要把指标口径写进项目计划，而不是等到评估前补数据。
4.2 缺陷密度和缺陷消除率的计算
缺陷密度和缺陷消除率（Defect Removal Efficiency，DRE）是软件质量管理体系里两个最常用的量化指标。用一段 Python 把口径固定下来：
def defect_density(defects, kloc): if kloc <= 0: raise ValueError("kloc must be positive") return defects / kloc def dre(defects_removed_before_release, defects_after_release): denominator = defects_removed_before_release + defects_after_release if denominator == 0: return 0.0 return defects_removed_before_release / denominator * 100defect_density 的 defects 是某个交付物在评审、测试阶段发现并关闭的缺陷数，kloc 是千行代码数，结果反映每千行代码的缺陷含量。DRE 的分子是发布前清除的缺陷，分母是发布前加发布后缺陷总和，反映质量门禁的过滤效率。边界处理很关键：分母为零时不能除零报错，直接返回 0.0，表示当前没有缺陷数据，不应参与后续基线计算。实际使用时，脚本要接缺陷库，比如从缺陷管理工具导出 CSV 后按「发现阶段」和「处理结果」两个字段分桶。
4.3 过程性能基线与异常判断
ML4 的核心不是算出平均值，而是判断过程有没有异常。用纯 Python 实现一个简单的过程性能基线计算：
def compute_ppb(values): n = len(values) if n < 3: raise ValueError("need at least 3 data points") mean = sum(values) / n variance = sum((v - mean) ** 2 for v in values) / (n - 1) sigma = variance ** 0.5 return { "mean": mean, "sigma": sigma, "ucl": mean + 3 * sigma, "lcl": max(0, mean - 3 * sigma), }过程性能基线用均值加三个标准差作为上下控制限。缺陷率、修复时长如果落到控制限外，就应该触发原因分析，而不是简单地认为「这次质量变好了」或「这次质量变差了」。注意这里用的是样本标准差，除数是 n-1，否则小样本下控制限会偏窄。控制线之外的点属于特殊原因，先查是不是数据口径变了，比如某个需求临时改了缺陷分类，再查过程是否真的偏移。基线每隔三个迭代或一个季度更新一次，更新要保留历史版本，评估时才能呈现「基线逐步稳定下来」的过程改进证据。
5. 评估、不一致问题和长期运行：CMMI 的进阶用法
5.1 SCAMPI 评估现场常被忽略的事项
认为「做了文件体系就能过评估」的团队，差距往往出在证据抽样上。SCAMPI（Standard CMMI Appraisal Method for Process Improvement）评估会跨组织、跨项目、跨工作产品抽取证据，而不是只抽一个样板项目。准备评估时至少选两到三个不同规模、不同开发流程的现场项目参与，把项目的真实运行数据与体系文件对应起来。评估员的思路是顺着一条需求看完整链路：需求入库、追踪矩阵、设计评审、编码检查、测试验证、发布记录。任何一环缺证据，都会变成发现项。
5.2 在敏捷流程中落地 CMMI 实践
CMMI 与敏捷不是对立关系。常见的映射做法是：用户故事对应需求开发与需求管理，Sprint 计划对应项目计划，Sprint 评审对应里程碑评审，每日站会对应项目监控，冲刺回顾对应组织过程改进。不要单独为 CMMI 另建一套文档，直接把实践挂进敏捷工件里。一个可落地的技巧是把 CMMI 实践翻译成团队完成定义的检查项，比如「合并前通过质量门禁」「评审记录与需求条目双向可追溯」「缺陷根因分析在上线后两个工作日内完成」。
5.3 一个具体的持续改进技巧：改进登记表
持续改进最常见的失败方式是「会上说了，散会忘了」。我建议建一张改进登记表，作为过程改进的单项跟踪清单：
| 字段 | 示例 |
|---|---|
| 编号 | IMP-2025-003 |
| 来源 | 月度缺陷分析会 |
| 问题 | 评审记录中缺少评审人角色 |
| 根因 | 模板字段未做必选约束 |
| 措施 | 在评审模板中增加角色下拉校验 |
| 负责人 | 质量工程师 |
| 目标版本 | 2025-Q2 |
| 状态 | 进行中 |
使用方式很简单：每次评审会、缺陷分析会和评估结果回访都录入这张表，措施里必须写明交付物和验收方式，状态由负责人在措施完成后更新。配合前面 CI 卡点的思路，模板校验可以写进流水线，改进措施落地后自动关闭。这张表本身就是组织过程资产的一部分，评估时可以直接作为持续改进的证据。
本文还有配套的精品资源，点击获取
