ASPICE开发流程

前言

        好多做汽车软件的工程师都听过ASPICE这个词语，也大概清楚是怎么样一个流程，但是说到具体产物的时候，好多人都回答不上来，今天给大家分享下我学到的一些想换流程及产物的介绍，这个是我根据企业标准和ASPICE标准文档汇总出来的，希望能给大家一些帮助，不对的地方即使提醒并修改。

 第一部分：过程能力等级

级别	过程属性	评定	说明
等级0级	-	-	没有任何过程，代表一种不完备的混乱状态，没有流程可循，输出的工作产物是不确定的，有的可能有用，也可能没有。
等级1级	PA1.1:过程实施	主要	虽然能够完成产品研发相关的工作，但是缺乏项目管理，偶尔能够成功，但都是基于个人输出的工作产物，对项目质量缺乏整体掌控能力，无法确保一定能够按时交付高质量的产品
等级2级	PA1.1:过程实施 PA2.1:实施管理 PA2.2:工作产品管理	完全 主要 主要	代表在项目中不仅能够完成产品研发相关工作，还能对所有活动进行提前规划和持续监控，但是没有标准规范，没有整体计划安排，只能一步一步进行汇总收集
等级3级	PA1.1:过程实施 PA2.1:实施管理 PA2.2:工作产品管理 PA3.1:过程定义 PA3.2:过程部署	完全 完全 完全 主要 主要	代表不仅每个项目能够管理得很好，而且能够建立公司级的标准工作流程，形成组织的知识资产，可以指导后续项目的开展，通过项目经验层层迭代，一直完善。
等级4级	PA1.1:过程实施 PA2.1:实施管理 PA2.2:工作产品管理 PA3.1:过程定义 PA3.2:过程部署 PA4.1:定量分析 PA4.2:定量控制	完全 完全 完全 完全 完全 主要 主要	先述的已建立的过程，在定义的限值内可预测地运作以达成其过程成果。识别量化管理需要，收集和分析度量数据，以识别波动的可查明原因。采取纠正措施来解决波动的可查明原因。
等级5级	PA1.1:过程实施 PA2.1:实施管理 PA2.2:工作产品管理 PA3.1:过程定义 PA3.2:过程部署 PA4.1:定量分析 PA4.2:定量控制 PA5.1:过程创新 PA5.2:过程创新实施	完全 完全 完全 完全 完全 完全 完全 主要  主要	先述的可预测的过程得到不断地改进，以适应组织的变化。

以上就是过程能力等级划分，目前好多企业大部分都要求到达3级，也就是一个比较标准的一个要求，就是你的产物清晰明了，产物对应需求，通过一条需求ID可以追溯到整个开发过程，比如一条系统需求，可以查到他的软件需求-软件架构-软件详设-软件单元验证等等。后边的4级和5级，分别对应产物分析与产物创新优化，ASPICE在过程等级审核中，只能一级一级去审核，举个例子，在评定三级的时候，需要你已经评定了二级作为基础；

第二部分：总体框架

下边这个图大家应该都见过吧，整个流程的框图

接下来我讲解下软件工程过程的开发及产物

SWE.1软件需求分析：

第一部分主要讲述了软件需求的开发，从软件工程师依据系统需求进行分析，需要的工具、脚本、软件；工具例如（PE、canoe、canape、周立功）等，脚本例如（.dbc、Arxml文件）软件例如（编译器、调试器、Vector、simulink）对环境进行安装配置。依据定义需求，来做出初始版软件架构的框架，然后  澄清哪一部分是由软件开发的系统需求，结合系统定义的系统架构设计，最终作为软件需求，最后通过评审完成后，最终释放到相关工程师；

在评审过程中出现新的需求，需要反馈到拓展软件需求进行需求变更请求，变更的需求需要输出《变更记录》要求说明变更原因、新增删减还是变更，变更内容的前后变化，在所有变更完成之后，需要释放《沟通记录》

主要产物：

输入产物	输出产物
《软件项目计划管理》 《系统软件规范》 《系统架构设计》  《硬件软件接口规范》 《软件架构规范》 《系统规范》 《软件需求规范》 《软件规范》	《文档概览》 《软件规范》 《软件需求规范》 《审查记录》 《沟通记录》 《变更记录》 《追溯记录》 《接口需求规范》

《软件需求规范》：https://blog.csdn.net/yangren123456789/article/details/140172067?spm=1001.2014.3001.5501

SWE.2软件结构设计：

这一部分主要是决定整体架构的设计，依据整体架构来划分软件功能，底层的内存分配、时钟，中断之类的话分，设计完的产物同样需要进行评审，然后释放对应的工程师；

在前期的分析问题中，首先要分析SWE.1的产物是否符合接下来要做的工作，一旦出现问题需要及时更正说明并作出《沟通记录》和《变更记录》，然后根据系统需求进行输入输出的分析（CAN矩阵），得到总的输入输出，整个时候计划处整个软件架构的输出物，接下来就根据系统功能参数，决定内存分配问题，设计整体的软件架构，包括应用层的多个SWC划分、同时定义《软件概要》

主要产物：

输入产物	输出产物
《软件规范》 《系统架构设计》 《开发者相关文件》 《开发环境描述》 《输入输出列表》 《工程项目简介》	《软件概要》 《相关开发者文件》 《软件架构设计》 《软件层级介绍》 《流程视图》 《软件层级》 《追溯记录》 《接口需求规范》

《软件概要》：定义每个SWC软件输入输出的类型、枚举、范围；

《相关开发者文件》：在软件架构设计阶段产生的额外备注性质文件，通常是开发过程中一些异常情况的说明

SWE.3软件详细设计及单元结构：

这一部分就比较简单了，熟悉需要满足的软件需求和软件架构以及需要修复的缺陷，同时软件工程师会提出开发过程中所需要的软件及工具，对软件开发产物源代码进行评审最终释放到相关工程师

输入	输出
《软件架构设计》 《软件规范》 《软件详细设计》 《审查协议》 《软件详细设计》 《项目团队名单》 《开发环境描述》 《软件规范》	《软件详细设计》 《审查协议》 《软件详细设计发布》 《沟通记录》 《开发软件测试》 《源代码》 《软件规范》 《追溯记录》

《审查协议》针对于软件详细设计过程评审的结果

SWE.4软件单元验证：

软件测试计划人员主要负责审核整个SWE.4的开发产物及规范、收集测试结果

软件开发人员主要对源代码进行静态代码分析，比如规范、准测

软件单元测试人员主要复测软件单元测试编软件测试规范

整个流程中。软件测试计划人员（类似主要负责人）编写《组件测试计划》，根据软件详细设计创建《软件单元验证策略》同时会主导审核软件单元验证策略，随后开发人员和会将代码做代码分析，同时测试人员编写《软件测试规范》，完成以上后，软件单元测试人员会进行软件测试，最后，软件测试计划人员会收集测试结果《静态代码分析报告》和《软件单元测试协议》，并发送《分析报告》告知相关人员

输入	输出
《软件组件验证策略》 《审查协议》 《源代码》 《组件测试计划》 《软件详细设计》 《审查协议》 《软件组件验证计划》 《组件测试计划》 《单元测试规范》 《软件单元测试协议》	《组件测试计划》 《软件组件验证策略》 《静态代码分析报告》 《单元测试规范》 《审查协议》 《软件单元测试协议》 《沟通记录》 《分析报告》 《追溯记录》

SWE.5软件集成测试：

这一部分的具体信息后续会补上，

SWE.6软件系统测试：

这一部分的具体信息后续会补上，