摘要

本文介紹了AUTOSAR驅(qū)動(dòng)的敏捷開發(fā)（AUTILE）框架，作為開發(fā)汽車軟件的新方法，旨在減少缺陷的數(shù)量和其嚴(yán)重程度。以傳統(tǒng)方式開發(fā)的汽車軟件，目前必須從頭開始重寫，以支持新功能或相關(guān)硬件的修改。顛覆性的汽車大趨勢：連接性、電氣化和自動(dòng)駕駛，繼續(xù)要求在復(fù)雜的軟件基礎(chǔ)上提供新功能。因此，當(dāng)更多的功能被添加到傳統(tǒng)的、非標(biāo)準(zhǔn)化的汽車軟件中時(shí)，將面臨更大的質(zhì)量問題。一些研究人員提議汽車軟件的標(biāo)準(zhǔn)化，以提高軟件質(zhì)量。然而，到目前為止，該行業(yè)還缺乏一個(gè)公認(rèn)的標(biāo)準(zhǔn)。在AUTILE框架的，我們建議遵循汽車開放系統(tǒng)架構(gòu)標(biāo)準(zhǔn)，作為設(shè)計(jì)模塊化和開放軟件架構(gòu)的基礎(chǔ)。為了進(jìn)一步實(shí)現(xiàn)階段設(shè)計(jì)的模塊化軟件架構(gòu)的優(yōu)點(diǎn)，AUTILE選擇并整合了敏捷方法作為其軟件開發(fā)方法。敏捷方法在汽車軟件開發(fā)中的采用還沒有發(fā)生，這項(xiàng)研究強(qiáng)調(diào)了這一領(lǐng)域的促進(jìn)因素和壁壘。提出的該框架被實(shí)際應(yīng)用于開發(fā)汽車軟件項(xiàng)目，證明了使用這一新方法中概述的步驟可以完成缺陷的減少。

1 引言

隨著電氣化、連通性和自動(dòng)化的全球趨勢，汽車行業(yè)正在迅速發(fā)展。在提供增值功能和安全關(guān)鍵功能方面，汽車中行業(yè)的軟件集成正在成為一個(gè)關(guān)鍵的區(qū)別因素。一個(gè)典型的汽車開發(fā)周期為4至8年，在此期間，若干個(gè)在設(shè)計(jì)階段被認(rèn)為是的技術(shù)可能在為消費(fèi)者市場生產(chǎn)時(shí)已經(jīng)過時(shí)了。因此，為了保持競爭力，汽車公司正在采用更快的方法來設(shè)計(jì)軟件，重點(diǎn)是標(biāo)準(zhǔn)化，為不同變種的電子控制單元（ECU）實(shí)現(xiàn)更好的軟件可擴(kuò)展性。一些新的框架也被引入，從根本上改變了軟件開發(fā)方法。即使在設(shè)計(jì)后期,這些框架也能使開發(fā)者整合修改內(nèi)容，并且在不影響產(chǎn)品的質(zhì)量和安全特性的情況下。

近年來，軟件與汽車工業(yè)的整合出現(xiàn)了明顯增長。目前這一代汽車所配備的軟件模塊比一些高度復(fù)雜的機(jī)器還要多，例如，波音飛機(jī)和美國空軍的戰(zhàn)斗機(jī)。隨著對軟件控制部件的依賴性增加，設(shè)備發(fā)生故障的風(fēng)險(xiǎn)更大。許多研究人員聲稱代碼行數(shù)與軟件缺陷的平均數(shù)量之間存在線性關(guān)系。擁有一輛有數(shù)百萬行代碼的汽車意味著有大量的缺陷。即使有嚴(yán)格的質(zhì)量保證措施，仍然可能有高達(dá)15%的缺陷在制造單位中沒有被發(fā)現(xiàn)。多年來，汽車召回事件持續(xù)增加，在這些召回事件中，15%是由于軟件缺陷造成的。隨著汽車中軟件內(nèi)容的增加，軟件的可移植性、可擴(kuò)展性和可轉(zhuǎn)移性變得極為重要。利用一個(gè)穩(wěn)定的軟件基礎(chǔ)，用于一個(gè)以上的汽車變體，少量修改或沒有修改，這樣減少了研究和開發(fā)成本。然而，在汽車行業(yè)的傳統(tǒng)軟件開發(fā)實(shí)踐中經(jīng)歷了很差的可移植性，也就是說，代碼必須從頭開始重寫，從任何修改到相關(guān)硬件。學(xué)者和專業(yè)人士認(rèn)為，汽車軟件的標(biāo)準(zhǔn)化可以提高復(fù)用性，在這方面已經(jīng)做了一些嘗試。這種嘗試的一個(gè)成功例子是建立了汽車開放系統(tǒng)架構(gòu)（AUTOSAR），目的是提供模塊化和開放的軟件架構(gòu)。

汽車行業(yè)的特點(diǎn)還表現(xiàn)在對所有軟件需求的質(zhì)量和文件都有嚴(yán)格的要求。這使得采用V型或瀑布式的開發(fā)模式成為。汽車行業(yè)不斷被自動(dòng)化、連接性和電氣化等趨勢所顛覆，在設(shè)計(jì)的后期階段就會(huì)有相關(guān)要求。為此，采用輕量級的軟件開發(fā)過程，在不影響質(zhì)量的前提下減少從需求征詢到驗(yàn)證和生產(chǎn)的延誤，成為一個(gè)關(guān)鍵的要求?；诿艚莸能浖_發(fā)方法可以提供這些好處。盡管汽車制造商開始遵循敏捷框架，但采用過程非常緩慢。

汽車軟件的標(biāo)準(zhǔn)化和敏捷方法的采用可能會(huì)使汽車制造商有效地應(yīng)對行業(yè)的新趨勢進(jìn)行標(biāo)準(zhǔn)化，盡早的采用可以將許多汽車公司面臨的挑戰(zhàn)轉(zhuǎn)化為競爭優(yōu)勢，通過改善軟件質(zhì)量方面，如產(chǎn)品生命周期中的可擴(kuò)展性、可轉(zhuǎn)移性、可復(fù)用性、可移植性和可維護(hù)性。它可能會(huì)導(dǎo)致更好的軟件集成，從而提高工作效率。它還將提供一條更快的創(chuàng)新之路，即更好的設(shè)計(jì)。

問題陳述：汽車軟件的規(guī)模和復(fù)雜性正在增加，因此，現(xiàn)代汽車可能面臨數(shù)十萬的軟件缺陷。

研究聲明：一個(gè)AUTOSAR驅(qū)動(dòng)的敏捷開發(fā)方法將減少汽車軟件缺陷?？紤]到這個(gè)汽車顛覆的時(shí)代，本研究考慮了兩個(gè)特征，以盡量減少汽車軟件缺陷及其嚴(yán)重程度 :

1）基于AUTOSAR的標(biāo)準(zhǔn)化架構(gòu)，提供更好的可擴(kuò)展性、可維護(hù)性和可轉(zhuǎn)移性。

2）敏捷開發(fā)方法，目前在汽車軟件行業(yè)尚未使用。

本研究的范圍于由二級軟件供應(yīng)商執(zhí)行的汽車軟件項(xiàng)目（ASP）。本研究不考慮其他汽車公司執(zhí)行的ASP或其他行業(yè)的項(xiàng)目。

2 回顧

A. 傳統(tǒng)汽車工業(yè)規(guī)則正在被入局者打破

麥肯錫公司認(rèn)為，各種汽車趨勢的結(jié)合正在顛覆汽車行業(yè)。該報(bào)告指出，先進(jìn)技術(shù)的普及將在未來幾年催生更多的自動(dòng)駕駛和電動(dòng)汽車。另一項(xiàng)研究發(fā)現(xiàn)，超過1700家專注于互聯(lián)互通、自主運(yùn)營和電氣化等大趨勢的初創(chuàng)企業(yè)正在進(jìn)入市場，從而改變了商業(yè)規(guī)則。這種顛覆將影響到供應(yīng)鏈的所有方面，為了在未來保持相關(guān)性，所有利益相關(guān)者都必須進(jìn)行創(chuàng)新。

B. 傳統(tǒng)的汽車軟件開發(fā)及其弊端

汽車軟件開發(fā)的特點(diǎn)是預(yù)先定義需求和嚴(yán)格的質(zhì)量保證，這使得瀑布模型成為。在汽車行業(yè)，這個(gè)過程從收集客戶（原始設(shè)備制造商、級）的相關(guān)要求開始。第二級供應(yīng)商主要關(guān)注之后的內(nèi)部開發(fā)過程，并創(chuàng)建一個(gè)穩(wěn)定的軟件設(shè)計(jì)和架構(gòu)。隨后執(zhí)行軟件開發(fā)、測試和集成階段。在這些階段中，客戶再次參與進(jìn)來，并且只有當(dāng)軟件滿足預(yù)定義的驗(yàn)收標(biāo)準(zhǔn)時(shí)，軟件才會(huì)被部署?；谄俨寄Ｐ偷能浖_發(fā)將風(fēng)險(xiǎn)和不確定性降到，特別是當(dāng)需求在初始定義階段之后沒有變化，并且相關(guān)的技能組合可以用于開發(fā)時(shí)。它的其他優(yōu)點(diǎn)包括有效的資源和財(cái)務(wù)規(guī)劃、防止 "范圍蠕變"、設(shè)計(jì)的準(zhǔn)確性和的文件。

通過部署基于v模型的開發(fā)流程，也可以實(shí)現(xiàn)項(xiàng)目定義和測試階段之間的嚴(yán)格可追溯性。在流程開始時(shí)收集所有需求，并假設(shè)所需的技能集隨時(shí)可用。從需求集來看，軟件體系結(jié)構(gòu)是用的軟件組件來設(shè)計(jì)的。在設(shè)計(jì)階段完成后，將進(jìn)行實(shí)施，然后是單個(gè)組件的測試和集成。有了向上彎曲的V，設(shè)計(jì)和測試階段之間有了1:1的可追溯性，重點(diǎn)更加突出。它的其他優(yōu)點(diǎn)包括有效的資源和財(cái)務(wù)規(guī)劃，防止 "范圍蠕變"，設(shè)計(jì)的準(zhǔn)確性，的文件，以及交付前的詳細(xì)評估。

傳統(tǒng)的汽車軟件開發(fā)方法使用高度結(jié)構(gòu)化和組織化的方法。軟件開發(fā)方法的選擇取決于項(xiàng)目、團(tuán)隊(duì)和組織的特點(diǎn)。然而，有一個(gè)潛在的假設(shè)，在這個(gè)混亂的時(shí)代不一定是真的，即 "軟件需求在初的征詢后不會(huì)改變"。將軟件部署到復(fù)雜的、相互依賴的和連接的系統(tǒng)中，需要在高級階段進(jìn)行修改。因此，現(xiàn)代汽車級的軟件開發(fā)需要迎合不斷變化的需求。因此，傳統(tǒng)的開發(fā)方法不能產(chǎn)生效果，可能面臨更多的缺陷，并可能導(dǎo)致客戶和供應(yīng)商在交付時(shí)的。

C. 敏捷方法及其對汽車行業(yè)的適用性

敏捷宣言催生了各種敏捷技術(shù)，包括Scrum:極限編程、精益開發(fā)、看板開發(fā)和特性驅(qū)動(dòng)開發(fā)。盡管敏捷方法非常強(qiáng)調(diào)靈活性，但這個(gè)過程并不總是容易遵循的。為了減輕適應(yīng)工作，研究人員提出了根據(jù)組織要求、環(huán)境和文化來調(diào)整敏捷方法的建議。汽車軟件行業(yè)的特點(diǎn)是對質(zhì)量有嚴(yán)格的要求，所有的需求都預(yù)先定義好了，因此敏捷開發(fā)的使用非常少。一項(xiàng)針對15-20家的汽車公司進(jìn)行的調(diào)查報(bào)告顯示，敏捷實(shí)現(xiàn)在特定公司的范圍只占總體運(yùn)營的5.6%。

然而，連接性、電氣化和自動(dòng)化的顛覆性趨勢說明了新的用例，并要求對后期設(shè)計(jì)階段進(jìn)行需求修改，使敏捷成為軟件開發(fā)的。一些研究人員與主要的汽車制造商合作，進(jìn)行了案例研究，以確定公司可能面臨的挑戰(zhàn)，以及他們在采用敏捷方法時(shí)可能探索的機(jī)會(huì)。研究發(fā)現(xiàn)，大多數(shù)挑戰(zhàn)來自于管理變革過程和被嚴(yán)格過程包圍的穩(wěn)定需求集。在有組織的努力下，敏捷在汽車領(lǐng)域的應(yīng)用有了明顯的改善。首屆 "汽車敏捷 "會(huì)議于2019年5月在底特律舉行。在這次會(huì)議上，大多數(shù)討論的主題是分享參與組織的選定試點(diǎn)項(xiàng)目采用敏捷時(shí)的經(jīng)驗(yàn)教訓(xùn)。Scrum是一個(gè)敏捷開發(fā)框架，適用于在項(xiàng)目開始時(shí)需求沒有被完全定義的情況。它依賴于定期的反饋和增量的修改，以滿足不斷變化的需求。Scrum周期始于需求的收集和相關(guān)的優(yōu)先級劃分，并計(jì)劃創(chuàng)建一個(gè)Sprint Backlog。一系列的Sprint計(jì)劃在優(yōu)先級項(xiàng)目之上，以獲得可交付的增量，在Sprint周期中，每天進(jìn)行Scrum以確保團(tuán)隊(duì)保持在商定的軌道上。在Sprint結(jié)束時(shí)，要進(jìn)行回顧性檢查。這個(gè)周期一直持續(xù)到所需的產(chǎn)品被交付，或者分配的時(shí)間已經(jīng)過去，或者資金被耗盡。汽車軟件行業(yè)的項(xiàng)目是大規(guī)模的、全球分布的、迭代驅(qū)動(dòng)的，并且對質(zhì)量有嚴(yán)格的要求?？紤]到Scrum對這些動(dòng)態(tài)的適用性，以及汽車軟件行業(yè)的要求和流程，本研究將Scrum確立為標(biāo)準(zhǔn)框架，將敏捷性引入開發(fā)流程。

D. 汽車軟件標(biāo)準(zhǔn)化和AUTOSAR

在汽車工業(yè)中已經(jīng)有了一些標(biāo)準(zhǔn)化的嘗試，這可能內(nèi)在地改變了開發(fā)軟件的工作方法。其中一個(gè)標(biāo)準(zhǔn)化的嘗試，在汽車行業(yè)獲得了接受，以及相關(guān)的全球部署和擴(kuò)散，就是AUTOSAR標(biāo)準(zhǔn)的建立。AUTOSAR采用模塊化方法，的組件可以集成到一個(gè)完整的工作產(chǎn)品中，并采用開放的軟件政策，公開提供設(shè)計(jì)和源代碼。通過這樣做，軟件質(zhì)量方面，如可擴(kuò)展性、可2個(gè)樣本性和對不同車輛和平臺(tái)變體的可轉(zhuǎn)移性成為開發(fā)理念。此外，在產(chǎn)品的整個(gè)生命周期中，它能夠?qū)崿F(xiàn)更好的可維護(hù)性指標(biāo)。AUTOSAR是一個(gè)不斷發(fā)展的標(biāo)準(zhǔn)，其各種規(guī)格的新版本正在進(jìn)行中。一些研究人員試圖衡量在初部署后，需要在多大程度上遵循新的標(biāo)準(zhǔn)版本的演變的權(quán)衡。

3 方法論

本節(jié)描述了整個(gè)方法論，并以框架的形式將這些概念正式化，汽車軟件供應(yīng)商可以用它來通過減少缺陷數(shù)量和DSI來提高軟件質(zhì)量。本研究分六個(gè)階段進(jìn)行，采用了幾種方法來實(shí)現(xiàn)其目標(biāo)：

1) 識別汽車軟件開發(fā)的實(shí)踐和趨勢；

2) 基于AUTOSAR和Agile的項(xiàng)目的缺陷數(shù)量及其嚴(yán)重程度的假設(shè)；

3) 對傳統(tǒng)/遺產(chǎn)項(xiàng)目和基于AUTOSAR和Agile的項(xiàng)目進(jìn)行假設(shè)測試；

4) AUTILE框架的開發(fā)；

5) 基于AUTILE的項(xiàng)目的缺陷數(shù)量和其嚴(yán)重程度的假設(shè)；

6) 對AUTILE項(xiàng)目進(jìn)行假設(shè)測試；

7) 結(jié)論和對未來工作的建議。

A. AUTILE 框架

AUTILE框架提供了一個(gè)汽車級軟件的整體視圖。它旨在作為一個(gè)指南，通過利用基于AUTOSAR的標(biāo)準(zhǔn)化和模塊化軟件架構(gòu)，在一個(gè)的層面上提請關(guān)注早期設(shè)計(jì)和架構(gòu)(37)。此外，在后期的設(shè)計(jì)階段，由于工業(yè)的進(jìn)步，預(yù)計(jì)軟件需求會(huì)有修改。在設(shè)計(jì)的早期階段，我們就考慮到了這一事實(shí)，提出基于敏捷的Scrum開發(fā)方法，這使得AUTILE具有相當(dāng)大的發(fā)展靈活性。該框架也是可定制的，以適應(yīng)不同的組織戰(zhàn)略和文化。此外，敏捷原則是為適應(yīng)汽車軟件需求、流程和挑戰(zhàn)而量身定制的。AUTILE框架分為三個(gè)主要階段：初始（見圖1）、計(jì)劃（見圖2）和執(zhí)行（見圖3）。

圖1. AUTILE框架-初始化

圖2. AUTILE 框架—計(jì)劃

圖3. AUTILE 框架—執(zhí)行

1) 初始化：AUTILE框架的個(gè)階段是預(yù)先收集可用的需求集。在這一點(diǎn)上，收集到的需求是非常高的。在這方面，我們利用了兩個(gè)來源。

1. 出于效率和設(shè)計(jì)的目的，所有種類的汽車軟件都需要在車輛上安裝特定的硬件模塊或其他軟件組件。這些基本要素被稱為汽車系統(tǒng)需求。這些需求被分為和可選，作為指導(dǎo)方針并定義了軟件的結(jié)構(gòu)。來自二級公司（軟件供應(yīng)商）的軟件架構(gòu)師和產(chǎn)品經(jīng)理與一級公司（硬件集成商）和OEM（汽車制造商）的架構(gòu)師一起，在系統(tǒng)或平臺(tái)層面定義詳細(xì)的設(shè)計(jì)規(guī)范。產(chǎn)品所有者（PO）從這些系統(tǒng)需求中提取軟件指南。開發(fā)團(tuán)隊(duì)的領(lǐng)導(dǎo)也由PO參與，將這些需求映射到具體的軟件模塊上。

2. 在執(zhí)行軟件開發(fā)之前，汽車的電氣/電子（E/E）設(shè)計(jì)已經(jīng)完成，系統(tǒng)級提議由OEM建筑師準(zhǔn)備。該提議定義了在ECU之間交流的信號和信息，并制定了汽車的 "系統(tǒng)提取"。在系統(tǒng)提取的信息中，屬于單個(gè)ECU的信號和信息可以由一級廠商提取出來。所提取的信息，詳細(xì)說明了汽車內(nèi)特定ECU的信號，被稱為 "ECU提取"。

二級架構(gòu)師、PO和開發(fā)團(tuán)隊(duì)領(lǐng)導(dǎo)利用基于AUTOSAR的ECU提取的AUTOSARARXML格式，獲得整體設(shè)計(jì)的可見性，實(shí)現(xiàn)相關(guān)的軟件要求。為了達(dá)到嚴(yán)格的質(zhì)量、可追溯性和審計(jì)要求，在此階段收集的需求由PO通過需求管理系統(tǒng)進(jìn)行記錄。

2) 計(jì)劃：AUTILE整合了Scrum作為一種敏捷方法。其規(guī)劃階段分為三個(gè)活動(dòng)。產(chǎn)品Backlog，產(chǎn)品Backlog的完善和Sprint計(jì)劃，以及Sprint Backlog。

產(chǎn)品積壓：在這個(gè)階段，高水平的軟件需求被轉(zhuǎn)化為Epics或User Stories。PO在產(chǎn)品經(jīng)理和系統(tǒng)架構(gòu)師的幫助下，將高層次的軟件需求轉(zhuǎn)化為新需要的功能、特征請求、需求、增強(qiáng)功能或錯(cuò)誤修復(fù)。產(chǎn)品Backlog是所有需要支持的需求的超級。它是一個(gè)萌芽階段的工件--根據(jù)不斷變化的業(yè)務(wù)或市場情況，PO可以在任何時(shí)候修改或修訂需求。產(chǎn)品Backlog列表中的項(xiàng)目可以具有“高級評估”或“訂單”等屬性。

產(chǎn)品Backlog細(xì)化：定期對產(chǎn)品Backlog進(jìn)行細(xì)化，通常是每周或兩周進(jìn)行一次。PO負(fù)責(zé)Backlog細(xì)化過程以及利益相關(guān)者，例如，來自相關(guān)開發(fā)團(tuán)隊(duì)的技術(shù)負(fù)責(zé)人。作為完善會(huì)議的結(jié)果，產(chǎn)品Backlog中優(yōu)先級較高的項(xiàng)目會(huì)進(jìn)行頭腦風(fēng)暴、詳細(xì)說明、確定優(yōu)先級，并粗略估計(jì)。這個(gè)細(xì)化過程一直持續(xù)到更高優(yōu)先級的項(xiàng)目被分析和理解，這樣一個(gè)特定的項(xiàng)目就可以在一個(gè)sprint中有明確的完成定義。這些會(huì)議的結(jié)果是一個(gè)項(xiàng)目清單，在這個(gè)清單上可以計(jì)劃一個(gè)具體的迭代。

Sprint 計(jì)劃：這是計(jì)劃階段的一步。在Sprint計(jì)劃期間，PO與Scrum團(tuán)隊(duì)成員合作，以目標(biāo)產(chǎn)品Backlog項(xiàng)目。討論由流程管理員（Scrum Master）主持，以確保計(jì)劃的有效性和正確性。在這個(gè)過程中，某些功能或修復(fù)--具有的優(yōu)先級，因此，具有的交付確定性——可以作為產(chǎn)品路線圖項(xiàng)目。我們發(fā)現(xiàn)，當(dāng)AUTILE部署在第二級供應(yīng)商時(shí)，每季度一次的頻率效果。然而，該框架允許在組織層面的靈活性，并允許POs自由定義在其特定場景中工作頻率。

3) 執(zhí)行：AUTILE執(zhí)行階段在Sprint計(jì)劃完成后開始。在這個(gè)階段，軟件被設(shè)計(jì)和編寫。它有以下一系列的活動(dòng)。

軟件設(shè)計(jì)和架構(gòu)：AUTILE強(qiáng)調(diào)在實(shí)施前有一個(gè)明確的軟件設(shè)計(jì)和架構(gòu)。為了實(shí)現(xiàn)這一目標(biāo)，Scrum團(tuán)隊(duì)還應(yīng)包括一個(gè)軟件架構(gòu)師。此外，現(xiàn)有項(xiàng)目的軟件設(shè)計(jì)和架構(gòu)，在修復(fù)或增強(qiáng)的情況下，也會(huì)在這個(gè)階段發(fā)生變化。AUTOSAR需求(SRS)和基本軟件模塊(BSW)規(guī)范被視為定義總體軟件體系結(jié)構(gòu)的基線。單獨(dú)的BSW配置參數(shù)和應(yīng)用編程接口層面的標(biāo)準(zhǔn)化接口被定義，目的是為了實(shí)現(xiàn)結(jié)構(gòu)化和模塊化的軟件架構(gòu)。由于 AUTOSAR 是一個(gè)不斷發(fā)展的標(biāo)準(zhǔn)，預(yù)計(jì)其規(guī)范會(huì)有一定的擴(kuò)展和偏差。在設(shè)計(jì)階段要預(yù)先考慮這方面的問題。AUTOSAR提供了一個(gè)模塊化和開放的軟件架構(gòu)，因此二級供應(yīng)商被賦予了對其進(jìn)行擴(kuò)展和偏離的權(quán)利。在設(shè)計(jì)階段要考慮BSW模塊之間的依賴關(guān)系，以確保開發(fā)的軟件滿足指定的需求。BSW模塊的依賴性以AUTOSAR特有的ARXML格式記錄的。此外，在此還生成了SWC服務(wù)層，因此在軟件開發(fā)過程中也可以確定應(yīng)用層面的服務(wù)需求。

任務(wù)和低層次的軟件要求：低層次的軟件需求和個(gè)別任務(wù)是在軟件設(shè)計(jì)完成后創(chuàng)建的。AUTOSAR特有的.ARXML格式中的BSW模塊定義是來自初提供的“ECU提取”。此時(shí)，開發(fā)團(tuán)隊(duì)對需求和單個(gè)任務(wù)有了清晰的理解，例如可以調(diào)度的靜態(tài)源代碼(.c格式)或生成器代碼(.jar格式)的創(chuàng)建。ECU配置和應(yīng)用軟件組件也會(huì)生成。單元測試伴隨著開發(fā)的軟件庫，以滿足質(zhì)量保證的苛刻要求。此外，為了實(shí)現(xiàn)對汽車安全標(biāo)準(zhǔn)的遵守，開發(fā)團(tuán)隊(duì)也注意到了需求的可追溯性。一個(gè)從高層次的需求，被分解成較低的層次時(shí)，它確保了這程不僅得到了實(shí)現(xiàn)，而且得到了充分的測試。，創(chuàng)建工件和文檔，為發(fā)布做準(zhǔn)備。

每日Scrum: 在Sprint執(zhí)行過程中，每日站立會(huì)議都是以三個(gè)問題為重點(diǎn)來計(jì)劃的 1) 我們昨天完成了什么？2) 我們的計(jì)劃是什么？3) 我們看到哪些依賴關(guān)系、風(fēng)險(xiǎn)和障礙可能會(huì)阻礙計(jì)劃？這樣一來，開發(fā)計(jì)劃就能得到日常跟蹤。此外，還能確保履行承諾并解決潛在的障礙。

沖刺評審、回顧和可發(fā)貨增量: 在Sprint周期結(jié)束時(shí)，計(jì)劃進(jìn)行Sprint評審和回顧。這些活動(dòng)的目的是為了從過去的錯(cuò)誤中學(xué)習(xí)，以便在未來的項(xiàng)目中改進(jìn)規(guī)劃。如果遺漏項(xiàng)目的話，則添加回產(chǎn)品Backlog中，以便重新確定優(yōu)先次序和調(diào)度。準(zhǔn)備好產(chǎn)品的可運(yùn)輸增量。如果合同允許發(fā)送源代碼，則向客戶提供 .ARXML、.c 和 .h 文件。在其他情況下，則提供 .elf 或 .s19 等格式文件。

B. 研究假設(shè)

RH1：使用AUTOSAR的一些應(yīng)用開發(fā)的ASP往往缺陷更少。

RH2：使用AUTOSAR的一些應(yīng)用開發(fā)的ASP往往具有較低的DSI。

RH3：在某種程度上應(yīng)用敏捷開發(fā)的ASP往往有較少的缺陷。

RH4：使用一些敏捷開發(fā)應(yīng)用程序開發(fā)的ASP往往具有較低的DSI。

H5：使用基于AUTILE的方法開發(fā)的ASP往往缺陷更少。

RH6：用基于AUTILE的方法開發(fā)的ASP往往有較低的DSI。

C. 變量

預(yù)測器/（Y）變量包括：AUTOSAR對ASP的應(yīng)用和Agile對ASP的應(yīng)用。同樣，響應(yīng)/自變量（X）有：總?cè)毕輸?shù)、每個(gè)項(xiàng)目的平均缺陷數(shù)和DSI。

缺陷嚴(yán)重程度指數(shù) (DSI): 汽車軟件行業(yè)將缺陷分為幾個(gè)類別，以確定優(yōu)先級和調(diào)度目的。雖然這些術(shù)語可以互換使用（例如，像 "關(guān)鍵 "或 "阻塞 "這樣的術(shù)語被用于優(yōu)先級的缺陷，而 "輕微 "或 "低 "則用于優(yōu)先級的缺陷），但基本的分類理念仍然是一致的。因此，我們決定采用二級制造商使用的術(shù)語，它們部署了AUTILE框架并為本研究提供了數(shù)據(jù)。根據(jù)他們的質(zhì)量體系，缺陷分類如下：

關(guān)鍵缺陷：如果工件是在客戶的關(guān)鍵路徑上，該缺陷使其無法使用，并且沒有可接受的解決方法。

重要缺陷：如果工件將在短時(shí)間內(nèi)進(jìn)入客戶的關(guān)鍵路徑，該缺陷使其無法使用，并且沒有可接受的解決方法。

中等缺陷：如果缺陷損害了工件的使用（不一定使其無法使用），并且沒有可接受的解決方法。

次要缺陷：存在一個(gè)解決方法，但該缺陷給用戶帶來了不便。DSI被用來作為確定缺陷嚴(yán)重程度的一個(gè)指標(biāo)。DSI是一個(gè)加權(quán)平均值，范圍從1到4，它闡明了特定項(xiàng)目所報(bào)告的缺陷的嚴(yán)重程度。與我們合作的二級制造商，它被四舍五入到小數(shù)點(diǎn)后九位，并定義為

DSI=（關(guān)鍵缺陷數(shù)*4+重要缺陷數(shù)*3+中等缺陷數(shù)*2+輕微缺陷數(shù)*1）/缺陷總數(shù)。(1)

4 結(jié)果

數(shù)據(jù)集的來源是一個(gè)大型的、高度成熟的、在汽車行業(yè)的二級供應(yīng)商（軟件供應(yīng)商）。項(xiàng)目狀態(tài)報(bào)告是由二級公司提供的ASP中獲得的。在開發(fā)階段，ASP的持續(xù)時(shí)間保持在6個(gè)月到1年之間，以適應(yīng)公司的發(fā)布周期。每個(gè)ASP都分配了2到6個(gè)開發(fā)人員。這些ASP的開發(fā)是為了向汽車行業(yè)中的一級公司（硬件集成商）和汽車制造商提供不同類型的汽車軟件產(chǎn)品和服務(wù)。這些產(chǎn)品和服務(wù)包括汽車級通信、操作系統(tǒng)、微控制器驅(qū)動(dòng)器和安全組件。

項(xiàng)目報(bào)告內(nèi)容包含的字段有：問題類型、嚴(yán)重程度、問題狀態(tài)、優(yōu)先級、解決方案、受影響的版本、組件、標(biāo)簽、epic名稱、AUTOSAR版本、受讓人、報(bào)告人、時(shí)間跟蹤、問題鏈接和創(chuàng)建以及關(guān)閉日期。在這項(xiàng)研究中，問題的嚴(yán)重程度（針對DSI）和ASP的缺陷總數(shù)被考慮在內(nèi)。這些ASP有四種類型：沒有應(yīng)用AUTOSAR或Agile的ASP被認(rèn)為是傳統(tǒng)/遺產(chǎn)ASP，有一些應(yīng)用AUTOSAR的ASP，有一些應(yīng)用Agile的ASP，以及應(yīng)用AUTILE框架的ASP。

為了對這些的項(xiàng)目樣本進(jìn)行分析，我們制定了五個(gè)數(shù)據(jù)集，即：

1) 個(gè)數(shù)據(jù)集（DS-1）：有AUTOSAR應(yīng)用和沒有AUTOSAR應(yīng)用的項(xiàng)目，以分析RH1和RH2。

2) 第二個(gè)數(shù)據(jù)集（DS-2）：有和沒有應(yīng)用Agile的項(xiàng)目，以分析RH3和RH4。

3) 第三個(gè)數(shù)據(jù)集（DS-3）：遺產(chǎn)項(xiàng)目和應(yīng)用AUTILE框架的項(xiàng)目，以分析RH5和RH6。

4) 第四數(shù)據(jù)集（DS-4）：AUTOSAR項(xiàng)目和應(yīng)用AUTILE框架的項(xiàng)目。

5) 第五數(shù)據(jù)集（DS-5）：敏捷項(xiàng)目和應(yīng)用AUTILE框架的項(xiàng)目。

所有數(shù)據(jù)集（DS 1-5）中兩個(gè)變量（缺陷總數(shù)和DSI）的正態(tài)性確認(rèn)是通過觀察概率圖中大于0.05的P值實(shí)現(xiàn)的。之后，用α值為0.05的雙樣本T檢驗(yàn)對數(shù)據(jù)進(jìn)行分析，以比較兩組的平均值，確定樣本之間是否有統(tǒng)計(jì)學(xué)上的差異。此外，每個(gè)項(xiàng)目的平均缺陷也分析了2個(gè)樣本泊松率。結(jié)果總結(jié)在表1中。

A. 使用AUTOSAR的總?cè)毕荩簩?shí)現(xiàn)減少

2個(gè)樣本的T檢驗(yàn)P值為0.028。檢驗(yàn)結(jié)果證實(shí)，采用AUTOSAR的ASP的總?cè)毕萜骄翟诮y(tǒng)計(jì)學(xué)上低于采用傳統(tǒng)/遺產(chǎn)方法（不使用AUTOSAR）開發(fā)的ASP的總?cè)毕萜骄怠?

B. 帶有AUTOSAR的DSI：實(shí)現(xiàn)減少

2個(gè)樣本的T檢驗(yàn)P值為0.000。檢驗(yàn)結(jié)果證實(shí)，采用AUTOSAR的ASP的DSI平均值在統(tǒng)計(jì)學(xué)上低于以傳統(tǒng)/傳統(tǒng)方式開發(fā)的ASP（不使用AUTOSAR）的DSI平均值。

C. 使用敏捷的總?cè)毕荩簩?shí)現(xiàn)減少

2個(gè)樣本的T檢驗(yàn)P值為0.009。檢驗(yàn)結(jié)果證實(shí)，采用Agile的ASP的總?cè)毕萜骄翟诮y(tǒng)計(jì)學(xué)上低于以傳統(tǒng)/遺產(chǎn)方式開發(fā)的ASP（沒有Agile）的總?cè)毕萜骄怠?

D. 采用敏捷的DSI：實(shí)現(xiàn)減少

2個(gè)樣本的T檢驗(yàn)P值為0.000。檢驗(yàn)結(jié)果證實(shí)，采用Agile的ASP的DSI平均值在統(tǒng)計(jì)學(xué)上低于以傳統(tǒng)/一次方式開發(fā)的ASP（不采用Agile）的DSI平均值。

E. 采用AUTILE的總?cè)毕荩簩?shí)現(xiàn)減少

2個(gè)樣本的T檢驗(yàn)P值為0.002。檢驗(yàn)證實(shí)，采用AUTILE的ASP的總?cè)毕萜骄翟诮y(tǒng)計(jì)學(xué)上低于采用傳統(tǒng)/遺產(chǎn)方法開發(fā)的ASP的總?cè)毕萜骄怠?

F. 采用AUTILE的DSI: 實(shí)現(xiàn)減少

2個(gè)樣本的T檢驗(yàn)P值為0.000。檢驗(yàn)結(jié)果證實(shí)，采用AUTILE的ASP的DSI平均值在統(tǒng)計(jì)學(xué)上低于采用傳統(tǒng)/遺產(chǎn)方法開發(fā)的ASP的DSI平均值。

G. AUTILE與AUTOSAR和Agile ASP的比較

本節(jié)與任何研究假設(shè)沒有聯(lián)系。將AUTILE ASP與AUTOSAR和Agile ASP進(jìn)行比較，以確定擬議框架的效率。在DS-4的案例中，通過兩個(gè)樣本的T檢驗(yàn)，能觀察到總?cè)毕莸腜值為0.039，DSI的P值為0.048。測試證實(shí)，使用AUTILE的ASP的總?cè)毕莺虳SI的平均值在統(tǒng)計(jì)學(xué)上均低于使用AUTOSAR方法開發(fā)的ASP。

就DS-5的總?cè)毕荻?，?jīng)2個(gè)樣本T檢驗(yàn)，得到結(jié)果P值為 0.190。這并不低于0.05的α值。雖然AUTILE ASP的總?cè)毕萜骄档陀贏gile ASP的總?cè)毕萜骄?，但這一發(fā)現(xiàn)無法通過獲得的樣本進(jìn)行統(tǒng)計(jì)確認(rèn)。因此，針對一個(gè)變量（總?cè)毕荩?，無法確定所提出的框架對敏捷ASP的有效性。為了獲得進(jìn)一步的了解，建議增加項(xiàng)目的樣本量。然而，這個(gè)行為超出了本研究的范圍。就DS-5案例中的DSI而言，通過2個(gè)樣本的T檢驗(yàn)，P值為0.013。檢驗(yàn)結(jié)果證實(shí)，AUTILE ASP的DSI平均值在統(tǒng)計(jì)學(xué)上低于Agile ASP的DSI平均值。

F. 每個(gè)項(xiàng)目的平均缺陷 ：減少的實(shí)現(xiàn)

每個(gè)項(xiàng)目的平均缺陷用2個(gè)樣本的Poisson率測試來分析。觀察到傳統(tǒng)、AUTOSAR、Agile和AUTILE項(xiàng)目的Poisson率分別為307.818、195.414、169.938和128.9。據(jù)觀察，當(dāng)框架不應(yīng)用于開發(fā)ASP時(shí)，Poisson率更高。為了衡量統(tǒng)計(jì)學(xué)意義，用2個(gè)樣本的Poisson率測試對DS 1-3進(jìn)行了檢驗(yàn)。通過所有的數(shù)據(jù)集的P值為1.01可以觀察到統(tǒng)計(jì)學(xué)上的改善測試證實(shí)，采用AUTOSAR、Agile和AUTILE的ASP的平均缺陷數(shù)在統(tǒng)計(jì)學(xué)上低于采用傳統(tǒng)方法（沒有AUTOSAR、Agile或AUTILE）開發(fā)的ASP的平均缺陷數(shù)。該結(jié)果總結(jié)如表1所示。

5 結(jié)論、貢獻(xiàn)和建議

這項(xiàng)研究終得出了以下結(jié)論：

1) 與不使用AUTOSAR的ASP相比，使用AUTOSAR的某些應(yīng)用開發(fā)的ASP面臨較少的缺陷數(shù)量。

2) 與不使用AUTOSAR的ASP相比，使用AUTOSAR的某些應(yīng)用開發(fā)的ASP的DSI較低。

3) 與沒有應(yīng)用敏捷的ASP相比，應(yīng)用敏捷開發(fā)的ASP面臨的缺陷更少。

4) 與沒有應(yīng)用敏捷技術(shù)的ASP相比，應(yīng)用敏捷技術(shù)開發(fā)的ASP的DSI較低。

5) 與沒有AUTILE框架的ASP相比，使用AUTILE框架開發(fā)的ASP出現(xiàn)的缺陷更少。

6) 與沒有AUTILE框架的ASP相比，使用AUTILE框架開發(fā)的ASP的DSI較低。

這項(xiàng)研究通過研究將標(biāo)準(zhǔn)化和敏捷系統(tǒng)工程（ASE）部署到汽車軟件行業(yè)的復(fù)雜性以及提出一個(gè)汽車軟件開發(fā)框架，對理論知識體系做出了貢獻(xiàn)。從更的角度來看，這項(xiàng)研究也有助于理解商業(yè)產(chǎn)品開發(fā)環(huán)境的標(biāo)準(zhǔn)化和ASE進(jìn)入具有既定流程的環(huán)境的復(fù)雜性。這項(xiàng)研究有助于一家的二級汽車軟件供應(yīng)商在實(shí)際應(yīng)用中通過部署AUTILE框架來開發(fā)ASP。這個(gè)實(shí)施項(xiàng)目提供了一個(gè)程序的概要，以及它們各自在汽車工業(yè)中的影響和優(yōu)勢。AUTILE框架提供了關(guān)于如何實(shí)現(xiàn)軟件標(biāo)準(zhǔn)化的好處和如何在在汽車公司的軟件開發(fā)中使用敏捷方法的見解。它也可以被汽車行業(yè)以外的公司使用，通過學(xué)習(xí)這項(xiàng)研究然后應(yīng)用到他們的流程中，以提高軟件質(zhì)量。

這項(xiàng)研究強(qiáng)調(diào)的結(jié)果為其他研究人員開辟了一條途徑，通過解決任何缺陷來為汽車公司擴(kuò)展AUTILE框架。研究的重點(diǎn)是提高汽車行業(yè)的軟件質(zhì)量。這項(xiàng)研究可以擴(kuò)展到其他行業(yè)，如對質(zhì)量有嚴(yán)格要求的航空航天業(yè)，或像醫(yī)療設(shè)備制造這樣對工藝非常關(guān)注的行業(yè)。還可以探索如何應(yīng)用到在零售業(yè)，目前該行業(yè)正被技術(shù)所顛覆。此外，這項(xiàng)研究可以在不同類型的產(chǎn)品和技術(shù)之間，或在不同的群體和國家之間進(jìn)行復(fù)制，以調(diào)查該框架對各種類型的軟件或在不同文化和地理環(huán)境中的效率。