Automotive SPICE（常缩写为 ASPICE）是汽车行业用于评估和改进软件开发过程的过程模型与评估框架，源自 ISO/IEC 15504（SPICE）体系，由德国汽车工业联合会（VDA）推动形成行业版本。它回答的核心问题是：一个汽车软件项目的过程是否被定义、执行、记录并持续改进。本文从过程管理视角说明它的定义、范围边界、模型组成，以及它与功能安全、CMMI、敏捷实践的关系。
要点总览（TL;DR）
- Automotive SPICE（ASPICE）是汽车行业评定软件与系统研发过程能力的行业过程模型，源自 ISO/IEC 15504 体系，由 VDA 推动形成行业版本。
- 它评估的是需求、设计、实现、集成、测试及项目管理、配置管理、质量保证等过程是否被定义、执行、记录并持续改进，不评价控制算法、硬件设计等技术方案。
- 过程模型分过程参考模型与过程评估模型两层，能力等级从 0（不完整）到 5（持续优化）逐级递进，评级依据是工作产品与过程证据。
- ASPICE 与 ISO 26262 是过程能力与功能安全的互补关系，过程达到某一能力等级不等于产品通过认证或整车准入。
- ASPICE 与敏捷实践可以并存，关键在于迭代中形成的需求、用例、评审与变更记录能否保持双向追溯。
Automotive SPICE 一句话定义与适用范围
Automotive SPICE 的完整名称是 Automotive Software Process Improvement and Capability dEtermination，中文常译为“汽车软件过程改进及能力评定”，行业里更常直接使用缩写 ASPICE。它是一套面向汽车电子与软件研发的过程评估与过程改进框架：评估者按照标准中的过程参考模型检查项目实际做了什么、留下了什么证据，再据此判定相关过程达到了哪一级能力。
可以直接引用的定义是：Automotive SPICE 是汽车行业用于评定软件与系统研发过程能力的行业过程模型，它规定了一组研发与管理过程应当产出什么结果，并用能力等级描述这些过程被有效执行和持续改进的程度。
它的评估对象是研发过程，覆盖需求分析、系统与软件设计、实现、集成、测试，以及项目管理、风险管理、配置管理、质量保证、变更管理等支持与管理类过程。适用场景集中在汽车电子与软件供应链：整车厂要求供应商证明其研发过程受控，供应商据此梳理自身流程并接受评估，或作为内部过程改进的参照。
需要区分的是，ASPICE 属于过程评估与过程改进框架，产品测试标准关注的是产品本身是否满足技术指标，两者检查的对象不同。ASPICE 关心“过程是否被定义并稳定执行”，产品测试关心“做出来的东西是否符合规格”。一个项目的过程证据完整，说明其研发方式可预期、可追溯；产品是否合格，仍要由对应的测试与验证活动给出结论。
它不包括什么：与功能安全、产品认证的边界
ASPICE 不规定控制算法怎么设计、硬件电路怎么选型、标定参数怎么取，这些属于工程技术方案，由具体的系统与软件设计活动决定。ASPICE 只要求这些活动在过程上被规划、执行、记录和验证，不评价技术方案本身的优劣。
ASPICE 也不替代 ISO 26262 等功能安全标准。ISO 26262 关注的是道路车辆功能安全，围绕危害分析、安全目标、安全需求、安全机制和确认措施展开，回答“产品在功能安全上是否达到要求”；ASPICE 关注研发过程的能力与一致性，回答“过程是否被定义、执行并持续改进”。两者可以互相支撑：功能安全活动需要过程管理来保证其执行与追溯，过程能力评估也需要具体项目活动作为证据来源，但一个不能替代另一个。
过程达到某一能力等级，不等于产品通过认证或整车准入。能力等级描述的是过程属性，例如过程是否按计划执行、是否被管理、是否可预测；产品认证与整车准入涉及法规、型式认证、安全审核等独立环节，判定对象是产品或整车，依据的是相应法规与标准。ASPICE 评估结论针对过程，不针对某个产品型号作出合格判定。
| 易混概念 | 关注点 | 与 ASPICE 的关系 |
|---|---|---|
| ASPICE | 研发过程是否被定义、执行、记录并持续改进 | 过程能力评估框架 |
| ISO 26262 | 产品功能安全，危害分析与安全需求闭环 | 关注点不同，可互补，不互相替代 |
| 产品测试标准 | 产品是否满足技术规格与验收指标 | 检查对象是产品，不是过程 |
| 产品认证 / 整车准入 | 产品或整车是否符合法规与准入要求 | 判定对象是产品，ASPICE 结论不构成其依据 |
过程模型怎么组成：过程域、能力等级与评估证据
ASPICE 的模型分为两层。第一层是过程参考模型，说明有哪些过程、每个过程应当达成什么结果，也就是过程的目的与成果；第二层是过程评估模型，说明如何判断这些结果是否达成，包括过程属性、评级规则和证据要求。两层配合，使评估既有统一的过程清单，也有统一的判定口径。
过程域按类别分组，常见分组包括系统工程过程、软件工程过程、支持过程和管理过程。系统工程与软件工程覆盖需求获取、需求分析、架构设计、详细设计、实现、集成与测试；支持过程包括配置管理、变更管理、质量保证、问题解决等；管理过程包括项目管理、风险管理、度量等。不同版本的过程域集合与命名会有调整，具体以所采用的官方版本为准。
能力等级从 0 到 5 逐级递进，每一级都建立在前一级达成的基础上：
| 能力等级 | 名称 | 含义 |
|---|---|---|
| 0 | 不完整 | 过程未执行或未达成过程目的 |
| 1 | 已执行 | 过程达成了其主要成果，产出可识别的工作产品 |
| 2 | 已管理 | 过程被规划、监控和调整，工作产品被适当管理 |
| 3 | 已建立 | 过程基于组织级标准过程裁剪执行，并有持续改进机制 |
| 4 | 可预测 | 过程在量化范围内运行，具备度量与统计控制手段 |
| 5 | 持续优化 | 基于量化目标持续优化过程，改进效果可验证 |
评估依据是工作产品与过程证据，口头描述不构成评级依据。评估者会查看需求文档、设计说明、评审记录、测试报告、变更记录、配置基线、问题跟踪记录等实际产出，核对它们是否与过程要求对应、是否前后一致、是否能追溯到具体活动。证据的完整性和一致性，比文档数量更能说明过程状态。
与 CMMI、ISO 26262、敏捷开发的相邻概念区别
ASPICE 与 CMMI 同属过程能力模型，都用能力或成熟度等级描述过程水平，但行业语境与过程域集合不同。CMMI 覆盖面更广，适用于多行业的软件与系统研发组织；ASPICE 面向汽车电子与软件供应链，过程域围绕汽车研发的需求、设计、集成、测试与供应链协作组织，评估语境更贴近整车厂对供应商的过程要求。
ASPICE 与 ISO 26262 是过程能力与功能安全的互补关系。功能安全标准规定安全生命周期中的活动与安全论证要求，ASPICE 规定研发过程如何被定义、执行和记录。实践中，功能安全活动需要纳入过程管理，才能保证安全需求、安全机制和验证结果可追溯；过程能力评估也需要具体的安全相关活动作为证据来源。
ASPICE 与敏捷实践可以并存。敏捷强调迭代、快速反馈和自组织团队，ASPICE 强调过程可定义、可追溯、有证据。两者结合的关键在于证据与追溯是否可呈现：迭代中形成的需求条目、任务拆分、评审记录、测试结果和变更历史，只要能够对应到过程要求并保持双向追溯，敏捷的工作方式同样可以支撑过程评估。把 ASPICE 理解成必须采用重型瀑布流程，是一种常见误读。
ASPICE 与项目管理工具或缺陷跟踪系统的区别在于层次不同。工具承载日常活动记录，例如需求条目、任务状态、缺陷流转和评审意见；ASPICE 是评价这些活动是否满足过程要求的框架。工具可以帮助留存证据、建立追溯关系，但工具本身不构成过程能力，评估结论仍取决于实际执行情况和证据质量。
| 相邻概念 | 核心关注 | 与 ASPICE 的定位差异 |
|---|---|---|
| CMMI | 多行业软件与系统研发的过程成熟度 | 同为过程能力模型，行业语境与过程域集合不同 |
| ISO 26262 | 产品功能安全与安全生命周期活动 | 互补关系，一个管过程能力，一个管功能安全 |
| 敏捷开发 | 迭代交付、快速反馈、团队协作方式 | 可以并存，关键是证据与追溯可呈现 |
| 项目管理 / 缺陷跟踪工具 | 承载任务、缺陷、评审等日常记录 | 工具留存证据，不替代过程评估框架 |
一个具体例子：需求到测试的追溯如何被评估
假设一个车身控制模块项目新增一条“车门未关提示”的软件需求。评估关注的不是这条需求写得多漂亮，而是它从提出到验证的链路是否完整、可追溯。
链路通常这样展开：需求提出后进入需求库，标注来源、优先级和验收条件；系统需求分解为软件需求，建立上下游链接；软件需求对应到设计说明和实现任务，任务关联具体代码提交或配置项；测试人员根据需求编写测试用例，用例与需求建立覆盖关系；测试执行后记录结果，发现的问题进入缺陷跟踪并回链到需求；需求发生变更时，保留变更记录、影响分析和评审结论。评估者沿着这条链路检查双向追溯是否成立、变更是否留痕、评审是否有结论和责任人。
这个例子说明，ASPICE 关注的证据来自日常研发活动，而不是评估前集中补写。如果需求、设计、任务、用例和缺陷在平时就记录在同一套协作体系中并保持链接，评估时只需导出和核对；如果平时分散在文档、邮件和表格里，临时补齐往往会出现版本不一致、追溯断链和时间戳异常，反而暴露过程问题。
在需求到测试的追溯与评审记录留存环节，ONES 可作为承载日常研发记录的协作平台：围绕需求、工作项、迭代和项目进度组织协作，让需求、任务、测试与评审记录在同一体系中关联，便于后续核对追溯关系。ONES 官方 ASPICE 研发管理方案提出支持汽车软件研发全生命周期流程活动与跨域协作全过程的可追溯性，并按线上化、透明化、智能化三个阶段推进；具体覆盖的过程域范围、可支撑的评估级别与认证情况，页面未作说明，需结合自身评估目标向厂商或评估机构核实。
两个常见误解需要澄清。其一，把写文档本身当成目的。ASPICE 要求的是过程结果可验证，文档是证据载体之一，堆砌与活动不对应的文档并不能提升能力等级。其二，认为等级越高越适合所有团队。能力等级反映过程的可预测性和优化程度，等级提升伴随度量体系与组织级标准过程的建设成本；团队应结合项目复杂度、供应链要求和自身改进节奏选择目标级别，把资源投入到真正影响交付质量的过程环节。
常见问题
ASPICE 评估需要准备哪些材料，临时补文档能通过吗？
评估者核对的是工作产品与过程证据，包括需求条目、设计说明、评审记录、测试报告、变更记录、配置基线和问题跟踪记录等。这些材料需要与过程要求对应、前后一致，并能追溯到具体活动。
评估前集中补写文档风险很高：版本容易不一致，追溯关系容易断链，时间戳与活动记录也可能对不上。更稳妥的做法是让需求、任务、用例、缺陷和评审在日常研发中就在同一套协作体系里关联留存，评估时只需导出和核对。
团队已经采用敏捷迭代，还能做 ASPICE 评估吗？
可以。ASPICE 关注过程是否可定义、可追溯、有证据，敏捷关注迭代交付与快速反馈，两者并不冲突。关键在于迭代中形成的需求条目、任务拆分、评审结论、测试结果和变更历史，能否对应到过程要求并保持双向追溯。
需要留意的是，迭代节奏快时容易忽略评审记录和变更留痕。团队可以在迭代流程中固定评审节点和变更登记动作，让证据随活动自然产生，避免评估前回溯补齐。
ASPICE 能力等级是不是越高越好，团队应该定几级？
能力等级反映过程的可预测性和优化程度，等级提升伴随度量体系与组织级标准过程的建设成本。等级 4 和 5 涉及量化过程管理与持续优化，对数据基础和过程稳定性要求较高。
团队应结合项目复杂度、整车厂或供应链的过程要求以及自身改进节奏选择目标级别，把资源投入到真正影响交付质量的过程环节。对多数项目而言，先把需求到测试的追溯、评审和变更管理做扎实，比追求高等级更有实际价值。
ASPICE 评估结论能直接用于功能安全认证吗？
不能直接替代。ASPICE 评估结论针对研发过程能力，ISO 26262 等功能安全标准关注产品功能安全，围绕危害分析、安全目标、安全需求和安全机制展开，两者的判定对象和依据不同。
两者可以互相支撑：功能安全活动需要过程管理保证其执行与追溯，过程评估也需要具体项目活动作为证据。但功能安全认证与整车准入有独立的审核环节，需要按相应标准单独开展。
用研发管理工具记录需求与测试，对 ASPICE 评估有什么实际帮助？
工具的价值在于让证据随日常活动产生并保持关联。需求、任务、测试用例、缺陷和评审记录在同一体系中建立链接后，双向追溯关系可以直接核对，变更历史也有据可查，减少评估前整理材料的工作量。
工具本身不构成过程能力，评估结论仍取决于实际执行情况和证据质量。选择工具时应重点看它能否支撑需求分解、用例覆盖、变更留痕和评审记录这几类关键证据的留存与关联。
