在聊ASPICE MAN.3项目跟踪怎么去开展，还有偏差措施又要怎样去验证的时候，重点并不只是看一看项目有没有照着计划往前面走，还得去瞧清楚实际的状况跟计划之间到底有没有出现偏离。项目管理如果只停在一张进度表上，好多问题是会被盖住的，比方说人员跟资源不太够、缺陷关得慢慢吞吞、供应商那边的交付拖了时间，又或者测试环境老半天都没准备好。MAN.3更加关心的是，项目是不是在被持续地管着，一旦发现了偏差，后面跟上的措施是不是真的起到了作用。

在聊ASPICE SUP.1的配置管理怎么审计、审计出来的问题又该怎么关闭时，要紧的不是单独去查有没有版本号这回事，也不只是翻翻配置库，看文件有没有全塞进去。SUP.1真正操心的地方，是那些工作产品能不能被清楚地认出来并管住，发生了变更之后能不能顺着线索往回追，还有项目在往前跑的过程中，能不能随时都闹明白“当前到底用的哪个版本、是谁在什么时间改的、因为啥改的、这次改动又连累到了哪些别的东西”。所以，给配置管理做审计，就得围着配置项、基线、变更记录，还有最终交付物跟清单能不能对得上号来展开；而问题的关闭，也必须靠着实打实的证据串成一个闭环，不能只丢一句“已整改”就完事。

在软件开发过程中，ASPICE SWE.4的单元验证及其证据留存，往往容易被做成表面功夫，不少项目将单元验证简单视作开发人员随手一测，或是仅保留几张工具截图，但从ASPICE的视角出发，SWE.4更强调的是软件单元是否依据详细设计进行了验证，测试方法是否恰当，结果能否追溯，以及发现的问题是否形成了一个闭环，所以单元验证不能只盯着执行了没有，还要去关注验证的对象、内容、结果，还有证据链够不够完整。

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

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

在功能安全的前期工作里，Item定义该怎么写，Item边界又该怎么去划分，这一步常常容易让人卡住。Item定义并不是给系统写一段普普通通的介绍，也不是把控制器、传感器、执行器都列成一张清单就算完事儿了；它真正要去说明的，是当前要分析的那个车辆功能到底是什么，这个功能需要依赖哪些对象，以及边界内外怎样互相交换信息。

很多项目是一直到版本快要交付之前，才突然发现一个问题：代码明明已经封版了，测试也跑完了一轮，可是需求的追踪、缺陷的关闭、风险的说明、配置的基线，还有评审的记录，这几样东西并没有完全对齐，发布评审要解决的，并不是简单判断一下“这个东西能不能打包发出去”，它真正要确认的，是这个版本是不是真的具备了可以作为交付依据的条件，后面一旦遇到客户审核或者过程评估，项目组能不能把这一切都讲得清清楚楚。

很多项目一直到准备ASPICE评估的时候，才发现写下来的风险都太笼统了，像“进度延期”“需求变更”“测试不足”这一类的话，单从字面上看，倒也不能说它们就写错了，可真到了评审的时候，靠着这些描述，是很难继续往下追问责任在谁、影响有多大、又该用什么样的措施去应对的，识别风险这个动作，需要紧紧地贴着过程活动去走，而针对风险定出来的那些措施，也得能够拿得出证据来，证明它们确实是有效的。

在汽车软件外包、嵌入式开发还有系统集成这些项目里，评估一个供应商的ASPICE能力，还有后续怎么去跟踪它的表现，不能只是看供应商有没有证书、是不是做过类似的项目，真正会影响到最后交付的，是供应商能不能把需求、设计、编码、测试、配置管理、问题管理，还有变更管理这些过程，稳稳当当地跑起来，在评估的阶段把对方能力的边界看清楚，在跟踪的阶段盯住每一个问题是不是都闭环了，这样到了项目后期，才不容易出现一种情况，就是交付的东西虽然都齐了，可是背后的证据链却断了。

在软件开发评审的时候，有两个问题经常是连在一块儿出现的，一个是怎么去策划ASPICE的集成测试，另一个是在测试做完之后，那些用来证明测试确实被执行了、而且结果有效的证据，又要怎么去保存下来，集成测试这件事，并不是简单地把一堆模块拼到一起去跑上一遍，看见没报错就算结束了，它需要我们能够说清楚，模块之间到底应该按照一个什么样的顺序去集成、它们之间的接口关系是怎样的、测试的依据又是什么、测试是在什么环境里跑的，还有最后出来的结果，有没有形成一个完整的闭环，而保存证据，也不是随随便便地把截下来的图往文件夹里一塞就行了的，它的目的是要让后面来做评审的人，能够顺着需求、设计、测试用例、执行时候的记录，还有对缺陷的处理，这一整条线，一路顺畅地查下去。