目录

1. 什么是ASPICE？
2. ASPICE发展历程
3. ASPICE的导入范围
4. 导入ASPICE要花多少时间
5. 如何计划导入ASPICE？

什么是ASPICE？

Automotive SPICE（简称A-SPICE 或 ASPICE）是汽车产业的系统流程改进和能力测定标准，目前盛行于汽车供应链，是车厂对供应商进行系统（包含软件、硬件）开发过程评估的标准。

ASPICE源自于 ISO 12207 及 ISO 15004–5：2006 提供的重评估模型，目前由VDA WG13 （德国汽车联合公会工作小组13）发行，并且由VDA注册商标。 现在最新的ASPICE标准是在2023年12月15日发布的4.0版本（该文件于2023年11月29日发行）。

从ASPICE的英文缩写，可以得知这是专属于汽车产业的标准，A代表着Automotive、SPICE则为「系统流程改进和能力测定」（ System Process Improvement and Capability dEtermination）是由国际标准化组织ISO、国际电工委员会IEC、信息技术委员会JTC1发起制定的ISO 15504标准、及后续改版的ISO 330XX系列标准，延伸发展而来。

在ASPICE 3.1版本之前，英文字母「S」代表「软件」。 然而，在ASPICE标准的最新版本中，范围已不仅限于软件工程。 此版本不仅扩展至包括硬件工程和机器学习工程等多种工程流程，因此，英文字母「S」的含义已经悄悄转变为「系统」。

在过去，业界普遍认为当产品涉及软件开发时，才需要遵循ASPICE标准。 然而，随着标准及流程的改善，现今情况已大不相同。 目前，几乎所有的「车用产品」都必须符合这一标准。

下载 ASPICE 标准：

• ASPICE 英文版（v3.1）
• ASPICE 简体中文版（v3.1）
• ASPICE 英文版-草稿版（v3.991）
• ASPICE 英文版-正式版（v4.0）

ASPICE标准包含3个部分（请参考下图），分别为流程参考模型、量测架构、流程评估模型。 其中 ：

• 流程参考模型（Process reference model）： （Automotive SPICE 相关）根据项目执行所需，共定义了32个流程，并且详加定义了各流程的范围、目的、主要产出。
• 量测架构（Measurement framework）： 主要继承ISO/IEC 33020中的定义，包含能力等级（各定义了6个等级）、流程属性、评分规模、评分方法、 合计方法、流程能力等级模型等。
• 流程评估模型（Process assessment model）： （Automotive SPICE 相关）针对各流程定义了流程能力指标及流程实施指标。

过程参考模型与过程评估模型的关系

ASPICE的评鉴师将基于企业所选定的 流程范围 （X轴），并参考量测架构所定义的 能力维度 （Y轴）及流程评估模型所定义的能力指标与实施指标来逐一为每个流程进行评分。 其评分后的结果如下图，最终的证书也将条列所有流程及其等级。

X轴为企业所选定的评鉴范围，Y轴为能力等级，最终每个流程都会有自己的评估结果

ASPICE的分级

针对公司的软件流程改进和能力进行测定，目前共分为6个等级，分别为Level 0 到 5级 （请参考下表）：

ASPICE的6个能力等级，从Level0到Level5

• 1级：已执行：
  主要的要求是达成欲导入流程的基础实践（Base Practice）及工作产出（work product）要求。
  
• 2 级：已管理：
  主要特征分成两个部分：
  1） 针对欲执行的流程进行计划，并针对流程执行的过程过程进行数据的采集，并根据所采集的数据评估流程的执行绩效;
  2）针对流程的工作产品进行定义及相应的建构管理。
  
• 3 级：已建立：
  主要特征分成两个部分：
  1） 公司应定义标准流程程且制定了流程裁剪规则;
  2） 公司标准过程能根据项目的属性与特征裁剪成项目的专用流程，并在项目中执行。
  
• 4级：可预测：
  主要特征是流程的执行按量化的标准去度量，且能根据度量结果去控制项目的进展。
  
• 5 级：优化：
  主要特征是公司能从项目执行中收集数据，并优化执行流程，且持续进行流程改进。

2. ASPICE发展历程

ASPICE自发布以来，被车厂广泛的用于平价供应商的「研发流程与能力」。 随着车联网、自动驾驶、新能源汽车的迅速发展，及大规模的汽车召回事件。 车用软件在汽车产业研发中的比重大大提升，车厂对软件质量管理的需求不断增强。

CMM — 1987

ASPICE标准是建立在CMM的基础上发展的，CMM全名是Capability Maturity Model，是由卡耐基梅隆大学（CMU）的软件工程研究所（SEI）于1987年所发展出来的审核投标厂商资格的理论模型，后来被广泛应用于软件流程改善和软件研发团队能力评价。

早期，车厂需求文件中提到作软件流程认证可以选用CMMI或ASPICE，当时CMMI评估师也可以直接获得ASPICE审核员资格。 随着车用软件的发展与ASPICE标准的改版，现在ASPICE与CMMI已经分道扬镳。

SPICE — 1994

1994年，国际标准化组织（ISO）、国际电工委员会（IEC）和信息技术委员会JTC1联合制定并发布了国际标准ISO/IEC15504，又称SPICE（Software Process Improvement and Capability dEtermination），这个标准专为软件公司设计， 旨在改进软件开发过程及评估公司应用的流程的有效性。

不同产业/领域的软件特性特性不同，因此，各产业/领域亦基于SPICE标准，发展出各自的不同的版本：

• 汽车 SPICE
• 医疗设计产业：Medi SPICE
• 航空网站：SPICE 4 Space （S4S）
• 测试SPICE
• 企业名称：Enterprise SPICE
• 裁剪和延展： SPiCE in Action — 剪裁和扩展的经验

ASPICE — 2005, 2010

2005年汽車行業的SPICE：Automotive SPICE從ISO體系中獨立出來，由德國汽車工業聯合會(VDA)的品質管理中心(QMC)運營發展，發布了ASPICE第一個版本：ASPICE v2.0。

在2010年，ASPICE改版成v2.5；在v2.5版中，PAM與PRM是分開的兩份文件，且在這個版本中所有工程流程的編號皆為ENG開頭。

ASPICE 3.0 — 2015

2015，ASPICE再次改版; 在文件上的结构上有许多的修订，包括：

• 将PRM和PAM合二为一
  (在这之前，PRM跟PAM是兩份不同的文件)
• 内文也有增加了比较细节的说明
  (針對基礎實踐BP的部分)
• 将一致性（Consistency）与追溯性（Traceability）从一个基础实践（BP），拆成两个基础实践（BP）
  (這表示業界覺得一致性與追溯性是不同的，而且需要特別注意)
• 针对工程流程（ENG）拆分为系统工程流程（SYS）和软件工程流程（SWE）
  （传统以为ASPICE是只注意软件的品质，自从切分成SYS跟SWE两个部分后，ASPICE就不只是关注软件，也关注整体）
• 针对旧有的ENG.5， ENG.6 拆分成SWE.2， SWE.3， SWE.4
  （架构设计、细部设计、软件单元开发、软件单元验证、 被更细的切分出來）

ASPICE v2.5 与 ASPICE v3.1 的差异

ASPICE 3.1–2017

2017年，VDA QMC发布了当前最新版本ASPICE v3.1。 v3.1在v3.0的基础上仅做了一些勘误及微小改动（多数是文字的变更），并将HIS SCOPE改名为了VDA SCOPE。

ASPICE for Cybersecurity – 2021

2020年起，网络安全（Cybersecurity）的声量在业界越来越受到重视，VDA QMC为因应这个趋势，于2021年2月发布了ASPICE for Cybersecurity（ASPICE网络安全增订版）。 这份文件，修改并新增了网络安全的相关流程，笔者后续会再针对这份增订版详细说明。

ASPICE for Cybersecurity （ASPICE网络安全增订版）已经于2021年7月正式发布

ASPICE 4.0 – 2023

2023年底，VDA QMC的正式发表了ASPICE v4.0。

新版的ASPICE，加入了硬件工程流程、机器学习流程，并且也简化了许多流程。

3. 如何决定ASPICE的导入范围？

ASPICE v3.1版，共有32个关键流程;新增订版的ASPICE for Cybersecurity 又额外增加了6个流程; ASPICE 4.0版，亦加入了新的关键流程。 这么多的流程，该如何选定导入与验证范围呢？ 本篇文章， 笔者将简介ASPICE v3.1版的导入范围 。

ASPICE v3.1现有流程

为了促使汽车电子和软件供应商关注产品开发过程，提升过程质量。 ASPICE v3.1版本共定义了32个关键流程，分为3大类、8个流程组。

ASPICE v3.1 所定义的 3的大类、8个子分类、32个流程

从标准的流程图中，3大类流程，分别是：

• （橘色） 主要生命周期（Primary Life Cycle Processes）
• （蓝色） 组织生命周期（Organizational Life Cycle Processes）
• （绿色） 支持生命周期（Supporting Life Cycle Processes）

ASPICE流程（分成三个大类，八个领域，共计32个流程）

根据流程所侧重的活动型别不同，每个分类又被细分成8个子分类，每个子分类再定义各自的流程：

• 采购（ACQ： Acquisition） 主要生命周期
• 供应（SPL： Supply） 主要生命周期
• 系统工程（SYS： System Engineering） 主要生命周期
• 软件工程（SWE： Software Engineering） 主要生命周期
• 管理（MAN： Management） 组织生命周期
• 改進(PIM: Process Improvement) 組織生命週期
• 重用(REU: Reuse) 組織生命週期
• 支持(SUP: Supporting) 支持生命週期

ASPICE范围谁來決定？

在标准文件中，ASPICE并没有说明评估的范围，总数32个流程如果全部要导入，将会非常的旷日废时。 谁来决定ASPICE的范围？

答案是：与客戶共同商定的

在亞洲，常被要求的范围大致上，可以分為三個，分別是：

• VDA Scope
• VDA Extended Scope
• VDA Extended Scope (plus additional processes)

不同的ASPICE範圍：VDA Scope, VDA Extended Scope, VDA Extended Scope (plus additional process)

VDA Scope

为最基本，也是最常见的范围，为上图中「红色」框所圈选的范围 — 共计16个。

• ACQ.4： 供应商监控 采购 主要生命周期
• SUP.1： 质量管理 支持 支持生命周期
• SUP.8： 建构管理（或称 组态管理， 或称 配置管理） 支持 支持生命周期
• SUP.9： 问题管理 支持 支持生命周期
• SUP.10： 变更管理 支持 支持生命周期
• MAN.3： 项目管理 管理 组织生命周期
• SYS.2： 系统需求分析 系统工程 主要生命周期
• SYS.3： 系统架构设计 系统工程 主要生命周期
• SYS.4： 系统集成及集成测试 系统工程 主要生命周期
• SYS.5： 系统合格测试 系统工程 主要生命周期
• SWE.1： 软件需求分析 软件工程 主要生命周期
• SWE.2： 软件架构设计 软件工程 主要生命周期
• SWE.3： 软件细部设计及单元开发 软件工程 主要生命周期
• SWE.4： 软件单元验证 软件工程 主要生命周期
• SWE.5： 软件整合及整合测试 软件工程 主要生命周期
• SWE.6： 软件合格测试 软件工程 主要生命周期

VDA Extended Scope

是VDA Scope的延伸范围，这个范围通常是由16个VDA Scope提到的流程，外加4个或5个流程。 （通常SUP.2和SUP.4可以被归类为同一个）

• SYS.1： 需求获取 系统工程 主要生命周期
• MAN.5： 风险管理 管理 组织生命周期
• SUP.2： 验证 支持 支持生命周期
• SUP.4： 联合审查 支持 支持生命周期
• SPL.2： 产品发布 供应 主要生命周期

VDA Extended Scope (plus additional processes)

上述的VDA Scope（16个流程），和VDA Extended Scope（21个流程）为汽车供应链中最常被要求的两个范围，除此之外，不同国家的车厂亦会额外要求一些流程，这些被额外追加的流程通常包含但不限于下列：

• REU.2： 重复使用 管理 组织生命周期
• SUP.7： 文件化 支持 支持生命周期
• PIM.3： 流程改善 改进 组织生命周期

2023年后的范围趋势

VDA QMC在2023年12月，发布的ASPICE 4.0，该文件将ASPICE 3.1的许多流程删除，亦增加了许多新的范围，包含：

• 硬件工程流程 （Hardware Engineering）
• 机器学习工程流程 （Machine Learning Engineering）
• 確效流程 （Validation）

新版的ASPICE标准中，将会留有更多的活动与已经发布的ISO 26262：2018及ISO/SAE 21434进行整合，预计2023年后的项目流程范围除了既有的ASPICE流程之外，亦会提出整合功能安全与网宇安全等标准。

4. 导入ASPICE要花多少时间？

企业从导入ASPICE开始，到最后取得ASPICE的能力认证，需要多少的时间？ 这是笔者最常被问到的问题。 本篇文章将分享，从标准导入、项目实施、到最后取得ASPICE认证所需要花费的建议时间。

根据所需要导入的ASPICE及不同，其所需要的导入时间与工作量，也不同。 笔者将以VDA Scope（16个流程）的导入范围为基础，说明ASPICE Level 2与Level 3所需要的导入时间。 範圍 能力等級(Level)

ASPICE Level 2 – VDA Scope

ASPICE Level 2 导入時間 （VDA Scope）

ASPICE 在Level2的导入，建议分成三个阶段来进行。

• 起始规划：
  在确认要导入ASPICE流程前，建议先针对不同的流程指派对应的同仁。 由于，VDA Scope共有16个流程，每个流程所需要的能力与经验不同，因此在指派负责人员时，一定要确保其对流程及相关知识的完整性。
• 第一阶段：流程定义 （~5个月）
  在这个阶段中，主要的目的是针对16个流程进行流程定义，在这边，建议将ASPICE流程的BP要求撰写成实务可执行的步骤与方法，其中分别对应到二、三、四阶文件。 完成流程定义后，建议针对所有制定的文件，进行比对确认，务必要确保BP及GP的完整覆盖，并确保文件之间的一致性。

• 第二阶段：试做项目 （~5个月）
  接续第一个阶段，接着建议挑选一个“内部项目”，并搭配所制定的流程文件来执行。 在这个环节中，目的是放在流程文件的可执行性，让项目成员熟悉ASPICE的开发流程，并留下相对应的纪录与证据。
  建议挑选5个月左右能够执行完的项目，因为试做项目的目的仅止于磨合项目团队，建立项目开发流程的文化。 当试做项目完成，建议可以通过 预评鉴（pre-assessment） 来确认项目团队的执行成果，并以预评鉴的结果报告为基础，调整所制定的流程。
• 第三阶段：实作项目 （≥6个月）
  进入第三个阶段前，务必确保所制定的流程是合理且可以执行的; 另外也要确保，项目团队有熟悉ASPICE的开发流程并建立留下证据的文化。
  建议挑选一个正式项目（也可以是内部项目），项目的时程建议可以足够。 项目团队按着项目时程进行开发，并完成项目后，则可进行最后的 正式评鉴（formal assessment） ，并于评鉴后取得评鉴结果，与能力等级的认可。 累積6個月的證據

ASPICE Level 3 – VDA Scope

ASPICE Level 3 导入时间 (VDA Scope)

ASPICE 在Level3的导入，建议分成五个阶段来进行。

• 起始规划：
  ASPICE Level 3特别重视公司标准流程的制定及流程的改善。 因此，建议目标为Level 3的公司要先建立公司的，并针对这个流程改善团队定义章程与计划。 流程改善小組

• 第一阶段：流程定义 （~5个月）
  ASPICE Level 3的流程定义除了各别流程的BP要求之外，亦要流程的可裁减性（PA3.1及PA3.2）的要求。 假设公司并没有项目裁减的经验，建议先制定一套基本的项目开发流程，这个制定的过程可以参考ASPICE Level 2的做法，优先考量项目能够被有效的执行即可。
• 第二阶段：试做项目A （~5个月）
  流程定义结束后，建议先挑选一个项目来确保流程的有效性。 ASPICE Level 3除了要确保流程的有效性之外，亦要确认流程改善小组的执行状况，因此，在项目过程中（包含项目结束），项目团队必须定期的与流程改善小组沟通与回馈意见，藉此让流程改善小组知道项目执行的状况，并依此调整公司的项目标准作业流程。
• 第 三 阶段：试做项目B （~5个月）
  试做项目A结束后，笔者建议再另行挑选一个不同于项目A的项目，这边所谓的不同，指的是项目两者间存在不同的特性（characteristic），因为特性不同，所以在实作项目标准作业流程时，项目团队反馈的意见也不同。 流程改善小组，才能依此建立项目的裁剪表，提供给公司不同的项目进行流程的裁减。
  建议在第二次执行项目后，进行一次预评鉴，透过预评鉴的结果，可以让项目团队与流程改善小组了解与目标等级的差距，这份评鉴报告也可用来协助调整公司的标准作业流程。

• 第四阶段：流程定义调整 （~3个月）
  经历项目A与项目B后，在正式执行“待评鉴”的项目前，建议先稍缓让流程改善小组重新调整与改善公司的标准作业流程。 在这个阶段的调整重点是标准作业流程的裁剪指南，透过前述的项目经验及预评鉴的结果，来调整各流程的裁减指南。
  
• 第五阶段：裁减并实作项目 （≥6个月）
  执行最后一个阶段的项目前，务必要让项目团队使用各流程的裁剪指南，并根据项目的特性，进行流程裁减，裁减的结果必须与流程改善小组进行讨论与沟通。 确认完毕后，项目团队始可开始执行项目。
  值得一提的是，流程改善小组被视为项目团队的利益关系人，因此，彼此的沟通是必须先被计划的（对项目团队而言，存在项目计划中的沟通计划中; 对流程改善小组而言，存在流程行动计划中），沟通的证据，也必须适时的进行管理。
  ASPICE Level 3正式评鉴的重点，除了放在项目的执行外，亦重视项目所采用的流程的合理性（指的是裁减结果）与有效性（亦指流程改善小组的监控是否奏效）。 因此，评鉴过程中，流程改善小组与项目小组将会被交叉询问，以确保公司确实达到Level 3的要求。

值得思考的问题 – 同时考验项目团队与流程改善小组

问题： 项目团队在执行项目过程中，发现公司的标准作业流程存在问题，这个问题导致项目团队必须使用原先没有定义的方法来执行。 这个时候，该如何是好？

答： 因应ASPICE Level 3的要求，当项目团队发现这个问题时，应该先透过流程记录问题，并确实将问题提回馈给流程改善小组; 这个时候，项目团队可以与流程改善小组沟通解决的方法，待流程改善小组确认同意后，始可根据议定的解决方法来执行。 (SUP.9) (PA3.2)

延伸的问题： 新议定的法是否应该放入标准作业流程中？ 又该是何时放入？ 流程改善小组是否有一套评估项目团队解决方法的标准？

ASPICE标准，并没有将上述的情境仔细的定义，因此，这些项目层面会遇到的问题，必须先由公司制定相关的规则来进行管理。 对于ASPICE的评鉴老师来说，这些规则是否能够有系统地被执行，执行的过程会不会引申更多的问题，这些都是评鉴的重点。

最后笔者说： 这些问题，通常是在项目执行时，才会被发现的。 ASPICE标准并没有定义唯一的解答。 这些问题，就留给各公司自行定义与改善，这也是标准留下来的有趣的弹性。

5. 如何计划导入ASPICE？

ASPICE 导入概述

ASPICE标准的导入，与一般的ISO系统难度落差非常的巨大。 在导入ASPICE之前，多数的公司通常已经存在流程跟做法，只是这些做法没有被白纸黑字写下来; 因此，与其从头导入ASPICE，到不如从现有的基础上尽量做到标准的要求。

由于高度客制化，因此市场上几乎没有可共享的文件; 这也让想导入ASPICE的公司造成相当大的困扰; 如果要导入ASPICE，建议以下的步骤：

APSICE 导入步骤建议

1-1 教育训练

了解ASPICE的基础概念。 现行市场上主要存在2种教育训练，分别是标准认知训练Automotive SPICE standard cognitive training及「助理评审师训练Automotive SPICE provisional assessor training」; 这两个课程的差异是：

• 「标准认知训练 Automotive SPICE standard cognitive training」
  课程目标是让学员了解ASPICE标准，并能让后续导入标准，提供一些指引; 课程通常以ASPICE标准为主，针对标准条文要求，提交完整的认知训练。 这项课程，一般由业界的顾问公司进行培训，培训的内容通常也会说明与其他车用标准（例如： ISO 26262， ISO 21434）之间的关系。
• 「助理评鉴师训练 Automotive SPICE provisional assessor training」
  课程目标是让学员了解如何进行ASPICE评鉴; 课程通常以评鉴师需要注意的事项进行培训，另外，值得一提的是，这个课程通常需要由intacs认证的授课老师进行授课。 课程完成后，通常会安排考试，考试通过后即成为助理评鉴师（申请助理评鉴师将需要付费，且每三年需要付费维持相关资格）。

1-2 差距分析

ASPICE所讲述的流程，基本上属于项目开发流程，如果公司已经存在既有的流程，则建议透过差距分析，来评断公司的既有流程与ASPICE之间的差距，并藉由差距分析来规划后续所需要的资源。

值得一提的是，差距分析也可以用来评估项目的执行与ASPICE标准之间的差距。

2.流程定義

根据所选定的ASPICE范围（如何选定ASPICE的导入范围？ ），定义并撰写各流程的二、三、四阶文件; 如果项目有使用特定的工具，也建议撰写工具使用说明书。

二、三、四阶文件的定义如下：

• 二阶文件 – 程序书 （Procedure）
  针对ASPICE流程定义公司 执行的步骤 ，在程序书中应说明执行该流程的活动与相关任务，并透过EITVOX模型定义每个活动。
• 三阶文件 – 指导书 （Instruction）， 工具使用说明（Guideline）
  针对二阶程序书文件中所提到的任务 ，制定详细实施的做法。
• 四阶文件 – Template， 检查表 （Checklist）
  为二楼和三楼提到的资源制定相关的文件模板和清单。

EITVOX 模型： 二阶程序书文件的参考撰写模型

3.项目执行

根据ASPICE评分的说明，如果要拿到L或F的评鉴分数，那么就需要有系统化的做法。 最简单的系统性作法则是，根据已经定义好的流程，执行项目，并产出证据。

4.预评 鉴 （预评）

预评鉴将会针对已执行的项目，进行模拟评鉴，该评鉴方式将会以正式评鉴的模式做为基础。 评估项目执行与标准要求的差距。

执行预评鉴的目的是为了进行正式评鉴预演，让项目团队熟悉评鉴相关流程，提高通过正式评鉴的可能性。 另外一个目的是，预评鉴的发现将作为下一个项目（或下一个开发生命周期，即V-model）的输入需求。

一般来说，预评鉴的结果并不会有分数，也不会有证书。

5.正式评鉴（正评）

与预评鉴相同，正式评鉴也是针对已执行的项目进行评鉴; 差别是，评鉴完成后，公司将会收到正式的评估结果（包含各流程的能力等级）。

进行正式评鉴前，有几点特别需要注意：

• 确认项目执行证据的完整性
  进行正式评鉴之前，请务必确认项目已累积至少6个月的执行证据。 （针对小于6个月的项目，一般都需要再与客户与评鉴老师进行讨论，以确认评鉴的有效性）
• 选定评鉴老师
  ASPICE的评鉴通常会找首席评鉴师，或合格评鉴师进行评鉴，而且评鉴师的口碑也相当重要。 一般而言，建议公司先与客户确认评鉴师名单，再进行评鉴。
• 确认评鉴范围
  开始评鉴前，评鉴师会提供一份评鉴计划，该计划将会说明评鉴依据，评鉴范围，评鉴的注意事项以及各流程的负责备谘询人员名单。
• 确认项目数据
  在执行评鉴前，项目团队务必再温习项目执行数据的放置位置及逻辑关联。
• 确认应答人员
  执行评鉴的当天，评鉴师只会访问工作执行的当事人，亦即只有当事人能够回答。 因此，务必要确保当事人对所执行的工作的熟练度，针对项目所使用的工具也要确保能够在1~2分钟内反应回答，另外，最重要的就是对于语言的掌握度，尤其是“英文”听跟说的部份。