ASPICE评估证据准备的核心，是把散落在项目经理、需求工程师、测试人员和过程工程师手中的工作产品，整理成可追溯、可核验的证据链。这份清单按“范围确认—分阶段检查—追溯核查—就绪判定”的顺序组织，每项写明通过标准、证据形式、负责人和阻断标记，适用于评估范围确定后启动、正式评估前完成全部阻断项的阶段。在证据留存与追溯环节，ONES可作为承载需求、任务、测试与文档的研发管理平台，帮助团队让证据随工作项状态自然沉淀。
要点总览（TL;DR）
- 这份清单在评估范围确定后启动使用，正式评估前必须完成全部阻断项清零，评估前两周做最后一轮复核。
- 检查维度覆盖范围与证据目录、计划与需求、设计与实现、测试与验证、双向追溯、通过标准与负责人、阻断项判定七个部分。
- 通过标准要写成可判断完成或未完成的表述，写明对象、数量范围和可核对位置，避免“基本完善”这类模糊说法。
- 追溯断链、关键工作产品缺失、评审记录缺失、配置版本不一致、已关闭问题缺少验证证据，通常列为阻断项。
- 就绪判定由评估协调人发起，项目经理和各过程域负责人共同确认，形成书面结论后再进入正式评估。
谁在什么时点使用这份清单
这份清单服务于评估准备，不替代过程定义文件本身。过程定义回答“应该怎么做”，项目计划回答“这个项目打算怎么做”，清单只回答一个问题：按定义和计划应当产生的工作产品，是否真实存在、内容完整、彼此对得上，并且能在评估时按需调取。
使用对象与职责分工如下表。评估协调人负责组织和汇总，各过程域负责人对本域证据的真实性和完整性负责，项目经理提供项目层面的计划和状态证据，质量/过程工程师负责核对证据与过程定义的一致性。
| 角色 | 主要职责 | 介入时点 |
|---|---|---|
| 评估协调人 | 确定评估范围与证据目录，汇总检查结果，组织就绪判定 | 范围确定后即介入，贯穿全程 |
| 项目经理 | 提供项目计划、估算、资源安排、项目状态与变更记录 | 计划与需求阶段检查开始前 |
| 各过程域负责人 | 按本域检查项准备证据，标注缺口并组织补齐 | 分阶段检查启动时 |
| 质量/过程工程师 | 核对证据与过程定义、模板要求的一致性，执行抽样复核 | 各阶段检查完成后 |
时点上建议分三段：评估范围确定后一周内完成证据目录确认；正式评估前四到六周完成分阶段检查和追溯核查；评估前两周完成阻断项清零和最后一轮复核。具体周期按项目规模和评估范围调整，但阻断项必须在正式评估开始前关闭。
评估范围与证据目录确认
准备工作的第一步是把范围定死。范围不清，后续收集的证据可能覆盖了错误的过程域，或者遗漏了本次评估要求的能力等级。确认结果应形成一份书面记录，由评估协调人和项目经理共同确认。
需要确认的内容包括四项：本次评估覆盖的过程域清单；每个过程域要求达到的能力等级；按过程域列出的应产生工作产品清单；样本项目和样本迭代的选取口径，例如按项目类型、交付阶段或时间窗口选取，并说明选取理由。
| 确认项 | 通过标准 | 证据形式 | 负责人 |
|---|---|---|---|
| 过程域与能力等级范围 | 形成书面范围说明，逐项列出过程域与目标等级，经项目经理确认 | 范围确认记录 | 评估协调人 |
| 工作产品清单 | 每个过程域至少列出一份应产生的工作产品，并与过程定义中的模板对应 | 证据目录表 | 各过程域负责人 |
| 证据形式定义 | 每项工作产品标明是文档、记录、工具数据还是评审记录，存放位置明确 | 证据目录表 | 质量/过程工程师 |
| 样本选取口径 | 样本项目和迭代的选取规则书面化，样本数量满足评估覆盖要求 | 样本选取说明 | 评估协调人 |
证据目录确认后应冻结版本。后续如需增补，走变更记录，避免不同角色按不同版本目录准备，造成重复劳动或遗漏。
计划与需求阶段的证据检查项
计划与需求阶段的证据决定整条证据链的起点是否可靠。这一阶段最常见的缺口是计划缺少估算依据、需求评审记录只有结论没有意见处理过程、需求变更没有回写到计划。
| 检查项 | 通过标准 | 证据形式 | 负责人 | 阻断 |
|---|---|---|---|---|
| 项目计划 | 计划覆盖范围、进度、资源、风险，经评审并有批准记录 | 计划文档、评审记录 | 项目经理 | 是 |
| 估算依据 | 估算方法、输入和结果可查，与计划中的工作量对应 | 估算记录 | 项目经理 | 否 |
| 资源与职责分配 | 每个角色有明确职责，人员分配与计划一致 | 职责矩阵、资源计划 | 项目经理 | 否 |
| 需求获取与分析 | 需求来源可追溯，分析结果形成基线 | 需求文档、基线记录 | 需求负责人 | 是 |
| 需求评审 | 评审有参加人、检查项、发现问题和处理结论 | 评审记录 | 需求负责人 | 是 |
| 需求变更 | 每次变更记录影响分析、批准人和受影响工作产品 | 变更记录 | 需求负责人 | 是 |
| 需求与计划一致性 | 需求范围变化后，计划中的任务、进度和资源有对应更新 | 计划修订记录 | 项目经理 | 否 |
一致性检查的做法是抽取若干条已变更需求，核对计划中是否有对应的任务调整和进度更新。若变更只停留在需求文档，计划仍是旧版本，说明变更影响分析没有闭环。
设计、实现与集成阶段的证据检查项
这一阶段的证据要能说明设计如何落到实现、实现如何按顺序集成为可测试的整体。检查重点是设计评审是否覆盖了需求、集成顺序是否有依据、配置项版本是否一致。
| 检查项 | 通过标准 | 证据形式 | 负责人 | 阻断 |
|---|---|---|---|---|
| 设计工作产品 | 设计文档覆盖需求分配，接口和约束有说明 | 设计文档 | 设计负责人 | 是 |
| 设计评审 | 评审记录包含检查项、问题清单和关闭状态 | 评审记录 | 设计负责人 | 是 |
| 实现工作产品 | 代码或实现产物与设计对应，版本可识别 | 代码库记录、版本标签 | 开发负责人 | 是 |
| 集成顺序 | 集成顺序有书面依据，与设计和依赖关系一致 | 集成计划 | 集成负责人 | 否 |
| 集成结果 | 每次集成有执行记录和结果判定 | 集成记录 | 集成负责人 | 是 |
| 集成问题处理 | 集成中发现的问题有记录、责任人和关闭结论 | 问题记录 | 集成负责人 | 否 |
| 配置项标识与版本一致性 | 纳入配置管理的项有唯一标识，评估样本的版本与记录一致 | 配置管理记录 | 配置管理员 | 是 |
版本一致性建议用抽样方式核对：从评估样本中选三到五个配置项，比对设计文档、实现产物和测试记录引用的版本号是否一致。出现版本错位时，先确认是记录引用错误还是实际交付了错误版本，两种情况处理方式不同。
测试、验证与问题处理的证据检查项
测试证据是否充分，判断标准是能否从测试结果反推回需求与设计，并说明每个问题从发现到关闭的完整过程。只有测试报告结论、没有用例和执行记录，通常不足以支撑验证活动的证据要求。
| 检查项 | 通过标准 | 证据形式 | 负责人 | 阻断 |
|---|---|---|---|---|
| 测试计划 | 测试范围、策略、环境和准入准出条件明确 | 测试计划 | 测试负责人 | 是 |
| 测试用例 | 用例与需求或设计条目对应，有预期结果 | 用例库 | 测试负责人 | 是 |
| 测试执行记录 | 每次执行有日期、执行人、实际结果和判定 | 执行记录 | 测试负责人 | 是 |
| 验证活动对应关系 | 验证活动能对应到具体需求或设计条目，覆盖情况可统计 | 验证矩阵 | 质量/过程工程师 | 否 |
| 问题记录与跟踪 | 问题有唯一编号、严重度、责任人和状态流转记录 | 问题跟踪记录 | 测试负责人 | 是 |
| 问题关闭证据 | 关闭前有修复验证记录，关闭结论有依据 | 验证记录 | 测试负责人 | 是 |
| 回归与变更后重新验证 | 变更影响到的测试项有回归执行记录 | 回归记录 | 测试负责人 | 否 |
判断证据充分性可以用一个简单方法：随机抽取若干条已关闭问题，检查能否还原“发现—分析—修复—验证—关闭”的完整链条。链条中断在任一环节，该问题的关闭证据就不充分。
双向追溯与一致性检查
追溯是横向贯穿各阶段的检查维度，单独核查的原因是：各阶段内部证据齐全，追溯关系仍可能断裂。追溯链应覆盖需求到设计、设计到实现、实现到测试的正向关系，以及测试结果回到需求的逆向关系。
| 检查项 | 通过标准 | 证据形式 | 负责人 | 阻断 |
|---|---|---|---|---|
| 需求—设计追溯 | 每条需求至少对应一项设计条目，无孤立需求 | 追溯矩阵 | 需求负责人 | 是 |
| 设计—实现追溯 | 设计条目能定位到实现产物，实现产物有设计来源 | 追溯矩阵、版本记录 | 开发负责人 | 是 |
| 实现—测试追溯 | 测试用例覆盖实现的功能点，覆盖缺口有说明 | 追溯矩阵、覆盖统计 | 测试负责人 | 是 |
| 逆向追溯 | 从测试结果可回溯到需求，失败项能定位影响范围 | 追溯矩阵 | 质量/过程工程师 | 否 |
| 变更后追溯更新 | 需求或设计变更后，追溯关系同步更新并有记录 | 变更记录、追溯矩阵版本 | 各过程域负责人 | 是 |
追溯断点的补齐方式取决于断点类型：缺少对应条目时补建关系并说明依据；条目存在但引用错误时修正引用并记录修正原因；变更后未更新时，先确认变更影响范围，再补齐受影响的追溯关系。补齐过程本身也应留痕，评估时能说明断点何时发现、如何修复。
在工具层面，ONES的ASPICE解决方案支持跨域协作全过程的可追溯性，需求、任务、测试与文档在同一平台内流转，追溯关系可随工作项状态更新而留存。团队可将追溯矩阵的维护动作嵌入日常研发流程，减少评估前集中补录的工作量。具体追溯对象的配置方式需结合实际环境确认。
每项检查的通过标准与证据负责人
通过标准的写法直接决定清单能否使用。合格的标准应当让两个不同的人检查同一项时得出相同结论。写法上遵循三条规则：写明对象和数量范围，例如“每条需求均有对应测试用例”；写明状态要求，例如“状态为已执行且有判定结果”；写明可核对的位置，例如“存放于配置库指定目录”。
以下对比说明模糊表述与可判断表述的差别：
| 模糊表述 | 可判断表述 |
|---|---|
| 需求文档基本完善 | 需求文档已基线，评审问题全部关闭或有延期批准记录 |
| 测试比较充分 | 评估样本内每条需求至少有一条已执行用例，执行记录含日期和判定 |
| 追溯关系已建立 | 追溯矩阵覆盖需求、设计、实现、测试四类对象，无孤立条目 |
负责人分配按“谁产生、谁负责”的原则：工作产品的作者或所属角色对该项证据负责，质量/过程工程师负责复核，评估协调人负责汇总。检查时点与分阶段安排对应，每阶段检查完成后由质量/过程工程师执行抽样复核，抽样比例可按证据数量确定，重点抽取变更频繁和跨团队交接的工作产品。
证据存放位置应统一：文档类进入配置库或知识库的指定目录，记录类按过程域归档，工具数据保留可查询的原始状态。命名规则在证据目录确认阶段一并定下，避免评估时因命名混乱找不到对应文件。
阻断项与评估就绪判定
阻断项指未通过即不具备进入正式评估条件的检查项。通常列为阻断项的有：关键工作产品缺失，例如项目计划、需求基线、测试计划；评审记录缺失或只有结论没有过程；追溯链存在未修复的断点；配置项版本与记录不一致；已关闭问题缺少验证证据。
| 判定项 | 就绪条件 | 确认方式 |
|---|---|---|
| 阻断项清零 | 阻断项清单中所有条目状态为已关闭 | 评估协调人汇总，过程域负责人签字确认 |
| 非阻断项整改 | 未通过的非阻断项有整改计划，明确责任人和完成时间 | 整改计划表 |
| 证据目录完整性 | 目录中每项证据均有实际文件或数据对应，无空项 | 抽样核对 |
| 追溯完整性 | 追溯矩阵无孤立条目，变更后关系已更新 | 追溯核查记录 |
| 样本可调取性 | 随机指定样本时，能在约定时间内调出全部相关证据 | 调取演练 |
非阻断项不要求评估前全部关闭，但需要进入整改计划并说明对评估的影响。若非阻断项集中在同一过程域且数量较多，建议评估协调人重新评估该域的证据成熟度，必要时升级为阻断项处理。
评估前最后一轮复核建议安排在正式评估前两周，内容包括：阻断项状态复查、证据调取演练、追溯矩阵抽查。复核通过后冻结证据版本，评估期间如需补充材料，保留补充记录以便说明来源和时点。就绪判定由评估协调人发起，项目经理和各过程域负责人共同确认，形成书面结论后方可进入正式评估。
常见问题
评估范围在准备过程中发生变化，已经收集的证据怎么处理？
范围变化后先更新范围确认记录和证据目录，再判断已有证据的复用情况。新增过程域需要补充对应工作产品；被移出范围的过程域，其证据可保留归档但不再计入本次检查。证据目录应冻结版本，变更走记录，避免不同角色按不同版本目录准备。已按旧目录完成的检查项，需要对照新目录重新核对一遍覆盖关系。
样本项目选几个、怎么选比较合适？
样本数量由评估范围和评估方要求决定，清单本身不设定固定数量。选取口径建议书面化，按项目类型、交付阶段或时间窗口确定规则，并说明选取理由。样本应覆盖本次评估涉及的主要过程域和典型交付形态，避免全部集中在同一类项目。选取口径确认后写入证据目录，后续检查按此执行。
非阻断项数量较多时，是否可以直接进入评估？
非阻断项不要求评估前全部关闭，但需要进入整改计划，明确责任人和完成时间，并说明对评估的影响。若非阻断项集中在同一过程域且数量较多，建议评估协调人重新评估该域的证据成熟度，必要时升级为阻断项处理。判断依据是该域证据能否支撑评估时的抽样调取和一致性核对。
追溯断点补齐后，评估时如何说明补齐过程？
补齐过程本身应留痕。缺少对应条目时补建关系并说明依据；引用错误时修正引用并记录修正原因；变更后未更新时先确认影响范围再补齐。每条断点的发现时间、断点类型、修复动作和确认人都应可查，评估时据此说明断点何时发现、如何修复，避免只呈现补齐后的结果。
用研发管理平台承载证据，需要注意什么？
平台承载证据的关键是让证据随工作项状态自然留存，而不是评估前集中补录。ONES的ASPICE解决方案支持跨域协作全过程的可追溯性，需求、任务、测试与文档在同一平台内流转，追溯关系可随工作项状态更新而留存。落地时需确认证据的存放位置、命名规则和版本标识与证据目录一致，具体追溯对象的配置方式结合实际环境确认。
