Q：什么是ASPICE?
A：Automotive Software Process Improvement and Capacity dEtermination，中文名是汽车软件过程改进及能力评定。
Q：那我想学习ASPICE的话，首先要看什么？官网上的文档吗？
A：是的，可以去官网下载最新版本的ASPICE文档，有英、日、韩、中四个版本。文档的名字是Automotive SPICE PRM/PAM。建议大家沉下心先看一遍ASPICE PRM/PAM的中文版本，形成一个完整的知识框架。
Q：什么是PRM和PAM？
A：PRM是Process Reference Model的缩写，即过程参考模型；PAM是Process Assessment Model的缩写，即过程评估模型。如下图所示，过程参考模型其实可以看做过程评估模型的一个维度。
还是上面这个图，过程评估模型是一个二维框架，X轴是过程参考模型里的一堆过程（Process），Y轴是度量框架里的过程属性（PA）。
Q：什么是过程？
A：过程，即Process。首先我们将一个完整的汽车软件开发项目切割成8个组（Group）。然后对每个组再次切分成若干个子模块，即过程（Process）。每个过程都有自己的过程ID，过程名称，过程目的和过程成果。ASPICE将汽车软件开发项目分为8组32个过程，如下图所示是软件工程组里面的6个过程。SWE.1是过程ID，软件需求分析是过程名字，其对应的过程目的是将系统需求中与软件相关的部分转化为一组软件需求，其过程成果请自行去文档第四章查找。
总之，过程是一件“高标准、严要求、必须要去完成的事儿”，过程与过程之间可能还存在着执行先后顺序的约束，比如你不能在软件架构设计没有冻结时，开始写代码（行话叫：单元构建）。
Q：一共32个过程？那ASPICE评审的时候，所有的过程都会审核吗？
A：不，通常我们会根据VDA Scope进行评审，这样只剩下16个过程了。即ACQ.4, SYS.2-5, SWE.1-6, SUP1, SUP.8, SUP.9, SUP.10, MAN.3。根据实际的项目情况，ACQ.4可以不进行评审。
Q：那度量框架和过程属性又是什么？
A：ASPICE使用的是ISO/IEC 33020:2015中定义的度量框架。我们既然有了过程，当然需要有针对过程的评判标准，比如给你的软件架构打“90分”，但软件详细设计和代码给“60分”。ASPICE采用的不是百分制，而是等级制，即能力级别（Capability Level，简称CL）。针对一个软件项目的评级，总共分为6级。
5级（CL5）指 创新 的过程。Innovating Process.
4级（CL4）指 可预测 的过程。Predictable Process.
3级（CL3）指 已建立 的过程。Established Process.
2级（CL2）指 已管理 的过程。Managed Process.
1级（CL1）指 已执行 的过程。Performed Process.
0级（CL0）指 不完整 的过程。Incomplete Process.
这还没完，CL2-CL5还各有2个维度的“高标准视角”，用于衡量过程的完成情况。再加上CL1也需要勉强有一个“低标准要求”，我们一共有9个不同视角的“要求”。是的，过程属性（PA）可以理解为“要求”。
过程属性（PA）是过程能力的可度量特性。
当然，如果你达到了CL3，那你需要无条件满足CL1和CL2的“要求”。
| 能力等级 CL | 过程属性 PA |
|---|---|
| CL0 | 没有PA |
| CL1 | PA1.1 过程实施PA |
| CL2 | PA2.1 实施管理PA |
| CL2 | PA2.2 工作产品管理PA |
| CL3 | PA3.1 过程定义PA |
| CL3 | PA3.2 过程部署PA |
| CL4 | PA4.1 定量分析PA |
| CL4 | PA4.2 定量控制PA |
| CL5 | PA5.1 过程创新PA |
| CL5 | PA5.2 过程创新实施PA |
我们举个例子，你开了一家面包店，CL0就是面包好不好吃，要看今天上班的师傅手艺怎么样。CL2的PA2.1和PA2.2达成后，面包制作流程和最终质量得到了有效管控，作为老板再也不用担心大师傅跳槽了。
Q：如何来评定过程属性呢（PA）？
A：ISO/IEC 33020（Information Technology — Process assessment ）里面定义的评定尺度分为4种。
N(Not Implemented)未达成，指达成预期性能的（0%，15%]。
P(Partially Implemented)部分实现，达成预期性能（15%，50%]。
L(Largely Implemented)基本达成，达成预期性能（50%，85%]。
F(Fully Implemented)完全达成，达成预期性能（85%，100%]。
其中的P和L还可以二分为P-、P+、L-、L+。对应的范围请参考原版文档。
Q：怎么样算是达成能力等级2级？达成PA2.1和PA2.2的L即可吗？
A：达成某等级需要主要达成（L）该等级对应的过程属性，并且完全达成（F）更低等级的过程属性。
所以达成CL2，需要满足PA1.1达到F，PA2.1和PA2.2达到L。
如果要达成CL3，需要满足P1.1、P2.1、P2.2达到F，P3.1和P3.2达到L。
Q：如何来判定过程评估模型？
A：过程评估模型提供了指标（indicators），用以识别过程成果和过程属性成果（成就）在项目和组织单位的实例化过程中是存在还是缺失的。
从上面的二维图中可以看到，BP们和WP们都是和每个过程的过程成果相关的。每个过程，都有自己独有的基本实践（BP，Base practices）和工作产品（WP，Work products）。GP们和GR们则是和过程属性（PA）的达成相关。每个PA，都有自己独有的通用实践（GP，Generic Practice）和通用资源（GR，Generic Resource）。比如PA3.2自己的GP，名字就叫GP3.2.1、GP3.2.2等等。
Q：过程评估模型和我们每天做的工作有什么关系呢？
A：一个项目从kick-off到EOL，必然经历很多道工序，不同的公司在实施/doing的过程中肯定会产生很多方法，即如何做/How to do。我们采用这些方法肯定是为了达到一个目标，止于至善嘛，自然就形成了指标，去指导我们追求完美的产品。就这样，我们把软件产品的生产过程切割为若干个独立单元，再为这些独立单元创建评价体系，就得到了过程评估模型。
Q：GP是过程能力指标，而原版文件中说，过程能力指标是适用于CL2-CL5的，那CL1咋办？
A：按照过程评估模型的两个维度，即便是CL1也是需要有过程属性PA的。有PA必然有GP。
PA1.1的名称是过程实施PA，它有一个单一的通用实践（GP1.1.1），作为对各个过程性能指标的编辑参考（editorial reference）。这句话的言外之意是，既然X轴上有BP和WP，CL1-PA1.1这个Y轴上也需要派出一位选手，即GP1.1.1。这GP1.1.1讲了什么呢？两句话：
GP1.1.1 实现过程成果：实现BP的意图。生成证明过程成果的WP。完美呼应X轴。所以，说能力级别1级（CL1）没有GP，是不正确的说法。
Q：ASPICE中常会遇见的过程组是什么？
A：对研发来说常见的四个组分别是SYS、SWE、SUP和MAN。SYS（System）指系统工程过程组，SWE（Software）指软件工程过程组，SUP（Support）指支持过程组，MAN（Management）指管理过程组。
系统流程分5部分，软件流程分6部分。这11个部分的先后顺序是：SYS.1 需求挖掘，SYS.2 系统需求分析，SYS.3 系统架构设计，SWE.1 软件需求分析，SWE.2 软件架构设计，SWE.3 软件详细设计和编码，SWE.4 软件单元验证，SWE.5 软件集成和软件集成测试，SWE.6 软件合格性测试，SYS.4 系统集成和系统集成测试，SYS.5 系统合格性测试。其中后10个部分是镜像水平对应的。
SUP需要重点学习的四个过程是：SUP.1质量保证，SUP.8 配置管理，SUP.9 问题解决管理，SUP.10 变更需求管理。其中，配置管理（Configuration Management）需要解决文档化的工作产品（Work Product），存储在哪里的问题，如何打基线、访问权限、命名规则、合并和分支策略等问题。通常需要一个配置管理工具，配合一套配置管理策略来完成。
Q：怎么来理解Work Product？软件的产品不就是最后的hex或s19文件吗？
A：Work Product在ASPICE中代表面向结果的指标。比如SWE.2需要输出的Work Product有软件架构设计、沟通记录、评审记录、追溯记录、接口需求规范这五项，即这些文档都会作为“呈堂证供”参与评审，审核员以此为证据来打分。对于软件部分，显然hex/s19文件不再是唯一的输出物，软件需求规范、接口需求规范、软件详细设计、代码、测试规范等都是同等重要的输出物，并需要保证双向可追溯性和一致性。
Q：什么是追溯性？什么是一致性？什么又是双向可追溯性？
A：追溯性（Traceability）指工作产品之间存在引用或者链接（Reference），比如某条需求与某条测试用例之间存在引用关系。一致性（Consistency）关注的则是内容和语义。官方文档中在一致性下有这么一句话，“一致性由双向可追溯性支持”。那如何理解这里的“双向可追溯性（Bidirectional traceability）”呢？这里我们举个软件架构设计阶段的例子。SWE.2 BP7里面要求针对软件需求和SWC（软件组件）建立双向可追溯，也就是说，对于100条系统工程师发布的软件需求，每条软件需求都至少要有一个“孩子”——SWC；而对于10个软件架构师设计出的SWC，每个SWC都必须至少有一个“妈”——软件需求。这很容易理解，如果某条软件需求没“孩子”，那说明你漏需求了。如果某个SWC没有“妈”，那你干吗要设计它呢？这两点若都能提供覆盖率报告，即说明我们建立了双向可追溯性。
对于一致性，我的理解是评审时需要检查追溯性链接的合理性、真实性。实际工作中如果我们刻意去满足双向可追溯100%覆盖的要求，可能会出现“驴唇不对马嘴”的情况。比如软件架构师将一条可随音乐律动的氛围灯需求分配给了网络管理模块。当然这种低级失误应该会在评审阶段被发现并被纠正。
版权声明：本文为知乎「心机之花」的原创文章，已获作者发表许可。
后台回复：“ECU008获取ASPICE中文版标准！
推荐阅读
谈谈对两家AUTOSAR工具看法
奥迪首款800V车型技术总览
CAN设计与应用指南
汽车软件需求是如何变成用户功能？
电子电气架构设计需要考虑哪些方面？
汽车E/E架构的网络安全分析
电子电气架构设计需要考虑哪些方面？
分享不易，恳请点个【👍】和【在看】
