再谈 ASPICE（再谈记忆）

以下文章来源于汽车ECU设计 ，作者氨气

汽车ECU设计.

一个菜鸟程序猿的成长之路。

符合流程不难，难在如何证明自己符合流程。做好人不难，难在如何证明自己是一个好人。花一份精力做良民，花十分精力做良民证，这是不合理，又无可奈何的事。

上次的《ASPICE 消亡倒计时》在发布后得到了大家的充分讨论，包括我自己在内也收获良多。汽车行业就是缺乏这样的线上讨论，思想只有经过充分的交流才能得到提升。

如何在成本 周期 控制允许的前提下，最大限度地提高软件质量一直都是所有行业的老大难问题。至于最后 ASPICE 会不会被淘汰，就等待时间来慢慢检验吧。

01

讨论

实践是检验真理的唯一标准

关于 ASPICE 大家的评论主要分为两个方面：

• 做过 ASPICE 项目的朋友，大多数对其持有怀疑和否认的态度
• 没有搞过 ASPICE 的项目，大多表示支持

如果一个流程，大部分做的人都说繁琐，那起码有其不科学或者说不符合现实的地方。到最终实施起来，做的人也不会去好好的执行，只是疲于应付流程而流程罢了。

技术与流程就好比生产力和生产关系

如果能把技术和流程比作生产力与生产关系的话，就比较好理解了。生产力决定生产关系，而不是生产关系决定生产力！软件开发技术的变革必然会推动新的软件开发流程，换言之，如果在这种流程下，技术能充分发挥其作用和效率的话，那就是一个好的流程。

手拿铁锤的人，看什么都像钉子

举一个汽车软件的例子，AUTOSAR 这个在传统汽车嵌入式软件中基本绕不开的行业标准，但特斯拉自己却没有加入这个标准组织。因为它的目标是像苹果一样打造一个属于自己的生态王国，它选择自己来设计软件架构。在未来只有别人来适配我的标准，而不是让我被别人牵着鼻子走。

同理，只是单纯的认为 ASPICE 可以提高软件质量，就去追捧它。有种只见树木，不见森林的感觉。怀着拒绝 ASPICE 就是拒绝质量的观点未免有点太狭隘了，而事实上能提高软件质量的流程有很多种，甚至比 ASPICE 做得更好。

ASPICE 只是因为出身在汽车行业而被熟知，其余的只是因为我们不知道罢了。再往深处去看，一个公司选择哪种开发模式是更多的是由于其内部基因所决定的。

02

观点

未来 ECU 将沦为算力工具？

很遗憾，仅从供应商的角度上来说：是的。目前来说有几个现象支持这个观点：

整车厂主导软件开发 目前越来越多的整车厂开始选择自己设计应用层功能，而不使用 Tier1 的软件。更有甚者，由于 Vector 等第三方 Autosar 底层软件的出现，整车厂向供应商定制化硬件需求，由自己来完成 应用层 底层 的创建工作。

自动驾驶控制器 虽然大家的自动驾驶汽车还没有正经上路，但是自动驾驶控制器却呈现百家争鸣的状态。但除了秀算力肌肉以外，就没有其他可以展示的了，大家目前好像还不知道应该拿这个肌肉干什么。不过参考计算机的发展进程来看，算力多多益善，因为最后总会用完的！

与手机类比 如果把控制器的未来看作手机或者电脑的话，那未来应用层的开发很可能像是 APP 那样百家争鸣的状态。除了传统供应商以外，主机厂，互联网公司，通信服务运营，甚至个人开发者在未来都有可能入场分一杯羹。如果你能看到这一点，就会理解为什么华为要造车，也会理解为什么吉利要卖手机和发射卫星？那或许特斯拉在将来也要造手机了？

毫无疑问，由于入场的新玩家增多，供应商在未来整体软件的开发占比肯定是会逐步减少。但考虑整个蛋糕在变大，所以软件工程师的人数也会不断增多！

OTA 刷新 —— 拿消费者当小白鼠 ？

框架效应（Framing effect）是指人们对一个客观上相同问题的不同描述导致了不同的决策判断。

关于OTA，有一个很有意思的地方，如果说让“消费者当小白鼠”那必然会遭到消费者的唾弃，但如果改为给消费者提供“免费终身的软件升级服务”，那效果就完全不一样了。

降低软件更新成本

OTA 可以大幅度降低软件更新的成本，这是一个巨大的优势。但如果认为有了 OTA 的话，未来的软件就会有更多的 bug 。这点我不能苟同，相反地我认为软件的 bug 可能会更少，或者说造成的危害和影响更小。

因为 OTA 只能更新软件，而并不能影响软件的质量，之前该有的测试一个也少不了，并不会转嫁到消费者，而具体到软件质量则是由一个很复杂的系统工程所决定的。

相反地，由于更新成本的降低，人们更愿意去发布新软件去修复以前的小bug，更多的验证也让软件的质量得到提高。

不成熟软件的更新

首先要弄清楚 不成熟 ≠ 不测试 ≠ bug 个人认为不成熟意味着不完美，表明还有开发进步的空间，亦或者还没有经过大规模验证，这些都可以称为不成熟。

在买车的时候，有经验的人可能会告诉你：“刚刚上市的新车，质量和工艺还不够成熟 稳定，让子弹飞一会，等个两年再买。”产线工艺这类慢周期的迭代善且如此，何况软件乎？

一项技术，一个功能，在使用的过程中必然会出现从不成熟到逐步到成熟的过程。这是事物发展的客观过程，也是行业现状，而 OTA 只是加速这一切的发生罢了。

“大”规模“测试”的一种手段

这个的 “大” 是带引号的，即可以根据需求来选取测试范围，甚至实现精准测试。同样，这里“测试”也是带引号的，我们不能把它只限于软件功能级别的测试，而应该延伸到互联网产品经理的测试。根据测试结果，进行统计学上的消费者行为分析。

• 这项功能消费者是否喜欢？
• 这项功能的使用频率是多少？
• 是都应该对此项功能进行收费？
• 在什么工况下消费者更愿意使用这项功能？

A/B测试就是为同一个目标制定两个版本，这两个版本只有某个方面不一样，其他方面保持一致。让一部分用户使用A版本（实验组），另一部分用户使用 B版本（对照组）。

敏捷开发 ？

如果大家都采取一样策略那只能获得平均收益，无法得到超额的回报，但总会有人率先进行改革尝试。就目前行业的发展方向来看，敏捷开发是当前所有候选人中最有潜力的。已经有越来越多公司开始尝试“敏捷转型”。

首先是互联网企业：

• Tesla、Apple、Google应用敏捷基本是不用去考证了，其中Apple在2012年组织架构已经是“敏捷”的, Google也在2006年就成功将”敏捷”引入Adwords的开发中，并发表相关论文，被IEEE收录

然后是汽车零部件巨头：

• 至少是2020年起，Aptiv已经在全球范围内全面推广”敏捷”，且聘请咨询公司专门定制了AutoScrum的敏捷框架，在公司官网也可以看到其已经在"主动安全"、"自动驾驶"、"车辆互联"等领域应用敏捷方法了
• Bosch在2015年宣布开始转型为敏捷组织, 管理层率先使用”敏捷”的方式开始工作
• Continental在2020年也宣布全面转向敏捷的方法与文化，其VNI部门率先开始全球试点

整车厂也不例外：

• 奔驰已经将”敏捷(Agile)的组织文化”写入公司战略,并且其子公司Mbition也开始用敏捷的方式生产整车，并要求其供应商也使用敏捷的方式。
• 沃尔沃自2017年起，全球整车研发开始转向敏捷开发。并从2020年开始，使用完全敏捷的方式打造新的量产车型。
• 宝马的智能座舱和IT部门也是使用敏捷方式，其中IT部门在2019年实现100%敏捷

敏捷宣言

03

精彩评论

Christiana Guo郭家春

ASPICE并不等于V model。在ASPICE中对于车载软件中的方方面面都进行了要求，比如合同管理如何做，比如项目管理如何做，比如供应商管理如何做，比如支持过程如何做。而V model仅仅是在Engineer这块的一个体现，因为车载软件的开发也要和汽车的研发过程相配套，所以我更愿意说ASPICE选择了V model。V model是软件开发的基础，实际上它体现了从需求到交付的环节，以及一般情况下这些环节的步骤，无论曾经盛行的Waterfall还是如今流行的敏捷，它们的基础是V model的思路，只是在形式上是完全沿用，还是将实施和测试融合以加速产品迭代进行的灵活的选择，从而衍生出各种新的模型。我总觉得和ASPICE对应的应该是CMMI，它们都是用来评估过程成熟度的。

另外关于ASPICE是否能提高软件质量？我的理解是，提高软件质量的不在于ASPICE模型本身。提高软件质量的因素有很多，比如适应产品的开发流程，有效的项目管理，团队间的合作，有效的工具链，等等一系列因素。ASPICE的出发点是为了定义更好的规则来要求产品的质量，因此也有0-5级的定义。当然，更高级别就有更高的成本要求。成本和质量总是要平衡的。

杜小杜

觉得扯淡根本原因不就是很多组织做不到认真的完成工程活动，能少测就少测，能不测就不测。项目中投入更多的人力按标准每一步都认真做了难道真的不能提高项目质量？如果你的工程过程都认真做了，你可以说管理流程少投入点时间人力。真实情况是没有这么自觉的人和组织，为了保证工程过程活动按质量完成，投入了更多人力在管理活动上文档编制上，这部分可以让自动化解决。

Sabercon

说白了还是没搞清楚为什么有流程，流程的出现就是因为以前的开发人员踩过这些坑，为了避免后面的人重复踩坑才总结出来的流程。当然流程肯定是会越来越冗余越来越复杂的，结合自己组织的实际情况灵活改进流程才是一流团队的核心竞争力。很多新势力完全无视流程xjb搞的结果就是把坑全部踩一遍，然后建立自己的流程。

郭超GuoChao

ASPICE是肯定能保证软件质量的，但是国内比较难找到好的设计工程师，一般都是一个人既写需求，又写设计，然后是自己去实施，最后还自己测试！当然ASPICE也不止是提高软件质量，也能够留下开发过程的记录，如果没有这些文档，员工离职后你只能看到一堆代码，却不知为什么这样设计！

GUO

ASPICE是作为项目的一个指导性流程，并没有强制要求需要怎么做。个人感觉ASPICE不会消亡。

1. ASPICE并不是真对于变更，它讲述的是需要从客户需求到产品实现的指导性流程。

2.根据ASPICE开发与补洞式的开发模式各有优缺点，前者可以规避重复返工情况，后者可以敏捷的响应客户，各有优缺点。

3.汽车开发是基于硬件平台的，每个项目都会持续ABCD样，而且验证必须是充分的，不然会影响客户人身安全。传统互联网的开发模式导入到汽车并不一定适用。

张臻庆-Arvin

老实讲我有些怀疑你的行业经验是否真正有做过，主机厂在审核中发现，恰恰是号称做的做得还不够才导致的没有体现质量，目前我们的汽车行业恰恰是缺乏德国企业的稳扎稳打浮躁一片，沉下心来好好做产品，流程和规范才是基石，才可以有真正强大的理由！我们应该担心的是为了ASPICE而ASPICE的风气！从业者更应该在此基础上深耕对软件质量的提升！

Ricky

ASPICE的本质是，让三流的人，能够开发出二流的产品。如果你有二流的人甚至一流的人，随便你怎么搞。流程和标准都不是为个人服务的。他们是一流的人才总结制定出来，并且提供一些工具，让三流的人才来操作，然后能够产出二流的产品。这样就能降低对人才的要求，提供更多的就业岗位(三流），扩大公司规模。同时，开展更多的业务(一流二流人才)。

周兵

多少企业为了通过ASPICE审核，在补资料，这样的ASPICE是没有意义的！

William

频繁OTA，谁对安全负责，法制应该会也会越来越健全。安全是车载和互联网最大的区别，出事故后总得要有合理章法来追溯。时代在进步，效率和规范中找平衡点。

mingsen

软件开发的质量跟遵循什么流程无关，如果对外宣称我们遵循ASPICE流程，但是实际上都是产品开发完了再去补流程性文件，这不是ASPICE。在合适的阶段选择合适的方式，可能更容易抓住机会，获得发展。如果一个企业正在快速发展，攻城略地的时候，他可能会崇尚一种高效率，高可操作性的开发方式。因为ASPICE会显得比较死板。但是当一个企业发展到一定程度，客户资源趋于稳定，产品组件比较健全，那么这时候ASPICE的优势才会全面凸显。

水轻言@汽车软件质量

从文章内容来看，主要观点是：感觉不出ASPICE的执行能让软件质量有明显提升，而它那么重，与敏捷相悖，推行价值不大。

作者应该是在主机厂做开发或测试之类的岗位，这个角色有两个视角上的局限：1. 主机厂的软件开发经验相较于大牌供应商很浅，特别是针对功能安全类控制器（娱乐车机类相对可以乱搞搞，大不了黑屏，不至于车毁人亡），主机厂的ASPICE不代表行业水平；2. 开发测试角度对整个业务的理解很局限，并不是没测出bug，或者领导试驾和售后没发现突出问题，就代表软件是好的，安全、成本、法规、人员等均是要考虑的。

在当今敏捷盛行的环境下，反感ASPICE那一套笨重的体系几乎是本能，软件不同于机械，机械看得见摸得着，百年经验下，质量已经内化到整个产业链里了，DV、PV及标准化作业足够保证其质量，但软件不同，看不见摸不着，没有原材料，没有模具，人的问题、文档的问题恰恰是导致其质量问题的主要原因，ASPICE某种程度其实是一套管理体系，是一种分析工具，它既不陈旧也不新鲜，当你的人没法做到足够有能力、有责任心，软件内在问题几乎必然，ASPICE也允许裁剪允许敏捷。

无论如何，利用ASPICE打好地基，都是必要的，而后去做敏捷也好，OTA也罢，而不是急功近利，感觉繁琐，就认为过时。

SHG

Autosar也是轰轰烈烈，过段时间估计也不搞了，只有vector etas kpit赚的盆满钵满。

简之道

建议了解一下软件工程的历史（@ARVOINSIGHT价值洞察或者@爱索咨询），参阅中国2021软件质量报告，或许，你会发现ASPICE的更多优点，毕竟ASPICE的基础ISO/IEC 15504 不是小作坊的出品。

1. ASPICE本身确实存在某些缺点，例如厚重的文档导向。但是，不可否认，他的很多Base Practice是迄今为止最好的软件工程实践方法。

2. 文中提到ECU未来是算力工具人 – 这是对汽车控制器的极度误解。新势力造车用到的各种ESC，AEB等等，还是来自于传统汽车厂商，如博世等。控制器的强项是控制而不是算力。

3. 汽车软件相当复杂，不要仅仅把IVI软件或者智能驾舱软件，甚至云端平台，APP软件，以偏概全为汽车软件。

4. OTA的误读 – 如果是底盘控制系统软件，80% 功能完成，就上市销售汽车，不知哪种消费者敢购买这种车？

Jerry

ASPICE的底层逻辑是软件工程理论，是方法论而不是要你死搬硬套，开发过程中遵循开发的基本原则，理论、原则和方法论什么时候都不会过时。

丹溪

ASPICE和AUTOSAR认证都是欧美老牌发达国家的一种利益输送腐败策略，汽车行业的累赘。不能没有流程，不能没有标准，但不能为了流程和标准搞得比原始需求复杂数十倍，最后掩盖了第一性需求。AUTOSAR接口标准显然还不如CMSIS精炼。

arkrise

玩消费电子和玩车规电子的思维区别，不是什么都要颠覆才好玩，要拥抱变化，也要敬畏之心。