内容提要：此文为该连载系列的“下”部分，我们将深入阐述所研究问题、数据收集方法和数据分析策略的具体结果与结论。

本专题连载共分为“上下”两个部分。此文为该连载系列的“下”部分，在之前的“上部分中，我们已经针对“研究问题、数据收集方法和数据分析策略”进行了具体解析。那么在“下部分”中，我们将深入阐述所研究问题、数据收集方法和数据分析策略的具体结果与结论。

添加牛小喀微信：NewCarRen，回复"直播课咨询"，参加福利活动

6.结果

本研究的主要目标是制定一个文档管理策略，映射哪些信息是使敏捷软件开发实践适应A-SPICE功能安全性所必需的，以及在敏捷软件开发周期中如何生成这些信息。

A.采用A-SPICE进行敏捷开发的问题

表2显示了团队在将A-SPICE应用于敏捷开发方法时面临的问题。该表基于在研究和数据收集的第一次迭代期间进行的访谈中收集的数据，以及“上部分的第2节”中涵盖的ASPICE和敏捷方法的背景信息。供应商监控(ACQ.4)被排除在外，因为它不适用于本例，因为团队“只做内部软件”（软件开发人员）。添加产品发布(SPL.2)是因为他们“向客户发布产品，在本例中也是沃尔沃汽车”（软件开发人员）。

这些采访中提到的一些问题是在与不同团队合作时难以保持文档更新并通知必要的相关方。保持工作产品之间的一致性也被认为是一个问题，因为不同的团队可能会使用不同的内容填充文档模板。尽管如此，接受采访的团队成员指出，他们最相关的问题是建立和维护工作产品的可追溯性，生成和更新文档模板。正确的A-SPICE合规性文档，并拥有生成这些文档的工具链。

在观察和参与团队的冲刺计划/PI计划、每日站立会议和冲刺回顾期间获得的现场记录有助于发现表2中提出的其余问题。观察中发现的问题是难以解决的问题。在问题解决管理的情况下，在大公司中委派角色职责，监视和控制冲刺中的日常进度，管理短期重复产品发布，同时为客户生成必要的文档。

表2.应用A-SPICE进行规模化敏捷软件开发时发现的问题概述

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

创建了两个表来呈现回答RQ1需要生成哪些信息的映射。表3列出了需要根据A-SPICE生成的文档与其相应的基本实践的映射，以及需要包含在此类文档中的信息的描述。

关于SAFe敏捷实践和持续集成工具建议的专栏包含产生此类信息的敏捷实践以及包含这些信息的工具。这回答了敏捷开发过程中需要生成哪些信息的问题。

表3.要生成的A-SPICE信息及其安全实践–概述图

为了映射需要生成的文档，VDA A-SPICE 3.1标准文档被用作生成此类信息的参考。一旦确定了必要的文件，它们就会与相应的A-SPICE基本实践相匹配。这些基本实践定义了为了实现流程结果而需要完成的任务和活动。需要根据这些基本实践生成哪些信息的描述映射在“根据A-SPICE需要制作哪些信息”列中。

“持续集成工具的哪些SAFe实践和工具生成信息”一栏用于识别SAFe框架中包含的敏捷实践，这些实践生成所识别的A-SPICE文档中包含的所需信息。在团队的冲刺计划、计划增量计划、积压工作细化、每日站会、回顾和配置管理工具使用演示期间所做的现场笔记被用来帮助创建本专栏。还使用了在研究和数据收集阶段以及工件生命周期的规划阶段进行的访谈。访谈产生的信息包括对这些会议期间团队活动的解释、他们如何管理产品开发以及他们为此目的使用了哪些工具。

表4介绍了A-SPICE工作产品、信息的生成将如何被敏捷方法和持续集成工具所取代，以及信息是如何生成的。由于它概述了如何收集所产生的信息以及为此目的使用了哪些工具，因此它也部分涵盖了RQ2的部分内容。

在工件的研究、数据收集和规划阶段所做的现场笔记用于帮助创建表4。观察是在团队的冲刺规划、项目增量规划、待办事项细化、每日站会、回顾和总结期间进行的。演示其配置管理工具的使用情况。团队在这些敏捷实践期间执行的活动有助于确定如何使用正确的工具生成信息，以及他们的哪一项SAFe实践正在生成ASPICE工作产品必须涵盖的信息。

表4.A-SPICE工作产品被敏捷方法和生成它们的持续集成工具所取代

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

为了展示如何在敏捷开发过程中收集前面提到的信息，创建了一个图表，显示不同的持续集成工具如何相互交互以生成必要的A-SPICE报告。图3展示了这种交互。这个数字是在规划阶段与Aurora团队的三位软件开发人员合作规划的。访谈涵盖了配置管理工具和持续集成工具的使用和性能。规划阶段访谈中产生的信息在实施阶段用于创建工具链图。

为了能够保存A-SPICE推荐的策略和指南文档，开发人员可以选择编写这些策略和指南，并将其保存在基于web的协作平台（如SharePoint或类似平台）中，以供团队共享，并将它们存储在分布式版本控制系统中，以跟踪源代码（如GIT/Gerrit）中的更改。

团队任务是使用软件配置管理工具（SCM）（例如JIRA）创建、存储和管理的，团队可以在冲刺计划期间计划他们将要执行哪些任务。这个特殊的SCM工具还具有创建产品路线图以及问题、风险和变更请求报告的功能。

功能和非功能需求存储在嵌入式系统的开发平台中，例如SystemWeaver。此应用程序用于生成需求规范报告、软件体系结构报告和软件功能规范报告。SystemWeaver可以配置为支持SCM工具，例如JIRA，从而共享需求。这是提供需求可追溯性，并在SCM工具中更新它们所必需的。对于这两个应用程序，可以使用正确的插件生成需求可追溯性矩阵。

一旦开发人员编写了源代码，就会出现一个驱动持续集成、交付和部署的程序，例如Zuul用于监视、构建和运行测试，无需管理跨域资源共享(CORS)和一对一身份验证。然后使用持续集成服务器工具，例如Jenkins，并行运行不同的测试，以提供持续集成。

持续集成服务器（例如Jenkins）运行测试工具（例如CANoe）进行功能测试，并生成软件功能测试规范报告。此报告存储在通用工件存储库管理器中，例如Artifactory。

并行运行的持续集成服务器工具（例如Jenkins）还执行来自测试驱动的开发工具（例如Ceedlings）的测试，该工具提供自动测试发现、模拟生成和测试执行。单元测试产生的报告是更改日志报告和发布说明报告。

用于持续检查代码质量的工具，例如SonarQube，

添加牛小喀微信：NewCarRen，回复"软件测试"，免费试用申请

用于确保源代码和测试用例中的代码质量和错误识别。此应用程序生成的报告是软件鉴定测试规范报告。源代码中的错误报告和问题也会报告给分布式版本控制系统，用于跟踪源代码中发生的更改，例如GIT/Gerrit。

前面提到的所有测试报告都被压缩为zip文件，并保存在通用工件存储库管理器（例如Artifactory）中，在那里将对其进行标记并创建标签以便对它们进行排序。

文档生成工具（例如Doxygen）将用于生成与源代码相关的文档。此报告将包含代码函数和变量的作用说明。它由分布式版本控制系统（如GIT）生成，并存储在通用工件存储库管理器（如Artifactory）中。

持续集成服务器工具（例如Jenkins）也可以处理作业的状态报告，以便向开发人员提供状态的可视化。

为了提供进一步的可追溯性，可以使用插件将测试用例和不同的测试应用程序集成到SCM工具中，例如JIRA。这对于维护更新的需求可追溯性矩阵是必要的。

图3.工具链和文档创建–概述

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

SAFe框架中有两个主要的敏捷开发流程，团队定期参与其中。其中之一是为期两周的冲刺以及管理、开发和发布产品所需的活动。另一种是项目增量规划（PI规划）。这样做是为了规划在接下来的六个冲刺期间将要开发和生产的内容，并展示在之前的冲刺期间已完成的工作。

创建以下两个图表是为了概述冲刺和PI计划文档的创建时间。不同ASPICE实践与其各自工作产品的映射已作为注释添加。此外，敏捷活动映射到相应的A-SPICE流程。这两个图表都是根据团队敏捷实践的访谈和观察提供的反馈创建的。

图4显示了PI规划活动以及相应的A-SPICE流程及其随每个活动生成或更新的工作产品。不同工作产品的生产应该用颜色编码，以区分哪些产品必须创建和存储一次，或者在活动期间是否需要修改“最好区分我们什么时候必须修改文档，或者我们只需要创建一次文档并与团队其他成员共享，例如不同的策略”。因此，在PI计划和冲刺计划活动期间，使用不同的颜色来区分何时需要更新或创建A-SPICE工作产品。

蓝色的文档是需要考虑创建的文档（如果适用）。在这种情况下，软件设计描述、软件风险矩阵、PI规划回顾报告和系统演示报告只需在PI规划过程中创建一次。

红色文档是对以前现有文档的更新或修改，例如需求可追溯性矩阵、产品路线图、SCM工具（例如JIRA和需求规范文档(SWRS)。这些报告通常使用前面提到的工具自动生成。

绿色文件是指团队在PI规划实践期间使用SCM工具（如JIRA）或嵌入式系统开发平台（如SystemWeaver）更新信息的文件，因此无需生成单独的书面报告/文件。最后，用黑色标记的文件是在PI规划之前已经生成的文件，但需要存储在基于web的协作平台中，例如SharePoint或类似工具，以符合A-SPICE基本实践。需要创建的策略包括软件开发计划、软件分析、PI目标文件和软件配置管理计划。

图5显示了冲刺活动以及相应的A-SPICE流程及其随每个活动生成或更新的工作产品。

图4.使用A-SPICE流程和工作产品的PI规划活动-概述

图5.冲刺和A-SPICE流程以及工作产品-概述

该图映射了不同文档的生成时间以及在冲刺生命周期期间需要创建（如果适用）和/或更新哪些文档。访谈和现场笔记的使用方式与图4相同，因为这两个数据同时呈现给团队成员。

为了区分何时需要创建、更新或自动记录/生成不同的工作产品，创建了颜色标签。

待办事项细化活动仅在为期两周的冲刺的第二周中间举行一次，以保持待办事项的更新，并且仅包括与当前冲刺相关的用户故事。

黑色标记的文件表示该文件只需制作并保存一次。如果对策略进行任何更改，无论冲刺阶段如何，团队中的负责人都应该更新它们。这些文档存储在共享位置，以便其他团队可以访问它们。质量保证策略和配置策略等文档仅映射到其相应的A-SPICE流程和基本实践。它们不属于任何冲刺活动，但需要使用任何上述工具来生成和存储，以符合功能安全性。软件合格测试规范是一份包含自动化工具生成的所有报告信息的报告，并在测试阶段收集在基于网络的协作平台（例如SharePoint）中。

红色文档需要在每个相应的冲刺活动期间更新和/或生成。当冲刺计划期间做出的任何决策影响产品路线图时，冲刺路线图文档就会更新。团队速度图表报告、进度报告和冲刺回顾分别在冲刺计划阶段和发布阶段创建。关于质量审核，只有在开发阶段进行此活动，才会创建和更新必要的文件。质量审核是检查或审查开发过程以确保符合要求所必需的冲刺活动。质量审核活动可以在6周PI期间的第三个或第四个冲刺期间执行一次。

只要软件和系统需求发生任何变化，需求可追溯性矩阵文档就会更新。这些变更通常在冲刺规划和开发阶段执行，更具体地说是在软件实施实践期间执行。

蓝色文档对应于使用软件配置管理工具（如JIRA）自动记录、管理和更新的信息。如果需要，可以使用此工具生成报告。

最后，绿色标记的文档是在不同的冲刺活动期间自动生成的。使用必要的工具生成和存储报告（见图5）。不同报告的自动生成在测试阶段和发布阶段并行发生，特别是在发布过程活动期间。

E.评估

在评估阶段，我们与Aurora团队的三位不同的软件开发人员进行了三次访谈，以获得反馈并根据他们的需求进一步调整文档管理策略。

在第一次评估访谈中，Aurora的一位软件开发人员收到了为将冲刺和PI规划与ASPICE流程和工作产品进行映射而创建的图表（图4和5）。开发人员认为，这样的图表直观地展示了团队敏捷实践中需要制作哪些文档，“能够帮助团队更好地了解需要制作哪些文档以及何时制作”（Aurora团队软件开发人员）。

在评估阶段进行了三次采访，以评估图3中所示的工具链图。Aurora团队的三位不同的软件开发人员分别接受了采访，以获得他们对所显示的图的见解。其中一个提供了反馈，用于识别工具链中缺失的流程，例如测试用例的创建，因为它们在第一个版本中缺失，“工具链看起来不错，似乎映射了所有管理工具，我们与持续集成工具一起使用。然而，我认为唯一缺少的是测试用例的创建以及它们如何与JIRA交互，以确保双向可追溯性与需求可追溯性矩阵的要求”（Aurora团队的软件开发人员）。然后，测试用例被添加到图3所示的工具链图的最终版本中。另一位人士认为，某些工具是沃尔沃汽车特有的，因此应将它们更改为类似的工具“我认为你不应该包括X和X是沃尔沃汽车专用工具，你可以将它们更改为与公司无关但具有相同目的的类似应用程序”。因此，最终版本的工具链图中没有使用沃尔沃汽车的特定工具，而是使用了类似的工具。无论收到的反馈如何，三位开发人员都认为所提供的工具链满足了团队的需求，正确地展示了团队的管理工具与其CI工具的集成，并正确地映射了如何使用这些工具生成文档。

最后一次评估访谈是针对表3和表4进行的，以评估表中包含的信息。Aurora团队的一位软件开发人员参与了采访。开发人员认为这些表格的目的是突出显示需要生成哪些文档，以及应在生成的报告中呈现哪些信息“这些表格有助于显示我们需要填写哪些文档。很好地展示了ASPICE需要哪些信息以及我们如何在敏捷实践中生成这些信息”（Aurora团队的软件开发人员）。

7.讨论

在本节中，讨论了结果部分中遇到的主要发现，并提出了有关研究可重复性的局限性。

A.主要发现

根据每个研究问题讨论主要发现。此外，还描述了文档管理策略如何帮助团队调整敏捷实践以提供A-SPICE合规性。

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

在文档管理策略的创建过程中进行的现场记录和访谈（如专题连载上部分的第5节所述）有助于提供必要的信息，以便稍后将其敏捷开发流程映射到A-SPICE流程。

表3和表4显示，A-SPICE工作产品所需的大部分信息是由团队的SAFe开发实践生成的。但是，需要以某种方式存储、维护和更新这些信息，以便向以下人员提供前面提到的报告：符合功能安全。这些文档实践之前并未由团队在日常敏捷开发实践中维护，或者恰好处于适应ASPICE文档需求的早期阶段。

确定必要的信息后，团队更好地了解了从A-SPICE 1级过渡到3级需要创建哪些策略。这些表格可作为开发人员遵循的指南，以适应他们的敏捷实践A-SPICE流程（参考评估阶段进行的访谈）。

研究人员提出了一种将文件保持在最低限度的策略，类似于本研究中提出的策略。其中包含一个表格，其中包含使用A-SPICE进行敏捷软件开发的文档以及此类文档背后的基本原理。然而，他们研究中确定的文档只能适用于小公司，因为它们只包括A-SPICE软件工程流程组(SWE.1-6)。他们的方法被认为不足以满足沃尔沃汽车等大型汽车公司的需求，因为这些文件不足以遵守A-SPICE。因此，本研究中提出的指南（与沃尔沃汽车ART Steer部门的Aurora团队合作制定）被认为更适合规模化敏捷软件开发和ASPICE流程。

表3和表4中确定的文件不仅是A-SPICE特定的，因为它们也由从事敏捷的汽车领域以外的其他公司填写，例如软件需求规范和软件架构设计规范文件等。因此，所提出的表格也可以作为汽车领域以外的软件开发公司的文档指南，这些公司正在从瀑布式开发过程过渡到面向敏捷的开发过程。

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

正如前面几节（参见该专题连载的第2节和第3节）所述，A-SPICE和敏捷在文档问题上相互对立。

为了协调这些对文档的对立立场，我们使用了工具来自动化生产尽可能多的A-SPICE工作产品。

该团队为图5所示的工具链选择了工具（见第6节）。创建工具链集成是为了为工具提供建议，这些工具可用于生成必要的信息，而不需要额外的会议或额外的团队活动来填写和更新文档。

前面提到的由其他作者以及Aurora团队确定的A-SPICE挑战之一是建立工作产品的双向可追溯性。关于溯源问题，发现工具集成链使用了SCM工具，例如：JIRA作为主要管理工具，可视化需求和测试用例之间的双向可追溯性。这是因为有可能将新的插件或其他应用程序集成到其中。Komiyama等人在他们的研究中使用了类似的方法。他们使用TestRail、Bitbucket、Bamboo和SonarQube等工具来提供工作产品的可追溯性。他们的方法与本研究中提出的方法相似。然而，他们的工具链只适用于由一个或两个开发团队组成的小型公司，因为他们使用SCM工具JIRA管理所有需求。

新的文档管理策略使用嵌入式系统（如SystemWeaver）集成到软件管理工具（如JIRA）中的开发平台来跟踪功能性和非功能性系统和软件需求。这种集成可以提供跨职能团队需求的可追溯性可视化，并在需要时生成必要的数字报告文档（类似文档格式的报告）。也就是说，需要选择正确的应用程序和插件来提供这种双向可追溯性。由于SystemWeaver被用作主要用于汽车系统的嵌入式系统的开发平台，如果该工具链被汽车领域以外的公司使用，则应使用类似的工具。

报告创建的自动化是一件积极的事情，因为它可以帮助开发团队更好地管理他们的活动，并使他们更多地关注开发而不是文档。然而，对于那些已经建立了难以改变的工具链的公司来说，拥有不同应用程序的需求（例如本研究中提出的应用程序）可能具有挑战性。

对团队敏捷实践和持续集成工具的观察以及访谈有助于创建此类工具链，以建立和维护产品的可追溯性。

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

PI规划和冲刺活动的不同映射有助于团队可视化在团队的敏捷软件开发过程中何时需要生成或更新必要的文档。

它在不同的SAFe团队活动期间提供了文档。然而，映射发现了关于何时需要创建或更新质量保证策略和配置策略文档的一些差距。A-SPICE 意味着需要制定这些策略作为确保产品质量的第一步，但不是何时制定。然而，团队的SAFe框架活动都不是专门针对质量保证(SUP.1)或配置管理(SUP.8)的。话虽这么说，但这并不意味着团队不执行质量保证活动或配置管理活动。这些活动在开发阶段和测试阶段作为开发操作执行，例如具有预定义的职责、配置项的命名约定以及分支指南。所有这些不同的准则都使用SharePoint或允许跨团队共享信息的类似工具来存储。因此，这些团队实践被认为足以确保质量和处理配置管理，并且无需多次生成额外的文档，尽管应在适用时进行更新。

关于本指南的有用性，图4和5中呈现的映射使用表3和4中确定的文档，这些文档不仅是A-SPICE特定的，汽车领域以外正在过渡到更灵活的开发过程的公司也可以从这些映射中受益。

B.对有效性的威胁

根据Runeson和Höst的说法，有五种类型的有效性威胁适合案例研究。它们是内部有效性、构造有效性、结论有效性、可靠性和外部有效性。

1)内部有效性

这些威胁涉及观察者的偏见。定性数据的收集可能会通过提出引导性问题等方式在数据收集中引入错误。这可能会影响数据的记录并导致结果的错误解释。可以采取的尽量减少偏差的解决方案是：对评估员进行盲法、培训非盲法评估员来检测偏差或使用互观察者。这些方法被认为需要资源且不可靠。另一个内部有效性是该研究作者制定的文档管理策略。这可能会导致研究偏见，即研究人员影响结果。为了减轻这种威胁，在Aurora团队的协作和监督下制定了文档管理策略。我们的大学主管也审查了文件管理策略。

2)外部有效性

这解决了案例研究的普遍性。由于这是一项针对公司的研究，因此收集的数据和工件的创建与Aurora团队和沃尔沃汽车的工作方式相关。这就是为什么该研究的结果旨在为其他希望调整其敏捷软件开发流程和A-SPICE实践的汽车公司或汽车领域之外愿意调整其实践的其他公司提供参考。

3)构造有效性

结果的有效性部分取决于在文档管理策略创建的不同阶段进行的访谈记录和现场笔记的可靠性，以及它们是否足以从从业者那里捕获正确的信息。为了帮助缓解这一问题，我们向一位软件开发人员展示了采访记录和现场笔记，以验证收集到的信息是否正确且与研究问题相关。

另一个重要方面是，调整后的文档管理策略在理论上涉及基于对团队敏捷实践的观察的流程，但在实践中并非如此，因为实施该流程超出了本研究的时间范围。

4)结论有效性

这是指内部普遍性或从访谈期间收集的定性数据得出的结论的合理程度。由于我们案例研究的时间有限，且外部环境不可控，因此访谈并未对案例组织的每一位成员进行。相反，为了尝试获得具有代表性的结果，访谈仅针对关键团队成员进行，例如Scrum Master、产品负责人以及团队中的相关软件开发人员。访谈数据是根据从Aurora团队到整个部门的观察来完成的。

5)可靠性

需要考虑不同A-SPICE工作产品的映射和解释结果的可靠性。为了解决这个问题，该工件是与Aurora团队及其持续反馈合作创建的。这样做是为了确保在每个映射、工作产品和工具上达成一致。

8.结论

本研究的目标是为大公司提供将A-SPICE和敏捷方法相结合的适应方案。这是为了确保生成符合ASPICE标准的所有必要文档，同时保持汽车领域敏捷的可交付成果的开发和生产。

与Aurora团队一起制定了文档管理策略，作为此类调整的指南。该策略有助于可视化信息的生成和收集方式、需要生成哪些信息以及在敏捷开发过程的不同阶段何时需要管理信息。人们发现，新的文档管理策略部分解决了有关需求及其各自测试用例的双向可追溯性的挑战之一。我们还发现，结合两种开发实践所发现的问题已通过所提出的策略得到解决。这是通过结合使用不同的配置管理工具进行持续集成实践来实现的。此外，本研究旨在为汽车领域其他希望通过A-SPICE流程调整敏捷实践以确保功能安全的组织提供参考。

本研究是大公司首次尝试将规模化敏捷开发流程应用于汽车领域的A-SPICE功能安全实践。需要进行进一步的研究，将拟议的策略扩展到充当其他大型汽车公司外部供应商的其他团队，并实施该策略以检查它如何影响短期和长期的团队生产力。更可取地，这样的实施将揭示战略实施期间的进一步差距或问题。

关注牛喀网，学习更多汽车科技。有兴趣的朋友，可以添加牛小喀微信：NewCarRen，加入专家社群参与讨论。

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