“軟件定義汽車”逐漸在汽車行業(yè)達(dá)成共識，大家紛紛意識到軟件相比于硬件，對于汽車行業(yè)重要性的比重逐漸提升。我們看到傳統(tǒng)的主機(jī)廠紛紛轉(zhuǎn)型，也涌入了越來越多的造車新勢力，出現(xiàn)了越來越多的汽車軟件供應(yīng)商。不管是有造車經(jīng)驗(yàn)，還是沒有造車經(jīng)驗(yàn)的，開始造車之后，首先都需要問一個(gè)問題：汽車行業(yè)的軟件開發(fā)是什么樣的？比如說小米來造車，是否能夠按照小米之前開發(fā)手機(jī)軟件的流程和步驟來直接開發(fā)車載軟件？面對這個(gè)問題，我們?nèi)ふ疫@個(gè)問題的答案。就會(huì)發(fā)現(xiàn)在汽車行業(yè)有兩個(gè)比較重要的軟件開發(fā)標(biāo)準(zhǔn)，一個(gè)叫 ASPICE， 一個(gè)叫功能安全I(xiàn)SO26262。這兩個(gè)標(biāo)準(zhǔn)都是基于 V 字型的開發(fā)模式。
ASPICE誕生的時(shí)間、背景和目的
那么ASPICE標(biāo)準(zhǔn)誕生的背景是什么呢？在05 年的時(shí)候——注意這個(gè)時(shí)間是 05年， 現(xiàn)在已經(jīng)是 17 年之后了——德國的十幾家主機(jī)廠和比較強(qiáng)勢的供應(yīng)商一起制定了一個(gè)汽車軟件流程的評價(jià)框架，后來他們背靠VDA（德國汽車工業(yè)協(xié)會(huì)）發(fā)布了這套框架。制定這套框架的目的是什么呢？因?yàn)樗麄兊能浖⿷?yīng)商，不可能把軟件以白盒形式交付給他們。這時(shí)候他們想到了一個(gè)招：雖然我不能看你的代碼，但是我要求你的整個(gè)軟件或者系統(tǒng)的研發(fā)流程是按照特定的流程。這個(gè)流程就是汽車行業(yè)非常有名的 V字型開發(fā)流程。它的主體部分，是系統(tǒng)工程和軟件工程部分。具體來說，就是針對一個(gè)系統(tǒng)的開發(fā)需要包括：系統(tǒng)需求分析、系統(tǒng)架構(gòu)設(shè)計(jì)、軟件需求分析、軟件架構(gòu)設(shè)計(jì)、軟件詳細(xì)設(shè)計(jì)，這是V字型的左邊，以及對應(yīng)的右邊驗(yàn)證測試的過程。
這十幾家主機(jī)廠和供應(yīng)商的邏輯是這樣的：雖然我看不到你的詳細(xì)代碼，但是假如你的整個(gè)開發(fā)是流程是基于這個(gè)我定義的這個(gè)流程來開發(fā)的，那么我就認(rèn)為你的質(zhì)量是基本達(dá)標(biāo)的。但這其實(shí)只是進(jìn)入主機(jī)廠和強(qiáng)勢供應(yīng)商的供應(yīng)鏈體系的敲門磚。只是代表你遵循了這樣一個(gè)流程，并不代表你的產(chǎn)品好壞。至于最終是否能進(jìn)入供應(yīng)鏈體系，產(chǎn)品優(yōu)劣、價(jià)格、交付速度、售后，其實(shí)更加重要。所以如果我們深入理解這個(gè)邏輯的話，我們就會(huì)發(fā)現(xiàn)，它是強(qiáng)勢的甲方，對于乙方的要求。這個(gè)框架的要求和細(xì)節(jié)，是非常繁雜的。
具體來說，ASPICE對兩塊地方的要求特別高，一塊叫做追溯性，一塊叫做合規(guī)性。所謂的追溯性，簡單的理解就是，從任何一個(gè)細(xì)節(jié)，比如說一個(gè) bug，我可以追溯到它的測試用例，追溯到它的測試計(jì)劃，追溯到它的軟件需求，追溯到它的軟件架構(gòu)，追溯到它的系統(tǒng)架構(gòu)、系統(tǒng)需求等等。
另外一塊是叫做合文檔的合規(guī)性。比如說我要做一個(gè)測試，測試的時(shí)候首先需要制定一個(gè)測試計(jì)劃，我的測試策略是什么？我的測試目標(biāo)是什么？我這次測試是針對什么東西的測試，然后有哪些人參與，然后測試的過程怎么進(jìn)行結(jié)果的記錄，bug如何進(jìn)行追蹤，以及 bug 的解決過程，bug 的原因分析，它的影響分析等等。
那么具體追溯性和合規(guī)性如何實(shí)現(xiàn)呢？這套評價(jià)框架是沒講的，主機(jī)廠也不關(guān)心，或者就算他想關(guān)心，他那些供應(yīng)商也不可能完全按照他的要求來做。那么既然主機(jī)廠不關(guān)心，那么他們怎么來把控他們的供應(yīng)商真的能滿足這套評價(jià)框架呢？這時(shí)候就出現(xiàn)了叫做 ASPICE評審的活動(dòng)，是由對ASPICE標(biāo)準(zhǔn)比較熟悉的評審師，來針對某家公司的流程來做評價(jià)的。你通過了，就能給你發(fā)個(gè)證。有些評審師非常有經(jīng)驗(yàn)，他不僅知道怎么評價(jià)，還知道你通過什么方式、什么工具能快速通過評價(jià)；還有一些評審師，他只知道標(biāo)準(zhǔn)的要求是什么，至于“怎么做”才能通過標(biāo)準(zhǔn)，“怎么做”才能高效地通過這個(gè)標(biāo)準(zhǔn)，提供不了什么幫助。
那么這塊就出現(xiàn)了一個(gè)問題，既然標(biāo)準(zhǔn)都是一樣的，但是具體的實(shí)現(xiàn)過程不一樣，我們就會(huì)發(fā)現(xiàn)有些公司實(shí)現(xiàn)追溯性的過程非常高效，還有一些公司就非常繁雜。舉個(gè)例子，有些公司基本上全部是用 word 的方式來管理他所有的文檔。有一份需求用 word 來書寫有 20 頁，有一份軟件架構(gòu)用 word 來書寫有 50 頁。你可以看到有一個(gè)需求，比如叫需求1，我問你它的架構(gòu)是什么，你就會(huì)發(fā)現(xiàn)需求 1 下面寫了是架構(gòu)3.2，然后你就去架構(gòu)的word文檔里面翻到架構(gòu)3.2。那么到了架構(gòu)的時(shí)候，我問你架構(gòu)有沒有測試用例，然后你就會(huì)在架構(gòu)那看到，對應(yīng)的測試用例是5.3，然后你就去翻到對應(yīng)的測試用例word里面，有一條5.3。你說這家公司有沒有建立追溯性呢？它確實(shí)建立了追溯性。但是我們剛剛舉的這個(gè)例子非常簡單，它只涉及到三步，我們確實(shí)可以通過翻閱文檔的方式來進(jìn)行追溯。
但是大家想象一下，一般來說在一家公司里面，需求、軟件架構(gòu)、測試用例都是由不同的工程師來完成的。那么不同的工程師可能把這些文檔放在不同的地方，不同的工程師也會(huì)實(shí)時(shí)地更新它的文檔。比如說我們剛剛把軟件需求和軟件架構(gòu)聯(lián)系起來了，這時(shí)候，軟件架構(gòu)word更新了一點(diǎn)東西，它能否通知到軟件需求，這里有一處更新呢？以及架構(gòu)師是否知道去通知誰呢？
假如我的系統(tǒng)中有 30 份軟件需求文檔，50份軟件架構(gòu)文檔，100 份測試用例文檔，這個(gè)時(shí)候你再去尋找它，這個(gè)尋找過程的復(fù)雜程度，就是指數(shù)級增長了。可以看到，確實(shí)建立了追溯性，但是這個(gè)追溯性的實(shí)用性很差。這也是為什么很多團(tuán)隊(duì)在ASPICE評審的過程中怨聲載道，一旦評審?fù)ㄟ^，立刻拋棄這套“追溯性”和“合規(guī)性”過程。
總結(jié)：ASPICE誕生的背景是強(qiáng)勢的主機(jī)廠和供應(yīng)商，對于它下級供應(yīng)商的要求，誕生的原因是甲方看不到乙方的白盒交付，所以至少要保證你的流程是按照我定義的標(biāo)準(zhǔn)流程來實(shí)施的。乙方通過這種方式拿到甲方供應(yīng)鏈體系的敲門磚。但并不代表通過了這個(gè)標(biāo)準(zhǔn)，就能開發(fā)出好的產(chǎn)品，這兩者之間是沒有根本性的聯(lián)系的。
| 
華潤燃?xì)?/td>
港華燃?xì)?/td>
