内容提要：本专题连载共分为“上、下”两个部分。此文为该连载系列的“上”部分，我们将对相关主题、背景信息和案例进行介绍，并对研究问题、数据收集方法和数据分析策略进行了具体阐述。

摘要

ASPICE在汽车行业中可以用于功能安全合规性。本指南使用瀑布/V模型进行软件开发。然而，汽车公司正在将工作方式转变为敏捷的软件迭代开发。融合这两种开发方法时，仍然存在的挑战之一是确保工作产品及其相应文档的关键安全性，因为大公司使用的扩展敏捷框架(SAFe)没有考虑这一点。因此，本文深入研究了沃尔沃汽车ART转向部门Aurora团队的软件流程，提出了一种新的文档管理策略，允许使用敏捷软件开发，同时仍符合A-SPICE。为了实现这一目标，我们进行了积极的观察和访谈来收集数据。适应的文档管理策略的创建表明，在大型汽车公司中采用敏捷开发实践并且仍然符合A-SPICE是可能的。

本专题连载共分为“上、下”两个部分。此文为该连载系列的“上”部分，我们将对相关主题、背景信息和案例进行介绍，并对研究问题、数据收集方法和数据分析策略进行了具体阐述。1.简介

过去几年，电子系统在汽车行业的使用不断增加，因为现代汽车的大部分功能现在都是由复杂的软件控制的。软件复杂性的逐渐增加也导致汽车行业项目复杂性的逐渐增加。随着更复杂项目的并行执行和更短的模型生命周期，以及客户对舒适性和安全性的期望越来越高，在汽车领域交付软件产品时需要遵循稳定的开发流程。因此，VDA（Verband der Automobilindustrie–汽车工业协会）同意设立Automotive SPICE® 作为标准过程模型。该模型提供了定义、管理和改进系统和软件开发流程的指南，特别是针对汽车行业。

如今，越来越多的开发公司正在将工作方式转变为更敏捷的迭代软件开发工作方式。通过采用这种方法，开发团队的目标是从更快的交付、更高的可交付成果质量以及更强的应对变化的能力中受益。此外，通过敏捷工作，需求和解决方案可以通过与客户的协作来发展。

在大型汽车公司中，许多团队共同开发和交付产品。因此，为了实现产品的最终交付而协调和组合这些不同的工程学科可能会很麻烦。因此，为了管理这种复杂性，许多汽车公司正在采用大规模敏捷框架，例如SAFe等，以加快产品的开发并管理不同团队和工件的交换。然而，这些框架不考虑风险管理、安全分析或生成用于创建安全关键系统的相应文档，因此不提供ASPICE合规性。

结合敏捷和A-SPICE方法论的许多剩余挑战之一，包括调整规模化敏捷框架以满足敏捷性需求并生成必要的文档（工作产品）以遵守单个团队之外的A-SPICE。

这仍然是一个挑战，因为敏捷实践更注重产品的更快交付和跨职能团队协作，而不是文档。与ASPICE相反，其中文件为产品发布认证提供了基础，并且对于确保产品的功能安全是必要的。大量参与生产车辆的组织，以及许多物理位置和学科，以及专门为汽车领域建立的工具链，造成了这个特殊的问题。

据我们所知，还没有研究尝试对大公司进行这样的调整，特别是在汽车领域。

因此，本研究的目的是找到一种将A-SPICE和敏捷方法相结合的方法，以生成和记录所有必要的文档，确保快速生成的交付物符合安全标准。为了实现这一点，有必要事先知道根据A-SPICE应该生成和记录哪些信息，如何记录和生成这些信息，以及在敏捷迭代开发过程中何时生成和记录信息。这就是为什么研究问题制定如下：

RQ1.在遵循汽车行业的敏捷开发流程的同时，需要生成哪些信息才能符合ASPICE要求？

RQ2.如何收集和记录敏捷开发过程中产生的信息以确保A-SPICE合规性？

RQ3.在敏捷开发过程的不同阶段，何时需要生成、收集和记录信息？

由于目标是提供SAFe与A-SPICE工作产品相适应的示例，因此需要制定文档管理策略来回答RQ2和RQ3。因此，该文档管理策略可以作为如何改进前面提到的结合SAFe和A-SPICE时发现的问题的建议。

该文档管理策略的创建是与沃尔沃汽车的ART指导部门（具体是Aurora团队）合作完成的。

该专题连载的结构在“上部分”的第2节介绍了主题、背景信息和案例相关描述，第4节介绍了相关文献，并在第4节描述了研究问题、数据收集方法和数据分析策略。在该专题连载的“下部分”的第6节介绍结果，第7节根据研究问题讨论结果的主要发现。研究结论在第8节中提出。

2.背景

A.ASPICE

ASPICE定义了符合功能安全所需的基本实践和流程。它是确保系统和软件开发成熟、系统且文档齐全的指南。

该模型遵循开发过程的V模型表示，并且被沃尔沃汽车认为是瀑布开发模型的扩展。这意味着每个开发阶段只有在前一阶段完成后才会开始。A-SPICE V模型和瀑布模型之间的关系在其他公司可以有不同的解释。

A-SPICE过程参考模型概述

V模型将软件开发过程分为主过程的两个方面。V模型的左侧是关于软件需求分析、设计和单元构建，而右侧则集中于软件的主要验证和确认，其中测试与每个相应的开发阶段相关联。

ASPICE还用于能力确定。建立能力级别的目标是设置流程属性，这些属性是可以在流程实现的规模上进行评估的流程特征，提供流程能力的度量。由属性集表征的能力级别一起工作以提供执行过程的能力的增强。

根据ISO/IEC 33020，有六个能力级别，包含九个过程属性，分别为0级“不完整过程”和5级“创新过程”。因此，需要创建、管理、应用和维护某些策略，以达到最高的能力水平，其中创建的流程不断改进以响应组织变革。

基础实践的另一个A-SPICE特征是，它的大多数工作产品，例如SWE.1-6、SYS.2-5和SUP.10，必须从需求到测试用例向前追溯，从测试用例到需求向后追溯。双向可追溯性记录在单个文档中，称为需求可追溯性矩阵。它确保所有指定的需求都有相应的测试用例，反之亦然。这是结合硬件和软件的嵌入式系统所需要的，以确保产品的安全和质量。

B.敏捷框架SAFe

SAFe是一种开发软件和项目管理方法的迭代方法，可帮助团队快速、增量地向客户交付价值。需求、计划和结果被持续评估（持续增量），因此团队可以快速响应变化。这种方法的重点是为跨职能团队提供支持以及持续的沟通和反馈，最大限度地减少开发过程中的工件数量，从而减少软件开发和设计的文档。

这家特定的汽车公司采用了Scaled Agile提供的完整SAFe框架，因为它是专门为大型组织创建的。它结合了精益产品开发原则和敏捷原则。该框架用于实现敏捷性，可以根据公司的需求和情况进行调整。

SAFe 5.0敏捷框架–完整SAFe概述（Scaled agile，Inc.“SAFe 5.0”）

完整SAFe中包含的不同级别是团队级别、项目级别、大型解决方案级别和产品组合级别。

1）团队层面

操作方式类似于Scrum和/或Kanban。开发团队由五到九名开发人员和测试人员组成，他们跨职能工作，以在两周的冲刺间隔结束时交付预期的产品。产品负责人(PO)是冲刺待办事项的负责人，也是进行冲刺计划、计划增量、待办事项细化以及进度报告或演示的人。他还在日常会议中与团队互动，讨论进展情况，并在冲刺回顾中讨论如何改进即将到来的冲刺。所有这一切都由Scrum Master指导，他确保团队不受限制地有效工作。

2)程序级别

此级别与团队级别类似，但扩展到5到12个团队，他们共同努力为产品提供完整的工作解决方案。由于其持续交付实践，这种团队协作交付预定功能以规划和交付产品被称为敏捷列车发布（ART）。

项目增量(PI)之于ART，就像迭代之于敏捷团队一样。每个PI由6个冲刺组成。在PI期间，不同的团队构建并验证完整的系统增量，展示价值并获得快速反馈。此外，他们还与ART一起规划下一步的增量工作。

在这个级别上，产品管理的行为类似于团队级别上的PO，因为它决定应该向每个PI交付什么以及计划待办事项的内容。

发布列车工程师充当ART的Scrum Master，确保一切按计划运行。

每个PI规划都从与所有团队举行的规划会议开始，他们在会上讨论PI结束时要完成的功能。

3)大型解决方案级别

在这个层面上，积压的内容被称为能力，它由几个特性组成。

在这里，拥有最高权力的解决方案管理人员与解决方案培训工程师合作，以确保在ART中使用正确的架构。

4)投资组合级别

精益投资组合管理(LPM)是负责投资和资源的支持和预算分配的小组。产品待办事项列表包含史诗，由ART产品管理层检查以在每个PI期间解决它们。

3.案例描述

在本节中，我将解释Aurora团队目前在使用敏捷和A-SPICE时面临的问题。

沃尔沃汽车ART转向部门的内部软件开发团队Aurora最近将工作方式转变为更加敏捷的软件开发流程。通过敏捷工作，团队旨在从更短的交付时间中受益，更快地响应变化，改善客户协作，生产更高质量的软件。作为汽车公司的内部供应商，他们必须确保其实践符合A-SPICE，以确保软件开发体系成熟、系统且文档齐全。为此，必须达到至少3级的能力。

内部团队目前使用的敏捷方法和实践是汽车领域的Scrum、持续集成(CI)和测试驱动开发(TDD)。其中一些敏捷实践包含在团队级别的公司采用的框架中，称为“规模化敏捷框架”或SAFe。团队以冲刺计划开始为期两周的冲刺，然后是开发阶段和测试阶段。在冲刺结束时，会举行冲刺演示和冲刺回顾等活动，以获取反馈并展示进度。待办事项细化将在第二个冲刺的中间进行，以保持冲刺待办事项的更新。

敏捷开发过程——Scrum团队级概述

Aurora软件开发团队在使用SAFe框架工作一年多后意识到，很难将A-SPICE融入他们的敏捷方法中，以生成必要的文档来遵守ASPICE安全标准。他们缺乏一个文档管理策略来作为适应这两种软件开发方法的指南。如果没有将所有A-SPICE工作产品映射到其敏捷实践的必要策略，提供大多数A-SPICE实践所需的双向可追溯性就会成为一件危险的事情，尤其是在跨职能团队环境中工作时。原因是，在使用敏捷迭代开发流程的大型汽车公司中，参与变更的团队成员必须经常修改文档。此外，文档中的这些更改可能不会被提供者和其他团队成员察觉。

为了保持这种双向可追溯性，A-SPICE要求软件开发团队填写需求可追溯性矩阵文档等。它记录了哪个需求被哪个测试所测试，在需求和测试之间建立了跟踪链接。该文档需要由负责此类任务的人员填写，如前所述，很难跟踪何时执行更改以及文档是否包含最新信息。

4.相关文献

在本节中，我们将介绍与我们的研究相关的文献：结合敏捷软件方法和A-SPICE的文档管理策略。

结合A-SPICE和敏捷方法论来调查文档管理策略的研究数量有限。现有关于敏捷和ASPICE的研究主要集中在汽车领域的软件可追溯性问题以及确定其挑战和解决方案。相反，其他研究往往关注敏捷实践如何支持A-SPICE合规性，但不关注大规模敏捷框架。

Diebold等人根据文献综述和专家意见，对敏捷实践如何支持ASPICE需求进行了评估，并包括722个敏捷实践（包括Scrum）和ASPICE需求的映射。他们发现，155个敏捷实践中的103个涵盖了185个A-SPICE需求中的173个，这意味着大多数A-SPICE基础实践都得到了支持(96%)，而工作产品(87%)得到的支持较少。他们的结论是，汽车行业的公司可以从敏捷开发流程中受益，而不会影响A-SPICE和功能安全。与Diebold 等人的类似研究支持这些发现。只有Kähkönen和Abrahamsson进行的一项研究与Diebold等人的研究结果相矛盾，指出这两种方法相互矛盾，因此不能合并。

关于需求可追溯性矩阵的挑战，Maro等人的研究结合了详尽的文献综述和一家汽车公司的案例研究，介绍了汽车领域软件可追溯性实践中遇到的挑战和解决方案（参考资料1，关注牛喀网公众号，后台咨询下载）。

他们在案例研究中确定了17个挑战，其中6个挑战尚未解决。通过文献综述和案例研究，报告最多的一些内容是手动链接创建和维护。作者针对这些挑战提出的解决方案，是实现集成工具平台的使用和文档的自动化。公司的案例研究和文献综述都认为链接创建是一种开销，因为链接需要由开发人员手动创建。应对这一挑战的解决方案是再次自动化文档，并使用提供从一个工件到另一个工件的快速导航的工具。Amalfitano等人也提出了可视化技术作为应对这一挑战的解决方案。

ART转向部门的Aurora团队发现了与文献中发现的类似挑战。手动创建可追溯性链接并维护它们，对于团队来说仍然是一项乏味的任务，因此应提供所生成文档的部分自动化解决方案。

与发现的其他文献相比，仅发现三篇文章与本研究的目的相似，其中一篇是前面提到的Diebold等人的研究。另一项是Hantke所做的研究。他为两个A-SPICE流程软件测试和软件需求分析提供了Scrum实践和SPICE基本实践的覆盖矩阵。他发现大多数工程组流程（A-SPICE中的“ENG”）都是由团队根据其特定的业务需求在冲刺中针对特定于项目的任务执行的。

然而，与这项具体研究最相关的是Komiyama等人的案例研究。在他们的研究中，他们面临并解决了与流程改进相关的问题，例如集成scrum和A-SPICE，并直观地展示在项目期间如何以及何时应用和调整实践。他们阐明了A-SPICE和敏捷软件开发应用中的问题，描述了解决已识别问题的适应策略和方法，并提供了考虑敏捷和ASPICE合规性的实施实例。然而，他们的方法只适用于以前没有使用过Scrum的小公司。

因此，本研究将采用与Komiyama等人类似的方法，但它将侧重于更实用的解决方案，以满足公司在敏捷和ASPICE方法的适应方面的需求。

5.研究方法

本研究选择的研究方法是案例研究。这被认为适合本研究，因为该研究是自然环境中的当代案例。因此，研究人员与Aurora开发团队合作，以开发诊断问题的解决方案。更具体地说，由于本研究试图改进所研究现象的某个方面，例如找到一种记录所产生信息的方法，因此本研究可以被视为改进案例研究。

A.研究问题

为了回答研究问题，我们需要提出、诊断和调查团队流程中当前缺失的数据。为了实现这一目标，我们需要知道在制定文档管理策略之前应该收集和生成哪些信息；他们将如何收集这些信息，以及何时在符合ASPICE合规性的敏捷开发流程中生成这些信息。

因此，本案例研究拟回答的研究问题如下：

RQ1.在遵循汽车行业的敏捷开发流程的同时，需要生成哪些信息才能符合ASPICE要求？

RQ2.如何收集和记录敏捷开发过程中产生的信息以确保A-SPICE合规性？

RQ3.在敏捷开发过程的不同阶段，何时需要生成、收集和记录信息？

除了文件管理策略流程的设计之外，工作流程的观察还将在沃尔沃汽车的ART指导部门现场进行。这些观察的目的是回答前面提到的研究问题，并帮助创建新的文档管理流程，以了解新策略是否能够满足组织的需求及其遵循的标准。

B.研究时间表

研究时间表由五个主要阶段和一个初始阶段组成。初始阶段的目的是更好地了解团队在A-SPICE差距分析中提供的信息及其缺失的敏捷开发流程。其他阶段涉及创建适应的文档策略以满足团队需求所需的步骤。

图1显示了工件创建过程的周期。

图1：工件的创建时间线

1)研究和数据收集阶段

在研究的第一次迭代中，此阶段的目标是了解ASPICE的要求与团队当前应用的流程之间的差距。为此，使用了A-SPICE实践与当前作为流程一部分执行的活动之间的映射，作为许多半结构化访谈的基础。通过将A-SPICE实践的描述与流程步骤的描述进行比较来分析映射。每当发现不匹配时，就在访谈指南中添加相应的问题。

第一次迭代之后，此阶段包括获取必要的数据，以便稍后为初始阶段中识别出的缺失流程生成调整后的文档策略。这是通过对团队进行半结构化访谈并积极观察团队的敏捷实践来完成的。

2)规划阶段

此阶段的重点是规划新的文档管理策略。新的战略原型是与团队合作制定的，以适应他们的敏捷流程并确保符合A-SPICE。规划策略时考虑了前一阶段的信息。此外，还进行了半结构化访谈，以澄清问题并观察团队的实践。

3)创建阶段

创建阶段包括创建提议的和先前计划的文档管理策略。这是通过使用必要的工具正确记录团队在工作实践中产生的信息，并使用适用于敏捷软件开发流程A-SPICE推荐的基本实践来实现的。

4)评估阶段

在评估阶段，向团队展示了之前创建的策略。在此阶段，向团队展示了包含新文档策略的功能和解决方案的相应图表，并通过采访团队成员进行评估。

评估和演示工件的目的是获得必要的信息和反馈，以便以后能够调整策略。

在此阶段进行了半结构化访谈，以获得团队必要的反馈。

5)学习和适应阶段

在此阶段，将对前阶段访谈收集的数据进行评估。这些数据用于进一步调整他们的敏捷实践以适应所提出的文档管理策略，并进行必要的更改以满足他们的需求，同时仍然确保A-SPICE \合规性。

C.数据收集策略

1)受试者

数据收集的对象是沃尔沃汽车内部ART Steer部门Aurora团队的成员。该团队由六名软件开发人员、产品负责人和Scrum Master组成。大多数团队成员平均拥有四到六年的软件开发经验，在沃尔沃汽车工作一年到五年。在敏捷软件开发流程方面，所有团队成员都拥有丰富的敏捷软件开发经验。平均有三年工作经验。对于A-SPICE，除了一名没有任何A-SPICE工作经验的团队成员外，所有团队成员都熟悉这种方法，并且已经使用它大约两年了。

2)数据类型

收集的主要数据类型是定性类型，因为数据收集的主要方法是访谈以及主动和被动观察。

3)数据收集方法

收集数据的方法是现场进行的半结构化访谈、档案数据的文献分析以及对其过程的主动和被动观察。

a)访谈

进行的访谈是半结构化类型。访谈包括与新文档策略的规划和实施过程相关的准备好的问题。此外，它们还用于获取直接反馈，并解决收集有关团队敏捷实践的数据和信息所需的问题。每次访谈平均持续30分钟。

在研究和数据收集的初始阶段总共进行了两次半结构化访谈，在工件时间线创建的剩余阶段又进行了十四次访谈。

表1显示了在工件创建周期的不同阶段进行的访谈数量、接受访谈的团队成员数量及其在团队中的角色，以及何时进行观察。

“进行的采访”一栏显示了每个工件时间线创建期间进行的采访总数。

“受访者角色”一栏显示了进行采访的受访者的角色。一些软件开发人员在工件时间线创建的不同阶段接受了两次或更多次采访，例如，在评估阶段，一名软件开发人员接受了三次采访，而另一名软件开发人员只接受了两次采访。研究和数据收集阶段也是如此，其中Scrum Master接受了一次采访，产品负责人接受了两次，其中一名软件开发人员接受了两次，剩下的软件开发人员只接受了一次采访。

表1.访谈概述

对不同团队成员的访谈是亲自进行的，并且单独与每个团队成员进行，其中向相关团队成员提出了几个问题。如果团队成员无法亲自参加采访，则可以通过电子邮件、电话或视频聊天提出问题。

这些信息是通过笔记和录音记录的。在访谈开始之前，要求受试者口头同意并进行记录。

b)观察结果

进行了非结构化观察，观察者的角色被假定为参与者。这些信息以现场笔记的形式记录，其中包含日期、唯一标识符、观察摘要以及对其进行的评论。

观察结果分为两组：

•积极观察：参与团队的日常站立会议、冲刺计划和回顾。会议期间提出了一些问题，以更好地了解他们的敏捷实践和流程。在每日站立会议期间报告了文档管理策略的进展情况。在回顾过程中，也与团队一起积极参与回答哪些进展顺利或哪些可以为下一个冲刺改进。

•被动观察：对两个团队计划增量(PI)流程进行了观察。项目增量期间团队进行的会议和演示都没有积极参与，只是作为旁观者。

D.数据分析

用于分析收集的定性数据的数据分析方法是常规内容分析。内容分析的目标是将大量文本转换为关键结果的有组织的摘要，以便更好地理解主题并帮助创建工件。它包括对沃尔沃汽车提供的采访、观察和文件中的口头和文本数据的系统分类。数据的编码和类别标记是在数据分析过程中根据研究问题定义的。

对数据进行内容分析的步骤如下：

•选择要分析的内容。在这种情况下，是在访谈和观察过程中所做的转录和笔记。

•通读访谈记录。选择与研究问题相关的数据。然后，根据与哪个研究问题相关，创建并将其分类为不同的类别。每一份现场笔记和成绩单都是如此。

•一旦数据被分类为主要类别，这些数据回答任何“哪个”、“何时”和“如何”问题，就会审查该列表，以检查这些类别中包含的数据是否与研究问题和工件的创建相关。

•如果数据不属于任何已确定的类别，则创建一个新的子类别并审查它是否与研究相关。

•完成类别编码后，将对收集到的数据进行检查，以找出模式并针对研究问题得出结论。

图2概述了数据分析过程。

图2.数据分析流程概述

关于专题上部分所研究问题、数据收集方法和数据分析策略的具体结果与结论等更多内容，请关注“敏捷软件开发过程中的ASPICE合规性（下）：研究问题的结果与结论”，关注牛喀网，或者登录牛喀网智能汽车开发者社区(www.i-newcar.com)学习更多汽车科技。有兴趣的朋友，可以添加牛小喀微信：NewCarRen，加入专家社群参与讨论。

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！