ASPICE流程体系入门

前言：

必须说明，ASPICE是个很复杂的概念，涉及很多方面的知识。大家也不要希望是一篇文章就弄清楚所有问题。

本文是从供应商的角度去切入，和大家一起学习ASPICE。后面有时间会切入到OEM（主机厂的角度）和大家一起学习。

1：了解ASPICE的流程概念

ASPICE（Automotive Software Process Improvement and Capability Etermination）是汽车产业的软件流程改进和能力测定标准（牢记这个概念，对象是专门针对汽车产业的软件流程，内容是流程改进和能力测定标准），旨在提高汽车供应商的软件研发能力。

流程改进的核心思想和方法，包括且不限于，控制文档输出，控制开发过程（V开发模型），控制软件变更的方法和流程。建立双向追溯的机制。

能力测定则是对流程和流程所获得的结果的一种评分系统。

也就是说这是一种专门针对软件开发和验证流程的标准？不要被他的名称所欺骗，ASPICE是完整的覆盖了所有的开发人员（销售+项目经理+研发（软件+硬件）+测试+质量等都被纳入到这个体系中），是为产品的开发，生产销售过程中的一系列都做出了规定或指导。

对于初次了解ASPICE的童鞋，可能被复杂的描述所吓倒。

很多资料如此，描述。ASPICE流程共分为“3大过程” 、“8大过程组”、“16个主要过程域”。马上就被吓倒。其实只要有过相关工作经验,即使不是基于ASPICE的工作经验。代入工作流程一步步的分析过程，也能有一个初步的概念理解。

**重要提示，目前ASPICE已经更新到4.0版本，主要新增加了，硬件过程组和，和机器学习过程组。暂时还不知道“3大过程” 、“8大过程组”、“16个主要过程域”的描述还是否适用。

2：流程解析

2.1 ）3大过程**（支持生命周期过程）

2.1.1 概念理解

初步了解下，支持过程组中的几个重要域，全部都是以SUP开头（Support支持），先看这个支持的意思，支持意味着该些过程非ASPICE，主要关注的内容。是属于必不可少，但是任务量，严格要求程度，比主要生命周期过程要宽松一点。

补充说明：

1：以上描述并不意味着，支持组的工作不重要，比如“质量保证域”相关的执行逻辑和规范在IATF16949中已经规定了，不需要Aspice对其作出更多规范和要求

2.1.2 架构和人员组成

支持生命周期过程，只包含一个“支持工作组”。一般人员包括如下（这里按最基本的人员配置来写）

人员	职责	对应过程域	人数
QA(质量)	负责开发质量的审核，评估，对开发过程和结果中的质量负责	SUP1:质量管理
配置管理员	配置，就是管理文件，包括各种文件库的管理，过程域的ID分配，文件升级管理。等工作。	SUP8.配置管理
问题管理	对开发过程中的问题进行管理的人员， 包括测试问题，开发问题，质量问题生产问题，需输出《问题管理计划》。 可以由质量，或项目经理兼任	SUP9 问题解决管理
变更请求管理	对项目开发，生产维护过程中的变更，管理，可以由项目经理兼任	SUP10 变更请求管理

补充说明，配置管理，因为整个ASPICE流程的建立，需要编写大量的说明文件，且这些文件都是由不同的人员编写，如果不对文件作出命名规范就会产生混乱。一般采用如下规则

项目名+过程域名+过程域文档分配的ID+文档名+版本号（后面可自由发挥，可以加上时间，项目阶段+以及其他一些公司层面认为重要的信息）

NBcar_SYS4_系统集成测试规范_V00.00.01(时间+项目阶段等补充信息皆可以)。

此外版本如何升级。文件如何放在公共盘（SVN,PLM,,禅道，OA等工具均可）中，如何分类都需要配置管理去作出说明，和操作。

2.1.3 每个域对应的文档构成

域名称	输出文档
SUP.8 配置管理	1:配置管理计划及评审报告 2：配置项清单 3：配置项检查清单 4：配置状态报告 5：配置审计报告 6：读取权限表
SUP1:质量管理
SUP10,变更请求管理	变更请求管理计划 变更管理计划评审报告 变更状态管理表（也就是变更时，需要填写的表格）
SUP9问题管理	问题管理解决计划及评审报告 问题管理表，就是记录问题的表格，除了说明问题，该表还要有追踪的能力

2.2）主要生命周期过程

2.2.1 概念理解

分为 1）系统工程组Sys（系统开发工作和测试验证工作）（系统工程师+测试工程师+产品工程师）

    2）软件工程组SWE（软件开发，底层+应用层，+测试。比较复杂的项目按功能划分，这个主要看架构）

3）硬件工程组HWE（主要是硬件开发）

4）确认过程组VAL(就是指开发过程中的的领导，)

5)获取过程组（获取过程组，主要是指采购工程师，主机厂OEM就复杂，可能需要技术人员参与，如果开发商委外开发的话，其实也是需要比较复杂的供应商管理的）

6）供应过程组（SPL）,SPL.2产品发布

拓展：ASPICE4.0增加了一个机器学习（MLE）Mechaian Learn ,机器学习，主要是为了适应现在智驾的，比如智驾中的图像识别，就需要大量的机器学习。

2.1.2  SYS架构和人员组成

人员	职责	对应过程域
系统工程师	负责对客户输入的需求，进行挖掘，如果客户需求提的非常笼统，这一步就非常有必要，不过在汽车领域。一般客户给的需求都很细	SYS1:需求挖掘（非关键域）
系统工程师	需求分析，针对客户和挖掘出来的需求，并结合项目资金，人员和物料成本。对需求进行分析，对软件架构，硬件选型作出分析。 该过程，还需要软件，硬件，开发，测试，质量来参与。	SYS2系统需求分析
系统工程师 软件架构+硬件架构	对软件进行结构划分，对软件组件间的接口，API接口，通讯接口等作出设计 对硬件，元器件（芯片选型），硬件模块划分，比如硬件上驱动模块，主芯片模块，供电管理模块，通讯模块（蓝牙，无线模块等） 系统工程师，就是舵手一样，规划好了大框架，后面的人继续添砖加瓦就可以了	SYS3系统架构设计
系统集成测试工程师	对产品进行验证的过程，从系统级别，进行验证（验证方式包括,台架测试+HIL台架测试+实车测试） 此步骤其实可以分为两个不同的步骤，先集成，再测试。 站在产品复杂的维度来说，系统集成测试的重要性也不同。 比如供应商生产一个小模块，没有任何复杂的外设，只有模块内部存在的传感器。只通过CAN总线与整车连接。这种就没有做集成和集成测试的必要了。直接可以跳到功能合格性，或系统合格性测试。 但是，如果从主机厂的角度来看，集成测试是必不可少的，因为主机厂很多零部件都是委外开发的，几千种零部件，是要集成到一部车上的。集成，和集成测试是非常有必要的。	SYS4系统集成和集成测试
系统合格性验证	分为功能性测试和非功能性测试，功能性测试是针对系统需求，依据一些特定的方法设计出来的测试用例，进行测试，主要针对功能点。 非性能测试覆盖也很广阔，包含性能测试 压力测试，耐久测试，ECM测试，DV、PV测试等。。。	SYS5 系统验证

2.1.3  SYS输出文档

域名称	输出文档
SYS2系统需求分析	1:系统需求说明书及评审文件
SYS3系统架构设计	系统架构设计及评审文件 物理架构+静态架构+动态架构
SYS4系统集成和集成测试	1：系统和系统集成测试计划及评审报告 2：系统验证规范及评审报告 3：验证报告及评审报告
SYS5 系统验证	1：系统合格性验证计划及评审报告 2：系统合格性验证规范及评审报告 3：系统合格性验证报告及评审报告

总结：到系统层面，就有输出文档就开始多了，作为供应商来说，很多文档是需要输出给OEM整车厂的。

2.1.4  SWE架构和人员组成

人员	职责	对应过程域
软件工程师	对系统输入的需求，进行分析。到这一步，其实需求就很明显了。软件工程师需要分析，系统需求是否合理，现有的软硬件资源能否实现该需求	SWE1:软件需求分析
软件架构师	对SWE1,提取的需求，结合软硬件条件+开发团队实际能力，设计软件架构	SWE:2软件架构设计
软件工程师	注意：这一阶段不仅仅只是敲代码，敲代码之前需要，对软件中的每个单元（代码段或函数，进行详细的设计思路要作出文档化说明），就是先把思路捋清楚，在执行代码敲定的过程。	SWE:3软件详细设计和单元构建
测试工程师	验证代码覆盖率，验证代码逻辑，验证函数调用	SWE4:软件单元验证
测试工程师	验证软件组件之间的接口，API接口，数据流方向，数据的存储。	SWE5 软件组件验证和集成测试
测试工程师	验证软件合格性（包括功能和非功能） 非功能，包括且不限于系统稳定性测试，ios26262相关的功能安全，和信息安全测试 内存泄漏测试，数组越界测试等 CPU高负载，等情况下的测试过程。	SWE6 软件验证

2.1.5  SWE需要输出的文档

域名称	输出文档
SWE1:软件需求分析	1:软件需求说明书及评审文件
SWE:2软件架构设计	软件架构设计及评审文件 物理架构+静态架构+动态架构
SWE:3软件详细设计和单元构建	软件详细设计文档，和编译通过的代码也需要输出
SWE4:软件单元验证	1：单元验证计划及评审 2：单元验证规范及评审 3：单元验证报告及评审
SWE5 软件组件验证和集成测试	1：软件组件验证计划及评审 2：软件组件规范及评审 3：软件组件报告及评审
SWE6 软件验证	1：软件合格性验证计划及评审报告 2：软件合格性验证规范及评审报告 3：软件合格性验证报告及评审报告

2.1.6 其他主要生命周期的过程组

我对其他4个主要生命周期的过程组，也不是很了解。

**1）硬件工程过程组，

人员	职责	对应过程域
硬件工程师	负责对系统输入的需求，进行挖掘，对一些不满足设计的需求，需要作出说明，对系统中硬件设计的一些易错点和容易出现问题的点作出说明	HWE1:需求分析（关键域）
硬件工程师	硬件域中，只有一个架构设计，而没有硬件详细设计？这点就很不理解。 根据我的项目经验，硬件先要设计架构，再进行原理图设计（同时进行元器件选型，需要考虑项目报价和利润），再进行仿真，仿真无问题后，可以进行PCBlayout。最后可以进行贴片，然后验证。	HWE2硬件架构设计
硬件工程师		HWE3硬件架构验证
硬件工程师		HWE4 y硬件需求验证

 **2）确认过程组

VAL.1 (确认，整车测试)，不太了解

**3）需求，机器学习工程过程组

人员	过程域
机器学习工程师（暂且这么叫）	机器学习需求分析MLE.1
机器学习工程师（暂且这么叫）	MLE2 机器学习架构
机器学习工程师（暂且这么叫）	MLE3 机器学习培训
机器学习工程师（暂且这么叫）	MLE4 机器学习模块测试

**4）获取工作组

ACQ.4 供应商监控

**5）供应过程组

SPL.2 产品发布 

2.3 组织生命周期过程

组织生命周期过程，主要包括三个工作组

2.3.1 管理过程组

人员	职责	对应过程域
项目经理	项目过程管理，主要是指对整个项目组，人员能力评价，交付节点定义，交付物的定义。	MAN.3项目管理
项目经理	风险大概率是指，对项目交付时间管理，对开发过程中出现质量问题，人员的安排解决预案。主要还是从管理的层面来看风险管理	MAN.5风险管理
项目经理	这个暂时还不清楚	MAN.6度量

2.3.2 重用过程组的管理

REU.2 重用程序管理，因为现在基本都是使用AUTOSAR来设计软件，所以会有很多模块会在其他项目可以使用。有因为AUTOSAR中的                        BSW中的很多软件组件是基于平台设计的，所以我们经常听到，买个主机厂或零部件供应商是基于XX平台，设计了一种车型或零部件，就是这个道理。

这个域如果使用，一般也是由经验丰富的软件工程师，或系统工程师来做

2.3.3 过程改进组

PIM.3过程改进，就是对执行过程结合公司实际，人员实际，在具体执行过程中。对具体执行过程提出改进，一般由项目经理，或各个部门的领导兼任。

总结：本文是站在供应商的角度来理解ASPICE流程中，需要作出的规划部署，和工作过程，本人也是在学习的一个阶段，后续会从更细致的角度来解读ASPICE的评价过程。