ASPICE评估准备的核心依据可以归为三类：评估范围内适用的过程域及目标能力等级要求、项目全生命周期真实产生的过程证据、把过程活动与证据对应起来的追溯关系和自查记录。准备工作从确定评估范围与目标等级开始，再按过程域拆出应产出什么、由谁产出、在哪个阶段产出，逐项核对证据的存在性、受控状态与内容一致性，最后形成差距清单和整改计划。
要点总览（TL;DR）
- ASPICE评估准备的依据分三层：适用过程域与目标能力等级要求、项目真实产生的过程证据、过程活动与证据之间的追溯关系和自查记录。
- 准备从确定评估范围与目标等级开始，再按过程域把要求拆成可核对的证据条目，标注产出时点、责任角色与受控状态。
- 证据收集要落实到人：过程负责人定条目，项目经理组织计划类证据，开发测试人员提供工作产物，质量或评估接口人汇总自查。
- 就绪判定看三条：阻断级差距全部关闭，影响级差距关闭或有经确认的替代证据，证据索引与实际一致。
- 证据数量多、跨项目跨角色时，可用研发管理平台统一跟踪证据条目、核对结论与差距整改状态。
先定范围：评估依据从哪里来
评估准备的第一步是划定边界。ASPICE评估通常围绕特定项目或组织单元展开，评估范围决定了哪些项目、哪些过程域、哪些生命周期阶段需要提供证据。范围不清就铺开收集材料，常见结果是收集了大量与评估无关的文档，真正需要的过程证据反而缺失。
确定评估范围与目标能力等级
评估范围一般由评估发起方与评估机构共同确认，需要明确三项内容：被评估的组织单元或项目、覆盖的过程域集合、每个过程域的目标能力等级。目标等级直接决定证据深度——等级1关注过程是否执行并产出预期结果，等级2在此基础上要求过程被管理（计划、监控、调整），等级3进一步要求过程在组织层面标准化并被裁剪应用。准备时按目标等级倒推证据要求，避免用高等级标准准备低等级评估，或反之遗漏管理类证据。
适用过程域清单的来源与裁剪
适用过程域清单通常来自评估模型的过程参考模型与评估模型，结合项目实际承担的系统或软件层级进行裁剪。裁剪需要记录理由：哪些过程域因项目不涉及而被排除，哪些因组织职责划分由其他单元承担。裁剪结论应形成书面清单，作为后续证据梳理的唯一口径，防止不同角色各自理解范围。
评估依据的三层结构
把依据组织成三层，可以让准备工作有清晰的推进顺序：
| 层级 | 内容 | 作用 |
|---|---|---|
| 要求层 | 适用过程域、目标能力等级、过程实践与通用实践要求 | 确定准备边界和证据应满足的标准 |
| 证据层 | 项目实际产生的计划、需求、设计、测试、评审、变更、问题等记录 | 证明过程被执行并产出预期结果 |
| 追溯层 | 过程活动与证据的对应关系、自查记录、差距与整改记录 | 证明证据完整、一致、可追溯 |
本节的交付物是一份评估范围与适用过程域清单，至少包含：被评估单元、过程域列表、每个过程域的目标等级、裁剪说明与确认人。这份清单确认后，后续证据梳理才有稳定基准。
按过程域梳理应准备的证据清单
范围确定后，工作重心转向把过程域要求翻译成可逐项核对的证据条目。拆解的基本单位是过程实践：每条实践对应一个或多个应产出物，每个产出物再对应产出时点、责任角色和受控状态。
从要求到证据条目的拆解方法
建议按四步拆解。第一步，列出该过程域的过程实践与通用实践。第二步，对每条实践写出“应看到什么”的具体产出物名称，例如需求分析实践对应需求规格说明、需求评审记录、需求追溯关系。第三步，标注产出时点和责任角色，明确该产出物在项目哪个阶段由谁完成。第四步，标注受控要求，包括版本、审批状态、存放位置和变更记录。四步完成后，每条证据都具备可核对的具体属性，而不是笼统的“需求文档”。
各环节的典型证据
项目全生命周期的证据可以按环节归类，便于分工收集：
| 环节 | 典型证据 | 受控要点 |
|---|---|---|
| 计划 | 项目计划、过程裁剪记录、资源与进度安排、计划评审记录 | 版本与审批状态，计划变更留痕 |
| 需求 | 需求规格说明、需求评审记录、需求变更记录、需求与设计/测试的追溯关系 | 需求基线与变更影响分析 |
| 设计 | 架构与详细设计文档、设计评审记录、设计到需求的追溯 | 设计版本与评审结论 |
| 测试 | 测试计划、测试用例、测试执行记录、缺陷记录与回归结果 | 用例与需求的对应关系，缺陷闭环状态 |
| 评审 | 各类评审的检查单、问题记录、整改确认 | 评审问题是否关闭 |
| 变更 | 变更请求、影响分析、变更审批、变更后验证记录 | 变更前后版本对应关系 |
| 问题 | 问题报告、原因分析、纠正措施、验证关闭记录 | 问题状态与关闭依据 |
证据的版本、状态与可追溯性要求
评估关注的不只是文档是否存在，还包括证据是否处于受控状态。核对时重点看三项：版本是否为当前有效版本、审批状态是否完成、内容之间是否一致。追溯性要求证据之间能建立双向关系，例如需求能追到设计与测试用例，测试结果能回溯到需求条目。追溯关系缺失时，即使单个文档质量合格，也难以证明过程完整执行。证据清单表建议按过程域组织，每条记录包含证据名称、对应实践、责任角色、产出时点、存放位置、受控状态和核对结论。
准备工作的角色分工与交付物
证据梳理完成后，需要把收集、核对和汇总工作落实到人。角色分工不清是准备阶段常见的返工来源：同一份证据多人重复整理，或关键证据无人负责。
各角色职责与交付物
| 角色 | 主要职责 | 交付物 | 提交时点 |
|---|---|---|---|
| 过程负责人 | 解读过程域要求，定义证据条目与受控标准 | 过程域证据清单、裁剪说明 | 准备启动阶段 |
| 项目经理 | 确认项目范围，组织计划类证据，协调资源 | 项目计划、裁剪记录、进度与问题跟踪 | 证据收集启动前 |
| 开发与测试人员 | 提供需求、设计、测试、缺陷等实际工作产物 | 各环节工作产品与记录 | 按证据清单分批提交 |
| 质量或评估接口人 | 汇总证据，组织自查，维护差距清单，对接评估机构 | 证据汇总目录、自查记录、差距整改清单 | 自查与整改阶段 |
证据汇总与评审的组织方式
汇总建议采用集中目录加条目索引的方式：所有证据按过程域和证据条目编号存放，索引表记录每条证据的位置、版本和核对状态。自查评审按过程域分批组织，由过程负责人和评估接口人共同核对，开发与测试人员到场解释证据内容。每轮评审输出核对结论和待补项，待补项进入差距清单并指定责任人与完成时点。评审节奏可按周推进，避免临近评估集中补材料。
一个过程域的准备示例
以下用软件需求分析类过程域示范完整走法，具体实践编号与名称以实际采用的评估模型为准。示例为演示情景，用于说明方法，不代表任何具体项目的评估结论。
要求解读
该过程域的核心要求通常包括：需求被完整收集并分析、需求与相关方达成一致、需求被记录并建立基线、需求变更受控、需求与后续工作产品建立追溯。对应到证据，需要看到需求来源记录、需求分析结果、需求评审与确认记录、需求基线、变更记录以及需求到设计、测试的追溯关系。
证据逐项核对
按证据清单逐条核对，示例核对结果如下：
| 证据条目 | 核对内容 | 结论 |
|---|---|---|
| 需求规格说明 | 版本为当前基线，审批完成 | 符合 |
| 需求评审记录 | 评审问题已关闭，结论明确 | 部分问题未关闭 |
| 需求变更记录 | 变更均有影响分析与审批 | 两次变更缺少影响分析 |
| 需求到测试追溯 | 每条需求可追到测试用例 | 三条需求无对应用例 |
差距与整改记录写法
差距记录应写清四要素：差距描述、对应证据条目、影响判断、整改责任人与完成时点。例如“需求变更CR-012、CR-015缺少影响分析，影响变更受控证据的完整性，由项目经理在两周内补充影响分析并提交评审”。记录避免只写“补充变更文档”这类无法验证的表述，整改完成的标志应是补充后的证据通过复核并更新索引状态。
准备完成检查与差距整改
准备是否充分，取决于证据能否支撑评估人员按过程域逐条验证过程被执行且结果可预期。判断标准应提前明确，而不是等评估前临时讨论。
证据检查项
完成检查围绕三个维度展开：完整性，即证据清单中每条条目是否都有对应材料；一致性，即证据内容之间、证据与过程描述之间是否矛盾；可追溯性，即需求、设计、测试、变更、问题之间能否建立双向关系。检查时逐条记录结论，未通过项进入差距清单。
差距分级与整改优先级
差距建议按影响程度分级：阻断级指关键过程证据缺失或严重不一致，直接影响评估结论，必须优先整改；影响级指证据存在但受控状态或追溯关系不完整，可能影响评级，应在评估前完成；优化级指记录规范性、表述清晰度等问题，可在评估后持续改进。整改优先级按阻断级、影响级、优化级依次推进，每项明确责任人和完成时点。
就绪判定与遗留问题处理
就绪判定条件可以设为：阻断级差距全部关闭，影响级差距关闭或已有经确认的替代证据，证据索引与实际情况一致。仍存在的优化级问题应形成遗留问题清单，说明现状、影响和后续计划，在评估沟通中主动说明。遗留问题不等于准备失败，但需要评估接口人判断其是否影响目标等级的达成。
当证据数量较多、跨项目跨角色时，证据的版本受控、追溯关系和差距整改状态容易分散在多个文档与沟通渠道中。ONES 一站式软件研发平台面向车企研发管理场景，其 ASPICE 解决方案支持汽车软件研发全生命周期流程活动与跨域协作全过程的可追溯性，方案模块组合包括项目管理、知识库、工单管理、资源管理、测试管理、效能管理。准备阶段可以把证据条目、核对结论和差距整改作为工作项统一跟踪，让每条差距有责任人、有状态、有完成记录，评估接口人据此汇总就绪情况。具体过程域与模块的对应关系需结合组织实际配置确认。
常见问题
评估范围还没最终确认，可以先开始收集证据吗？
可以先做与范围无关的准备工作，例如整理现有过程文档的存放位置、确认各环节的责任角色、梳理历史项目的变更与问题记录。证据条目的拆解和正式收集建议等范围清单确认后再铺开，因为过程域集合和目标能力等级直接决定证据深度：等级2需要计划、监控类管理证据，等级3还要求组织层面的标准化与裁剪记录。范围未定时大规模收集，容易把低等级不需要的材料和高等级缺失的材料混在一起，返工成本更高。
项目实际执行与过程文件描述不一致，准备时应该改文件还是改做法？
先判断不一致的性质。如果实际做法合理、只是文件未及时更新，应修订文件使其反映真实过程，并保留修订记录；如果实际做法偏离了组织规定的过程且缺少必要活动，例如变更未做影响分析、评审问题未关闭，则要补齐实际活动并留下证据，仅修改文件描述无法支撑评估验证。两类情况都应在差距清单中记录，写明差距描述、影响判断、责任人与完成时点，整改后由评估接口人复核并更新索引状态。
历史项目的老证据需要补做吗？
评估通常针对评估范围内的项目与时间段，历史项目是否纳入取决于范围清单的界定。纳入范围内的证据，缺失的关键活动记录不能靠事后补写文档替代，因为评估关注过程是否真实执行；可行的做法是提供能够证明该活动实际发生的替代证据，例如邮件确认、会议记录、系统操作记录，并在自查记录中说明替代理由。范围外的历史项目一般不作为本次评估证据，但其中的问题与经验可以用于完善当前项目的证据清单。
差距整改到什么程度算准备就绪？
建议提前设定判定条件：阻断级差距全部关闭，影响级差距关闭或已有经确认的替代证据，证据索引与实际存放情况一致。优化级问题可以保留为遗留问题清单，写清现状、影响和后续计划，在评估沟通中主动说明。遗留问题是否影响目标等级达成，需要评估接口人结合过程域要求判断，判断结论应记录在案，便于评估时解释。
证据分散在多个系统和文档里，怎么保证版本和追溯关系不乱？
关键是建立统一的证据索引：按过程域和证据条目编号，记录每条证据的名称、对应实践、责任角色、存放位置、版本、审批状态和核对结论，所有角色以这份索引为唯一口径。追溯关系可以单独维护一张对应表，标明需求、设计、测试用例、变更、问题之间的双向关联。证据条目和差距整改也可以作为工作项统一跟踪，让每条差距有责任人、有状态、有完成记录。ONES 一站式软件研发平台面向车企研发管理场景，其 ASPICE 解决方案支持汽车软件研发全生命周期流程活动与跨域协作全过程的可追溯性，方案模块组合包括项目管理、知识库、工单管理、资源管理、测试管理、效能管理；具体过程域与模块的对应关系需结合组织实际配置确认。
