ASPICE证据整理的核心做法是：先按过程域和过程活动建立证据清单，明确每项活动的输入、执行记录、输出物和评审记录；再按项目阶段同步收集原始记录，统一命名与版本，建立活动到证据的追溯关系；最后按评审口径组卷，做完整性与一致性自查，形成可追溯、可复核的证据包。整理工作从清单开始，证据在过程执行中同步产生并归档，事后集中补材料往往难以保证记录之间的一致性。
要点总览（TL;DR）
- 证据整理从证据清单开始：按过程域和过程活动反推每项活动应产生的输入、输出、评审记录，并逐条对应评估要求条款。
- 证据在执行中同步归档：按阶段设定收集触发条件，统一命名、版本和目录规则，原始记录与整理件分开存放，缺失项登记补录。
- 用追溯矩阵挂接需求—设计—实现—测试链路，正向与反向双向检查，断点登记后闭环处理。
- 组卷按评审阅读顺序编排目录与索引，自查覆盖完整性、一致性、时间逻辑和签署，问题整改后更新证据包版本。
- 提交前用完成检查表逐项判定，关键活动无证据、追溯断点未关闭、签署缺失属于阻断项，需处理后放行。
先定证据清单：从过程活动反推需要哪些记录
证据整理的第一步是建立证据清单。清单的编制方向是从过程活动反推证据，先确定项目适用的过程域和过程活动，再逐项回答“这项活动的执行痕迹应该落在哪里”。这样得到的清单与评估要求直接对应，避免按文档类型罗列一堆与活动脱节的资料。
拆解时可按三层展开：过程域（如需求分析、软件设计、测试等）、过程活动（该域下的具体活动）、证据项（证明活动已执行的记录）。每个证据项在清单中至少填写以下字段：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 证据编号 | 唯一编号，便于追溯引用 | SWE1-EV-003 |
| 对应过程活动 | 引用过程域与活动名称 | 软件需求分析—需求评审 |
| 输入 | 活动开始前应具备的材料 | 需求草案、评审检查单 |
| 输出/记录 | 活动完成后形成的记录 | 评审记录、问题清单、修订后需求 |
| 责任人 | 该证据的产生者 | 需求工程师 |
| 产生时点 | 在哪个阶段、哪个里程碑产生 | 需求基线建立前 |
| 存放位置 | 目录路径或系统位置 | 项目库/需求/评审记录 |
清单需要与所采用的评估模型和过程要求逐条对应，可以在清单中增加“对应过程要求条款”一列，确保每条要求都有证据项承接，没有承接的条款要单独标注并说明原因。清单在项目策划阶段完成初稿，经过程负责人和质量角色评审后冻结；冻结后如需增补，走变更记录，保留版本差异，避免评审时出现清单与实物对不上的情况。
在工具层面，证据清单可以落在研发管理平台的工作项或文档模板中。ONES 的解决方案定位支持汽车软件研发全生命周期流程活动与跨域协作的可追溯性，项目管理、知识库等模块可用于承载清单条目与对应记录，具体字段设计仍以项目自身的评估范围为准。
按阶段收集与归档：让证据在执行中同步产生
证据收集的节奏应与项目阶段同步。每个阶段结束时，该阶段应产生的记录已经完成归档，而不是等到评估前统一翻找。可按阶段划分证据类型：策划阶段产生项目计划、过程裁剪说明、角色任命；需求阶段产生需求规格、评审记录、需求基线；设计与实现阶段产生设计文档、代码评审记录、单元测试记录；测试阶段产生测试计划、用例、执行记录与缺陷记录；收尾阶段产生变更记录、问题闭环记录与阶段总结。
收集时点由触发条件决定，常见触发条件包括：评审会议结束、基线建立、里程碑通过、变更单关闭。每个触发条件对应一个收集动作和责任人，收集完成后在清单中标记状态。归档规则需要提前统一：
- 命名规则：采用“项目代号_过程域_证据类型_版本_日期”的固定结构，避免同名文件覆盖。
- 版本规则：原始记录保留原版本，修订件另存新版本并注明修订原因，不直接覆盖原件。
- 目录结构：按过程域分层，层内按证据类型分目录，与证据清单的存放位置字段保持一致。
- 原始记录与整理件分开存放：会议签到、系统截图、邮件确认等原始记录单独保存，整理件（如汇总表、索引）放在另一目录，两者建立引用关系。
发现缺失证据时，在清单中登记缺失项、缺失原因、补录责任人和计划完成时间。补录的记录要注明“补录”及补录依据，不能伪装成当时产生的原始记录。缺失项集中出现在某一过程域时，说明该活动的执行或记录习惯存在问题，应在下一个阶段调整，而不是只处理单条记录。
建立追溯关系：活动、工作产品与证据如何对应
追溯矩阵解决的是“这条证据证明的是哪项活动、哪个工作产品”的问题。矩阵的行可以是过程活动或工作产品，列包括：上游输入、本活动输出、对应证据编号、证据存放位置、评审记录编号、状态。需求—设计—实现—测试链路是追溯检查的主线：每条需求应能向下找到对应的设计条目、实现记录和测试用例，每个测试用例应能向上回溯到需求和设计依据。
双向追溯的检查方法分两个方向执行。正向检查从需求出发，逐条确认下游的设计、实现、测试证据是否齐全；反向检查从测试记录或缺陷出发，确认其对应的需求和设计依据是否存在。两个方向都走通，才说明链路完整。检查结果记录在矩阵的状态列中，发现断点时登记断点清单：
| 断点编号 | 断点位置 | 断点类型 | 处理动作 | 责任人 | 关闭状态 |
|---|---|---|---|---|---|
| TR-01 | 需求R-012无对应测试用例 | 正向缺失 | 补充用例或说明不测理由 | 测试负责人 | 已关闭 |
| TR-02 | 用例TC-045无上游需求 | 反向缺失 | 确认来源并补挂需求 | 需求工程师 | 处理中 |
断点处理要形成闭环：每个断点有处理动作、责任人和关闭确认，关闭时在矩阵中更新状态并保留处理记录。追溯关系在项目执行中随变更同步维护，变更单关闭时检查受影响的追溯链路是否已更新，避免矩阵停留在旧版本。
组卷与自查：形成可评审的证据包
组卷是把分散的证据按评审阅读顺序组织成包。目录结构建议与证据清单的过程域顺序一致，包内包含：封面与版本信息、证据包目录、证据索引表（证据编号、名称、对应活动、页码或文件位置）、各过程域证据正文、追溯矩阵、自查记录。索引表是评审人员定位证据的入口，编号必须与清单和实物一致。
组卷完成后执行自查，自查项至少覆盖：
- 完整性：清单中的每个证据项是否都能在包内找到对应文件，缺失项是否有登记和说明。
- 一致性：同一记录在不同位置出现时版本是否一致，文档中的日期、人员、编号是否前后一致。
- 时间逻辑：记录的产生时间是否与活动时间匹配，评审记录是否晚于被评审文档的形成时间。
- 签署与审批：需要签署的记录是否完成签署，签署人是否为授权角色。
常见问题集中在三类：版本不一致（正文引用旧版文档）、签署缺失（评审记录只有会议纪要没有确认签署）、记录与活动时间错位（补录记录的时间早于实际形成时间）。自查发现的问题登记在自查记录表中，逐条整改并复核，整改完成后更新证据包版本。自查记录本身也作为证据包的一部分保留，体现整理过程的可复核性。
角色分工与交付物：谁在什么时点交什么
证据整理要落到角色和节点上，否则清单和规则难以执行。基本分工如下：
| 角色 | 职责 | 主要交付物 | 交付节点 |
|---|---|---|---|
| 过程负责人 | 确定适用过程域，组织清单编制与冻结 | 证据清单、过程裁剪说明 | 项目策划阶段 |
| 项目成员 | 在活动执行中产生并提交原始记录 | 各活动记录、评审材料 | 活动完成时 |
| 证据整理责任人 | 收集归档、维护追溯矩阵、组卷 | 归档记录、追溯矩阵、证据包 | 各阶段末、评审前 |
| 质量/评审角色 | 审核证据完整性与一致性，确认自查结果 | 审核意见、自查确认记录 | 组卷完成后 |
整理责任人与审核人应分离，整理人负责收集和组卷，审核人独立检查，避免同一人既做又判。交付节点与项目里程碑对齐：阶段末完成该阶段证据归档，评审前完成组卷和自查，评审时提交证据包和自查记录。角色交接时，移交方需提交证据清单状态、未关闭断点清单和存放位置说明，接收方核对后确认，交接记录留存。
一个示例：某过程域证据包从清单到组卷
以下为演示情景，用于说明流程，不代表真实项目记录。假设某项目选取“软件需求分析”过程域作为示例范围，覆盖需求获取、需求分析、需求评审三项活动。
清单条目示例：SWE1-EV-001 需求规格说明书（输出，需求工程师，需求基线前，项目库/需求/规格）；SWE1-EV-002 需求评审记录（输出，评审主持人，评审会后，项目库/需求/评审）；SWE1-EV-003 评审问题清单及关闭记录（输出，需求工程师，评审后一周内，项目库/需求/问题）。每条均标注对应过程要求条款。
收集与追溯填写示例：需求R-012在矩阵中挂接设计条目D-008、测试用例TC-045，证据编号分别为SWE1-EV-001和测试域证据；正向检查发现R-012的评审记录缺少签署页，登记为断点TR-03，补签后关闭。组卷时按“封面—目录—索引—规格—评审记录—问题闭环—追溯矩阵—自查记录”排列，索引表逐条对应证据编号。
自查结果示例：发现评审记录引用的是规格V1.1而包内放的是V1.2，整改为统一使用V1.2并在评审记录中注明版本；自查记录表登记该问题、整改人和复核结论。可迁移的规律是：清单先行、按活动挂证据、断点闭环、组卷后自查；适用边界在于示例只覆盖单一过程域，跨域项目需在矩阵中增加域间接口证据，组卷目录也需相应扩展。
完成检查：证据整理到什么程度算可提交
提交前用一份检查表逐项判断，全部通过或阻断项已获放行才可提交：
| 检查项 | 判断标准 | 结果 |
|---|---|---|
| 清单覆盖度 | 适用过程要求条款均有证据项承接，无承接条款有书面说明 | 通过/不通过 |
| 追溯完整性 | 正向与反向检查均完成，断点全部关闭或有放行说明 | 通过/不通过 |
| 版本与签署 | 包内文档版本一致，需签署记录已完成签署 | 通过/不通过 |
| 时间一致性 | 记录时间与活动时间逻辑匹配，补录项已标注 | 通过/不通过 |
| 自查闭环 | 自查问题全部整改并复核，自查记录随包提交 | 通过/不通过 |
阻断项通常包括：关键过程活动无任何证据、追溯链路存在未关闭断点、签署缺失且无法补签。出现阻断项时暂停提交，明确责任人和完成时间；非阻断项（如个别记录格式不统一）可登记后随包说明。检查表由整理人填写、审核人确认，作为证据包的最后一页留存，评审时可直接展示整理与自查的完整过程。
常见问题
项目已经进入后期，之前的证据没有同步归档，还能补吗？
可以补录，但要区分补录与原始记录。补录的记录需在清单和记录本身标注“补录”、补录原因和补录依据，不能伪装成当时产生的原始记录。补录完成后，重点检查时间逻辑：补录记录的形成时间与所证明活动的发生时间是否匹配，评审记录是否晚于被评审文档的形成时间。若某过程域缺失集中出现，说明该活动的记录习惯需要调整，应在后续阶段建立触发式收集，避免同类问题重复发生。
追溯矩阵要维护到什么颗粒度，是否每条需求都要挂接全部下游证据？
颗粒度取决于评估范围和项目规模。通常以需求条目为最小追溯单元，向下挂接设计条目、实现记录和测试用例；测试用例向上回溯到需求和设计依据。对于批量生成或共用实现的条目，可在矩阵中注明归并关系，但归并依据要可查。颗粒度过粗会导致断点难以定位，过细则维护成本高，建议在项目策划阶段与过程负责人确认颗粒度并写入清单说明。
证据包提交前发现签署缺失，但签署人已离职，怎么处理？
先确认该记录是否属于必须签署的证据项。若属于，可由原签署人的授权代理人或现任对应角色补签，并在记录中注明补签原因、补签依据和授权关系；若无法补签，登记为阻断项并说明影响范围，由质量角色评估是否放行。处理过程要留痕，补签记录与原始记录一并保留，避免评审时无法解释签署链的变化。
多个项目共用一套过程资产时，证据清单需要每个项目各做一份吗？
建议以组织级过程资产为基线，项目级清单在基线上做裁剪。裁剪内容包括：本项目适用的过程域、活动裁剪说明、证据项增减及理由。项目清单保留与基线条款的对应关系，便于跨项目比较和复用。裁剪说明本身也是证据的一部分，需经过程负责人评审后冻结，后续变更走变更记录。
证据整理工作能否在研发管理工具中完成，而不是靠文件夹管理？
可以在工具中承载清单条目、记录归档和追溯关系。ONES 的解决方案定位支持汽车软件研发全生命周期流程活动与跨域协作的可追溯性，项目管理、知识库等模块可用于存放清单条目与对应记录。具体字段设计、目录结构和权限规则仍以项目自身的评估范围和管理要求为准，工具承载不改变证据本身的产生时点和内容要求。
