3.1独有而4.0删除的会用删除线。
3.1到4.0没变化的会用斜体。
4.0新增的会用正体加粗。
本系列会分三篇文章，分别是基础运行逻辑（ASPICE标准的框架、基础概念与评估逻辑）、ASPICE L1（过程参考模型）和ASPICE L2~L5（不同的过程能力等级），本文是第二篇。
ASPICE L1过程参考模型涉及3个过程类别、118个过程组及32个过程。但限于篇幅，我们只进行整体的阐释，不对指标进行拆分。
1
获取过程组（ACQ）
这个ACQ被翻译成了获取，但业内习惯叫法是询价或报价，基本都是发生在新项目早期的OEM对Tier 1或者Tier 1对Tier 2，也就是客户与供应商。
一般来说，客户采购会通过供应商销售这个口子，将询价的各类大需求送达，并限定报价时间。这时的需求包常被称为RFQ或SOR（Statement Of Requirement，需求说明书）。
销售呢，转手将相关文件分发给工程、工厂、物流等角色去分析。各个责任人与客户或内部采购或供应商对应接口将方案、风险等确认后，再协同对应部门的成本一起汇总给销售，销售综合之后，向客户报价。
这是个简单的理论路径，实际上，报价阶段项目组介入不多，参与者多是销售或项目经理等少数人，流程也不会非常规范，会有各种操作。
相比较3.1，4.0在ACQ过程组删除了6个过程，如下图。
ASPICE 3.1
ASPICE 4.0
1.1 ACQ.3合同协定
当走到这一步，前期工作基本完成。接下来，就要准备定点给这家供应商了，后续要走商务合同的签署，明确好双方的权利与义务等等，也就是本节所谓的“合同协定”。
商务合同涉及法律条文，所以多数是定式，修改里面部分项目信息即可，但是在报价阶段形成的以及与项目相关的技术协议、技术方案、各类承诺文档乃至邮件，其实都是可以作为合同的附属物来约束双方。
甲方的威严和乙方的挣扎，很多时候，都需要台面上的这些东西来维护和推进。
商业社会中，项目经理或销售都需要有敏感的法律和契约意识，邮件不乱发，字不乱签，话不乱说。尽管合作成熟的甲乙方不怎么会对簿公堂，但“扯皮”却是不可避免的。因为某方乱承诺或没有留好证据，导致自己陷入被动和胶着是非常常见的。
1.2 ACQ.4供应商监控
监控这个词放在汽车行业的语境里是不够精准的。其实就是，日常项目开展中，客户对供应商的管控。比如，根据客户行业地位的高低和前期的约定，进行开会盯、评审看、电话催、微信问、邮件投诉各类常规操作，就是客户要想办法让供应商按时保质地完成他的各种要求，包括但不限于上一部分的合同协议涵盖的内容。
相比较3.1，4.0在该过程主要有以下变化：
语言描述更精炼、更具概括性。
记录（record）改为证据（evidence）。
删除了评审的表述。
9个工作产品（work product）降为8个信息项（information item）。
......
1.3 ACQ.11技术需求
需求与技术需求这两个概念本身都不复杂，但后面章节还专门细分了系统、软件需求，所以这里的需求实际上更侧重于报价阶段宏观的、描述性的、概要的需求定义。
理论上或期望上，我们追求在报价阶段就将需求范围锁定，做什么，不做什么，什么时候做，一清二楚。显然，又是不太可能的，一来报价阶段持续时间很短，介入的人不太容易涉及各方专家；二来这个阶段的很多信息还不清楚，无法做最终决定。
风险和不确定性一定存在。那么，怎么做呢？其实，就是基于经验、项目复杂度及重要程度，关于到底带多大的风险而进行的权衡。
如果面对相对成熟的或重要级别没那么高的项目，会使用参考或假设的描述，比如，对于尚不清晰的部分，可以说基于某款量产的整车空间和某款量产ECU的技术要求，增加某项功能，参数范围是多少，并按照哪一标准完成实验，如后续有超出的范围，另行谈判......通过这样的方式，框定一个范围，并留有一定的余量，虽说带一些风险，但后期总是有办法吃掉的。
但如果面对的是新型的或很重要的项目，可能会引入更多的职能角色进行更细致的分析，结合历史LLs和新的要求去考虑得更全面，以尽量避免难以掌控的情况出现。
1.4
ACQ.12法律和行政要求这个属于项目红线，相关角色要绷紧神经。一般涉及出口国家的法规、认证、运输等各类需求，或者本国的法律、行业的强标以及专利侵权的一些考量。
比如，有些产品受到政治限制是无法出口到伊拉克之类，或者型式认可（上公告）需要特定状态的产品，或者UI文言涉及国家主权之类的......
1.5 ACQ.13项目需求
这部分包罗万象，除了技术的、法规的、资质的等特定需求部分，其余所有需求都可以划归到这里。所谓万事皆可项目，万事不离项目，万事都可找项目经理。
具体来说，要看具体的产品特点和以往项目的运作模式。双方的项目接口人员与内部团队，在共同协定下，定义好怎么推进问题、怎么跟踪进展、怎么分配任务、怎么划分职责、怎么沟通交流、怎么交付软件或样件、怎么付款、怎么进行风险或bug管理、安排什么资质的工程师......
期望的做法是，不仅仅停留在口头和不正式的临时约定上，还要落实成规则、流程。
1.6 ACQ.14提案要求
在汽车行业，将其粗略理解为RFQ或SOR包更好些。
采购发包时，会将很多需求包含在内，除了前面提到的项目、技术、财务、人力、法规之类，报价本身也会有一些特殊的要求，可能会对R&D成本有特别的拆分需求，可能会有多家供应商竞标的要求，可能会有供应商能力评定的要求，可能会有售后支持的要求......
标准里的描述很宽泛，仅仅给了一个概念上的框架。实际操作中，会有不同类别的要求通过该阶段发布给竞标供应商。
1.7 ACQ.15供应商资质鉴定
这和ASPICE、16949以及所有考级或认证的考试或评定一样，在建立好的一套评估体系里给它打个分、划个级别、贴个标签，以便于后续选择时作为参考。
采购部门里一般会有供应商的库，可能会有不同的标签标记，如红黄绿或者首选次选之类。然而，无论如何，供应商资质只是一个很低的门槛，选定一家供应商有诸多无法尽述的明暗规则。
2
供应过程组（SPL）
2.1 SPL.1供应商投标
这里不作详述，因为这部分和ACQ实质上是混杂在一起的，招标与投标是协同做一件事情。
相比较3.1，4.0在SPL过程组删除了1个过程，如下图。
ASPICE 3.1
ASPICE 4.0
2.2 SPL.2产品发布
换句话说，产品发布就是供应商将样件或软件交付给客户的过程。
在此过程中，会涉及软件版本号定义、样件标签定义、供应商内部批准、Release Note编制、测试报告提交、客户认可......一系列管理过程。目标是将客户需求的软硬件正确及时地交给客户。
相比较3.1，4.0在该过程主要有以下变化：
语言描述更精炼、更具概括性。
删除了释放所需媒介的要求。
删除了批准、确认、计划这些形式化行为。
删除了释放时建议的识别编号。
删除了计划的表述。
记录（record）改为证据（evidence）。
删除了评审的表述。
6个工作产品（work product）降为5个信息项（information item）。
BP数量从13个降到8个。
......
3
系统工程过程组（SYS）
系统工程和软件工程组的整体思路是，从需求、设计、验证3个角度逐级拆分，并完成追溯。从客户一句话到一段代码，颗粒度会越来越小，做得也越来越精细。
就像做十字绣，从想要“家和万事兴”的一句话，到一张布画出很细碎的格子，再到明确每个格子谁来用什么线与什么针法。格子越细，越容易标准化，越容易分工，出错的概率越低，难度越低，越容易重复成功。
相比较3.1，4.0在SYS过程组未增删过程，但在验证测试部分调整了表述，即强化了验证（verification）的概念，如下图。
ASPICE 3.1
ASPICE 4.0
3.1 SYS.1需求挖掘
需求是我们开展项目的目标，所谓目标导向，就是需求导向。
这里所讲的需求不仅仅限于客户需求，是指所有相关方的需求，领导的、工厂的、采购的、销售的、开发的、测试的......也会以各种形式存在，明示的、暗示的、文本的、邮件的、微信的、电话的......
总之，所有有关系的人的想要的都要被考虑到，只是有些不那么重要的人的需求往往被忽略和平衡掉。
需求挖掘的几个核心点是要沟通、要理解、要达成一致，而后要持续跟踪，并确保变更要被管理、是否实现要定义清楚等。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼、更具概括性。
删除了基线（baseline）与追溯的表述.
删除了需求变更或监控或沟通机制建立的表述.
删除了需求变更管理活动的表述。
删除了计划的表述。
记录（record）改为证据（evidence）。
删除了评审的表述。
6个工作产品（work product）降为4个信息项（information item）。
BP数量从7个降到4个。
......
3.2 SYS.2系统需求分析
在识别出各位想要什么之后，不是满口答应，而是要去分析，要看它们对不对、能不能做、能不能验、值不值得做，还要将上一阶段相对杂乱的需求整理，进行结构化和优先级排序，要确保把相关方的需求很好地梳理了出来，并形成了清晰、层次分明且不遗漏的技术语言。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼、更具概括性。
强调了需求的结构化。
强调了需求撰写的规范性（参考ISO/IEC/IEEE 29148和ISO 26262等要求）。
删除了需求变更的表述。
删除了需求验证准则的表述。
记录（record）改为证据（evidence）。
报告（report）改为结果（result）。
删除了评审的表述。
8个工作产品（work product）降为5个信息项（information item）。
BP数量从8个降到6个。
......
3.3 SYS.3系统架构设计
要什么清楚了，然后就是设计。这步是架构的设计，比如，要形成架构框图、接口定义、时序图等，还要进行与需求的追溯。相当于你要装修房子，店家给你弄了个效果图。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼、更具概括性。
提出了特殊特性（special characteristic），这是在强调16949中的硬件和结构件。
删除了架构备选方案评估的表述。
记录（record）改为证据（evidence）。
删除了评审的表述。
BP数量从8个降到5个。
......
3.4 SYS.4系统集成与集成测试验证
从技术上来讲，系统集成就是根据BOM在硬件上刷新软件，并搭建好相关的整车或网络环境等。
集成验证的目标是确认架构对不对，可能会关注到系统组件之间的正确信号流、信号流的时效性、时序依赖性、接口的动态交互等。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼、更具概括性。
将测试（test）改为验证（verification），强化了测试分层概念。
删除了集成策略和集成测试策略的表述。
删除了测试规范、测试用例的表述，取而代之是是更宽泛的验证措施（verification measure）。
提出了发布或交付范围（release scope）的概念。
记录（record）改为证据（evidence）。
删除了评审的表述。
7个工作产品（work product）增加为8个信息项（information item）。
BP数量从9个降到5个。
......
3.5 SYS.5系统合格性测试验证
系统验证也叫系统需求验证，就是看看系统需求有没有做到位。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼、更具概括性。
将合格性测试（qualification test）改为验证（verification），强化了测试分层概念。
删除了测试策略的表述。
删除了测试规范、测试用例的表述，取而代之是是更宽泛的验证措施（verification measure）。
提出了发布或交付范围（release scope）的概念。
记录（record）改为证据（evidence）。
删除了评审的表述。
BP数量从7个降到5个。
......
4
软件工程过程组（SWE）
相比较3.1，4.0在SWE过程组未增删过程，但在验证测试部分调整了表述，即强化了验证（verification）的概念，如下图。
ASPICE 3.1
ASPICE 4.0
4.1 SWE.1软件需求分析
软件需求和系统需求类似，就是将上一层级的系统需求与系统架构再细分为更贴合编码的软件需求语言。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼、更具概括性。
强调了需求撰写的规范性（参考ISO/IEC/IEEE 29148和ISO 26262等要求）。
删除了需求验证准则的表述。
提示了软硬件接口信息要作为输入。
记录（record）改为证据（evidence）。
报告（report）改为结果（result）。
删除了评审的表述。
8个工作产品（work product）降为5个信息项（information item）。
BP数量从8个降到6个。
......
4.2 SWE.2软件架构设计
架构设计呢，也就是针对最后一层的需求——软件需求，进行的方案和架构设计。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼、更具概括性。
删除了架构备选方案评估的表述。
记录（record）改为证据（evidence）。
删除了评审的表述。
5个工作产品（work product）降为4个信息项（information item）。
BP数量从9个降到5个。
......
4.3 SWE.3软件详细设计和单元构建
根据架构划分的模块，软件开发人员就可以进行详细的编码设计，会形成一个个的可执行文件。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼、更具概括性。
强调了源代码也需要在相关方之间沟通。
针对静动态行为描述，给出了一些更具体的提示，如接口数据范围、UML语言描述等。
记录（record）改为证据（evidence）。
删除了评审的表述。
5个工作产品（work product）降为4个信息项（information item）。
BP数量从8个降到5个。
......
4.4 SWE.4软件单元验证
软件单元设计完后，依然需要验证，只不过这里更多是针对本身设计合理性进行的，比如，静态分析、依照编码规范的检查等。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼、更具概括性。
删除了测试策略的表述。
删除了测试规范、测试用例的表述，取而代之是是更宽泛的验证措施（verification measure）。
提出了发布或交付范围（release scope）的概念。
记录（record）改为证据（evidence）。
删除了评审的表述。
8个工作产品（work product）降为6个信息项（information item）。
BP数量从7个降到5个。
......
4.5 SWE.5软件集成组件验证和集成测试验证
软件集成是将一个个可执行的单元文件集成为完整的集成软件，而后进行集成验证，以确认其是否符合软件架构设计。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼、更具概括性。
提出了要该过程要满足详细设计。
删除了测试策略的表述。
删除了测试规范、测试用例的表述，取而代之是是更宽泛的验证措施（verification measure）。
提出了发布或交付范围（release scope）的概念。
记录（record）改为证据（evidence）。
删除了评审的表述。
BP数量从9个降到7个。
......
4.6 SWE.6软件合格性测试验证
同系统验证类似，也就是针对软件需求进行的验证。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼、更具概括性。
删除了测试策略的表述。
删除了测试规范、测试用例的表述，取而代之是是更宽泛的验证措施（verification measure）。
提出了发布或交付范围（release scope）的概念。
记录（record）改为证据（evidence）。
删除了评审的表述。
BP数量从7个降到6个。
......
5
确认过程组（VAL）
此为4.0新增，恰逢其时。以前的嵌入式软件开发聚焦在满足从主机厂传递下来的需求，但我们现在需要关注真实实车环境中终端用户的使用情况，而他们的需求常常是主观的、难以用语言阐明的。
实际上，这份工作本身并不是多新鲜的，4.0提出来，具备的意义更多是引导大家将开发思维从“工程逻辑”转向“用户满意”。
ASPICE 4.0
6
机器学习过程组（MLE）
此为4.0新增，主要是增加了一个智驾算法训练与ASPICE的接口，提出了要关注机器学习需求、数据集、训练环境、架构定义、模型训练及模型验证等，思路与ASPICE其他工程过程域接近。
不过，由于现在的算法公司基本不是ASPICE背景下发展来的，而且机器学习也非我所深刻理解的领域，暂不扩展。
ASPICE 4.0
7
硬件工程过程组（HWE）
此为4.0新增，再次强化了汽车车载软件是ASPICE的主要客户。
7.1 HWE.1 硬件需求分析
实际上，硬件需求是和软件需求同层级或同阶段来识别的，都是要从系统需求与系统架构来拆分，也都要考虑软硬件接口的要求。
7.2 HWE.2 硬件设计
基于硬件需求进行硬件设计是顺理成章的，但硬件设计还需要考虑到一些生产与可靠性的要求，这个又是完全不同于系统工程与软件工程的另一个方向的学科。
另外，硬件设计不像软件设计，并未对架构和详细设计进行拆分，这既与复杂度相关，也与可见度相关，还与硬件元器件分散供应有关。
这个环节要关注到具体的供电、接地、EMC、选型、AEC-Q、BOM等电子电气件的一些内容。
7.3 HWE.3 硬件设计验证
硬件验证的逻辑依然是去符合设计，这里不同于软件的一个特殊点在于，硬件是生产制造出来的，生产是物理的，也就是有变差的，所以生产工艺管控是要关注的。
7.4 HWE.4 硬件需求验证
硬件需求验证回归到功能级或需求级，面向产品或系统的，这与系统需求验证及软件需求验证思路一致。
8
支持过程组（SUP）
相比较3.1，4.0在SUP过程组删除3个过程（ASPICE中最具形式化的内容）和新增1个过程（机器学习数据管理），如下图。
ASPICE 3.1
ASPICE 4.0
8.1 SUP.1质量保证
特别是在国内环境下，这个角色其实一直处于相对比较尴尬的境地。
理论上的定义是，作为独立第三方去保证工作产品（不单单是软件产品，还包括其他各类要交付的文档等）和流程符合规定及计划，但达到这个目标的前提是，有脱离于具体场景的标准（即不是具体问题具体分析）和执行标准的文化，显然这很难具备。
ASPICE似乎也意识到了，所以有这么两句话，“建立了将不符合项升级到适当管理层的权限“和”管理层确保已升级的不符合项得到解决”，但目前环境下的管理层多数并无这样的认识。
“实事求是”、“具体问题具体分析”、“成王败寇”是中国的经典智慧，但执行起来就是给质量保证工作当头棒喝。如果事情以结果论英雄，凡事可讨论，质量保证很难有发挥空间。不过，到什么山唱什么歌，在什么环境按照什么样的方式做事，这个角色依然可以拓展到不同的领域。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼、更具概括性。
删除了质量保证策略的表述。
记录（record）改为证据（evidence）。
BP数量从6个增加到7个。
......
8.2 SUP.2验证
这里的验证和软件的测试是不同的概念，它具有更广泛的涵义，是指对确认每个工作产品是否满足定义的要求的行为，包含但大于测试，比如，同行评审、领导签字、第三方审核等。
8.3 SUP.4联合评审
这个概念单独拿出来，其实是侧重于整体项目状态的确认，以能够让多个相关方达成共识，有意见提前讲。所谓联合就是整体，所谓评审就是确认。
通俗点，就是大家一起理理清、对对齐。对照实际的工作，基本可以等同于质量组织的各个节点的质量评审或审计，这部分也是质量保证工作难得的发声场景。
8.4 SUP.7文档化
标准定义的目的是“开发和维护由过程产出的记录信息”，关键词在“信息”。
尽管大家往往比较反感这部分工作，但至少截至目前，我们找不到更好的信息传递方式，数字化可能能解决一部分传统文档化的弊端，但由于其工具使用有一定的门槛、编辑展示不够灵活、未足够普及、技术尚未成熟等不足，并不能取代文档。
无论是敏捷变更也好，还是数字化转型也好，文档的优化都是一大课题，后续我们可以持续思考探索。
8.5 SUP.8配置管理
关于配置管理，在历史文章已有充分的讨论，这里不赘述了。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼、更具概括性。
删除了配置管理策略的表述。
7个工作产品（work product）增加为8个信息项（information item）。
BP数量从9个降到8个。
......
8.6 SUP.9问题解决管理
问题包括软件bug或其他项目相关问题，总体要求是要有特定ID、来源、发生阶段、严重或紧急等级、发生场景、发生版本、原因分析、解决方案、责任人等。
由于软件bug动辄几百上千，所以bug的管理流程是相对规范的，而且bug基本代表了软件产品的状态，相应地，受到的关注度也比较高。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼、更具概括性。
删除了问题解决管理策略的表述。
记录（record）改为证据（evidence）。
5个工作产品（work product）降为3个信息项（information item）。
BP数量从9个降到7个。
......
8.7 SUP.10变更请求管理
变更是个老生常谈的话题，变更本身不具备特殊性，实际上会驱动一次简化的或完整的开发过程。其中的关键点在于，变更要经过预先可行性分析和CCB上是否执行的批准。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼、更具概括性。
删除了变更管理策略的表述。
删除了评审的表述。
4个工作产品（work product）降为3个信息项（information item）。
BP数量从8个降到个。
......
8.8 SUP.11机器学习数据管理
智能驾驶的算法模型训练需要喂大量的数据，自然会衍生出数据的管理，包括数据管理系统、数据的质量、数据的收集、数据的处理等多个领域。
9
管理过程组（MAN）
相比较3.1，4.0在MAN过程组未增删过程，如下图。
ASPICE 3.1和ASPICE 4.0
9.1 MAN.3项目管理
ASPICE并没有将项目管理讲出什么花样来，权威的论述还是要看项目管理宝典PMBOK。
这里其实想分享点对项目管理另外的看法，如果要挑选出前三点，一个好的项目经理最需要的素质是：积极的沟通、很强的抗压能力和全面的业务逻辑。其余呢，要靠经验积累了。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼、更具概括性。
提出了要关注发布或释放的范围。
删除了评审的表述。
记录（record）改为证据（evidence）。
9个工作产品（work product）增加为11个信息项（information item）。
......
9.2 MAN.5风险管理
每次看到风险管理，总有种无语的感觉，就像我们前面所说的“流于形式化”。除了比较流行的FMEA、FTA等工具，常规的项目经理维护的那个风险管理表格，确实有种应付交差的样子。
实际的项目推动，基本是靠开口项、靠bug管理、靠变更管理。唯独风险，着实难以独立落地，并不是不存在，而是都融合到了其余环节，比如，识别出什么风险后，会首先定义相关的调整任务，而不是去做一下风险管理。
当然，并不是没价值，而在于如何挖掘。此外，有时候需要汇报项目状态时，或者做一个什么决策选择时，也会用到这个概念。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼、更具概括性。
删除了风险管理策略的表述。
9个工作产品（work product）降为4个信息项（information item）。
......
9.3 MAN.6度量
度量离不开数据，数据离不开真实、及时和完整。这也是比较难做到的，但聊胜于无吧，越是关键的判断和决策越会关注数据的有效性。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼、更具概括性。
删除了度量组织承诺的表述。
删除了度量策略的表述。
15个工作产品（work product）降为5个信息项（information item）。
BP数量从11个降到6个。
......
10
过程改进过程组（PIM）
相比较3.1，4.0在PIM过程组未增删过程，如下图。
ASPICE 4.0
10.1 PIM.3过程改进
过程改进是个很有价值的点，最有机会的人其实是前线战斗的人，但这批人往往没动力，反正一个项目交付了就好了。所以，这部分常会沦落为EPG（Engineering Process Group）自嗨的领地。
这很需要制度来驱动大家的积极性，最直接的是通过钱来鼓励大家动起来。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼、更具概括性。
13个工作产品（work product）降为10个信息项（information item）。
BP数量从9个降到8个。
......
11
重用过程组（REU）
相比较3.1，4.0在REU过程组未增删过程，但调整了表述，即更聚焦在产品的重用上，如下图。
ASPICE 3.1
ASPICE 4.0
11.1 REU.2重用程序产品管理
这个概念和平台化与共享化很接近，核心在于如何最大化利用现有资源。
对于汽车行业软件开发，相当于裁剪。针对不同复杂度的项目，将部分活动进行裁剪，主要也就是进行复用或重用，比如，A项目的某些测试结果可被B项目拿来重用等。
4.0的该过程相比较3.1，主要有以下变化：
语言描述更精炼，也更聚焦在产品上。
删除重用策略的表述。
记录（record）改为证据（evidence）。
9个工作产品（work product）降为5个信息项（information item）。
BP数量从8个降到6个。
......
以上，算是聊了下ASPICE眼里应该完成的基本任务和达到的基本目标，以及它们在实际工作中是怎么体现的，即一篇作文基本成文后是什么样子的。
12
全文小结
针对过程参考模型和ASPICE L1，ASPICE 4.0相比较ASPICE 3.1，除了新增了HWE、MLE和VAL这3个过程组之外，其余部分整体进行了比较多的删减，可以总结为以下5点：
语言描述更精炼、更具概括性，即给具体如何做留出更大空间。
工作产品（4.0使用信息项替代）和BP数量基本都在下降。
删除了各类策略的定义，更加务实了。
明显地在弱化文档的要求，比如，record或report不再提，取而代之的是evidence或status，以及测试规范和测试用例用更宽泛的验证措施替代。
弱化评审、批准、计划之类较为形式化的要求。
13
写在最后
写完第二篇，更强烈地体会到ASPICE 4.0在稳步却坚定地拥抱敏捷。
这也是我更认可的敏捷——在现有汽车软件开发体系体系下加速提频。
关注公众号，点击公众号主页右上角“ ··· ”，设置星标，实时获取公众号“水轻言”最新文章。
完
