很多软件开发团队在准备ASPICE评估的时候，都会碰到这样的问题：ASPICE SWE.2到底是什么意思，它的架构设计输出物又包括哪些。SWE.2一般指的是Software Architectural Design，也就是软件架构设计这一步，它关心的倒不是代码该怎么去写，而是软件需求要怎样分解到架构元素里面，软件内部的模块怎么去切分，接口又该怎么去定义，以及后面的编码、集成和测试怎样才能顺畅地接上。在Automotive SPICE里，是用PRM和PAM来描述过程和评估指标的，目前的ASPICE 4.0版本里头也继续保留了SWE.2这一个软件工程过程。

　　一、ASPICE SWE.2是什么意思

　　SWE.2是夹在软件需求和软件详细设计当中的那一层，它的任务是把SWE.1输出来的软件需求转成一份既能实现、又能集成、还能验证的软件架构。往简单里说，SWE.1讲的是“软件要做什么”，而SWE.2就接着往下讲“软件打算拆成哪些部分来做，这些部分相互之间又该怎么配合”。要是缺了SWE.2，后面的SWE.3软件详细设计、SWE.4单元验证，还有SWE.5软件集成测试，全都会少了一份清晰的凭据。

　　1、明确软件架构边界

　　SWE.2并不是画一张模块框图就算完事，它还要去说清楚软件系统里面到底有哪些主要的构成部分，哪些属于应用层，哪些属于基础软件或者是跟平台搭边的部分，又有哪些接口需要去跟系统、硬件，还有外部的软件打交道。只有这些边界都给理清楚了，后面的需求分配、接口设计，还有后续的变更管理，才不容易搅和在一块儿。

　　2、分配软件需求

　　可以依据【软件需求规格说明】到【软件架构元素】建立分配关系，确认每条关键需求都有对应的架构承载对象。

　　这里确实存在着一条实际的分配路径，所以可以用这种形式来表现。打个比方，诊断需求会分到诊断管理模块，通信需求归到通信服务模块，控制算法的需求则落在控制逻辑模块上。这样做的目的，是为了不让需求只在文档里头打转，到了后面却找不着对应的软件实现位置。

　　3、描述静态和动态架构

　　在SWE.2这一步，既要去看静态的结构，也要去看动态的行为。静态的结构，主要是用来讲清楚模块、组件、层级、接口，还有它们之间的依赖关系；动态的行为呢，则要把注意力放在任务调度、运行的先后顺序、状态怎么切换，以及数据流、控制流、异常处理这些上面。ASPICE对SWE.2的目的描述里，也着重提到了软件架构需要把静态和动态这两个方面都包纳进来，并且要跟软件需求保持住一致性。

　　二、ASPICE SWE.2架构设计输出物有哪些

　　ASPICE SWE.2的输出物，它的核心用处是要能证明软件的架构已经被定义过了、被分析过了、被分配好了，也是能够被追溯的。各家公司的文件叫法可能会不一样，有的管它叫软件架构设计说明书，有的叫Software Architecture Document，也有的把这些内容拆散放在模型、接口表、状态机图还有追溯矩阵里面。叫法虽然可以不同，但里头的内容，得能撑得起评估才行。

　　1、软件架构设计说明书

　　软件架构设计说明书，这一般是SWE.2最中心的一份输出物。它需要去说明软件是怎么样分层、模块是怎么样划分的、各个组件要担起什么职责，还有关键的接口、数据流、控制流、任务的关系，以及异常处理的办法。文档倒不是越厚就越好，重点是要让做评审的人能够一眼看明白，软件为什么要这么去拆，拆完之后，需求又是怎么被承接起来的。

　　2、软件需求分配表

　　通过【软件需求】→【架构元素】整理追溯关系，确认需求没有遗漏，也没有脱离架构单独存在。

　　这是一种很典型的追溯关系，用箭头来表示是很合适的。需求分配表常常被用来讲清楚每条软件需求是被哪一个模块、组件或者是服务给承接的，反过来也能去检查某一个架构元素它为什么会在那里。要是少了这张表，SWE.2就很容易让人觉得跟SWE.1和SWE.3是脱开来的。

　　3、接口定义和数据说明

　　接口的定义，得把模块相互之间传来传去的是什么数据、数据的类型是什么、刷新的周期是多长、异常值要怎么去处理，还有接口的调用方向是怎么样，这些都给说明白了。搁在汽车软件这一块儿看，好多问题都是因为大家对接口的理解没统一才闹出来的，比如信号的范围、初始值、无效值，还有超时处理这些地方没有拉齐，到了后面的集成测试，就免不了要翻来覆去地返工。

　　三、ASPICE SWE.2落地时容易忽略什么

　　SWE.2如果做得不好，一般倒不是因为团队一点儿架构都没有，而是架构里头的内容跟需求、代码还有测试之间，没能够连到一块儿去。好多的项目，要有框图也有框图，要有模块名也有模块名，要有接口表也有接口表，可就偏偏少了需求分配、状态的说明、异常的路径，还有分析上的证据，到头来评估的时候，还是一样会被追着问“这个架构到底怎么证明它是满足软件需求的”。

　　1、不要只交架构图

　　光靠一张架构图，它只能讲出结构的大概模样，是替代不了一套完整的架构设计的。真正能够派上用场的SWE.2输出物，还得能把模块的职责、接口的关系、数据是往哪个方向流的、状态是怎么变化的，还有异常是怎么样去处理的，这些一并都给交代明白。要是只有图，文字上的解释和追溯的关系都找不见，那开发的人和测试的人，就很容易照着各自的理解去干了。

　　2、注意和SWE.1、SWE.3衔接

　　需要把【SWE.1软件需求】、【SWE.2软件架构】和【SWE.3详细设计】放在同一条链路里检查，避免需求、架构和实现各写各的。

　　这倒不是为了去堆砌什么格式，而是因为这三者之间本来就有着上下游的关系。SWE.2接住的是SWE.1，又转过头去给SWE.3提供输入；要是中间这个地方断掉了，那后面的代码实现和测试覆盖，再想去解释就很费劲了。

　　3、保留评审和变更记录

　　架构设计这东西，并不是一次写完就搁在那儿不动了。需求变动了、平台改了、接口有了调整，还有冒出来的性能问题，都可能牵着架构要跟着变，所以项目里头要把架构评审的意见和变更的记录给保留下来。只有这样，到了后面评估的时候，才好去解释架构的调整不是随随便便做的，而是经过了分析、评审，还有受控变更的。

　　总结

　　总的说来，ASPICE SWE.2是什么意思、它的架构设计输出物又有哪些，最核心的意思可以拢成一句话：SWE.2是在把软件需求往软件架构上转化的一个过程，它的输出物要能证明软件被合理地划分了、需求被正确地分派好了、接口也给清楚定义了出来、架构是被认真分析过的，并且还能够继续撑起后面的详细设计、编码、集成和测试。在真实项目里，别只光准备一张架构图就了事，而要把软件架构设计说明书、需求分配表、接口的定义、动态行为的说明、架构的分析记录，还有评审和变更的记录，整理成一个能闭环的东西，这样才更对得上ASPICE在做评估时对SWE.2的那份关注。