在软件过程改进项目里，有两个问题是经常碰到的，一个是ASPICE的软件架构到底要怎么去评审，另一个是评审中发现的那些架构问题，又要怎样才能真正地闭环掉，如果在做软件架构评审的时候，大家的目光只是停留在图是不是画得足够整齐，就很容易把接口、数据流、资源的分配、异常处理，还有安全的机制这些非常关键的内容给漏过去；而问题的闭环呢，要是仅仅停留在把表格里的状态给更新一下，到了后面，去给系统需求、软件需求、软件详细设计这些环节做追溯的时候，也会变得怎么也说不清楚，比较稳当的一种做法，是把对架构的评审，当成一次可以被追溯的技术检查来做，并且把发现的每一个问题，都落实到具体要负责的人、要修改的条目、用来验证的证据，还有最终关闭它的结论上面去。

　　一、ASPICE软件架构怎么评审

　　在对ASPICE的软件架构进行评审的时候，我们首先要去看一看，这个架构是不是能够撑得起软件的需求，然后再去看它，能不能去指导后面要做的详细设计、编码，还有测试的工作，在评审的过程当中，不要只是在底下听架构的负责人去讲他的思路，而是要把需求、接口、模块划分的情况，还有测试的依据，都拿出来一起对照着看。

　　1、先去检查一下需求是不是被完整地分配下去了

　　我们可以把软件的需求，一条一条地映射到架构里的各个组件上面去，然后去确认一下，每一个功能、诊断、安全、通信、存储，还有时序上面的要求，是不是都已经有了承接它的模块，对于那些没有被分配出去的需求，就要把它们给标记出来，不能一直留到了编码的阶段，再靠着个人的经验去临时往里面补。

　　2、接着去检查模块之间的边界是不是足够清楚

　　每一个软件的组件，都需要去说明它从外部接收了什么、向外面输出了什么、自己内部的职责是什么、它依赖了哪些别的东西，还有它是在什么样的条件下开始运行的，一个比较常见的问题是，一个模块自己揽下了太多本该属于别人的活，或者是好几个模块之间互相调用的层次太深，结果到了后面，只要动其中的一个接口，就会牵连出一大片的地方。

　　3、去检查接口和数据流的情况

　　对接口的评审，需要去看信号是从哪里来的、数据是什么类型的、刷新的周期是多久、有效值的范围划在了哪里、出了错返回的是什么东西，还有超时了要怎么去处理，在数据流的图上能够跑得通，并不代表到了真正实现的时候它也会很稳定，尤其是那些跨了任务、跨了内核、跨了不同的通信协议栈传递的数据，更要重点去看它们的同步机制，还有异常情况下要走的分支路径。

　　4、去检查资源以及在运行时的各种约束

　　架构里面，需要去讲清楚任务的周期是多少、优先级是怎么排的、存储空间占用了多少、初始化的顺序是什么，还有那些关键运行的路径是哪些，在嵌入式的软件里面，很多冒出来的问题，其实并不是功能的逻辑本身写错了，而是周期预留得不够、缓存处理的方式不得当、任务被抢占之后，状态没能恢复到一致。

　　5、去检查它是不是方便做测试

　　在做架构评审的时候，还要去关心一下，后面的测试打算怎么去做，每一个关键的组件，是不是都能够被单独地拿出来验证，它的接口是不是方便去打桩，那些异常的路径，是不是都有了触发它的条件，还有设计的测试用例，能不能把安全机制和边界条件都覆盖到，这些问题，都需要在评审的这个阶段，就提前去确认好。

　　二、ASPICE软件架构问题怎么闭环

　　要让软件架构的问题实现闭环，关键的一点，就是要把一个问题，从“被发现了”这个起点，一路推进到“修改完之后可以被验证”这个终点，用来闭环的记录，不能只是简单地写上“已经整改了”就完了，要能够从中看出来，这个问题是从哪来的、到底改了些什么东西、影响的范围有多大，还有验证下来是个什么结果。

　　1、先给发现的问题分一下类

　　评审中发现的问题，是可以分成需求没有被分配、接口讲得不清楚、组件之间的职责有重叠、异常处理缺失了、时序上存在风险、资源上也有风险，还有追溯关系缺失等等这些类型的，分完类了以后，项目组就能判断出来，哪些问题是会影响到整个架构基线的，而哪些问题，只不过是文档上的表达还需要再去补充一下而已。

　　2、把问题发生的地方描述清楚

　　对于问题的描述，要具体到被评审的那个对象，还有它所在的位置上，比如，说一句“DiagMgr这个组件，没有去说明DTC清除失败之后的返回路径”，就要比单单说一句“诊断模块描述不完整”，要来得更加容易处理，对一个问题的描述越是模糊，负责改的那个人在后面就越容易把方向给改偏掉。

　　3、把整改的动作给明确下来

　　整改的动作，是要写成那种可以具体去执行的内容，比方说，去补充接口的说明、把组件的职责给拆分一下、增加一个异常的状态、把时序图更新一遍、补上缺失的需求追溯，还有同步去修改测试的设计，不要只是丢下“完善文档”、“继续优化”这种话，像这样的内容，是很难拿来当作关闭问题的依据的。

　　4、去做一下影响的分析

　　对架构所做的修改，是有可能会影响到后续的详细设计、代码的接口、测试的用例，还有配置的文件的，在把一个问题关闭掉之前，需要去确认一下，相关联的那些文档，是不是也都已经同步地被更新过了，不然的话，就会出现一种情况，就是架构看着是改好了，可后面要交付的那些东西，却还是在沿用着老一套的设计。

　　5、要用证据来把问题给关闭掉

　　用来关闭问题的证据，可以是更新完之后的那份架构说明、评审的记录、追溯的矩阵、接口的表、时序图、变更的记录，还有测试设计更新之后的截图等等，这些证据，是要能够跟原来发现的那个问题对应得上的，不能随随便便拿一份开会的纪要，就直接把一个问题给关掉了。

　　三、ASPICE软件架构评审记录怎么留痕

　　在ASPICE的项目里面，去保留评审的记录，目的并不是为了堆砌一大堆的文件，而是为了要去证明，架构的那些活动是真实发生过的，风险是曾经被识别出来过的，还有问题，也是被认真地处理过的，只要记录留得足够清楚，到了后面去做过程审核和客户评审的时候，就会给我们省下很多解释的功夫。

　　1、把评审的输入给保留下来

　　用来做评审的输入，至少应该要包括软件的需求、架构的说明、组件的图、接口的表、数据流、时序的说明，还有上一轮评审遗留下来的问题清单，这些输入文件的版本，是需要被固定下来的，不能等到评审都做完了以后，才发现原来大家看的，根本就不是同一版的东西。

　　2、把评审的结论给保留下来

　　每一次的评审，都要把结论给记录下来，是直接通过了，是带着一些问题勉强通过，还是需要改完之后再重新来评一次，结论不要写得太过于空泛，要去说明，哪些内容已经是被认可了的，又有哪些内容，在通过的时候还是带着一些前提条件的。

　　3、把问题清单给保留下来

　　问题清单里面，建议要把编号、它是从哪来的、严重的程度、由谁来负责、计划在什么时候完成、具体要做什么样的整改动作、用什么方式去验证，还有最后是谁关闭它的，这些信息都给包含进去，这样做了以后，每一个问题，就都能从它被发现的那个时刻，一路追到它最终被关闭掉，而不会在中途就停在了口头上的沟通里面。

　　4、把版本的变化给保留下来

　　架构的文件，在每一次被修改了之后，我们都要能够看得出来，到底是改了哪一个地方、又是因为什么原因去改它的，还有，它对应的是评审里发现的哪一个问题，把版本的记录和问题的编号关联起来以后，后面再去查看基线发生了哪些变化的时候，就不需要去翻一堆的聊天记录了。

　　总结

　　总地来说，ASPICE软件架构要怎么去评审，它的重点，是紧紧地围绕着需求是不是都分配下去了、组件的职责是不是清楚、接口的数据流有没有问题、运行的约束条件是什么，还有它是不是方便做测试，这几个方面来开展检查；而架构问题又要怎么去闭环，它的重点，则是问题的描述要足够具体、整改的动作要足够明确、影响的分析要做得完整，还有用来关闭的证据要足够可靠，只要把架构的评审给做扎实了，到了后面，详细设计、编码、测试，还有追溯这些环节，才不会各走各的路，在项目审核的时候，也更容易把那些技术上的判断，给讲得清清楚楚。