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）

软件单元测试，可参考如下文章，获得更详细的解读和示例：

• ISO26262软件部分的测试: (1) 软件单元测试

② 依据详细设计中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）

这个部分，通常都不会有什么疑问，本文也不对此进行赘述了。

感兴趣的读者，可参考如下文章：

• ISO26262软件部分的测试: (3) 嵌入式软件测试

(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的范围。