扫码微信咨询
ASPICE诞生的时间、背景和目的
2023-08-17
273
“软件定义汽车”逐渐在汽车行业达成共识，大家纷纷意识到软件相比于硬件，对于汽车行业重要性的比重逐渐提升。我们看到传统的主机厂纷纷转型，也涌入了越来越多的造车新势力，出现了越来越多的汽车软件供应商。不管是有造车经验，还是没有造车经验的，开始造车之后，首先都需要问一个问题：汽车行业的软件开发是什么样的？比如说小米来造车，是否能够按照小米之前开发手机软件的流程和步骤来直接开发车载软件？面对这个问题，我们去寻找这个问题的答案。就会发现在汽车行业有两个比较重要的软件开发标准，一个叫ASPICE，一个叫功能安全ISO26262。这两个标准都是基于V字型的开发模式。今天就来讲讲ASPICE认证。
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诞生的背景是强势的主机厂和供应商，对于它下级供应商的要求，诞生的原因是甲方看不到乙方的白盒交付，所以至少要保证你的流程是按照我定义的标准流程来实施的。乙方通过这种方式拿到甲方供应链体系的敲门砖。但并不代表通过了这个标准，就能开发出好的产品，这两者之间是没有根本性的联系的。
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诞生的背景是强势的主机厂和供应商，对于它下级供应商的要求，诞生的原因是甲方看不到乙方的白盒交付，所以至少要保证你的流程是按照我定义的标准流程来实施的。乙方通过这种方式拿到甲方供应链体系的敲门砖。但并不代表通过了这个标准，就能开发出好的产品，这两者之间是没有根本性的联系的。