關于ASPICE各過程的詳細內(nèi)容介紹

Aspice（Automotive SPICE） 中文翻譯為汽車軟件過程改進及能力評定。是為保證軟件質(zhì)量的規(guī)范，要求供應商按照Automotive SPICE的要求進行產(chǎn)品的設計與開發(fā)。是汽車行業(yè)中常用于質(zhì)量管理的工具。 Aspice 的過程組包含了供應商過程組，系統(tǒng)過程組，軟件過程組，支持過程組，管理過程組，過程改進過程組，重用過程組。此篇文章著重介紹系統(tǒng)過程組，軟件過程組這兩個與開發(fā)人員強相關的部分。

01 “V”字模型的示意

先來看看過程組。因為所有工程（即：系統(tǒng)工程和軟件工程）過程的組織似于”V“字，因此常在人們口中為V模型。左邊的過程與右邊的過程正好對應，但需要知道的是，過程“SWE.3軟件詳細設計與單元構建”與“SWE.4軟件單元驗證”是獨立和分離的。 V模式很好的詮釋了我們項目開發(fā)過程中幾個重要的工作過程與工作內(nèi)容。

圖1 “V”字模型示意圖

02 追溯性和一致性

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

圖2 雙向可追溯性和一致性示意圖 雙向追溯性更多被定義為在測試用例與測試結果之間，往往漏掉測試用例與軟件需求之間的雙向追溯性。 圖2 可知我們需要具備雙向追溯性的有：系統(tǒng)需求與軟件需求；軟件需求與軟件單元測試；軟件詳細設計與軟件單元測試等等，可見圖藍色部分。 需要注意的是，軟件集成測試的依賴對象主要是軟件架構設計；軟件集成測試主要是根據(jù)軟件架構的接口設計以及接口之間的數(shù)據(jù)時序，數(shù)據(jù)流向，測試一個子系統(tǒng)內(nèi)部各個接口之間的數(shù)據(jù)輸入/傳輸/輸出是否正確。詳細內(nèi)容介紹可見我這邊文章：淺聊集成測試。

03 ASPICE各過程的詳細內(nèi)容介紹

SYS1 系統(tǒng)需求（篩選審核）

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

主要輸出：系統(tǒng)需求Feature清單/系統(tǒng)需求功能規(guī)范

SYS2 系統(tǒng)需求分析

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

主要輸出：系統(tǒng)需求Feature清單/系統(tǒng)需求功能規(guī)范

SYS3 系統(tǒng)架構設計

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

主要輸出：系統(tǒng)架構設計說明文檔

SYS4 系統(tǒng)集成和集成測試

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

主要輸出：系統(tǒng)集成測試用例/系統(tǒng)測試計劃/系統(tǒng)集成測試報告

SWE1 軟件需求分析

根據(jù)篩選后的系統(tǒng)需求進行軟件部分的需求分析。

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

SWE2 軟件架構設計

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

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

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

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

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

SWE5 軟件集成與集成測試

制定了系統(tǒng)集成策略，制定包括回歸測試在內(nèi)的集成測試策略，形成測試計劃；選擇測試用例，形成集成測試規(guī)范中的測試用例；然后進行進行測試并形成系統(tǒng)集成測試結果

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

SWE6 軟件合格性測試輸出

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

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

04 總結

一，ASPICE流程的利弊

ASPICE是為了規(guī)范我們代碼開發(fā)流程，同時提高我們的代碼質(zhì)量，嚴格做到在開發(fā)前有明確的開發(fā)方案，明確的開發(fā)流程，任何代碼的設計都有靠譜的依據(jù)來源，是我們代碼質(zhì)量的保證。 簡單來講，就是在保證代碼質(zhì)量的情況下，按時完成我們的項目目標。如果僅僅是為了完成項目目標，而對于我們完成的交付物不做最后的“估值”，那我認為我們完成的這個任務沒有任何的意義，因為它不被人們滿意的接受。而完成這最后的“估值”就需要我們輸出的那些文檔作為支撐，我們通過這個文檔以及測試結果來進行驗收，來判斷設計，開發(fā)是否符合客戶的需求，是否滿足于最初的項目目標。 作為項目管理者來講，我們更喜歡這個文檔按照標準輸出，他更像我們與開發(fā)者之前溝通的橋梁，通過這些文檔，我們能知道開發(fā)者更加詳細的設計方案與想法。在溝通中會少了很多前期的溝通成本。 可能針對開發(fā)人員來說，遵頊這個流程的最大挑戰(zhàn)就是文檔的輸出，嚴格按照標準的ASPICE來進行項目開發(fā)，我們需要從上至下按照V模型進行。即：先完成系統(tǒng)需求，系統(tǒng)架構設計，再完成軟件需求，軟件架構，軟件詳細設計，最后才是代碼開發(fā)和測試，而現(xiàn)實中的很多項目因為時間關系代碼開發(fā)和文檔編寫都是并行，這是不符合ASPICE的要求的，并沒有很好的發(fā)揮ASPICE的優(yōu)點來把控我們的代碼質(zhì)量。 而如果嚴格按照這個流程來執(zhí)行，在開發(fā)端的時間將會延長至少一倍，對我們的人力成本也是一個很大的挑戰(zhàn)。ASPICE要求的設計文檔都需要相關的開發(fā)人員進行輸出，用程序員的話來講：寫這些文檔的時間比碼代碼的時間更長，寫一個功能的開發(fā)文檔，我可以完成至少3個同等功能的開發(fā)。

二，ASPICE流程規(guī)范，是否需要裁剪？

雖然ASPICE在我們項目開發(fā)過程中具有很好的指導作用，但是否我們需要完全“死板”遵循。前面已經(jīng)提到，我們的ASPICE流程雖然好，但是需要的時間長，人工成本高，針對任務重且周期短的項目是不友好的。因此，這個問題我的答案是：根據(jù)項目實際情況進行裁剪。 在項目開發(fā)中，我們常常會參與或者組織項目階段總結會。之前小鹿組織的一個項目總結會中，很多工程師常常對項目的任務的優(yōu)先級有很大的疑惑：是先完成文檔設計工作還是先完成代碼交付工作？這種疑惑常發(fā)生在生命周期短的項目，工程師常常同時被催促輸出文檔以及代碼。標準的回答是：按照開發(fā)流程，是先完成文檔設計，再做代碼開發(fā)，但是由于我們的時間緊張，因此他們同步進行。在會上，我們達成的統(tǒng)一目標就是：充分使用，合理安排，在滿足客戶的需求下，對文檔的要求進行適當?shù)牟眉?，在此條件之前，按時按質(zhì)的完成項目目標。 裁剪僅僅是為了將有限的時間安排在重要的事項中。針對生命周期長的項目，可嚴格遵循；針對生命周期短且任務重的項目，可做適當?shù)牟眉?，裁剪掉相對不重要的過程以及流程，或者做并行處理。當然根據(jù)實際情況實際評估。 小鹿說：ASPICE是我們保證代碼質(zhì)量，優(yōu)化代碼開發(fā)流程的工具，它可以指導我們做項目開發(fā)，但我們可以根據(jù)開發(fā)任務做裁剪。實際情況實際分析哦！

編輯：黃飛