汽車行業(yè)的軟件開發(fā)標(biāo)準(zhǔn),最著名的應(yīng)該是V模型。以V模型為代表的有ASPICE、 ISO 26262 和 ISO/SAE 21434。今天我們主要以ASPICE為基礎(chǔ),探討V模型在當(dāng)前汽車軟件變革時(shí)代的特點(diǎn)。
傳統(tǒng)的V模型標(biāo)準(zhǔn)在當(dāng)前這個(gè)階段,有點(diǎn)使不上勁兒。
這個(gè)要怎么理解呢?首先我們要明確ASPICE的一個(gè)特點(diǎn)。ASPICE標(biāo)準(zhǔn)采用的是一種“命題提綱”式的寫法。十幾年了,還在使用,并且我們一直沒有聽說,有什么大的錯(cuò)誤,因?yàn)閷懙米銐驅(qū)挿骸?/p>
我們舉幾個(gè)例子。在 ASPICE 的供應(yīng)商監(jiān)控部分,他寫了 5 條BP,分別是:
第一個(gè)BP是,要和供應(yīng)商之間達(dá)成并且維護(hù)一個(gè)聯(lián)合開發(fā)的措施或接口,使得信息可以進(jìn)行交換(至于聯(lián)合的過程,或者接口應(yīng)該是什么樣的,在ASPICE 里面并沒有進(jìn)行描述)。
第二個(gè) BP 是,交換所有經(jīng)過雙方同意的信息。
第三個(gè)BP是,和供應(yīng)商一起評(píng)審技術(shù)開發(fā)過程。
第四個(gè) BP 是,評(píng)審供應(yīng)商的進(jìn)度。
第五個(gè) BP 是。對(duì)偏差有所行動(dòng)。
可以看到,這些BP,實(shí)際上是一種非常寬泛的行為描述。至于這個(gè)行為應(yīng)該怎么做,在標(biāo)準(zhǔn)里面是沒有體現(xiàn)的。
所以ASPICE的標(biāo)準(zhǔn),有非常大的靈活度去進(jìn)行解讀。這也是為什么,在十幾年的過程中,它一直沒有什么大的錯(cuò)誤的原因。它所說的這些過程,其實(shí)是一個(gè)正常的產(chǎn)品開發(fā)或者項(xiàng)目管理的通用過程。但是在當(dāng)前這個(gè)汽車軟件變革的階段,我們需要的是,標(biāo)準(zhǔn)告訴我們?cè)趺醋觯辉偈墙o我們一個(gè)命題作文。
從傳統(tǒng)汽車向智能網(wǎng)聯(lián)汽車轉(zhuǎn)型的時(shí)代,所有人對(duì)這種新模式,都是處在一個(gè)探索的過程。這種探索既包括軟件供應(yīng)商,還有主機(jī)廠。如果ASPICE真是一劑神藥,那標(biāo)準(zhǔn)的制訂方之一,德國大眾的新車,就不至于在停車場(chǎng)趴窩幾個(gè)月了。
所以,這就是我的結(jié)論:傳統(tǒng)的V模型開發(fā)標(biāo)準(zhǔn),在當(dāng)前這個(gè)階段使不上勁兒,單純的命題作文,在這個(gè)階段不奏效,還需要實(shí)際的解題方法。
在當(dāng)前這個(gè)階段,越來越多的主機(jī)廠和新勢(shì)力,采取了另外一種開發(fā)模式,敏捷開發(fā)。
敏捷開發(fā)尚未形成一個(gè)標(biāo)準(zhǔn),而只是一些思想、工具和實(shí)踐。敏捷開發(fā),更多的好像是一個(gè)非常優(yōu)秀的“考生”,寫的一份備考指南,里面講到了很多方法。這個(gè)考生上來就說:你不要想著一次就把事情做對(duì)、做完(因?yàn)槭虑樘珡?fù)雜了),你先去做就好了,做出一個(gè)原型,通過快速驗(yàn)證,你很快就能發(fā)現(xiàn)其中的問題,再去改,保證你的每一次,都比上次做得好,而且你的每一次,都是當(dāng)前這個(gè)階段最想要的。然后他開始告訴你,這個(gè)過程中,你的武器庫里面有多少武器可以使用,比如敏捷看板、需求優(yōu)先級(jí)的排序、敏捷報(bào)表、功能回顧會(huì)、每日站會(huì)等等。正是由于這位“考生”寫作的出發(fā)點(diǎn),導(dǎo)致了很多爭議。因?yàn)槲覀冎?,同樣一份考卷,同樣一個(gè)應(yīng)用題,不同的人去做,可以采用不同的方法,并且大家都能夠做對(duì)。這就像,市面上有黃岡老師的答題技巧,也有人大附中的答題技巧,但是高考出題提綱只有一份。
敏捷開發(fā)這套思想的推動(dòng)者,最開始并沒有太大野心。他們想做的只是告訴程序員,告訴項(xiàng)目管理者,怎樣去管理一個(gè)項(xiàng)目,怎樣在不同的角色之間進(jìn)行協(xié)作。它沒有對(duì)行業(yè)做什么要求,它也并不是針對(duì)汽車行業(yè)的。所以這樣的一種方法,在被汽車行業(yè)運(yùn)用的時(shí)候,必然會(huì)產(chǎn)生很多的爭論。
我之前也寫過了一篇文章《ASPICE 還值得做嗎?》,從評(píng)論中也可以看得出來,敏捷開發(fā)在汽車行業(yè)充滿了爭論。有些人對(duì)敏捷開發(fā)保持了冷嘲熱諷的態(tài)度。實(shí)際上包括特斯拉以及國內(nèi)的造車新勢(shì)力,基本上都在采用一種小步快跑,持續(xù)迭代的的方式來做軟件開發(fā)。特斯拉的FSD功能,在已交付的車輛上,以肉眼可見的速度進(jìn)化和升級(jí)。當(dāng)汽車行業(yè)很多頭部企業(yè),都已經(jīng)在或多或少嘗試敏捷開發(fā)的思想時(shí),還有一些人仍然停留在自己的看法里。
當(dāng)然,我們不得不承認(rèn)的一個(gè)事實(shí)是,敏捷開發(fā)在汽車行業(yè)尚未得到大規(guī)模的認(rèn)可,我覺得這個(gè)也很正常,當(dāng)前汽車行業(yè)正在進(jìn)行一場(chǎng)變革,在變革的過程中肯定是百家爭鳴,大家都有各自方式。而且也未形成變革后的統(tǒng)一標(biāo)準(zhǔn),在這個(gè)時(shí)候產(chǎn)生比較多的爭論,是有益于行業(yè)進(jìn)步的。
今天文章的主題,我想預(yù)測(cè)一下,汽車行業(yè)的軟件開發(fā)標(biāo)準(zhǔn),將向一個(gè)什么樣的方向進(jìn)行演進(jìn)。
我預(yù)測(cè)的第一點(diǎn)是,V模型將吸納敏捷開發(fā)的特點(diǎn),形成新的標(biāo)準(zhǔn)。
雖然敏捷開發(fā)并未形成汽車行業(yè)的標(biāo)準(zhǔn),但卻有非常多的團(tuán)隊(duì)以此種方法來進(jìn)行實(shí)踐。
有很多公司找我們咨詢汽車行業(yè)敏捷開發(fā)相關(guān)的工具鏈,我們發(fā)現(xiàn)他們或多或少都已經(jīng)開始使用敏捷項(xiàng)目管理工具。業(yè)界對(duì)這種趨勢(shì)應(yīng)該有更加明顯的感受。
在汽車行業(yè)新的軟件標(biāo)準(zhǔn)中,我預(yù)計(jì),一定會(huì)是接納并且認(rèn)可小步快跑、持續(xù)迭代這樣一種思想的。V模型也不應(yīng)該簡單地被看作是瀑布流。V模型的編寫方式,并未提到它是一個(gè)瀑布流。但是我們從它上下文的行文中,很容易把它理解成一個(gè)瀑布流。比如,在我們做軟件架構(gòu)設(shè)計(jì)的時(shí)候,一定是對(duì)軟件需求分析已經(jīng)經(jīng)過了大量的討論,經(jīng)過了大家的認(rèn)可,但是并未提到,如果需求本身不全會(huì)怎樣?如果需求沒有理清楚,沒有經(jīng)過充分的討論,我們是否能夠去做架構(gòu)方面的設(shè)計(jì)?是否可以并行?需求是逐漸完善的過程、架構(gòu)也是逐漸完善的過程,在完善的過程中,再逐漸去建立追溯性,是否可行?
變更在開發(fā)過程中,是不可避免的,但在ASPICE中,變更管理是一個(gè)支持性流程,好像變更并不是在每個(gè)過程中進(jìn)行的,而像是項(xiàng)目做到一定階段之后,反過來進(jìn)行的、偶爾的偏差改動(dòng)。但實(shí)際上,變更管理應(yīng)該被提到一個(gè)更重要、更頻繁的位置,因?yàn)樵谄囎兏锏倪^程中,我們所做的很多技術(shù)和產(chǎn)品,不確定性是非常高的,我們會(huì)面臨更加頻繁的變更。
在產(chǎn)品的初期,我們可能沒有辦法考慮到方方面面,我們擁有的是一個(gè)產(chǎn)品的Roadmap。但是針對(duì) Roadmap 里面的每一個(gè)功能點(diǎn),可能并不是在最開始的時(shí)候,就去詳細(xì)地寫出所有需求的細(xì)節(jié),而是在做的過程中不斷完善。通過不斷地交付出一些可工作的產(chǎn)物,對(duì)需求也會(huì)不斷做出調(diào)整。
第二點(diǎn),我預(yù)計(jì)新的標(biāo)準(zhǔn),會(huì)對(duì) BP 進(jìn)行更多的細(xì)化,并且也會(huì)推薦一些敏捷開發(fā)方法。
前面我們已經(jīng)舉過例子,在ASPICE里面,BP一般寫的都比較粗。具體怎么做,其實(shí)沒有很多的方法推薦。我估計(jì)新的標(biāo)準(zhǔn)中,會(huì)比較多的推薦敏捷開發(fā)的方法。如果某種解題方法是比較好的,我們需要把這種方法在標(biāo)準(zhǔn)里面體現(xiàn)出來,雖然這并不是強(qiáng)制性要求,但至少給我們提供了一些參考。這樣才能讓標(biāo)準(zhǔn)能夠逐漸融合敏捷開發(fā)。
第三點(diǎn)是,如何與第三方進(jìn)行合作,將會(huì)是標(biāo)準(zhǔn)的重要組成部分。
在ASPICE原來的標(biāo)準(zhǔn)中,針對(duì)如何與第三方進(jìn)行合作,其實(shí)篇幅很少,有一塊叫做供應(yīng)商管理。
但是,在新的標(biāo)準(zhǔn)中,如何與第三方合作,應(yīng)該有大量的篇幅去解讀它。在當(dāng)前的汽車軟件開發(fā)過程中,我們發(fā)現(xiàn),聯(lián)合開發(fā)變成了一種常態(tài),導(dǎo)致了像 Tier 0. 5 這樣一些合作方式出現(xiàn)。
在傳統(tǒng)的標(biāo)準(zhǔn)中,我們一般只是強(qiáng)調(diào),需要和供應(yīng)商之間進(jìn)行溝通,需要有與供應(yīng)商之間進(jìn)行信息交換的渠道,需要與供應(yīng)商達(dá)成統(tǒng)一等等。
但在新的開發(fā)過程中,我們需要意識(shí)到,我們不僅與供應(yīng)商之間會(huì)進(jìn)行聯(lián)合開發(fā),與甲方客戶之間也需要進(jìn)行聯(lián)合開發(fā)。而且聯(lián)合開發(fā)的過程相比于原來會(huì)更加頻繁和緊密,它不再是一個(gè)交鑰匙的工程。對(duì)于一個(gè)軟件或系統(tǒng)的開發(fā),不同的軟件組件可能是由不同的參與方來執(zhí)行的。這個(gè)時(shí)候就要求我們?cè)谛枨蠊芸?、問題管理上擁有更加實(shí)時(shí)的交流渠道,互相可以對(duì)對(duì)方提需求、提bug,并且大家好像是在一個(gè)管理系統(tǒng)上進(jìn)行工作。這對(duì)于提升軟件的開發(fā)效率是非常有必要的。
第四點(diǎn)是,CICD 將成為 BP 之一,缺少 CICD 的基礎(chǔ)設(shè)施,意味著產(chǎn)品不具備持續(xù)迭代的屬性。
在 ASPICE原來的標(biāo)準(zhǔn)中,對(duì)于持續(xù)集成、持續(xù)交付、持續(xù)部署,并沒有特地強(qiáng)調(diào)。只是描述了針對(duì)軟件的驗(yàn)證過程,需要有軟件單元測(cè)試、軟件集成測(cè)試、軟件功能測(cè)試等等。更多還是強(qiáng)調(diào),針對(duì)需求、架構(gòu)、詳細(xì)設(shè)計(jì)的可追溯性和完全覆蓋。至于驗(yàn)證的過程要怎么做,并未提出要求。可以預(yù)見,未來甲方的需求會(huì)越來越多,且越來越頻繁,CICD基礎(chǔ)設(shè)施將是響應(yīng)這一變化的關(guān)鍵。我們有一家做氣體傳感器的客戶,其德方客戶明確提出要求,研發(fā)過程必須上系統(tǒng),且必須擁有統(tǒng)一的代碼倉庫和持續(xù)集成的能力(雖然這家客戶本身的代碼量不多,之前的代碼全部放在工程師的電腦里進(jìn)行管理)。但德方客戶考慮到,后續(xù)市場(chǎng)或法規(guī)對(duì)于車內(nèi)空氣的更高要求,可能需要在更短時(shí)間內(nèi),提供更新迭代的產(chǎn)品。
-
開發(fā)
+關(guān)注
關(guān)注
0文章
357瀏覽量
40734 -
汽車
+關(guān)注
關(guān)注
12文章
3269瀏覽量
36833
原文標(biāo)題:汽車軟件開發(fā)標(biāo)準(zhǔn),將走向何方?
文章出處:【微信號(hào):智能汽車電子與軟件,微信公眾號(hào):智能汽車電子與軟件】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論