ASPICE过程裁剪的对象是过程的实施方式与证据形式，过程目标本身不能通过裁剪取消。实际操作中，团队先依据项目目标能力等级和合同要求确定必须保留的过程范围，再结合产品类型、变更幅度、复用程度、供应商分工和风险等级逐项判断保留、简化或调整实施方式，把理由、替代证据和影响写进裁剪记录，经评审批准后纳入项目计划，并在运行中复核前提是否仍然成立。
要点总览（TL;DR）
- 裁剪的对象是过程的实施方式与证据形式，过程目标本身不能取消；先依据目标能力等级、合同要求和组织过程资产确定必须保留的过程范围。
- 逐项判断时把产品类型、变更幅度、复用程度、供应商分工和风险等级落到具体过程项，决定分为保留、简化、调整实施方式三类。
- 裁剪记录要写清过程项、原要求、决定、可核验依据、替代证据、影响与风险；依据空泛、替代证据缺失、影响未评估的记录应退回补充。
- 裁剪由提出人起草、过程负责人与质量安全角色评估、项目负责人批准，批准后与项目计划版本关联，并在前提变化时重新评审。
- 定稿前按范围完整性、依据充分性、证据可采集性、批准与版本一致性四类检查项自查，不通过则回到对应环节修正后重新评审。
裁剪前先定范围：哪些过程必须保留
裁剪的起点是确定范围，而非按工作量删减过程。范围来自三个输入：项目要达到的目标能力等级（如某个过程域需达到CL2或CL3）、客户与合同中的明确要求、组织过程资产中适用的过程集与裁剪规则。三者叠加后，得到本项目必须覆盖的过程域清单，再逐项标注目标等级和来源依据。
这里要区分两个层次：过程目标（如“确保需求与实现一致”）属于必须保留的部分，不能因项目小而取消；实施方式（如采用何种评审形式、记录在哪个工具、证据以什么粒度保存）才是可裁剪的部分。把这两层混在一起，容易出现“项目小所以不做需求评审”这类站不住脚的裁剪。
形成初始过程范围清单时，建议按以下结构记录，作为后续逐项判断的底稿：
| 过程域 | 目标能力等级 | 来源依据 | 备注 |
|---|---|---|---|
| 需求分析 | CL2 | 客户合同附件、组织过程资产 | 含双向追溯要求 |
| 软件单元验证 | CL1 | 项目风险等级评估 | 复用模块可简化验证范围 |
| 供应商监控 | CL2 | 存在外部供应商分工 | 无外部供应时可调整 |
完成标志是：清单覆盖了目标等级与合同要求涉及的全部过程域，每一项都有可追溯的来源，且已识别出哪些条目存在裁剪空间。
按项目特征逐项判断：裁剪依据与判断规则
范围确定后，对清单中每个过程项做判断。常用裁剪依据有五类：产品类型（嵌入式软件、应用软件、系统集成）、变更幅度（新开发、派生、维护）、复用程度（全新、平台复用、模块复用）、供应商分工（自研为主、外包为主、多方协作）、风险等级（安全相关、功能相关、一般）。判断时把依据落到具体过程项上，而不是笼统地给项目贴一个“低风险”标签。
裁剪决定分为三类，适用情形不同：
- 保留：过程目标与实施方式均按组织标准执行。适用于安全相关、客户明确要求、风险较高的过程项。
- 简化：过程目标不变，减少实施频次、合并活动或降低证据粒度。适用于复用程度高、变更幅度小的模块，例如复用模块的单元验证可依据复用评估结论缩小范围。
- 调整实施方式：过程目标不变，改变实现路径。适用于供应商分工场景，例如由供应商提供过程证据、本方执行监控与验收，替代本方全流程执行。
判断表建议包含过程项、决定、依据、影响说明四列。依据要写到可核验的程度，例如“该模块为平台复用件，复用评估报告编号XXX，接口未变更”，而非“复用度高”。影响说明要写清裁剪后对下游活动、证据采集和评估准备的影响，例如“单元验证范围缩小后，集成测试需增加接口覆盖以补偿”。
裁剪记录怎么写：字段与示例
裁剪记录是评审和评估时的核心证据，字段应覆盖：过程项、原要求（标准或合同中的原始条款）、裁剪决定、依据、替代证据、影响与风险。替代证据一栏尤其关键，它说明裁剪后用什么材料证明过程目标仍然达成。
一份完整填写示例如下（演示情景）：
| 字段 | 填写内容 |
|---|---|
| 过程项 | 软件单元验证 |
| 原要求 | 对所有软件单元执行单元测试并保留测试记录与覆盖率报告 |
| 裁剪决定 | 简化：复用模块仅对变更接口执行单元测试 |
| 依据 | 该模块为平台复用件，复用评估报告REU-012确认内部逻辑未变更，仅接口适配层修改 |
| 替代证据 | 变更接口的单元测试记录、复用评估报告、接口适配层的代码评审记录 |
| 影响与风险 | 内部逻辑缺陷依赖平台既有验证覆盖；风险为接口适配引入的集成问题，通过增加集成测试用例补偿 |
常见填写问题有三类：依据空泛，只写“项目规模小”“时间紧”，无法核验；替代证据缺失，写了简化却没有说明用什么证明目标达成；影响未评估，裁剪后对下游活动和评估准备的影响没有交代。评审时这三类问题应直接退回补充。
角色分工与评审批准
裁剪不能由个人决定。提出人通常是项目负责人或过程工程师，负责识别裁剪需求并起草记录；过程负责人评估该过程项的目标是否仍能达成、实施方式调整是否在组织规则允许范围内；质量与安全角色评估风险是否可接受、替代证据是否可采集；项目负责人对整体裁剪方案批准并承担执行责任。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 提出人（项目负责人/过程工程师） | 识别裁剪需求，起草裁剪记录 | 裁剪记录初稿 |
| 过程负责人 | 评估过程目标可达性、实施方式合规性 | 过程评估意见 |
| 质量与安全角色 | 评估风险、替代证据可采集性 | 风险与证据评估意见 |
| 项目负责人 | 批准方案，承担执行责任 | 批准记录 |
评审关注三点：依据是否成立且可核验；替代证据是否能在项目运行中实际采集到；风险是否在可接受范围内并有补偿措施。批准后的记录应归档并与项目计划版本关联。触发重新评审的条件包括：项目范围或目标等级变更、供应商分工调整、复用评估结论变化、出现与裁剪前提不符的实际问题。
在研发管理工具中承载这套流程时，裁剪记录可以作为受控文档与项目计划关联，评审意见和批准状态随记录留存，后续变更触发时能直接定位受影响的裁剪条目。ONES支持文档与工作项的关联管理，可用于把裁剪记录、评审意见和项目计划放在同一处追溯，具体配置按团队现有流程设计。
裁剪结论如何落到项目执行与证据
批准后的裁剪结论要进入项目计划：每个裁剪决定对应到具体的过程活动、工作项和评审节点，明确谁在什么时点采集替代证据。例如“简化单元验证”对应到集成测试阶段增加的接口覆盖用例，责任人为测试负责人，采集时点为集成测试完成时。
建议维护一份对应清单，把裁剪条目、落地活动、证据名称、采集时点、责任人逐项列出。这份清单同时是评估准备时的检索入口：评估前按清单核对每项替代证据是否已实际产生、版本是否为当前有效版本。
项目运行中要定期复核裁剪前提。当出现需求大幅变更、复用模块被修改、供应商交付方式调整等情况时，原裁剪依据可能不再成立，需要重新评估并走再批准流程。复核周期可与项目里程碑对齐，在关键节点检查裁剪结论是否仍然有效。
完成检查：裁剪是否站得住
裁剪方案定稿前和评估前，可用以下清单逐项自查：
| 检查类别 | 检查项 | 不通过时的处理 |
|---|---|---|
| 范围完整性 | 目标等级与合同要求涉及的过程域是否全部覆盖；是否有过程目标被当作可裁剪项取消 | 补全范围清单，恢复被误删的过程目标 |
| 依据充分性 | 每条裁剪依据是否可核验、是否与项目实际特征一致 | 补充可核验材料或撤销该条裁剪 |
| 证据可采集性 | 替代证据是否已明确名称、时点和责任人，运行中能否实际产生 | 调整证据方案或改为保留原实施方式 |
| 批准与版本一致性 | 记录是否经规定角色批准，是否与当前项目计划版本一致 | 补走评审批准，更新关联版本 |
任何一类不通过，都应回到对应环节修正后重新评审，而非在检查表上标注“已知悉”放行。复核周期建议与项目里程碑对齐，触发条件包括范围变更、复用结论变化、供应商分工调整和评估前准备。裁剪方案站得住的标准是：每条裁剪都能说清依据、替代证据和影响，且在评估时能当场取出对应材料。
常见问题
项目规模小、周期紧，能不能直接删掉部分过程域？
不能按工作量直接删减过程域。过程目标属于必须保留的部分，项目规模小、周期紧影响的是实施方式和证据粒度，例如减少评审频次、合并活动或调整记录形式。如果确实存在不适用于本项目的过程域，需要在初始范围清单中写明来源依据（如合同未要求、组织过程资产允许），并经过评审确认，而不是以“时间紧”作为裁剪理由。
复用模块的裁剪依据，评估时通常要看哪些材料？
复用程度是常见的裁剪依据，但需要落到可核验的材料上。通常包括复用评估报告（说明模块内部逻辑是否变更、接口是否修改）、变更记录、接口适配层的评审记录，以及针对变更部分补充的验证记录。裁剪记录中应写明这些材料的名称或编号，并说明它们如何支撑“过程目标仍然达成”的结论。仅有“复用度高”的描述，评审时难以成立。
裁剪结论批准后，项目中途哪些情况需要重新评审？
当裁剪所依赖的前提发生变化时，需要重新评估并走再批准流程。常见触发情形包括：项目范围或目标能力等级调整、需求大幅变更、复用模块被修改导致原复用评估结论失效、供应商分工或交付方式调整，以及运行中出现与裁剪前提不符的实际问题。复核周期可与项目里程碑对齐，在关键节点检查裁剪结论是否仍然有效，避免评估时才发现依据已不成立。
替代证据应该在什么时点采集，由谁负责？
替代证据的采集时点和责任人应在裁剪结论落到项目计划时一并明确。做法是维护一份对应清单，把裁剪条目、落地活动、证据名称、采集时点、责任人逐项列出，例如“简化单元验证”对应集成测试阶段增加的接口覆盖用例，由测试负责人在集成测试完成时采集。这份清单同时作为评估准备时的检索入口，评估前按清单核对证据是否已实际产生、是否为当前有效版本。
裁剪记录和项目计划怎么保持版本一致？
批准后的裁剪记录应与项目计划版本关联，记录中体现批准角色和批准状态。当项目计划因范围、进度或分工调整而更新时，需要检查受影响的裁剪条目是否仍然成立，必要时重新评审并更新关联关系。在研发管理工具中，可以把裁剪记录作为受控文档与项目计划、评审意见放在同一处追溯，变更触发时直接定位受影响的条目；具体配置按团队现有流程设计。
