OEM在与软件供应商合作时，总会遇到一些挑战。这里从实际工作中总结了六条经验。汽车上的软件开发会需要多家供应商为车辆的不同功能提供软件。成功地从所有供应商那及时获得高质量的软件是一个巨大的挑战。为了应对这一挑战，汽车公司通过国际标准、企业标准、功能规范和工程合同等来规范供应商的工作。但是在日常工作中，如何处理与软件供应商的合作，使其达到想要的结果呢？我在软件开发项目中担任过两年的软件质量工程师，接触过七家供应商。我的工作是为DRE提供技术和计划支持，他们则监督供应商的软件开发，使项目的成功执行。这种支持涵盖了合同管理、项目规划、需求工程、设计、实施、供应商和内部测试、可追溯管理、过程改进、质量保证、符合标准、风险和机会管理、处理器和内存负载监控、和产品交付。我经常与供应商进行沟通，并不断协商我们在这些领域的责任。此外，在一个项目的生命周期内，我们会与供应商进行了几次联合审查，这意味着亲自前往供应商现场，并在2 - 3天的联合会议中审查他们的过程和工作产品。这项工作让我对软件开发有了一个整体的看法，从而产生了一系列后续行动，让双方能够克服项目瓶颈。这些都是我的工作，除此之外，我还观察和记录总结了这个过程中最重要的经验，这些经验对项目执行的成功有明显的影响。经验一：如果需要与供应商进行长期的合作并且有密集的功能开发需求，那就建立一个敏捷合同
OEM外包软件开发的常见操作之一是为每个软件增量向供应商付款。如果供应商负责开发一个比较大的软件，那么总是有功能增量的需求。在这种情况下，双方通常建立功能开发或变更计划，这里每个功能开发的周期设置为十周，但在不同的实践中会有所不同。
在这十周的开始，供应商会收到需求或者变更请求，即一些新功能和旧功能的变更。供应商工程师设计变更，并估算开发需要的时间。然后供应商管理层进行审查和批准。接下来OEM也会对其进行审查和批准。最后就按照这个计划开发。图1（a）显示了十周时间段内所述活动的简化图。
这种合作模式的一个缺点是开发组织必须详细估算开发时间，并等待管理层批准。另一个缺点是一个开发周期必须足够长，这样在减去前期评估和审批的时间，仍然有足够的时间进行开发，结果就是开发周期变长。对于一个大型ECU开发，一年中花在前期评审和审批的时间高达13-17周，这种方式阻碍了在双方之间构建快速反馈和缺陷解决的持续集成链。这种浪费可以通过开发敏捷模式来消除。该模式的本质是，OEM不仅要为劳动力付费，还要为开发的功能付费。这意味着OEM应该从供应商那里雇佣敏捷团队。由于该团队位于供应商处，一个好的程序是有专门的产品负责人，一个来自供应商，一个来自OEM。然后任何更改请求都会发送给产品负责人，他们一起分析并决定即将到来的开发时间段的下一项工作。OEM产品负责人关心的是根据需求的紧急程度和开发工作对变更请求进行优先级排序。当然，供应商产品负责人也会评估方案的可行性和开发团队的工作量。这种方式审批浪费的时间被消除了，所以开发的时间可以减少，从而使快速反馈和对供应商的响应变得有效。
汽车开发的惯例是，OEM会有一份全面的书面工程合同，详细说明供应商应该遵守的每一个实践和供应商应该达到的每一个指标。一个常见的惯性思维是，只要制定好了，项目就能成功。
但是这其中有两个问题：第一，大多数实践和指标在持续应用时是有价值的。例如，如果不遵从MISRA编码规范，修复缺陷会引发创建新缺陷的高风险。这几乎适用于所有领域，如复杂性管理、内存优化、处理器负载度量、风险管理等等。当OEM不积极地去审查供应商的交付物以及开发过程时，为了满足合同上的条款，供应商经常发送指标报告，而没有后续动作。
第二，有一种说法是，如果项目失败了，供应商将承担后果(如合同中所示)。但事实并非如此。即使供应商可能会因为有缺陷的产品而支付罚款，或者可能会因为项目失败而得不到付款，但对OEM的影响是巨大的。OEM无法提供承诺的功能，失去信誉。在实践中，合同是OEM和供应商的工程师组织协作的法律、道德和实践框架。这种协作越系统化，项目进行的就越无缝。这样的合作主要通过联合审查的方式进行，双方可以陈述他们的关注点、困难、需求、需要的支持、变更请求等。他们还会就合同范围之外的小问题进行谈判，并庆祝进展中的小成功。系统化和详尽的联合评审对产品的成功至关重要。正是在这些审查过程中，看似业余的问题可能可以识别到关键的问题和风险。也正是在这些评审期间，工程师们为了一个共同的有意义的目标团结在一起，并为长期合作建立前提。在某些情况下，软件供应商有自己的供应商。例如，如果一个供应商承担了一个节点的主要功能的开发，他们可能会从另一个供应商那里购买该节点的操作系统，而后者则是OEM的二级供应商。与工程合同规范OEM和供应商合作的方式一样，它们也规范供应商和二级供应商的合作。一方面，OEM不能强制二级供应商遵守工程合同，因为合同不是直接在他们之间签订的。另一方面，迫使供应商要求二级供应商遵守合同是具有挑战性的。虽然这个问题在合作中似乎是次要的，但如果不从一开始就仔细考虑，它可能会成为一个棘手的问题。假设由于一些法律和实际原因，工程合同要求供应商在OEM需求和供应商测试用例之间显示完整的可追溯性。同样，假设供应商和二级供应商在二级供应商只开发和交付工作功能而没有测试用例的条件下合作了很多年。这个问题可能在一开始就不明确，因为供应商可能认为购买的功能符合工程合同，而OEM可能不这么认为。之后，在项目文件交付过程中发现问题，出于法律原因，解决方案不会很明显，强调三方的关系。另一个相关问题是，供应商专注于自己的工作以遵守工程合同，但在没有适当沟通的情况下将合同转让给二级供应商。这种情况下，供应商可以展示其开发部分的合规性，但无法展示二级供应商开发部分的合规性。至关重要的是，二级供应商的开发可能占整个软件开发的50%。解决这些问题需要大量的时间和精力，甚至涉及到更高的管理层。建议OEM质量工程师和项目经理要求二级供应商的关键工程师参与合同的制定过程。他们应讨论并商定在项目开始时，合同合规性的可接受范围。达成这样的协议通常需要付出出乎意料的巨大努力，因为三方之间的工程政策总是存在冲突，但这些协议正在为积极合作奠定坚实基础。另一个建议是，OEM工程师应该询问供应商与二级供应商的关系如何，双方合作是否存在瓶颈，是否存在可行性问题，交付问题等等。这样的对话通常会发现看似很小的问题，但在项目接近尾声时可能会发展成大问题。但当OEM工程师表现出关注和兴趣时，这些问题就会自动变得重要，并在后续过程中得到解决。
供应商软件管理的一项基本任务是了解供应商何时完成开发。实践中的一个问题是，从业者有时要么不使用任何KPI，要么使用无效的KPI。在这两种情况下，实践者都以一遍又一遍地无用的讨论而告终。
常见的无效KPI是静态KPI，忽略了时间轴，因此是朝着完成日期发展的趋势。一个例子是饼图，显示60%的需求已经实现。
相反可以构建一个KPI，它可以预测完成日期。图2显示了两个这样的KPI。第一个KPI（图1 a）适用于确定总体需求数量的项目。这是几周内实施需求的趋势（橙色线），旨在在目标周内达到需求总数（蓝色线）。例如知道目标是第26周，从业者可以预测开发将延迟2-3周。
在实践中，用图1（a）构建另外两个趋势可以更全面地概述发展趋势：1、分解的OEM需求（有多少原始要求分解为供应商的内部设计要求）；监控这三种趋势将有助于确定开发中哪些主要活动是滞后的，因此可以在各自的活动中增加更多的资源，或者重新确定需求的优先级。
第二个KPI(图1 b)适用于只定义了即将到来的待定项的功能的项目。因此燃尽和堆积趋势对于监控进度遵从性是有效的。趋势(图2 b)显示了一个为期四周的敏捷迭代，团队在27天内烧掉了40个故事点(绿线)。同时，新的故事点在开发期间堆积在现有的待定项之上(橙色线)，提高了实际趋势(黑色线)。在第17天，如果添加了更多的描述点，那么团队有按时发布产品增量的风险。
图2 b 未定义产品需求集发展趋势的KPI
供应商软件管理中的另一项基本任务是了解所开发软件的质量。软件KPI是监控质量和指导改进活动的有力手段。同样，关键是选择有效的KPI并持续使用，并采取后续行动。
然而，一个大问题是供应商只是偶尔进行衡量，并将结果发送给OEM，而不采取后续行动。因此，OEM负责人应要求KPI报告，以证明持续改进，如每周或每两周。这种态度建立了基于客观和准确度量的软件质量密切协作和讨论。双方的实践者在讨论质量时使用相同的语言。供应商了解到，遵循KPI并提高质量不是一项独立的活动，而是开发过程中的一个自然部分。
质量KPI的另一个大问题是，从业人员被许多众所周知的KPI弄糊涂了，这些KPI不准确，因此最终对任何质量改进活动都是无用的。例如计算代码行数或众所周知的复杂度数，如圈复杂度、Halstead度量等。测试中类似的例子是决策和条件覆盖率的计数。这里我列出了一些KPI，它们明显地帮助显著提高了软件质量。
1、OEM需求测试的覆盖范围
2、严重违反MISRA的数量
3、高度嵌套的源函数数量
4、未跟踪的需求/测试/代码的数量
第一个KPI的目标值为100%；在交付给OEM之前，应在供应商现场对所有OEM要求进行功能测试。这样的测试最好与开发同时进行。第二个KPI的目标值为0；所有严重违反MISRA的行为都应该在引入这些行为后“及时”得到解决。第三个KPI的目标值为0；所有超过最大嵌套级别4（最大嵌套<5）的源函数都应该在引入它们时“及时”进行重构。第四个KPI的目标值为0；所有客户需求都应与内部供应商设计需求、源功能和测试用例有明确的跟踪链接。有更多的KPI可以用于提高软件质量：例如MC/DC覆盖范围，应具有基于软件关键性级别的目标值；处理器和内存负载趋势，应像上一节中的实现趋势一样进行监控。
在软件开发中持续使用这种有效的KPI，并要求供应商及时解决问题，可以获得以下三个大的好处：
1、在整个开发过程中，所开发的软件功能始终符合OEM的要求；
2、许多缺陷都是在供应商方面提前发现的，不会浪费系统测试的时间，也不会占用测试设备；
3、源代码保持可维护性，以便更快地添加新功能和修复缺陷，尤其是在项目完成后很长时间。
经验六：考虑让你的供应商参与后续项目，即使有更便宜的替代方案
在持续的大型产品开发中，新项目通常是一个带有一些附加功能的旧项目的后续。新项目与前一个项目有很多功能重叠，可能会外包给不同的供应商。在这种情况下，功能的设计是围绕OEM之前指定的一组需求发展的。同时，在新供应商现场重新开发新的项目代码。
因此，这两个连续的项目有不同的预算、负责人，而且往往有不同的供应商，即使它们的功能重叠。每次启动新的后续项目时，都应选择供应商。本次选择考虑了两个主要方面：成本和能力。选择了一个具有合理价格和较高软件开发能力的供应商。
但是，如果旧供应商已经拥有为新项目开发的大部分功能，是否有机会选择新供应商？现实情况是，新供应商通常给其他OEM开发类似的功能，这些OEM与当前OEM有很大的功能重叠。因此，供应商之间的竞争是真实的，因为他们都有一些已经开发的功能。
然而，供应商评估中经常忽略的一个微妙的考虑是，即使开发的功能相似，新供应商的代码也不同：首先，功能相似性仍然包含不同汽车之间细微的行为差异，这些差异表现为代码中某些变量的不同范围和初始值。其次，代码的内部设计和结构不同，因为它们取决于公司的开发人员和编码实践。
然而，这两个细微的差异在实践中产生了重大问题。首先，供应商应了解所有产品要求，尽管已经开发了大部分功能；这需要大量的详细需求评审工作，以确保产品符合需求。其次，供应商应确保软件与硬件的集成：软件兼容性、信号交换技术以及硬件处理器和内存负载要求。第三，更改现有代码中某些变量的初始值和范围以符合OEM要求可能会触发一系列软件缺陷、更正和更新，这些缺陷、更正和更新只会随着时间的推移而消退。如果变更或缺陷很多，可能会影响生产。
如果供应商在软件开发方面有很强的能力，那么上述问题就会得到缓解。但是高能力只能解决部分问题。另一部分在于软件的性质;如果在开发中有足够多的更改，那么软件缺陷肯定会出现。软件是一个复杂的工件。预计变化的后果是不可能的。时间是一个独立的参数，它允许软件的成熟和缺陷的消退。因此，每次OEM考虑为后续项目更换供应商时，都应该考虑到新供应商需要更长的时间来实现软件的成熟和适应。
申明：整理自外文文档，侵删
