“軟件定義汽車”逐漸在汽車行業達成共識，大家紛紛意識到軟件相比于硬件，對于汽車行業重要性的比重逐漸提升。我們看到傳統的主機廠紛紛轉型，也涌入了越來越多的造車新勢力，出現了越來越多的汽車軟件供應商。不管是有造車經驗，還是沒有造車經驗的，開始造車之后，首先都需要問一個問題：汽車行業的軟件開發是什么樣的？比如說小米來造車，是否能夠按照小米之前開發手機軟件的流程和步驟來直接開發車載軟件？面對這個問題，我們去尋找這個問題的答案。就會發現在汽車行業有兩個比較重要的軟件開發標準，一個叫 ASPICE， 一個叫功能安全ISO26262。這兩個標準都是基于 V 字型的開發模式。

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誕生的背景是強勢的主機廠和供應商，對于它下級供應商的要求，誕生的原因是甲方看不到乙方的白盒交付，所以至少要保證你的流程是按照我定義的標準流程來實施的。乙方通過這種方式拿到甲方供應鏈體系的敲門磚。但并不代表通過了這個標準，就能開發出好的產品，這兩者之間是沒有根本性的聯系的。