ASPICE 消亡倒计时？

01

ASPICE 疯狂

最近 和身边的同事交流，发现 去年上的 ASPICE 项目无一例外 地都停滞了。没有什么原因，就是整车厂不想搞了。

这让我想起了快四年前，我第一次参加 ASPICE 认证的时候（ 工作思考ASPICE ）。当时的我对这个流程比较好奇，毕竟是第一次接触，只知道是一个高级版的V流程。虽然我只涉及了其中的一个很小部分，但其中繁琐的流程让我十分头痛。这种感觉只有真正做过的人，才能体会。

印象中大约是三年前， 国内似乎掀起了一场 ASPICE 热。各种 ASPICE 项目蜂拥而上，其认证机构更是赚得盆满钵满。 如果 哪个 供应商 没有 A SPICE 资质，你都不好意思跟别人打招呼。

02

ASPICE 与 V模型

ASPICE 全称 Automotive Software process improvement and capability determination ，汽车软件过程改进和能力测定。它是车载软件开发的过程标准，用于欧洲整车厂对供应商进行软件过程评估。不了解 ASPICE 的朋友可以先看看这两篇文章（ Automotive SPICE 简介 ） 以及（ Automotive SPICE和Automotive SPICE评估的那些事 ）。 可以看出 ASPICE 是在传统的汽车V模型开发流程上演化出来的 。

ASPICE overview

Why V model ?

关于这个问题，没有所谓的标准答案。我试着说说我自己的理解。对于汽车控制器软件开发而言，其主要原因是 需求变更少

传统汽车控制器由于被控对象以及工作特点都是非常确定的，所以其需求也是非常明确。例如 ABS 控制器软件就是为了防抱死而设计的，TCU 控制器软件就是控制变速箱换挡的。这就意味着在开发前，整车厂就会对该控制器需要实现的软件功能有着明确的要求，同时提供明确的需求输入文档，这也是V模型开发的第一步。

另外，客户的需求文档一般也具有连续性， 除非是那些需求 不合理的地方 ， 不然贸然的更改 就会给终端消费者造成 前后不一致的使用困扰。

ASPICE真的可以提高软件质量吗？

理论上，可能可以。能提高多少，不知道。因为除非是整车厂特意要求（付钱），否则供应商是不会主动使用 ASPICE 流程来进行开发的。

ASPICE 只是针对某一个项目的过程证书，借用这个项目可以间接证明研发部门有能力达到 AS PICE 所要求的标准。可以在每次获取新项目的时候秀一下，但并不表示每次都要按照此流程进行开发。

我个人一直对 ASPICE 的指导意义保持着怀疑的态度。因为其本身定位是 整车厂期望供应商所采取的软件开发模式 。是否有人质疑过这种方式真的能提升供应商的软件质量？是否是专门针对供应商所量身打造的？目前 也没有任何数据支持这个观点。

相同一个工程师，分别使用公司内部的流程进行开发，和 A SPICE 流程开发的 Bug 缺陷率有多大差别？不知道有没有有人统计过？ 如果没有的话，我对于其有效性就保持怀疑的态度。

别人怎么玩？

作为新入场的电动车新势力，你说它们也玩 ASPICE 吗？现在看来并没有。如果 你要 说他的软件不行，但也不是到处满地跑吗？新入场的玩家，没有传统汽车人的历史包袱，运用互联网的经验，通过不断地迭代与测试， 依旧可以保证软件质量，甚至更高 ！

80/20 软件开发流程

我个人一直以来都是对于 增加开发流程就可以提高软件质量的言论 ，持有反对态度 ！而真正适用的应该是80/20法则，即只有 20% 的关键流程，保证了 80% 的软件质量，而这些关键的流程才是我们需要重点关注的！

那剩下的20%质量就不重要了吗？并不是，但我们绝不能够把主要的精力放在这20%上面。 而是应该通过自动化工具，自动化测试等方法来保证，而这个过程是不需要让研发工程师亲力亲为的。

03

拥抱变化

当前汽车软件正在从固定的功能开发转向算力为主的超级电脑。简而言之， 控制器在未来就是一个算力工具人，内部的软件种类决定了其工作特点。

工作场景的多样性，就意味着需求的多样性。在未来，软件的开发与变更将更为频繁，这也就是 OTA 在汽车行业突然兴起的主要原因。

让我们展开脑洞，大胆假设，小心求证： 通过OTA，移动互联网 APP的开发更新模式，将有可能在汽车上实现 比如有一个软件功能包，其功能可能才完成了80%。整车厂就可以先推送给一些体验用户进行尝鲜体验，通过后台数据的不断收集，进行持续不断地迭代更新。等到最后验证完全了，再推送给所有车主，甚至还需要付费后才能体验！

现在回头来看，ASPICE 遇冷和“软件定义汽车”的兴起似乎是同时发生的。 火的时候，大家一起蜂拥 而上。到最后...我之所以认为 ASPICE 会慢慢走向没落，是因为它是繁琐的，是抗拒变化的。而在未来，变化将会成为主流趋势。 也许将来 ASPICE 会融合 敏捷 或者其他开发模式从而获得新生，但 起码不是现在。

04

不破不立

万事万物的存在都依赖着一个根基，就好比每一栋摩天大厦都无不例外地仰仗着其稳固的基石。基石就好比是数学中的公理，是不用也是无法证明的。这个基石保证了大厦的建立，但最终也会限制大厦 的高度。

对于身处行业中的我们来说，一般很难觉察到基石的存在，正所谓“不是庐山真面，只缘身在身在此山中”。 只有当我们真正跳出这个行业，才有可能真正发现基石存在。 很显然，特斯拉，互联网造车新势力的进入，给我们带来了新的思想。顺着他们的思路，看看他们的行为，我们才有机会窥探到自己的基石。

那汽车控制器软件开发的基石是什么？ 也许你也发现了，那就是V模型。 从我们的开发模式，流程文档，组织架构，岗位设立等，无一例外都是按照V模型的指导思想来建立的。

你是否有过很多创新的想法，但是被这V流程的条条框框限制而无法实施？ V模型陪伴了我们走过了20多年，它是否还能继续承载我们这座软件大楼？

毫无疑问，只有打破这个基石，我们可能才能建立新的一座崭新的大厦。 互联网造车新势力给我们传统汽车人带来了敏捷开发，但这是否就是最终的答案？ 这一切还尚未可知。

[1] 工作思考 —— 敏捷开发（1）

[2] 工作思考：不可能三角

[3] 原理性知识