《车企如何掌握卓越软件开发能力.docx》由会员分享，可在线阅读，更多相关《车企如何掌握卓越软件开发能力.docx（15页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、车企如何掌握卓越软件开发能力软件正在快速重塑汽车行业。近年来，业内的四股颠覆浪潮自动驾驶化、网联 化、电动化、共享化（ ACE S ）全都重度依靠先进的软件。这些领域将来还将迎来更多的颠覆发展。全行业的整车厂（ O EM ）、供应商和新企业无不希望自己能在这条由 软件驱动的新价值链上把握住关键的控 制点。软件：关键的行业转折点 随着行业格局变更，缺少软件实力的车企将面临重大风险，包括量产（ SO P ）延期和预算超支。它们甚至可能落后于竞争对手 和新入场者，倘如后两者能以快得多的速 度将新奇得多的产品推向市场的话。更糟的是，软件问题可能导致大规模召回，或是让车企无力防范因黑客攻击而产生的客户平
2、安风险。我们的探讨显示，软件实力强的企业和实力弱的企业之间的差距是显著的，实力最强的企业报告中公布的产量和质量，比实力垫底的企业高出三到六倍 1 。这一开发效率差距远大于不同实力的硬件生产商之间可产生的差距。许多车企已相识到强大的软件开 发实力带来的各种优势，也正在实行大刀阔斧的措施改善业绩。一些车企安排在今后几年提升软件实力，并将聘请数以千计的软件工程师；另一些则将重新定义治理模式，建立合作关系，并在全球推广卓越软件开发中心。然而，我们认为这些措施是不够的，因为只有当车企针对软件开发更新了基础运营模式的时候，真正的变革才会到来。依据我们的探讨，在那些认为软件是主要颠覆因素的车企研发领导当中，
3、仅有 40 % 的人觉得自己已为必要的运营变革做好了打算 2 。虽然一些领军车企已在软件工程实践上取得长足进步，但大部分车企仍旧远远落后于佼佼者。目前车企的问题集中在几个领域：灵敏实践、持续集成、自动化测试。软件开发转型的风险如此之大，车企必需对一整套软件开发方法进行重新思索，包括基础运营模式等。本文共享了我们通过 与车企、供应商，以及生态圈中其他合作伙伴亲密合作，收获的关键理念和洞见。这些洞见还建立在两项基础上：一是针对技术专家开展的广泛访谈，二是利用麦肯锡 S o tt C os t er 专有数据库进行的大规模对标。依据我们的探讨，在那些认为软件是主要颠覆因素的车企研发领导当中，仅有 4
4、 0 % 的人觉得自己已为必要的运营变革做好了打算1基于麦肯锡的 S o f t C os t er 专有数据库的信息，该数据库包含多个行业的 1 4 000 多个软件开发项目。2 麦肯锡将来研发调研。软件困难度提高的速度比生产力提高的速度更快各时期软件困难度与生产力的相对增幅，已依据汽车软件特征做了指数化4 困难度 32生产力120102020 2 0 2 02 03 0 1 23 O n d r e j B u rk a c k y ,J oh a nn e sDe ic h m a nn ,J a nP a u lS t e i n 2 03 0 A u t o m o ti v e s
5、 o f twar ea n de l e ct ro n i c s2 0 3 0 :M a pp i n gt h es e c t o r ’ sf u tu r el a n d s c a p e2 0 1 979M c K i n s ey . c o m2533 . 56211 . 541ADA S253 5111 21软件开发实力位居前 25% 的企业表现出明显较高的生产力、开发通量和质量第四四分位平均水平 1第一四分位研发实力处在平均水平和第四四分位上的研发组织在研发业绩上的潜在增长 生产力， 每人周的困难度单位 ¹开发通量， 每周困难度单位 1质量，
6、残余设计缺陷 +3.5× +3.0×224175155–6.0×100100100656527 1.平均水平已指数化，基准值 100 。每人周困难度单位代表每个全职员工的生产力。每周困难度单位代表整个组织的生产力。资料来源：麦肯锡 SoftCoster 嵌入式软件项目数据库2第一个维度开发什么软件聚焦的是通过模块化和解耦的硬 件/ 软件架构、以用户为中心的设计，以及需求管理，来降低开发困难度。其他三个维度所聚焦的，则 是通过供应合适的结构、流程和基础设施 A.开发什么软件：架构、设计及各项要求 在新的运营模式下，企业必需把与软件相关的开发目标和业
7、务机会转化为产品、功能和 模块等层面上的可行架构、产品及投资组合 提高软件开发的效率。我们从四个维度动身，需求。通过这个流程，企业可以具体了解能 明确了 11 项最佳实践，这些做法能帮助车企胜利地解决在软件上面临的挑战（图 3 ）。志向状况下，企业将同时处理好全部维度。为其创建价值的软件类型。这个流程还将 助力企业降低架构的困难度，应用以用户为中心的设计流程，改善对软件需求的管理。图 3新的软件开发运营模式须要对四个关键维度做出变更各维度的最佳实践 调整组织并建立 确保企业有实力 全球卓越中心 获得顶尖软件开 发人才资源，并对其保持吸引力 制定清楚的自制或外购策略并建立合作生态圈 实施绩效管理
8、 实施大规模灵敏方法实现硬件与软件开发之间的解耦 提高测试的自动升级到标准化的先进软件开发工具链 化程度，实现成 熟的持续集成 降低架构的困难度 的设计 理方式进行调整 应用以用户为中心 对软件需求的管 如何开发软件CD如何促进软件开发开发什么软件在哪里开发软件BA车企必需力争实现一个志向架构，使之能支持软硬件之间的解耦，而且具备强大的中间件层次 云平台 联网（回传）应用层 将围绕服务重构用户界面/用户体验/人机界面•将依据现代软件开发的各种做法，在不对基础硬件做假设的状况下打造应用•AI/AA 将通过中间件/数据库运用专业硬件应用 人工智能/高级分析 中间件层/操作系统中
9、间件层次将抽取硬件并将 API 暴露给上层软件电气/电子硬件•模块化的中间件架构•API 将定义可供上层软件运用的困难的、传感器执行器动力构件标准化的硬件功能集合•标准化的操作系统将协调各类电子及域汽车限制单元以及传感器之间的功能，确保互通性 A 1 . AP I 4O E M4 而且企业也还没有明确这些系统的准确研发重点和功能。通过遵循明确的架构原理和指导原则，企业能够有效地应对更高的系统和软件困难度。硬 件/ 软件解耦允很多个实体参加模块化开发。反过来，由于代码共性增多，模块 化软件构建技术可增加对代码的重复利用，并削减须要的代码总量。许多企业已着手引入软件产
10、品线工程（ PL E ）方法，以增加重复利用，同时处理产品变更。这个方法能让一个软件服务于多个产品、产品变体和产品系列，还可以兼容不同的硬件版本。软件 PL E显著降低了开发和测试工作的难度，这两项工作都只需进行一次。换句话说，促使硬件从软件上解耦，可促使硬件实现进一步的 自主化 ，硬件供应了标准的计算、存储、输入 / 输出和电源功能，而软件则定义了终端用户功能。对于须要标准性能的应用，不同的软件功能可以利用虚拟化和容器化技术在相同的硬件上运行，如有必要，还可以动态地分布到其他硬件（例如在硬件发生故障的状况下）。对于 ADA S等存在实时性能要求的应用，针对特定硬件的软件开发工作对于实现最优效
11、率仍旧至关重要。以服务为导向的架构。该架构应当遵循各项服务的定义，反过来，这些定义则应将业务或用户需求代码化。以服务为导向的架 构设计既能让企业实现各核心要素的标准化，也能让各部门和各业务单位之间的接口实现标准化。企业还应对单项硬件和软件要素应用标准化的设计，以便在不影响性能的状况下，针对其他支持设备和功能规模化地配置资源，如计算和存储资源。以服务为导向的架构对 O E M 尤为重要。实现从车辆 到云端的快速连接，不仅将提升车企各种车型的长期价值，也将推动车企实力的快速更新和升级。A2 . 应用以用户为中心的设计技术 综观各行业，专注于开发以用户为中心的 强大设计、创建最优用户体验（ UX ）
12、的企业，将实现更高的财务收益 4 。随着 ACE S 概念 持续受到追捧，软件定义的汽车成为常态，对于 O EM 的整体竞争力而言，这些特征将 会变得越来越重要。即便是顶尖企业也须要做改进，缘由在于汽车行业在设计良好的软件用户体验、供应最优的客户价值等方面仍旧落后于其他行业。根据最佳实践奉行的设计原则， O EM 应当与终端用户合作对新软件进行迭代，无论 交付前后都应如此。车企也应当采纳新的 交付模式，以便以每周或每月一次的频率对软件进行更新或添加，从而实现持续的优化。这些工作的周期相比经典软件开发工作短了很多，后者通常须要几年时间。新的交付模式还有一个好处，它可以让 O EM与客户实现持续的
13、干脆接触，从而使 O EM持续收到反馈，而这些反馈有助于它们优 化软件需求，供应主动的用户体验提升。当 O EM 依靠硬件实现升级时，此类互动是不行能实现的，因为接触只会在通过经销商网络进行的一次性销售或市场调研期间发生一次。为了达到这个目标状态， O EM 须要落实必要的先决条件，例如配套的软件和电子架构，以及可实现云端更新的工具链。希望成为用户体验领导者的 O EM 必需对自己的数据善加利用。随着车载软件和传感器数量不断增多， O EM 如今能够获得大量的数据，以了解客户如何运用汽车。O EM可以挖掘此类数据，识别对客户最重要的4 基于针对业务发展的麦肯锡设计指数评分的相关分析。如欲了解更
14、多信息，参阅 B e ne dic tS he pp a r d,H u goSa rr a z i n ,G a r e nKou y ou m j i a n 和 F a b r icioD or e 合撰的文章设计的商业价值（ T h eb u s i n e ssv a l u eo fd e s i g n ）,M cKi n s eyQ u a r t e r l y ,20 1 8 年 10 月 25 日 ,M cKi n s ey . c o m 。胜利的软件开发须要依据客户反馈对需求进行持续的调整和修正特性，以及配置超标或根本没人用的特性。重关注价值创建，并能在软件开发期间设
15、定 这些洞见将为明确配置和将来型号需求供应参考。最终，新的交付模式将给开发效率带来主动影响。鉴于车企将对软件进行常见的变更、调适、修改，它们不须要从项目一起先的时候就确定极端具体的需求。由于用在定义需求上的时间缩短了，产品面市时间也将缩短。A3 . 调整软件需求管理 历史上，汽车行业曾是在集成的价值链上管理各项需求的领导者。但是， O E M 主要关注的是硬件需求，而且它们的既有流程并未 针对软件调适到最优状态。随着车载软件成为重要的差异化因素， O EM 必需采纳新 的做法来管理需求。管理需求的变更尤为重要，因为我们的探讨显示，对汽车软件的种种需求已经变得过于细化，以至于拖慢了开发进程。根据
16、最佳实践， O EM 应当基于客户价值对各项需求进行聚类。第一个层级应当主要 合理的优先事项。随着车企将各种需求划 分到多个层级，以下工作能够起到帮助作用。将需求与战略和客户价值挂钩。胜利的软件开发须要依据客户反馈对需求进行持续的调整和修正。虽然企业在初期就应依据其商业战略和目标定义软件需求，但它们也应依据客户反馈和开发进度周期性地做出调整。确保端到端的可追溯性。通过在整条价值链上对需求进行亲密追踪，车企可避开做无用功，加快开发进程。但是，只有当车企的开发流程和工具链能够从定义到验收全过程实现需求的严格可追溯性时，车企才能做到这一点。这种明确性有助于车企了解清晰各项需求（客户观点）、须要的功能
17、 （开发者观点），以及各项交付成果（测试者观点）。车企必需分四步实现端到端的追踪，这要么须要用到少数几种高度集成的工具，要么用到四种专业工具，并搭配相应的接口。这 包括面对客户的需求（通常被表述为用例）。些步骤是：另一个层级主要包括技术或实施方面的需 求（通常被表述为赋能因素），比如某个特性所需的内存。这个方法可以保证 O EM 着 对需求进行追踪，从特性到构件对这些需求进行细化和详细说明管理待办清单，这项工作有助于各团队在软件开发冲刺时管理好各项需求的覆盖范围（与下一个步骤亲密相关） 追踪代码变更，包括对代办项目的更新 通过开展测试案例对需求进行验证，并检查测试案例的通过 - 失败状态 利用
18、工具将各项需求关联起来，用户能够高效地在项目的每个阶段实施变更，从而满意监管对端到端可追溯性的各种要求 （例如， A S P I CE 或 U N EC E 5 ）。利用这个方法，我们能快速弄清晰哪些变更影响到了哪些工作成果。当遵循灵敏流程开发软件时，此类需求变更是正常的，也是可取的 （如基于客户反馈的变更），企业应当利用各种流程和工具对它们予以支持。在软件开发工作的传统瀑布式流程当中，此类变更是罕见的，而且通常也预见不到。避开过度细化，创建明确的需求类别。企业可以建立一些最佳实践，对软件需求进行详细说明和分类，并拟定精简的测试方法。一份优秀的需求说明应当是清楚明确的，而且允许测试工作不受其他需求影响。与组合管理一样，企业应当对不同类型的需求加以区分。常见的需求类别包括法律监管类、平安类、战略类，以及必要改进、客户价值、成本赋能等因素。另外，企业还必需确保，凡是需求之间的依存关系都应当是透亮的。许多企业已经将这些规则融入到自己的软件开发流程和培训课程之中，以便优化对需 求的处理和评审过程。开展优先排序，进行持续调整。企业既应依据详细的商业论证和战略目标，也应依据在整个开发过程中（例如在测试过程中）获 得的客户反馈和和阅历对软件需.