ASPICE证据清单的作用，是把分散在配置库、文档库和评审记录中的证据组织成一份可定位、可追溯、可评审的索引。它通常以“一条证据一行”的方式记录证据编号、对应过程域与实践、名称与类型、项目与基线版本、产生阶段与责任人、存放位置与权限、评审状态、追溯关系以及保留与更新信息。下面给出一份可直接复制的空白表格，并说明各字段的填法与维护方式。
要点总览（TL;DR）
- ASPICE证据清单以“一条证据一行”组织，核心字段覆盖识别信息、归属信息、内容信息、受控信息与追溯信息五类。
- 必填字段为证据编号、证据名称、证据类型、过程域、所属项目、责任人、存放位置、评审/批准状态八项，其余按项目裁剪并记录裁剪说明。
- 字段无法填写时统一使用“待产生”“不适用”“待确认”三种标注，避免留白导致评审时无法判断是遗漏还是有意裁剪。
- 清单本身是受控记录，需有独立版本号，在里程碑、基线发布和评估准备时打基线，项目收尾时冻结归档并更新存放位置。
- 证据数量增长到数百条、跨团队协作时，可用研发管理平台承载索引、评审状态与追溯关系，具体配置按项目采用的ASPICE版本确定。
可复制空白证据清单模板
将下表复制到 Excel、在线表格或文档工具中即可使用。第一行是表头，从第二行起每条证据占一行。表格按“识别信息—归属信息—内容信息—受控信息—追溯信息”的顺序排列字段，便于从左到右完成填写和检查。
| 证据编号 | 过程域 | 过程属性/实践 | 证据名称 | 证据类型 | 所属项目 | 基线/版本 | 产生阶段 | 责任人 | 存放位置 | 访问权限 | 评审/批准状态 | 上游追溯 | 下游追溯 | 保留期限 | 更新记录 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
如果项目证据数量较多，可以在表头之上增加一行清单元信息，记录清单名称、适用项目、对应ASPICE版本、清单版本号、编制人和最后更新日期。这行元信息不参与逐条证据的填写，只用于标识整份清单的身份。
字段说明：每个列填什么、怎么填
字段设计的共同目标是让阅读清单的人在不打开原件的情况下，判断这条证据是否存在、属于哪个过程、由谁负责、当前是否受控。下表逐列说明含义、取值来源和常见写法。
| 字段 | 含义 | 取值来源与填写方法 |
|---|---|---|
| 证据编号 | 证据在清单中的唯一标识 | 建议采用“过程域缩写-工作产品缩写-三位序号”，如“SWE1-SRS-001”。编号一经分配即固定，证据升版时沿用原编号，在版本字段体现变化 |
| 过程域 | 证据所属的ASPICE过程域 | 按项目采用的ASPICE版本和评估范围，从过程域清单中选取，如需求分析、软件架构设计、软件详细设计与单元构建等对应过程域 |
| 过程属性/实践 | 证据支撑的过程属性或具体实践 | 填写该证据主要支撑的过程属性编号或实践编号。一条证据支撑多个实践时，可在单元格内分行列出，或拆成多行并保持证据编号一致 |
| 证据名称 | 证据的可识别名称 | 使用与原件标题一致的名称，如“软件需求规格说明书”“单元测试报告”，避免只写“文档1”“记录A”这类无法定位的名称 |
| 证据类型 | 证据的形态分类 | 常见取值包括文档、记录、评审纪要、测试报告、配置项、工具截图、会议记录。类型决定后续的评审方式和保留要求 |
| 所属项目 | 证据产生的项目 | 填写项目正式名称或项目代号，与项目管理中的项目标识保持一致，便于跨项目检索 |
| 基线/版本 | 证据对应的基线或版本 | 填写证据纳入的基线名称或原件版本号，如“V1.2”“基线B2”。取值来自配置管理记录，与配置库中的版本标识一致 |
| 产生阶段 | 证据形成的研发阶段 | 按项目阶段划分填写，如需求阶段、设计阶段、实现阶段、测试阶段、发布阶段。取值来自项目计划中的阶段定义 |
| 责任人 | 对该证据内容和更新负责的人 | 填写角色加姓名，如“需求工程师 张某”。责任人负责证据的提交、更新和应答评审问题 |
| 存放位置 | 证据原件的定位信息 | 填写配置库路径、文档库页面地址或记录编号。只记录定位信息，不复制原件内容。路径应精确到文件或页面，避免只写到目录层级 |
| 访问权限 | 证据的可见与编辑范围 | 写明可读角色和可编辑角色，如“项目组可读，配置管理员可编辑”。涉及保密内容时注明访问审批方式 |
| 评审/批准状态 | 证据当前的受控状态 | 常见取值包括草稿、待评审、评审中、已批准、已基线、已作废。状态变化时同步更新更新记录字段 |
| 上游追溯 | 本证据所依据的上游工作产品 | 填写上游证据的编号，如需求规格对应的系统需求编号。多个上游用分号分隔 |
| 下游追溯 | 引用或派生自本证据的下游工作产品 | 填写下游证据编号，如设计文档对应的测试用例编号。上下游字段配合使用，形成双向可查的追溯链 |
| 保留期限 | 证据需要保存的时长 | 按项目质量要求或合同约定填写，如“项目结束后5年”“产品生命周期内”。没有明确约定时，在裁剪说明中记录确定依据 |
| 更新记录 | 该行最近一次变更的说明 | 填写日期加变更摘要，如“2025-03-10 状态由待评审改为已批准”。完整变更历史可另设变更日志表 |
过程域、过程属性与实践的编号体系随ASPICE版本不同而变化，填写时应以项目实际采用的版本和评估范围为准。清单只记录对应关系，不替代对过程本身的定义。
必填与选填：哪些字段不能空
必填字段的判断标准是：缺少该字段，证据就无法被定位、追溯或判断受控状态。其余字段按项目规模和评估要求裁剪，裁剪结论应写入清单的裁剪说明，便于评审时解释。
| 类别 | 字段 | 说明 |
|---|---|---|
| 必填 | 证据编号、证据名称、证据类型、过程域、所属项目、责任人、存放位置、评审/批准状态 | 这八项共同保证证据可识别、可找到、有人负责、状态明确。缺少任一项，清单就失去索引作用 |
| 条件必填 | 过程属性/实践 | 当清单用于支撑过程评估或内审时必填；仅作为项目内部资料索引时可暂不填写，但需在裁剪说明中注明 |
| 条件必填 | 基线/版本 | 证据已纳入配置管理或已基线时必填；处于草稿阶段且尚未纳入配置库时可标注“未基线” |
| 条件必填 | 上游追溯、下游追溯 | 当证据处于需求、设计、测试等存在明显派生关系的环节时必填；会议记录、培训记录等独立证据可标注“不适用” |
| 条件必填 | 访问权限 | 证据含保密信息或跨团队共享时必填；项目内部公开且权限统一的证据可填写默认权限说明 |
| 选填 | 产生阶段 | 适用于需要按阶段统计证据完整性的项目；小型项目阶段划分简单时可省略 |
| 选填 | 保留期限 | 适用于有合同约定或质量体系明确要求的项目；无明确要求时可统一在清单元信息中说明 |
| 选填 | 更新记录 | 适用于证据频繁变更的项目；变更较少时可由独立的变更日志承担 |
字段确实无法填写时，使用统一标注而不是留白：尚未产生填“待产生”，不适用于该证据填“不适用”，暂未确定填“待确认”并注明确认期限。三种标注的含义不同，混用会让评审人员无法判断是遗漏还是有意裁剪。
填写示例：一条完整证据记录
以下为演示情景中的一条记录，用于说明字段之间的对应关系，不代表任何真实项目或评估结果。
| 字段 | 填写内容 |
|---|---|
| 证据编号 | SWE1-SRS-003 |
| 过程域 | 软件需求分析 |
| 过程属性/实践 | 对应软件需求分析过程域中的需求规格化实践 |
| 证据名称 | 整车控制器软件需求规格说明书 |
| 证据类型 | 文档 |
| 所属项目 | VCU-SW-2025 |
| 基线/版本 | V1.2，基线B2 |
| 产生阶段 | 需求阶段 |
| 责任人 | 需求工程师 张某 |
| 存放位置 | 配置库 / VCU-SW-2025 / 需求 / SRS_V1.2.docx |
| 访问权限 | 项目组可读，需求组可编辑，外部访问需项目经理审批 |
| 评审/批准状态 | 已批准 |
| 上游追溯 | SYS2-SYSRS-007（系统需求规格说明书对应条目） |
| 下游追溯 | SWE2-ARCH-004（软件架构设计文档）；SWE4-TC-011（软件需求测试用例集） |
| 保留期限 | 项目结束后5年 |
| 更新记录 | 2025-03-10 状态由评审中改为已批准；2025-03-18 版本由V1.1升为V1.2 |
这条记录体现了几个填写要点。编号中的“SWE1”标识过程域，“SRS”标识工作产品类型，序号保证唯一；上游字段指向系统需求，下游字段同时指向架构设计和测试用例，形成从系统需求到软件需求再到验证的双向链路；状态字段与更新记录相互印证，评审通过和版本升级都能在清单中看到时间点。存放位置精确到文件，访问权限写清了读、写和例外审批三种情况。
调整与维护：清单如何随项目演进
证据清单在项目启动时建立，随阶段推进不断补充，在项目收尾时归档。维护工作的重点是让清单始终与配置库中的实际证据保持一致，避免出现清单有记录而原件已变更、或原件已产生而清单未登记的情况。
按项目裁剪字段与行
裁剪从字段和行两个层面进行。字段层面，小型项目可省略产生阶段和更新记录，把变更集中记录在清单元信息中；涉及跨团队交付的项目应保留访问权限和上下游追溯。行层面，按过程域分批建立证据行，每个阶段结束时补齐该阶段应产生的证据，尚未产生的行保留并标注“待产生”，作为阶段检查的输入。裁剪结论写入清单的裁剪说明，记录裁剪了哪些字段、原因和批准人。
清单版本与基线管理
清单本身也是受控记录，应有独立的版本号。建议在项目里程碑、基线发布和评估准备三个时点对清单打基线，基线后的修改通过新版本体现，旧版本保留可查。清单版本号与项目基线名称建立对应关系，例如“清单V3对应基线B2”，便于回答“某个基线当时包含哪些证据”。
定期评审与更新责任
责任人负责在证据状态变化时更新自己名下的行，过程负责人按阶段检查本过程域证据的完整性，配置管理员负责清单版本和存放位置的一致性。评审节奏可与项目阶段评审同步，评估准备期适当加密。
| 时点 | 维护动作 | 责任角色 | 产出 |
|---|---|---|---|
| 项目启动 | 建立清单元信息，按过程域预置证据行，标注“待产生” | 过程负责人、配置管理员 | 清单初版 |
| 阶段结束 | 补齐本阶段证据，核对存放位置与状态，处理“待确认”标注 | 证据责任人、过程负责人 | 更新后的清单行 |
| 基线发布 | 对清单打基线，记录版本与基线对应关系 | 配置管理员 | 清单基线版本 |
| 评估准备 | 全量核对必填字段，检查追溯链完整性，整理裁剪说明 | 过程负责人、质量人员 | 评估用清单快照 |
| 项目收尾 | 冻结清单，按保留期限归档，记录归档位置 | 配置管理员 | 归档清单及说明 |
归档与保留期限的处理
归档时冻结清单内容，不再修改行数据，后续如需补充说明另附归档说明文件。保留期限按项目约定执行，到期前由配置管理员发起处置评审，决定继续保留或销毁，处置结论记录在案。清单中的存放位置字段在归档后应更新为归档库路径，保证多年后仍能定位原件。
当证据数量增长到数百条、跨多个团队协作时，清单的版本同步、状态流转和追溯关系维护会占用较多人工。ONES 研发管理 + ASPICE 解决方案支持汽车软件研发全生命周期流程活动和跨域协作全过程的可追溯性，可作为承载证据索引、评审状态与追溯关系的研发管理平台；ONES Wiki 支持记录页面版本并查看与回滚，支持按角色配置读写权限，适合存放需要版本控制和权限区分的过程文档。具体字段配置和流程设置需结合项目采用的ASPICE版本与评估范围确定。
常见问题
证据清单里的“过程属性/实践”字段，项目不参加评估时还需要填吗？
可以暂不填写，但要在清单的裁剪说明中注明原因。该字段属于条件必填：清单用于支撑过程评估或内审时必填；仅作为项目内部资料索引时，可先保留列而不填值。后续如果项目进入评估准备，再按评估范围补填，补填时以项目实际采用的ASPICE版本和过程域编号体系为准。
同一条证据支撑多个实践，是拆成多行还是写在一个单元格里？
两种做法都可以，取决于清单的用途。如果清单主要用于评估时按实践检索，建议拆成多行并保持证据编号一致，便于筛选和统计；如果清单主要用于项目内部索引，可在一个单元格内分行列出多个实践编号。无论哪种方式，证据名称、存放位置和状态字段在各行之间应保持一致，避免同一证据出现互相矛盾的状态记录。
证据原件在配置库中升版了，清单需要同步改哪些字段？
至少同步三处：基线/版本字段更新为新版本号，更新记录字段追加日期和变更摘要，存放位置字段核对路径是否随版本变化。如果升版伴随评审状态变化，评审/批准状态字段也要同步。上下游追溯字段通常不需要改动，除非升版导致追溯关系调整。责任人应在升版完成后及时更新，避免清单记录与配置库实际版本脱节。
项目收尾归档后，清单里的存放位置还要维护吗？
需要。归档时清单内容冻结，但存放位置字段应更新为归档库路径，保证多年后仍能定位原件。后续如需补充说明，另附归档说明文件，不改动已冻结的行数据。保留期限到期前由配置管理员发起处置评审，决定继续保留或销毁，处置结论记录在案。
用表格工具维护清单和用研发管理平台承载，怎么选？
证据数量少、参与团队单一、变更不频繁时，表格工具足够，复制模板即可开始填写。当证据达到数百条、跨多个团队协作，版本同步、状态流转和追溯关系维护的人工成本明显上升，可考虑用研发管理平台承载。ONES 研发管理 + ASPICE 解决方案支持汽车软件研发全生命周期流程活动和跨域协作全过程的可追溯性，可作为承载证据索引、评审状态与追溯关系的平台；ONES Wiki 支持记录页面版本并查看与回滚，支持按角色配置读写权限，适合存放需要版本控制和权限区分的过程文档。具体字段配置和流程设置需结合项目采用的ASPICE版本与评估范围确定。
