一种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提取的AUTOSAR专用ARXML格式，获得整体设计的可见性，实现相关的软件要求。为了达到严格的质量、可追溯性和审计要求，在此阶段收集的需求由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平均值。

H. 每个项目的平均缺陷 ：减少的实现

每个项目的平均缺陷用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框架。研究的重点是提高汽车行业的软件质量。这项研究可以扩展到其他行业，如对质量有严格要求的航空航天业，或像医疗设备制造这样对工艺非常关注的行业。还可以探索如何应用到在零售业，目前该行业正被技术所颠覆。此外，这项研究可以在不同类型的产品和技术之间，或在不同的群体和国家之间进行复制，以调查该框架对各种类型的软件或在不同文化和地理环境中的效率。

文章转载自公众号：智能汽车开发者平台