ASPICE证据整理的核心，是把过程活动与工作产物按“要求—活动—产物—证据—责任人—时点”建立可追溯关系，再按过程域和项目阶段归集成证据包。本文按范围确定、条目拆解、追溯建立、规则统一、角色分工、示例演示和完成检查的顺序展开，适用于评估准备或内部自查场景，不涉及认证结论。
要点总览（TL;DR）
- 先按评估或自查目标锁定本次覆盖的过程域、项目版本与时间区间，形成经过程负责人和质量角色确认的范围清单，作为后续工作的基线。
- 把过程域要求逐条拆成可判断“有/无、完整/缺失”的证据条目，标注来源要求、预期产物、证据类型和判断标准。
- 用追溯矩阵建立要求与证据的双向索引，允许一对多与多对一引用，缺失条目保留空行并登记整改，不删除。
- 统一命名、版本与状态规则，把证据的产生、收集、审核、归档分到过程负责人、项目成员、质量角色和证据管理员身上。
- 交付前按完整性、一致性、可追溯性三个维度逐项检查，缺口登记责任人与完成时间，关闭后方可交付证据包。
先定范围：本次证据整理覆盖哪些过程域与项目
证据整理最容易失控的起点，是一上来就要求所有项目、所有过程域同时交材料。更稳妥的做法是先锁定本次评估或自查的目标，再倒推范围。范围一旦确定，后续的条目拆解、追溯矩阵和检查才有统一口径。
范围确定需要三类输入：评估或自查通知中列明的过程域与能力等级；被评估项目的名称、版本与时间区间；组织内可调配的整理人力。输出是一份范围清单，至少包含过程域、项目、版本、时间区间、责任人和计划完成时间。
具体动作可以按以下顺序进行：
- 从评估计划或自查方案中摘出覆盖的过程域清单，逐条确认是否在本次范围内，避免凭印象扩大或遗漏。
- 为每个过程域指定一名过程负责人，由其确认该过程域在项目中的实际执行区间，例如需求分析从哪个版本开始、到哪个里程碑结束。
- 确定项目与版本边界。同一项目存在多个并行版本时，明确本次整理以哪个版本为主线，其他版本作为参照还是纳入。
- 划定时间区间。证据通常按项目阶段归集，区间过宽会增加无效材料，过窄则可能漏掉关键评审记录。
- 形成范围清单并组织一次确认会，由质量或过程改进角色核对过程域与项目的对应关系。
完成标志是：范围清单经过过程负责人和质量角色双方确认，每个过程域都有明确的责任人和交付时间。范围清单是后续所有工作的基线，中途调整需要记录变更原因。
把过程要求拆成可核对的证据条目
范围确定后，下一步是把过程域的抽象要求转成可以逐项判断“有或无、完整或缺失”的证据条目。这一步的产物是证据条目清单，它决定了追溯矩阵的粒度和最终检查的严格程度。
拆解时以过程域的要求条款为起点，逐条追问三个问题：这条要求对应哪些工作产物？产物在什么活动中产生？产物以什么形式留下记录？例如一条关于需求评审的要求，对应的产物可能是需求规格说明、评审记录和评审问题关闭记录，证据类型分别属于工作产物、评审记录和跟踪记录。
证据条目建议包含以下字段：
| 字段 | 填写内容 | 作用 |
|---|---|---|
| 条目编号 | 按过程域加序号，如 SWE.1-E01 | 作为追溯矩阵的索引键 |
| 来源要求 | 过程域要求条款的编号或简述 | 保证条目可回溯到要求 |
| 预期产物 | 该要求下应产生的工作产物名称 | 明确找什么 |
| 证据类型 | 计划、记录、评审、验证、变更等 | 区分证据性质，便于分类归集 |
| 判断标准 | 有/无、完整/缺失的具体判据 | 让不同人检查时结论一致 |
证据类型建议控制在少数几类，例如计划类、执行记录类、评审类、验证类、变更类。类型划分的作用是让收集人知道去哪个系统或目录找材料，也让检查人知道某类证据通常应具备哪些要素。条目拆解完成后，应由过程负责人逐条确认，避免把组织惯例当成要求，也避免漏掉要求中隐含的记录。
建立要求与证据的追溯关系
追溯矩阵是证据整理的中枢。它把证据条目与实际证据文件连接起来，使每条要求都能定位到具体证据，每份证据也能回指它支撑的要求。矩阵建立得是否扎实，直接决定交付前检查能否走通。
矩阵的字段设计建议覆盖：要求编号、对应活动、工作产物、证据编号、证据名称与存放位置、责任人、产生时点、当前状态。状态可以用“待收集、已收集、已审核、已归档、缺失”这类取值，便于按状态筛选缺口。
双向追溯需要在矩阵中同时支持两个方向的查询：从要求出发，能找到支撑它的全部证据；从证据出发，能说明这份证据服务于哪条或哪几条要求。实际操作中，一对多和多对一关系很常见。一份评审记录可能同时支撑需求评审和变更控制两条要求，一条要求也可能需要计划、记录和验证三类证据共同支撑。处理方式是允许矩阵中一行对应多条要求编号，或一份证据在多个条目下重复引用同一证据编号，并在备注中说明复用理由。
建立矩阵的顺序是：先导入证据条目清单作为行，再逐条填入证据编号和存放位置，最后统一检查是否存在有要求无证据、有证据无归属的行。对于暂时找不到证据的条目，保留空行并标记为缺失，不要删除，缺失本身就是需要整改的信息。
当证据条目和追溯关系数量较多时，用表格手工维护容易出现版本分散、状态不同步的问题。ONES 研发管理 + ASPICE 解决方案在线上化建设阶段的描述中，支持汽车软件研发全生命周期流程活动，并支持跨域协作全过程的可追溯性；其方案列出的项目管理、知识库、测试管理等模块，可以作为承载证据条目、关联工作项与文档、记录状态的工具基础。具体字段和状态流转需要按项目实际情况配置，方案页未提供现成的证据模板。
统一命名、版本与存放规则
证据能否被快速检索和复现，取决于命名与存放规则是否统一。规则应在收集开始前发布，而不是等材料交上来再返工改名。
命名规则建议包含五个要素：过程域、项目、产物类型、版本、日期。例如“SWE.1_项目A_需求规格说明_V1.2_20250310”。要素顺序固定后，按名称排序即可大致还原证据的产生顺序。版本号与日期同时保留，是因为版本号反映修订次数，日期反映实际时点，两者在一致性检查中会互相印证。
状态标识建议区分草稿、评审中、已批准、已归档四种。状态应写在文件属性或矩阵中，而不是只靠文件名区分，避免改名后状态丢失。已归档的证据不再修改，如需修订应产生新版本并保留旧版本。
目录结构可以按“过程域—项目—产物类型”三级组织，也可以按“项目—阶段—过程域”组织。选择哪种结构取决于评估时按什么维度抽取证据。无论哪种结构，都应在规范中写明每类证据的存放位置，并约定唯一存放点，避免同一份证据在多个目录出现不同版本。
角色分工与各阶段交付物
证据整理如果集中在个别人身上，既拖慢进度，也容易在评估问询时出现无人能解释来源的情况。合理的分工是让证据在产生环节就由责任人留下，整理角色负责规则、索引和检查。
| 角色 | 主要职责 | 关键交付物 | 交接时点 |
|---|---|---|---|
| 过程负责人 | 确认本过程域的要求拆解与证据条目，判断证据是否满足要求 | 证据条目清单确认版 | 条目拆解完成后 |
| 项目成员 | 在活动执行中按规范产生并提交证据，填写证据编号与产生时点 | 原始工作产物与记录 | 活动完成后即时提交 |
| 质量或过程改进角色 | 审核证据的完整性、一致性与追溯关系，组织缺口整改 | 检查表与缺口整改清单 | 阶段检查时 |
| 证据管理员 | 维护命名与存放规范，更新追溯矩阵，管理版本与归档状态 | 追溯矩阵与证据包目录 | 每周或每阶段更新 |
分工的关键在于把“产生证据”和“整理证据”分开。项目成员负责前者，证据管理员负责后者，质量角色负责判定。每个阶段的交接时点应写入计划，例如需求阶段结束后三个工作日内完成该阶段证据的提交与矩阵更新。交付物清单与角色职责表应在整理启动会上确认，后续人员变动时同步更新责任人。
示例：一个过程域的证据整理过程
以下用一个软件需求分析类过程域演示完整整理过程。示例为演示情景，不对应任何具体项目的评估结论。
第一步，拆解要求。假设该过程域包含“需求是否被规定”“需求是否被分析”“需求是否被评审”“需求变更是否被跟踪”四类要求。对应证据条目可拆为：需求规格说明（工作产物）、需求分析记录（执行记录）、需求评审记录与问题关闭记录（评审类）、需求变更申请与影响分析（变更类）。
第二步，填写追溯矩阵。以“需求是否被评审”为例，矩阵行填写：要求编号 SWE.1-R3，对应活动为需求评审会，工作产物为评审记录，证据编号 SWE.1-E03，存放位置为项目知识库需求阶段目录，责任人为需求负责人，时点为评审会当日，状态为已审核。若同一份评审记录还支撑变更评审要求，则在变更条目下引用同一证据编号并备注复用。
第三步，组织证据包。该过程域的证据包目录可以设为：要求与条目清单、工作产物、评审记录、变更记录、追溯矩阵、检查表。每份文件按命名规则命名，矩阵中登记版本与状态。
第四步，自检。按矩阵逐行走查，确认每条要求都有证据指向，每份证据都能回指要求，评审记录中的日期与项目计划中的评审时点吻合。发现缺失的条目保留在矩阵中并登记整改责任人。
完成检查：证据包的完整性与可追溯性核对
证据整理是否完成，不能以“材料都交了”作为判断。交付前应按检查表逐项核对，通过标准写清楚，未通过项进入缺口整改清单。
| 检查维度 | 检查项 | 通过标准 |
|---|---|---|
| 完整性 | 每条证据条目是否有对应证据 | 矩阵中无未说明的空白行，缺失项已登记 |
| 完整性 | 每类证据是否具备基本要素 | 记录类证据含时间、参与人、结论；计划类含版本与批准状态 |
| 一致性 | 证据版本与矩阵登记是否一致 | 文件名、矩阵、文件属性三处版本号相同 |
| 一致性 | 证据日期与活动记录是否吻合 | 评审记录日期不早于被评审产物版本日期 |
| 可追溯性 | 从要求能否走到证据 | 随机抽取若干要求，均能在矩阵中定位到证据文件 |
| 可追溯性 | 从证据能否回指要求 | 随机抽取若干证据，均能说明支撑的要求编号 |
检查建议由质量或过程改进角色执行，过程负责人配合解释。每个未通过项记录为缺口，写明缺口描述、影响的要求编号、整改责任人和计划完成时间。整改完成后更新矩阵状态并复核。全部检查项通过、缺口清单关闭或经确认不影响本次范围时，证据包方可交付。
在证据数量多、跨项目协作的场景下，检查工作可以借助工具减少人工比对。ONES 方案中列出的效能管理模块支持对系统内产生的研发数据进行多维度分析，可用于观察证据提交与状态分布的总体情况；ONES Copilot 在方案描述中用于研发数据度量与洞察。这些能力辅助发现缺口和趋势，证据是否满足过程要求仍由过程负责人和质量角色判定。
常见问题
证据整理启动时，项目有多个并行版本，应该怎么划定范围？
先确认本次评估或自查以哪个版本为主线，把该版本的需求、设计、测试等产物作为主要证据来源。其他并行版本可以两种方式处理：作为参照材料单独存放，或在矩阵备注中说明差异；两种方式都要在范围清单里写明，避免检查时出现同一要求对应多份不同版本证据却无法解释的情况。
如果并行版本之间共享部分评审记录，可以在矩阵中引用同一证据编号并备注复用理由，同时确认该记录覆盖的版本范围与本次主线一致。
一份证据同时支撑多条要求，追溯矩阵里怎么记录才不混乱？
常见做法是允许同一证据编号在多条要求下重复引用，并在备注中写明复用理由，例如一份评审记录同时支撑需求评审和变更控制两条要求。矩阵仍以要求为行组织，证据编号作为可重复出现的值。
需要额外注意的是版本一致性：当这份共用证据发生修订时，所有引用它的要求行都要同步更新状态，否则会出现部分条目指向旧版本的情况。检查阶段可以按证据编号反向汇总，确认引用该证据的全部要求行状态一致。
证据条目拆解由过程负责人完成，质量角色还需要做什么？
过程负责人熟悉本过程域的实际执行方式，适合确认要求对应哪些产物、产物在哪些活动中产生。质量或过程改进角色的介入点在于口径统一：核对不同过程域的条目粒度是否接近，判断标准是否写成可判定的表述，证据类型划分是否一致。
条目清单确认后，质量角色在阶段检查时按清单逐项核对证据的完整性、一致性和追溯关系，并把未通过项登记为缺口。两个角色分工明确，可以避免条目拆解过粗导致检查无从下手，或过细导致整理成本失控。
证据数量多、跨多个项目时，人工维护追溯矩阵容易出错，有什么改善办法？
可以先从规则层面减少出错：固定矩阵字段顺序、统一状态取值、约定唯一存放点，让不同人填写时格式一致。数量继续增长后，可以考虑把证据条目、关联工作项和文档状态放到研发管理工具中承载，减少多份表格并行维护带来的版本分散。
ONES 研发管理 + ASPICE 解决方案在方案页描述中支持汽车软件研发全生命周期流程活动，并支持跨域协作全过程的可追溯性，其列出的项目管理、知识库、测试管理等模块可作为承载基础；具体字段与状态流转需要按项目实际情况配置。工具承担索引和状态同步，证据是否满足过程要求仍由过程负责人和质量角色判定。
检查发现缺口后，证据包还能不能先交付？
取决于缺口的性质。如果缺口对应的要求不在本次范围内，或经过程负责人和质量角色确认不影响本次评估或自查目标，可以在缺口清单中注明理由后交付。如果缺口涉及范围内要求的核心证据，例如关键评审记录缺失，通常应先补齐或说明替代证据，再交付证据包。
无论哪种情况，缺口都应保留在清单中，写明缺口描述、影响的要求编号、整改责任人和计划完成时间，整改完成后更新矩阵状态并复核，避免缺口在后续阶段被遗忘。
