作者 | 龚萌

出品 | 汽车电子与软件

概要：

本文鉴于从事汽车软件ASPICE咨询和评估过程中的经验总结，内容章节如下：

1 ASPICE之风愈吹愈烈

2 不满足ASPICE不一定代表产品质量不高

3 满足ASPICE也不一定代表产品质量高

4 ASPICE标准言简意赅，偶有难会其意

5 ASPICE并非神药，请留意副作用

一、ASPICE之风愈吹愈烈：

软件定义汽车，高级别辅助驾驶，甚至自动驾驶，促成了软件规模急剧上升，尽管IATF16949等质量标准依然是汽车行业的基调，但是在这些标准在以软件为主的开发中，还是显得颗粒度太粗，未细化到具体的工程实践要求，如需求如何分析，架构设计需要哪些实践，测试要分多少层级等等，难以起到很好的指导和规范作用。

但其并非神药，符合与不符合ASPICE要求，并不是衡量软件质量或者可靠的绝对标准，需要客观看待，理由在如下章节中阐述。

二、不满足ASPICE不一定代表产品质量不高

a) 未满足的ASPICE实践可能被事业环境因素弥补

图1展示的是产品质量与事业环境因素的关系，其中事业环境因素列举了组织文化，流程体系和人员技能三项为代表。如果说这三项构成的三角形面积的大小代表了产品质量的高低，那流程体系越是完善就越能提高产品质量，ASPICE作为组织流程体系的一部分，那开发过程中满足ASPICE实践当然为产品质量提供了保障，这是正向解读。

图 1 产品质量与事业环境因素

那反过来，开发过程不满足ASPICE要求的产品质量就没有保障吗？我想不是的，未执行的ASPICE实践可能被组织文化和人员技能等事业环境因素弥补，案例如下一章节；

b) 案例：ASPICE-问题解决管理要求为项目制定问题管理计划和执行问题趋势分析

实际上有很多公司，甚至跨国公司都有自己的问题管理过程，或者问题管理过程被某个过程定义覆盖了，但其中可能不会要求每个项目都制定问题管理计划，或者执行问题趋势分析。但是负责问题管理的项目经理的岗位要求高，且公司有中层管理者的项目推动会和高层管理委员会的项目汇报会等多重机制来监控项目问题及健康状况，同样可以确保问题可以被识别，分析管理和控制，最终得到有效解决。

所以，不满足ASPICE实践要求也不见得开发过程就不受控，产品质量就不高。

三、满足ASPICE也不一定代表产品质量高

比如，ASPICE标准定义了需求分析基本实践，但是需求中是否全面考虑了产品使用的所有场景及其需求，是否考虑了可预见的误操作？ASPICE也要求了定义测试策略，但其中的测试设计方法是否正确？……，这些都是要根据具体的产品和工程技术来判断的。

而且，有些车企对软件质量的评估也不再单独以ASPICE来评判了，需要结合自己的软件质量要求。这也说明APSICE并不是绝对的质量标准，企业应该根据自己的需求裁剪。

b) ASPICE认证评估中存在主观因素

ASPICE的评估是根据ISO/IEC330XX:2015系列标准来进行的，应该是比较规范的。而实践中，一个开发项目，不管范围大小，都不会像只有选择题的考试一样来判断绝对的对与错，那么就可能有仁者见仁智者见智的主观判断成分。比如对下面这个问题的探讨中，也听过不同ASPICE评估师给过不同意见。

在系统需求规范中，把每一条系统需求都分解成了软件、电子、机械的需求，这个实践是否构成了ASPICE评估的弱项？

更为严重的是在评审过程中可能会有利益冲突，导致评估师不能保证独立客观的立场去评估，尽管很多弱项，依然会评判为达到了某个过程能力级别。评估结果由评估师负责给出，国际评估师联盟 （INTACs）和德国汽车工业协会质量管理中心（VDA-QMC）并不直接监管评估结果。

四、ASPICE标准言简意赅，偶有难会其意

图 2 行业门槛趋势

只是ASPICE标准言简意赅，偶有难会其意，这让依靠百、八十页标准来实施的企业有点摸黑的感觉。标准写的简洁本无可厚非，理由之一是：ASPICE未详解工程逻辑，假设了实施团队有基础的工程知识；理由之二是：它要适用于整个汽车行业，不便于用特定产品举例，理由之三是：它不限定实现形式，可以根据产品特点来选择。但是这些言简意赅的理由有时又反过来增加了这种摸黑感，比如：

Ø将需求分配架构要素，要素指的是什么？

Ø先逻辑架构设计后物理架构设计，逻辑架构是必须的吗？

Ø软件资源消耗定义到哪个架构视图，哪个层级？

Ø如何把握项目生命周期模型的颗粒度？

Ø……

为了在实施ASPICE的时候不抹黑少碰壁，有如下几种方式可以考虑：

Ø多与有ASPICE评估的车企合作，但需要考虑评估结果是否影响付款，通过评估的形式来增进对ASPICE的理解；

Ø软件有分供方时，要求分供方按照ASPICE的要求来开发，甚至要求通过认证，借机审核供应商的形式去理解ASPICE的要求；

Ø参考集团公司中其他实施过ASPICE的优秀项目案例模板；

五、ASPICE并非神药，请留意副作用

以上这一段的内容只提到到了组织变更的意识问题，除此之外，还有意愿（为什么我要做？）、知识、方法、固化等一系列的变革阻力需要去考虑，当然，这些组织变革管理的内容，已经超出了ASPICE标准的范围，但是组织如果不能妥善处理好这些，则可能要承受药物副作用了，比如：

Ø项目策划不充分，工作量严重超预期；

Ø人力资源不够，项目超期；

Ø过程实践依葫芦画瓢，不思考也不能解释工程逻辑；

Ø项目团队身心疲惫，人员离职；

Ø天天救火，最终未达到预期的ASPICE要求；

Ø客户审核问题成堆；

Ø项目即使达成预期，好的实践未固化，下一个项目还是老套路；

Ø……

归根结底，ASPICE并非是药到病除的神药，良药苦口，要行之药效，还需要根据组织自己的体质研究服用方法，以免用药过量，人财两空。

如上是本人在实施多个ASPICE项目后感悟，希望能帮助大家客观理解ASIPCE ，也希望大家冷静对待，以免踩坑。

篇幅有限，若有其他疑问，欢迎通过如下方式交流，即使本人阅历有限，Methodpark, KMC, KVA等公司还有其他实践者可能可以解答您的疑问，欢迎联系我们，共同学习，共同进步！