ASPICE SWE.3详细设计怎么写ASPICE SWE.3详细设计和代码怎么对应，关键并不在于把架构图再来一次细化，也不是提前把代码逻辑翻译成中文的解释说明。SWE.3这个环节所关注的，是软件的详细设计还有单元的构建工作，它需要把SWE.2给出的软件架构再往下分解到软件单元这个层级，并且要使得后面的代码、单元验证以及追溯的关系全都能相互匹配得上。在ASPICE里面，SWE.3所侧重的部分有详细设计、软件单元的接口、动态的行为，以及设计的评价等等，而紧跟在它之后的SWE.4，还会接着去核实软件单元到底是不是符合详细设计的要求。

　　一、ASPICE SWE.3详细设计怎么写

　　在动手去写SWE.3的详细设计时，可不能只丢下一句“模块实现某某功能”就算了；这份设计得比架构设计更加地贴近实现，却又不能细致到跟代码一模一样的地步。比较合适的程度是，开发人员翻看完之后，能够弄清楚每个软件单元要去做什么事情，接口之间怎样传递数据，状态又会怎样改变，而测试人员同样可以拿它作为依据，去设计出单元验证的内容来。

　　1、先明确软件单元边界

　　在划定软件单元的边界时，需要顺着架构设计一路往下拆，通常可以拿功能职责、接口关系、可测试性，还有代码的组织方式这些东西来当划分的尺子。就拿一个诊断管理模块来说，在它下头还可以接着拆出故障检测单元、故障确认单元、状态存储单元，还有故障上报单元。每一个单元都得有自己清楚的职责，不能让单独一个单元把太多的逻辑全揽在身上，要不然到了后面，代码的对应关系会乱，单元测试也会跟着变得很乱。

　　2、对齐设计输入

　　结合【SWE.2软件架构】和【软件需求规格说明】，确认详细设计覆盖的功能范围、接口范围和约束条件。

　　这一步主要就是为了防止详细设计跑开了上游的约束；如果说架构里面规定了某一个组件要负责信号的校验，那到了详细设计里面，就得能够看到对应的单元是怎样去完成校验的，碰到异常又是怎么样去处理的，最终的结果又是如何给出去的。决不能在架构那边写一套，跑到详细设计这里，又按照写代码的习惯另外再写一套。

　　3、写清接口和数据

　　在详细设计当中，需要去说明软件单元彼此之间到底要传递哪些数据，是由谁来调用谁，输入和输出的类型又是什么，还有异常值准备怎样去处置。接口这部分倒也不一定全都要画上很复杂的图样，但起码也得让读的人一眼就看明白，数据到底是从哪里来的，中间经过了哪一个单元的处理，最后又是传到了哪里去。放在嵌入式软件上来看，还得多去留意周期任务、全局变量、状态变量、标定量，还有返回值这些东西，因为它们全都会直接牵动着代码的实现。

　　二、ASPICE SWE.3详细设计和代码怎么对应

　　要让详细设计和代码对得上号，不能单靠着开发人员口头上去解释，也不能只是指望着文件名长得相像。比较稳当的办法，是在设计、代码、评审，还有测试这几样东西中间，把清楚的关系给搭建起来，使得每一个软件单元都能够找得到它对应的实现，每一段关键的代码也都能倒回去找到设计上的依据。

　　1、建立单元到代码的映射

　　在【详细设计说明】中列出软件单元名称、对应源文件、函数名称、主要输入输出和实现状态。

　　比方说，详细设计里头有一个“故障确认单元”，那么代码那边就应该能被翻得到对应的.c文件、核心函数，或者是模型模块。这里并不强求一个设计单元只能去对应到单个函数，只不过当中的对应关系要能够交代得清清楚楚；要是某一个设计单元被拆成了好几个函数，那就得讲明白这些函数各自是挑着哪一部分逻辑在走，免得到了后面评审的时候，找不着实现的地方。

　　2、让代码体现设计逻辑

　　代码的实现，可不能光是把运行的结果满足就算了，它还得能让人从里头看出详细设计里的那些主要逻辑。像详细设计里面写了输入的检查、阈值的判断、计数的确认、状态的更新，还有故障的上报，那代码里头也应该能看得到这些个步骤才对，而不是把它们全搅和在一个大函数里面。要不然的话，代码倒是跑得动，可从ASPICE这个视角来看，可读性、可维护性，还有可验证性，全都会往下掉一截。

　　3、把追溯关系补完整

　　通过【追溯矩阵】记录软件需求、软件架构、详细设计、代码文件和单元测试之间的对应关系。

　　这张表倒用不着写得多么花哨，但是它得要能够回答这么几个问题：某一条软件需求，是由哪一个设计单元去做实现的；又是哪一个源文件，在那边承载着这一份实现；再去看看是哪一项单元测试，对着它做的验证；还有评审的记录，是不是已经把这条链路给覆盖全了。只要这串链路中间断掉了，那SWE.3跟SWE.4之间，就很容易冒出一块证据上的缺口来。

　　三、SWE.3落地时容易出现哪些问题

　　好多的项目，倒并不是没有详细设计，而是那份详细设计读起来就像是在补文档一样。代码那边早已经写完了，设计才回过头来倒着推出来，这么一弄，表面上看着材料是都有了，可骨子里既不能去指导开发，也撑不住验证。SWE.3要真想落得了地，重点是要让设计、代码，还有测试这几样东西，能够同步地对齐。

　　1、不要把详细设计写成代码翻译

　　详细设计并不是去对代码做一行一行的逐句解释；要是一份设计文档，只是在把if、else、for循环挨个翻成了中文，那就说明它离代码那一层已经贴得太近了。详细设计更应该去说明的是职责、接口、状态、异常处理，还有关键的那几条算法思路，至于具体的语法，大可以留给后面的代码实现再去处理。

　　2、不要忽略异常路径

　　有相当多的详细设计，只是把正常的流程描了一遍，那些异常的输入、边界上的取值、超时的情况、无效的状态，还有恢复的条件，却都没有往里面写。这样一来，代码开发的时候就容易各敲各的，搞单元测试的人也不清楚到底该去测哪些异常的分支。特别是在汽车软件这一块儿，异常的那一路常常比正常的路径还要更加影响整体的质量。

　　3、不要让评审只看格式

　　去给SWE.3做评审的时候，可不能只去查模板里头是不是全都填满了就行，还得去瞧一瞧这份设计到底是不是可实现的、可测试的、可追溯的。比如说接口是不是完整的，状态的切换是不是一个闭圈，复杂的逻辑有没有被拆解得清清爽爽，代码那边的结构又能不能承接得住设计。要是这些问题都漏掉没去检查，等后面进到了编码和单元验证的阶段，返工的事情就很容易冒出来。

　　总结

　　总的来看，ASPICE SWE.3的详细设计到底要怎么去写，详细设计又该怎样跟代码对得上，可以沿着“架构拆出单元、单元定好职责、接口交代清楚、动态行为写完整，还有代码建立起映射”这样一条思路往下推。详细设计既不能写得空空荡荡的，可也不能直接变成代码的注释；它需要正好站在架构和代码的中间位置，既能够去引导开发，又能够去撑住单元的验证。