ASPICE过程裁剪的起点是确定项目适用的过程范围与目标能力等级，再按项目特征逐过程判断保留、简化、合并或调整实施方式。裁剪的产物是一份可追溯的裁剪说明：每个结论都写明理由、替代措施和批准人，并纳入项目计划与过程资产。本文按“定边界—逐过程判断—角色分工—记录—复核”的顺序给出可执行步骤和记录模板。
要点总览（TL;DR）
- 裁剪从确定过程范围与目标能力等级开始，再收集项目类型、开发模式、复用策略、供应商分工等特征作为判断依据。
- 逐过程判断保留、简化、合并或调整实施方式，每条非保留结论都要写明理由和替代措施，并对应到具体项目特征。
- 裁剪由过程负责人牵头、项目经理与技术负责人参与、质量角色组织评审，批准后的结论落实到项目计划和过程资产。
- 裁剪记录按过程逐条维护，包含结论、理由、替代措施、影响分析、关联项和批准人，评估时可从结论追溯到证据。
- 批准前检查结论是否成立，评估前核对实施是否与结论一致；范围或复用策略变化时触发裁剪复核并保留变更记录。
裁剪前先定边界：范围、目标与依据
裁剪是在既定范围和目标下做取舍，前提条件不清楚，后面的判断就缺少参照。开始逐过程讨论之前，先把四类输入固定下来：项目涉及哪些系统过程和软件过程、目标能力等级与评估范围是什么、项目有哪些影响实施方式的特征、谁对裁剪结论负责以及如何评审。
确定过程范围与目标等级
过程范围来自项目在整车或系统架构中的位置。一个同时承担系统需求分析、系统架构设计和软件开发的ECU项目，过程范围通常覆盖系统过程组和软件过程组；只承接软件模块开发的项目，范围集中在软件过程组，系统层过程由上游组织承担。范围确定后，写明目标能力等级和本次评估覆盖的过程清单，作为后续判断“哪些要求必须保留”的基准。
收集裁剪依据
裁剪依据是判断过程如何实施的事实输入，建议按以下清单收集：
- 项目类型与交付形态：全新开发、平台衍生、客户定制或维护类项目。
- 开发模式：瀑布、迭代或混合模式，决定过程活动的时序和迭代粒度。
- 复用策略：哪些需求、架构或组件来自既有平台，复用程度如何。
- 供应商分工：哪些工作由供应商完成，接口和交付物如何约定。
- 安全相关度：项目是否涉及功能安全相关需求，影响验证与确认活动的严格程度。
- 工具与数据环境：需求、变更、测试数据在哪些系统中管理。
明确决策责任人与评审方式
裁剪决策由过程负责人牵头，项目经理、技术负责人共同参与，质量角色组织评审。评审方式可以是裁剪说明的正式评审会，也可以是在项目计划评审中一并确认，但需要有记录表明谁批准了哪条结论。评审通过的裁剪结论才进入项目计划。
这一阶段的交付物是裁剪范围与依据清单，至少包含目标能力等级、过程范围、项目特征描述和决策责任人。清单确认后，再进入逐过程判断。
逐过程裁剪的操作步骤
逐过程裁剪按五步推进，每一步都有明确的输入、动作、输出和完成标志。整个过程的目标是形成一张裁剪决策表，让每条结论都能被追问“为什么这样裁、裁了之后怎么满足过程目的”。
第一步：列出候选过程清单并标注属性
输入是S1确定的过程范围。动作是把范围内每个过程逐条列出，标注三项属性：该过程在目标等级下是否必须覆盖、过程目的中的关键结果有哪些、本项目对该过程的实施是否有调整空间。输出是一张带属性的过程清单。完成标志是清单覆盖了范围内全部过程，没有遗漏，也没有把范围外的过程混入。
第二步：逐过程判断保留、简化、合并或调整实施方式
判断依据是S1收集的项目特征。四种结论的含义和适用条件如下：
| 裁剪结论 | 含义 | 典型适用条件 |
|---|---|---|
| 保留 | 按组织标准过程完整实施 | 过程与项目核心工作直接相关，或目标等级对该过程结果要求完整 |
| 简化 | 保留过程目的和关键结果，减少活动形式、文档数量或评审层级 | 项目规模较小、复用程度高，标准过程中的部分活动可由既有资产替代 |
| 合并 | 将两个过程的实施活动整合到同一工作流或同一份工作产品中 | 过程之间存在天然衔接，分开实施会产生重复记录 |
| 调整实施方式 | 过程目的不变，改变执行顺序、工具或责任分配 | 开发模式为迭代式，或部分活动由供应商承担 |
判断时先看过程目的和关键结果，再看实施形式。例如软件单元验证过程，在复用组件已有验证证据的情况下，可以简化为对复用证据的确认加增量部分的验证，但“验证结果被记录并可追溯”这一关键结果仍需满足。合并的典型场景是把变更请求管理与配置管理中的变更控制活动整合到同一变更流程中，减少重复审批。完成标志是每个过程都有明确结论，且结论能对应到至少一条项目特征。
第三步：记录裁剪理由与替代措施
每条非“保留”的结论都要写清两件事：为什么这样裁，以及裁剪后如何满足过程目的。替代措施要具体到动作和证据，例如“以平台项目的架构评审记录作为本项目的架构确认证据，补充本项目差异分析”。只写“项目较小，适当简化”不构成可评审的理由。输出是裁剪决策表的初稿。
第四步：评审批准并纳入项目计划与过程资产
输入是裁剪决策表初稿。动作是由质量角色组织评审，过程负责人、项目经理、技术负责人参加，逐条确认结论和替代措施；批准后，把裁剪结论落实到项目计划的活动安排、工作产品清单和过程资产引用中。输出是批准后的裁剪说明和更新后的项目计划。完成标志是每条结论都有批准记录，项目计划中的活动与裁剪结论一致。
第五步：在实施与评估中复核裁剪结论
裁剪不是一次性动作。项目执行中出现范围变化、供应商调整或复用策略变化时，需要回看相关结论是否仍然成立。评估前，按裁剪说明逐条核对实际执行是否与结论一致，替代措施是否产生了预期证据。发现偏差时更新裁剪说明并重新批准，保留变更记录。
角色分工与各阶段交付物
裁剪涉及四类角色，各自在不同阶段提供输入或做出决定。角色可以兼任，但职责要写清楚，避免出现“大家都参与、没人批准”的情况。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 过程负责人/质量角色 | 制定裁剪规则，组织裁剪评审，维护裁剪说明模板，检查结论与过程资产的一致性 | 裁剪规则、评审记录、批准后的裁剪说明 |
| 项目经理 | 提供项目类型、范围、进度和供应商分工等特征输入，把裁剪结论落到项目计划 | 项目特征说明、更新后的项目计划 |
| 技术负责人 | 提供开发模式、复用策略、技术方案对过程活动的影响判断 | 复用分析、技术方案说明、替代措施的技术依据 |
| 评估或审核角色 | 在评估前复核裁剪证据，确认结论与实施一致 | 裁剪证据自查记录、偏差清单 |
交付物按阶段归集：裁剪前形成范围与依据清单，逐过程判断后形成裁剪决策表，评审后形成批准版裁剪说明，实施和评估阶段形成复核记录。这些交付物之间要能相互引用，评估时可以从一条结论追溯到依据、批准和实际执行证据。
裁剪说明、评审记录和过程资产需要在团队日常使用的平台上留存，避免散落在个人文档中。ONES支持汽车软件研发全生命周期流程活动和跨域协作全过程的可追溯性，裁剪说明可以作为项目文档与需求、任务、测试等工作项关联，评审意见和批准记录随文档版本保留；过程资产放在知识库中，项目计划中的活动与裁剪结论对应，评估时按项目追溯即可。具体承载方式按团队现有的项目空间和文档结构配置。
裁剪记录怎么写：字段与示例
裁剪记录建议以表格形式维护，一行一条裁剪结论。字段设计要让评审者不看正文也能判断结论是否成立，让评估者能顺着字段找到证据。
字段结构
| 字段 | 填写要求 | 必填/选填 |
|---|---|---|
| 过程名称与编号 | 使用目标等级对应的过程名称，编号与过程资产一致 | 必填 |
| 裁剪结论 | 保留、简化、合并或调整实施方式，四选一 | 必填 |
| 裁剪理由 | 对应到具体项目特征，说明为什么这样裁 | 必填 |
| 替代措施 | 裁剪后如何满足过程目的，写明动作和产生的证据 | 非“保留”结论必填 |
| 影响分析 | 对下游过程、工作产品、供应商接口和评估范围的影响 | 必填 |
| 关联项 | 关联的项目计划活动、工作产品、过程资产版本 | 必填 |
| 批准人及日期 | 评审批准的责任人和批准时间 | 必填 |
| 复核记录 | 实施中或评估前的复核结论、偏差与变更 | 选填，发生变更时必填 |
填写示例
以下为演示情景，用于说明字段如何填写，不代表任何具体项目的真实结论。
| 字段 | 示例内容 |
|---|---|
| 过程名称与编号 | 软件单元验证（按项目适用的过程编号填写） |
| 裁剪结论 | 简化 |
| 裁剪理由 | 本项目软件单元中约七成来自既有平台，平台项目已完成单元验证并保留验证记录；本项目为平台衍生项目，复用策略为平台组件直接复用 |
| 替代措施 | 复用单元以平台验证记录作为证据，补充复用清单与版本对应关系；新增和修改单元按标准过程执行单元测试并保留测试记录与覆盖率数据 |
| 影响分析 | 不影响软件单元验证过程的关键结果；需在软件集成测试中确认复用单元与新增单元的接口一致性；供应商提供的单元需提供对应验证证据 |
| 关联项 | 项目计划中“单元验证”活动；复用清单文档；单元测试记录工作产品 |
| 批准人及日期 | 质量负责人，评审会日期 |
| 复核记录 | 集成阶段发现两个复用单元接口变更，已补充验证并更新本记录 |
裁剪记录与项目计划的关联方式有两种：在项目计划的活动说明中引用裁剪记录编号，或在裁剪记录的关联项字段中写明对应的计划活动和工作产品。两种方式选一种并保持一致即可。与过程资产的关联要写到版本，确保评估时能确认当时依据的是哪一版标准过程。
裁剪结论的检查与复核
裁剪是否可交付，可以用一组检查项来判断。建议在裁剪说明批准前和评估前各做一次自查，两次检查的侧重点不同：批准前看结论是否成立，评估前看实施是否与结论一致。
裁剪完成检查清单
- 过程范围覆盖目标等级要求的过程，清单无遗漏、无范围外过程。
- 每条裁剪结论都有对应的项目特征依据，理由具体到事实而非笼统描述。
- 非“保留”结论均写明替代措施，替代措施能指向具体动作和预期证据。
- 每条结论都有批准人和批准日期，评审记录可查。
- 裁剪未削弱目标等级对过程关键结果的要求；简化或合并后，过程目的仍可被证据证明。
- 裁剪说明与项目计划的活动安排、工作产品清单一致，关联项字段填写完整。
- 影响分析覆盖下游过程、供应商接口和评估范围，相关方已知悉。
- 评估前完成证据自查：逐条核对实际执行与裁剪结论，偏差已记录并处理。
- 实施过程中发生的范围或策略变化已触发裁剪复核，变更留有记录。
复核时常见的问题有三类：结论写了简化但找不到替代措施产生的证据；裁剪说明与项目计划的活动对不上，计划里仍按完整过程安排；项目中途调整了复用策略，裁剪记录没有同步更新。前两类在批准前检查中解决，第三类靠实施阶段的定期复核和变更触发机制控制。把这三类问题处理掉，裁剪说明就能在评估中作为过程适用的合理解释被追溯。
常见问题
项目中途范围或供应商分工发生变化，裁剪结论需要重新做吗？
需要回看受影响的结论，不必整体重做。先判断变化涉及哪些过程，例如新增了由供应商承担的软件单元，就检查软件单元验证过程的简化结论是否仍然成立、替代措施中的证据来源是否改变。确认后更新对应裁剪记录，写明变更原因和新的替代措施，重新走批准流程并保留旧版本。范围、复用策略、供应商分工和开发模式这几类变化最容易影响裁剪结论，建议把它们设为触发复核的条件。
裁剪说明和项目计划对不上，通常是什么原因？
常见原因是裁剪结论批准后没有同步到计划。裁剪说明里写了简化，项目计划的活动安排仍按完整过程排；或者计划调整了活动，裁剪记录没有更新。处理方式是在裁剪记录的关联项字段写明对应的计划活动和工作产品，并在计划评审时把裁剪说明作为输入一并核对。两者以裁剪说明为准，计划按结论调整；如果计划确实需要偏离结论，应先更新裁剪说明再改计划。
简化某个过程后，评估时如何证明过程目的仍然满足？
靠替代措施产生的证据。裁剪记录中的替代措施要具体到动作和证据，例如复用组件以平台项目的验证记录作为证据，同时补充复用清单与版本对应关系。评估时按裁剪说明逐条核对：该过程的关键结果是否有对应工作产品，替代措施是否实际执行并留下记录。如果替代措施只写在文档里、执行中没有产生证据，这条简化就缺少支撑，需要在评估前补齐或调整结论。
裁剪记录和评审记录放在哪里，评估时怎么快速追溯？
建议放在团队日常使用的研发管理平台中，与项目计划、工作产品和过程资产建立关联，避免散落在个人文档里。ONES 支持汽车软件研发全生命周期流程活动和跨域协作全过程的可追溯性，裁剪说明可以作为项目文档与需求、任务、测试等工作项关联，评审意见和批准记录随文档版本保留，过程资产放在知识库中。具体承载方式按团队现有的项目空间和文档结构配置，目标是评估时能从一条结论追溯到依据、批准和实际执行证据。
小项目或平台衍生项目，裁剪可以做到什么程度？
可以简化活动形式、文档数量或评审层级，也可以把衔接紧密的过程合并到同一工作流，但目标等级要求的过程关键结果仍需被证据证明。平台衍生项目的常见做法是复用既有平台的验证、评审记录作为证据，补充本项目的差异分析和版本对应关系。判断标准是过程目的能否被证明，项目规模本身不构成裁剪理由；结论仍要写明依据、替代措施和批准人。
