由于创新热潮和来自客户日益增长的时间压力，软件密集型电子汽车部件的供应商正面临着技术挑战。由于车载汽车电子系统的质量在很大程度上取决于其开发实践的质量，汽车制造商和供应商积极主动地专注于改善技术和组织流程。今天，汽车SPICE（ASPICE）是在这种情况下评估和改进汽车电子流程和项目的参考标准。由于汽车制造商使用ASPICE来鉴定他们的软件密集型系统的供应商，这样的标准成为市场的需求。本文确定并讨论了在符合ASPICE标准的软件开发项目中，技术债务管理（TDM）的整合和协调的好处和影响。此外，本文还提供了一个概念框架和一个参考流程描述，用于在一个软件工程流程样本中整合ASPICE和TDM实践。
软件密集型电子汽车部件的生产者处于第一线，因为他们需要面对创新热潮[1, 2]和来自客户越来越大的时间压力。在这种情况下，软件开发项目是一个战场，开发人员和项目经理每天都在与时间压力、技术挑战和狭窄的成本利润率作斗争，以实现苛刻的质量目标。ASPICE[6]是一个参考标准，它提供了一个过程框架，规范了软件开发活动，并允许对其进行能力评估，以满足预先定义的许多过程要求。
ASPICE[6]是一个参考标准，它提供了一个过程框架，规范了软件开发活动，并允许他们在匹配预先定义的许多过程要求方面进行能力评估。十多年来，ASPICE已经被许多OEM厂商用来对软件供应商进行资格认证，要求其达到特定的过程质量目标。因此，ASPICE的影响是有目共睹的，所以今天的汽车软件开发项目具有共同的特点，主要归功于ASPICE本身。我们注意到，ASPICE的特殊性为汽车软件开发中引入技术债务管理（TDM）[11]提供了肥沃的土壤。事实上，系统的质量检查和工作成果审查，以及过程绩效的纪律，可以说是有效的TDM的必要先决条件。
然而，由于TDM没有被ASPICE（以及其他特定领域的标准）明确解决，它在工业汽车软件项目中的应用仍然相当有限。本文旨在为回答以下研究问题做出贡献：“在符合ASPICE的软件密集型开发项目中执行TDM的影响是什么？”
本文结构如下：在第二节中，我们简要介绍了TDM和ASPICE；在第三节中，我们讨论了ASPICE为实施TDM所带来的好处；在第四节中，我们在BPMN[10]图形的支持下，通过关注一个示范性的工程流程，深化了与TDM和ASPICE之间整合有关的流程方面。最后，在第五节中提供了结论。
在本节中，我们将介绍与TDM和ASPICE有关的基本概念。
A. 技术债务：概念和特点
技术债务（Technical Debt，TD）的概念是基于一个财务隐喻，并提供了一个框架来阐明延迟某些软件开发任务或快速而不仔细地完成这些任务的短期利益，以及这些延迟或不可靠的工作的长期成本之间的权衡概念。TD概念引入了这样一个观点：在软件开发中部署捷径（即获得TD）不一定是负面的，因为有限的债务可以帮助开发人员在短期内加快开发过程[3, 4]。TD可以分为两种类型：非故意的和故意的。第一种类型仅仅对应于做得不好的非战略结果（例如，一个软件架构设计只是被证明是容易出错的）。第二种技术债务是故意产生的。这通常发生在一个组织有意识地决定为现在而不是为未来进行优化[5]。
B. ASPICE简介
ASPICE提供了一个过程框架，在一个高度抽象的水平上规范了软件开发活动，并允许他们在匹配预先定义的许多过程要求时进行能力评估。汽车制造商使用ASPICE来推动软件密集型系统供应商的软件流程改进[7]。该标准的目的是为评估开发软件密集型汽车部件的过程质量提供一个方案，并为其改进提供途径。许多原始设备制造商正在使用这一标准，通过要求供应商达到特定的评级来对其进行资格认证[8]。ASPICE标准既提供了相关流程的定义，又提供了衡量其能力的评级机制[6]。在表1中，提供了原始设备制造商最感兴趣的ASPICE过程的集合。根据ASPICE，每个过程都可以按照由6个级别（从0到5）组成的量表来评分。0级意味着该过程的部署是不完整的，没有达到预期结果。达到1级意味着有证据证明该过程预期结果的实现（1级是说与过程绩效有关）。
TABLE I. ASPICE PROCESSES OF GREATEST INTEREST FOR OEMS
ASPICE过程参考模型的每一个过程都有一套特定的过程指标，被称为基础实践（BP）；如果BP的完整表现保证了过程结果的实现，那么就是能力水平1。第2至5级与管理、控制、测量和改进过程实践水平的评价有关（第2至5级与过程能力有关）。
III.ASPICE 对TDM的影响
在文献中可以找到一些旨在了解与生产软件的组织引入TDM有关的主要挑战的研究[12, 13, 14]。从这些研究中，并根据作者的经验（其中一位是ASPICE认证的评估员），可以确定这些挑战中最常见的是：（a）在组织中建立一个以TDM为导向的思维方式/文化；(b) 在整个开发项目中系统地进行技术审查和项目状况检查； (c) 广泛使用实施积压的工具，支持软件分析，或实施问题跟踪系统；以及 (d) 有效（和工具支持）记录缺陷和审查/分析结果。
A. ASPICE项目的实践
在过去的二十年里，ASPICE的广泛应用塑造了汽车软件行业。因此，许多软件项目从技术和程序的角度都呈现出共同的特点[7]。ASPICE汽车软件项目中最明显的技术共性是：(1) 广泛地应用编码规则（MISRA）[9]和代码度量；(2)对主要的软件开发工件进行系统的技术审查，如软件架构设计、软件详细设计、测试定义；(3) 在整个开发生命周期中进行全面的双边追踪；(4) 注重集成测试；(5) 系统和软件需求之间明确分离。
从管理的角度来看，汽车软件项目的主要共同点是：(6) 独立的质量保证，处理过程和工作产品的合规性；(7) 严格的问题/缺陷和变化管理，包括有记录的影响分析；(8) 广泛和毛细血管的任务和资源管理；(9) 为代码和项目文件提供工具支持的配置管理。
目前在汽车软件开发项目中应用的工程和管理技术及流程在很大程度上受制于ASPICE；然而，ASPICE并没有明确涉及TDM；因此，它并没有系统地应用于汽车。
B. 促进TDM的因素：ASPICE
人们认识到，高成熟度的流程不仅有利于部署TDM[12, 13]，而且也有助于限制TD的数量[17]。因此，一般来说，遵守ASPICE本身就可以被认为是TDM的助推器。无论如何，从与引进TDM有关的挑战和ASPICE项目的特点之间的比较中，我们有可能找出ASPICE软件开发项目中一些更详细的TDM促进因素：
熟悉处理技术方面、成本和资源需求的影响分析的表现： 与MAN.3、SUP. 10和SUP.9过程相关的ASPICE条款有利于TDM，因为对项目任务的精确调度、监控和调整的系统部署支持了TDM的评估、监控和优先级阶段。这些促进因素在一定程度上解决了上面列出的挑战d)和挑战a)。
广泛使用辅助工具：尽管ASPICE没有要求使用任何特定的工具来遵守它的规定，但对某些过程的支持工具的需求只是隐含的，因为如果不使用自动或半自动工具，一些实践就不能以令人满意的方式进行（例如，使用自动代码解析器进行代码静态分析，即使没有明确要求，在实践中也是必要的）。ASPICE大力推动自动支持工具和环境的使用，以实现问题跟踪和所需分析结果的共享（缺陷根源、变更影响、设计审查、质量保证检查和审计等）。这可以被认为是挑战c)和d)的一个促进因素。
有效管理工作成果：ASPICE包含一个特定的过程属性，提供与项目工作产品的定义、提供、控制和审查有关的规定。ASPICE工作成果包括技术文件（如源代码、软件架构设计、需求）、计划和程序（如配置管理计划、质量计划、测试策略），以及审查和分析的结果记录（如项目状态报告、技术审查报告、需求分析报告、质量问题）。这一促进因素解决了上述b）和d）的挑战。
上述因素的结合决定了部署TDM的肥沃土壤。
IV.在ASPICE项目中整合TDM
缺乏与现有流程的整合被认为是TDM的一个主要障碍[17]。在这一节中，我们将讨论TDM在一个符合ASPICE的项目中的集成问题。 为此，由于篇幅所限，我们重点讨论一个ASPICE过程： SWE.2 软件架构设计。
首先，我们以简化的方式描述了在一个典型的符合ASPICE的开发项目中部署这样一个过程；然后，我们展示了如何整合TDM，并讨论了相关影响。
A. 根据ASPICE进行软件架构设计过程的部署
SWE.2的目的是 "建立一个架构设计并确定哪些软件需求将被分配给软件的哪些元素，并根据定义的标准评估软件架构设计" [6]。SWE.2基础实践（BP）在表二中报告，更多细节请参考[6]。SWE.2流程的基础实践的顺序和关系，以及该流程的输入/输出工作产品，通过BPMN[ 10]图显示在图3。
TABLE II. SWE.2 BASE PRACTICES
初步步骤(对应于SWE.1. BP5和SWE.1.BP6)与寻找最佳参考架构设计和说明资源消耗目标有关。然后，对项目进行软件体系结构设计(SWE.2.BP1)。一旦软件架构设计可用，将根据资源消耗目标对其进行验证。软件架构是通过对动态行为的描述(至少对于关键的操作模式)和对内部和外部接口的精确描述来完成的(SWE.2. BP4 and SWE.2.BP3)。下面的步骤处理需求和软件测试用例的体系结构元素的双边可追溯性的建立，以及相关的一致性检查(对应于 SWE.2.BP7 和 SWE.2.BP8)。最后，软件架构设计应是可用的并传达给受影响的各方(SWE. 1.BP9）。
图1. 代表SWE.2（软件架构设计）过程的BPMN图
值得注意的是，尽管由于篇幅限制，在本文中，我们只关注一个ASPICE过程，其他ASPICE软件和系统工程过程也包含基本实践（即强制性活动），涉及技术工件和技术解决方案的分析，通过提供必要的程序支持来识别和评估可能的TD，有力地支持TDM的引入。
B. 在符合ASPICE的项目中整合TDM
在这一小节中，我们将简要讨论在BPMN图的支持下ASPICE和TDM之间可能的整合步骤。由于篇幅限制，我们只讨论SWE.2，我们重点讨论TD识别阶段，它不仅被认为是整个TDM中成本最高、影响最大的阶段之一[15]，而且它代表了TDM的触发点。为了描述该流程与TDM初始阶段的整合，我们从图1的BPMN图开始，通过整合TDM相关的流程阶段来丰富它。为清晰起见，与TDM相关的过程阶段用黄色表示，以便更好地与ASPICE过程阶段（白色）相区别。
尽管TD的识别可以在软件开发过程的每个阶段进行，但有一些特定阶段特别适合触发TDM。在SWE.2过程中，对备选软件架构设计的评估阶段是可以发现可能的次优参考软件架构设计的地方。在这种情况下，如图2所示，一个TD可以被识别、记录，然后被处理。同样，对资源消耗的分析是另一个过程阶段，可以促进检测次优的软件架构设计，然后识别TD。
尽管我们只考虑了一个流程，但我们表明，在流程定义层面，TDM和ASPICE之间的整合可以被清楚地表达和理解。即使有BPMN这样的半正式符号的支持，如果没有组织的具体数据和信息，也很难对流程变革的成本和影响进行估计。然而，根据流程工程的基本概念[16]，我们可以断言，由于ASPICE流程包含几个代表与TDM连接的实践，从流程的角度来看，ASPICE和TDM的整合需要进行有限的重新设计和影响。这一点很重要，因为缺乏流程整合被认为是引入TDM的主要障碍之一[15]。
图2. 代表SWE.2流程和TDM之间整合的BPMN图
V.结论
本文通过描述和讨论TDM在一个典型的符合ASPICE的软件开发项目中的整合和协调，解决了在符合ASPICE的项目中引入TDM的问题。我们注意到ASPICE的广泛应用决定了在执行软件开发项目方面取得显著成熟的成就，包括采用支持工具、整合良好实践、获得执行影响分析、风险管理、项目控制和缺陷/问题管理的习惯。从文化和技术的角度来看，这样的背景提供了肥沃的土壤，让汽车软件行业通过与ASPICE的有效整合来采用TDM。TDM应该与ASPICE流程相结合，使其具有更强的能力，通过评估短期利益和欠佳发布之间的正确权衡来面对项目问题。在本文中，从过程的角度来看，我们通过关注一个工程过程，表明ASPICE意味着能够支持TDM识别阶段（即TDM引入中需要较高开销的步骤[15]）的实践表现。从研究的角度来看，本文为更深入地阐述TDM在汽车方面的效果开辟了道路。从从业者的角度来看，本文为将TDM注入实际项目提供了一个初步的、仍然是部分的参考模型。我们未来的研究活动将集中在通过应用过程模拟技术和经验测量研究来定量评估在汽车中引入TDM的实际影响。此外，我们打算在ASPICE社区推动将TDM过程纳入ASPICE过程参考模型。
参考文献：
[1] J. Moessinger, “Software in Automotive Systems” . IEEE Software,
2010 Vol. 27(2), pp. 92-94.
[2] F. Falciniand G. Lami, “Challenges in certification of autonomous
driving systems” . 2017 IEEE International Symposium on Software
Reliability Engineering Workshops(ISSREW). IEEE, 2017. p. 286-
293.
[3] Y. Guo and C. Seaman, “A portfolio approachto technical debt” . In
Second International Workshop on ManagingTechnical Debt, ICSE 2011, Honolulu, Hawaii, USA, 23 May2011.
[4] L. Zengyang, A. Paris and L . Peng, “A systematic mappingstudy on
technical debt and its management” . Elsevier The Journal of Systems and Software, 2015 Vol. 101, pp. 193–220.
[5] S. McConnell, “Managing technical debt” . 2008, Construx pp. 1– 14.
http://www.construx.com/uploadedfiles/resources/whitepapers/Manag ing%20Technical%20Debt.pdf accessed 10/06/2022)
[6] VDA QMC Working Group13 / Automotive SIG, “Automotive SPICE
Process Assessment / Reference Model Ver. 3.1", 2017.
[7] VDA, “Automotive SPICE Guidelines” . 2017, 1st Ed. H . Druck.
[8] F. Fabbrini, M . Fusani, G . Lami, E . Sivera, “A SPICE-based Supplier
Qualification Mechanism in Automotive Industr2. Wiley Software Process Improvement and Practice Journal, 2007, 12, pp. 523-528.
[9] MISRA: MISRA C:2012 – Guidelines for the use of the C languagein
critical systems. 2013, MISRA Ltd, Nuneaton, Warwickshire CV10 0TU, UK.
[10] OMG. BusinessProcess Model and Notation (BPMN), 2013 https://www.omg.org/spec/BPMN/2.0.2/PDF accessed 10/06/2022
[11] P. Kruchten, R Nord and I. Ozkaya, “Managing Technical Debt: ReducingFriction in SoftwareDevelopment”, 2019, Addison-Wesley
Professional.
[12] J. Yli-Huumo, A. Maglyas and K. Smolander. "How do software development teams manage technicaldebt?–An empirical study." 2016Journal of Systems and Software 120 pp. 195-218.
[13] Malakuti, S. and Heuschkel, J., “The Need for HolisticTechnical Debt Management across the Value Stream: Lessons Learnt and Open Challenges” . 2021, IEEE/ACM International Conferenceon Technical Debt (TechDebt) pp. 109- 113.
[14] A. Martini, T . Besker and J. Bosch, “Technical debt tracking:Current state of practice: A survey and multiple case study in 15 large organizations”, 2018 Science of Computer Programming, 163, 42-61.
[15] Y. Guo, C. Seamanand F.Q . da Silva “Costs and obstacles encountered in technical debt management–A case study” . 2016 Journal of Systems and Software, 120, pp. 156- 169.
[16] E. Rolón, F. Ruiz, F. Garcia, and M.Piattini,M., “Applying Software Metrics to evaluate Business Process Models” . 2006 CLEI-Electronic Journal, Vol. 9(1, Paper 5).
[17] Rios, N., et al. “On the relationship between technical debt management and process models” . 2021 IEEE Software, 38(5), pp. 56-
64.
[16] E. Rolón, F. Ruiz, F. Garcia, and M.Piattini,M., “Applying Software Metrics to evaluate Business Process Models” . 2006 CLEI-Electronic Journal, Vol. 9(1, Paper 5).
[17] Rios, N., et al. “On the relationship between technical debt management and process models” . 2021 IEEE Software, 38(5), pp. 56-64.
分享不易，恳请点个【👍】和【在看】
