ASPICE的案例
舍與得——主機廠與供應商的ASPICE博弈
要不要求ASPICE？這是個問題
主機廠
拿到供應商提交上來的軟件和100%通過率的測試報告，才跑幾個功能就發現一堆明顯的bug，發生甚么事了？難道是打開的方式不對？還是雙方對“測試通過率”這個概念的理解不同？——既然理解不同就用行業里大家都懂的語言ASPICE溝通吧，“SYS.2系統需求里的驗證準則是怎么定義的”、“SYS.5系統合規性測試中測試策略的要求都滿足了么”……
供應商
小伙伴們通宵加班總算是在期限之內把軟件交付給主機廠，就連頻繁變更的需求都實現了，這下金主爸爸總該滿意了吧。納尼！？這封味十足的郵件在challenge什么？ASPICE？我們在合同里承諾過么？想要馬兒跑就得給馬兒吃草，系統需求和軟件需求要分開、各種追溯性得建立鏈接、評審checklist都得用上……要做ASPICE都是實打實的工作量啊！銷售，客戶既然提到了ASPICE，我們是不是該向他們多收點錢啊？
主機廠
還要加錢？確定驗證準則保證可測試性不是需求人員的本分么？保證所有功能在目標環境下正常運行不是開發人員的基本職責么？就算你們自己搞了ASPICE，找了技術背景不如自己靠著精通流程賺錢的咨詢公司來評估，最終搞出那一堆文檔真的能提升產品質量么？是，合同里是沒有寫ASPICE，但IATF16949總得認吧，最新版本里明確了嵌入式開發需要配套的軟件評估方法和質量保證流程，不用ASPICE的話，用的是哪一套呢？那家狼性文化的供應商過的就是ASPICE，還是三級！人家還用架構師來擔當SQA來保證質量，你們的SQA有多少年開發經驗？為啥別人能做到你們做不到？
展開 ASPICE vs Agile，誰是自動駕駛時代答案？
來源 | 智能汽車設計
開寫前先嘮兩句，只要與開發工程師多聊兩句，你就會很容易地發現，開發工程師幾乎是一邊倒的支持敏捷開發，筆者曾完整地參與過一次ASPICE認證項目，也在敏捷模式下進行過較長時間開發。從開發工程師的角度出發，使用敏捷進行開發的體驗吊打ASPICE(或者V模型)九條街，但我們今天討論的話題是哪種模式更適合“更快更高質量”地輸出產品，而不是哪個模式對工程師更友好。那么我們就來探討一下這兩種開發模式在域控時代的適應性。
當汽車電子電器架構還處于分布式的年代，ASPICE（或V模型）可以說是唯一的答案，就沒聽說過哪家Tier 1或者OEM是使用敏捷去開發一個發動機控制器的。到了域控時代，新的玩家入場，開發邏輯出現不同聲音，特斯拉，蔚小理等硅谷/互聯網背景出身的新玩家都使用敏捷進行開發，做出來的產品用戶體驗確實讓消費者有種“諾基亞轉安卓”的感覺，難道說敏捷就有如此大的魔力？可以給軟件賦予生命力？ASPICE和敏捷的差異和思路究竟在哪？
1. ASPICE：堂正之師
1.1.
展開 敏捷與ASPICE：SDV趨勢下軟件研發體系的挑戰與思考
敏捷與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.
展開 敏捷與ASPICE：SDV趨勢下軟件研發體系的挑戰與思考
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是必要條件。
展開 
在線研討會預熱 | 基于ASPICE&CNAS的單元測試介紹
經緯恒潤中心實驗室于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 流程標準
的車載電控單元正向開發研究
ASPICE 是汽車行業軟件開發的流程標準， 可用于提高車載電控單元的研發質量；文章基于 ASPICE 流程 框架， 結合實際研發項目及 ASPICE L2 等級認證過程的經驗， 闡述了正向開發過程中各層級交付物的界定及追溯 關系， 并給出設計實例， 說明了正向開發過程中軟、 硬件設計交付物的承接關系。
隨著我國汽車自主品牌的發展， 車載電控單元的自主研 發成為主機廠的關鍵技術之一。為確保電控單元軟、 硬件產 品的設計質量， 產品的正向開發流程越來越受到國內廠商的 重視。
ASPICE 作為汽車行業內軟件開發的流程標準， 較 CMMI 更適合汽車行業的軟件開發 [1] ， 難點在于研發實踐中， 如何對不同層級的交付物進行界定， 如何建立需求與設計的追溯關系， 以及如何梳理軟件設計與硬件設計的承接關系。
另一方面， 在正向開發過程中， 如何將整車功能需求分 解到零部件的設計要求中， 也是業內探討的熱點， 有研究人 員指出：零件之間構成的整車系統的功能實現、 場景描述有 限， 更缺少部分性能指標的定義 [2] 。
注：本圖與文無關，文章轉摘自2020年設計研究，作者廣汽研究院曾備，僅供學習參考！
綜上所述， ASPICE 標準中要求的系統開發流程（SYS）及軟件開發流程（SWE） 可對應到車載電控單元零部件級別 （L3）、 組件級別（L4） 及模塊級別（L5） 的交付物。各層 級的架構設計文檔， 對上層的設計需求進行了分解， 并根據 下層的接口關系進行功能的分配， 進而建立了上下層級設計 需求的追溯關系。
展開 關于 ASPICE 的理解
5.關于系統開發
有點懶，就直接摘錄了，此處與本人開發過程相關，摘錄參考《? VDA Quality Management Center》
SYS.1 需求挖掘
SYS.2 系統需求分析
SYS.4 系統集成與集成測試
SYS.5 系統合格性測試
6.關于軟件開發
有點懶，就直接摘錄了，此處與本人開發過程相關，摘錄參考《? VDA Quality Management Center》
SWE.1 軟件需求分析
SWE.2 軟件架構設計
SWE.3 軟件詳細設計和單元構建
SWE.4 軟件單元驗證
SWE.5 軟件集成和集成測試
SWE.6 軟件合格性測試
7.ASPICE認證的典型問題
1、為了管理各個工作產品，以及支持ASPICE過程，一般都需要有相關的工具作為支持，典型如ALM工具；
2、ASPICE提供了各個WP的要求，但是并沒有提供模板，一般認證機構會提供相應的模板；
3、針對每個過程，評估師如何打分？這個依賴對應的評估師，一般評估師會提前提要求；
4、ASPICE過程與功能安全過程基本類似，一般經過ASPICE認證后，能滿足功能安全要求。
展開 守好軟件定義汽車下的質量之門
▎基于CMMI/ASPICE3.1的認證咨詢服務
目前，國內外多數OEM和Tier1在按照CMMI/ASPICE梳理、優化現有的軟件產品研發過程，并根據差距分析結果進行過程改進，確保“過程”既適合當前研發現狀又滿足更高的質量和效率要求。隨著過程質量管控進一步提升，OEM和Tier1也在逐步要求供應商按照CMMI/ASPICE的過程模型進行軟件產品的研發。
針對市場需求，經緯恒潤提供基于CMMI和ASPICE的認證咨詢服務，涵蓋了定義企業級的研發過程、定義各過程的規程/規范/模板/檢查單/指南、建立/評估工具鏈等。經緯恒潤基于客戶現有研發流程，通過定制化的方式完成上述的咨詢服務。同時，協助客戶通過相應認證或評估工作。經緯恒潤憑借多年的行業經驗，成功為20余家企業提供過程能力改進服務，并協助客戶順利通過ASPICE/CMMI級別認證。
▎車載軟件開發服務
汽車電子軟件主要是應用軟件和底層軟件。應用軟件開發的難點主要是在AUTOSAR架構下劃分合理的SWC，并通過MBD的方式進行軟件開發和測試，最后完成復雜的應用層軟件和底層軟件集成工作。經緯恒潤在提供AUTOSAR基礎軟件的同時也在新能源整車控制、電池管理系統、整車能量管理、車身電子控制系統等多個領域，為整車廠和供應商提供控制器應用層開發和系統集成服務，并協助客戶完成控制器交付和量產。
目前，經緯恒潤已成功為吉利、泛亞、寧德時代等多家公司提供了覆蓋HCU、VMM、BMS等領域的應用層軟件開發服務。
▎車載軟件測試服務
在軟件功能實現的過程中，不同模塊、不同層次之間的信息基于軟件接口進行傳遞，因此，軟件接口的可靠性決定了相應功能是否正常實現。
展開 直播內容搶先看 | 符合安全要求的軟件測試解決方案
基于CNAS實驗室，參考ASPICE、ISO26262、ISO21434等標準，使用HelixQAC、Tessy、DefenseCode、AbsInt、RVS、Symtavision、Mx-Suite、TAE等工具開展：
?? HelixQAC、Abslnt、Symtavision
滿足功能安全、ASPICE要求的靜態分析
?? TESSY、Rapita Systems
滿足功能安全、ASPICE要求的單元和集成動態測試
?? INTEWORK-TAE、Mx-Suite
滿足功能安全、ASPICE要求的HIL測試
?? DefenseCode
滿足ISO21434要求的信息安全測試
持續集成平臺
ET-ci提供了編譯-測試-發布解決方案，使得開發、測試團隊在軟件開發、測試和交付生命周期中對研發過程進行可視化管理，幫助軟件開發組、測試組輕松、高效地完成復雜的軟件項目，縮短軟件的整體測試周期和研發周期。
欲了解更多相關信息，請點擊“本鏈接”報名參加11月18日-19日云技術研討會 | 合作、高效--下一代汽車電子軟件開發與測試論壇，期待您的參與！
展開 單元測試階段的測試工作量自動預估
編者按：為提高軟件開發管理能力，OEM和零部件供應商對ASPICE關注和認可程度越來越高，ASPICE的落地成為大家亟需解決的要點。那么在ASPICE中，如何合理估算單元測試階段工作量和迭代更新WBS呢？單元測試工具Tessy日前宣布，在其新版本中加入了自動預估測試工作量的功能。該功能可應用在ASPICE MAN.3.BP4及MAN.3.BP5中，讓單元測試階段的時間安排更有說服力。此文章來源于Tessy原廠于1月底發布的軟件新功能說明《Hitex_TESSY4_2_Evaluation test effort》。
圖 預估測試工作耗時（ET），實際工作耗時（AT）
自動預估測試工作量是Tessy V4.2的新功能。以測試對象的多個度量值作為該計算公式的元素，用戶可以根據自身情況來調整此公式。例如通過更改/增加因子或加數。Tessy4.2版本新增語句數、調用統計和深度這三個度量元的統計，加上原有的度量元如圈復雜度等，均可在公式中靈活應用。Tessy新版本所提供的總測試工作量的初始預估這一功能的重要性，在包含大量測試對象的大型測試項目中將得到充分的體現。
此外，Tessy4.2同時提供統計實際測試時間的方式，通過實際工作耗時與預估耗時的自動比對，對測試耗時進行科學評估（紅色表示遠超預估時間，黃色表示略超預估時間，綠色表示在預估時間之內完成測試工作）。當然，Tessy也提供了實際工作耗時與預估工作耗時比對的上下閾值的設定，滿足用戶的個性化使用需求。
經緯恒潤
北京市海淀區知春路7號致真大廈D座6層
郵箱：market_dept@hirain.com
網址：www.hirain.com
展開 11月18-19日云端見 | 合作 · 高效—下一代汽車電子軟件開發與測試論壇
ASPICE Provisional Assessor，INCOSE ASEP，主要從事需求工程、MBSE、ASPICE過程改進相關研究和項目實施工作。負責系統工程相關過程、方法、工具在國內的推廣工作。
李琪
經緯恒潤軟件開發部經理助理。電子科技大學控制工程碩士，具有豐富的持續集成平臺開發以及搭建經驗。熟悉Jenkins等多款持續集成工具，掌握多種汽車行業相關工具的集成方法，承擔過國內多家知名汽車企業的持續集成&持續交付平臺的開發和搭建。
呂美
經緯恒潤電子系統部經理。浙江大學&伯明翰大學雙碩士，ASPICE Provisional Assessor，功能安全認證工程師，具備內外部功能安全項目經驗，有豐富的整車網絡時間性能分析及優化項目經驗、控制器資源/性能分析項目經驗。
王淼
經緯恒潤測試工具部經理。10年車載軟件測試經驗，負責各整車廠及其各級供應商的代碼級自動化測試工具的推廣和實施。擅長軟件靜態分析和軟件動態測試，對MISRA編碼規范、代碼級信息安全要求等有著深入的見解。
展開 
Stages — 研發過程可視化建模和管理平臺
大陸汽車集團使用Stages建立了一個動態的研發過程，并進行持續的過程改進，確保過程信息能快速、清晰、及時地傳遞給所有項目成員，并且使研發過程符合ISO26262和ASPICE 等標準。
此外，GM、Audi、BOSCH、TRW 、Johnson Controls、Siemens、Webasto等都使用Stages進行汽車電子產品過程建模和流程發布。
Stages—研發過程可視化建模和管理平臺
大陸汽車集團使用Stages建立了一個動態的研發過程，并進行持續的過程改進，確保過程信息能快速、清晰、及時地傳遞給所有項目成員，并且使研發過程符合ISO26262和ASPICE等標準。
此外，Audi、BOSCH、TRW、Johnson Controls、Siemens、Webasto等都使用Stages進行汽車電子產品過程建模和流程發布。
Stages — 研發過程可視化建模和管理平臺
大陸汽車集團使用Stages建立了一個動態的研發過程，并進行持續的過程改進，保證過程信息能快速、清晰、及時地傳遞給項目成員，并且使研發過程符合ISO26262和ASPICE等標準。
此外，GM、Audi、BOSCH、TRW 、Johnson Controls、Siemens、Webasto等使用Stages進行汽車電子產品過程建模和流程發布。
經緯恒潤
北京市海淀區知春路7號致真大廈D座6層
郵箱：market_dept@hirain.com
網址：www.hirain.com
3月19日在線研討會預熱 | Stages — 研發過程可視化建模和管理平臺
大陸汽車集團使用Stages建立了一個動態的研發過程，并進行持續的過程改進，過程信息能快速、清晰、及時地傳遞給項目成員，并且使研發過程符合ISO26262和ASPICE等標準。
此外，GM、Audi、BOSCH、TRW 、Johnson Controls、Siemens、Webasto等使用Stages進行汽車電子產品過程建模和流程發布。
經緯恒潤
北京市海淀區知春路7號致真大廈D座6層
郵箱：market_dept@hirain.com
網址：www.hirain.com
