Aspice（Automotive SPICE） 中文翻譯為汽車軟件過程改進及能力評定,。是為保證軟件質(zhì)量的規(guī)范，要求供應(yīng)商按照Automotive SPICE的要求進行產(chǎn)品的設(shè)計與開發(fā),。是汽車行業(yè)中常用于質(zhì)量管理的工具,。
Aspice 的過程組包含了供應(yīng)商過程組，系統(tǒng)過程組,，軟件過程組，支持過程組，管理過程組,，過程改進過程組,，重用過程組。此篇文章著重介紹系統(tǒng)過程組,，軟件過程組這兩個與開發(fā)人員強相關(guān)的部分,。
01 “V”字模型的示意
先來看看過程組。因為所有工程（即：系統(tǒng)工程和軟件工程）過程的組織似于”V“字,，因此常在人們口中為V模型,。左邊的過程與右邊的過程正好對應(yīng)，但需要知道的是,，過程“SWE.3軟件詳細設(shè)計與單元構(gòu)建”與“SWE.4軟件單元驗證”是獨立和分離的,。
V模式很好的詮釋了我們項目開發(fā)過程中幾個重要的工作過程與工作內(nèi)容。
圖1 “V”字模型示意圖
02 追溯性和一致性
ASPICE重要之一的就是需要具備雙向追溯性和一致性,。追溯性著重工作產(chǎn)品之間存在引用和鏈接,，進一步支持覆蓋率，影響分析,，需求實施,，狀態(tài)跟蹤等。相反,，一致性關(guān)注內(nèi)容和定義,。
圖2 雙向可追溯性和一致性示意圖
雙向追溯性更多被定義為在測試用例與測試結(jié)果之間，往往漏掉測試用例與軟件需求之間的雙向追溯性,。
圖2 可知我們需要具備雙向追溯性的有：系統(tǒng)需求與軟件需求,；軟件需求與軟件單元測試；軟件詳細設(shè)計與軟件單元測試等等,，可見圖藍色部分,。
需要注意的是，軟件集成測試的依賴對象主要是軟件架構(gòu)設(shè)計,； 軟件集成測試主要是根據(jù)軟件架構(gòu)的接口設(shè)計以及接口之間的數(shù)據(jù)時序,，數(shù)據(jù)流向，測試一個子系統(tǒng)內(nèi)部各個接口之間的數(shù)據(jù)輸入/傳輸/輸出是否正確,。詳細內(nèi)容介紹可見我這邊文章：淺聊集成測試,。
03 ASPICE各過程的詳細內(nèi)容介紹
SYS1 系統(tǒng)需求（篩選審核）
其中包含了硬件/軟件/結(jié)構(gòu)等所有的客戶需求。
主要輸出：系統(tǒng)需求Feature清單/系統(tǒng)需求功能規(guī)范
SYS2 系統(tǒng)需求分析
此過程進行需求的分析,，劃分哪部分是屬于軟件任務(wù),，那部分是屬于硬件任務(wù)或者是結(jié)構(gòu)設(shè)計相關(guān)的任務(wù)。分析需求是否具備可實現(xiàn)性等,，為后續(xù)的架構(gòu)設(shè)計做鋪墊,。
主要輸出：系統(tǒng)需求Feature清單/系統(tǒng)需求功能規(guī)范
SYS3 系統(tǒng)架構(gòu)設(shè)計
建立系統(tǒng)架構(gòu)設(shè)計,，識別哪些系統(tǒng)需求被分派到哪些系統(tǒng)元素中，并按已定義的標(biāo)準(zhǔn)評估系統(tǒng)架構(gòu)設(shè)計,。是軟件架構(gòu)設(shè)計的依賴對象,，必須現(xiàn)有系統(tǒng)架構(gòu)設(shè)計再有軟件架構(gòu)設(shè)計。定義了軟件的詳細設(shè)計,，描述了軟件單元,，每個軟件單元及其接口。
主要輸出：系統(tǒng)架構(gòu)設(shè)計說明文檔
SYS4 系統(tǒng)集成和集成測試
根據(jù)系統(tǒng)需求以及系統(tǒng)架構(gòu)設(shè)計進行系統(tǒng)集成測試用例的編寫,，然后進行系統(tǒng)集成測試,。屬于白盒測試。
主要輸出：系統(tǒng)集成測試用例/系統(tǒng)測試計劃/系統(tǒng)集成測試報告
SWE1 軟件需求分析
根據(jù)篩選后的系統(tǒng)需求進行軟件部分的需求分析,。
主要輸出：軟件需求Feature清單
SWE2 軟件架構(gòu)設(shè)計
目的是建立軟件架構(gòu)設(shè)計,，是被每條軟件按需求被分配到哪個軟件元素中，并按照已定義的標(biāo)準(zhǔn)評估軟件架構(gòu)設(shè)計
主要輸出：軟件架構(gòu)設(shè)計說明文檔
SWE3 軟件詳細設(shè)計與單元構(gòu)建
目的是為軟件單元提供一個已評估的詳細設(shè)計以實現(xiàn)軟件單元
主要輸出：軟件詳細設(shè)計說明文檔
SWE5 軟件集成與集成測試
制定了系統(tǒng)集成策略,，制定包括回歸測試在內(nèi)的集成測試策略,，形成測試計劃；選擇測試用例,，形成集成測試規(guī)范中的測試用例,；然后進行進行測試并形成系統(tǒng)集成測試結(jié)果
主要輸出：軟件集成測試計劃/軟件集成測試用例/軟件集成測試報告
SWE6 軟件合格性測試輸出
制定包括回歸測試策略在內(nèi)的軟件合格性測試策略；開發(fā)軟件合格性測試規(guī)范,；然后選擇測試用例,；測試集成軟件；總結(jié)和溝通結(jié)果：總結(jié)軟件合格性測試結(jié)果
主要輸出：軟件合格性測試報告
04 總結(jié)
一,，ASPICE流程的利弊
ASPICE是為了規(guī)范我們代碼開發(fā)流程,，同時提高我們的代碼質(zhì)量，嚴(yán)格做到在開發(fā)前有明確的開發(fā)方案,，明確的開發(fā)流程,，任何代碼的設(shè)計都有靠譜的依據(jù)來源，是我們代碼質(zhì)量的保證,。
簡單來講,，就是在保證代碼質(zhì)量的情況下，按時完成我們的項目目標(biāo),。如果僅僅是為了完成項目目標(biāo),，而對于我們完成的交付物不做最后的“估值”，那我認(rèn)為我們完成的這個任務(wù)沒有任何的意義,，因為它不被人們滿意的接受,。而完成這最后的“估值”就需要我們輸出的那些文檔作為支撐，我們通過這個文檔以及測試結(jié)果來進行驗收,，來判斷設(shè)計,，開發(fā)是否符合客戶的需求,，是否滿足于最初的項目目標(biāo)。
作為項目管理者來講,，我們更喜歡這個文檔按照標(biāo)準(zhǔn)輸出,，他更像我們與開發(fā)者之前溝通的橋梁,，通過這些文檔,，我們能知道開發(fā)者更加詳細的設(shè)計方案與想法。在溝通中會少了很多前期的溝通成本,。
可能針對開發(fā)人員來說,，遵頊這個流程的最大挑戰(zhàn)就是文檔的輸出，嚴(yán)格按照標(biāo)準(zhǔn)的ASPICE來進行項目開發(fā),，我們需要從上至下按照V模型進行,。即：先完成系統(tǒng)需求，系統(tǒng)架構(gòu)設(shè)計,，再完成軟件需求,，軟件架構(gòu)，軟件詳細設(shè)計,，最后才是代碼開發(fā)和測試,，而現(xiàn)實中的很多項目因為時間關(guān)系代碼開發(fā)和文檔編寫都是并行，這是不符合ASPICE的要求的,，并沒有很好的發(fā)揮ASPICE的優(yōu)點來把控我們的代碼質(zhì)量,。
而如果嚴(yán)格按照這個流程來執(zhí)行，在開發(fā)端的時間將會延長至少一倍,，對我們的人力成本也是一個很大的挑戰(zhàn),。ASPICE要求的設(shè)計文檔都需要相關(guān)的開發(fā)人員進行輸出，用程序員的話來講：寫這些文檔的時間比碼代碼的時間更長,，寫一個功能的開發(fā)文檔,，我可以完成至少3個同等功能的開發(fā)。
二,，ASPICE流程規(guī)范,，是否需要裁剪？
雖然ASPICE在我們項目開發(fā)過程中具有很好的指導(dǎo)作用,，但是否我們需要完全“死板”遵循,。前面已經(jīng)提到，我們的ASPICE流程雖然好,，但是需要的時間長,，人工成本高，針對任務(wù)重且周期短的項目是不友好的,。因此,，這個問題我的答案是：根據(jù)項目實際情況進行裁剪,。
在項目開發(fā)中，我們常常會參與或者組織項目階段總結(jié)會,。之前小鹿組織的一個項目總結(jié)會中,，很多工程師常常對項目的任務(wù)的優(yōu)先級有很大的疑惑：是先完成文檔設(shè)計工作還是先完成代碼交付工作？這種疑惑常發(fā)生在生命周期短的項目,，工程師常常同時被催促輸出文檔以及代碼,。標(biāo)準(zhǔn)的回答是：按照開發(fā)流程，是先完成文檔設(shè)計,，再做代碼開發(fā),，但是由于我們的時間緊張，因此他們同步進行,。在會上,，我們達成的統(tǒng)一目標(biāo)就是：充分使用，合理安排,，在滿足客戶的需求下,，對文檔的要求進行適當(dāng)?shù)牟眉簦诖藯l件之前,，按時按質(zhì)的完成項目目標(biāo),。
裁剪僅僅是為了將有限的時間安排在重要的事項中。針對生命周期長的項目,，可嚴(yán)格遵循,；針對生命周期短且任務(wù)重的項目，可做適當(dāng)?shù)牟眉?,，裁剪掉相對不重要的過程以及流程,，或者做并行處理。當(dāng)然根據(jù)實際情況實際評估,。
ASPICE是我們保證代碼質(zhì)量,，優(yōu)化代碼開發(fā)流程的工具，它可以指導(dǎo)我們做項目開發(fā),，但我們可以根據(jù)開發(fā)任務(wù)做裁剪,。實際情況實際分析哦！
更多信息可以來這里獲取==>>電子技術(shù)應(yīng)用-AET<<
