汽車行業(yè)為何采用ASPICE V型開發(fā)，而不是敏捷開發(fā)？

電子設(shè)計(jì)聯(lián)盟 · 發(fā)表于 2024-11-19 08:01:00

點(diǎn)擊上方藍(lán)色字體，關(guān)注我們
關(guān)于這個(gè)問題主要聽到了兩種聲音：

一種視敏捷開發(fā)為豺狼虎豹，認(rèn)為敏捷開發(fā)就是“MMA”（無(wú)規(guī)則格斗），拋開一切規(guī)則擼起袖子使勁干，認(rèn)為使用敏捷開發(fā)的軟件都會(huì)存在嚴(yán)重的質(zhì)量問題，使用敏捷開發(fā)的公司都是草菅人命。

另一種聲音認(rèn)為單純的敏捷和現(xiàn)有的ASPICE都不完全適用域控開發(fā)，應(yīng)采用V+敏捷的進(jìn)行結(jié)合，創(chuàng)新地根據(jù)公司實(shí)際情況適配，既不能完全按敏捷一套快速迭代，也不能僅僅為了通過BP而找補(bǔ)文檔。

對(duì)于第一種聲音，我個(gè)人只能說尊重百花齊放的意見，歡迎繼續(xù)評(píng)論�？赡艽_實(shí)有MMA那樣的“敏捷開發(fā)”，但其實(shí)這種不叫敏捷，這種叫沒有開發(fā)流程。

還有動(dòng)不動(dòng)就說要ASPICE的，您真的過過審嗎？您知道里面的工作量有多少嗎？V可以，ASPICE？HELL NO！可能很多傳統(tǒng)汽車電子行業(yè)出身的工程師沒有真正使用過敏捷，這不是問題，怎么說呢，空杯心態(tài)很重要吧。

對(duì)于第二種聲音，本人舉雙手雙腳贊成�？梢园岩粋€(gè)scrum看成一次小V，也可以通過FFI的方式把功能和監(jiān)控分開成兩個(gè)小項(xiàng)目實(shí)施，以達(dá)到功能安全的要求，還有建議把what to do部分V化，How to do部分scrum化，這具體展開就涉及到各家拆招的能力了，沒有統(tǒng)一答案，主要看各家practice上的經(jīng)驗(yàn)了。

開寫前先嘮兩句，只要與開發(fā)工程師多聊兩句，你就會(huì)很容易地發(fā)現(xiàn)，開發(fā)工程師幾乎是一邊倒的支持敏捷開發(fā)，筆者曾完整地參與過一次ASPICE認(rèn)證項(xiàng)目，也在敏捷模式下進(jìn)行過較長(zhǎng)時(shí)間開發(fā)。

從開發(fā)工程師的角度出發(fā)，使用敏捷進(jìn)行開發(fā)的體驗(yàn)吊打ASPICE(或者V模型)九條街，但我們今天討論的話題是哪種模式更適合“更快更高質(zhì)量”地輸出產(chǎn)品，而不是哪個(gè)模式對(duì)工程師更友好。

那么我們就來探討一下這兩種開發(fā)模式在域控時(shí)代的適應(yīng)性。

當(dāng)汽車電子電器架構(gòu)還處于分布式的年代，ASPICE（或V模型）可以說是唯一的答案，就沒聽說過哪家Tier 1或者OEM是使用敏捷去開發(fā)一個(gè)發(fā)動(dòng)機(jī)控制器的。

到了域控時(shí)代，新的玩家入場(chǎng)，開發(fā)邏輯出現(xiàn)不同聲音，特斯拉，蔚小理等硅谷/互聯(lián)網(wǎng)背景出身的新玩家都使用敏捷進(jìn)行開發(fā)，做出來的產(chǎn)品用戶體驗(yàn)確實(shí)讓消費(fèi)者有種“諾基亞轉(zhuǎn)安卓”的感覺，難道說敏捷就有如此大的魔力？可以給軟件賦予生命力？ASPICE和敏捷的差異和思路究竟在哪？
1
ASPICE：堂正之師
1.1. 簡(jiǎn)述
ASPICE的核心思想就是DRIFT(Do things right in first time)。

ASPICE認(rèn)為：

軟件缺陷修復(fù)的成本是隨著軟件進(jìn)度的開展，成倍數(shù)級(jí)提升的，BUG越早發(fā)現(xiàn)，成本越低；

在關(guān)鍵控制器上（比如動(dòng)力總成的ECU），某些Bug可能是致命的（字面意義上的）且難以被發(fā)現(xiàn)的，因此，對(duì)代碼的態(tài)度必須慎之又慎；

傳統(tǒng)的合作關(guān)系上，通常是Tier1供控制器（Turn-key or Customer-sharing），OEM集成到車上，對(duì)于軟件這種無(wú)形的資產(chǎn)，又是閉源交付，OEM管控是很難的，唯一的監(jiān)管方式就是交付物，所以ASPICE既是開發(fā)過程，也是質(zhì)量證據(jù)。

因此，ASPICE講究走一條最康莊平坦的大道。

一份不偏離相關(guān)方（stakeholder）意圖的工程需求---->按照意圖，考慮所有corner case，基于選型芯片資源，設(shè)計(jì)考慮完備的軟件架構(gòu)---->將軟件架構(gòu)進(jìn)一步細(xì)化到模塊與函數(shù)級(jí)別的詳細(xì)設(shè)計(jì)---->與詳細(xì)設(shè)計(jì)思路一模一樣的編碼---->驗(yàn)證是否與詳細(xì)設(shè)計(jì)一致的單元測(cè)試---->驗(yàn)證是否與軟件架構(gòu)設(shè)計(jì)一致的集成測(cè)試---->驗(yàn)證是否與軟件需求一致的合格性測(cè)試。

說白了，就是：

V左半邊：保證每一行代碼都能知道是為哪一條需求服務(wù)的。

V右半邊：保證每一行代碼都在正確的實(shí)現(xiàn)每一條需求。

1.2. ASPICE的缺點(diǎn)
ASPICE統(tǒng)治了汽車軟件這么多年，自然有他的必要性與優(yōu)勢(shì)，但ASPICE的缺點(diǎn)也非常致命。

0 b& i. I) J' D2 z
1. 難以擁抱變化
從上文可以看出，一套V模型擼下來，都是一環(huán)套一環(huán)的，下一步的輸出完全依賴上一步的輸入，如果需求發(fā)生了變更，而且需求還是與原需求互斥的，那整個(gè)項(xiàng)目的改動(dòng)量將是災(zāi)難性的。

所以有些OEM的DRE可能會(huì)很疑惑，為什么看起來一個(gè)小小的CR（change request）發(fā)下去，會(huì)被Tier1告知一大筆的開發(fā)費(fèi)用，甚至是拒絕？流程可能就是其中一個(gè)原因。

只要代碼需要變更，好嘛，相應(yīng)的設(shè)計(jì)文檔作廢，重新設(shè)計(jì)，測(cè)試重新做……想想都頭疼。而國(guó)內(nèi)的項(xiàng)目氛圍又是“最愛”擁抱變化的，hmmm……

2. 對(duì)人力消耗巨大
我貼一下SWE.3（軟件詳細(xì)設(shè)計(jì)與單元開發(fā)）的BP出來給大家感受一下。

隨便說幾個(gè)工作量大到離譜的：

BP3：很多時(shí)候模塊間交互是很難窮盡描述的，特別是大型軟件，應(yīng)用層，或者高聚低耦做得沒那么好的模塊，在不同場(chǎng)景，不同條件下，都可能走不同邏輯，整個(gè)交互路徑都窮舉一遍是很難的，畫出來的seq圖也很難閱讀

BP5：每一步的流程都要求這個(gè)，做過的dddd（懂的都懂），有DOORS相對(duì)好點(diǎn)，用excel去管理這玩意就是個(gè)災(zāi)難，還感覺沒什么卵用

其實(shí)每個(gè)BP要求的工作量都很大，我做過大概的統(tǒng)計(jì)，執(zhí)行ASPICE的人力需求是不執(zhí)行的3倍，除此以外，就像我之前說的，這個(gè)流程既是開發(fā)流程，也是質(zhì)量證據(jù)，屬于監(jiān)管與被監(jiān)管的關(guān)系，繁重的文檔任務(wù)深深的打擊了工程師的積極性。
2
敏捷開發(fā)：短平快，擁抱變化
2.1. 簡(jiǎn)述

敏捷開發(fā)的核心邏輯是解構(gòu)，把軟件需求分解成Epic or story，通過一輪開發(fā)迭代（sprint）實(shí)現(xiàn)相應(yīng)的功能。

一輪sprint包含：需求確認(rèn)->方案制定->coding->臺(tái)架驗(yàn)證->實(shí)車驗(yàn)證->rolling candidate版本驗(yàn)證->代碼合入。

敏捷的優(yōu)點(diǎn)在于：

擁抱不確定性，發(fā)生需求變更，那就直接來一輪sprint，如果還不夠，那就來兩輪；

出活快，一個(gè)sprint的迭代以周為單位；

充分調(diào)動(dòng)工程師積極性，（相對(duì)）輕文檔，重代碼；

2.2. 敏捷的缺點(diǎn)
說完敏捷這枚硬幣的正面，下面說他的反面。

相比ASPICE或者V模型，敏捷少做的事情：

缺少統(tǒng)籌全局的進(jìn)行軟件架構(gòu)設(shè)計(jì)，導(dǎo)致模塊很難做到高類聚低耦合，比如Sprint A實(shí)現(xiàn)的一個(gè)功能，其底層模塊其實(shí)可以被Sprint B的某個(gè)功能部分復(fù)用，但由于Sprint A沒有考慮Sprint B的開發(fā)需求，所以該底層模塊并不能被完全復(fù)用，Sprint B可能就要重新開發(fā)一個(gè)底層模塊去覆蓋他自己的需求。多輪sprint下來，可能會(huì)有重復(fù)造相似輪子的情況出現(xiàn)。這樣會(huì)導(dǎo)致軟件比較臃腫，代碼量大，執(zhí)行效率低，且代碼質(zhì)量不高；

缺少集成測(cè)試，導(dǎo)致新加的功能可能對(duì)已實(shí)現(xiàn)的功能有潛在的影響而不能被發(fā)現(xiàn)；

由于短平快的特性，很多時(shí)候單元測(cè)試也不能充分進(jìn)行，比如動(dòng)態(tài)單元測(cè)試；

與FUSA的流程完全不兼容。ISO26262也好，ISO61508也好，ISO34590也好，都是植根于V模型，使用敏捷開發(fā)的軟件，很難滿足功能安全的開發(fā)要求，也無(wú)法做功能安全分析，無(wú)法做FFI。
[/ol]
3
誰(shuí)是自動(dòng)駕駛時(shí)代答案？
兩種開發(fā)流程各擅勝場(chǎng)，也有其出現(xiàn)的背景，在傳統(tǒng)汽車時(shí)代，各個(gè)控制器沒有花哨的功能，但要求軟件穩(wěn)定可靠，這種情況下，使用ASPICE或者V模型進(jìn)行開發(fā)無(wú)疑是非常正確的。

域控時(shí)代的來臨，最主要的變化有三點(diǎn)：

功能眾多：帶來的變化是軟件復(fù)雜度指數(shù)式上漲，相關(guān)方眾多；

產(chǎn)業(yè)鏈合作關(guān)系改變：從一功能一盒子，由Tier1軟硬件一起交付，OEM負(fù)責(zé)集成，到所有功能集中在域控，Tier1只提供底軟和硬件，應(yīng)用軟件由Tier1，Tier2，OEM聯(lián)合開發(fā)；

我的觀點(diǎn)是：ASPICE不適合用于開發(fā)智駕域控軟件，敏捷相對(duì)更合適，但必須根據(jù)汽車軟件的特點(diǎn)，進(jìn)行適配（一家之言，如果有使用ASPICE完整開發(fā)過智駕域控到SOP的經(jīng)驗(yàn)，非常非常歡迎留言探討）。

3.1. 為什么ASPICE不合適用于開發(fā)域控？
第一，ASPICE下對(duì)發(fā)生變更的代價(jià)是巨大的，因此需要一次把所有功能都定義，設(shè)計(jì)完美。

然而在域控這種軟件復(fù)雜度下，我不認(rèn)為有哪個(gè)人或者團(tuán)隊(duì)可以在項(xiàng)目開發(fā)初期，就能一次把所有的需求都定到完美。

不完美，后期增改功能，好嘛，又一輪完整的V迭代，所有文檔改掉，軟件配置管理做版本管理，恐怕需求沒開發(fā)完，工程師跑一大半了。

第二，退一萬(wàn)步講，就算有優(yōu)秀的產(chǎn)品團(tuán)隊(duì)可以一次把所有需求縷清，肯定也需要漫長(zhǎng)的時(shí)間，試想下，兩家公司同時(shí)開始項(xiàng)目，使用敏捷的小步快跑，不斷試錯(cuò)，都已經(jīng)有產(chǎn)品在投放市場(chǎng)了，使用ASPICE的可能還在需求制定階段……

3.2. 敏捷開發(fā)需要做什么適配？
敏捷開發(fā)需要克服的困難主要在于提升軟件質(zhì)量和滿足功能安全要求。

并不是用敏捷開發(fā)出來的軟件架構(gòu)就會(huì)松散，臃腫，而是敏捷的環(huán)境讓工程師更容易輸出這樣的結(jié)果。

所以我認(rèn)為以下措施的執(zhí)行能有效改善軟件質(zhì)量：

適當(dāng)延長(zhǎng)sprint周期；

嚴(yán)格的編碼規(guī)范與培訓(xùn)；

使用TDD（測(cè)試驅(qū)動(dòng)開發(fā)）思路

強(qiáng)大的devops能力作為技術(shù)保證；

引入自動(dòng)化單元檢查工具；

滿足功能安全要求，話只有一句，其實(shí)是個(gè)悖論，因?yàn)檐浖δ馨踩?V模型開發(fā)。

可能的一個(gè)解決方案，是利用ISO26262中FFI的思路，通過前期技術(shù)規(guī)劃，將軟件架構(gòu)分解成功能。

QM(D)和功能安全軟件D(D)，功能分區(qū)使用敏捷開發(fā)小步快走，功能安全分區(qū)還是按V模型進(jìn)行開發(fā)（思路是這么個(gè)思路，但做軟件安全分析和安全架構(gòu)設(shè)計(jì)需要非常小心，而且僅適用于safety goal為fail safe的域控，如果L4以上需要做fail operational的，又不能這么玩了）。