CMMI, ASPICE, V模型一揽子澄清
同系列文章点击以下链接：
晕就对了 CAN通讯进阶- 为什么会有错误帧 什么是SSP SJW Tseg Tq和Transceiver delay compensation
特斯拉 AP （autopilot）和FSD（Full Self-Drive）
当你发现你的同事们连ASPICE是什么都不知道就开始讲敏捷...
[全网唯一中文] 通用Volt混动架构解读笔记（Toyota THS/GM Volt/Honda Pruis系列之二）
丰田THS混动架构解读笔记（Toyota THS/GM Volt/Honda Pruis系列之一）
“职场霸凌，这样的成长我并不想经历”[全网唯一中文]万字长文 反职场霸凌研究所WBI研究阅读笔记
写在最前
ASPICE标准获取
最新的标准可以从http://www.automotivespice.com上免费下载：
网络安全ASPICE标准：Automotive SPICE® for Cybersecurity - Process Reference and Assessment Model (PDF 794KB) - 1st. edition 2021
0 ASPICE与CMMI的渊源
1986年，美国国防部与卡内基-梅隆大学
和美国国防工业协会共同开发和研制的一个用于评价企业研发能力水平的模型CMMI，是一套融合多学科的、可扩充的产品集合，其研制的初步动机是为了利用两个或多个单一学科的模型实现一个组织的集成化过程改进，后被广泛用于软件流程改善和软件研发团队能力评价。
CMM全名是Capability Maturity Model，是能力成熟度集成模型。
ASPICE模型最早在CMM基础上发展起来的，最初的ASPICE模型几乎与CMM完全一样，评估结果可直接转换、CMMI评估师也可以直接获得ASPICE审核员资质。
1994年，国际标准化组织
（ISO）、国际电工委员会（IEC）和信息技术委员会JTC1联合制定并发布了国际标准ISO/IEC15504，又称SPICE( Software Process Improvement and Capability dEtermination)，这个标准专为软件公司设计，旨在改进软件开发过程
及评估公司应用的流程的有效性。
各产业/领域基于SPICE标准，发展出各自的不同的版本：汽车产业：Automotive SPICE，医疗设备产业：Medi SPICE，航空产业：SPICE 4 Space (S4S)，测试：Test SPICE，企业：Enterprise SPICE，裁剪和延展：SPiCE in Action — Experiences in Tailoring and Extension。
自1994年Automotive SPICE出现后，ASPICE共更新过4次。
1 什么是ASPICE
ASPICE是由SPICE发展而来。而SPICE是由国际标准化组织ISO、国际电工委员会IEC、信息技术委员会JTC1发起制定的ISO15504标准。其项目名为“软件过程改进和能力测定
”（Software Process Improvement and Capability dEtermination），简称SPICE。
ASPICE 全称是“Automotive Software Process Improvement and Capacity Determination”，即汽车软件过程改进及能力评定，是汽车行业用于评价软件开发团队的研发能力水平的汽车软件过程改进及能力评定模型框架，也是国际标准化组织（ISO）和国际电工委员会（IEC）的联合标准之一。
ASPICE其实包含两部分：过程参考模型、过程评估模型。
过程参考模型：PRM是过程参考模型Process Reference Model的缩写；
过程评估模型：PAM是过程评估模型Process Assessment Model的缩写。
过程评估模型从过程参考模型中选择过程并增补指标，这些指标支持收集客观证据，使评估师能够根据能力维度对过程进行评定分配。评估指标与过程能力的关系如下图所示。
ASPICE将层级分为6级：L0~L5，各级别过程能力的评定参考表如下图。
Level 0：企业不知道如何开发或开发出来的产品不符合要求。
Level 1：企业能开发出产品，但无相关开发经验总结、设计规范
、管理规范。因此每次开发完成的产品可能过程差异较大。
Level 2：企业可以通过项目管理方式
来管理整个项目的开发，包含制定项目计划、项目开发监控、调整与管理、项目交付管理等，但可能只适用某个项目。
Level 3：企业已经积累相关开发与管理经验，知道如何管理各类项目的开发过程。各个过程域的担当只需要按公司过程规范来裁剪，并执行相关过程即可完成项目的开发，确保项目的开发品质。
Level 4：企业关于开发的过程与管理已经稳定，开始收集对应各过程对应的数据。引入统计学知识和技术，通过对过程和结果数据的分析、统计与回归计算，来预测过程的结果，并可根据预测的结果，对项目开发过程进行实时调整，并将之运用于未来的项目管理之中。
Level 5：企业可以根据本身的商业目标需求，来反向调整过程相关因素，持续改善过程。对变革管理有很强的管理能力，能够基于对过程的量化分析
设定明确有效的过程改进目标，并能对过程改进结果进行有效的量化监控和分析。
1.1 过程参考模型
过程参考模型是基于V模型构造。
ASPICE将汽车系统研发过程划分为了32个过程，并将这32个过程归类到3大类、8个过程组。每个过程组里面有很多的过程，比如其中最重要的系统过程组和软件过程组。
3大生命周期过程（主要生命周期过程、组织生命周期
过程、支持生命周期过程）
8大过程组（获取过程组
、供应过程组、系统过程组、软件过程组、支持过程组
、管理过程组、重用过程组、过程改进过程组）
系统过程组分为五个过程，软件过程组分为六个过程，这两个过程都过程组都呈现出一个明显的V模型的结构，是左右相互验证的。软件过程组依次是系统需求、软件架构和软件详细设计
，对应的验证就分别是单元测试、集成测试和系统测试。系统过程组分为需求分析
和架构设计，所以验证就是集成验证和系统验证。
过程，即Process。首先将一个完整的汽车软件开发项目切割成8个组（Group）。然后对每个组再次切分成若干个子模块，即过程（Process）。每个过程都有自己的过程ID，过程名称，过程目的和过程成果。
过程参考模型
在ASPICE中的工程过程主要有系统工程和软件工程。系统工程和软件工程在“V”模型中十分醒目，也是整个ASPICE的精华所在。
分5部分，软件流程分6部分。
这11个部分的先后顺序是：
SYS.1需求挖掘，
SYS.2 系统需求分析
， SYS.5 系统合格性测试
SYS.3 系统架构设计
， SYS.4 系统集成和系统集成测试
SWE.1 软件需求分析，， SWE.6 软件合格性测试
SWE.2 软件架构设计，， SWE.5 软件集成和软件集成测试
SWE.3 软件详细设计和编码， SWE.4 软件单元验证
其中后10个部分是镜像水平对应，如下图。
1.2 过程评估模型
有了过程之后，我们就要来看过程是如何评估的，就是说如何去评估一个组织在每个过程的完成度如何？ 所以就会有两种指标，一个指标叫做过程实施指标
，它是展示过程成果的实现，第二个指标叫做过程能力指标
，它会体现过程属性成就实现程度。
过程评估模型提供了指标，以识别过程成果和过程属性成果（成就）在项目和组织单位的实例化过程中是存在还是缺失的。这些指标为评估师收集必要的客观证据提供了指导，以支持能力的判定。这些指标不应被视为必须遵循的检查单集。
过程属性提供了过程能力可度量的特性。
过程评估模型是基于一个二维框架来确定过程能力的：
第一个维度是由过程参考模型PRM（过程维度
）定义的过程来提供；
第二个维度是由进一步细分到过程属性的能力等级（能力维度）所构成。
如下图所示，过程参考模型其实可以看做过程评估模型的一个维度。
过程评估模型是从过程参考模型中选择过程并增补了指标，这些指标支持收集客观证据，是评估师能够根据能力维度
对过程进行评定分配。过程评估模型PAM提供了指标（indicators），用以识别过程成果和过程属性成果（成就）在项目和组织单位的实例化过程中是否存在。
为了判断过程成果和过程成就的存在还是缺失，评估需要获取客观的证据。所有证据是来自对工作产品和被评估过程的存储库内容的检查，以及来自被评估过程的执行者和管理者提供的证词。将证据映射到PAM 指标，以允许建立与相关过程成果和过程属性成就的对应关系。
有两种指标：
过程实施指标——只适用于L1
过程实施指标，其只适用于能力级别1 级。它们提供了过程成果实现程度的指示。
过程能力指标——适用于L2~L5
过程能力指标，其适用于能力级别2 级到5 级。它们提供了过程属性成就实现程度的指示
1.2.1 过程实施指标 PAM
过程实施指标只适用于能力级别1 级。它们提供了过程成果实现程度的指示。类型分为：
- 基本实践（BP）。BPs 代表面向活动的指标。
2. 工作产品（WP）。WPs 代表面向结果的指标。工作产品Work Product（WP）在ASPICE中代表面向结果的指标，是作为达成某属性的结果的一组特性，这组特性将是期望的通用工作产品中的证据。
BPs基本实践和WPs工作产品都与一个或多个过程成果相关。因此，BPs 和WPs 总是过程特定的，而不是通用的。BP 和WP 都是评估师在评估的实施中所收集和积累的客观证据。在这方面，BPs 和WPs 是评估师可以使用的备选指标集。
PAM过程实施指标为每个WP 提供了一组工作产品特性（WPC，见Annex B）。这些都旨在为评估师提供好的实践和最先进的知识的指南。所以，WP 和WPC 被认为是评估中可快速访问的信息源。在这方面，WPs 和WPCs 只代表示例结构。它们既不是“严格的必须”，也不是组织的规范。相反，针对实施的过程的具体工作产品和文档的实际结构、形式和内容必须由项目和组织定义。项目和/或者组织确保工作产品适合预期的目的、需要及开发目标。
尽管过程的能力等级1 级只是对过程成果的达成程度的测量的特性，度量框架
（见3.2 章节）为显示各级别的过程属性的状态，要求PAM过程实施指标引入至少一个过程能力指标。所以只有能力级别1 级（PA1.1.）的过程实施属性有一个单一的通用实践（GP1.1.1），作为编辑参考引用各个过程实施指标（见图3）。
1.2.2 过程能力指标
类型分为：通用实践（GP）， 通用资源（GR）。
GPs 和GRs 是与一个或多个PA过程实施的达成相关的。然而，与过程实施指标相反，它们是通用类型，即它们适用于任何过程。
GP通用实践 和GR通用资源的区别在于，在判断客观证据方面，前者是面向活动的指标，而后者是面向基础设施的指标。评估师需要在评估中收集和积累支持过程能力指标的证据。在这方面，GPs 和GRs 是评估师可以使用的备选指标集。
ASPICE的评分机制：能力等级1级的评定是对BP打分，能力等级2-5需要对PA进行打分。
通过NPLF这四个评定尺度进行打分。
1.3 度量框架
度量框架为能力维度提供了必要的需求和规则。它定义了一个可使评估人员确定对象过程的能力级别的模式。这些能力级别被定义为度量框架的一部分。
为了能够进行评定，度量框架提供了定义过程能力的有可度量特性的过程属性。每个过程属性被分配到特定的能力级别。某个过程属性达成的程度是基于已定义的评定尺度的评定方式来表示。评估师对对象过程的最终能力级别的导出规则是由过程能力等级模型来表示。
Automotive SPICE3.1 使用在ISO/IEC 33020：2015 中定义的度量框架。
过程能力级别和过程属性与ISO/IEC 33020 5.2 中的定义相一致。能力级别的详细描述和对应的过程属性是通过提供过程能力的度量，对达成程度进行评估的过程特征。过程属性适用于所有的过程。
1.3.1 过程能力等级
过程级别是为了显著提高过程的执行能力而相互协作的一组过程属性（一个或多个）。每个过程属性处理能力级别的某个特定方面。这些级别构成了通过任何过程的能力改进而发展来的合理方法。
根据ISO/IEC 33020，共有6 个能力级别，包含9 个过程属性：
在此过程评估模型中，能力的确定是基于ISO/IEC 33020 及表11 所定义的9 个过程属性。
1.3.2 过程属性评定
为支持过程属性评定，ISO/IEC 33020 度量框架提供了一个已定义的评定尺度（可选择更详细的评定尺度），其是基于评估类型（例如，组织成熟度评估所需的）的不同评定方法和不同聚合方法的选择。
评定尺度
在这个过程度量框架中，过程属性是过程能力的可度量特性。过程属性评定是对被评估过程的过程属性达成程度的判断。
ISO/IEC 33020 所定义的评定尺度见表12。
1.3.3 过程能力等级模型
根据表16 所定义的过程能力等级模型，过程所达到的过程能力等级应从该过程的过程属性评定中导出。
依赖于评估对象等级及在所有更低等级的过程属性的评定，过程能力等级模型定义了如何达成各等级的规则。
作为一般规则，达成某等级需要主要达成该等级对应过程属性，并且完全达成更低等级的过程属性。
表16 — 根据ISO/IEC 33020 的过程能力等级模型
1.4 过程参考模型和实施指标（等级1 级）
过程维度中的过程可取自Automtive SPICE 过程参考模型，该内容包含在下表中由左侧红色竖线显示的部分。
与过程维度中各个过程相关的表包含过程参考模型（由红色栏显示）和定义过程评估模型所需的过程实施指标。过程实施指标是由基本实践（由绿色栏显示）和输出工作产品（由蓝色栏显示）所构成。
有两种指标：
过程实施指标——只适用于L1，类型为基本实践（BP）、工作产品（WP）
过程能力指标——适用于L2~L5，类型为通用实践（GP）、 通用资源（GR）
每个过程（process），都有自己独有的基本实践（BP，Base practices）和工作产品（WP，Work products），BP们和WP们都是和每个过程的过程成果相关的。
过程属性PA是通用实践GP和通用资源GR组合成的针对一个过程的特征描述。
每个过程属性（PA, process attribute）都有自己独有的通用实践（GP，Generic Practice）和通用资源（GR，Generic Resource）。
在ASPICE的32个过程域中，每个都各有几个到十几个1级的BP（Base Practice基础实践），以及2到5级的GP（Generic Practice通用实践）。
以SYS.1为例，
它的BP有：
SYS.1.BP1:获得利益相关方需求和要求。通过直接征求客户意见并通过评审客户业务提案（相关部分）、目标运行和硬件环境以及其它影响客户需求的文档来获取并定义利益相关方的需求和要求。[成果1，4]
注1：需求挖掘可能需要客户和供应商的参与。
注2：约定的利益相关方需求和对变更的评估可基于可行性研究和/或成本和时间分析。
注3：必须收集并记录保持每个客户需求可追溯性所需的信息。
SYS.1.BP2:理解利益相关方的期望。确保供应商和客户对每个需求有同样的理解。[成果2]
注4：与客户一起评审需求和要求有助于更好的理解客户需要和期望。参见过程SUP.4 联合评审。
SYS.1.BP3:达成需求共识。获得所有相关方关于需求的明确协议，以便于开展工作。[成果2]
SYS.1.BP4:建立利益相关方需求基线。将利益相关方的需求正式化，并建立基线以便项目使用和依照利益相关方需要进行监控。供应商应确定利益相关方未说明的但对指定和预期用途有必要的需求，并将其包括在基线中。[成果2,3 ]
SYS.1.BP5: 管理利益相关方需求变更。依照利益相关方需求基线来管理所有利益相关方需求的变更，以确保识别技术和利益相关方需要的变化而带来的改进，以及确保受变化影响的人能够评估影响和风险，并启动适当的变更控制和缓解措施。[成果3, 6 ]
注5：需求变化可有不同的来源，例如技术和利益相关方需求的变化、法律约束。
注6：在定义约定的利益相关方需求时所获的和所需的信息可能需要信息管理系统来进行管理、存储和引用。
SYS.1.BP6: 建立客户 - 供应商查询沟通机制。给客户提供可以了解其需求变更状态和处置结果的方法，供应商能够以客户指定的语言和形式沟通包括数据在内的必要信息。[成果5]
注7：任何变更在实施之前都应和客户沟通，以便评估时间、成本和功能性的影响。
注8：这可包括与客户的联合会议或正式沟通，以评审其需求和要求的状态。参见过程SUP.4 联合评审。
注9：供应商沟通的信息格式可包括计算机辅助设计
数据和电子数据交换。
它的WP有：
08-19 风险管理计划 → [成果 6]
08-20 风险缓解计划 → [成果6]
13-04 沟通记录 → [成果1, 4]
13-19 评审记录 → [成果4, 5]
13-21 变更控制记录 → [成果3, 4]
15-01 分析报告
→ [成果2, 3, 6]
17-03 利益相关方需求 → [成果1, 2]
1.5 过程能力等级与过程属性
过程能力指标是达成所考虑的过程属性指定的能力的方法。过程能力指标的证据支持对过程属性的达成程度的判断。
有两种指标：
过程实施指标——只适用于L1，类型为基本实践（BP）、工作产品（WP）
过程能力指标——适用于L2~L5，类型为通用实践（GP）、 通用资源（GR）
过程评估模型的能力维度由与ISO / IEC 33020定义相匹配的六个能力等级组成。过程能力指标是对包含在过程能力等级1到等级5的能力维度中的9个过程属性进行描述。
该过程评估模型中的每个过程属性与过程度量框架中定义的过程属性相同。通用实践指出每个过程属性的特征。通用资源与整体的过程属性相关联。
过程能力等级0级不包括任何类型的指标，因为它反映了未实施的过程或未能部分实现其任何成果的过程。
注：从ISO / IEC 33020 引用的过程属性定义和属性成果，以斜体字并用左侧栏标记。
1.5.1. 过程能力等级0 级：不完整的过程
过程未实施、或未能实现其过程目的。在这个等级只有很少或没有系统化实现过程目的的证据。
1.5.2. 过程能力等级1 级：已执行的过程
已执行的过程实现其过程目的。以下过程属性证明这个等级的实现：
1.5.2.1. PA 1.1 过程实施过程属性
过程实施过程属性是衡量过程目的实现程度的一种度量，完全达成该过程属性的结果如下:
a) 过程实现其定义的成果
1.5.3. 过程能力等级2 级：已管理的过程
以管理的方式（计划，监控和调整）来实施前述的已执行的过程，并且适当的建立、控制和维护该过程工作产品。
以下过程属性与先前已定义的过程属性一起来证明本级别的达成：
1.5.3.1. PA 2.1 实施管理过程属性
实施管理过程属性是对过程实施进行管理的程度的度量。完全达成该过程属性的结果如下:
a) 识别了过程的实施目标；
b) 计划了过程的实施；
c) 监控了过程的实施；
d) 调整了过程的实施以满足计划；
e) 定义、分配和沟通了执行过程的职责和权限；
f) 准备了执行过程的人员以履行其职责；
g) 识别、提供、分配并使用了执行过程所需的资源和信息；
h) 管理了参与方之间的接口以确保有效的沟通和明确的职责分配。
1.5.3.2. PA 2.2 工作产品管理过程属性
工作产品管理过程属性是对过程生成的工作产品进行适当管理的程度的度量。完全达成该过程属性
的结果如下:
a) 定义了过程工作产品的需求；
a) 定义了工作产品的文档化和控制的需求；
b) 适当地识别、文档化和控制了工作产品；
c) 按照计划的安排评审了工作产品，并根据需要调整了工作产品以符合需求。
注1：工作产品的文档化和控制的需求可包括：变更和修订状态的识别，工作产品的批准和复批，工作产品
的分发，及在需要使用时提供适当的工作产品的相关版本。
注2：本章节提及的工作产品是通过过程成果达成过程目的的结果.
1.5.4. 过程能力等级3 级：已建立的过程
先述的已管理的过程，由能实现其过程成果的已定义的过程来实施。
以下过程属性结合先前已定义的过程属性，证明达成该等级：
1.5.4.1. PA 3.1 过程定义过程属性
过程定义过程属性是维护标准过程以支持已定义过程的部署的程度的度量。完全达成该过程属性的
结果如下:
a) 定义并维护了标准过程，包括适当的裁剪指南。该标准过程描述了必须纳入已定义过程的基本元素；
b) 确定了标准过程与其他过程的顺序和交互；
c) 识别了执行过程所需的能力和角色，作为标准过程的一部分；
d) 识别了执行过程所需的基础设施和工作环境，作为标准过程的一部分；
e) 确定了监控过程的有效性和适用性的合适方法和度量。
1.5.4.2. PA 3.2 过程部署过程属性
过程部署过程属性是，对标准过程作为已定义过程进行部署而实现其过程成果的程度的度量。完全
达成该过程属性的结果如下:
a) 基于适当地被选择的 和/或 裁剪的标准过程部署了已定义过程；
b) 分配和沟通了已定义过程执行时所需的角色、职责和权限；
c) 基于适当的教育、培训和经验，人员有能力执行已定义过程。
d) 提供、分配和使用了已定义过程执行时所需的资源和必需信息；
e) 提供、管理和维护了已定义过程执行时所需的基础设施和工作环境；
f) 收集并分析了适当的数据，作为理解过程行为的基础，以证明过程的适用性和有效性，并评估
在哪里可以持续改进过程。
1.5.5. 过程能力等级4 级：可预测的过程
先述的已建立的过程，在定义的限值内可预测地运作以达成其过程成果。识别量化管理需要，收集和分析度量数据，以识别波动的可查明原因。采取纠正措施
来解决波动的可查明原因。
以下过程属性结合先前已定义的过程属性，证明达成该等级：
1.5.5.1. PA 4.1 定量分析过程属性
定量分析过程的属性是，定义信息需要、识别过程要素之间的关系以及收集数据的程度的度量。完全达成该过程属性的结果如下:
a) 过程与量化的商业目标相一致；
b) 建立了过程信息需要，以支持相关已定义的量化商业目标；
c) 过程度量目标由过程信息需要导出；
d) 识别了有助于过程实施的过程要素之间的度量关系；
e) 建立了过程实施的定量目标，以支持相关的商业目标；
f) 识别和定义了合适的度量项及其频率，并与过程度量目标及过程实施的定量目标相一致；
g) 收集、确认和报告了度量结果，以监控过程实施达成定量目标的程度。
注1 信息需要通常反映了管理、技术、项目、过程或产品的需要。
1.5.5.2. PA 4.2 定量控制过程属性
定量控制过程属性是对客观数据被用于管理可预测的过程绩效的程度的度量。完全达成该过程属性
的结果如下:
a) 选择了分析收集数据的技术；
b) 通过分析收集到的数据，确定了过程波动的可查明原因；
c) 建立了表征过程绩效的分布；
d) 采取了纠正措施以解决波动的可查明原因；
e) 建立了各自的分布（必要时）以分析受波动的可查明原因所影响的过程。
1.5.6. 过程能力级别5 级: 创新的过程
先述的可预测的过程得到不断地改进，以响应与组织目标一致的变化。
以下过程属性结合先前已定义的过程属性，证明达成该等级：
1.5.6.1. PA 5.1 过程创新属性
过程创新过程的属性是，从对过程的定义和部署的创新方法的调查中识别过程变化的程度的度量。
完全达成该过程属性的结果如下:
a) 定义了支持相关商业目标的过程创新目标;
b) 分析了适当的数据以识别创新的机会;
c) 识别了来自新技术和过程概念的创新机会;
d) 建立了实施战略以达成过程创新目标。
1.5.6.2. PA 5.2 过程创新实施过程属性
过程创新实施过程属性是对过程的定义、管理和绩效的变化达成相关过程创新目标的程度的度量。
完全达成该过程属性的结果如下:
a) 依据已定义过程和标准过程的目标，对所有提议的变更的影响进行评估；
b) 对所有约定的变更的实施进行管理，以确保对过程绩效的任何干扰得到理解并采取行动；
c) 依据已定义的产品需求和过程目标，基于实际绩效对过程变更的有效性进行评估。
1.6 关于ASPICE评估
ASPICE评估对象是项目，而不是产品或公司体系。ASPICE评估只能证明一个公司某个项目在某个时间段的过程能力情况。假设一个公司项目通过了ASPICE CL2评估时，说明该公司被评估项目X的相关被评估过程达到了CL2能力度等级。但并不能说明该公司其他项目Y也达到了CL2能力度级别。
被评估项目如果没有发生变更（包括开发过程调整、组织结构调整、人员替换等），则可以认为评估结果在12个月之内是有效的。
在Automotive SPICE领域，没有机构去执行和管理评估，而完全由评估师个人进行ASPICE评估并签发评估结果，只是iNTACS（国际评估师认证机构，INTernational Assessor Certification Scheme）去管理评估师。iNTACS定义了评估师的级别，级别晋升条件和级别维持的条件。ASPICE评估师的级别从低到高分别为：Provisional Assessor，Competent Assessor, PrincipalAssessor。
ASPICE特别重视双向可追溯性和一致性。
但这种可追溯性和一致性在项目的实操过程中，审查员一般只能以抽查的方式检测。特别是一致性，工具很难检查出来。因此ASPICE要求，
- 需求文档需要被验证，且需要有具体标准定义。
- 设计文档需要被评估，且评估准则可包括质量特性如模块化、可靠性、安全性（security）和可用性等
以SWE.6 软件合格性测试为例，需要确保：
- 100%软件需求被软件合格性测试覆盖。
- 每个软件合格性测试条目（Item）可追溯到相应的软件需求。
- 一致性得到保证，比如不能把CAN的测试用例
链接到XCP上。
- 选中的测试用例100%得到执行并生成测试结果，如果没通过的需要修复，或者确保没有影响并与客户达成一致。
- 需求变更的内容要在测试中体现相应修改。
2 APSICE作用
上面说到APSICE包括软件开发的过程参考模型和过程评估模型。也就说它是一套评估体系，是衡量开发过程规范性、有效性和一个组织软件开发能力的一套方法论
。
它把软件开发能力分为五个等级，
第一个等级是能开发出产品；
第二个等级是开发出产品，并且有相关的项目管理的活动，但是这些项目管理的经验是不可复用到其他项目的；
第三个等级是具备可复用的软件开发项目管理
经验；
第四个等级是能够通过开发过程中相关的数据来对整个开发过程进行调整；
第五个等级是能够根据组织本身的一个目标对项目软件开发这件事情进行创新和改进；
流程是用来做参考，指导软件开发的，每个环节做哪些事、标准是什么、要求是什么，都是经验的总结和提炼。反过来说，要设计出符合需求的软件，如果经验足够丰富的话，这些流程不一定每个步骤都走。但是流程就像一个checklist，能帮我们结构化思考计划、安排任务，以避免不必要的过失。
制定这套框架的目的是什么呢？
起初，OEM的软件供应商，不能把软件以白盒形式交付。于是大家想到：虽然不能看到代码，但是可以要求整个软件或者系统的研发流程是按照特定的流程。这个流程就是汽车行业非常有名的 V模型开发流程。它的主体部分，是系统工程和软件工程部分。
具体来说，就是针对一个系统的开发需要包括：系统需求分析、系统架构设计、软件需求分析、软件架构设计、软件详细设计，这是V字型的左边，以及对应的右边验证测试的过程。
这中间的逻辑是：虽然看不到详细代码，但是假如整个开发是流程是基于预先定义的流程来开发的，那么可认为质量是基本达标的。
这个框架的要求和细节，是非常繁杂的。
具体来说，ASPICE对两块地方的要求特别高，一块叫做追溯性，一块叫做合规性。
所谓的追溯性，简单的理解就是，从任何一个细节，比如说一个 bug，可以追溯到它的测试用例，追溯到它的测试计划，追溯到它的软件需求，追溯到它的软件架构，追溯到它的系统架构、系统需求等等。
另外一块叫做合文档的合规性。比如说要做一个测试，测试的时候首先需要制定一个测试计划，测试策略是什么？测试目标是什么？测试是针对什么东西的测试，有哪些人参与，测试的过程中怎么进行结果的记录，bug如何进行追踪，以及 bug 的解决过程，bug 的原因分析，它的影响分析等等。
那么具体追溯性和合规性如何实现呢？这套评价框架没有规定，那如何来把控是否真的能满足这套评价框架呢？
这时候就出现了叫做 ASPICE评审的活动，是由对ASPICE标准比较熟悉的评审师，来针对某家公司的流程来做评价。有些评审师非常有经验，他不仅知道怎么评价，还知道你通过什么方式、什么工具能快速通过评价；还有一些评审师，他只知道标准的要求是什么，至于“怎么做”才能通过标准，“怎么做”才能高效地通过这个标准，提供不了什么帮助。
那么这块就出现了一个问题，既然标准都是一样的，但是具体的实现过程不一样，就会发现有些公司实现追溯性的过程非常高效，还有一些公司就非常繁杂。
举个例子，有些公司基本上全部是用 word 的方式来管理他所有的文档。有一份需求用 word 来书写有 20 页，有一份软件架构用 word 来书写有 50 页。可以看到有一个需求1，问它的架构是什么，我们发现需求 1 下面写了是架构3.2，然后去架构的word文档里面翻到架构3.2。此时问架构有没有测试用例，在架构看到，对应的测试用例是5.3，然后就去翻对应的测试用例word里面，有一条5.3。
这家公司有没有建立追溯性呢？它确实建立了追溯性。但是刚刚举的这个例子非常简单，它只涉及到三步，确实可以通过翻阅文档的方式来进行追溯。
但是想象一下，一般来说在一家公司里面，需求、软件架构、测试用例都是由不同的工程师完成。那不同的工程师可能把这些文档放在不同的地方，不同的工程师也会实时地更新它的文档。当我们刚刚把软件需求和软件架构联系起来了，这时候，软件架构word更新了，它能否通知到软件需求，这里有一处更新呢？以及架构师是否知道去通知谁呢？
假如系统中有 30 份软件需求文档，50份软件架构文档，100 份测试用例文档，这个时候再去寻找，这个寻找过程的复杂程度，就是指数级增长了。
可以看到，这个例子中确实建立了追溯性，但是追溯性的实用性很差。
这也是为什么很多团队在ASPICE评审的过程中怨声载道，一旦评审通过，立刻抛弃这套“追溯性”和“合规性”流程。
所以说，ASPICE其实只是代表遵循了这样一个流程，并不能代表软件的好坏。并不代表通过了这个标准，就能开发出好的产品，这两者之间是没有根本性的联系的。
3 ASPICE现实
大多数情况下，会对ASPICE做裁剪，根据情况舍弃/复用某些流程/工作，否则一整套做下来,项目时间肯定不够。
随着汽车电子系统越来越复杂，发生任何安全问题都可能导致汽车召回，车厂销量越大，损失越大。所以对供应商的要求也越来越严格。一些主机厂会指定项目请独立第三方来做ASPICE审核，这种情况下，供应商只能尽量照着ASPICE走。
从长远角度看，ASPICE/ASIL都是供应商的必经之路。
按照SPICE来开发，是对产品负责，也是对开发团队的保护。
但不遵循ASPICE开发的潜在风险和导入所投入的成本相比较，很多小体量公司宁愿承担风险，或者说根本无法承担实施ASPICE的成本。
（to be continued）
**本人号码具备通话属性和绿色泡泡属性
很期待和同业的技术交流
我是Maeve，我们之间仅仅隔着一个186-0161-9614**
扫一扫
1678
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
