Aspice标准化管理软件的版本基线，评估前不冻结，访谈时一定对不上

评估现场最常见的尴尬，不是答不上来，而是每个人答的版本不一样。项目经理说需求评审到V2.1，测试负责人打开的是V2.0用例，配置管理员手里的记录又是另一版。评估师沿抽样路径往下追，证据链的断点很快出现。

谈ASPICE标准化管理软件的版本基线，很多团队只盯流程文件是否齐全，却忽略更基础的一步：评估前有没有真正冻结基线。版本基线不冻结，访谈对不上往往不是表达问题，而是证据版本失控。

一、访谈对不上，先别急着怪记忆力

1. 三种典型表现

第一种是同一工作产品多个版本并存：文档库一版、邮件附件一版、评审记录又是一版，谁都说自己手里的是对的。

第二种是工具记录不可追溯：历史版本被覆盖，分支合并后找不到当时的提交，权限调整后旧记录打不开。

第三种是口头描述与证据不一致：访谈人按现在的做法回答，证据记录的却是几个月前的做法，两种说法放在一起就矛盾。

评估访谈核对的是当时怎么做、留下什么证据，不是现在记得什么。

2. 版本基线在ASPICE里的位置

ASPICE是汽车行业评价软件与系统开发过程能力的模型。VDA QMC在2023年12月发布ASPICE4.0；其中SUP.8配置管理的目的是建立和维护全部工作产品的完整性，并让受影响方能够获取。基线就是把一组确认过的配置项固定在某个版本上，形成可识别、可回溯的集合。

配置项是单个受控对象，基线是这些对象在某一版本上的受控集合。基线不是文件夹快照，而是哪些对象、哪个版本、由谁确认、放在哪里的一组受控记录。

图1把这条关系画得很直接：配置项汇入基线，基线支撑抽样，抽样进入访谈；基线之后还继续漂移，访谈拿到的版本就可能和证据对不上。

3. 不冻结为什么会放大差异

时间上，评估覆盖多个里程碑，证据版本一直在变；角色上，不同岗位各存一份，版本口径不统一；抽样上，正式评估通常在约定范围内抽取样本，抽到哪一版，就要能用哪一版解释清楚。

冻结的目的不是让工作停摆，而是让评估范围内的证据停止漂移。

二、冻结什么、什么时候冻结

这也是ASPICE标准化管理软件在版本基线上最容易失守的地方：系统里能查到最新版，不等于能还原评估用的那一版。

1. 五类冻结对象

纳入冻结的对象，建议分成五类。

需求与架构：客户需求、系统需求、软件架构。

设计与实现：详细设计、代码提交、发布包。

测试资产：测试计划、测试用例、测试记录。

计划与评审：项目计划、配置管理计划、评审记录。

问题与变更：问题单、变更请求、关闭记录。

不是所有文件都要冻结，纳入评估范围、会被抽样、会支撑访谈结论的工作产品必须冻结。

2. 三个检查点

第一个在评估范围确认后，冻结范围、样本项目和过程域，避免评估对象中途变化。

第二个在正式评估前10至15个工作日，完成基线候选冻结、证据索引和一致性核对。这个时间不是标准强制，而是给断点修复留余量；项目越大、变更越频繁，余量应越长。

第三个在访谈前48小时，停止非必要变更，锁定版本索引和口径。

冻结时点宁早勿晚，但也不能早到把正常修复挡在门外。

3. 冻结动作

冻结至少要做实五件事：给基线编号、版本号、冻结日期和责任人；冻结范围内普通成员只读，变更走工作流专门入口；建立证据索引，记录对象、版本、位置、责任人和访谈人；沿需求、设计、代码、测试、问题、变更的路径做一致性核对；把冻结通知发到所有访谈人，明确用哪一版回答。

图2把三个检查点和五类对象放在同一条时间轴上。范围先定，对象再冻，访谈前锁口径，顺序颠倒就容易返工。

三、让访谈对得上，靠索引不靠背话术

1. 先建版本索引表

版本索引表不需要复杂，能把人、对象、版本和位置对上就够用。

索引表让任何人被问到某个对象时，都能快速找到同一版证据。版本号不统一，访谈口径就不可能统一。

2. 用同一版证据做模拟访谈

按抽样路径走一遍：需求到设计，设计到代码，代码到测试，测试到问题，问题到变更。每个角色只回答自己实际参与的部分，不替别人回答；不确定的问题回到证据，不凭记忆补细节。

模拟访谈不是对台词，而是检查每个人能否用同一版证据讲清同一件事。

3. 四类断点及修复

版本不一致，统一到冻结基线，旧版本留档；历史不可查，恢复历史记录或补充可核验的变更记录，不补造；口径不一致，以冻结证据为准；记录缺失，先确认是否真的缺失，能补的补过程记录，不能补的如实说明。

图3把四类断点汇到同一个处理方向：先核对，再统一到基线。访谈中最危险的不是不知道，而是用错版本还很确定。

四、冻结后必须变更，怎么处理

1. 先判断是否影响评估范围

只有影响评估范围内工作产品、影响证据一致性，或必须修复的问题，才进入解冻流程；不影响评估的变更放到评估后。

2. 解冻五步

申请、影响分析、审批、在新基线实施、回归验证并更新证据索引。旧基线保留，不覆盖。

3. 访谈时主动说明

说明哪一版是评估基线、变更了什么、为什么变、验证结果是什么。评估师关注的是变更是否受控，不是有没有变更。

冻结不是禁止变更，而是让每一次变更都有入口、有记录、有验证、可回滚。

五、评估前检查表

把上面的要求收成一张表，评估前逐项核对。

检查表的价值，在于把应该冻结变成可以验证。任何一项没有验证信号，冻结就还停留在口头。

1. 访谈当天核对

带版本索引，不带一堆散文件。先确认评估师抽样的是哪个版本，再回答；回答顺序可以是结论、证据位置、版本号、变更说明。

2. 四个常见误区

冻结太晚，只留几天补材料；只冻文档，不冻代码、配置和测试记录；冻结后没有变更通道，大家私下改；访谈前统一话术，却不统一版本。

冻结的质量，最终体现在访谈时每个人能不能指向同一版证据。

六、FAQ

1. 冻结基线后，评估期间发现Bug还能修吗？

能，但要分流。影响评估范围和安全相关内容的走解冻流程并保留旧基线；不影响评估的记录到评估后处理。关键是变更受控。

2. 评估范围还没最终确认，能先冻结吗？

先冻结范围，再冻结对象。先锁定样本项目和过程域，对象冻结放在范围确认之后。

3. 多个项目共用平台代码，基线怎么划？

按评估样本项目划基线，共用平台代码单独标识版本和复用关系，不要直接当成所有项目的评估基线。

4. 评估结束后，冻结基线还要保留多久？

按组织配置管理策略和客户合同要求保留，至少保证报告、发现项和证据链在后续复核时可追溯。

回到标题里的判断：ASPICE标准化管理软件的版本基线，评估前不冻结，访谈时一定对不上。对不上的根源通常不是人不熟流程，而是证据没有停在同一个版本上。 把冻结对象、冻结时点、版本索引、变更通道四件事做实，访谈才是在讲同一个项目，而不是各讲各的版本。

资料来源：VDA QMC，《Automotive SPICE Process Assessment / Reference Model》4.0版，2023年12月，https://vda-qmc.de/wp-content/uploads/2023/12/Automotive-SPICE-PAM-v40.pdf