ASPICE V4.0中SWE部分的SWE.4, SWE.5，与ASPICE V3.1相比，其范围和边界进行了调整进而更加明晰
本文对SWE的各Process的范围、边界和主要内容进行举例说明，帮助读者更好的对其进理解
(1) 软件需求 （映射到SWE.1）
通常情况下，在定义“软件需求”时，是把软件当成一个“黑盒”，描述软件需要实现的功能性需求和非功能性需求。
示例：
SW_REQ_01: BMS软件，每50ms，从XX Pin读取电芯电压数据
SW_REQ_02: 当电压持续超过5V，持续时间500ms时，BMS软件判断电芯电压是过压
SW_REQ_03: 当电芯过压时，BMS软件发出切断接触器的指令
(2) 软件架构设计 （映射到SWE.2）
软件架构设计
是对软件需求的Solution
识别出软件有哪些SW Component，以及这些SW Component之间需要如何交互，才能实现需求
设计过程中，为满足设计原则或非功能性需求（如：高内聚，低耦合，可扩展性，Safety等）的要求，需要进行一些设计决策
示例：
如上图所示，在软件架构设计中：
识别了SW Component：Data Processor, Sensor Handler, ADC Driver, Actuator Driver
设计了SW Component之间的交互关系：时序图
识别了SW Component的接口函数，以及其职责（SW Component Behavior），例如：
(3) 软件详细设计 （映射到SWE.3）
软件详细设计
是对软件架构设计中的SW Component的进一步设计
识别出SW Unit，以及这些SW Unit之间的交互调用关系
对SW Unit进行设计
同时，设计过程中，需要满足设计原则（如：低复杂度、低关键性、低交互等） 的要求
示例：
① 识别出SW Unit，并设计SW Unit间的调用关系，如下图：
②对SW Unit进行设计，如下图：
(4) 基于“软件详细设计”的测试
① 依据详细设计中SW Unit的设计，对SW Unit的测试 （映射到SWE.4 BP1, BP3）
软件单元测试，可参考如下文章，获得更详细的解读和示例：
② 依据详细设计中SW Unit间的交互调用关系，而进行的SW Unit集成测试 （映射到SWE.5 BP1, BP4）
(5) 基于“软件架构设计”的测试
① 依据软件架构设计中SW Component Behavior，对SW Component的测试 （映射到SWE.5 BP2, BP5）
读到此处，读者可能会有这样的疑问：
SW Component的接口函数，在单元测试的时候已经测试过了，再测试的话，是不是重复了？（这个问题留个读者来思考哈）
② 依据软件架构设计中SW Component间的交互，进行的SW Component集成测试 （映射到SWE.5 BP1, BP4）
软件集成测试，可参考如下文章，获得更详细的解读和示例：
(6) 基于“软件需求”的测试（映射到SWE.6）
这个部分，通常都不会有什么疑问，本文也不对此进行赘述了。
感兴趣的读者，可参考如下文章：
(7) 总结
SWE Process间的对应关系，如下图所示：
最后有一点碎碎念：
ASPICE中的Process与项目中的Process，很多时候不需要一一对应。
例如：
项目中的SW Unit Test中，包括了SW Unit测试、SW Unit Integration测试。
不能因为ASPICE V4.0 将SW Unit Integration Test放在了SWE.5，就调整项目中的SW Unit Test的范围。
关于这个话题，可参考如下文章：
（ -- 完 -- ）
先起公司近期公开课：
推荐阅读：
欢迎访问公众号菜单，下载文章合集
