随着注意力的转移，公司需要学习新的流程和标准来管理他们的软件开发，来满足硬件开发的需要，以便他们能够让流程更加有效率以及让软件更加可靠。一个系统中各部件协同工作情况的好坏在硬件中的不确定性比较少：要么连接得很好，要么没连接上，但软件开发则会有很多阴影地带，显得扑朔迷离。这是因为软件的相互关联更加多，并且与其他系统的集成也更加复杂，在测试阶段很难发现所有的副作用。汽车工业为我们研究不断增加的复杂性以及设计提高嵌入软件的质量和可靠性的方法提供了一个很好的案例。目前，汽车嵌入式软件是这个行业大多数创新的驱动力量，并且在每一部新车中的价值在不断地上升，正在成为新车型价值构成的重要组成部分。嵌入式软件系统控制了大部分汽车的应用软件并且要处理很多基础性的挑战，例如悬挂系统的控制以及卫星导航——所有这些交换信息都是实时的。德国以及日本的高端车型的汽车制造商使用65到100个电控单元（ECU），来让每辆车的实时计算网络获得相当高的可靠性。不幸的是，嵌入式软件过去的质量是毁誉参半，报纸则一般都会报道失败的案例或者是汽车被召回的事件。

嵌入式软件存在的问题根源于硬件开发过程中。软件开发在逐渐地主导消费品以及工业产品的工业处理，小到手机，大到农业设备、挖掘工具以及飞机，甚至随处可见的洗衣机和汽车都缺少不了软件的开发。在今天，对于那些曾经将精力集中于机械硬件生产的公司来说，最基本的挑战就是如何开发出高质量的、可靠的能够嵌入到这些产品中的软件。举例来说，现在西门子在其高科技公司中雇佣了比大型软件公司如微软、甲骨文或者SAP更多的软件工程师。制造商对工业产品的注意力和产品的价值本身正在从芯片转向代码。

为了提高嵌入式软件的可靠性，并且为了保住汽车品牌的名声，轿车制造商和他们的供应商必须找到改进质量的方法。这做起来并不容易，但是别的行业已经通过采用更加成熟的架构以及对设计、开发和测试流程的改进获得了成功。举例来说，航天工业正在采用中心计算的架构来促进复用并且帮助公司管理复杂性以及满足严格的可靠性和质量的标准1。而在日用品行业，移动电话行业的几家厂商开发了被称作Symbian的软件协议栈和应用程序的标准接口。这种方法帮助制造商与供应商进行协调并因此能提高产品上市速度。

私有信息的优势在汽车工业中是至关重要的，因此一些现有的标准想升级为行业标准比较困难。例如汽车开放系统架构（Autosar：Automotive Open  Systemarchitecture）以及日本汽车软件平台与架构（Jaspar：JapanAutomotive  Software platform and architecture）要想成为行业的标准都有困难2。但即使没有这些标准，个体的制造商和公司也能够为汽车制造商工作，并改进嵌入式软件的可靠性，并因此可以提高汽车自身的质量。

构建更好的软件

汽车制造商必须把改善软件的责任与零配件供应商共享，因为制造商的很多零配件都要依赖这些供应商。麦肯锡正在从事一项嵌入式软件复杂性以及设计选择对汽车工业经济冲击的研究，并且鼓励行业中汽车制造商以及供应商的高级管理者参与到讨论中来。这项研究工作的初步结论认为，四项关键的领域通力合作就能够提高嵌入式系统的质量，并且能够提高开发的效率。

减少特性的复杂性

任何翻看过长达500页的新车的说明手册的人都知道，汽车制造商每年都会给新车加上许多新的特性。既然汽车的复杂性对质量等级以及保修成本有重大的影响，汽车行业就应该认真审视他们向产品添加的每一个新的特性的价值。我们的研究显示，小规模项目的生产率（大约300个特性点，按照我们描述复杂性的标准）比包含3000个特性的大规模的项目的生产率要高3倍。汽车制造商应该分析消费者和评级组织评估特性的方式，然后设计满足这些标准但不会增加复杂性的车辆。举例来说，一个安全气袋的供应商认识到安全气袋是根据他们从新车评估计划（New Car Assessment Program：一个全球安全和质量的标准）中获得的星级被评判的，所以公司将注意力放在了测试中能看得见的软件特性上。这种注意力的改变就减少了开发的范围，并且让公司能够采用新的设计来避免无用的复杂性，并因此打败市场上的竞争对手。

采用一个成熟的软件架构

好的软件架构——模式或者是框架能够为软件开发提供坚实的基础，它应该是被很好地组织起来的标准组件，并且拥有让开发者复用组件的代码库。但是在实践中，很多嵌入式的软件开发者依赖的是不断增加的而且经常是随意组织起来的软件架构，这有时会导致我们称作“spaghetti”的代码（无头绪代码）的出现。事实上，我们的研究发现，嵌入式软件的架构是它的开发中最弱的一个环节，与传统的软件开发相比，它的开发要滞后半个等级3。

这个缺点一定要被改正才行，因为软件架构的成熟度已经变成了影响生产率的重要因素。一个软件架构越是标准化和模块化，越能够进行组件的复用，点对点的接口越少，那么它就越成熟。我们的研究发现，从一个成熟度等级发展到下一个成熟度等级能够使得生产率提高2.5倍。在大多数案例中，改进来自于放弃现存的平台并且再采用一个更加先进的架构作为公司的标准。要想进一步地提升，就要对标准的操作系统、硬件以及集成的平台进行取舍。嵌入式软件的开发者期望能够达到目前传统软件开发者所能获得的生产率。一个电信设备公司已经从它自有的系统切换到了一个嵌入式的Linux架构，并且发现它开发一个新特性比以前快六倍。一个发动机控制器的供应商投资建设了一个柔性的分层软件架构，将产品投放市场的时间从四个月缩短到了三周。

要了解何种方式更经济

成本的压力能够迫使供应商和汽车制造商试着通过选择更便宜的投入品来节约成本，但是这个解决方案经常提高了保修成本。在硬件方面，更加便宜的组件可能磨损得更快。在嵌入式系统中，错误通常会隐藏在差劲的设计或者不完善的测试中。当供应商和原始设备制造商采取了按费用设计（design-to-cost）的计划后，他们必须学着考虑一个范围更加宽的标准，这包括复杂软件的生命周期成本以及更加便宜的硬件成本。一个汽车制造商要想降低它的零部件的成本就必须分析它是否能够使用更加便宜的硬件，而这个选择可能需要更多的软件的开发并且可能导致更多的缺陷。这种额外的复杂性可能导致更高的维修成本。公司通过计算知道，要达到盈亏平衡点需要生产260，000个单位。通过使用更昂贵的硬件，它能将盈亏平衡点降低到120，000个单位。

改进开发过程

很多使用嵌入式软件的公司，无论是汽车生产商还是电信设备制造商或者是耐用电器生产商都有工程化的思维传统。结果，他们经常会采用硬件驱动的解决方案，并且经常机械地看是不是组件能够很好地配合。这样的公司需要改进他们开发以及集成软件系统的技巧。

在过去的20年中，软件工业已经通过采用全球通用的质量检测手段例如CMM（Capability Maturity Model）或者那些基于功能点的方法来使得它的开发方法变得专业化。但是嵌入式系统的软件开发滞后于整个行业的发展。几乎没有适合嵌入式开发的软件开发工具，并且那些现有的工具都专注于整个开发周期的一部分而不是全部。因为嵌入式开发需要软件以及硬件工程的专门技术，最好的方法包括使用由专家组成的交叉功能团队（基于特性的开发），适用于通用模型的开发方法论，仿真工具，以及“时间盒”（给开发者设定提交的截至日期）。通过组建交叉功能团队以及时间盒开发，一个导航系统公司的生产率比行业平均水平提高了近两倍。

实施改进措施

随着很多行业的产品日益依赖软件，汽车供应商需要从硬件开发的思维模式转换到软件迭代开发的思维模式上来。和许多别的软件开发者相比，那些创建了汽车行业嵌入式软件的公司认为自己是正宗，更加不可能遵从那些提高了劳动生产率的别的公司的标准——举例来说，测量两个开发流程的劳动生产率（比方说，通过每人每月完成的功能点）以及软件的质量（每个功能点的缺陷的数量）。这些开发者依然在硬件开发的模式下进行复杂的工作，所以，以硬件为导向的生产率的测量依然控制者他们的思想。直到公司学着按照软件为导向的标准来衡量开发过程的生产率以后，他们才能努力改善他们的绩效并且获得正确的平衡。例如提高他们最开始在架构上的投资来提高软件的质量。

管理人员要改变已经建立起来的思维模式也是一项非常艰难的工作。在公司内部，他们必须说服工程师采用接近监控生产率的标准，有时几乎没有雇员会喜欢这样做。他们也将必须进行财务上的争吵，最后还要为了更高的内部的生产率标准而把已经建立好的架构和开发流程卖出去。别的行业的案例能够帮助管理人员进行这样的改变，而且这项工作随着更多的汽车供应商的加入会不可避免地变得更加容易。在汽车供应网络中，个体的厂商必须变得更加熟悉他们的系统怎样与别的供应商的系统进行互操作。私有的技术是重要的，但是他们再也不能是一个黑盒子，因为汽车制造商需要进行必要的连接。在强大的行业标准不存在的时候，系统集成商会有很多新的机会。

汽车制造业虽然只是一个特殊的案例，但正是在这个行业，嵌入式软件的潜能正在被浪费，而且目前开发模式的弱点被暴露无疑。如果汽车制造商和其它制造商要为它们质量的名誉而战的话，他们以及他们的供应商必须提高嵌入式软件的质量并且使开发更加有效率以缩短投放到市场的时间。