汽车软件开发标准,将走向何方?

 作者:罗宇超

汽车行业的软件开发标准,最著名的应该是V模型。以V模型为代表的有ASPICE、 ISO 26262 和 ISO/SAE 21434。今天我们主要以ASPICE为基础,探讨V模型在当前汽车软件变革时代的特点。

传统的V模型标准在当前这个阶段,有点使不上劲儿

这个要怎么理解呢?首先我们要明确ASPICE的一个特点。ASPICE标准采用的是一种“命题提纲”式的写法。十几年了,还在使用,并且我们一直没有听说,有什么大的错误,因为写得足够宽泛。

我们举几个例子。在 ASPICE 的供应商监控部分,他写了 5 条BP,分别是:

汽车软件开发标准,将走向何方?_第1张图片

第一个BP是,要和供应商之间达成并且维护一个联合开发的措施或接口,使得信息可以进行交换(至于联合的过程,或者接口应该是什么样的,在ASPICE 里面并没有进行描述)。

第二个 BP 是,交换所有经过双方同意的信息。

第三个BP是,和供应商一起评审技术开发过程。

第四个 BP 是,评审供应商的进度。

第五个 BP 是。对偏差有所行动。

可以看到,这些BP,实际上是一种非常宽泛的行为描述。至于这个行为应该怎么做,在标准里面是没有体现的。

所以ASPICE的标准,有非常大的灵活度去进行解读。这也是为什么,在十几年的过程中,它一直没有什么大的错误的原因。它所说的这些过程,其实是一个正常的产品开发或者项目管理的通用过程。但是在当前这个汽车软件变革的阶段,我们需要的是,标准告诉我们怎么做,而不再是给我们一个命题作文

从传统汽车向智能网联汽车转型的时代,所有人对这种新模式,都是处在一个探索的过程。这种探索既包括软件供应商,还有主机厂。如果ASPICE真是一剂神药,那标准的制订方之一,德国大众的新车,就不至于在停车场趴窝几个月了。

所以,这就是我的结论:传统的V模型开发标准,在当前这个阶段使不上劲儿,单纯的命题作文,在这个阶段不奏效,还需要实际的解题方法。

在当前这个阶段,越来越多的主机厂和新势力,采取了另外一种开发模式,敏捷开发。

敏捷开发尚未形成一个标准,而只是一些思想、工具和实践。敏捷开发,更多的好像是一个非常优秀的“考生”,写的一份备考指南,里面讲到了很多方法。这个考生上来就说:你不要想着一次就把事情做对、做完(因为事情太复杂了),你先去做就好了,做出一个原型,通过快速验证,你很快就能发现其中的问题,再去改,保证你的每一次,都比上次做得好,而且你的每一次,都是当前这个阶段最想要的。然后他开始告诉你,这个过程中,你的武器库里面有多少武器可以使用,比如敏捷看板、需求优先级的排序、敏捷报表、功能回顾会、每日站会等等。正是由于这位“考生”写作的出发点,导致了很多争议。因为我们知道,同样一份考卷,同样一个应用题,不同的人去做,可以采用不同的方法,并且大家都能够做对。这就像,市面上有黄冈老师的答题技巧,也有人大附中的答题技巧,但是高考出题提纲只有一份。

敏捷开发这套思想的推动者,最开始并没有太大野心。他们想做的只是告诉程序员,告诉项目管理者,怎样去管理一个项目,怎样在不同的角色之间进行协作。它没有对行业做什么要求,它也并不是针对汽车行业的。所以这样的一种方法,在被汽车行业运用的时候,必然会产生很多的争论。

我之前也写过了一篇文章ASPICE 还值得做吗?,从评论中也可以看得出来,敏捷开发在汽车行业充满了争论。有些人对敏捷开发保持了冷嘲热讽的态度。实际上包括特斯拉以及国内的造车新势力,基本上都在采用一种小步快跑,持续迭代的的方式来做软件开发。特斯拉的FSD功能,在已交付的车辆上,以肉眼可见的速度进化和升级。当汽车行业很多头部企业,都已经在或多或少尝试敏捷开发的思想时,还有一些人仍然停留在自己的看法里。

当然,我们不得不承认的一个事实是,敏捷开发在汽车行业尚未得到大规模的认可,我觉得这个也很正常,当前汽车行业正在进行一场变革,在变革的过程中肯定是百家争鸣,大家都有各自方式。而且也未形成变革后的统一标准,在这个时候产生比较多的争论,是有益于行业进步的。

今天文章的主题,我想预测一下,汽车行业的软件开发标准,将向一个什么样的方向进行演进。

我预测的第一点是,V模型将吸纳敏捷开发的特点,形成新的标准。

虽然敏捷开发并未形成汽车行业的标准,但却有非常多的团队以此种方法来进行实践。

有很多公司找我们咨询汽车行业敏捷开发相关的工具链,我们发现他们或多或少都已经开始使用敏捷项目管理工具。业界对这种趋势应该有更加明显的感受。

在汽车行业新的软件标准中,我预计,一定会是接纳并且认可小步快跑、持续迭代这样一种思想的。V模型也不应该简单地被看作是瀑布流。V模型的编写方式,并未提到它是一个瀑布流。但是我们从它上下文的行文中,很容易把它理解成一个瀑布流。比如,在我们做软件架构设计的时候,一定是对软件需求分析已经经过了大量的讨论,经过了大家的认可,但是并未提到,如果需求本身不全会怎样?如果需求没有理清楚,没有经过充分的讨论,我们是否能够去做架构方面的设计?是否可以并行?需求是逐渐完善的过程、架构也是逐渐完善的过程,在完善的过程中,再逐渐去建立追溯性,是否可行?

变更在开发过程中,是不可避免的,但在ASPICE中,变更管理是一个支持性流程,好像变更并不是在每个过程中进行的,而像是项目做到一定阶段之后,反过来进行的、偶尔的偏差改动。但实际上,变更管理应该被提到一个更重要、更频繁的位置,因为在汽车变革的过程中,我们所做的很多技术和产品,不确定性是非常高的,我们会面临更加频繁的变更。

在产品的初期,我们可能没有办法考虑到方方面面,我们拥有的是一个产品的Roadmap。但是针对 Roadmap 里面的每一个功能点,可能并不是在最开始的时候,就去详细地写出所有需求的细节,而是在做的过程中不断完善。通过不断地交付出一些可工作的产物,对需求也会不断做出调整。

第二点,我预计新的标准,会对 BP 进行更多的细化,并且也会推荐一些敏捷开发方法。

前面我们已经举过例子,在ASPICE里面,BP一般写的都比较粗。具体怎么做,其实没有很多的方法推荐。我估计新的标准中,会比较多的推荐敏捷开发的方法。如果某种解题方法是比较好的,我们需要把这种方法在标准里面体现出来,虽然这并不是强制性要求,但至少给我们提供了一些参考。这样才能让标准能够逐渐融合敏捷开发。

第三点是,如何与第三方进行合作,将会是标准的重要组成部分

在ASPICE原来的标准中,针对如何与第三方进行合作,其实篇幅很少,有一块叫做供应商管理。

但是,在新的标准中,如何与第三方合作,应该有大量的篇幅去解读它。在当前的汽车软件开发过程中,我们发现,联合开发变成了一种常态,导致了像 Tier 0. 5 这样一些合作方式出现。

在传统的标准中,我们一般只是强调,需要和供应商之间进行沟通,需要有与供应商之间进行信息交换的渠道,需要与供应商达成统一等等。

但在新的开发过程中,我们需要意识到,我们不仅与供应商之间会进行联合开发,与甲方客户之间也需要进行联合开发。而且联合开发的过程相比于原来会更加频繁和紧密,它不再是一个交钥匙的工程。对于一个软件或系统的开发,不同的软件组件可能是由不同的参与方来执行的。这个时候就要求我们在需求管控、问题管理上拥有更加实时的交流渠道,互相可以对对方提需求、提bug,并且大家好像是在一个管理系统上进行工作。这对于提升软件的开发效率是非常有必要的。

第四点是,CICD 将成为 BP 之一,缺少 CICD 的基础设施,意味着产品不具备持续迭代的属性。

在 ASPICE原来的标准中,对于持续集成、持续交付、持续部署,并没有特地强调。只是描述了针对软件的验证过程,需要有软件单元测试、软件集成测试、软件功能测试等等。更多还是强调,针对需求、架构、详细设计的可追溯性和完全覆盖。至于验证的过程要怎么做,并未提出要求。可以预见,未来甲方的需求会越来越多,且越来越频繁,CICD基础设施将是响应这一变化的关键。我们有一家做气体传感器的客户,其德方客户明确提出要求,研发过程必须上系统,且必须拥有统一的代码仓库和持续集成的能力(虽然这家客户本身的代码量不多,之前的代码全部放在工程师的电脑里进行管理)。但德方客户考虑到,后续市场或法规对于车内空气的更高要求,可能需要在更短时间内,提供更新迭代的产品。

作者介绍:

罗宇超,云体科技创始人,软件质量工程师,工具链工程师。

你可能感兴趣的:(汽车,软件工程,devops,敏捷开发,人工智能)