作者 | 不可說
出品 | 汽車電子與軟件
01 ASPICE介紹
ASPICE是Automotive SPICE的縮寫，是一種用於評估和(he)改(gai)進汽車軟件開發過程的國際(ji)標準；ASPICE定義(yi)了一組標準化(hua)的軟件開發過程和(he)最佳實踐，適用於整個軟件生命周(zhou)期，包括(kuo)需求工(gong)程、軟件設計、編碼、測試和(he)維(wei)護等各個領域(yu)。
通過規範(fan)化(hua)開發過程，ASPICE有助(zhu)於提高軟件產品的質量(liang)和(he)可維(wei)護性，確保軟件符合質量(liang)要求；同時對於開發者來講(jiang)，ASPICE的實施要求團隊具備一定的技能和(he)知識，這促進了團隊技能和(he)專(zhuan)業知識的提升，同時也(ye)促進了組織內的知識和(he)經(jing)驗的共(gong)享。
各家OEM與Tire1等可以去花費一定成本(ben)去做(zuo)ASPICE評審，以彰(zhang)顯自(zi)家公司對於軟件開發過程管(guan)理和(he)實施能力水平(ping)。
評審的等級(ji)是基於ISO/IEC 15504的能力成熟度模型，對汽車軟件開發過程的成熟度進行劃(hua)分的。
ASPICE評審等級(ji)通常(chang)劃(hua)分為以下六(liu)個等級(ji)，每個等級(ji)代表了不同的水平(ping)層次，目前行業內達到L1~L2的較多：
Level 0 - 未實施；
Level 1 - 執行；提供基本(ben)的項目管(guan)理和(he)開發活動，但缺乏係統(tong)的管(guan)理；
Level 2 - 管(guan)理了過程的執行；企業不僅能夠完成產品研(yan)發相(xiang)關工(gong)作，還能提前製定嚴謹和(he)周(zhou)全(quan)的工(gong)作計劃(hua)，確保各項目能夠有序進行；
Level 3 - 定義(yi)了過程的執行；軟件開發過程在組織範(fan)圍內得到了定義(yi)和(he)標準化(hua)，符合需求和(he)目標；
Level 4 - 量(liang)化(hua)了過程的執行；軟件開發過程的績效進行了量(liang)化(hua)，通過數據分析和(he)評估改(gai)進；
Level 5 - 優(you)化(hua)了過程的執行；軟件開發過程持續改(gai)進，並(bing)與組織的業務目標和(he)策(ce)略相(xiang)一致。
02 SWE介紹
ASPICE過程參考模型
作為汽車軟件開發工(gong)程師，應(ying)該了解並(bing)盡(jin)量(liang)遵循SWE過程，不僅有助(zhu)於提高軟件質量(liang)，還能夠降(jiang)低開發成本(ben)、縮短開發周(zhou)期，並(bing)增強軟件的可維(wei)護性和(he)可擴(kuo)展性。
ASPICE SWE（Software Engineering Process Group，軟件工(gong)程過程組）是ASPICE中的一個關鍵部分，它(ta)涵蓋了軟件開發的多個階段和(he)流程。SWE過程組的主(zhu)要目標是確保軟件開發過程中的各個階段都遵循最佳實踐，以提高軟件質量(liang)、減(jian)少(shao)開發風險，並(bing)滿足汽車行業的嚴格(ge)要求。
03 SWE.1
軟件需求分析；目的是建立(li)一套與係統(tong)需求和(he)係統(tong)架構一致的結構化(hua)和(he)分析的軟件需求。
對應(ying)這一部分的開發者，應(ying)該接收來自(zi)SYS.2、SYS.3的輸入，即係統(tong)需求和(he)係統(tong)架構設計。
需要完成六(liu)項BP（Base Practices 基礎實踐；ASPICE各項流程均定義(yi)了不同的BP，需要開發者遵守(shou)並(bing)完成）：
-
Specify software requirements. 定義(yi)軟件需求
-
Structure software requirements. 結構化(hua)軟件需求
-
Analyze software requirements. 分析軟件需求
-
Analyze the impact on the operating environment. 分析需求在操(cao)作環境中的影響
-
Ensure consistency and establish bidirectional traceability. 確保一致性和(he)雙向可追溯性
-
Communicate agreed system requirements and impact on the operating environment. 與利(li)益相(xiang)關者對係統(tong)需求及其(qi)影響溝通達成一致
舉例說明，以車身控(kong)製中外燈係統(tong)中的近光燈部分需求點為例，SWE1對應(ying)描述如下：
SW_REQ-10001 若(ruo)整車電源模式是ON，車輛應(ying)在打開近光燈開關被按下時打開近光燈；
SW_REQ-10002若(ruo)整車電源模式是ON，車輛應(ying)在關閉所(suo)有燈光被按下時關閉近光燈；
SW_REQ-10003車輛應(ying)為用戶(hu)提供信息（近光指示燈）以提示近光燈的工(gong)作狀態(tai)。
架構化(hua)需求及環境模塊影響分析：
04 SWE.2
軟件架構設計；目的是建立(li)一個與軟件需求一致的且(qie)分析過的軟件架構，包括(kuo)靜態(tai)和(he)動態(tai)方麵。
該過程的輸入既(ji)是來源於SWE.1。
5個BP說明如下：
-
Specify static aspects of the software architecture.定義(yi)靜態(tai)的軟件架構
-
Specify dynamic aspects of the software architecture. 定義(yi)動態(tai)的軟件架構
-
Analyze software architecture. 分析軟件架構
-
Ensure consistency and establish bidirectional traceability. 確保一致性並(bing)建立(li)雙向可追溯性
-
Communicate agreed software architecture. 溝通商(shang)定的係統(tong)架構
靜態(tai)架構示意：
定義(yi)軟件模塊的靜態(tai)信息，如接口名、信號名、模塊名等；
繼續以上述SW_REQ-10001~ SW_REQ-10003需求為例
動態(tai)架構示意：重(zhong)點在於模塊的動態(tai)交互(hu)、時序等邏輯體(ti)現
05 SWE.3
軟件詳細(xi)設計和(he)單元構建；目的是建立(li)與軟件體(ti)係結構一致的軟件詳細(xi)設計，包括(kuo)靜態(tai)和(he)動態(tai)方麵，並(bing)構建與軟件詳細(xi)設計一致的軟件單元。
輸入來源於SWE.1與SWE.2；
同樣包含5個BP：
-
Specify the static aspects of the detailed design. 定義(yi)軟件詳細(xi)配置
-
Specify dynamic aspects of the detailed design. 定義(yi)軟件詳細(xi)模塊交互(hu)
-
Develop software units. 開發並(bing)配置模塊單元
-
Ensure consistency and establish bidirectional traceability. 確保一致性並(bing)建立(li)雙向可追溯性
-
Communicate agreed software detailed design and developed software units. 溝通商(shang)定的軟件詳細(xi)設計和(he)開發的軟件單元
這一環節(jie)是對軟件架構設計中的SW Component的進一步設計，同樣的也(ye)包含了動態(tai)詳細(xi)設計與靜態(tai)詳細(xi)設計兩個方麵；通常(chang)需要識別(bie)出SWE.2環節(jie)中設定的軟件模塊SWC中包含哪(na)些(xie)子模塊，不過，在通常(chang)的正向開發過程中，SWE.2執行過程已(yi)經(jing)完成這一步分析，如LoBeam SWC中包含了SW unit：電源判(pan)斷模塊 與 SW unit：燈光判(pan)斷模塊兩個軟件子模塊；
對SW uint進行更(geng)詳細(xi)的設計：定義(yi)操(cao)作函數、設定或理解交互(hu)接口；
如果涉及到複雜(za)的數據類(lei)型或者算法，也(ye)需要在這個環節(jie)完成；
06 SWE.4
軟件單元驗證；目的是驗證軟件單元是否與軟件詳細(xi)設計一致，提供證據證明軟件單元符合軟件詳細(xi)設計和(he)非功能軟件需求；
該流程含有5個BP：
-
Specify software unit verification measures. 規定軟件單元驗證措施
-
Select software unit verification measures. 選(xuan)擇軟件單元驗證措施
-
Verify software units. 驗證軟件單元
-
Ensure consistency and establish bidirectional traceability. 確保一致性，建立(li)雙向可追溯性
-
Summarize and communicate results. 總結並(bing)交流結果
所(suo)要驗證的對象來自(zi)於SWE.3的輸出；
根據BP，實際(ji)操(cao)作流程可以如下：
-
收齊輸入物（被測模型/代碼），即SWE.1需求，與SWE.3代碼/模型
-
搭(da)建測試環境
在代碼模型裏(li)模擬輸入，觀測輸出；如在代碼simulink模型中搭(da)建測試module；
3. 導入測試用例
首先要製定測試用例，以SWE.3中的模塊為例，製定測試case；
4. 執行測試
按照測試case執行測試代碼+功能代碼，記錄測試結果；
5. 針對測試結果及覆蓋度結果補充(chong)測試用例
分析測試結果，同步的檢查測試用例製定的完整性
6. 回歸測試
反饋測試NG項，待代碼修改(gai)後回歸測試
完整的流程過程物/輸出物應(ying)該還包含詳細(xi)的測試計劃(hua)、測試報(bao)告分析等內容。
07 SWE.5
軟件組件驗證和(he)集成驗證；這一環節(jie)目的是驗證軟件組件與軟件架構設計一致，並(bing)集成軟件元素(su)，驗證集成的軟件元素(su)與軟件架構和(he)軟件詳細(xi)設計一致
該流程含有7個BP：
BP1: Specify software integration verification measures 指定軟件集成驗證措施
BP2: Specify verification measures for verifying software component behavior 指定驗證軟件組件行為的驗證措施
BP3: Select verification measures 選(xuan)擇驗證措施
BP4: Integrate software elements and perform integration verification 集成軟件元素(su)並(bing)執行集成驗證
BP5: Perform software component verification 執行軟件組件驗證
BP6: Ensure consistency and establish bidirectional traceability 確保一致性並(bing)建立(li)雙向可追溯性
BP7: Summarize and communicate results 總結和(he)交流結果
SWE.4與SWE.5均是做(zuo)軟件驗證，區別(bie)就是範(fan)圍不一樣，SWE.4側重(zhong)於單個軟件單元的驗證，確保單元的正確性和(he)質量(liang)；而SWE.5則(ze)關注於軟件組件的集成和(he)整體(ti)係統(tong)的測試，確保係統(tong)能夠正確運行並(bing)滿足需求。
SWE.5參考流程
SWE.5的關鍵輸入即是SWE.2中的輸出物--軟件架構；軟件集成後，按照SWE.2中SWC模塊逐步進行測試即可；測試過程與相(xiang)關過程物類(lei)型與SWE.4接近，此處不再舉例。
08 SWE.6
軟件驗證；確保集成的軟件與軟件需求一致，也(ye)叫軟件合格(ge)性測試
該流程含有5個BP：
BP1: Specify verification measures for software verification 規定軟件驗證的驗證措施
BP2: Select verification measures 選(xuan)擇驗證措施
BP3: Verify the integrated software 驗證集成軟件
BP4: Ensure consistency and establish bidirectional traceability 確保一致性並(bing)建立(li)雙向可追溯性。
BP5: Summarize and communicate results 總結並(bing)溝通結果
該環節(jie)的輸入主(zhu)要來源於上級(ji)SYS.1中的係統(tong)需求與SWE.1中的軟件需求；
SWE.6與SWE.4、SWE.5同屬測試範(fan)疇，為了更(geng)好的區分，特(te)意做(zuo)出如下對比：
SWE.6參考執行流程
以SWE.1中軟件需求SW_REQ-10001為例，驗證用例和(he)測試結果記錄表格(ge)可參考如下：
09 總結
遵循ASPICE開發流程，既(ji)要有專(zhuan)業化(hua)知識，還要有標準化(hua)流程，專(zhuan)業化(hua)知識包含了專(zhuan)業的汽車電子技術、編程能力、專(zhuan)業工(gong)具使用能力等；標準化(hua)流程即是各家主(zhu)機廠(chang)或者供應(ying)商(shang)根據ASPICE流程製定各家專(zhuan)屬的開發流程及各個流程對應(ying)產出物；
有一點貫穿整個軟件開發過程，並(bing)且(qie)在評審過程中也(ye)會相(xiang)當注重(zhong)的，就是追溯性；
雙向追溯
1)V模型左邊的需求、設計和(he)實現之間
2)V模型左邊的需求設計實現與V模型右邊的測試規範(fan)（或測試用例）之間
3)測試用例與測試結果之間
4)變(bian)更(geng)與變(bian)更(geng)影響的工(gong)作產品之間
因此，除了功能實現，體(ti)現追溯性的各環節(jie)文檔(dang)與工(gong)具等要做(zuo)好記錄與管(guan)控(kong)，實現符合ASPICE流程的標準化(hua)開發。
