Aspice（Automotive SPICE） 中文翻譯為汽車軟件過程改進及能力評定。是為保證軟件質量的規范，要求供應商按照Automotive SPICE的要求進行產品的設計與開發。是汽車行業中常用于質量管理的工具。

Aspice 的過程組包含了供應商過程組，系統過程組，軟件過程組，支持過程組，管理過程組，過程改進過程組，重用過程組。此篇文章著重介紹系統過程組，軟件過程組這兩個與開發人員強相關的部分。

01 “V”字模型的示意

先來看看過程組。因為所有工程（即：系統工程和軟件工程）過程的組織似于”V“字，因此常在人們口中為V模型。左邊的過程與右邊的過程正好對應，但需要知道的是，過程“SWE.3軟件詳細設計與單元構建”與“SWE.4軟件單元驗證”是獨立和分離的。

V模式很好的詮釋了我們項目開發過程中幾個重要的工作過程與工作內容。

圖1 “V”字模型示意圖

02 追溯性和一致性

ASPICE重要之一的就是需要具備雙向追溯性和一致性。追溯性著重工作產品之間存在引用和鏈接，進一步支持覆蓋率，影響分析，需求實施，狀態跟蹤等。相反，一致性關注內容和定義。

圖2 雙向可追溯性和一致性示意圖

雙向追溯性更多被定義為在測試用例與測試結果之間，往往漏掉測試用例與軟件需求之間的雙向追溯性。

圖2 可知我們需要具備雙向追溯性的有：系統需求與軟件需求；軟件需求與軟件單元測試；軟件詳細設計與軟件單元測試等等，可見圖藍色部分。

需要注意的是，軟件集成測試的依賴對象主要是軟件架構設計； 軟件集成測試主要是根據軟件架構的接口設計以及接口之間的數據時序，數據流向，測試一個子系統內部各個接口之間的數據輸入/傳輸/輸出是否正確。詳細內容介紹可見我這邊文章：淺聊集成測試。

03 ASPICE各過程的詳細內容介紹

SYS1 系統需求（篩選審核）

其中包含了硬件/軟件/結構等所有的客戶需求。

主要輸出：系統需求Feature清單/系統需求功能規范

SYS2 系統需求分析

此過程進行需求的分析，劃分哪部分是屬于軟件任務，那部分是屬于硬件任務或者是結構設計相關的任務。分析需求是否具備可實現性等，為后續的架構設計做鋪墊。

主要輸出：系統需求Feature清單/系統需求功能規范

SYS3 系統架構設計

建立系統架構設計，識別哪些系統需求被分派到哪些系統元素中，并按已定義的標準評估系統架構設計。是軟件架構設計的依賴對象，必須現有系統架構設計再有軟件架構設計。定義了軟件的詳細設計，描述了軟件單元，每個軟件單元及其接口。

主要輸出：系統架構設計說明文檔

SYS4 系統集成和集成測試

根據系統需求以及系統架構設計進行系統集成測試用例的編寫，然后進行系統集成測試。屬于白盒測試。

主要輸出：系統集成測試用例/系統測試計劃/系統集成測試報告

SWE1 軟件需求分析

根據篩選后的系統需求進行軟件部分的需求分析。

主要輸出：軟件需求Feature清單

SWE2 軟件架構設計

目的是建立軟件架構設計，是被每條軟件按需求被分配到哪個軟件元素中，并按照已定義的標準評估軟件架構設計

主要輸出：軟件架構設計說明文檔

SWE3 軟件詳細設計與單元構建

目的是為軟件單元提供一個已評估的詳細設計以實現軟件單元

主要輸出：軟件詳細設計說明文檔

SWE5 軟件集成與集成測試

制定了系統集成策略，制定包括回歸測試在內的集成測試策略，形成測試計劃；選擇測試用例，形成集成測試規范中的測試用例；然后進行進行測試并形成系統集成測試結果

主要輸出：軟件集成測試計劃/軟件集成測試用例/軟件集成測試報告

SWE6 軟件合格性測試輸出

制定包括回歸測試策略在內的軟件合格性測試策略；開發軟件合格性測試規范；然后選擇測試用例；測試集成軟件；總結和溝通結果：總結軟件合格性測試結果

主要輸出：軟件合格性測試報告

04 總結

一，ASPICE流程的利弊

ASPICE是為了規范我們代碼開發流程，同時提高我們的代碼質量，嚴格做到在開發前有明確的開發方案，明確的開發流程，任何代碼的設計都有靠譜的依據來源，是我們代碼質量的保證。

簡單來講，就是在保證代碼質量的情況下，按時完成我們的項目目標。如果僅僅是為了完成項目目標，而對于我們完成的交付物不做最后的“估值”，那我認為我們完成的這個任務沒有任何的意義，因為它不被人們滿意的接受。而完成這最后的“估值”就需要我們輸出的那些文檔作為支撐，我們通過這個文檔以及測試結果來進行驗收，來判斷設計，開發是否符合客戶的需求，是否滿足于最初的項目目標。

作為項目管理者來講，我們更喜歡這個文檔按照標準輸出，他更像我們與開發者之前溝通的橋梁，通過這些文檔，我們能知道開發者更加詳細的設計方案與想法。在溝通中會少了很多前期的溝通成本。

可能針對開發人員來說，遵頊這個流程的最大挑戰就是文檔的輸出，嚴格按照標準的ASPICE來進行項目開發，我們需要從上至下按照V模型進行。即：先完成系統需求，系統架構設計，再完成軟件需求，軟件架構，軟件詳細設計，最后才是代碼開發和測試，而現實中的很多項目因為時間關系代碼開發和文檔編寫都是并行，這是不符合ASPICE的要求的，并沒有很好的發揮ASPICE的優點來把控我們的代碼質量。

而如果嚴格按照這個流程來執行，在開發端的時間將會延長至少一倍，對我們的人力成本也是一個很大的挑戰。ASPICE要求的設計文檔都需要相關的開發人員進行輸出，用程序員的話來講：寫這些文檔的時間比碼代碼的時間更長，寫一個功能的開發文檔，我可以完成至少3個同等功能的開發。

二，ASPICE流程規范，是否需要裁剪？

雖然ASPICE在我們項目開發過程中具有很好的指導作用，但是否我們需要完全“死板”遵循。前面已經提到，我們的ASPICE流程雖然好，但是需要的時間長，人工成本高，針對任務重且周期短的項目是不友好的。因此，這個問題我的答案是：根據項目實際情況進行裁剪。

在項目開發中，我們常常會參與或者組織項目階段總結會。之前小鹿組織的一個項目總結會中，很多工程師常常對項目的任務的優先級有很大的疑惑：是先完成文檔設計工作還是先完成代碼交付工作？這種疑惑常發生在生命周期短的項目，工程師常常同時被催促輸出文檔以及代碼。標準的回答是：按照開發流程，是先完成文檔設計，再做代碼開發，但是由于我們的時間緊張，因此他們同步進行。在會上，我們達成的統一目標就是：充分使用，合理安排，在滿足客戶的需求下，對文檔的要求進行適當的裁剪，在此條件之前，按時按質的完成項目目標。

裁剪僅僅是為了將有限的時間安排在重要的事項中。針對生命周期長的項目，可嚴格遵循；針對生命周期短且任務重的項目，可做適當的裁剪 ，裁剪掉相對不重要的過程以及流程，或者做并行處理。當然根據實際情況實際評估。

ASPICE是我們保證代碼質量，優化代碼開發流程的工具，它可以指導我們做項目開發，但我們可以根據開發任務做裁剪。實際情況實際分析哦！

審核編輯 ：李倩