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