汽车行业的软件开发是什么样的？

“软件定义汽车”逐渐在汽车行业达成共识，大家纷纷意识到软件相比于硬件，对于汽车行业重要性的比重逐渐提升。我们看到传统的主机厂纷纷转型，也涌入了越来越多的造车新势力，出现了越来越多的汽车软件供应商。

不管是有造车经验，还是没有造车经验的，开始造车之后，首先都需要问一个问题：汽车行业的软件开发是什么样的？比如说小米来造车，是否能够按照小米之前开发手机软件的流程和步骤来直接开发车载软件？

面对这个问题，我们去寻找这个问题的答案。就会发现在汽车行业有两个比较重要的软件开发标准，一个叫 ASPICE， 一个叫功能安全ISO26262。这两个标准都是基于 V 字型的开发模式。

01.ASPICE诞生的时间、背景和目的

那么ASPICE标准诞生的背景是什么呢？在05 年的时候——注意这个时间是 05年， 现在已经是 17 年之后了——德国的十几家主机厂和比较强势的供应商一起制定了一个汽车软件流程的评价框架，后来他们背靠VDA（德国汽车工业协会）发布了这套框架。制定这套框架的目的是什么呢？因为他们的软件供应商，不可能把软件以白盒形式交付给他们。这时候他们想到了一个招：虽然我不能看你的代码，但是我要求你的整个软件或者系统的研发流程是按照特定的流程。这个流程就是汽车行业非常有名的 V字型开发流程。它的主体部分，是系统工程和软件工程部分。具体来说，就是针对一个系统的开发需要包括：系统需求分析、系统架构设计、软件需求分析、软件架构设计、软件详细设计，这是V字型的左边，以及对应的右边验证测试的过程。

这十几家主机厂和供应商的逻辑是这样的：虽然我看不到你的详细代码，但是假如你的整个开发是流程是基于这个我定义的这个流程来开发的，那么我就认为你的质量是基本达标的。但这其实只是进入主机厂和强势供应商的供应链体系的敲门砖。只是代表你遵循了这样一个流程，并不代表你的产品好坏。至于最终是否能进入供应链体系，产品优劣、价格、交付速度、售后，其实更加重要。所以如果我们深入理解这个逻辑的话，我们就会发现，它是强势的甲方，对于乙方的要求。这个框架的要求和细节，是非常繁杂的。

具体来说，ASPICE对两块地方的要求特别高，一块叫做追溯性，一块叫做合规性。所谓的追溯性，简单的理解就是，从任何一个细节，比如说一个 bug，我可以追溯到它的测试用例，追溯到它的测试计划，追溯到它的软件需求，追溯到它的软件架构，追溯到它的系统架构、系统需求等等。

另外一块是叫做合文档的合规性。比如说我要做一个测试，测试的时候首先需要制定一个测试计划，我的测试策略是什么？我的测试目标是什么？我这次测试是针对什么东西的测试，然后有哪些人参与，然后测试的过程怎么进行结果的记录，bug如何进行追踪，以及 bug 的解决过程，bug 的原因分析，它的影响分析等等。

那么具体追溯性和合规性如何实现呢？这套评价框架是没讲的，主机厂也不关心，或者就算他想关心，他那些供应商也不可能完全按照他的要求来做。那么既然主机厂不关心，那么他们怎么来把控他们的供应商真的能满足这套评价框架呢？这时候就出现了叫做 ASPICE评审的活动，是由对ASPICE标准比较熟悉的评审师，来针对某家公司的流程来做评价的。你通过了，就能给你发个证。有些评审师非常有经验，他不仅知道怎么评价，还知道你通过什么方式、什么工具能快速通过评价；还有一些评审师，他只知道标准的要求是什么，至于“怎么做”才能通过标准，“怎么做”才能高效地通过这个标准，提供不了什么帮助。

那么这块就出现了一个问题，既然标准都是一样的，但是具体的实现过程不一样，我们就会发现有些公司实现追溯性的过程非常高效，还有一些公司就非常繁杂。举个例子，有些公司基本上全部是用 word 的方式来管理他所有的文档。有一份需求用 word 来书写有 20 页，有一份软件架构用 word 来书写有 50 页。你可以看到有一个需求，比如叫需求1，我问你它的架构是什么，你就会发现需求 1 下面写了是架构3.2，然后你就去架构的word文档里面翻到架构3.2。那么到了架构的时候，我问你架构有没有测试用例，然后你就会在架构那看到，对应的测试用例是5.3，然后你就去翻到对应的测试用例word里面，有一条5.3。你说这家公司有没有建立追溯性呢？它确实建立了追溯性。但是我们刚刚举的这个例子非常简单，它只涉及到三步，我们确实可以通过翻阅文档的方式来进行追溯。

但是大家想象一下，一般来说在一家公司里面，需求、软件架构、测试用例都是由不同的工程师来完成的。那么不同的工程师可能把这些文档放在不同的地方，不同的工程师也会实时地更新它的文档。比如说我们刚刚把软件需求和软件架构联系起来了，这时候，软件架构word更新了一点东西，它能否通知到软件需求，这里有一处更新呢？以及架构师是否知道去通知谁呢？

假如我的系统中有 30 份软件需求文档，50份软件架构文档，100 份测试用例文档，这个时候你再去寻找它，这个寻找过程的复杂程度，就是指数级增长了。可以看到，确实建立了追溯性，但是这个追溯性的实用性很差。这也是为什么很多团队在ASPICE评审的过程中怨声载道，一旦评审通过，立刻抛弃这套“追溯性”和“合规性”过程。

总结一下：ASPICE诞生的背景是强势的主机厂和供应商，对于它下级供应商的要求，诞生的原因是甲方看不到乙方的白盒交付，所以至少要保证你的流程是按照我定义的标准流程来实施的。乙方通过这种方式拿到甲方供应链体系的敲门砖。但并不代表通过了这个标准，就能开发出好的产品，这两者之间是没有根本性的联系的。

02.ASPICE 适合和不适合哪些公司

基于这个背景，我们来想一下，ASPICE或者说 V 字型开发，适合和不适合哪些公司呢？

我们首先说它适合的公司。

如果这家公司，比如说是一家传统的主机厂，之前没有做过软件开发，学习ASPICE开发模型对于它来说是合适的。因为它可以通过一套标准流程的建立，大体知道汽车软件是怎么开发的，它的系统，它的需求，它里面需要完成哪些步骤。可以快速地帮他建立起这个团队的流程，然后也可以让他快速找到对应的人。因为根据不同的事情，你就需要找对应的软件系统工程师、软件架构工程师、软件测试工程师等等。

如果是针对其他行业，比如说小米汽车，他转型过来做汽车。这个时候对于他们来说也是有用的，因为他们同样可以快速地熟悉汽车行业。

那么它不适合哪些公司呢？

如果有一家做汽车软件的公司，它本身的软件已经做得非常好了，它已经有一套自有的软件体系来保证软件质量。另外它也不需要对它的甲方供货，比如说它本身就是一家主机厂，他不需要对他的供应商详细解释，他的整个软件开发流程是什么样的。举个例子，比如在做测试计划的时候，详细的测试策略是什么，测试计划是怎么安排的，出现什么情况，才会进行回归测试。这些东西在团队内部，已经是约定俗成的。比如说蔚来汽车，蔚来汽车的智能座舱基本上是完全自研的。整个团队非常清楚测试策略是什么。这个测试策略一旦形成下来，比如说通过六个月、一年搭建好了，整个团队都知道怎么做了。这个时候，就不需要花大力气，在每一份测试计划里面，都去写详细的测试策略、测试流程、回归策略等等。

像这类公司，它其实是不适合反过头来做ASPICE，这个反而会降低他们的软件开发速度。但是并不是说ASPICE对于像蔚来这样的公司完全不可用，它其实是可以给它们作为一个参考的。因为有些团队一旦敏捷之后，很多文档就没有了。举个例子，软件需求有 100 条，对应的软件测试用例有 1000 条。他们之间没有建立追溯性关系，但是我知道这 1000 条测试用例就是针对这 100 条需求来测的。这当然没有问题。但是不可能每次测试的时候，都把这 1000 条测完。根据不同的开发阶段，有时候可能只选择其中的 500 条。这个时候，如果问你这十条需求在这次的测试计划里面，测试用例覆盖率是多少。如果没有建立一个追溯性的关系，这个问题就非常难以回答。

所以对于像蔚来汽车这样的团队，他们同样需要去借鉴 ASPICE的一些经验和方法，来让他们的整个流程，既保证有一定的敏捷效率，同时又能做到合规性和高效化。另外蔚来汽车本身是一家新造车，所以它招聘的人里面既有传统的软件开发团队，也有从手机行业过来的，从互联网行业过来的。怎么能让这些人用共同的语言说话，怎么能让这些人遵循一个共同的流程？在前期去借鉴ASPICE流程的思想和方法，也是有必要的。

总结一下：

如果你的团队以前没有做过汽车行业的软件开发，那么ASPICE的整个流程，作为快速搭建软件研发体系，是有用的；

如果你的团队是一个混合型的团队，从各行各业招人，那么为了让你的团队在短时间之内形成一个一致的开发习惯和开发流程，那么ASPICE也是有借鉴和参考意义的

但是如果你的团队本身没有向外交付软件的需求，你们整个内部流程也特别清晰，追溯性已经建立起来了，软件质量很高。这种情况下，ASPICE对你的重要性会大大降低。这个时候，反而是你需要通过升级你的工具链，升级你的管理方式，来让整个研发过程更高效。

举个例子，从我家到汽车公司的路线，我已经知道了 3 条很快的步行路径。接下来我要做的就不再是用步行的方式，寻找一条新的路径。因为最短的路线已经寻找出来了，而且我已经很熟悉了，再去寻找新的路线已经没有意义了。这个时候我就需要考虑，能否使用什么交通工具，进一步缩短上班时间。  

03.ASPICE与敏捷开发融合

 接下来我们就要谈谈ASPICE和敏捷开发的结合了。刚刚已经讲了很多ASPICE，它其实是软件流程的评价框架，是甲方对乙方的要求。那么敏捷是什么呢？敏捷其实是一种软件开发的理念、价值观和一系列工具的融合。它的出发点和 ASPICE完全不一样。 ASPICE的出发点是甲方对乙方的要求，而敏捷的出发点其实是站在乙方的角度，讨论如何快速地实现软件开发。所以敏捷实际上是来告诉大家怎么样真正地来实现这个过程的。

ASPICE是一个要求，甲方要求乙方做什么。敏捷是说，乙方怎么来快速地做这个东西。这个其实就是目前汽车行业转型的困境：大家都知道要转型，但没有人知道该怎么转，没有人知道该怎么融合，标准也还没出来。 敏捷里面讲到了很多理念，比如说可工作的软件，高于详细的文档。敏捷里面也提供了很多理论化的工具，比如说 scrum、Kanban、燃尽图、敏捷回顾会议等等。我们可以看到有很多软件公司就是基于这样一套方法来设计他们的软件，比如说澳洲的 Atlassion 公司。 我们谈完了ASPICE和敏捷，我们知道ASPICE是对于汽车行业软件开发流程的标准。

虽然它诞生于2005年，已经有17 年的历史了，但汽车软件开发（中国的），真正发生革命性的变化，是在2014年前后，在汽车行业还没有诞生一个新的软件开发标准之前，它还是有它存在的意义的。 我觉得这个新的软件开发标准，应该会在近几年诞生，因为最近几年整个汽车行业的变革是非常快的，可以说是颠覆性的，整个汽车行业变得非常有活力。这个时间点，特别适合产生新的软件开发流程。这个新的软件开发流程或者标准，也很有可能是在中国诞生的。因为中国的电动车或者说智能车的生产比例，占全球总数的40%以上。在这块我们是有优势的。

笔者曾在造车新势力及传统车企的软件中心从事软件质量与工具链的工作，在深入接触并应用ASPICE之后，觉得ASPICE不是一颗银弹，不要认为它能够解决所有的问题，它只是一个老师对于学生或者甲方对于乙方的要求。如果你去深入地挖掘这个要求，然后自己想出一套方法来做，当然也可以，但是你的效率会特别慢，因为整个汽车软件的研发过程比较复杂。 基于前文提到的问题，去年，我和几个小伙伴一起出来创业了，我们产品的设计思路是，基于ASPICE的开发理念，进行工具设计，通过工具来实现高效的追溯性和合规性的建立。如果满足标准本身并不繁琐，那么工程师会更乐意去满足标准，同时又能实现敏捷。 举个例子，在 ASPICE里面有非常强的追溯性要求。我们通过思维导图的方式来建立追溯性，因为思维导图天生具有上下文的追溯性。不同的思维导图之间，也能通过关联透视图的方式来建立追溯性。

再举一个例子，比如在ASPICE里面，我们经常提到评审的概念。也就是说，不管是你的软件需求还是软件架构，一个人做好之后，需要和团队其他成员进行评审。那么在敏捷开发里面这个评审可能就是现场的评审。这种讨论相对来说比较开放式的，它其实没有很好的记录。我们把这样一个评审融入到了工具里面，比如说基于思维导图，我可以向多个人或者指定的评审委员会发送评审请求。他看到这个思维导图，直接对它进行评审，通过还是不必通过，不通过他可以写一些评论。我们会自动计算所有人的评论结果，最后来决定这个评审是通过还是不通过。整个过程也会在工具里面留下记录。

总结一下：ASPICE不是银弹，满足了ASPICE标准，并不代表你能开发出好的产品。如果实现标准的过程不繁琐，工程师也乐于去实现标准。既能满足标准，又能快捷高效，是工具链搭建的方向。

审核编辑：刘清