ASPICE 核心逻辑：V 模型、追溯性与过程评估

ASPICE 的底层逻辑用一句话概括：V 模型左侧需求逐层分解，右侧验证逐层收敛，中间靠追溯性串联。抓住这条主线，22 个过程域就不再是散落的表格。

ASPICE（Automotive SPICE）是基于 ISO/IEC 15504 的车载嵌入式软件过程评估模型，由奥迪、宝马、奔驰、大众、福特、保时捷、沃尔沃等主机厂联合推动。它的本质是一套评估供应商软件过程能力的标准。当前版本 V3.1，发布于 2017 年。

很多工程师接触 ASPICE 后的第一反应是：过程域、基本实践、工作产品、能力级别……信息量爆炸，像在背说明书。培训时觉得都懂了，回到项目不知道从哪下手。

根本原因是把 ASPICE 当成了"要填的表"。实际上 ASPICE 的 22 个过程域围绕一个 V 模型 组织，每个过程内部遵循相同的结构模式，过程之间靠追溯性和一致性串联。理解这三条主线，所有过程域的要求自然就通了。

V 模型：左侧分解，右侧收敛

V 的左侧是需求逐层分解：SYS.1 需求挖掘 → SYS.2 系统需求分析 → SYS.3 系统架构设计 → SWE.1 软件需求分析 → SWE.2 软件架构设计 → SWE.3 软件详细设计和单元构建。每一层把上一层的产出作为输入，分解出更细粒度的需求或设计。

V 的右侧是验证逐层收敛：SWE.4 软件单元验证 → SWE.5 软件集成和集成测试 → SWE.6 软件合格性测试 → SYS.4 系统集成和集成测试 → SYS.5 系统合格性测试。从最底层开始验证，逐层向上收口。

左侧每个过程做的事，右侧都有对应过程来验证。SYS.2 定义了系统需求，SYS.5 用合格性测试来验证；SWE.1 定义了软件需求，SWE.6 来验证。V 模型的每一层都是一对"定义 - 验证"关系。

V2.5 版本中所有工程过程用 ENG 统一编号，V3.1 按领域拆分为 SYS 和 SWE，并引入了"插件"概念——顶层是系统过程，具体工程领域（软件 SWE、硬件 HWE、机械 MEE）可以按需加入评估范围。

左侧：需求分解的六层

需求分解从利益相关方需求开始。SYS.2 把它转化成一组可验证、可追溯的系统需求，同时定义验证准则。SYS.3 建立系统架构，将系统需求分配给各系统要素，定义要素之间的接口和动态行为。

进入软件层后，SWE.1 从系统需求中提取软件相关的部分，转化为软件需求。SWE.2 建立软件架构，将软件需求分配到架构要素，定义资源消耗目标。SWE.3 进一步分解到软件单元，写出详细设计，生成可执行代码。

每一层做三件事：定义需求或设计 → 建立与上游的追溯性 → 沟通给下游。

右侧：验证收敛的五层

验证从代码级别开始。SWE.4 通过静态分析、代码评审和单元测试验证软件单元是否符合详细设计。SWE.5 将单元集成到完整的软件，测试架构层面的接口和交互。SWE.6 对完整的集成软件做合格性测试，验证是否符合软件需求。

然后进入系统层面：SYS.4 集成系统项并测试接口，SYS.5 对完整系统做合格性测试。

每一层做三件事：制订测试策略 → 执行测试并记录结果 → 建立测试与被验证对象之间的追溯性。

右侧有一个关键概念：符合架构设计。SWE.5 和 SYS.4 的集成测试不是测功能，而是证明组件之间的接口和交互满足架构设计定义的规范——数据流是否正确、时序依赖是否满足、资源消耗是否达标。

追溯性与一致性：贯穿全程的红线

V3.1 把追溯性和一致性从一个基础实践拆分为两个独立实践。追溯性是工作产品之间的引用或链接关系，支持覆盖率分析、影响分析和需求实现状态跟踪。一致性是所有追溯的引用可用（无缺失）且正确（未连错），通过评审来验证。

追溯性是评估中最容易被扣分的地方。左侧要求需求到设计的追溯，右侧要求需求到测试用例、测试用例到测试结果的追溯。V3.1 新增了两项追溯要求：测试用例与测试结果、变更请求与受影响工作产品之间的追溯。在实际项目中，追溯性通过 ALM 工具（Polarion、DOORS 等）实现，而不是手工维护表格。

每个过程的共同结构

ASPICE 的过程域虽然内容不同，但结构高度统一。每个过程包含：过程目的（一句话说明做什么）、过程成果（成功后的 4-8 条结果）、基本实践（具体活动）、输出工作产品（带编号的产出物列表，如 08-52 测试计划、13-22 追溯记录）。

基本实践中，几乎每个过程都有三个固定项：建立双向可追溯性、确保一致性、沟通约定的结果。区别只在追溯的对象不同。理解了一个过程域的结构，就能快速读懂其他过程域——核心逻辑是相同的。

能力级别与评估

ASPICE 定义了 6 个能力级别：Level 1 已执行（有产出）、Level 2 已管理（过程被计划和监控，工作产品受控）、Level 3 已建立（过程被标准化定义并部署）、Level 4 可预测（过程被度量并控制）、Level 5 创新（过程持续改进）。

大多数供应商的目标是 Level 2。

评分使用四级尺度：N（0%-15%）、P（15%-50%）、L（50%-85%）、F（85%-100%）。Level 2 要求 PA 1.1（过程实施）达到 F，PA 2.1（实施管理）和 PA 2.2（工作产品管理）达到 L 或 F。

评分有约束：PA 2.1 和 PA 2.2 不能高于 PA 1.1——过程本身都没做好，管理和文档化做得再好也上不去。

评估实操

评估按独立性分 Type A/B/C/D 四种，Type A 最严格，评估组完全独立。评估类别（Class 1/2/3）决定每个过程需要几个项目实例——Class 1 至少 4 个，Class 3 只需 1 个。

评估组组长必须是 intacs 认证的 Principal 或 Competent Assessor，成员至少是 Provisional Assessor。典型 Type A、Class 3、VDA Scope Level 2 评估需要 5 天。

评估内容分两部分：将公司标准过程与 ASPICE 对标，以及评价具体项目的过程执行情况。过程完全缺失则不再进一步评估，部分缺失则按标准打分。

过程改进路径

准备评估不是临时抱佛脚。推荐路径：差距分析 → 过程定义 → 试点运行 → 推广 → 预评估。核心原则是渐进改进胜过激进改进——逐步适应，不影响商业目标。正式评估前 2-3 个月做一次预评估，把流程走一遍，不符合项及时纠正。

过程改进涉及三个维度：人、过程、技术，三者需要协同推进。目标可以从三个层面理解：缩短交付时间（过程透明、可度量、关注重用）、降低成本（一次成功，降低损失成本）、提高产品质量（产品质量由过程质量保证）。

支持过程：V 模型的基建

除了工程过程，支持过程为 AUTOSAR 项目中 V 模型的运行提供基础设施。

• SUP.1 质量保证：独立且客观地检查工作产品和过程是否符合规定。关键要求是"独立性"——质量保证人员不能有利益冲突。V3.1 新增了管理层确保解决已升级不符合项的明确要求，建立了从发现到升级的完整闭环。
• SUP.8 配置管理：维护所有工作产品的完整性。V3.1 新增分支管理要求，适应并行开发场景。核心活动是识别配置项、建立基线、控制修改和发布。基线是经正式评审并达成一致的规范或产品，只有通过正式变更控制规程才能更改。
• SUP.9 问题解决管理：确保问题从识别到关闭的全生命周期管理。V3.1 强调趋势分析——不只是记录问题，还要从数据中识别趋势提前预警。
• SUP.10 变更请求管理：覆盖变更请求的审批、实施和追溯。关键实践是实施前审批、实施后评审，以及建立变更请求与受影响工作产品之间的双向追溯性。
• MAN.3 项目管理：将 V2.5 的 12 条基本实践精简为 10 条，核心变化是将可行性评估独立出来，强调项目目标在可用资源和约束条件下的可实现性。
• ACQ.4 供应商监控：要求约定联合过程和接口，定期评审供应商的技术进展和进度，适用于供应商为客户开发组件、提供现成组件或混合交付的场景。

V2.5 到 V3.1 的关键变化

V3.1 的变化集中在三条主线：

• 结构重组：工程过程从统一的 ENG 编号拆分为 SYS 和 SWE，引入插件概念。追溯性和一致性从一个实践拆分为两个。单元构建与验证从合并变为分离。
• 实践精简：各支持过程的 BP 大幅精简——SUP.1 从 10 条变 6 条，SUP.10 从 13 条变 8 条，MAN.3 从 12 条变 10 条。核心思路是把"跟踪记录"和"报告"合并为"总结和沟通"，把"维护证据"融入执行过程的记录要求。
• 追溯性扩展：右侧过程从"验证"改为"测试"，独立出"选择测试用例"步骤。新增测试用例到测试结果、变更请求到受影响工作产品的追溯要求，体现了对测试过程更完整的覆盖。

ASPICE 的标准文件和评估工具在不断演进，但核心逻辑从未改变：需求分解要完整，验证闭环要严密，追溯链条不能断。这三点做到了，评估只是走个流程。