ASPICE评估前的证据准备，核心是把评估范围内的每个过程域拆成可核验的检查项，逐项确认证据存在、有效、可追溯，并且能在受控状态下取到。这份清单按评估前4–6周启动归集、前2周完成自查、前1周冻结版本的节奏组织，覆盖范围确认、证据归集、一致性自查、现场演示和阻断项判定五个阶段，适合过程负责人、质量与评估接口人、项目证据管理员分工使用。
要点总览（TL;DR）
- 先锁定评估范围与过程域，再按过程域归集计划、执行、评审、追溯四类证据，避免备了不在范围内的材料。
- 每项检查写成可判断的通过标准，并标明证据形式、存放位置、负责人和检查时点，评估前4–6周启动归集、前2周完成自查、前1周冻结版本。
- 自查用抽样走通一条需求到测试的追溯链，重点筛出事后补写、版本冲突和追溯断点三类问题。
- 关键过程域缺执行证据、追溯链断裂、版本冲突、评审未关闭属于阻断项，清零并复核签字后才进入评估。
- 现场准备落到演示路径、证据索引和口径统一，演示人能在限定时间内独立展示一条完整证据链。
谁在什么时点使用这份清单
这份清单面向三类角色：过程负责人对本过程域证据的完整性和真实性负责；质量与评估接口人负责范围确认、复核和阻断项判定；项目证据管理员负责台账维护、版本冻结和现场索引。三类角色在准备周期内并行工作，但检查动作按阶段推进，前一阶段的阻断项清零后才进入下一阶段。
时间安排上，评估前4–6周启动证据归集，此时评估范围应已基本确定；评估前2周完成一致性自查，把版本冲突和追溯断点暴露出来；评估前1周冻结证据版本，冻结后只允许修订阻断项，不再新增证据范围。冻结日之后发生的变更，登记为观察项并说明原因。
| 角色 | 主要职责 | 关键时点 | 输出物 |
|---|---|---|---|
| 过程负责人 | 提供本过程域计划、执行、评审与追溯证据 | 评估前4–6周起持续提交 | 过程域证据包 |
| 证据管理员 | 维护证据台账、冻结版本、编制证据索引 | 全程，冻结日为评估前1周 | 证据台账与索引 |
| 评估接口人 | 确认范围、复核自查结果、判定阻断项 | 评估前2周复核，前1周签字确认 | 复核记录与清单状态 |
检查节奏建议按周设置节点：第1周完成范围确认，第2–3周完成归集，第4周完成自查并关闭阻断项，第5周完成现场演示排练，第6周冻结并签字。每个节点结束时在台账中更新状态，未通过项写明原因和计划完成时间。
阶段一：评估范围与证据框架确认
归集证据之前先锁定范围，否则容易出现准备了很多材料、却不在评估范围内的浪费，或者关键过程域漏备。范围确认要回答三个问题：评估覆盖哪些过程域、每个过程域要求到什么能力等级、每个过程域需要哪几类证据。
证据类型可按四类划分：计划类（计划、策略、准则）、执行记录类（工作产品、操作记录、数据）、评审类（评审记录、结论、关闭状态）、追溯类（需求到设计到测试的关联关系）。每个过程域至少对应其中两类以上，具体组合以评估接口人确认的范围清单为准。
| 检查项 | 通过标准 | 证据形式 | 负责人 | 时点 |
|---|---|---|---|---|
| 评估过程域清单已确认 | 清单列明过程域名称与能力等级，经评估接口人签字 | 范围确认单 | 评估接口人 | 评估前6周 |
| 过程域与证据类型一一对应 | 每个过程域至少列出计划、执行、评审、追溯中的适用类型，无空白行 | 对照表 | 过程负责人 | 评估前5周 |
| 证据受控方式已明确 | 每类证据写明存放位置、访问权限、版本标识规则 | 受控说明或台账字段 | 证据管理员 | 评估前5周 |
| 证据可获取路径已验证 | 评估接口人按路径实际打开过至少一份样本 | 访问验证记录 | 证据管理员 | 评估前4周 |
范围确认阶段最常见的偏差，是把组织级制度文件当作项目证据提交。评估关注项目实际执行，制度文件只能作为计划类证据的支撑，执行记录仍需来自具体项目。范围清单确认后如需调整，走变更登记，避免归集过程中范围反复变动。
阶段二：分过程域证据归集检查项
归集阶段是清单的主体。下表按过程域类别列出检查项，每项都写成可判断完成的形式，并标明证据形式、存放位置和负责人。项目可按实际评估范围增删行，但删除需经评估接口人确认。
| 过程域类别 | 检查项 | 通过标准 | 证据形式 | 负责人 |
|---|---|---|---|---|
| 需求与变更 | 需求基线已建立并可识别版本 | 基线版本号、建立时间、批准人齐全 | 需求基线记录 | 需求负责人 |
| 需求与变更 | 变更记录含影响分析 | 每项变更关联受影响的需求、设计、测试项 | 变更单与影响分析 | 需求负责人 |
| 设计与实现 | 设计文档与实现一致 | 抽查的设计项能在实现记录中找到对应条目 | 设计文档、提交记录 | 设计负责人 |
| 设计与实现 | 设计评审已闭环 | 评审记录含参与人、结论、问题关闭状态 | 评审记录 | 设计负责人 |
| 测试与验证 | 测试计划与用例可追溯至需求 | 每条用例标注对应需求编号，无孤立用例 | 测试计划、用例库 | 测试负责人 |
| 测试与验证 | 缺陷闭环记录完整 | 缺陷含发现、修复、验证三个状态及责任人 | 缺陷跟踪记录 | 测试负责人 |
| 项目管理 | 项目计划与进度跟踪可对照 | 计划基线存在，实际进度有更新记录和偏差说明 | 项目计划、进度报告 | 项目经理 |
| 项目管理 | 风险与职责记录完整 | 风险有等级、应对措施和责任人；职责矩阵覆盖关键角色 | 风险清单、职责矩阵 | 项目经理 |
| 支持过程 | 配置管理记录可核验 | 配置项清单、基线标识、变更授权记录齐全 | 配置管理记录 | 配置管理员 |
| 支持过程 | 问题管理与质量保证记录完整 | 问题有状态流转；质量保证检查有发现、跟踪和关闭 | 问题清单、QA记录 | 质量负责人 |
归集时按“一份证据只登记一次”的原则维护台账，同一工作产品在多个过程域被引用时，在台账中建立关联而不是重复存放。证据存放位置写到可定位的层级，例如项目空间下的具体目录或工作项编号，避免只写“见共享盘”。
阶段三：证据有效性与一致性自查
归集完成不等于证据可用。自查要筛出三类问题：事后补写的记录、版本不一致的工作产品、追溯链断裂的条目。自查采用抽样方式，每个过程域抽取若干条业务线索，从需求出发沿设计、实现、测试走通一条完整链路，比逐份翻阅更容易在有限时间内发现问题。
| 检查项 | 通过标准 | 检查方法 | 负责人 | 时点 |
|---|---|---|---|---|
| 证据为实际执行产生 | 记录时间、操作人、关联工作项与项目实际进度吻合 | 抽查时间戳与提交记录 | 过程负责人 | 评估前3周 |
| 版本一致性 | 同一工作产品只保留有效版本，过期版本有作废标识 | 比对台账版本号与文件实际版本 | 证据管理员 | 评估前2周 |
| 追溯链完整 | 抽样条目可从需求走到测试执行，每级关联可点击或可查编号 | 抽样走通一条链路 | 评估接口人 | 评估前2周 |
| 评审记录有效 | 含评审结论、参与人、问题关闭状态，无“待定”结论 | 逐份检查评审记录字段 | 过程负责人 | 评估前2周 |
| 证据可获取 | 按台账路径能在评估现场打开，权限无阻碍 | 模拟现场访问 | 证据管理员 | 评估前1周 |
自查发现的问题分两类处理：影响追溯链完整性或版本有效性的，列为阻断项立即整改；格式不规范、非关键文档更新滞后的，登记为观察项。自查结束后由评估接口人复核抽样结果，确认无版本冲突后方可进入现场准备。
在研发管理平台中承载证据时，追溯关系可以随工作项和文档的关联自动保留。ONES 的研发管理方案支持汽车软件研发全生命周期流程活动和跨域协作的可追溯性，需求、设计、测试等工作项之间的关联可作为追溯自查的入口；证据台账也可借助项目管理与知识库模块维护，减少文件版本分散带来的比对成本。具体字段配置和过程域覆盖方式需结合项目评估范围在平台内确认。
阶段四：现场评估演示与访谈准备
现场评估考察的是能否在有限时间内展示一条完整证据链，以及文档、记录、访谈三处口径是否一致。准备重点从“材料齐全”转向“讲得清、找得到、对得上”。
- 为每个过程域确定演示路径和演示人，路径写明从哪个工作产品开始、经过哪些关联、到哪里结束，控制在评估方要求的展示时长内。
- 编制证据索引，按过程域和检查项编号排列，标注存放位置和负责人，支持现场按编号直接定位。
- 统一口径：同一事项在计划文档、执行记录和访谈回答中的描述保持一致，演示人提前熟悉本过程域的证据范围和边界。
- 安排一次完整排练，由评估接口人扮演评估方提问，记录演示中断或找不到证据的位置并修正。
通过标准是演示人能在限定时间内独立完成一条完整证据链展示，且访谈回答与文档记录无矛盾。排练中发现的口径不一致，回到台账登记并指定修订责任人，修订后重新冻结。
阻断项与完成条件
阻断项是必须清零才能进入评估的问题，观察项登记后按计划处理即可。两类问题分开管理，避免把格式问题当成阻断项反复返工，也避免把追溯断链当作小问题放过。
| 类别 | 问题描述 | 处理要求 | 判定人 |
|---|---|---|---|
| 阻断项 | 关键过程域缺少执行证据 | 补齐实际执行记录，无法补齐的说明原因并评估影响 | 评估接口人 |
| 阻断项 | 需求—设计—测试追溯链断裂 | 建立关联并复核抽样链路 | 评估接口人 |
| 阻断项 | 版本冲突未解决，过期版本混入 | 作废过期版本，重新冻结有效版本 | 证据管理员 |
| 阻断项 | 评审记录未关闭，结论缺失 | 补充评审结论与关闭状态 | 过程负责人 |
| 观察项 | 个别记录格式不规范 | 登记责任人与修订计划，不阻断评估 | 证据管理员 |
| 观察项 | 非关键文档更新滞后 | 登记并说明对评估范围的影响 | 过程负责人 |
完成条件是：阻断项全部关闭并有复核记录，观察项已登记责任人与计划完成时间，评估接口人在清单上签字确认状态。签字后证据版本冻结，冻结期内新增的变更只登记不替换，现场按冻结版本演示。
证据台账与责任分工
台账是把检查项、证据、负责人和状态串起来的跟踪工具。建议字段如下，项目可在此基础上增加评估方要求的编号列。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 过程域 | 按评估范围清单中的名称填写 | 需求分析 |
| 检查项 | 对应本清单条目编号 | S3-需求基线 |
| 证据名称 | 可识别的文件或记录名称 | 需求基线V2.1 |
| 存放位置 | 可定位到目录或工作项编号 | 项目空间/需求/基线 |
| 负责人 | 对该证据真实性负责的人 | 需求负责人 |
| 检查时点 | 计划检查日期 | 评估前3周 |
| 状态 | 未开始、进行中、已通过、阻断 | 已通过 |
| 备注 | 问题说明、整改计划、复核记录 | 已复核，无版本冲突 |
责任分工按“谁产生、谁负责，谁维护、谁复核”落实：过程负责人提供并确认本过程域证据，证据管理员维护台账字段和版本冻结，评估接口人复核状态并判定阻断项。状态取值统一为未开始、进行中、已通过、阻断四种，阻断状态需在备注中写明问题和计划关闭时间，关闭后由评估接口人改为已通过并记录复核人。
台账建议每周更新一次并在阶段节点集中复核，评估前1周冻结后只允许状态从阻断改为已通过，不再新增检查项。这样在评估现场，台账本身也能作为证据管理受控状态的佐证材料。
常见问题
评估范围在准备中途发生调整，清单和台账怎么处理？
范围调整走变更登记，由评估接口人确认后更新范围清单，再同步增删台账中的检查项。已经归集的证据如果落在新范围之外，保留在台账中标注“范围外”，不直接删除，便于回溯。调整尽量在评估前2周自查开始前完成；自查启动后新增的过程域，按阻断项处理并评估是否影响现场演示安排。
证据只能事后补写，是否一定构成阻断？
评估关注项目实际执行，事后补写的记录在时间戳、操作人和关联工作项上容易与实际进度对不上，自查阶段会被筛出。如果某项活动确实执行过、只是记录缺失，可以补齐并附说明，由评估接口人判断是否影响追溯链完整性；如果活动本身缺少执行证据，属于关键过程域无执行证据，按阻断项处理。
同一份工作产品被多个过程域引用，台账要重复登记吗？
不需要。按“一份证据只登记一次”的原则，在台账中登记一条主记录，其他过程域通过关联字段引用同一记录。这样版本冻结时只需冻结一处，避免同一文件在不同位置出现不同版本。引用关系要在备注中写清被哪些过程域使用，方便现场按过程域检索。
用研发管理平台承载证据，能减少哪些准备工作？
平台主要减少两类工作量：一是追溯关系的维护，需求、设计、测试等工作项之间的关联随工作推进保留，自查时可直接从关联入口走通链路；二是台账与文档的版本比对，证据集中存放后过期版本更容易识别。ONES 的研发管理方案支持汽车软件研发全生命周期流程活动和跨域协作的可追溯性，项目管理与知识库模块可用于维护台账和文档。具体字段配置和过程域覆盖方式需结合项目评估范围在平台内确认。
评估前1周冻结后，现场发现证据缺失怎么办？
冻结期内只允许阻断项状态从阻断改为已通过，不再新增检查项或替换证据版本。现场发现缺失时，如实说明该证据的状态和原因，登记为评估后整改项，由评估接口人记录。冻结机制的价值在于保证现场演示的证据与台账一致，临时补入的材料反而会破坏版本一致性。
