ASPICE评估准备中，证据清单常被当作一份“要交什么文档”的目录，真正影响评估效率的是它能否与研发过程活动逐项对应。做法是建立“过程活动—工作产物—证据条目”三层映射，让每项活动都能找到应产出的证据，每条证据也能回溯到具体活动。本文按编制步骤、字段模板、角色分工、填写示例和完成检查展开，并说明如何借助ONES承载活动与证据的关联和核验跟踪。
要点总览（TL;DR）
- 证据清单与研发活动对应的核心是三层映射：过程活动层确定要做哪些事，工作产物层确定应留下什么，证据条目层确定评估时查什么、在哪里查。
- 编制按五步推进：圈定评估范围与过程域、识别工作产物、拆解证据条目、标注负责人与时点存放位置、建立双向索引，每步都有可判断的完成标志。
- 证据条目至少写清编号、对应活动与产物、证据类型、责任角色、产生时点、存放位置与版本、核验状态，核验状态让清单从静态目录变成逐项关闭缺口的工具。
- 项目管理层、过程负责人、活动执行者、质量或评估准备角色分工明确，证据随活动交付同步产出，核验安排在阶段节点，缺口在下一阶段前关闭。
- 清单可用性用六项检查判断：活动覆盖与评估范围一致、每项活动至少一项证据、证据可定位可核验、双向索引完整、责任人与时点明确、更新维护机制已定义。
先确定映射的三层结构：过程活动、工作产物、证据条目
证据清单与研发活动对应的基本结构是三层：过程活动层回答“按评估范围要做哪些事”，工作产物层回答“做完这件事应留下什么”，证据条目层回答“评估时具体查什么、在哪里查”。三层逐级细化，形成一条从活动到证据的链路；反向查询时，从任一证据条目可以回到它所属的产物和活动。
三层之间是分解关系，不是并列关系。一项活动通常对应一个或多个工作产物，一个工作产物再拆成若干可独立检查的证据条目。例如“需求分析”是一项活动，工作产物包括需求规格说明和需求评审记录，证据条目则可能是需求规格说明的版本、需求与上游输入的追溯关系、评审结论及问题关闭记录。
| 层级 | 定义 | 必填字段 | 填写要求 |
|---|---|---|---|
| 过程活动层 | 评估范围内选定的过程域及其具体活动 | 过程域编号与名称、活动编号、活动名称、适用项目或项目类型 | 活动粒度以能明确对应产物为准，过粗会导致产物遗漏，过细会增加维护量 |
| 工作产物层 | 活动执行中应产生或更新的工作产物 | 产物编号、产物名称、产物类型、产生阶段 | 区分“应产生”和“应更新”，避免只列新文档而漏掉变更记录 |
| 证据条目层 | 产物中可被检查的具体证据单元 | 证据编号、证据名称、证据类型、责任角色、产生时点、存放位置、核验状态 | 一条证据只对应一个可判断的检查点，便于逐项核验 |
追溯方向要在结构设计时就确定。正向索引用于评估准备：从活动清单出发，逐项确认证据是否齐备。反向索引用于评估现场：评估人员抽到一条证据时，能立即说明它来自哪项活动、由谁在什么时点产出。两个方向共用同一套编号，编号规则应在建表前统一，避免后续靠人工记忆关联。
按活动逐项编制证据清单的操作步骤
编制过程按五个步骤推进，每一步都有明确输入、动作、输出和完成标志。建议先在一个过程域内跑通全流程，确认字段和粒度合适后再扩展到其他过程域。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步：圈定评估范围与过程域 | 评估目标、评估模型范围、项目清单、组织过程定义 | 确定本次覆盖的过程域和能力等级，把每个过程域拆到可执行的活动，形成活动清单 | 活动清单（含过程域编号、活动编号、适用项目） | 活动清单经项目管理层确认，范围与评估委托一致 |
| 第二步：识别工作产物 | 活动清单、组织过程定义中的产物要求、现有项目文档 | 为每项活动列出应产生或更新的产物，标注产物类型和产生阶段 | 活动—产物对照表 | 每项活动至少对应一个产物，无产物活动已说明原因 |
| 第三步：拆解证据条目并定义属性 | 活动—产物对照表、产物模板、历史项目样本 | 把每个产物拆成可独立检查的证据条目，定义证据类型、责任角色、产生时点 | 证据条目清单 | 每条证据可通过“有/无、符合/不符合”判断，不依赖主观描述 |
| 第四步：标注负责人、时点与存放位置 | 证据条目清单、项目组织架构、文档库结构 | 为每条证据指定责任角色、产生时点和存放位置，明确版本标识方式 | 带责任与位置信息的完整清单 | 每条证据都能定位到具体角色和具体位置，无“待定”项 |
| 第五步：建立双向索引 | 完整清单 | 按活动编号和证据编号建立双向查询关系，检查是否存在孤立证据或无证据活动 | 可双向查询的映射表 | 从任一活动可列出全部证据，从任一证据可回溯到活动 |
第三步的拆解粒度最容易出问题。拆得过粗，一条证据包含多个检查点，核验时无法判断部分满足；拆得过细，清单条目膨胀，维护成本超过收益。一个实用的判断标准是：如果一条证据在评估现场需要由不同角色分别说明，就应拆开；如果始终由同一角色一次说明，可以合并。
证据条目要写清哪些字段
证据条目的字段设计目标是让清单可填写、可核验、可维护。字段不必多，但每个字段都要在核验时用得上。下表给出建议模板，企业可结合自身过程定义增减。
| 字段 | 填写说明 | 示例 |
|---|---|---|
| 证据编号 | 按“过程域-活动-序号”规则编制，全表唯一 | SWE.1-02-03 |
| 证据名称 | 描述可检查的具体内容，避免只写文档名 | 需求评审问题关闭记录 |
| 对应过程域与活动 | 填写过程域编号和活动编号，与活动清单一致 | SWE.1 需求分析 / 活动02 需求评审 |
| 对应工作产物 | 填写产物编号和名称 | WP-012 需求评审记录 |
| 证据类型 | 文档、记录、评审结论、追溯关系、变更记录等 | 记录 |
| 责任角色 | 产出该证据的角色，写到岗位而非个人 | 需求负责人 |
| 产生时点 | 活动中的哪个节点产出，可写阶段或里程碑 | 需求评审会后三个工作日内 |
| 存放位置与版本标识 | 文档库路径或系统位置，注明版本规则 | 项目文档库/需求/评审记录，按评审轮次编号 |
| 核验状态 | 未核验、已核验、缺失、不适用，附核验人和日期 | 已核验，2024-05-10 |
| 备注 | 记录裁剪说明、替代证据或待补事项 | 本项目采用合并评审，替代证据见SWE.1-02-05 |
“核验状态”字段是清单从编制走向使用的关键。没有状态跟踪，清单只是一份静态目录；有了状态，评估准备就变成逐项关闭缺口的过程。“备注”字段用于记录裁剪和替代关系，评估时能解释为什么某条证据不适用或以其他形式存在。
角色分工与各环节交付物
清单能否持续可用，取决于编制、产出、核验三类职责是否清晰。常见问题是过程负责人编完清单就交给项目，项目执行者不知道哪些活动要留证据，评估前才发现缺口集中暴露。
| 角色 | 职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 项目管理层 | 确认评估范围、过程域覆盖和资源投入 | 评估范围确认单、活动清单审批结论 | 编制启动前 |
| 过程负责人 | 维护活动与证据的映射关系，定义产物和证据条目，处理裁剪申请 | 三层映射表、字段规范、裁剪记录 | 项目启动时发布，过程变更时更新 |
| 活动执行者 | 在活动执行中同步产出证据，按字段要求命名和存放 | 工作产物及对应证据条目 | 活动完成时，随活动交付同步提交 |
| 质量或评估准备角色 | 按清单逐项核验证据完整性和可定位性，跟踪缺口关闭 | 核验记录、缺口清单、关闭状态报告 | 阶段节点核验，评估前完成全量核验 |
交接时点决定证据能否在活动中自然产生。活动执行者的证据提交应与活动交付合并，避免活动结束后补做记录；质量角色的核验应安排在阶段节点，使缺口在下一阶段开始前关闭，而不是集中到评估前处理。
当项目数量较多、证据分散在多个团队时，映射表和核验状态需要集中承载。ONES 研发管理 + ASPICE 解决方案的线上化建设阶段支持汽车软件研发全生命周期流程活动和跨域协作全过程的可追溯性，可用于把活动、工作产物与证据条目关联起来，并在同一平台跟踪核验状态；具体落地范围需按企业流程裁剪确认。
一个映射示例：从过程活动到证据条目
以下示例选取“需求分析”过程域中的“需求评审”活动，演示映射表的填写方式。示例为演示情景，过程域编号和活动划分需以企业采用的评估模型和组织过程定义为准。
该活动的工作产物为需求评审记录和评审问题清单。拆解后的证据条目及字段填写如下：
| 证据编号 | 证据名称 | 对应活动 | 工作产物 | 证据类型 | 责任角色 | 产生时点 | 存放位置 | 核验方式 |
|---|---|---|---|---|---|---|---|---|
| SWE.1-02-01 | 评审计划与参与人记录 | SWE.1 活动02 需求评审 | WP-012 需求评审记录 | 记录 | 需求负责人 | 评审会前 | 项目文档库/需求/评审 | 检查计划是否覆盖评审对象、参与角色是否齐全 |
| SWE.1-02-02 | 评审检查单及逐条结论 | SWE.1 活动02 需求评审 | WP-012 需求评审记录 | 记录 | 评审主持人 | 评审会中 | 项目文档库/需求/评审 | 抽查检查项是否有明确结论，结论与需求条目可对应 |
| SWE.1-02-03 | 评审问题关闭记录 | SWE.1 活动02 需求评审 | WP-013 评审问题清单 | 记录 | 需求负责人 | 评审会后三个工作日内 | 项目文档库/需求/问题 | 核对每个问题有责任人、关闭结论和关闭日期 |
| SWE.1-02-04 | 评审后需求基线版本 | SWE.1 活动02 需求评审 | WP-011 需求规格说明 | 文档 | 配置管理员 | 问题关闭后 | 配置库/需求基线 | 检查基线版本号与评审结论一致，变更可追溯 |
填写时注意两点：证据名称描述的是可检查的内容，例如“问题关闭记录”而不是“问题清单”；核验方式写成具体动作，让核验人知道看什么、判断什么。示例的适用边界在于，它假设组织已定义需求评审的入口出口准则；若企业采用合并评审或异步评审，证据条目需相应调整，并在备注中记录替代关系。
完成检查：映射清单是否可用
清单编制完成后，用以下检查项逐条判断。全部通过，说明清单可以支撑评估准备；存在未通过项，应先修正再进入核验阶段。
| 检查项 | 判断标准 | 通过标志 |
|---|---|---|
| 活动覆盖与评估范围一致 | 活动清单中的过程域和活动与评估委托范围逐项比对 | 无范围外活动，无遗漏过程域 |
| 每项活动至少对应一项证据 | 逐项检查活动—证据对照关系 | 无证据活动为零，或已有书面裁剪说明 |
| 证据条目可定位、可核验 | 随机抽取若干条目，按存放位置实际查找 | 抽查条目均能在标注位置找到，且能做出符合性判断 |
| 双向索引完整 | 从活动查证据、从证据查活动各抽查若干条 | 两个方向均能完整回溯，无孤立证据 |
| 责任人与时点明确 | 检查每条证据的责任角色和产生时点字段 | 无空白项，角色为岗位而非个人 |
| 更新与维护机制已定义 | 确认过程变更、项目裁剪、证据替代时的更新规则和责任人 | 有明确的更新触发条件和维护责任人 |
最后一项常被忽略。评估准备往往跨越数月，过程定义、项目范围和证据形式都可能变化；若清单没有更新机制，评估时会出现清单与实际执行脱节。建议把清单更新纳入过程变更流程，由过程负责人统一维护，并在每次阶段核验后同步核验状态。
常见问题
评估范围在准备过程中调整了，证据清单怎么跟着改？
先判断调整属于哪一类：过程域增减、活动粒度变化，还是项目适用范围变化。过程域增减时，在活动清单中增删对应条目，并同步检查这些活动关联的工作产物和证据条目，避免留下孤立证据。活动粒度变化时，重点复核证据条目的拆解是否仍然成立，必要时合并或拆分条目。项目适用范围变化时，更新活动清单中的适用项目字段，并确认新增项目的证据存放位置已纳入清单。
每次调整后重新跑一遍双向索引检查，确认从活动能查到证据、从证据能回到活动。调整记录建议保留在清单的变更说明中，评估时可用于解释范围口径。
项目对某些活动做了裁剪，证据清单里怎么体现？
裁剪不等于删除条目。建议保留原活动与证据条目，在核验状态中标记为“不适用”，并在备注中写明裁剪依据、批准人和替代证据。这样评估时既能说明为什么没有该证据，也能展示裁剪经过了正式决策。
如果裁剪后由其他活动承担了等效目的，应在备注中写明替代关系，例如合并评审替代了单独评审，并指向替代证据的编号。裁剪记录由过程负责人统一维护，避免各项目自行删改导致清单口径不一致。
证据分散在多个团队和系统中，核验状态怎么统一跟踪？
关键是让核验状态只有一个权威来源。可以指定一张集中维护的映射表或一个统一平台承载证据条目和核验状态，各团队按字段要求提交证据位置和状态更新，质量或评估准备角色在此基础上做核验并回写结论。
证据本体可以留在原有文档库或系统中，清单只记录位置和版本标识，避免为了集中而搬运全部文件。ONES 研发管理 + ASPICE 解决方案的线上化建设阶段支持汽车软件研发全生命周期流程活动和跨域协作全过程的可追溯性，可用于把活动、工作产物与证据条目关联起来并在同一平台跟踪核验状态；具体落地范围需按企业流程裁剪确认。
评估前多久开始按清单做全量核验比较合适？
没有统一时限，取决于项目数量、证据缺口的历史情况和团队响应速度。一个可操作的安排是：在阶段节点做抽样核验，让缺口在日常执行中关闭；在评估前留出一段完整时间做全量核验，覆盖所有活动和证据条目。
如果历史项目常出现集中补记录的情况，应把全量核验提前，并把核验发现的缺口按责任角色分派、设定关闭日期。核验频率和提前量建议在清单的维护机制中写明，作为过程定义的一部分固定下来。
三层映射和追溯矩阵是一回事吗？
两者相关但用途不同。三层映射解决的是证据清单与研发活动的对应关系，回答“哪项活动应产出哪条证据、证据在哪里”。追溯矩阵通常用于描述需求、设计、测试等工作产物之间的上下游关系，回答“这个需求被哪个设计实现、被哪个用例覆盖”。
实践中两者可以共用编号体系：证据条目引用工作产物编号，追溯矩阵中的产物关系再与活动关联。这样评估时既能从活动查到证据，也能沿产物关系说明一致性。具体如何衔接，取决于企业已有的过程定义和工具配置。
