简介《精品2021-2022年资料软件质量保证体系》是一份面向精品课件开发团队、软件项目经理与QA/QC人员的质量管理文档重点解决课件从需求、设计、编码到测试交付过程中的质量责任不清、评审与配置管理缺乏统一规范等问题。压缩包内仅含1个docx文件大小约176KB内容以正式标准文本呈现便于直接查阅、裁剪或作为内部规范模板复用。文档依次说明使用范围、引用标准与术语定义并围绕软件质量管理责任分配、工作产品和活动、评审、质量保证、软件测试及配置管理展开列出项目经理、配置管理员、QA与QC等角色的职责覆盖版本控制、变更管理、基线管理与配置审计等关键环节。目前已有60人学习适合需要搭建软件质量保证流程、完善评审与测试制度或对照CMMI3、ISO 9001要求整理内部标准的读者参考。1. 一份 2021-2022 年的软件质量保证体系文档为什么值得逐字拆很多团队的质量体系文档都是评审前突击拼出来的评审一过就归档吃灰。这份《精品2021-2022年资料软件质量保证体系.docx》不太一样它把 CMMI3 的框架落到了一张张可执行的表上谁负责什么工作产品、哪些可裁剪哪些不可裁剪、评审几轮、QA 每月审计几次全都写死了。它针对的是课件类软件产品的开发交付署名微软中国参照 CMMI3 与质量管理标准同时只在本公司内部生效。换句话说这不是一份理论白皮书而是一份能直接拿来改字段、改角色名就投入使用的模板。适合两类人读一类是正在搭研发流程的中小团队技术负责人想找一份能照着抄的骨架另一类是已经过了 CMMI3 或者在做体系认证的公司想看看别人把责任分配和评审时机落到了什么颗粒度。下面按文档本身的章节顺序拆重点拆它没写透、但落地时必须补上的部分。2. 软件质量管理责任分配与工作产品裁剪矩阵2.1 四个角色如何切分质量职责文档开篇就把质量相关的角色分成四个配置管理员、QA、QC、以及隐含在表格里的项目经理和开发测试人员。这个切法有个关键点容易被忽略——QA 和 QC 是分开的。QA 管过程做过程评审和产品审计检查文档和代码的规范执行情况QC 管结果软件测试是质量控制的主要手段由测试人员负责测试设计和执行。这种切分的好处是责任不重叠QA 不发版、不改代码、不签字放行功能只对流程符合性负责测试人员不对流程负责只对缺陷发现率负责。常见的误用是把两者合成一个「质量部」结果就是既当裁判又当运动员审计报告里全是「基本符合」。配置管理员的职责写得很具体制定、创建和维护配置库提供文档规范并传达到各部门。这里「传达到各个部门」是个容易被漏掉的动作实际执行时需要一个确认回执否则规范写完了没人知道。2.2 工作产品与活动矩阵的可裁剪判定文档 4.2 节用一张表把活动、责任人、工作产品、是否可裁剪串起来了。这张表是全篇最有复用价值的部分我把它整理成下面这样方便对照改造活动责任人工作产品可裁剪项目立项项目经理项目计划否项目立项配置管理员配置管理计划是项目立项QA质量保证计划是项目立项测试人员系统测试计划否需求管理项目经理需求调研报告是需求管理项目经理需求规格说明书否需求管理用户、项目经理用户确认书是需求管理QA评审报告是设计过程设计组概要设计说明书否设计过程设计组界面设计图是设计过程设计组详细设计说明书是设计过程项目经理决策分析评议表是开发编码项目经理版本发布记录否开发编码开发人员程序代码否系统测试测试人员测试用例、测试报告否结项交付项目经理项目总结报告否结项交付项目经理、客户用户验收报告是注意「否」的那几项项目计划、系统测试计划、需求规格说明书、概要设计说明书、程序代码、测试用例与报告、项目总结报告加上所有阶段的 QA 不符合项跟踪记录表。它们构成最小合规底座任何规模的项目都不能砍。2.3 按项目规模裁剪的实操命令表格给的是「能不能裁」没给「什么规模裁什么」。小团队直接照搬全套会被文档压死我一般按人月数分档用一个脚本生成裁剪清单# crop_plan.py 根据项目规模和风险等级生成裁剪后的工作产品清单 import json # 从 4.2 表格抽取的基线与可选项 MANDATORY [项目计划, 系统测试计划, 需求规格说明书, 概要设计说明书, 程序代码, 测试用例, 测试报告, 项目总结报告, 不符合项跟踪记录表] OPTIONAL [配置管理计划, 质量保证计划, 需求调研报告, 用户确认书, 界面设计图, 详细设计说明书, 决策分析评议表, 培训教材, 用户手册, 安装手册] def build_plan(person_month: int, risk_level: str) - dict: person_month: 项目总人月risk_level: low/medium/high kept list(MANDATORY) if person_month 6 or risk_level in (medium, high): # 规模够大或风险偏高可选项全留 kept OPTIONAL elif person_month 3: # 中等规模只保留设计与交付类可选项 kept [详细设计说明书, 用户手册, 用户确认书] return {keep: sorted(set(kept)), drop: sorted(set(OPTIONAL) - set(kept))} print(json.dumps(build_plan(4, medium), ensure_asciiFalse, indent2))逻辑说明脚本把文档里的「否」列硬编码为MANDATORY这些无论如何都进keep「是」列放进OPTIONAL由人月数和风险等级两个维度决定是否保留。参数person_month用项目总投入人月估risk_level由是否涉及对外交付、是否有硬性合规要求决定。跑出来的drop列表要写进项目计划作为裁剪记录存档评审时这就是裁剪依据。3. 评审机制的角色约束与缺陷闭环实现3.1 评审组到底能有哪些人文档 4.3 节对评审组的构成写了三条硬约束成员包括作者、主持人、记录员以及若干陪审员可以包括 PPQA 和项目组成员但不能有作者的直接领导或者管理者。第三条是最容易被违反也最有价值的约束——领导在场作者不敢暴露问题评审会变成汇报会。预备会上作者要讲清工作产品的目标、相关实现细节和开发标准并且文档明确「应该允许甚至鼓励评审组成员动手查看工作产品」。这一句是在防「只讲不看」的形式主义评审。主持人负责确定正式评审会议的开始时间预备会到正式会议之间留出成员独立检查的时间。3.2 各阶段评审时机与参与角色对照评审不是每个阶段都开会文档给了明确的时机和人员我按阶段整理如下-- review_schedule.sql 阶段评审配置表可直接建表使用 CREATE TABLE review_stage ( stage VARCHAR(16) NOT NULL, -- 阶段名 item VARCHAR(64) NOT NULL, -- 评审对象 meeting VARCHAR(32) NOT NULL, -- 评审会议 participants VARCHAR(128), -- 参加角色 croppable TINYINT(1) DEFAULT 0 -- 1可裁剪 0不可裁剪 ); INSERT INTO review_stage VALUES (计划, 项目计划, 项目启动会议, 项目所有成员, 0), (计划, 质量保证计划, 项目启动会议, 项目所有成员, 1), (计划, 系统测试计划, 项目启动会议, 项目所有成员, 0), (需求, 需求调研报告, 项目评审会议1, 需求分析师,项目经理,系统架构师,设计组,QA, 1), (需求, 需求规格说明书, 项目评审会议1, 需求分析师,项目经理,系统架构师,设计组,QA, 0), (设计, 概要设计说明书, 项目评审会议2, 需求分析师,项目经理,系统架构师,设计组,QA, 0), (设计, UI 设计图, 项目评审会议2, UI美工,需求分析师,项目经理,系统架构师,设计组,QA, 1), (设计, 详细设计说明书, 项目评审会议2, 需求分析师,项目经理,系统架构师,设计组,QA, 1), (编码, 代码检查(1), 项目评审会议3, 开发组,项目经理,需求分析师,系统架构师,QA, 0), (编码, 代码检查(2), 项目评审会议3, 开发组,项目经理,需求分析师,系统架构师,QA, 0), (测试, 系统测试用例, 项目评审会议4, 测试人员,项目经理,开发组,需求分析师,系统架构师,QA, 0), (测试, 系统测试报告(1),项目评审会议4, 测试人员,项目经理,开发组,需求分析师,系统架构师,QA, 0), (测试, 系统测试报告(2),项目评审会议4, 测试人员,项目经理,开发组,需求分析师,系统架构师,QA, 0), (发布, 用户手册, 项目总结会议, 项目所有成员, 1), (发布, 项目总结报告, 项目总结会议, 项目所有成员, 0);逻辑说明meeting字段把评审对象和会议绑定编码阶段有两次代码检查说明代码要走两轮不是走个过场。participants存角色名不存具体人名方便跨项目复用。查询某个阶段要准备什么一句 SQL 就够SELECT item, participants FROM review_stage WHERE stage 设计 AND croppable 0;参数说明croppable为 0 的行对应文档里「否」的评审项这些会议的记录必须存档为 1 的行可依据 2.3 节的裁剪逻辑合并或跳过但跳过要在项目计划里注明理由。3.3 缺陷记录到关闭的流转规则文档写的是发现的每一个缺陷都要认真记录并适当分类会议结束后负责人分析原因并修正主持人确保所有缺陷得到解决如果过程需要变更把相关问题移交 QA。这套描述缺一个状态机落地时我一般补成四态流转新建 → 已分配 → 已修复 → 已验证关闭验证人不能是修复人。提示评审记录里的缺陷分类建议按「文档类 / 设计类 / 代码类 / 需求类」四类拆分类字段是后续做缺陷趋势分析的基础缺了它到项目末期算不出哪类问题在反复出现。4. QA 审计节奏与不符合项上报链路4.1 审计对象与频次的对应关系文档 4.4 节把 QA 的工作拆成三块审计哪些产品、审计哪些活动、不符合项怎么处理。产品审计列表里项目计划、需求规格说明书、概要设计说明书、用户手册、项目总结报告的责任人都写着项目经理源代码归开发组测试用例和报告归测试组。这里有个隐含信号QA 审计的是「工作产品是否按标准产出」不是「工作产品质量好不好」后者是 QC 的活。活动审计的频次在文档里给了明确值审计活动审计时机项目立项计划阶段需求管理需求阶段设计过程、决策分析设计阶段开发编码、集成过程编码阶段系统测试测试阶段项目结项、交付与维护发布阶段项目跟踪与监控每月一次风险管理每月一次配置管理每月一次评审活动每月一次前六项跟着阶段走后四项是周期性动作每月一次。这个设计能防止长周期项目在阶段之外失控——阶段审计只在节点上抽查月度审计负责兜底。4.2 不符合项跟踪表的落地与上报升级不符合项的处理链路文档写得很直白写入《不符合项跟踪记录表》邮件发给相关人员沟通顺序是项目组成员 → 项目经理 → 部门经理 → 总经理QA 跟踪到问题解决、验证并关闭。四级升级意味着问题不能在项目组内部沉淀超过约定时限实际执行要配一个时限否则「上报」永远不会触发。下面是一个可以改造后当模板用的跟踪表结构与催办脚本# ncr_track.py 不符合项跟踪与超期催办 import datetime as dt # 每条记录编号、所属活动、责任人、发现日期、升级级别(1项目组/2项目经理/3部门/4总经理) records [ {id: NCR-001, activity: 设计过程, owner: 张三, found: 2021-03-01, level: 1, closed: False}, {id: NCR-002, activity: 需求管理, owner: 李四, found: 2021-02-20, level: 2, closed: False}, ] SLA_DAYS {1: 3, 2: 5, 3: 7, 4: 10} # 每级允许的处理天数 def escalate(rec, today): 超期则升级一级返回是否已升级 limit SLA_DAYS[rec[level]] overdue (today - dt.date.fromisoformat(rec[found])).days limit if overdue and rec[level] 4 and not rec[closed]: rec[level] 1 return True return False today dt.date.today() for r in records: if escalate(r, today): print(f{r[id]} 超期已升级至第 {r[level]} 级抄送对应管理者)逻辑说明SLA_DAYS是每级升级前的容忍天数这个值文档没给需要团队自己定。脚本逐条判断是否超期超期且未关闭就升级一级并打印抄送提示。参数level达到 4 之后不再升级改为在月度质量报告里单列。这个脚本的价值在于把「跟踪到关闭」这句抽象要求变成可执行的日跑任务。注意升级不等于追责上报的目的在于调配资源解决阻塞。把升级当成问责工具项目组会选择瞒报不符合项数据就没有参考意义了。5. 配置管理与变更控制的 VSS 目录结构落法5.1 配置库目录与组织资产库的层次文档 4.6 节给的配置管理内容有九项工具的日常管理与维护、提交配置管理计划、配置项的管理与维护、执行版本控制和变更控制方案、配置审计并提交报告、对开发人员培训、编译测试及发布版本、版本日常维护、建立外部发布版本。工具明确写了 VSS。配置库目录的结构在文档里以层级形式呈现从「组织资产库」往下分组织风险库、最佳实践库、文档模板规范、代码库项目层再往下列项目名称各阶段项目文档挂在项目下。这个结构的关键在于组织级和项目级分开——模板、规范、最佳实践属于组织级跨项目复用阶段文档、代码、发布版本属于项目级随项目生命周期走。# VSS 目录初始化按文档结构建组织级与项目级两级库 # 组织级只读为主由 QA 与配置管理员维护 ss Create $/组织资产库 -C- 组织级资产总入口 ss Create $/组织资产库/组织风险库 -C- 风险清单与应对记录 ss Create $/组织资产库/最佳实践库 -C- 入最佳实践库的产品文档 ss Create $/组织资产库/文档模板规范 -C- 各类文档模板与编写规范 ss Create $/组织资产库/代码库 -C- 公共组件与骨架代码 # 项目级按项目名隔离 ss Create $/ProjectA/01_计划 -C- 项目计划、QA计划、配置管理计划 ss Create $/ProjectA/02_需求 -C- 调研报告、需求规格说明书、确认书 ss Create $/ProjectA/03_设计 -C- 概要设计、详细设计、界面图 ss Create $/ProjectA/04_编码 -C- 源代码与版本发布记录 ss Create $/ProjectA/05_测试 -C- 测试用例与测试报告 ss Create $/ProjectA/06_发布 -C- 用户手册、安装手册、验收报告参数说明ss Create是 VSS 命令行建目录-C-后跟注释。项目编号用01_到06_前缀是为了在客户端按名称排序时天然按阶段排列。组织资产库/最佳实践库对应文档里「入最佳实践库的产品」这条 QA 审计项项目结项时由 QA 从项目文档里挑出可复用件迁入。5.2 变更控制流程的四步闭环文档 4.6.4 把变更控制流程画成四步提出变更申请 → 审核变更申请 → 识别变更的可行性 → 执行对应变更请求审批表、变更跟踪记录表。三步走下来真正决定流程成败的是「审核」这一步由谁做、依据什么。常见做法是配置控制委员会CCB来审成员至少覆盖项目经理、架构师、测试负责人、配置管理员重大变更加 QA 列席。变更申请提交后必须绑定影响范围影响哪些基线、哪些测试用例要重跑、哪些文档要同步更新。没有影响范围分析的变更单审批就是走过场。执行完成后往回填变更跟踪记录表这张表是配置审计的输入——审计时抽查几个已关闭的变更看跟踪表、代码提交记录、更新后的文档三者能不能对上。5.3 配置审计的三个检查点配置审计文档只说「完成配置审计并提交报告」没给检查点。按这套体系的逻辑我一般固定查三件事一是基线完整性某次发布对应的需求、设计、代码、测试用例是不是都在配置库里且版本一致用命令导出对比即可# 导出指定标签下的文件清单与发布记录核对 ss History $/ProjectA -V~LRelease_1.0 -R release_filelist.txt # -V~L 指定标签-R 递归子目录输出重定向后逐行核对是否与发布记录一致二是变更闭环率统计未关闭的变更请求占比超过阈值说明审核环节积压。三是外部发布版本的对应关系文档要求「建立外部发布版本」也就是交付给客户的版本要在配置库里能唯一对应到一个标签否则客户报缺陷时回溯不到源码。提示VSS 的年代较久如果团队用的是 Git目录结构照搬把ss Create换成目录加.gitkeep把标签换成git tag -a Release_1.0审计命令换成git ls-tree -r --name-only Release_1.0其余流程不变。6. 把这份 docx 改成团队自用模板的三个技巧第一个技巧是先用「角色替换表」把微软中国的署名和角色名换掉再动内容。文档里的角色是配置管理员、QA、QC、项目经理、开发组、测试组小团队往往一人多角直接改职责描述会前后矛盾。做法是建一张映射表把文档角色映射到现有岗位然后全局替换替换完再人工过一遍 4.4.1 的产品审计表确认「责任人」一栏没有同一个人同时出现在审计方和被审计方。第二个技巧是给可裁剪项加标记而不是删行。文档 4.2 的「是否可裁剪」列是个字符串实际用起来容易忘。把 docx 转成 Markdown 或 CSV 后给可裁剪行加[可选]前缀裁剪时整行删除并在项目计划的裁剪说明里引用原始章节号评审时能说清删的是文档哪一条。转换可以用 python-docx 批量处理# docx2md_note.py 给可裁剪行加标记保留章节号引用 from docx import Document doc Document(质量保证体系.docx) for para in doc.paragraphs: text para.text.strip() # 文档 4.2 表格行的可裁剪列以「是」结尾 if text.endswith(是) and (计划 in text or 报告 in text or 说明书 in text): para.text [可选] text doc.save(质量保证体系_标注版.docx) # 参数endswith(是) 匹配可裁剪标志条件里限定关键词避免误伤正文句子逻辑说明这个脚本用的是粗匹配只适合做初筛。跑完必须人工核对因为正文里也有以「是」结尾的句子会被误标。python-docx修改para.text会丢失原来的样式如果在意格式改用批注方式追加标记更稳妥。第三个技巧最关键把「每月一次」的四项审计项目跟踪与监控、风险管理、配置管理、评审活动做成日历提醒而不是写进流程文件。流程文件里写「每月一次」等于没写实际执行的团队都是把提醒挂在项目管理工具里到点自动生成审计任务并指派给 QA。另外不符合项跟踪表的 SLA 天数、变更审核的 CCB 名单、配置审计的三个检查点这三样文档里都没有明确值属于必须由团队自己补的空白补完再落库这份体系才算真正跑起来。本文还有配套的精品资源点击获取
简介《精品2021-2022年资料软件质量保证体系》是一份面向精品课件开发团队、软件项目经理与QA/QC人员的质量管理文档重点解决课件从需求、设计、编码到测试交付过程中的质量责任不清、评审与配置管理缺乏统一规范等问题。压缩包内仅含1个docx文件大小约176KB内容以正式标准文本呈现便于直接查阅、裁剪或作为内部规范模板复用。文档依次说明使用范围、引用标准与术语定义并围绕软件质量管理责任分配、工作产品和活动、评审、质量保证、软件测试及配置管理展开列出项目经理、配置管理员、QA与QC等角色的职责覆盖版本控制、变更管理、基线管理与配置审计等关键环节。目前已有60人学习适合需要搭建软件质量保证流程、完善评审与测试制度或对照CMMI3、ISO 9001要求整理内部标准的读者参考。1. 一份 2021-2022 年的软件质量保证体系文档为什么值得逐字拆很多团队的质量体系文档都是评审前突击拼出来的评审一过就归档吃灰。这份《精品2021-2022年资料软件质量保证体系.docx》不太一样它把 CMMI3 的框架落到了一张张可执行的表上谁负责什么工作产品、哪些可裁剪哪些不可裁剪、评审几轮、QA 每月审计几次全都写死了。它针对的是课件类软件产品的开发交付署名微软中国参照 CMMI3 与质量管理标准同时只在本公司内部生效。换句话说这不是一份理论白皮书而是一份能直接拿来改字段、改角色名就投入使用的模板。适合两类人读一类是正在搭研发流程的中小团队技术负责人想找一份能照着抄的骨架另一类是已经过了 CMMI3 或者在做体系认证的公司想看看别人把责任分配和评审时机落到了什么颗粒度。下面按文档本身的章节顺序拆重点拆它没写透、但落地时必须补上的部分。2. 软件质量管理责任分配与工作产品裁剪矩阵2.1 四个角色如何切分质量职责文档开篇就把质量相关的角色分成四个配置管理员、QA、QC、以及隐含在表格里的项目经理和开发测试人员。这个切法有个关键点容易被忽略——QA 和 QC 是分开的。QA 管过程做过程评审和产品审计检查文档和代码的规范执行情况QC 管结果软件测试是质量控制的主要手段由测试人员负责测试设计和执行。这种切分的好处是责任不重叠QA 不发版、不改代码、不签字放行功能只对流程符合性负责测试人员不对流程负责只对缺陷发现率负责。常见的误用是把两者合成一个「质量部」结果就是既当裁判又当运动员审计报告里全是「基本符合」。配置管理员的职责写得很具体制定、创建和维护配置库提供文档规范并传达到各部门。这里「传达到各个部门」是个容易被漏掉的动作实际执行时需要一个确认回执否则规范写完了没人知道。2.2 工作产品与活动矩阵的可裁剪判定文档 4.2 节用一张表把活动、责任人、工作产品、是否可裁剪串起来了。这张表是全篇最有复用价值的部分我把它整理成下面这样方便对照改造活动责任人工作产品可裁剪项目立项项目经理项目计划否项目立项配置管理员配置管理计划是项目立项QA质量保证计划是项目立项测试人员系统测试计划否需求管理项目经理需求调研报告是需求管理项目经理需求规格说明书否需求管理用户、项目经理用户确认书是需求管理QA评审报告是设计过程设计组概要设计说明书否设计过程设计组界面设计图是设计过程设计组详细设计说明书是设计过程项目经理决策分析评议表是开发编码项目经理版本发布记录否开发编码开发人员程序代码否系统测试测试人员测试用例、测试报告否结项交付项目经理项目总结报告否结项交付项目经理、客户用户验收报告是注意「否」的那几项项目计划、系统测试计划、需求规格说明书、概要设计说明书、程序代码、测试用例与报告、项目总结报告加上所有阶段的 QA 不符合项跟踪记录表。它们构成最小合规底座任何规模的项目都不能砍。2.3 按项目规模裁剪的实操命令表格给的是「能不能裁」没给「什么规模裁什么」。小团队直接照搬全套会被文档压死我一般按人月数分档用一个脚本生成裁剪清单# crop_plan.py 根据项目规模和风险等级生成裁剪后的工作产品清单 import json # 从 4.2 表格抽取的基线与可选项 MANDATORY [项目计划, 系统测试计划, 需求规格说明书, 概要设计说明书, 程序代码, 测试用例, 测试报告, 项目总结报告, 不符合项跟踪记录表] OPTIONAL [配置管理计划, 质量保证计划, 需求调研报告, 用户确认书, 界面设计图, 详细设计说明书, 决策分析评议表, 培训教材, 用户手册, 安装手册] def build_plan(person_month: int, risk_level: str) - dict: person_month: 项目总人月risk_level: low/medium/high kept list(MANDATORY) if person_month 6 or risk_level in (medium, high): # 规模够大或风险偏高可选项全留 kept OPTIONAL elif person_month 3: # 中等规模只保留设计与交付类可选项 kept [详细设计说明书, 用户手册, 用户确认书] return {keep: sorted(set(kept)), drop: sorted(set(OPTIONAL) - set(kept))} print(json.dumps(build_plan(4, medium), ensure_asciiFalse, indent2))逻辑说明脚本把文档里的「否」列硬编码为MANDATORY这些无论如何都进keep「是」列放进OPTIONAL由人月数和风险等级两个维度决定是否保留。参数person_month用项目总投入人月估risk_level由是否涉及对外交付、是否有硬性合规要求决定。跑出来的drop列表要写进项目计划作为裁剪记录存档评审时这就是裁剪依据。3. 评审机制的角色约束与缺陷闭环实现3.1 评审组到底能有哪些人文档 4.3 节对评审组的构成写了三条硬约束成员包括作者、主持人、记录员以及若干陪审员可以包括 PPQA 和项目组成员但不能有作者的直接领导或者管理者。第三条是最容易被违反也最有价值的约束——领导在场作者不敢暴露问题评审会变成汇报会。预备会上作者要讲清工作产品的目标、相关实现细节和开发标准并且文档明确「应该允许甚至鼓励评审组成员动手查看工作产品」。这一句是在防「只讲不看」的形式主义评审。主持人负责确定正式评审会议的开始时间预备会到正式会议之间留出成员独立检查的时间。3.2 各阶段评审时机与参与角色对照评审不是每个阶段都开会文档给了明确的时机和人员我按阶段整理如下-- review_schedule.sql 阶段评审配置表可直接建表使用 CREATE TABLE review_stage ( stage VARCHAR(16) NOT NULL, -- 阶段名 item VARCHAR(64) NOT NULL, -- 评审对象 meeting VARCHAR(32) NOT NULL, -- 评审会议 participants VARCHAR(128), -- 参加角色 croppable TINYINT(1) DEFAULT 0 -- 1可裁剪 0不可裁剪 ); INSERT INTO review_stage VALUES (计划, 项目计划, 项目启动会议, 项目所有成员, 0), (计划, 质量保证计划, 项目启动会议, 项目所有成员, 1), (计划, 系统测试计划, 项目启动会议, 项目所有成员, 0), (需求, 需求调研报告, 项目评审会议1, 需求分析师,项目经理,系统架构师,设计组,QA, 1), (需求, 需求规格说明书, 项目评审会议1, 需求分析师,项目经理,系统架构师,设计组,QA, 0), (设计, 概要设计说明书, 项目评审会议2, 需求分析师,项目经理,系统架构师,设计组,QA, 0), (设计, UI 设计图, 项目评审会议2, UI美工,需求分析师,项目经理,系统架构师,设计组,QA, 1), (设计, 详细设计说明书, 项目评审会议2, 需求分析师,项目经理,系统架构师,设计组,QA, 1), (编码, 代码检查(1), 项目评审会议3, 开发组,项目经理,需求分析师,系统架构师,QA, 0), (编码, 代码检查(2), 项目评审会议3, 开发组,项目经理,需求分析师,系统架构师,QA, 0), (测试, 系统测试用例, 项目评审会议4, 测试人员,项目经理,开发组,需求分析师,系统架构师,QA, 0), (测试, 系统测试报告(1),项目评审会议4, 测试人员,项目经理,开发组,需求分析师,系统架构师,QA, 0), (测试, 系统测试报告(2),项目评审会议4, 测试人员,项目经理,开发组,需求分析师,系统架构师,QA, 0), (发布, 用户手册, 项目总结会议, 项目所有成员, 1), (发布, 项目总结报告, 项目总结会议, 项目所有成员, 0);逻辑说明meeting字段把评审对象和会议绑定编码阶段有两次代码检查说明代码要走两轮不是走个过场。participants存角色名不存具体人名方便跨项目复用。查询某个阶段要准备什么一句 SQL 就够SELECT item, participants FROM review_stage WHERE stage 设计 AND croppable 0;参数说明croppable为 0 的行对应文档里「否」的评审项这些会议的记录必须存档为 1 的行可依据 2.3 节的裁剪逻辑合并或跳过但跳过要在项目计划里注明理由。3.3 缺陷记录到关闭的流转规则文档写的是发现的每一个缺陷都要认真记录并适当分类会议结束后负责人分析原因并修正主持人确保所有缺陷得到解决如果过程需要变更把相关问题移交 QA。这套描述缺一个状态机落地时我一般补成四态流转新建 → 已分配 → 已修复 → 已验证关闭验证人不能是修复人。提示评审记录里的缺陷分类建议按「文档类 / 设计类 / 代码类 / 需求类」四类拆分类字段是后续做缺陷趋势分析的基础缺了它到项目末期算不出哪类问题在反复出现。4. QA 审计节奏与不符合项上报链路4.1 审计对象与频次的对应关系文档 4.4 节把 QA 的工作拆成三块审计哪些产品、审计哪些活动、不符合项怎么处理。产品审计列表里项目计划、需求规格说明书、概要设计说明书、用户手册、项目总结报告的责任人都写着项目经理源代码归开发组测试用例和报告归测试组。这里有个隐含信号QA 审计的是「工作产品是否按标准产出」不是「工作产品质量好不好」后者是 QC 的活。活动审计的频次在文档里给了明确值审计活动审计时机项目立项计划阶段需求管理需求阶段设计过程、决策分析设计阶段开发编码、集成过程编码阶段系统测试测试阶段项目结项、交付与维护发布阶段项目跟踪与监控每月一次风险管理每月一次配置管理每月一次评审活动每月一次前六项跟着阶段走后四项是周期性动作每月一次。这个设计能防止长周期项目在阶段之外失控——阶段审计只在节点上抽查月度审计负责兜底。4.2 不符合项跟踪表的落地与上报升级不符合项的处理链路文档写得很直白写入《不符合项跟踪记录表》邮件发给相关人员沟通顺序是项目组成员 → 项目经理 → 部门经理 → 总经理QA 跟踪到问题解决、验证并关闭。四级升级意味着问题不能在项目组内部沉淀超过约定时限实际执行要配一个时限否则「上报」永远不会触发。下面是一个可以改造后当模板用的跟踪表结构与催办脚本# ncr_track.py 不符合项跟踪与超期催办 import datetime as dt # 每条记录编号、所属活动、责任人、发现日期、升级级别(1项目组/2项目经理/3部门/4总经理) records [ {id: NCR-001, activity: 设计过程, owner: 张三, found: 2021-03-01, level: 1, closed: False}, {id: NCR-002, activity: 需求管理, owner: 李四, found: 2021-02-20, level: 2, closed: False}, ] SLA_DAYS {1: 3, 2: 5, 3: 7, 4: 10} # 每级允许的处理天数 def escalate(rec, today): 超期则升级一级返回是否已升级 limit SLA_DAYS[rec[level]] overdue (today - dt.date.fromisoformat(rec[found])).days limit if overdue and rec[level] 4 and not rec[closed]: rec[level] 1 return True return False today dt.date.today() for r in records: if escalate(r, today): print(f{r[id]} 超期已升级至第 {r[level]} 级抄送对应管理者)逻辑说明SLA_DAYS是每级升级前的容忍天数这个值文档没给需要团队自己定。脚本逐条判断是否超期超期且未关闭就升级一级并打印抄送提示。参数level达到 4 之后不再升级改为在月度质量报告里单列。这个脚本的价值在于把「跟踪到关闭」这句抽象要求变成可执行的日跑任务。注意升级不等于追责上报的目的在于调配资源解决阻塞。把升级当成问责工具项目组会选择瞒报不符合项数据就没有参考意义了。5. 配置管理与变更控制的 VSS 目录结构落法5.1 配置库目录与组织资产库的层次文档 4.6 节给的配置管理内容有九项工具的日常管理与维护、提交配置管理计划、配置项的管理与维护、执行版本控制和变更控制方案、配置审计并提交报告、对开发人员培训、编译测试及发布版本、版本日常维护、建立外部发布版本。工具明确写了 VSS。配置库目录的结构在文档里以层级形式呈现从「组织资产库」往下分组织风险库、最佳实践库、文档模板规范、代码库项目层再往下列项目名称各阶段项目文档挂在项目下。这个结构的关键在于组织级和项目级分开——模板、规范、最佳实践属于组织级跨项目复用阶段文档、代码、发布版本属于项目级随项目生命周期走。# VSS 目录初始化按文档结构建组织级与项目级两级库 # 组织级只读为主由 QA 与配置管理员维护 ss Create $/组织资产库 -C- 组织级资产总入口 ss Create $/组织资产库/组织风险库 -C- 风险清单与应对记录 ss Create $/组织资产库/最佳实践库 -C- 入最佳实践库的产品文档 ss Create $/组织资产库/文档模板规范 -C- 各类文档模板与编写规范 ss Create $/组织资产库/代码库 -C- 公共组件与骨架代码 # 项目级按项目名隔离 ss Create $/ProjectA/01_计划 -C- 项目计划、QA计划、配置管理计划 ss Create $/ProjectA/02_需求 -C- 调研报告、需求规格说明书、确认书 ss Create $/ProjectA/03_设计 -C- 概要设计、详细设计、界面图 ss Create $/ProjectA/04_编码 -C- 源代码与版本发布记录 ss Create $/ProjectA/05_测试 -C- 测试用例与测试报告 ss Create $/ProjectA/06_发布 -C- 用户手册、安装手册、验收报告参数说明ss Create是 VSS 命令行建目录-C-后跟注释。项目编号用01_到06_前缀是为了在客户端按名称排序时天然按阶段排列。组织资产库/最佳实践库对应文档里「入最佳实践库的产品」这条 QA 审计项项目结项时由 QA 从项目文档里挑出可复用件迁入。5.2 变更控制流程的四步闭环文档 4.6.4 把变更控制流程画成四步提出变更申请 → 审核变更申请 → 识别变更的可行性 → 执行对应变更请求审批表、变更跟踪记录表。三步走下来真正决定流程成败的是「审核」这一步由谁做、依据什么。常见做法是配置控制委员会CCB来审成员至少覆盖项目经理、架构师、测试负责人、配置管理员重大变更加 QA 列席。变更申请提交后必须绑定影响范围影响哪些基线、哪些测试用例要重跑、哪些文档要同步更新。没有影响范围分析的变更单审批就是走过场。执行完成后往回填变更跟踪记录表这张表是配置审计的输入——审计时抽查几个已关闭的变更看跟踪表、代码提交记录、更新后的文档三者能不能对上。5.3 配置审计的三个检查点配置审计文档只说「完成配置审计并提交报告」没给检查点。按这套体系的逻辑我一般固定查三件事一是基线完整性某次发布对应的需求、设计、代码、测试用例是不是都在配置库里且版本一致用命令导出对比即可# 导出指定标签下的文件清单与发布记录核对 ss History $/ProjectA -V~LRelease_1.0 -R release_filelist.txt # -V~L 指定标签-R 递归子目录输出重定向后逐行核对是否与发布记录一致二是变更闭环率统计未关闭的变更请求占比超过阈值说明审核环节积压。三是外部发布版本的对应关系文档要求「建立外部发布版本」也就是交付给客户的版本要在配置库里能唯一对应到一个标签否则客户报缺陷时回溯不到源码。提示VSS 的年代较久如果团队用的是 Git目录结构照搬把ss Create换成目录加.gitkeep把标签换成git tag -a Release_1.0审计命令换成git ls-tree -r --name-only Release_1.0其余流程不变。6. 把这份 docx 改成团队自用模板的三个技巧第一个技巧是先用「角色替换表」把微软中国的署名和角色名换掉再动内容。文档里的角色是配置管理员、QA、QC、项目经理、开发组、测试组小团队往往一人多角直接改职责描述会前后矛盾。做法是建一张映射表把文档角色映射到现有岗位然后全局替换替换完再人工过一遍 4.4.1 的产品审计表确认「责任人」一栏没有同一个人同时出现在审计方和被审计方。第二个技巧是给可裁剪项加标记而不是删行。文档 4.2 的「是否可裁剪」列是个字符串实际用起来容易忘。把 docx 转成 Markdown 或 CSV 后给可裁剪行加[可选]前缀裁剪时整行删除并在项目计划的裁剪说明里引用原始章节号评审时能说清删的是文档哪一条。转换可以用 python-docx 批量处理# docx2md_note.py 给可裁剪行加标记保留章节号引用 from docx import Document doc Document(质量保证体系.docx) for para in doc.paragraphs: text para.text.strip() # 文档 4.2 表格行的可裁剪列以「是」结尾 if text.endswith(是) and (计划 in text or 报告 in text or 说明书 in text): para.text [可选] text doc.save(质量保证体系_标注版.docx) # 参数endswith(是) 匹配可裁剪标志条件里限定关键词避免误伤正文句子逻辑说明这个脚本用的是粗匹配只适合做初筛。跑完必须人工核对因为正文里也有以「是」结尾的句子会被误标。python-docx修改para.text会丢失原来的样式如果在意格式改用批注方式追加标记更稳妥。第三个技巧最关键把「每月一次」的四项审计项目跟踪与监控、风险管理、配置管理、评审活动做成日历提醒而不是写进流程文件。流程文件里写「每月一次」等于没写实际执行的团队都是把提醒挂在项目管理工具里到点自动生成审计任务并指派给 QA。另外不符合项跟踪表的 SLA 天数、变更审核的 CCB 名单、配置审计的三个检查点这三样文档里都没有明确值属于必须由团队自己补的空白补完再落库这份体系才算真正跑起来。本文还有配套的精品资源点击获取
