ASPICE评估准备需要哪些依据：证据清单与准备步骤

ASPICE评估准备需要围绕四类依据展开：适用的过程范围与能力等级要求、过程定义与裁剪记录、项目执行证据，以及需求到测试的追溯与一致性证据。准备顺序通常是先确认评估对象和过程域，再建立证据清单，按项目逐项归集，最后做内部预审，确认材料可查、可追溯、版本一致。

要点总览（TL;DR）

• 先确认评估覆盖的组织单元、项目样本、过程域与目标能力等级，再向评估方核实标准版本和附加要求，范围清单是后续所有准备工作的输入。
• 把过程要求拆成以过程域为一级、工作产品为二级的证据清单，写清责任角色、存放位置、版本和状态，评审后冻结版本。
• 过程定义、裁剪记录与项目执行记录要能一一对应，偏差需写明原因、影响、替代措施和批准人，缺少说明和批准才是风险点。
• 追溯矩阵按需求、设计、实现、测试、问题单逐层建立，并做反向抽查；版本不一致和闭环缺失是预审中最常见的阻断项。
• 正式评估前两到四周组织内部预审，按完整性、可查性、追溯性、版本一致性逐项检查，阻断项全部关闭并复核后再放行。

评估准备先确定哪些依据范围

准备工作的第一步是划定边界。ASPICE评估会围绕特定组织单元和项目样本展开，过程域与目标能力等级不同，需要准备的工作产品差别很大。范围没有定清就收集材料，容易出现两类浪费：收集了大量与本次评估无关的文档，真正需要的过程证据反而缺项。

范围确认至少需要明确四项内容：评估覆盖的组织单元与项目样本、适用的过程域与目标能力等级、评估依据的标准版本与评估方要求、范围确认的负责人与输出物。项目样本通常选择已完整经历主要研发阶段、角色齐备、记录相对完整的项目，便于展示过程执行的真实状态。

标准版本与评估方要求需要向评估机构或客户质量部门确认，包括采用的ASPICE版本、评估模型、评分规则以及是否包含特定客户附加要求。这些信息决定证据清单的颗粒度，不能凭经验假设。

确认项	需要写清的内容	责任人	输出物
评估对象	组织单元名称、参与项目样本及版本	评估接口人	评估范围说明
过程域	本次覆盖的过程域清单及排除项	过程负责人	过程域清单
能力等级	每个过程域的目标等级	质量负责人	等级目标表
标准与评估方要求	标准版本、评估模型、客户附加要求	评估接口人	要求确认记录

范围确认完成后应形成一份书面清单，由评估接口人、过程负责人和项目经理共同确认。后续证据清单、角色分工和预审检查都以这份清单为输入，范围变更时同步更新。

证据清单怎么按过程域拆到工作产品

证据清单的作用是把过程要求翻译成可归集、可检查的条目。建议以过程域为一级分类，以工作产品为二级条目，每个条目对应一份或一组可查阅的记录。清单不是文档目录的复制，而是回答“这个过程的执行结果用什么材料证明”。

每个证据条目建议包含以下字段：过程域、工作产品名称、对应的过程结果或实践要求、责任角色、存放位置、版本或基线、当前状态、备注。状态可以用“已有、待补、待确认、不适用”四类，便于统计缺口。直接证据指计划、需求规格、设计文档、测试记录、评审记录、变更单、问题单等原始记录；支撑说明用于解释裁剪原因、工具截图含义或历史项目背景，二者分开标注，避免用说明材料替代原始记录。

字段	填写示例	用途
过程域	需求分析相关过程	按评估范围归类
工作产品	软件需求规格、需求评审记录	定位具体证据
责任角色	系统工程师、评审主持人	明确归集人
存放位置	项目文档库路径或工具工作项编号	保证可查
版本/基线	V1.2，已纳入某次基线	核对一致性
状态	已有、待补、待确认	跟踪缺口

清单编制完成后需要组织一次评审，参加人包括过程负责人、项目经理和主要职能角色。评审重点是条目是否覆盖范围内过程域、责任角色是否落实、存放位置是否可访问。评审通过后冻结清单版本，后续补充以变更记录方式追加，避免准备过程中清单反复变动导致统计失真。

当工作产品在研发管理工具中产生时，清单中的存放位置应写到具体项目、工作项类型或文档目录，并确认评估期间可被查阅。ONES在汽车软件研发场景中支持研发全生命周期流程活动的线上化，以及跨域协作过程的可追溯性，可作为工作产品与追溯记录的承载环境；具体到每个过程域的证据形式，仍需结合组织过程定义和评估方要求逐项确认。

过程定义与项目执行记录如何对应

评估关注项目是否按组织定义的过程执行，因此需要同时准备组织级过程资产和项目级执行记录。组织级材料包括过程定义、裁剪指南、模板和检查表；项目级材料包括项目计划、裁剪记录、执行记录和偏差说明。两类材料要能一一对应，评估人员才能判断过程被定义、被裁剪、被执行。

具体做法是建立一张“过程定义—项目执行对应表”。左侧列出适用的过程活动和预期工作产品，右侧填写本项目实际执行的活动、产生的记录及其存放位置。项目计划中的阶段划分、活动顺序、评审安排应与过程定义一致；如果项目采用了裁剪，裁剪记录要写明裁剪了哪项活动、理由、批准人和对过程结果的影响。

常见缺口有三类。第一类是过程定义要求某项活动，项目实际执行了但记录缺失，处理方式是补充记录或提供可核实的执行痕迹。第二类是项目执行方式与过程定义不一致且没有裁剪记录，需要补充偏差说明并经授权人批准。第三类是过程定义本身与评估方要求存在差距，应在评估前修订过程资产，而不是在项目记录中临时解释。

偏差说明要写清偏差内容、发生原因、影响范围、替代控制措施和批准记录。偏差本身不必然构成问题，缺少说明和批准才是风险点。对应表和偏差说明应纳入证据清单统一管理，版本随项目基线更新。

追溯与一致性证据怎么准备

追溯证据用于证明需求、设计、实现、测试之间的对应关系，以及变更和问题是否闭环。准备时先建立追溯矩阵，再逐条核对一致性。矩阵的行是需求或需求条目，列包括设计文档章节、实现工作项、测试用例、测试结果、变更单和问题单编号。

建立追溯链的步骤可以按以下顺序执行：

1. 以基线版本的需求清单为起点，给每条需求分配唯一标识。
2. 在设计文档中标注对应的需求标识，形成需求到设计的正向追溯。
3. 在实现工作项和测试用例中引用需求标识与设计章节，形成到实现和测试的覆盖。
4. 补充测试结果与问题单的关联，确认失败项有对应的修复记录和回归结果。
5. 反向抽查若干测试用例和设计章节，确认能回溯到需求，避免只做单向覆盖。

一致性核对关注三类问题：版本不一致，例如需求已变更但测试用例仍引用旧版本；基线不一致，例如设计文档纳入了基线而实现工作项未纳入；闭环缺失，例如问题单已关闭但没有回归验证记录。核对结果形成追溯缺口清单，按“影响评估放行”和“可评估期间说明”两类排序补齐。影响核心过程证据的缺口优先处理，说明性缺口可以准备补充材料。

追溯矩阵和核对记录应注明核对人、核对日期和依据的基线版本。工具中维护的关联关系可以导出为矩阵或清单，导出时确认字段完整、编号可读，便于评估方抽查。

角色分工与各阶段交付物

准备工作的效率取决于责任是否落到人。建议设置四类角色：过程负责人负责过程定义、裁剪指南和过程域证据的完整性；项目经理负责项目样本的执行记录、计划和偏差说明；各职能角色负责本领域工作产品的归集与自查；评估接口人负责与评估方沟通要求、汇总证据清单、组织预审和正式评估接待。

角色	主要职责	关键交付物	交接节点
评估接口人	确认评估要求，汇总清单，组织预审	范围确认清单、预审计划	范围确认后、预审前
过程负责人	维护过程定义与裁剪指南，审核过程域证据	过程资产、过程域证据审核记录	清单冻结前
项目经理	归集项目计划、执行记录与偏差说明	项目证据包、偏差说明	证据归集截止日
职能角色	提交本领域工作产品并完成自查	需求、设计、测试、评审等记录	按清单条目分批交接

交接节点建议与证据清单的状态联动：条目从“待补”变为“已有”时，由责任角色提交给过程负责人或项目经理复核，复核通过后更新状态。交付物的完成标志是“存放位置可访问、版本已标注、责任人已确认”，三者缺一不可。证据保管方式需要提前确定，包括目录结构、访问权限、只读备份和评估期间的查阅安排，避免正式评估时因权限问题无法调取材料。

一个项目样本的准备示例

以下为演示情景，用于说明准备过程，不代表真实评估结论。某项目被选为评估样本，范围覆盖需求分析、软件设计、测试和问题解决相关过程域，目标能力等级由评估方确认。

第一步，评估接口人组织范围确认会，输出范围清单，明确项目版本、参与角色和过程域清单。第二步，过程负责人依据过程定义和评估方要求编制证据清单，列出每个过程域的工作产品、责任角色和存放位置，评审后冻结。第三步，项目经理按清单归集项目计划、裁剪记录、需求规格、设计文档、测试计划和测试记录，职能角色补充评审记录和问题单。

归集中发现三个典型缺口：部分需求变更没有对应的测试用例更新记录；一次设计评审缺少评审问题关闭记录；项目裁剪了一项过程活动但裁剪记录未获批准。处理方式分别是补充变更影响分析和测试更新、补齐问题关闭记录、由授权人补批裁剪记录并说明替代控制措施。第四步，建立追溯矩阵，抽查需求到测试的正反向覆盖，形成缺口清单并逐项关闭。第五步，组织内部预审，按检查表核对证据完整性和版本一致性，整改阻断项后放行。

这个示例可迁移的做法是“先范围、再清单、后归集、再核对、最后预审”的顺序，以及把缺口分为阻断项和说明项分别处理。边界在于：过程域选取、证据颗粒度和能力等级判定因组织和评估方要求而异，示例中的做法需要按实际范围调整。

内部预审与完成检查

内部预审是正式评估前的最后一道关口，目的是在受控时间内发现证据缺口并完成整改。预审建议在正式评估前两到四周进行，参加人包括评估接口人、过程负责人、项目经理和主要职能角色，必要时邀请未参与准备的人员担任独立检查人。

预审按四项标准逐条检查：完整性，范围内每个过程域的工作产品是否齐备；可查性，证据存放位置是否可访问、编号是否清晰；追溯性，需求、设计、实现、测试和问题之间能否双向回溯；版本一致性，证据引用的版本与基线是否一致。检查表应直接对应证据清单条目，逐项记录“符合、不符合、不适用”及说明。

检查维度	检查要点	判定为阻断项的典型情形
完整性	过程域工作产品是否齐备	核心过程结果缺少原始记录
可查性	存放位置、权限、编号是否可用	评估期间无法访问关键证据
追溯性	正反向追溯是否可验证	需求到测试链路大面积断裂
版本一致性	证据版本与基线是否一致	关键文档版本与基线冲突且无说明

预审发现的问题分为阻断项和一般项。阻断项指影响过程证据成立或无法查阅的问题，必须在放行前整改并复核；一般项可以在评估前限期完成，或准备说明材料。放行条件是：阻断项全部关闭并经复核确认，证据清单状态更新完毕，追溯缺口清单中的高优先级项已处理。预审记录和整改记录一并归档，作为正式评估前的准备状态凭证。

常见问题

ASPICE评估准备中，评估范围由谁确认、需要评估方提供哪些信息？

范围确认通常由评估接口人牵头，过程负责人和项目经理共同参与，最终形成书面清单。需要向评估机构或客户质量部门确认的信息包括：采用的ASPICE标准版本与评估模型、本次覆盖的过程域、每个过程域的目标能力等级、评分规则，以及是否存在客户附加要求。

这些信息决定证据清单的颗粒度。标准版本和评估方要求属于外部输入，不能凭经验假设；范围发生变更时，证据清单、角色分工和预审检查表都要同步更新。

项目执行方式与组织过程定义不一致时，准备阶段应该怎么处理？

先判断不一致属于哪种情况。如果项目实际执行了活动但记录缺失，补充记录或提供可核实的执行痕迹即可；如果项目确实采用了裁剪或替代做法，需要补充偏差说明，写清偏差内容、原因、影响范围、替代控制措施和批准记录，并由授权人批准。

偏差本身不必然构成问题，缺少说明和批准才是风险点。如果差距来自过程定义本身与评估方要求不符，应在评估前修订过程资产，避免在项目记录中临时解释。

追溯矩阵需要做到什么程度才算准备到位？

基本要求是需求、设计、实现、测试和问题单之间能够双向回溯，而不只是需求到测试的单向覆盖。准备时可以以基线版本的需求清单为起点分配唯一标识，在设计文档、实现工作项和测试用例中引用该标识，再补充测试结果与问题单的关联。

完成后要反向抽查若干测试用例和设计章节，确认能回溯到需求。核对结果形成缺口清单，按是否影响核心过程证据排序补齐；影响放行的缺口优先处理，说明性缺口可准备补充材料。

内部预审发现的问题，哪些必须整改后才能进入正式评估？

预审问题分为阻断项和一般项。阻断项指影响过程证据成立或评估期间无法查阅的问题，例如核心过程结果缺少原始记录、关键证据无法访问、需求到测试链路大面积断裂、关键文档版本与基线冲突且无说明，这些必须在放行前整改并复核。

一般项可以在评估前限期完成，或准备说明材料。放行条件是阻断项全部关闭并经复核确认，证据清单状态更新完毕，追溯缺口清单中的高优先级项已处理。

用研发管理工具承载证据时，需要提前确认哪些事项？

重点是评估期间能否查阅。证据清单中的存放位置应写到具体项目、工作项类型或文档目录，并确认访问权限、编号可读性和版本记录完整。工具中维护的关联关系如需导出为追溯矩阵，要提前试导出，确认字段完整、编号清晰。

ONES在汽车软件研发场景中支持研发全生命周期流程活动的线上化，以及跨域协作过程的可追溯性，可作为工作产品与追溯记录的承载环境。具体到每个过程域的证据形式，仍需结合组织过程定义和评估方要求逐项确认。