摘要

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

1 引言

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

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

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

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

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

研究聲明：一個AUTOSAR驅(qū)動的敏捷開發(fā)方法將減少汽車軟件缺陷。考慮到這個汽車顛覆的時代，本研究考慮了兩個特征，以盡量減少汽車軟件缺陷及其嚴重程度 :

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

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

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

2 回顧

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

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

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

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

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

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

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

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

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

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

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

3 方法論

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

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

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

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

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

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

6) 對AUTILE項目進行假設(shè)測試；

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

A. AUTILE 框架

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

圖1. AUTILE框架-初始化

圖2. AUTILE 框架—計劃

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

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

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

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

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

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

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

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

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

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

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

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

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

沖刺評審、回顧和可發(fā)貨增量: 在Sprint周期結(jié)束時，計劃進行Sprint評審和回顧。這些活動的目的是為了從過去的錯誤中學(xué)習(xí)，以便在未來的項目中改進規(guī)劃。如果遺漏項目的話，則添加回產(chǎn)品Backlog中，以便重新確定優(yōu)先次序和調(diào)度。準備好產(chǎ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ù)、每個項目的平均缺陷數(shù)和DSI。

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

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

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

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

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

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

4 結(jié)果

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

G. AUTILE與AUTOSAR和Agile ASP的比較

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

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

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

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

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

這項研究終得出了以下結(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較低。

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

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