ASPICE证据清单把每条基本实践与可核查的证据对应起来，是评估准备和项目自查的基础表格。本文提供一张可直接复制到表格工具中的空白清单，并逐字段说明填写口径、划分必填与选填、给出一份填好的示例，最后说明清单在项目推进中的维护与调整方法。表中的过程域和角色为演示情景，使用时请按项目实际裁剪。
要点总览（TL;DR）
- 空白清单按过程域分组，一行对应一条基本实践，字段覆盖过程域、过程组、基本实践编号、证据名称、证据类型、责任角色、产生时点、存放位置、版本、状态与评审记录。
- 必填字段以“能否定位、能否判断有效性、能否追溯责任人”为标准，过程域、基本实践编号、证据名称、责任角色、存放位置和状态固定保留，其余可按项目裁剪。
- 填写时证据名称写具体文件名或记录名，存放位置写到可打开的目录层级，状态统一使用“待产生、已产生、已评审、已归档”四类取值。
- 清单在阶段节点、里程碑评审前和变更发生后更新，裁剪的行标注原因后保留历史记录，清单本身纳入版本管理。
- 证据分散在多个空间时，可用研发管理平台统一登记文档、工作项与评审记录，字段配置和追溯范围按项目实际设置。
可复制空白证据清单表
下表为空白模板，复制到Excel、在线表格或需求管理工具后即可逐行填写。行结构按过程域分组，同一过程域下的基本实践连续排列，便于按域抽查。空白单元格保持可填写状态，不预填示例值，避免误用。
| 序号 | 过程域 | 过程组 | 基本实践编号 | 证据名称 | 证据类型 | 责任角色 | 产生时点 | 存放位置 | 版本 | 状态 | 评审/确认记录 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
填写提示：先按项目裁剪确定适用过程域，再为每条基本实践至少指定一项可打开、可追溯的证据；状态列建议统一使用“待产生、已产生、已评审、已归档”四类取值，避免各人自造状态词。
每个字段记录什么、怎么填
字段说明与空白表一一对应，填写时保持同一口径，示例值仅作格式参考。过程域、过程组与基本实践编号三者构成层级关系：过程域是评估范围中的能力域，过程组是该域内的实践分组，基本实践编号是评估时逐条核查的最小单位，一行只对应一条基本实践。
| 字段名 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 过程域 | 证据所属的能力域 | 使用项目裁剪后确认的过程域名称，全文统一写法 | 软件需求分析 |
| 过程组 | 过程域内的实践分组 | 按评估模型的分组名称填写，与过程域对应 | 需求获取与确认 |
| 基本实践编号 | 评估时逐条核查的实践标识 | 一行一条，编号与评估模型保持一致，不合并多条 | BP1 |
| 证据名称 | 能证明该实践已执行的产物名称 | 写具体文件名或记录名，能直接定位到内容 | 需求评审记录_2024Q2 |
| 证据类型 | 证据的载体类别 | 从项目约定的类型表中选取，如文档、记录、工作项、报告 | 评审记录 |
| 责任角色 | 负责产生该证据的岗位 | 写角色而非个人姓名，便于人员变动后仍可追溯 | 需求工程师 |
| 产生时点 | 证据应形成的时间节点 | 写阶段节点或里程碑，不写模糊的“项目过程中” | 需求基线建立前 |
| 存放位置 | 证据的实际存储路径 | 写到可打开的目录或空间层级，避免只写系统名称 | 项目库/需求/评审记录 |
| 版本 | 证据的版本标识 | 与文件自身版本一致，更新时同步修改 | V1.2 |
| 状态 | 证据当前所处的处理阶段 | 使用统一状态词，随进展更新 | 已评审 |
| 评审/确认记录 | 证明证据已被评审或确认的凭据 | 写评审记录编号、日期或确认人角色 | 评审单R-018，2024-05-16 |
| 备注 | 补充说明 | 记录裁剪原因、替代证据或待补事项 | 按项目裁剪，暂用会议纪要替代 |
证据名称与证据类型容易混淆：名称回答“是哪一份东西”，类型回答“它属于哪一类载体”。责任角色与产生时点配合使用，前者说明谁负责，后者说明在哪个节点前必须完成，两者共同构成可追责的时间约束。存放位置、版本与状态三项决定证据能否被快速找到并判断有效性，填写时应写到可直接打开和核对的粒度。
必填项与选填项的划分
必填项的判断标准是：缺少该字段后，证据无法被定位、无法判断有效性或无法追溯责任人。满足这一标准的字段在清单中固定保留，其余字段可按项目规模和评估范围裁剪。
| 类别 | 字段 | 理由或适用情形 |
|---|---|---|
| 必填 | 过程域、过程组、基本实践编号 | 缺少任一项，证据无法与评估条目对应 |
| 必填 | 证据名称 | 没有具体名称，证据无法被找到 |
| 必填 | 责任角色 | 缺少责任人，证据缺失时无法追补 |
| 必填 | 存放位置 | 缺少路径，抽查时无法打开核对 |
| 必填 | 状态 | 无法判断证据是否已产生、已评审 |
| 选填 | 证据类型 | 项目证据种类单一时可省略，种类多时建议保留以便分类抽查 |
| 选填 | 产生时点 | 小型项目节点少时可并入备注，多阶段项目建议保留 |
| 选填 | 版本 | 证据更新频繁时必填，一次性记录可省略 |
| 选填 | 评审/确认记录 | 涉及评审类实践时必填，其余实践可按需填写 |
| 选填 | 备注 | 用于记录裁剪原因和替代证据，按需使用 |
裁剪规则按两条线执行：一是项目等级，评估范围较小的项目可减少过程域数量，但保留的过程域内必填字段不减少；二是过程域特性，评审、确认、追溯类实践对评审记录字段要求更严，应将其从选填提升为必填。发现必填项缺失时，先补登证据或标注“待补”并指定责任人和补登期限，不允许留空通过评审。
一份填好的证据清单示例
以下示例取自一个演示项目：某车型软件项目在需求阶段开展自查，选取三个过程域填写清单。表中角色、路径和编号均为演示情景，实际使用时替换为项目真实信息。
| 序号 | 过程域 | 过程组 | 基本实践编号 | 证据名称 | 证据类型 | 责任角色 | 产生时点 | 存放位置 | 版本 | 状态 | 评审/确认记录 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 软件需求分析 | 需求获取与确认 | BP1 | 需求评审记录_2024Q2 | 评审记录 | 需求工程师 | 需求基线建立前 | 项目库/需求/评审记录 | V1.2 | 已评审 | 评审单R-018，2024-05-16 |
| 2 | 软件需求分析 | 需求获取与确认 | BP2 | 需求变更影响分析表 | 分析记录 | 需求工程师 | 变更评审前 | 项目库/需求/变更 | V1.0 | 已产生 | 变更单C-006，2024-05-20 |
| 3 | 软件需求分析 | 需求追溯 | BP3 | 需求与测试用例追溯矩阵 | 工作项关联 | 系统工程师 | 测试计划评审前 | 需求管理空间/追溯视图 | V2.1 | 已评审 | 追溯评审纪要M-011，2024-06-03 |
| 4 | 软件详细设计 | 设计实现 | BP1 | 详细设计说明书 | 文档 | 软件设计师 | 编码启动前 | 项目库/设计/详细设计 | V1.3 | 已评审 | 设计评审单D-009，2024-06-12 |
| 5 | 软件详细设计 | 设计实现 | BP2 | 设计单元与需求对应表 | 工作项关联 | 软件设计师 | 设计基线建立时 | 需求管理空间/设计关联 | V1.0 | 已产生 | 待评审，计划2024-06-20 |
| 6 | 软件单元验证 | 测试执行 | BP1 | 单元测试报告 | 报告 | 测试工程师 | 单元测试完成后 | 测试空间/单元测试/报告 | V1.1 | 已归档 | 测试评审单T-014，2024-06-28 |
示例中每行证据名称都对应一条基本实践，状态与评审记录相互印证：状态为“已评审”的行均有对应的评审单或纪要编号，状态为“已产生”的行在评审记录中写明待评审计划。抽查时从任一行出发，沿存放位置打开文件、核对版本，再对照评审记录确认时间与结论，即可完成一次完整的可追溯性检查。
清单的维护、评审与版本调整
清单由项目质量负责人或过程改进负责人维护，各过程域的责任角色负责本域证据的登记与更新。建议在阶段节点、里程碑评审前和变更发生后三个时点更新，更新内容包括新增证据、补充评审记录和状态变更，每次更新在备注中记录变更原因和日期。
证据补充与状态变更应保留痕迹：状态从“待产生”变为“已产生”时填写实际存放位置和版本；变为“已评审”时补登评审记录编号。评审时按过程域分层抽查，每个过程域抽取若干行，从清单出发打开证据、核对版本、比对评审记录，再反向从评审记录回查清单是否登记，双向核对能发现漏登和错登。
过程域裁剪或项目范围变更后，先在清单中标注被裁剪的行及原因，保留历史记录而非直接删除；新增过程域时按空白模板追加行，并同步更新必填字段。清单本身也应纳入版本管理，每次整体调整形成新版本号，旧版本归档备查。
当证据分散在需求、设计、测试等多个空间时，清单的登记与评审流转可以借助研发管理平台承载。ONES 支持汽车软件研发全生命周期流程活动，并提供跨域协作全过程的可追溯性，其方案模块包括项目管理、知识库、测试管理与效能管理等，可用于把证据对应的文档、工作项和评审记录放在同一体系中登记和查询。具体字段配置和追溯范围需结合项目实际设置，平台承载的是管理动作，清单的裁剪与填写口径仍由项目团队确定。
常见问题
项目刚开始，很多证据还没产生，清单应该怎么填？
先填结构，再填状态。把适用的过程域和基本实践逐条登记，证据名称可以写计划产生的产物名称，状态统一填“待产生”，责任角色和产生时点必须填实，便于到期检查。证据实际形成后再补存放位置、版本和评审记录。这样清单在项目早期就能作为检查表使用，而不是等到评估前才集中补录。
一条基本实践有多份证据时，是合并一行还是拆成多行？
建议拆成多行，每行一份证据，基本实践编号重复填写。合并成一行会让存放位置和版本字段无法准确对应，抽查时难以判断哪份证据缺失。拆行后可以在备注中标注主证据与辅助证据，评审时优先核对主证据，辅助证据按需抽查。
清单里的状态和评审记录由谁更新，怎么避免长期不更新？
由各过程域的责任角色更新本域行，项目质量负责人或过程改进负责人定期汇总核对。把更新动作绑定到已有节点上更容易执行，例如阶段评审前必须完成本阶段证据的状态更新，变更关闭时同步更新受影响的行。核对时重点看状态为“已产生”但长期没有评审记录的行，这类行往往意味着评审环节被跳过。
用表格工具维护清单和放到研发管理平台里登记，怎么选？
证据数量少、参与角色单一的项目，表格工具足够，复制模板即可开始。证据分散在需求、设计、测试多个空间，且需要频繁核对版本与评审记录时，放到研发管理平台更便于查询和追溯。ONES 支持汽车软件研发全生命周期流程活动，并提供跨域协作全过程的可追溯性，方案模块包括项目管理、知识库、测试管理与效能管理等，可把证据对应的文档、工作项和评审记录放在同一体系中登记。具体字段配置和追溯范围需结合项目实际设置。
评估前发现必填项缺失，临时补记录可以吗？
可以补登，但要区分补登和补造。证据本身已存在、只是清单漏登的，补登名称、位置和版本即可；证据确实未产生的，应如实标注缺失并说明原因和后续措施，不宜事后补做记录充数。评估关注的是过程是否真实执行，补造记录在时间线和评审关联上容易出现矛盾，反而增加风险。
