ASPICE

要弄清楚ASPICE SYS.3的系统架构到底应该怎么去设计，还有SYS.3的架构接口又要怎么去验证，这里头的核心，并不是画一张系统的框图出来就算完事了，而是要把系统的需求，给分配到那些确实能做出来的系统元素上面去，把元素和元素之间，还有系统跟外部环境之间的那些接口，都给它定得明明白白的，然后再去证明，这个架构跟需求、跟设计上的那些约束，还有跟它相关的那些工程活动，是能够对得上的。Automotive SPICE 4.0这个版本，是进一步地强调了架构的一致性、设计的理由，还有SYS.3跟需求、硬件、软件，以及系统分析这些活动之间，要怎么去衔接好。

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

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

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

做ASPICE时，最容易出现的偏差，不是团队不知道要补流程，而是流程写了一套、项目干了一套、模板又是另外一套。到评估时，大家会发现问题并不只是“资料不全”，而是过程没有真正落到组织日常执行里。VDA QMC和Automotive SPICE的公开资料里已经把这条逻辑说得很清楚，ASPICE本身既有过程参考模型，也有过程评估模型；评估时看的不只是过程名字，还包括base practices和information items，而过程改进过程组本来就是用来定义、部署和改进组织过程的。

ASPICE SYS.2系统需求分析应当如何开展，以及SYS.2的需求质量应当如何检查，其重点并不是把客户需求换成另一种表述写进系统需求文档，而是要形成一套经过分析、结构清晰、可以验证，并且与利益相关方需求保持一致的完整系统需求。除了功能需求之外，还需要覆盖性能、接口、运行环境、安全、诊断以及各类约束条件，同时要对技术可行性、需求之间的依赖关系以及系统上下文所带来的影响进行分析。

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

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

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

在项目进行的过程中，如果只是靠大家在口头上去同步，那么对ASPICE的需求变更进行管理，还有为它留下相应的痕迹，这件事在后期评审的时候，是站不住脚的，需求一旦发生了变动，跟在它后面的系统设计、软件设计、测试用例、验证的结果，还有那些要交付的文件，全部都会被牵动起来；如果我们只是在开会的时候，随口说了一句“这个地方改一下”，那么到了后面做评审的时候，就很难去解释清楚，当时到底是为什么要改、这个改动经过了谁的批准、它影响到了哪些地方、以及改完之后有没有被重新验证过，ASPICE这套东西，它所关注的，就是过程是可以被追溯的，还有变更一定是处于受控状态的，所以，对需求变更的管理，就是要把它的来源、影响、决策、实施，还有验证，这五个环节给串到一条线上。

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

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

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

ASPICE等级评估不过，通常不是某一份文档写得不够漂亮，而是过程执行和证据留存没有对齐评估口径，导致同一个薄弱点在多个过程域重复出现。处理方式要先把不符合项拆成可行动的任务，再把责任人、证据、复查节奏锁死，最后用一次内部复评把风险提前消化掉。

在ASPICE语境里，验证做得好不好，不看你写了多少用例，而看你能不能拿出一条可追溯、可复核的证据链：从需求到验证措施，再到结果与问题闭环。很多团队觉得验证很“忙”却仍被指出不充分，往往是把验证和确认混在一起做，目标不清、对象不清、结果也就不好解释。

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

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

很多人第一次接触ASPICE，会把它理解成一张审核清单，或者把它当成汽车行业里的“软件开发流程模板”。这两个理解都不算准。更准确的说法是，ASPICE也就是Automotive SPICE，是基于ISO/IEC 330xx体系建立起来的汽车领域过程评估模型，它的核心用途是评估过程能力，而不是直接规定产品功能怎么做。VDA QMC公开说明里也写得很明确，当前通用的基础模型是Automotive SPICE 4.0，发布时间是2023年12月；后续还有配套的Guideline用来帮助统一理解和评估口径。

复评的难点往往不在再讲一遍流程，而在于上一次评估留下的缺口有没有被真正关闭，证据是不是能一眼看出版本、责任人、评审结论与追踪闭环。准备得当的复评，节奏应该是先把差距项逐条收敛到可验证的改动，再把证据按流程域打包成可抽样的链路，最后用一次内部模拟把口径对齐到能被评审员复核的程度。

对标ASPICE时，很多团队不是能力不足，而是对标口径不统一：同一份项目计划、同一套交付物，在不同人眼里对应不同流程与证据，评审时就会出现对不上、补不齐、解释不清。建议你先把对标对象锁定到ASPICE的PAM与PRM版本，再把项目实际做法映射到Base Practices与Information Items，最后用一份可复用的裁剪规则把适用范围与取舍理由写成可审计的记录。Automotive SPICE v4.0把PRM与PAM合并在同一套模型里，并以信息项作为证据表达的核心载体。