在ASPICE标准的理解过程中，初学者常常面对纷繁复杂的过程实践不知何从下手（Practice）——其中的265个基本实践（Base
Practice）和42个通用实践（Generic
Practice）分布在32个过程域、5个级别的框架中，各司其职又彼此关联。如果不能用清晰的脉络厘清这些实践中的序列关系,很容易陷入“只见树木、不见森林”的处境。
从ASPICE3.1的《表E.1 — 参考标准》来看（如下图），其来源无一例外地来自ISO族的标准（如ISO33020 /
ISO12207等），而与ISO最广为人知的质量体系标准ISO9000系标准类似，它同样遵循着过程方法的原则 (Process
Approach)。在众多方法论中，被广泛应用的“戴明环”PDCA同样在ASPICE的实践序列的定义中得到体现。
ASPICE3.1的《表E.1 — 参考标准》
在具体解析之前，我们先看看PDCA的定义——PDCA（Plan-Do-Check-Act的简称）循环式品质管理，针对品质工作按计划、执行、检查与行动来进行活动，以确保可靠度目标之达成，并进而促使品质持续改善。由美国学者爱德华兹·戴明提出，因此也称戴明环。这个四步的循环一般用来提高产品品质和改善产品生产过程。（参考维基百科）
了解了基本定义，我们随着这四个步骤，解读在ASPICE中，具体的过程域中是如何把这个过程方法的原则落地的，因为篇幅有限，本文讨论的是VDA范围的主要的工程过程域，即系统部分（SYS.2-SYS.5）和软件部分（SWE.1-SWE.6），以及相关的的项目管理部分（MAN.3）。
计划篇（Plan）
建立明确的目标，并制定相关的计划和确定必要的程序。通过这样的方式可以在后续的过程中评估实现的结果和目标的差距，便于进行修正。
在项目的实际过程中，各个部门在启动会（Kick-off）之后，首要应当完成的就是各自的计划了——
项目经理：完成整体的项目计划（Project
Plan），范围（Scope）、目标（Objectives）、职责分配RASI、进度表（Schedule）等等，作为各个部门具体计划的参照依据.。主要因素在MAN.3的10基本实践中写的非常清楚——范围（BP1）、周期（BP2）、可行性（BP3）、活动（BP4）、资源（BP5）、培训（BP6）、接口人（BP7）、进度表（BP8）、一致性（BP9）、评审（BP10）。
系统团队：完成系统团队的系统工程管理计划SEMP（System
Engineering Management
Plan），除了对应整体项目计划体现系统团队的内容外，更是要覆盖从SYS.1-SYS.5的具体工程实践部分。其中独立的测试团队可能根据需要，会建立各自的测试计划如。
软件团队：完成软件团队的软件开发计划SDP（Software Development Plan），除了对应整体项目计划体现软件团队的内容外，更是要覆盖从SWE.1-SWE.6的具体工程实践部分。
其他的支持过程域比如SUP.1（质量保证）、SUP.8（配置管理）、SUP.9（问题管理）、SUP.10（变革管理）、ACQ.4（供应商监控）等等，也需要定义出具体的负责人并完成计划，就不在本文中讨论了。而在系统和软件的计划阶段，值得注意的是，相对于左侧生产开发类（需求、设计、构建），右侧的验证测试部分在计划之外，更是强调了策略的内容，并在其相关过程域的首个基本实践BP1做出了明确定义——这在标准附录的D.7—策略和计划得到体现。
ASPICE3.1的《图 D.7—策略和计划》
相关过程域和基本实践列举如下——
| 过程域 | 基本实践 |
| SYS.4 系统集成和集成测试 | SYS.4.BP1: 制订系统集成策略 |
| SYS.4.BP2: 制订包括回归测试策略在内的系统集成测试策略。 |
| SYS.5 系统合格性测试 | SYS.5.BP1: 制订包括回归测试策略在内的系统合格性测试策略。 |
| SWE.4 软件单元验证 | SWE.4.BP1: 制订包括回归策略在内的软件单元验证策略。 |
| SWE.5 软件集成和集成测试 | SWE.5.BP1: 制订软件集成策略。 |
| SWE.5.BP2: 制订包含回归测试策略在内的软件集成测试策略。 |
| SWE.6 软件合格性测试 | SWE.6.BP1: 制订包括回归测试策略在内的软件合格性测试策略。 |
相似的，二级的实践也是以计划开始的，落地过程中，相关的SEMP和SDP需要体现出相关的内容，以下是相关的流程属性和通用实践。为了实现有效的跟踪，往往具体的目标会提炼到独立的表格中进行跟踪。
| 流程属性 | 通用实践 |
| PA 2.1 实施管理过程属性 | GP 2.1.1 识别过程实施的目标。 |
| GP 2.1.2 计划过程的实施以满足已识别的目标。 |
| PA 2.2 工作产品管理过程属性 | GP 2.2.1 定义工作产品的需求。 |
| GP 2.2.2 定义工作产品文档化和控制的需求。 |
执行篇（Do）
执行第一步（计划阶段）中制定的计划，并收集必要信息为下一步的检查和改善提供依据。个人对各个工程过程域进行了整理，用“三字经”的方式把要做的事情列表如下，10个过程域的43个基本实践，一张表搞定，没毛病干就完了。
| 过程域 | 执行阶段基本实践 |
|
| 序号 | 概括 |
|
| SYS.2 系统需求分析 | BP.1-5 | 写需求、定结构、做分析、明影响、验准则 |
| SYS.3 系统架构设计 | BP.1-5 | 写架构、分需求、定接口、画动态、评备选 |
| SYS.4 系统集成与集成测试 | BP.3-6 | 写用例、做集成、选用例、做测试 |
| SYS.5 系统合格性测试 | BP.2-4 | 写用例、选用例、做测试 |
| SWE.1 软件需求分析 | BP.1-5 | 写需求、定结构、做分析、明影响、验准则 |
| SWE.2 软件架构设计 | BP.1-6 | 写架构、分需求、定接口、画动态、分资源、评备选 |
| SWE.3 软件详细设计和单元构建 | BP.2-4,8 | 写设计、定接口、画动态、评设计、做开发 |
| SWE.4 软件单元验证 | BP.2-4 | 定标准、测静态、测单体 |
| SWE.5 软件集成和集成测试 | BP.3-6 | 写用例、做集成、选用例、做测试 |
| SWE.6 软件合格性测试 | BP.2-4 | 写用例、选用例、做测试 |
为了详细说明，具体过程域列表说明如下：
| 过程域 | 执行阶段基本实践 |
|
| 概括 | 标准说明 |
|
| SYS.2 系统需求分析 | 写需求 | SYS.2.BP1:定义系统需求。 |
| 定结构 | SYS.2.BP2:结构化系统需求。 |
| 做分析 | SYS.2.BP3: 分析系统需求。 |
| 明影响 | SYS.2.BP4: 分析对运行环境的影响。 |
| 验准则 | SYS.2.BP5:制订验证准则 |
| SYS.3 系统架构设计 | 写架构 | SYS.3.BP1: 开发系统架构设计。 |
| 分需求 | SYS.3.BP2: 分配系统需求。 |
| 定接口 | SYS.3.BP3: 定义系统要素的接口 |
| 画动态 | SYS.3.BP4: 描述动态行为。 |
| 评备选 | SYS.3.BP5: 评估备选的系统架构。 |
| SYS.4 系统集成与集成测试 | 写用例 | SYS.4.BP3：开发系统集成测试规范 |
| 做集成 | SYS.4.BP4: 集成系统项。 |
| 选用例 | SYS.4.BP5: 选择测试用例。 |
| 做测试 | SYS.4.BP6: 执行系统集成测试。 |
| SYS.5 系统合格性测试 | 写用例 | SYS.5.BP2: 开发系统合格性测试规范。 |
| 选用例 | SYS.5.BP3: 选择测试用例。 |
| 做测试 | SYS.5.BP4: 测试已集成的系统。 |
| SWE.1 软件需求分析 | 写需求 | SWE.1.BP1:定义软件需求。 |
| 定结构 | SWE.1.BP2:结构化软件需求。 |
| 做分析 | SWE.1.BP3:分析软件需求。 |
| 明影响 | SWE.1.BP4:分析对运行环境的影响。 |
| 验准则 | SWE.1.BP5:制订验证准则。 |
| SWE.2 软件架构设计 | 写架构 | SWE.2.BP1:开发软件架构设计。 |
| 分需求 | SWE.2.BP2:分配软件需求。 |
| 定接口 | SWE.2.BP3:定义软件要素的接口。 |
| 画动态 | SWE.2.BP4:描述动态行为。 |
| 分资源 | SWE.2.BP5:定义资源消耗目标。 |
| 评备选 | SWE.2.BP6:评估备选的软件架构。 |
| SWE.3 软件详细设计和单元构建 | 写设计 | SWE.3.BP1:开发软件详细设计。 |
| 定接口 | SWE.3.BP2: 定义软件单元的接口。 |
| 画动态 | SWE.3.BP3: 描述动态行为。 |
| 评设计 | SWE.3.BP4: 评估软件详细设计。 |
| 做开发 | SWE.3.BP8: 开发软件单元。 |
| SWE.4 软件单元验证 | 定标准 | SWE.4.BP2: 制订单元验证准则。 |
| 测静态 | SWE.4.BP3: 执行软件单元的静态验证。 |
| 测单体 | SWE.4.BP4: 测试软件单元。 |
| SWE.5 软件集成和集成测试 | 写用例 | SWE.5.BP3: 开发软件集成测试规范。 |
| 做集成 | SWE.5.BP4: 集成软件单元和软件项。 |
| 选用例 | SWE.5.BP5: 选择测试用例。 |
| 做测试 | SWE.5.BP6: 执行软件集成测试。 |
| SWE.6 软件合格性测试 | 写用例 | SWE.6.BP2: 开发软件合格性测试规范。 |
| 选用例 | SWE.6.BP3: 选择测试用例。 |
| 做测试 | SWE.6.BP4: 测试集成软件。 |
以上是一级的基本实践，谈到二级的通用实践，相应的列表如下：
| 流程属性 | 通用实践 |
| PA 2.1 实施管理过程属性 | GP 2.1.5 定义执行过程的职责和权限。 |
| GP 2.1.6 识别、准备并提供资源以按计划执行过程。 |
| GP 2.1.7 管理参与方之间的接口。 |
| PA 2.2 工作产品管理过程属性 | GP 2.2.3 识别、文档化和控制工作产品。 |
检查篇（Check）
分析上一步（执行阶段）收集到的信息，与计划阶段的目标进行对比并提出修改方案。一级的部分，无非就是两个词+一张图，两个词是双向可追溯性（bidirectional
traceability）和一致性（consistency），一张图就是ASPICE3.1附录中的《图 D.4 —
双向可追溯性和一致性》。在执行过程的相关BP之后，就是这两条检查类的工程实践，关注点在与其他过程域之间的互动。事实上，在其他的工程实践中，无论是制定计划、描述需求、编写设计等等，都有相应的评审和检查，而作为实践强调出来的内容，这两项担负着将各个实践连成一个整体的重要使命。
而在二级的事件中也有类似的检查部分列表如下——
| 流程属性 | 通用实践 |
| PA 2.1 实施管理过程属性 | GP 2.1.3 依照计划，监控过程的实施。 |
| PA 2.2 工作产品管理过程属性 | GP 2.2.4 评审并调整工作产品以满足定义的需求。 |
上表可见，GP2.2.4和检查相关的，是前半部分的评审。除了评审的部分，也包含了调整的内容，那我们来看下个部分吧。
行动调整篇（Act/Adjust）
Act于英文涵义上另有修正案的意思，所以有的时候很多人更加趋向于使用修正（Adjust）来解释PDCA的A，因而体现出A的改善的含义。一级的部分，相似的也是两个短语一张图，两个短语是“约定”
和“总结和沟通”，一张图就是ASPICE3.1附录中的《图 D.5 —
约定、总结和沟通》。在检查步骤的相关BP之后，就是这条行动调整类的工程实践。真正落地的改进可能是在下一轮PDCA的执行中体现，而在这里的部分，更多的是沟通的内容。
如图左侧——通过基本实践“沟通约定的‘工作产品 x’”确保在"V"左边的信息流。术语“约定”这里是指在受影响方之间对工作产品的内容有共同的理解。
如图右侧——通过基本实践“总结和沟通结果”确保在"V"右边的信息流。术语“总结”指的是测试执行所产生的抽象信息对所有相关方是可用的。
至于二级的行动调整部分，对应列表如下——
| 流程属性 | 通用实践 |
| PA 2.1 实施管理过程属性 | GP 2.1.4 调整过程的实施。 |
| PA 2.2 工作产品管理过程属性 | GP 2.2.4 评审并调整工作产品以满足定义的需求。 |
最后
运用过程方法解读ASPICE是一项重要的原则，PDCA戴明环的思路帮助我们有序地理解其中的实践序列，然而这个方法论不一定适应所有地过程域，还是要具体问题具体分析，在相应的过程域中选择适当的过程方法。