在 ASPICE 评估中，变更管理（SUP.10）是「基本实践覆盖最全、证据最容易残缺」的过程之一。研发团队每天都在改需求、改设计、改代码，真正的问题不是「有没有改」，而是「每一次变更，能不能说清楚为什么改、影响什么、谁批准的、验证了吗」。
▌ SUP.10 的核心闭环
一个合规的变更管理流程，至少要跑通五个环节：
- 变更请求：谁提出、改什么、为什么改，登记在案（哪怕是邮件，也要可检索）；
- 影响分析：受影响的需求、设计、代码、测试用例逐项识别，评估工作量和风险；
- 决策审批：CCB（变更控制委员会）明确「做/不做/缓做」，结论留痕；
- 实施与验证：变更落地后，受影响的验证活动必须重跑，不能「改了代码、不改用例」；
- 关闭与追溯：双向追溯矩阵同步更新，变更请求正式关闭。
▌ 中小团队最常见的三个坑
坑一：口头变更。会议室里说一句「这里改一下」，需求就变了。评估时追溯断链，全组补记录。对策：约定最低限度的登记形式，微信里达成的变更也要当天录入系统。
坑二：CCB 形式化。每周例会走个过场，所有请求全部通过。影响分析流于形式，评估师一问「这个变更影响了哪些用例」就卡壳。对策：CCB 关注重心放在影响分析和优先级，而不是签字本身。
坑三：变更后不重验证。代码改了，测试用例和测试报告还是旧的。这是 SUP.10 与 SWE.5 交叉处最常开出的不符合项。
▌ 用工具把流程「焊死」
我们自研的 AsPiCe 开发系统把 SUP.10 的五个环节做成了在线工作流：变更请求自动关联受影响的工作产品，影响分析一键生成清单，CCB 决策与验证记录在系统内闭环，追溯矩阵实时更新。评估前导出变更台账，证据一次到位。
经验总结一句话：变更管理做得好不好，不看流程文档写得多厚，看随机抽一条变更，五分钟内能不能讲清全貌。
In ASPICE assessments, change management (SUP.10) is one of the processes with the broadest coverage of base practices — and the one where evidence is most often incomplete. R&D teams change requirements, designs and code every day. The real question is never "whether something was changed", but whether every single change can be explained: why it was made, what it affects, who approved it, and whether it was verified.
▌ The Core Closed Loop of SUP.10
A compliant change management process must run through at least five stages:
- Change request: who raised it, what changes, and why — all on record (even decisions made in an email must be searchable);
- Impact analysis: systematically identify affected requirements, designs, code and test cases, and evaluate effort and risk;
- Decision and approval: the CCB (Change Control Board) makes a clear "do / don't / defer" call, with the decision documented;
- Implementation and verification: once a change lands, all affected verification activities must be re-run — updating code but not test cases is unacceptable;
- Closure and traceability: the bidirectional traceability matrix is updated in sync, and the change request is formally closed.
▌ The Three Most Common Pitfalls in Small and Mid-Sized Teams
Pitfall 1: Verbal changes. Someone says "change this" in a meeting room and the requirement is changed. When the assessment comes, traceability is broken and the whole team scrambles to backfill records. Fix: agree on a minimum registration format — changes agreed even in WeChat must be entered into the system the same day.
Pitfall 2: CCB as a formality. A weekly meeting goes through the motions and approves everything. Impact analysis becomes a rubber stamp, and the team freezes when the assessor asks "which test cases does this change affect?" Fix: focus the CCB on impact analysis and prioritization, not on the signature itself.
Pitfall 3: No re-verification after changes. The code changed, but the test cases and test reports are still the old ones. This is the most frequent non-conformity issued where SUP.10 intersects with SWE.5.
▌ Locking the Process in with Tooling
Our in-house AsPiCe development system implements the five SUP.10 stages as an online workflow: change requests are automatically linked to affected work products, impact analysis generates a checklist with one click, CCB decisions and verification records are closed within the system, and the traceability matrix updates in real time. Before an assessment, export the change ledger — all evidence ready in one pass.
One-sentence takeaway: the quality of change management is not measured by how thick the process documents are, but by whether you can explain any randomly picked change in full within five minutes.