简介这是XX计算机软件有限公司完整的CMMI软件质量管理体系文档版本VI.0发布于2010年12月。内容共分总则、项目管理、需求管理、设计、实施、验证和配置管理七篇系统梳理了软件研发全过程的质量管控流程适合软件质量管理人员、过程改进专员及研发团队参考借鉴。文档以单个docx文件打包体积约470KB方便直接查阅与打印。已有241人学习浏览适合对照公司实际项目裁剪落地或作为CMMI认证准备的过程资产样板。文档详细给出了立项评审、需求获取、架构设计、编码测试、配置项识别等环节的目标、角色职责、输入输出与结束准则具有较强的操作性和模板价值可直接用于建立或完善组织的软件质量管理体系。1. CMMi 体系不全是一套模板而是一台文档引擎做过几轮 CMMI 评估的团队都有这种体会真正让人疲惫的经常是“文档体系”而不是开发行为。CMMI 并不是一个产品而是一组过程文件、记录模板和评审证据评估组第一天进场就会要求提供质量方针、过程定义、项目计划、测量分析、配置管理、QA 检查记录等一套完整材料。很多团队拿到的所谓“全套 CMMi 软件质量管理体系”往往是一堆 Word 文件命名混乱、版本重复、正文格式不统一看似样样都有但一查过程域和证据就断链。我把这种文件称为“文档引擎”而不是文档集体系里每个过程都是输入到输出的流动权重在“引用链”。CMMI 的文件载体选择 Word 的 .docx 作为主体是合理的因为最终评估时要在现场批注、签字、修订纯表格工具或 Markdown 不适用。但如果不在 Word 中把样式、编号、目录、引用和变更记录做对你会发现一个问题几十个 docx 文件每个都是孤岛。这篇博文讲的是如何把一套以 .docx 为主载体的 CMMi 软件质量管理体系搭得可检索、可评审、可追溯。适合软件质量经理、项目过程改进人员和刚接手体系文档的 QA不需要事先接触过 CMMI但在读到最后时你会获得两样东西一套可复制的文档层级设计和一个接住评估质询的文档矩阵。2. 用 CMMI 过程域反推全套文档清单并固定 docx 粒度2.1 先从 CMMI 过程域倒推“要证明什么”CMMI-DEV 到成熟度三级有 18 个过程域对于大多数软件企业真正要写进体系文件的不是 18 个过程域的全套理论而是每个过程域对应的“执行凭证”。凭证是审计员最在意的计划有没有批准、需求有没有跟踪、评审有没有记录、不符合项有没有闭环。因此所有文档设计都要从“评估检查时会拿什么文件来质询我”入手。常见做法是先把目标定在二级加部分三级项目计划、项目监控、需求管理、配置管理、质量和过程保证、测量分析。这六个过程域足以覆盖一个小型项目组的全部质量管理活动也对应一套详略得当的 Word 文档。过程域与文档的对应关系可以整理成下面这张表它在后期就是整个体系的索引。CMMI 过程域对应过程文件应证明的证据记录PP 项目计划项目计划编制规程已批准的项目计划、估算记录PMC 项目监控里程碑评审规程周报、里程碑评审记录、偏差分析REQM 需求管理需求管理规程需求跟踪矩阵、需求变更申请单CM 配置管理配置管理规程配置项清单、基线发布记录、变更记录PPQA 过程和产品质量保证质量保证规程QA 检查单、不符合项报告、闭环记录MA 测量分析测量分析规程度量数据表、度量分析报告很多团队一开始就写“质量手册”这是把顺序搞反了。手册是展示给别人看的而上面这张表是给自己用的。没有这张表后面所有的 Word 文档都只是静态文件一旦过程域负责人更换体系立即失真。2.2 文档粒度怎么定一个文件只回答一个问题全套文档在形式上最容易失控的地方是“一个目录下堆几十个 docx”。我一般把文档分成三层分别对应不同修订频率和责任人这也是在 Word 工程里控制复杂度的前提。第一层是方针类包括质量方针、配置管理方针、项目过程裁剪方针这类文档不超过三页只有高层签字才修改。第二层是规程类每个过程域一份比如“配置管理规程”“需求管理规程”这一层是重点因为修订最多需要独立版本号。第三层是记录与表单包括需求跟踪矩阵、评审记录、QA 检查单、不符合项报告这类文档建议直接做成可填写的 .docx 模板或 .xlsx不放进规程正文里。按这种划分全套 CMMi 的 docx 数量控制在 30 个左右比较健康。如果超过 45 个维护成本会淹没过程改进收益少于 15 个则说明很多记录没有独立载体评估时无法快速取数。每条规程只回答“谁、何时、做什么、产生什么记录”一个问题不要在同一份文档里把多个过程域混写否则你的 Word 目录层级和版本历史会变成一团乱麻。2.3 目录结构即体系结构文件命名是很多人忽略的细节。Windows 资源管理器按名排序后加上前缀数字能保证顺序符合评估者的阅读习惯。我一般会这样组织一套 CMMi 文档库CMMI_L2/ ├─ 00_索引总表/ │ └─ CMMI文档矩阵.docx ├─ 01_方针/ │ ├─ 01_质量方针.docx │ └─ 02_配置管理方针.docx ├─ 02_过程/ │ ├─ 01_项目计划编制规程.docx │ ├─ 02_项目监控规程.docx │ ├─ 03_需求管理规程.docx │ ├─ 04_度量分析规程.docx │ ├─ 05_质量保证规程.docx │ └─ 06_配置管理规程.docx └─ 03_记录/ ├─ 需求跟踪矩阵.xlsx ├─ QA审核检查单.docx └─ 里程碑评审记录.docx这套目录结构解决了“全套 CMMi 软件质量管理体系”最容易犯的第一个错误文档物理位置和逻辑关系不对应。每一层文件夹代表一种文档角色文件夹名字用数字前缀固定阅读顺序任何新加入的人都能在十分钟内定位到要找的文件。后续开发这套体系的台账、版本号、评审记录时也都是以这个目录树为唯一事实来源。3. 在 Word 里给全套 CMMi 文档装上可追溯的“版本制动闸”3.1 文档头、变更记录和分发范围三件套CMMI 体系文件在评估现场最怕的不是写得不够专业而是版本对不上。因此每份 docx 的第一页顶部都要有一个表格依次放文件编号、版本号、编制人、审核人、批准人、生效日期、适用范围。文件编号要全局唯一比如QP-PP-001这样即使在多个项目之间复制也不会撞车。紧接着是变更记录表列名固定为版本、日期、变更内容、修订人。不要用 Word 批注功能来记变更历史批注容易被误删也不要只写在“文档属性”里因为.docx的元数据在评审时未必被接受。用可见表格写进正文是最稳妥的受控方式。每份规程还要有“分发范围”一节说明这份文件要发给谁、是否有受控副本、是否有电子版登记。这不是形式主义而是 CMMI 配置管理过程的直接证据。当评估员问“你怎么保证各项目用的是最新版规程”时你指给他看分发范围表和变更历史表即可不必口头解释。3.2 多级编号和目录字段别靠手打手工打“1.1.1”在几十个文档里几乎是灾难因为增删章节后不会自动重整。Word 自带的“多级列表”功能要和标题样式绑定目录字段则由页面生成。实际配置方法是修改标题 1、标题 2、标题 3 的样式然后在“定义新的多级列表”中把级别链接到对应样式并设置编号格式为“第1章”“1.1”“1.1.1”。如果你需要批量修改多个文档可以写一个 VBA 宏来完成样式校正。这里给一个可以在 Word 中直接运行的最小脚本它能把当前文档的标题字体统一并强制更新目录域。注意保存前必须退出所有 Word 实例否则文档会被锁定。Sub FixCMMIHeadings() Dim doc As Document Set doc ActiveDocument With doc.Styles(wdStyleHeading1) .Font.Name 微软雅黑 .Font.Size 16 .Font.Bold True End With With doc.Styles(wdStyleHeading2) .Font.Name 微软雅黑 .Font.Size 13 .Font.Bold True End With With doc.Styles(wdStyleHeading3) .Font.Name 微软雅黑 .Font.Size 11 End With doc.Fields.Update doc.Repaginate End Sub这段代码做的事情很简单把三个标题级样式指到统一的字体和字号然后更新目录字段并重新分页。它对已存在的文字不一定生效因为手动格式会覆盖样式所以使用前必须要求写作人员只使用“标题 1”“标题 2”等内置样式禁止直接修改字体。在 CMMI 文档体系中样式模板统一比内容措辞统一更早也更值得投入。3.3 表格列宽、自动调整和“关闭卡顿”的常见原因在评审记录和检查单中表格是最重要的信息载体。如果你遇到过“word 表格列宽无法拖动”多半是因为表格启用了“自动调整”或者列宽设置了固定值后又被嵌套表格干扰。解决办法是选中表格在“表格工具-布局”中把单元格宽度改为指定值并关闭“自动调整至窗口大小”。当文档达到 50 页以上Word 关闭时卡顿往往是目录域、交叉引用域和全文拼写检查在后台反复刷新。处理方式不是换电脑而是把工作分两步一般情况下关闭“更新域时重新分页”只在最终导出 PDF 前手动按 CtrlA 后按 F9 更新所有域。这样你的日常编辑过程不会频繁触发整个文档重排。需要强调的另一点是.docx的体积。很多人喜欢把截图直接粘贴进 Word导致单个文档超过 30MB。CMMI 文档应该保存截图时先压缩图片或者统一用“文件-选项-高级-压缩图片”控制像素。体积过大的 docx 在预览时占有大量内存也是“无法预览 doc”“打开时进度条卡住”的常见根因。4. 用 Python-docx 批量生成全套 CMMi 文档骨架4.1 为什么要用脚本生成骨架而不是手工复制当你需要维护 30 个结构相似的 CMMI 文档时手工复制粘贴的最大问题是样式漂移同一个标题级别第 3 个文档可能是五号宋体第 27 个文档变成了四号微软雅黑。我一般会先用脚本把这些文档的骨架和样式一次性生成再让各过程域负责人只填充正文内容。Python 的python-docx库是处理.docx文件最稳定的开源方案。它不需要安装 Word可以在 CI 环境里运行能够控制段落、表格和样式。下面的脚本会生成一份带标准标题层级和目录域的空模板之后循环调用这个函数就能批量生成整套文档。4.2 一个能直接运行的最小模板脚本from docx import Document from docx.shared import Pt from docx.enum.text import WD_ALIGN_PARAGRAPH from docx.oxml.ns import qn from docx.oxml import OxmlElement def set_font(doc, font_name): style doc.styles[Normal] style.font.name Arial rpr style.element.get_or_add_rPr() rfonts rpr.get_or_add_rFonts() rfonts.set(qn(w:eastAsia), font_name) def add_toc(doc): para doc.add_paragraph() run para.add_run() fld_begin OxmlElement(w:fldChar) fld_begin.set(qn(w:fldCharType), begin) instr OxmlElement(w:instrText) instr.set(qn(xml:space), preserve) instr.text TOC \\o 1-3 \\h \\z \\u fld_sep OxmlElement(w:fldChar) fld_sep.set(qn(w:fldCharType), separate) fld_end OxmlElement(w:fldChar) fld_end.set(qn(w:fldCharType), end) run._r.append(fld_begin) run._r.append(instr) run._r.append(fld_sep) run._r.append(fld_end) def build_cmmi_doc(file_name, title): doc Document() set_font(doc, 宋体) h doc.add_heading(title, level0) h.alignment WD_ALIGN_PARAGRAPH.CENTER add_toc(doc) doc.add_heading(1. 目的, level1) doc.add_paragraph(描述本规程的适用范围和期望达到的管理效果。) doc.add_heading(2. 术语与缩写, level1) doc.add_paragraph() # 正文由编写人补充 doc.add_heading(3. 角色与职责, level1) table doc.add_table(rows2, cols3) table.style Table Grid hdr table.rows[0].cells hdr[0].text 角色 hdr[1].text 职责 hdr[2].text 相关记录 data_row table.rows[1].cells data_row[0].text 项目负责人 data_row[1].text 审批计划提供资源 data_row[2].text 项目计划 doc.add_heading(4. 流程说明, level1) doc.add_heading(5. 记录与表单, level1) doc.save(file_name) if __name__ __main__: template_docs [ 项目计划编制规程.docx, 项目监控规程.docx, 需求管理规程.docx, 度量分析规程.docx, 质量保证规程.docx, 配置管理规程.docx, ] for name in template_docs: title name.replace(.docx, ) build_cmmi_doc(name, title) print(fgenerate {name} over)脚本逻辑并不复杂先定义正文字体和标题样式再插入一级目录域随后生成章节标题和一个简单的角色表格。add_toc里的w:fldChar和w:instrText是 Word 域代码的 XML 表示作用是告诉 Word 此处是动态目录而不是静态文字。生成完成后用 Word 打开任意文档右键目录区域选择“更新域”目录就会根据标题自动填充。4.3 参数调整把模板扩展成信息收集表实际使用时可以把脚本中的章节标题改成从外部配置读取这样同一套代码就能为不同项目生成不同体系。常见做法是维护一个doc_config.json里面写每个文档的标题、章节、涉及的表格列名运行脚本时迭代生成。这里的核心不是代码本身而是让“生成文档骨架”成为体系变更流程中的标准动作。你不再需要让每个员工手工调整 Word 模板而是由脚本统一发布。变更时只要改配置并重新生成旧文档改由版本控制工具管起来就能避免“内容对但格式不一致”的 CMMI 审核风险。5. 多人协作时不炸掉的 CMMi 文档交付宏、模板引擎和文件命名5.1 不要在体系库里放必须启用宏才能用的 docxWord 宏在 CMMI 文档体系里是高风险项。企业内安全策略会禁止启用宏尤其是从外部带入的.docm这会导致你的模板在评审电脑上打开时一片灰色。很多团队还喜欢把自动弹出修订提示的宏挂到每个文档上一旦安全策略阻止整个文档体验就会崩掉。我个人的原则是正文和表单中绝不依赖宏所有自动操作只放在构建阶段。比如上一节的 Python 脚本负责生成骨架和更新域交付到使用方的是普通.docx打开后不需要任何额外确认。如果需要统一更新 30 个文档的页眉也应当用脚本批量改而不是让每个用户打开宏。5.2 用 poi-tl 在服务端生成评审记录和检查单Java 团队通常需要从缺陷库或 CI 系统自动生成评审记录。这时可以使用poi-tl它是一个基于 Apache POI 的 Word 模板渲染引擎特点是模板用原生 Word 编写数据填充用{{}}占位符。和 Python-docx 不同poi-tl 更擅长处理已有模板的动态渲染适合把系统数据导入记录类文档。import com.deepoove.poi.XWPFTemplate; import java.util.*; public class CMMIReport { public static void main(String[] args) { MapString, Object data new HashMap(); data.put(projectName, 订单服务重构); data.put(reviewDate, 2025-03-18); data.put(reviewer, 张三); ListMapString, Object issues new ArrayList(); for (int i 1; i 3; i) { MapString, Object row new HashMap(); row.put(no, String.valueOf(i)); row.put(detail, 评审建议项 i); row.put(owner, 李四); row.put(deadline, 2025-03-25); issues.add(row); } data.put(issueList, issues); XWPFTemplate template XWPFTemplate.compile(qa_check_report.docx); template.render(data).writeToFile(qa_check_report_20250318.docx); template.close(); } }这段代码把项目名、评审日期和问题列表渲染到qa_check_report.docx模板中。注意issueList会对应模板里的一个表格poi-tl 会自动遍历列表生成多行。如果你在word 表格列宽无法拖动上踩过坑就会知道模板表格里的列宽设置必须在编译模板时就锁定为“固定列值”不要使用“自动匹配窗口”否则渲染后的行会出现列错位。服务端渲染方案和人工填写方案的差别在于人工填写的记录格式不稳定由系统生成的记录则能直接形成 CMMI 度量数据。但建议不要用服务端模板去写长文档因为 Word 排版上下文复杂渲染大量段落时性能不佳使用者最终还是要人工调整。所以我会把 poi-tl 限定在检查单、评审记录、不符合项报告这类结构高度固定的记录层。5.3 用“文件夹即版本”处理项目级 CMMI 记录多项目并行时每套 CMMI 文档都要跟着项目走。不要把所有项目的记录放在同一个文件夹里也不要让一个 Word 文档跨多个项目审批。标准做法是每个项目建独立目录把公司级规程放在公共库中项目只保留记录、计划和裁剪说明。如果你发现 Word 保存显示磁盘已满或写入失败先检查是不是这些 docx 文件正在被其他进程打开。Windows 上常见的错误是某个进程后台锁定了文件导致pqitl或 Python 脚本无法覆写。解决方法是把输出文档和正在使用的文档分开保存并关闭所有 Word 实例后再跑批处理。6. 一页索引 docx 完成 CMMI 覆盖度自查和评估取数最后的技巧是做一个只有一页的“CMMI 文档矩阵.docx”放在00_索引总表目录里。这个文档不写过程内容只放三列过程域、对应文档、关键证据。每次评审前把它打印出来逐行勾选比翻 30 个 Word 文档快得多。矩阵表的实际写法如下CMMI 过程域受控文档证据文件PP项目计划编制规程.docx订单服务项目计划_v1.2.docxPMC项目监控规程.docx3月里程碑评审记录.docxREQM需求管理规程.docx需求跟踪矩阵.xlsxCM配置管理规程.docx配置项登记表.docxPPQA质量保证规程.docxQA检查单_202503.docxMA测量分析规程.docx缺陷趋势分析.xlsx要做成可点击链接可以选中“对应文档”列的单元格右键选择“超链接”链接类型选“现有文件或网页”并指向..\02_过程\项目计划编制规程.docx。注意不要用绝对路径因为评审现场会把整个文件夹拷贝到另一台电脑绝对路径会全部断链。相对路径的前提是所有文档都在同一个父目录下这正是本文第 2 节目录设计的意义。验证矩阵是否有效的方法很简单按住 Ctrl 依次点击每个链接检查是否都能打开对应文件。如果某个链接断掉就说明文档目录被移动或改名了需要重新修复。每季度做一次这种确认能显著降低 CMMI 评估当天临时查找材料的风险。对一个多年经验的 QA 来说这套体系的本质不是内容完美而是让任何拿到文档的人都能在最短时间内找到“过程定义”和“执行证据”的对应关系。把索引矩阵留在手边就相当于给全套 CMMi 软件质量管理体系画了一张导航图。本文还有配套的精品资源点击获取
CMMI文档体系构建：用Word与脚本打造可追溯的质量管理
简介这是XX计算机软件有限公司完整的CMMI软件质量管理体系文档版本VI.0发布于2010年12月。内容共分总则、项目管理、需求管理、设计、实施、验证和配置管理七篇系统梳理了软件研发全过程的质量管控流程适合软件质量管理人员、过程改进专员及研发团队参考借鉴。文档以单个docx文件打包体积约470KB方便直接查阅与打印。已有241人学习浏览适合对照公司实际项目裁剪落地或作为CMMI认证准备的过程资产样板。文档详细给出了立项评审、需求获取、架构设计、编码测试、配置项识别等环节的目标、角色职责、输入输出与结束准则具有较强的操作性和模板价值可直接用于建立或完善组织的软件质量管理体系。1. CMMi 体系不全是一套模板而是一台文档引擎做过几轮 CMMI 评估的团队都有这种体会真正让人疲惫的经常是“文档体系”而不是开发行为。CMMI 并不是一个产品而是一组过程文件、记录模板和评审证据评估组第一天进场就会要求提供质量方针、过程定义、项目计划、测量分析、配置管理、QA 检查记录等一套完整材料。很多团队拿到的所谓“全套 CMMi 软件质量管理体系”往往是一堆 Word 文件命名混乱、版本重复、正文格式不统一看似样样都有但一查过程域和证据就断链。我把这种文件称为“文档引擎”而不是文档集体系里每个过程都是输入到输出的流动权重在“引用链”。CMMI 的文件载体选择 Word 的 .docx 作为主体是合理的因为最终评估时要在现场批注、签字、修订纯表格工具或 Markdown 不适用。但如果不在 Word 中把样式、编号、目录、引用和变更记录做对你会发现一个问题几十个 docx 文件每个都是孤岛。这篇博文讲的是如何把一套以 .docx 为主载体的 CMMi 软件质量管理体系搭得可检索、可评审、可追溯。适合软件质量经理、项目过程改进人员和刚接手体系文档的 QA不需要事先接触过 CMMI但在读到最后时你会获得两样东西一套可复制的文档层级设计和一个接住评估质询的文档矩阵。2. 用 CMMI 过程域反推全套文档清单并固定 docx 粒度2.1 先从 CMMI 过程域倒推“要证明什么”CMMI-DEV 到成熟度三级有 18 个过程域对于大多数软件企业真正要写进体系文件的不是 18 个过程域的全套理论而是每个过程域对应的“执行凭证”。凭证是审计员最在意的计划有没有批准、需求有没有跟踪、评审有没有记录、不符合项有没有闭环。因此所有文档设计都要从“评估检查时会拿什么文件来质询我”入手。常见做法是先把目标定在二级加部分三级项目计划、项目监控、需求管理、配置管理、质量和过程保证、测量分析。这六个过程域足以覆盖一个小型项目组的全部质量管理活动也对应一套详略得当的 Word 文档。过程域与文档的对应关系可以整理成下面这张表它在后期就是整个体系的索引。CMMI 过程域对应过程文件应证明的证据记录PP 项目计划项目计划编制规程已批准的项目计划、估算记录PMC 项目监控里程碑评审规程周报、里程碑评审记录、偏差分析REQM 需求管理需求管理规程需求跟踪矩阵、需求变更申请单CM 配置管理配置管理规程配置项清单、基线发布记录、变更记录PPQA 过程和产品质量保证质量保证规程QA 检查单、不符合项报告、闭环记录MA 测量分析测量分析规程度量数据表、度量分析报告很多团队一开始就写“质量手册”这是把顺序搞反了。手册是展示给别人看的而上面这张表是给自己用的。没有这张表后面所有的 Word 文档都只是静态文件一旦过程域负责人更换体系立即失真。2.2 文档粒度怎么定一个文件只回答一个问题全套文档在形式上最容易失控的地方是“一个目录下堆几十个 docx”。我一般把文档分成三层分别对应不同修订频率和责任人这也是在 Word 工程里控制复杂度的前提。第一层是方针类包括质量方针、配置管理方针、项目过程裁剪方针这类文档不超过三页只有高层签字才修改。第二层是规程类每个过程域一份比如“配置管理规程”“需求管理规程”这一层是重点因为修订最多需要独立版本号。第三层是记录与表单包括需求跟踪矩阵、评审记录、QA 检查单、不符合项报告这类文档建议直接做成可填写的 .docx 模板或 .xlsx不放进规程正文里。按这种划分全套 CMMi 的 docx 数量控制在 30 个左右比较健康。如果超过 45 个维护成本会淹没过程改进收益少于 15 个则说明很多记录没有独立载体评估时无法快速取数。每条规程只回答“谁、何时、做什么、产生什么记录”一个问题不要在同一份文档里把多个过程域混写否则你的 Word 目录层级和版本历史会变成一团乱麻。2.3 目录结构即体系结构文件命名是很多人忽略的细节。Windows 资源管理器按名排序后加上前缀数字能保证顺序符合评估者的阅读习惯。我一般会这样组织一套 CMMi 文档库CMMI_L2/ ├─ 00_索引总表/ │ └─ CMMI文档矩阵.docx ├─ 01_方针/ │ ├─ 01_质量方针.docx │ └─ 02_配置管理方针.docx ├─ 02_过程/ │ ├─ 01_项目计划编制规程.docx │ ├─ 02_项目监控规程.docx │ ├─ 03_需求管理规程.docx │ ├─ 04_度量分析规程.docx │ ├─ 05_质量保证规程.docx │ └─ 06_配置管理规程.docx └─ 03_记录/ ├─ 需求跟踪矩阵.xlsx ├─ QA审核检查单.docx └─ 里程碑评审记录.docx这套目录结构解决了“全套 CMMi 软件质量管理体系”最容易犯的第一个错误文档物理位置和逻辑关系不对应。每一层文件夹代表一种文档角色文件夹名字用数字前缀固定阅读顺序任何新加入的人都能在十分钟内定位到要找的文件。后续开发这套体系的台账、版本号、评审记录时也都是以这个目录树为唯一事实来源。3. 在 Word 里给全套 CMMi 文档装上可追溯的“版本制动闸”3.1 文档头、变更记录和分发范围三件套CMMI 体系文件在评估现场最怕的不是写得不够专业而是版本对不上。因此每份 docx 的第一页顶部都要有一个表格依次放文件编号、版本号、编制人、审核人、批准人、生效日期、适用范围。文件编号要全局唯一比如QP-PP-001这样即使在多个项目之间复制也不会撞车。紧接着是变更记录表列名固定为版本、日期、变更内容、修订人。不要用 Word 批注功能来记变更历史批注容易被误删也不要只写在“文档属性”里因为.docx的元数据在评审时未必被接受。用可见表格写进正文是最稳妥的受控方式。每份规程还要有“分发范围”一节说明这份文件要发给谁、是否有受控副本、是否有电子版登记。这不是形式主义而是 CMMI 配置管理过程的直接证据。当评估员问“你怎么保证各项目用的是最新版规程”时你指给他看分发范围表和变更历史表即可不必口头解释。3.2 多级编号和目录字段别靠手打手工打“1.1.1”在几十个文档里几乎是灾难因为增删章节后不会自动重整。Word 自带的“多级列表”功能要和标题样式绑定目录字段则由页面生成。实际配置方法是修改标题 1、标题 2、标题 3 的样式然后在“定义新的多级列表”中把级别链接到对应样式并设置编号格式为“第1章”“1.1”“1.1.1”。如果你需要批量修改多个文档可以写一个 VBA 宏来完成样式校正。这里给一个可以在 Word 中直接运行的最小脚本它能把当前文档的标题字体统一并强制更新目录域。注意保存前必须退出所有 Word 实例否则文档会被锁定。Sub FixCMMIHeadings() Dim doc As Document Set doc ActiveDocument With doc.Styles(wdStyleHeading1) .Font.Name 微软雅黑 .Font.Size 16 .Font.Bold True End With With doc.Styles(wdStyleHeading2) .Font.Name 微软雅黑 .Font.Size 13 .Font.Bold True End With With doc.Styles(wdStyleHeading3) .Font.Name 微软雅黑 .Font.Size 11 End With doc.Fields.Update doc.Repaginate End Sub这段代码做的事情很简单把三个标题级样式指到统一的字体和字号然后更新目录字段并重新分页。它对已存在的文字不一定生效因为手动格式会覆盖样式所以使用前必须要求写作人员只使用“标题 1”“标题 2”等内置样式禁止直接修改字体。在 CMMI 文档体系中样式模板统一比内容措辞统一更早也更值得投入。3.3 表格列宽、自动调整和“关闭卡顿”的常见原因在评审记录和检查单中表格是最重要的信息载体。如果你遇到过“word 表格列宽无法拖动”多半是因为表格启用了“自动调整”或者列宽设置了固定值后又被嵌套表格干扰。解决办法是选中表格在“表格工具-布局”中把单元格宽度改为指定值并关闭“自动调整至窗口大小”。当文档达到 50 页以上Word 关闭时卡顿往往是目录域、交叉引用域和全文拼写检查在后台反复刷新。处理方式不是换电脑而是把工作分两步一般情况下关闭“更新域时重新分页”只在最终导出 PDF 前手动按 CtrlA 后按 F9 更新所有域。这样你的日常编辑过程不会频繁触发整个文档重排。需要强调的另一点是.docx的体积。很多人喜欢把截图直接粘贴进 Word导致单个文档超过 30MB。CMMI 文档应该保存截图时先压缩图片或者统一用“文件-选项-高级-压缩图片”控制像素。体积过大的 docx 在预览时占有大量内存也是“无法预览 doc”“打开时进度条卡住”的常见根因。4. 用 Python-docx 批量生成全套 CMMi 文档骨架4.1 为什么要用脚本生成骨架而不是手工复制当你需要维护 30 个结构相似的 CMMI 文档时手工复制粘贴的最大问题是样式漂移同一个标题级别第 3 个文档可能是五号宋体第 27 个文档变成了四号微软雅黑。我一般会先用脚本把这些文档的骨架和样式一次性生成再让各过程域负责人只填充正文内容。Python 的python-docx库是处理.docx文件最稳定的开源方案。它不需要安装 Word可以在 CI 环境里运行能够控制段落、表格和样式。下面的脚本会生成一份带标准标题层级和目录域的空模板之后循环调用这个函数就能批量生成整套文档。4.2 一个能直接运行的最小模板脚本from docx import Document from docx.shared import Pt from docx.enum.text import WD_ALIGN_PARAGRAPH from docx.oxml.ns import qn from docx.oxml import OxmlElement def set_font(doc, font_name): style doc.styles[Normal] style.font.name Arial rpr style.element.get_or_add_rPr() rfonts rpr.get_or_add_rFonts() rfonts.set(qn(w:eastAsia), font_name) def add_toc(doc): para doc.add_paragraph() run para.add_run() fld_begin OxmlElement(w:fldChar) fld_begin.set(qn(w:fldCharType), begin) instr OxmlElement(w:instrText) instr.set(qn(xml:space), preserve) instr.text TOC \\o 1-3 \\h \\z \\u fld_sep OxmlElement(w:fldChar) fld_sep.set(qn(w:fldCharType), separate) fld_end OxmlElement(w:fldChar) fld_end.set(qn(w:fldCharType), end) run._r.append(fld_begin) run._r.append(instr) run._r.append(fld_sep) run._r.append(fld_end) def build_cmmi_doc(file_name, title): doc Document() set_font(doc, 宋体) h doc.add_heading(title, level0) h.alignment WD_ALIGN_PARAGRAPH.CENTER add_toc(doc) doc.add_heading(1. 目的, level1) doc.add_paragraph(描述本规程的适用范围和期望达到的管理效果。) doc.add_heading(2. 术语与缩写, level1) doc.add_paragraph() # 正文由编写人补充 doc.add_heading(3. 角色与职责, level1) table doc.add_table(rows2, cols3) table.style Table Grid hdr table.rows[0].cells hdr[0].text 角色 hdr[1].text 职责 hdr[2].text 相关记录 data_row table.rows[1].cells data_row[0].text 项目负责人 data_row[1].text 审批计划提供资源 data_row[2].text 项目计划 doc.add_heading(4. 流程说明, level1) doc.add_heading(5. 记录与表单, level1) doc.save(file_name) if __name__ __main__: template_docs [ 项目计划编制规程.docx, 项目监控规程.docx, 需求管理规程.docx, 度量分析规程.docx, 质量保证规程.docx, 配置管理规程.docx, ] for name in template_docs: title name.replace(.docx, ) build_cmmi_doc(name, title) print(fgenerate {name} over)脚本逻辑并不复杂先定义正文字体和标题样式再插入一级目录域随后生成章节标题和一个简单的角色表格。add_toc里的w:fldChar和w:instrText是 Word 域代码的 XML 表示作用是告诉 Word 此处是动态目录而不是静态文字。生成完成后用 Word 打开任意文档右键目录区域选择“更新域”目录就会根据标题自动填充。4.3 参数调整把模板扩展成信息收集表实际使用时可以把脚本中的章节标题改成从外部配置读取这样同一套代码就能为不同项目生成不同体系。常见做法是维护一个doc_config.json里面写每个文档的标题、章节、涉及的表格列名运行脚本时迭代生成。这里的核心不是代码本身而是让“生成文档骨架”成为体系变更流程中的标准动作。你不再需要让每个员工手工调整 Word 模板而是由脚本统一发布。变更时只要改配置并重新生成旧文档改由版本控制工具管起来就能避免“内容对但格式不一致”的 CMMI 审核风险。5. 多人协作时不炸掉的 CMMi 文档交付宏、模板引擎和文件命名5.1 不要在体系库里放必须启用宏才能用的 docxWord 宏在 CMMI 文档体系里是高风险项。企业内安全策略会禁止启用宏尤其是从外部带入的.docm这会导致你的模板在评审电脑上打开时一片灰色。很多团队还喜欢把自动弹出修订提示的宏挂到每个文档上一旦安全策略阻止整个文档体验就会崩掉。我个人的原则是正文和表单中绝不依赖宏所有自动操作只放在构建阶段。比如上一节的 Python 脚本负责生成骨架和更新域交付到使用方的是普通.docx打开后不需要任何额外确认。如果需要统一更新 30 个文档的页眉也应当用脚本批量改而不是让每个用户打开宏。5.2 用 poi-tl 在服务端生成评审记录和检查单Java 团队通常需要从缺陷库或 CI 系统自动生成评审记录。这时可以使用poi-tl它是一个基于 Apache POI 的 Word 模板渲染引擎特点是模板用原生 Word 编写数据填充用{{}}占位符。和 Python-docx 不同poi-tl 更擅长处理已有模板的动态渲染适合把系统数据导入记录类文档。import com.deepoove.poi.XWPFTemplate; import java.util.*; public class CMMIReport { public static void main(String[] args) { MapString, Object data new HashMap(); data.put(projectName, 订单服务重构); data.put(reviewDate, 2025-03-18); data.put(reviewer, 张三); ListMapString, Object issues new ArrayList(); for (int i 1; i 3; i) { MapString, Object row new HashMap(); row.put(no, String.valueOf(i)); row.put(detail, 评审建议项 i); row.put(owner, 李四); row.put(deadline, 2025-03-25); issues.add(row); } data.put(issueList, issues); XWPFTemplate template XWPFTemplate.compile(qa_check_report.docx); template.render(data).writeToFile(qa_check_report_20250318.docx); template.close(); } }这段代码把项目名、评审日期和问题列表渲染到qa_check_report.docx模板中。注意issueList会对应模板里的一个表格poi-tl 会自动遍历列表生成多行。如果你在word 表格列宽无法拖动上踩过坑就会知道模板表格里的列宽设置必须在编译模板时就锁定为“固定列值”不要使用“自动匹配窗口”否则渲染后的行会出现列错位。服务端渲染方案和人工填写方案的差别在于人工填写的记录格式不稳定由系统生成的记录则能直接形成 CMMI 度量数据。但建议不要用服务端模板去写长文档因为 Word 排版上下文复杂渲染大量段落时性能不佳使用者最终还是要人工调整。所以我会把 poi-tl 限定在检查单、评审记录、不符合项报告这类结构高度固定的记录层。5.3 用“文件夹即版本”处理项目级 CMMI 记录多项目并行时每套 CMMI 文档都要跟着项目走。不要把所有项目的记录放在同一个文件夹里也不要让一个 Word 文档跨多个项目审批。标准做法是每个项目建独立目录把公司级规程放在公共库中项目只保留记录、计划和裁剪说明。如果你发现 Word 保存显示磁盘已满或写入失败先检查是不是这些 docx 文件正在被其他进程打开。Windows 上常见的错误是某个进程后台锁定了文件导致pqitl或 Python 脚本无法覆写。解决方法是把输出文档和正在使用的文档分开保存并关闭所有 Word 实例后再跑批处理。6. 一页索引 docx 完成 CMMI 覆盖度自查和评估取数最后的技巧是做一个只有一页的“CMMI 文档矩阵.docx”放在00_索引总表目录里。这个文档不写过程内容只放三列过程域、对应文档、关键证据。每次评审前把它打印出来逐行勾选比翻 30 个 Word 文档快得多。矩阵表的实际写法如下CMMI 过程域受控文档证据文件PP项目计划编制规程.docx订单服务项目计划_v1.2.docxPMC项目监控规程.docx3月里程碑评审记录.docxREQM需求管理规程.docx需求跟踪矩阵.xlsxCM配置管理规程.docx配置项登记表.docxPPQA质量保证规程.docxQA检查单_202503.docxMA测量分析规程.docx缺陷趋势分析.xlsx要做成可点击链接可以选中“对应文档”列的单元格右键选择“超链接”链接类型选“现有文件或网页”并指向..\02_过程\项目计划编制规程.docx。注意不要用绝对路径因为评审现场会把整个文件夹拷贝到另一台电脑绝对路径会全部断链。相对路径的前提是所有文档都在同一个父目录下这正是本文第 2 节目录设计的意义。验证矩阵是否有效的方法很简单按住 Ctrl 依次点击每个链接检查是否都能打开对应文件。如果某个链接断掉就说明文档目录被移动或改名了需要重新修复。每季度做一次这种确认能显著降低 CMMI 评估当天临时查找材料的风险。对一个多年经验的 QA 来说这套体系的本质不是内容完美而是让任何拿到文档的人都能在最短时间内找到“过程定义”和“执行证据”的对应关系。把索引矩阵留在手边就相当于给全套 CMMi 软件质量管理体系画了一张导航图。本文还有配套的精品资源点击获取
