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