经验一：如果需要与供应商进行长期的合作并且有密集的功能开发需求，那就建立一个敏捷合同
OEM外包软件开发的常见操作之一是为每个软件增量向供应商付款。如果供应商负责开发一个比较大的软件，那么总是有功能增量的需求。在这种情况下，双方通常建立功能开发或变更计划，这里每个功能开发的周期设置为十周，但在不同的实践中会有所不同。
在这十周的开始，供应商会收到需求或者变更请求，即一些新功能和旧功能的变更。供应商工程师设计变更，并估算开发需要的时间。然后供应商管理层进行审查和批准。接下来OEM也会对其进行审查和批准。最后就按照这个计划开发。图1（a）显示了十周时间段内所述活动的简化图。
经验2：尽管有工程合同，但要注重积极的联合审查
汽车开发的惯例是，OEM会有一份全面的书面工程合同，详细说明供应商应该遵守的每一个实践和供应商应该达到的每一个指标。一个常见的惯性思维是，只要制定好了，项目就能成功。
但是这其中有两个问题：第一，大多数实践和指标在持续应用时是有价值的。例如，如果不遵从MISRA编码规范，修复缺陷会引发创建新缺陷的高风险。这几乎适用于所有领域，如复杂性管理、内存优化、处理器负载度量、风险管理等等。当OEM不积极地去审查供应商的交付物以及开发过程时，为了满足合同上的条款，供应商经常发送指标报告，而没有后续动作。
经验三：监督供应商与二级供应商的关系
经验四：建立绩效KPI，以管理项目进度的合规性
供应商软件管理的一项基本任务是了解供应商何时完成开发。实践中的一个问题是，从业者有时要么不使用任何KPI，要么使用无效的KPI。在这两种情况下，实践者都以一遍又一遍地无用的讨论而告终。
常见的无效KPI是静态KPI，忽略了时间轴，因此是朝着完成日期发展的趋势。一个例子是饼图，显示60%的需求已经实现。
相反可以构建一个KPI，它可以预测完成日期。图2显示了两个这样的KPI。第一个KPI（图1 a）适用于确定总体需求数量的项目。这是几周内实施需求的趋势（橙色线），旨在在目标周内达到需求总数（蓝色线）。例如知道目标是第26周，从业者可以预测开发将延迟2-3周。
图2 b 未定义产品需求集发展趋势的KPI
经验五：建立质量KPI，以管理质量合规性
供应商软件管理中的另一项基本任务是了解所开发软件的质量。软件KPI是监控质量和指导改进活动的有力手段。同样，关键是选择有效的KPI并持续使用，并采取后续行动。
然而，一个大问题是供应商只是偶尔进行衡量，并将结果发送给OEM，而不采取后续行动。因此，OEM负责人应要求KPI报告，以证明持续改进，如每周或每两周。这种态度建立了基于客观和准确度量的软件质量密切协作和讨论。双方的实践者在讨论质量时使用相同的语言。供应商了解到，遵循KPI并提高质量不是一项独立的活动，而是开发过程中的一个自然部分。
质量KPI的另一个大问题是，从业人员被许多众所周知的KPI弄糊涂了，这些KPI不准确，因此最终对任何质量改进活动都是无用的。例如计算代码行数或众所周知的复杂度数，如圈复杂度、Halstead度量等。测试中类似的例子是决策和条件覆盖率的计数。这里我列出了一些KPI，它们明显地帮助显著提高了软件质量。
1、OEM需求测试的覆盖范围
2、严重违反MISRA的数量
3、高度嵌套的源函数数量
4、未跟踪的需求/测试/代码的数量
在软件开发中持续使用这种有效的KPI，并要求供应商及时解决问题，可以获得以下三个大的好处：
1、在整个开发过程中，所开发的软件功能始终符合OEM的要求；
2、许多缺陷都是在供应商方面提前发现的，不会浪费系统测试的时间，也不会占用测试设备；
3、源代码保持可维护性，以便更快地添加新功能和修复缺陷，尤其是在项目完成后很长时间。
经验六：考虑让你的供应商参与后续项目，即使有更便宜的替代方案
在持续的大型产品开发中，新项目通常是一个带有一些附加功能的旧项目的后续。新项目与前一个项目有很多功能重叠，可能会外包给不同的供应商。在这种情况下，功能的设计是围绕OEM之前指定的一组需求发展的。同时，在新供应商现场重新开发新的项目代码。
因此，这两个连续的项目有不同的预算、负责人，而且往往有不同的供应商，即使它们的功能重叠。每次启动新的后续项目时，都应选择供应商。本次选择考虑了两个主要方面：成本和能力。选择了一个具有合理价格和较高软件开发能力的供应商。
但是，如果旧供应商已经拥有为新项目开发的大部分功能，是否有机会选择新供应商？现实情况是，新供应商通常给其他OEM开发类似的功能，这些OEM与当前OEM有很大的功能重叠。因此，供应商之间的竞争是真实的，因为他们都有一些已经开发的功能。
然而，供应商评估中经常忽略的一个微妙的考虑是，即使开发的功能相似，新供应商的代码也不同：首先，功能相似性仍然包含不同汽车之间细微的行为差异，这些差异表现为代码中某些变量的不同范围和初始值。其次，代码的内部设计和结构不同，因为它们取决于公司的开发人员和编码实践。
然而，这两个细微的差异在实践中产生了重大问题。首先，供应商应了解所有产品要求，尽管已经开发了大部分功能；这需要大量的详细需求评审工作，以确保产品符合需求。其次，供应商应确保软件与硬件的集成：软件兼容性、信号交换技术以及硬件处理器和内存负载要求。第三，更改现有代码中某些变量的初始值和范围以符合OEM要求可能会触发一系列软件缺陷、更正和更新，这些缺陷、更正和更新只会随着时间的推移而消退。如果变更或缺陷很多，可能会影响生产。
如果供应商在软件开发方面有很强的能力，那么上述问题就会得到缓解。但是高能力只能解决部分问题。另一部分在于软件的性质;如果在开发中有足够多的更改，那么软件缺陷肯定会出现。软件是一个复杂的工件。预计变化的后果是不可能的。时间是一个独立的参数，它允许软件的成熟和缺陷的消退。因此，每次OEM考虑为后续项目更换供应商时，都应该考虑到新供应商需要更长的时间来实现软件的成熟和适应。
申明：整理自外文文档，侵删
推荐阅读
智能驾驶功能那点事儿
浅谈汽车Tbox
关于车载以太网 Switch Vlan的理解
2018版IS026262与2011版有哪些差异？
Adaptive AUTOSAR 学习笔记 - AP 背景、技术及特征
AURIX TC3XX系列的SOTA机制详解
一文详解奥迪e-tron内部系统 |附下载
ID.3 和大众的电气化平台 |附下载
一文详解CAN总线错误帧|附下载
DoIP协议介绍，资料分享！
详解车载网络 OTA系统的开发|文末附下载
一文了解汽车嵌入式AUTOSAR架构|附下载
特斯拉Autopilot系统安全研究|附dbc下载
