【行業動態】一種AUTOSAR驅動的敏捷開發方法，減少汽車軟件的缺陷

摘要

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

1 引言

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

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

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

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

問題陳述：汽車軟件的規模和復雜性正在增加，因此，現代汽車可能面臨數十萬的軟件缺陷。

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

1）基于AUTOSAR的標準化架構，提供更好的可擴展性、可維護性和可轉移性。

2）敏捷開發方法，目前在汽車軟件行業尚未使用。

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

2 回顧

A. 傳統汽車工業規則正在被入局者打破

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

B. 傳統的汽車軟件開發及其弊端

汽車軟件開發的特點是預先定義需求和嚴格的質量保證，這使得瀑布模型成為。在汽車行業，這個過程從收集客戶（原始設備制造商、級）的相關要求開始。第二級供應商主要關注之后的內部開發過程，并創建一個穩定的軟件設計和架構。隨后執行軟件開發、測試和集成階段。在這些階段中，客戶再次參與進來，并且只有當軟件滿足預定義的驗收標準時，軟件才會被部署。基于瀑布模型的軟件開發將風險和不確定性降到，特別是當需求在初始定義階段之后沒有變化，并且相關的技能組合可以用于開發時。它的其他優點包括有效的資源和財務規劃、防止 "范圍蠕變"、設計的準確性和的文件。

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

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

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

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

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

D. 汽車軟件標準化和AUTOSAR

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

3 方法論

本節描述了整個方法論，并以框架的形式將這些概念正式化，汽車軟件供應商可以用它來通過減少缺陷數量和DSI來提高軟件質量。本研究分六個階段進行，采用了幾種方法來實現其目標：

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

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

3) 對傳統/遺產項目和基于AUTOSAR和Agile的項目進行假設測試；

4) AUTILE框架的開發；

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

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

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

A. AUTILE 框架

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

圖1. AUTILE框架-初始化

圖2. AUTILE 框架—計劃

圖3. AUTILE 框架—執行

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

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

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

二級架構師、PO和開發團隊領導利用基于AUTOSAR的ECU提取的AUTOSARARXML格式，獲得整體設計的可見性，實現相關的軟件要求。為了達到嚴格的質量、可追溯性和審計要求，在此階段收集的需求由PO通過需求管理系統進行記錄。

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

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

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

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

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

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

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

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

沖刺評審、回顧和可發貨增量: 在Sprint周期結束時，計劃進行Sprint評審和回顧。這些活動的目的是為了從過去的錯誤中學習，以便在未來的項目中改進規劃。如果遺漏項目的話，則添加回產品Backlog中，以便重新確定優先次序和調度。準備好產品的可運輸增量。如果合同允許發送源代碼，則向客戶提供 .ARXML、.c 和 .h 文件。在其他情況下，則提供 .elf 或 .s19 等格式文件。

B. 研究假設

RH1：使用AUTOSAR的一些應用開發的ASP往往缺陷更少。

RH2：使用AUTOSAR的一些應用開發的ASP往往具有較低的DSI。

RH3：在某種程度上應用敏捷開發的ASP往往有較少的缺陷。

RH4：使用一些敏捷開發應用程序開發的ASP往往具有較低的DSI。

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

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

C. 變量

預測器/（Y）變量包括：AUTOSAR對ASP的應用和Agile對ASP的應用。同樣，響應/自變量（X）有：總缺陷數、每個項目的平均缺陷數和DSI。

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

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

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

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

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

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

4 結果

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

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

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

1) 個數據集（DS-1）：有AUTOSAR應用和沒有AUTOSAR應用的項目，以分析RH1和RH2。

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

3) 第三個數據集（DS-3）：遺產項目和應用AUTILE框架的項目，以分析RH5和RH6。

4) 第四數據集（DS-4）：AUTOSAR項目和應用AUTILE框架的項目。

5) 第五數據集（DS-5）：敏捷項目和應用AUTILE框架的項目。

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

A. 使用AUTOSAR的總缺陷：實現減少

2個樣本的T檢驗P值為0.028。檢驗結果證實，采用AUTOSAR的ASP的總缺陷平均值在統計學上低于采用傳統/遺產方法（不使用AUTOSAR）開發的ASP的總缺陷平均值。

B. 帶有AUTOSAR的DSI：實現減少

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

C. 使用敏捷的總缺陷：實現減少

2個樣本的T檢驗P值為0.009。檢驗結果證實，采用Agile的ASP的總缺陷平均值在統計學上低于以傳統/遺產方式開發的ASP（沒有Agile）的總缺陷平均值。

D. 采用敏捷的DSI：實現減少

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

E. 采用AUTILE的總缺陷：實現減少

2個樣本的T檢驗P值為0.002。檢驗證實，采用AUTILE的ASP的總缺陷平均值在統計學上低于采用傳統/遺產方法開發的ASP的總缺陷平均值。

F. 采用AUTILE的DSI: 實現減少

2個樣本的T檢驗P值為0.000。檢驗結果證實，采用AUTILE的ASP的DSI平均值在統計學上低于采用傳統/遺產方法開發的ASP的DSI平均值。

G. AUTILE與AUTOSAR和Agile ASP的比較

本節與任何研究假設沒有聯系。將AUTILE ASP與AUTOSAR和Agile ASP進行比較，以確定擬議框架的效率。在DS-4的案例中，通過兩個樣本的T檢驗，能觀察到總缺陷的P值為0.039，DSI的P值為0.048。測試證實，使用AUTILE的ASP的總缺陷和DSI的平均值在統計學上均低于使用AUTOSAR方法開發的ASP。

就DS-5的總缺陷而言，經2個樣本T檢驗，得到結果P值為 0.190。這并不低于0.05的α值。雖然AUTILE ASP的總缺陷平均值低于Agile ASP的總缺陷平均值，但這一發現無法通過獲得的樣本進行統計確認。因此，針對一個變量（總缺陷），無法確定所提出的框架對敏捷ASP的有效性。為了獲得進一步的了解，建議增加項目的樣本量。然而，這個行為超出了本研究的范圍。就DS-5案例中的DSI而言，通過2個樣本的T檢驗，P值為0.013。檢驗結果證實，AUTILE ASP的DSI平均值在統計學上低于Agile ASP的DSI平均值。

F. 每個項目的平均缺陷 ：減少的實現

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

5 結論、貢獻和建議

這項研究終得出了以下結論：

1) 與不使用AUTOSAR的ASP相比，使用AUTOSAR的某些應用開發的ASP面臨較少的缺陷數量。

2) 與不使用AUTOSAR的ASP相比，使用AUTOSAR的某些應用開發的ASP的DSI較低。

3) 與沒有應用敏捷的ASP相比，應用敏捷開發的ASP面臨的缺陷更少。

4) 與沒有應用敏捷技術的ASP相比，應用敏捷技術開發的ASP的DSI較低。

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

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

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

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