红绿蓝——ASPICE过程域的组织形式

“日出江花红胜火，春来江水绿如蓝”

在红、绿、蓝的光影交错之下，白居易《忆江南》中的水乡美景便跃然纸上。

同样，ASPICE也运用这三原色来描述模型中的各个过程域。如下是VDA的《Automotive SPICE Process Assessment / Reference Model（ASPICE流程评估/参考模型）》3.1版中（以下简称APSICE3.1），第四章里定义各PA（过程域）的组织形式。

（[ASPICE3.1] Table 17 — Template for the process description）

如上图所示，红色部分解决的是“Why（为什么）”的问题，在过程域的ID、名称的基本信息之后，开宗明义地说明目标（Process purpose），并列举流程结果（Process outcomes）——作为与其他部分关联的纽带。

而绿色部分解决的是“How（怎么做）”的问题，在ASPICE一级中被称为BP（Base Practice基础实践），而二到五级中则被称为GP（Generic Practice通用实践），每个实践都会标注对应红色部分中的流程结果（Process outcomes）。

而蓝色部分解决的是“What（有什么）”的问题，说明Output Work Product（输出工作产品）如各类设计需求文档，与绿色部分类似，相应过程域的工作每个输出工作产品也会标注对应红色部分中的流程结果（Process outcomes），而对工作产品的具体特性要求，则在附录B中有说明。

下面通过实际的例子说明过程域是如何用红绿蓝三原色组织起来的。

红色——各司其职定目标

系统需求往往是实际开发过程中最关键的一环，产出物是大家熟悉的PDD（产品设计文档），我们先来看看这个PA（过程域）的目标（Process purpose）：

SYS.2 - System Requirements Analysis : The purpose of the System Requirements Analysis Process is to transform the defined stakeholder requirements into a set of system requirements that will guide the design of the system. （系统需求分析：系统需求分析过程的目的是将已定义的利益相关者需求转换为一组系统需求，这些需求将指导系统设计。）

在以上这个SYS.2过程域的目标表述，由一系列动词关联如下三个关键词形成：

1. 上游过程域SYS.1的工作产品（stakeholder requirements利益相关者需求）

2. 本过程域SYS.2的工作产品（system requirements系统需求）

3. 下游过程域SYS.3的工作产品（design of the system系统的设计）

从这个例子可以看出，ASPICE中每个过程域各司其职，而要了解一个过程域是干什么的，首先要了解它在整个ASPICE过程域中框架中的位置。APSICE3.1的章节3.1. Process reference model（流程参考模型）的这个概要图被各种ASPICE的介绍文章广泛引用，从这个图中可以看到各个过程域在整个框架中的位置。

（[ASPICE3.1]Figure 2 — Automotive SPICE process reference model - Overview）

绿色——按部就班出成果

在ASPICE的32个过程域中，每个都各有几个到十几个1级的BP（Base Practice基础实践），以及2到5级的GP（Generic Practice通用实践），而这些实践之间也有一定的逻辑关系。下面以软件合格性测试过程域SWE.6的BP为例，用PDCA戴明环的方式进行解析（该套路对于SYS.2-5、SWE.1-6的过程域理解还是比较有效的）。

如上图所示，PDCA循环的含义是将质量管理分为四个阶段，即计划（Plan）、执行（Do）、检查（Check）、处理（Act），而这4个阶段也正可以对应SWE.6的7个BP，如下表所示。

1)Plan (计划)

不同于CMMI在软件领域的单一，ASPICE所对应的汽车行业有多个competency（部门），如下图所示以“Plug-In（即插即用）”的形式结合在一起。由于每个部门的组织形式、开发流程各不一样，因而在统一的项目计划之下，每个部门也需要各自的计划，如系统部门需要系统工程管理计划（SEMP – System Engineering Management Plan），覆盖SYS.1到SYS.5的内容；软件部门则需要软件开发计划（SDP – Software Development Plan），SWE.6.BP1中的测试策略就包含在这个SDP之中。

（[ASPICE3.1] Figure D.1 — The "Plug-in" concept）

SWE.6.BP1中，明确要求“开发软件合格性测试策略，包括回归测试策略”作为后续BP的依据。在ASPICE过程域中，并非所有过程域都需要定义策略，如SYS.2系统需求分析、SWE.1软件需求分析就没有特定策略，这并不是说它就没有计划，而是计划阶段的内容已经覆盖在MAN.3项目管理之中了。SYS.2的计划覆盖在SEMP中，而SWE.1的计划覆盖在SDP之中，而这些计划，ASPICE在2-5级的GP（通用实践）中有更加明确的要求。关于策略（strategy）和计划（plan）的关系，ASPICE3.1用下图进行说明。

（[ASPICE3.1] Figure D.7— Strategy and plan）

2)Do（执行）

计划有了，没毛病干就完了，那么具体都干些什么呢？三件事——写用例、选用例、做测试——在SWE.6.BP2到SWE.6.BP4给出了答案。类似的，根据V模型环环相扣，下面是部分过程域执行步骤的简要内容——

在ASPICE中，各个过程域的工作产品粒度有不同的单位，也有特定的术语。如下图所示，同样是CAN（Controller Area Network）模块开发，在系统架构层级就是Element（元素）、在软件架构层级就称为Component（组件）、到了代码就叫Unit（单元），软件集成以上级别的测试就成了Item（条目）了。了解这个术语的区别便于我们在系统上设置字段的时候有统一规范，如果什么阶段都叫“Component”，就容易引起误解了。

（[ASPICE3.1] Figure D.3 — Element, component, unit, and item）

3)Check（检查）

检查的内容体现在双向追溯和一致性，这在下图中一目了然：

[ASPICE3.1] Figure D.4 — Bidirectional traceability and consistency）

ASPICE的环环相扣体现在它的追溯性上，以SWE.6为例，需要确保：

- 100%软件需求被软件合格性测试覆盖。

- 每个软件合格性测试条目（Item）可追溯到相应的软件需求。

- 一致性得到保证，比如不能把CAN的测试用例链接到XCP上。

- 选中的测试用例100%得到执行并生成测试结果，如果没通过的需要修复，或者确保没有影响并与客户达成一致。

- 需求变更的内容要在测试中体现相应修改。

4)Act（处理）

活干完了、也检查了，最后的处理步骤是什么呢？花开两朵，各表一枝：对V模型左侧的需求设计开发阶段而言，“达成一致并沟通（communicate agreed…）”即可告一段落；而对V模型右侧的测试阶段而言，“总结并沟通（summarize and communicate…）”才算宣告完成——如下图所示。

（[ASPICE3.1] Figure D.5 — Agree, summarize and communicate）

蓝色——分门别类留证据

项目计划需要包含哪些内容？系统需求需要考虑哪些要素？这些问题都可以ASPICE3.1的附录B-工作产品特性（Annex B Work product characteristics）中找到。该部分描述了共计21类工作产品的特性需求，列表如下：

以MAN.3项目管理为例，通过附录B可以找到主要工作产品项目计划的主要内容要求。项目计划（Project Plan）编号为08-12，因此需要考虑通用计划（08-00）和项目计划（08-12）的特性。无论是组织模板或是项目计划，都应当覆盖这些内容。

首先是通用计划08-00 Plan（计划）的特性，这在考虑组织模板的各类计划如质量计划、配置管理计划、测试计划等等的时候，都应当考虑满足这些特性。中英双语列举如下——

其次是项目计划08-12 Plan（项目计划）的特性，各个适用于各个competency（部门）的计划制定，中英双语列举如下——

纽带——流程结果（Process outcomes）

上述的红绿蓝三个部分由流程结果（Process outcomes）作为纽带关联而成，如下说明以SUP.10 Change Request Management（变更请求管理）中的第一个outcome为例。

SUP.10的变更请求管理过程域中，红色部分的第一个流程结果（Process outcomes）为“a change request management strategy is developed（制定变更请求管理策略）”，基于此，绿色部分的BP（基础实践）和蓝色部分Output Work Product（输出工作产品）的相应内容分别为：

绿色部分的BP（基础实践）

SUP.10.BP1: Develop a change request management strategy. Develop a change request management strategy, including change request activities, a status model for the change requests, analysis criteria, and responsibilities for performing these activities. Interfaces to affected parties are defined and maintained. [OUTCOME 1] （SUP.10.BP1：制定变更请求管理策略。制定变更请求管理策略，包括变更请求活动、变更请求的状态模型、分析标准和执行这些活动的职责。定义并维护与受影响方的接口。[结果1]）

蓝色部分Output Work Product（输出工作产品）

08-28 Change management plan → [OUTCOME 1] （08-28变更管理计划→[结果1]）

总结一下

ASPICE分为32个过程域，每个过程域通过红色、绿色、蓝色分别解答了Why、How、What（为什么做、怎样做、做成什么）的问题，红色、蓝色、绿色的内容通过流程结果（Process Outcome）链接，思路非常清晰。而这三个部分又参考了不同的质量标准，内容相当丰富，可以进一步深度解析。

-----------分割线------------

附录1：关于Why、What、How的讨论范围

文中采用了Why、What、How的表述，在这里补充一下这些表述的讨论范围，以避免不必要的误解。

在我们理解事物的过程中，5W1H是常用的方法，即对选定的项目、工序或操作，都要从原因（何因Why）、对象（何事What）、地点（何地Where）、时间（何时When）、人员（何人Who）、方法（何法How）等六个方面提出问题进行思考。而在运用这个方法之前，限定讨论范围非常重要。

在本文中，就是使用5W1H中的Why、What、How对ASPICE单个过程域的组织形式的解析，Why对应以Process Purpose（流程目的）为主要核心的PRM（流程参考模型），What对应输出的工作产品，而How则对应为达成目的输出工作产品所需要做的事情即实践（BP&GP）。所以，本文Why、What、How的讨论对象是ASPICE单个过程域的组织形式。

相似的ASPICE也运用了5W1H，如下就是INTACTS在Provisional Assessor培训资料中 对“流程”这一术语（The term ”Process”）进行解析的PPT页，在这里，What、How、Doing的讨论对象是“流程”这一术语（The term ”Process”）。

由于两者的讨论范围不同，虽然都使用了“What”“How”的表述，却并不互相矛盾。

文章转载自公众号：汽车电子与软件