ASPICE
關注創建者：匿名 創建時間：2021-08-02
ASPICE的實例教程
要不要求ASPICE？這是個問題
主機廠
拿到供應商提交上來的軟件和100%通過率的測試報告，才跑幾個功能就發現一堆明顯的bug，發生甚么事了？難道是打開的方式不對？還是雙方對“測試通過率”這個概念的理解不同？——既然理解不同就用行業里大家都懂的語言ASPICE溝通吧，“SYS.2系統需求里的驗證準則是怎么定義的”、“SYS.5系統合規性測試中測試策略的要求都滿足了么”……
供應商
小伙伴們通宵加班總算是在期限之內把軟件交付給主機廠，就連頻繁變更的需求都實現了，這下金主爸爸總該滿意了吧。納尼??？這封味十足的郵件在challenge什么？ASPICE？我們在合同里承諾過么？想要馬兒跑就得給馬兒吃草，系統需求和軟件需求要分開、各種追溯性得建立鏈接、評審checklist都得用上……要做ASPICE都是實打實的工作量?。′N售，客戶既然提到了ASPICE，我們是不是該向他們多收點錢啊？
主機廠
還要加錢？確定驗證準則保證可測試性不是需求人員的本分么？保證所有功能在目標環境下正常運行不是開發人員的基本職責么？就算你們自己搞了ASPICE，找了技術背景不如自己靠著精通流程賺錢的咨詢公司來評估，最終搞出那一堆文檔真的能提升產品質量么？是，合同里是沒有寫ASPICE，但IATF16949總得認吧，最新版本里明確了嵌入式開發需要配套的軟件評估方法和質量保證流程，不用ASPICE的話，用的是哪一套呢？那家狼性文化的供應商過的就是ASPICE，還是三級！人家還用架構師來擔當SQA來保證質量，你們的SQA有多少年開發經驗？為啥別人能做到你們做不到？
展開 來源 | 智能汽車設計
開寫前先嘮兩句，只要與開發工程師多聊兩句，你就會很容易地發現，開發工程師幾乎是一邊倒的支持敏捷開發，筆者曾完整地參與過一次ASPICE認證項目，也在敏捷模式下進行過較長時間開發。從開發工程師的角度出發，使用敏捷進行開發的體驗吊打ASPICE(或者V模型)九條街，但我們今天討論的話題是哪種模式更適合“更快更高質量”地輸出產品，而不是哪個模式對工程師更友好。那么我們就來探討一下這兩種開發模式在域控時代的適應性。
當汽車電子電器架構還處于分布式的年代，ASPICE（或V模型）可以說是唯一的答案，就沒聽說過哪家Tier 1或者OEM是使用敏捷去開發一個發動機控制器的。到了域控時代，新的玩家入場，開發邏輯出現不同聲音，特斯拉，蔚小理等硅谷/互聯網背景出身的新玩家都使用敏捷進行開發，做出來的產品用戶體驗確實讓消費者有種“諾基亞轉安卓”的感覺，難道說敏捷就有如此大的魔力？可以給軟件賦予生命力？ASPICE和敏捷的差異和思路究竟在哪？
1. ASPICE：堂正之師
1.1.
展開 敏捷與ASPICE
前面講了很多“敏捷”的好處，但是在汽車行業“ASPICE”才是老大哥啊。本節就講講把這兩者放一起講講。
1. 敏捷與ASPICE可以結合嗎？
答案是：可以。行業中把這兩者結合起來用的不少，比如說Aptiv。但是，我要問一句，“為什么要結合呢”？
首先，來說為什么要用“ASPICE”？答案也很顯然，客戶爸爸們要求的啊。沒有ASPICE認證，很多OEM壓根就不會把項目給你。
然后，來說為什么要用“敏捷”？答案也很顯然，被客戶爸爸們逼的。沒事改需求，交付周期壓縮到巴不得明天就上等等，不“敏捷”怎么活？
那么，ASPICE和敏捷結合之后的結果是什么呢？在行業中，結果往往是敏捷主導著整個開發流程，ASPICE流于形式。因為，兩者從“價值觀”上就是沖突的。
了解ASPICE的人就該明白：
ASPICE更加注重文檔：這里的文檔泛指可被第三方檢查的證據。ASPICE Level1的認證就是根據你的文檔輸出(outcome)來倒推你是否有按Base Practice干的。如果你沒有這些，Level 1過不了。
ASPICE更加注重流程和計劃，GP(Generic Practice)2.1.1~2.1.6基本講的就是流程、計劃。如GP2.1.6里面寫明了：必須識別、準備、安排合適的資源來保證流程按計劃的進行。要知道，你想通過ASPICE Level 2的認證，GP2.1.1~2.1.6是必要條件。
另外，實行“敏捷”的一大好處就是“提高客戶滿意度”，你沒事就給客戶交點東西，讓他提意見，然后按他的意見改，他能不滿意嗎？在客戶滿意了之后，還要啥ASPICE啊？
2.
展開 03 敏捷與ASPICE
前面講了很多“敏捷”的好處，但是在汽車行業“ASPICE”才是老大哥啊。本節就講講把這兩者放一起講講。
1. 敏捷與ASPICE可以結合嗎？
答案是：可以。行業中把這兩者結合起來用的不少，比如說Aptiv。但是，我要問一句，“為什么要結合呢”？
首先，來說為什么要用“ASPICE”？答案也很顯然，客戶爸爸們要求的啊。沒有ASPICE認證，很多OEM壓根就不會把項目給你。
然后，來說為什么要用“敏捷”？答案也很顯然，被客戶爸爸們逼的。沒事改需求，交付周期壓縮到巴不得明天就上等等，不“敏捷”怎么活？
那么，ASPICE和敏捷結合之后的結果是什么呢？在行業中，結果往往是敏捷主導著整個開發流程，ASPICE流于形式。因為，兩者從“價值觀”上就是沖突的。
了解ASPICE的人就該明白：
ASPICE更加注重文檔：這里的文檔泛指可被第三方檢查的證據。ASPICE Level1的認證就是根據你的文檔輸出(outcome)來倒推你是否有按Base Practice干的。如果你沒有這些，Level 1過不了。
ASPICE更加注重流程和計劃，GP(Generic Practice)2.1.1~2.1.6基本講的就是流程、計劃。如GP2.1.6里面寫明了：必須識別、準備、安排合適的資源來保證流程按計劃的進行。要知道，你想通過ASPICE Level 2的認證，GP2.1.1~2.1.6是必要條件。
展開 經緯恒潤中心實驗室于2018年11月通過中國合格評定國家認可委員會（CNAS）的軟件測試能力擴項現場審核，依據ISO26262、GB/T 15532等相關測試標準建立了軟件測試體系，標志著經緯恒潤同時具備符合功能安全（ISO26262）和ASPICE的測試咨詢和測試服務能力。
ISO26262作為從IEC61508衍生出來的汽車行業電子電氣標準，站在電子系統和全生命周期的高度，統籌電子電氣系統的功能安全，以系統的方法，指導產品全生命周期的安全事項的實施。針對軟件單元測試，ISO26262標準的Part 6部分給出了具體要求說明，包括測試的前提條件、測試的要求、推薦測試方法、工作產品等。
ASPICE作為汽車行業軟件過程改進和能力測定是由SPICE發展而來。它將過程分成3個組別：主要生命周期過程、組織生命周期過程、支持生命周期過程。ASPICE中的工程過程主要由系統工程和軟件工程組成，我們依據"V"模型整理出ISO26262和ASPICE的映射關系，從而在軟件研發階段制定符合功能安全和ASPICE要求的解決方案。
針對單元測試我們將測試過程分為：測試策劃、測試設計與實現、測試執行、測試總結。
? 測試策劃階段對應功能安全9.4.1-9.4.3和ASPICE-SWE.4.BP1的要求。制定軟件單元驗證策略，包括軟件單元發生變更時重新驗證的回歸策略，并產出測試計劃作為工作成果。
? 測試設計與實現階段對照功能安全9.4.4等要求和ASPICE-SWE.4.BP2的要求，制定軟件單元驗證標準，編寫測試用例，并生成軟件測試說明書等工作成果。
展開 
ASPICE的相關專題、標簽、搜索
ASPICE的最新內容
以汽車電子為例，已助力眾多企業順利通過 ISO 26262 與 ASPICE 認證，加速智能座艙、自動駕駛軟件安全落地。
選擇 Parasoft，就是選擇更短的交付周期、更低的缺陷成本、更穩的系統質量、更輕松的合規路徑。
軟件定義世界，質量決定未來。Parasoft 以 AI 為翼，以合規為基，以全棧能力為盾，持續為企業研發提質增效。
基于行業廣泛認可的多重標準體系，如ASPICE、CMMI、ISO 26262、IATF 16949，為客戶量身打造符合其實際需求的車載軟件開發流程及供方管控標準和流程。
經緯恒潤測試團隊擁有豐富的研發經驗、嚴格的流程管控，依據ISO26262/ASPICE等開展符合要求的<a href="https://www.hirain.com/product/%E5%8D%95%E5%85%83%E9%9B%86%E6%88%90%E6%B5%8B%E8%AF%95%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88-527.html" rel="noopener
此外借助 ASPICE 過程管理的思維，在整個測試過程中加入過程管理思維，確保測試過程、測試環境、測試策略的可靠性以及測試用例的充分性、一致性、追溯性，以此確保模型質量。
如何優化軟件結構？
經緯恒潤憑借多年在汽車電子ASPICE、功能安全、信息安全等方面的豐富經驗積累，結合Codebeamer工具自身強大的需求、開發、測試、項目管理能力，已設計多套完整的行業模板，并為30多家汽車公司構建了落地的Codebeamer方案。
同時，經緯恒潤依托自研的開發測試工具鏈及對自動化測試的深度理解，已構建從代理、實施到二次開發的完整服務流程，能為客戶提供完整的ALM實施落地服務。
經緯恒潤測試團隊擁有豐富的研發經驗、嚴格的流程管控，依據ISO26262/ASPICE等開展符合要求的單元測試/集成測試工作。
在ISO 26262 - part 6部分產品開發：軟件層面，對軟件開發配置、軟件體系結構設計和軟件單元的設計和實現提出了具體的要求。
Codebeamer自身優勢
功能強大且易于使用
簡化法規遵從性
可伸縮的、集成的、企業級
Codebeamer核心能力
支持敏捷Agile和混合Hybrid開發模式
質量保證與測試，缺陷管理
需求管理
集成擴展(預配置)：ReqIF、DOORS、Enterprise Architect、MATLAB Simulink、Word/Excel(round-trip)
過程可見性：符合ASPICE
產品概述
Stages是美國UL Solutions旗下UL Method Park GmbH的產品，用于幫助企業定義、管理、發布、控制、優化其研發過程，同時使其研發過程符合CMMI、ASPICE、ISO26262等標準。Stages的核心理念是把過程理論和實際項目進行有機結合。
在滿足合規性的剛性需要下（比如：ASPICE，ISO26262，ASIL，能力成熟度模型集成CMMI等），實現軟件在環、模型在環、硬件在環，提高軟件復用顆粒度，保證產品質量并更快地進行交付，以滿足汽車客戶對汽車電子電氣軟件開發的需求，如下圖所示。
在滿足合規性的剛性需要下（比如：ASPICE，ISO26262，ASIL，能力成熟度模型集成CMMI等），實現軟件在環，模型在環，硬件在環，提高軟件復用顆粒度，保證產品質量、更快地進行交付，滿足汽車客戶對汽車軟件開發的需求，如圖17所示。
