正版新书]智能汽车电子与软件:开发方法、系统集成、流程体系与

目    录  Contents<br />赞誉<br />前言<br />第1章  汽车向软件转型的行业背景1<br />1.1  百年汽车走向软件1<br />1.1.1  手工打造奢侈品的法系车2<br />1.1.2  面向95％平民的福特2<br />1.1.3  欧洲汽车品牌百花齐放3<br />1.1.4  通用汽车推进汽车组织现代化4<br />1.1.5  丰田与精益互相成就5<br />1.1.6  环保与安全法规的约束5<br />1.1.7  汽车全球模块化供应6<br />1.1.8  汽车智能的前身与延续6<br />1.2  汽车工业的特点—技术隐形化7<br />1.2.1  NVH正在淡出理论研究7<br />1.2.2  Know-How构筑技术壁垒8<br />1.3  软件工程化与汽车工业化的结合9<br />1.3.1  工程化的内涵与模式9<br />1.3.2  工业化的大批量要求10<br />1.4  安全成为汽车智能化的红线12<br />1.4.1  总是上热搜的安全事件12<br />1.4.2  当我们谈安全时我们在谈什么12<br />1.4.3  怎么保障软件的安全15<br />1.5  软件正在改变汽车格局16<br />1.5.1  从几个故事看形势与趋势16<br />1.5.2  销量为王—行业地位的<br />    变化17<br />1.5.3  顾客在逐渐被视为“上帝”17<br />1.6  传统汽车的没落18<br />1.6.1  变局来得出其不意18<br />1.6.2  一些仍在混战的观点19<br />1.6.3  传统汽车确实呈现疲态20<br />1.7  本章小结21<br />第2章  软件开发与汽车组织的融合22<br />2.1  Tier 1和OEM常见的组织模式22<br />2.1.1  Tier 123<br />2.1.2  OEM26<br />2.2  软件开发在整车交付中的位置29<br />2.2.1  功能、ECU、域和中央计算30<br />2.2.2  软件仍需进入汽车31<br />2.2.3  合作模式持续变化31<br />2.3  软件自研成为OEM的期望32<br />2.3.1  自研与外购的决策要素33<br />2.3.2  如何选择自研对象33<br />2.4  OEM如何融入软件供应商内部34<br />2.4.1  入局资格—承诺34<br />2.4.2  打到“七寸”的承诺—<br />    详细标准35<br />2.4.3  再深入一点—审计36<br />2.4.4  持续深入—工具36<br />2.5  软件供应商如何进入OEM体系37<br />2.5.1  资质认证37<br />2.5.2  开发前移38<br />2.5.3  定制化38<br />2.5.4  能力共建38<br />2.6  走向开放协同与敏捷迭代的<br />     汽车组织39<br />2.6.1  开放协同39<br />2.6.2  敏捷迭代39<br />2.7  汽车企业文化与软件的冲突40<br />2.7.1  文化就是游戏规则40<br />2.7.2  文化与软件的冲突41<br />2.8  从软件质量看组织转型路径42<br />2.8.1  无所适从的汽车软件质量42<br />2.8.2  传统汽车质量的启发43<br />2.8.3  质量管理的目标—干掉<br />    质量44<br />2.8.4  软件质量的落地路径44<br />2.9  本章小结46<br />第3章  面向整车的软件项目管理47<br />3.1  汽车软件全生命周期47<br />3.1.1  技术推动与市场拉动48<br />3.1.2  六大环节48<br />3.2  软件项目的开端—裁剪53<br />3.2.1  裁剪的通俗理解53<br />3.2.2  裁剪的理论逻辑53<br />3.2.3  裁剪的落地思路54<br />3.3  软件与样件产品交付的方法55<br />3.3.1  软件交付的3个关注点56<br />3.3.2  样件交付成熟度的划分—<br />    ABCD样件57<br />3.4  软件里程碑质量评审流程59<br />3.4.1  里程碑和质量门的关系59<br />3.4.2  如何开展质量门评审60<br />3.4.3  略显尴尬的评审66<br />3.5  软件bug的管理模式67<br />3.5.1  机械与软件的不同67<br />3.5.2  汽车与互联网的不同68<br />3.5.3  最“好”的开发过程—<br />    bug管理69<br />3.6  软件项目变更管理72<br />3.6.1  是不是变更的争论72<br />3.6.2  变很痛，那不变呢72<br />3.6.3  如何做好变更管理73<br />3.7  软件项目文档管理74<br />3.7.1  图书馆学五定律74<br />3.7.2  过程法与要素法75<br />3.8  软件项目配置管理76<br />3.8.1  从一张“标签”说起76<br />3.8.2  一项完美的配置管理工作78<br />3.8.3  配置管理的优选价值79<br />3.8.4  烦琐之处在哪里80<br />3.8.5  基于价值，删繁就简81<br />3.9  软件项目风险管理82<br />3.9.1  风险的含义82<br />3.9.2  风险管理的形式化83<br />3.9.3  风险形式之外的价值83<br />3.10  软件项目成本估算84<br />3.10.1  3个估算对象84<br />3.10.2  2个估算方法85<br />3.11  数据驱动软件开发86<br />3.11.1  开发是否有必要关注数据86<br />3.11.2  怎么理解汽车软件的<br />    数据分析87<br />3.11.3  数据分析的3个段位88<br />3.12  软件开发数字化转型91<br />3.12.1  转型之道—高层的决心91<br />3.12.2  转型之术—流程与数据92<br />3.13  软件项目复杂性的驾驭思路94<br />3.13.1  如何理解软件项目复杂性95<br />3.13.2  平台化项目的要素及特点96<br />3.13.3  复杂性的表现及应对思路98<br />3.14  软件项目经理的汇报技巧99<br />3.14.1  纸上谈兵1.0之能上能下99<br />3.14.2  纸上谈兵2.0之细节100<br />3.14.3  一个实用的汇报框架100<br />3.15  本章小结101<br />第4章  软件开发与产品系统<br />    集成流程102<br />4.1  从一个旋钮看智能汽车102<br />4.1.1  莫名其妙的客户需求103<br />4.1.2  机械结构的设计103<br />4.1.3  电子硬件的设计104<br />4.1.4  软件、架构与安全的设计105<br />4.2  汽车软件开发基础模型—<br />    V模型107<br />4.2.1  瀑布模型是一种认知逻辑107<br />4.2.2  V模型的本质108<br />4.3  汽车软件需求开发与管理111<br />4.3.1  一些有关需求的感触111<br />4.3.2  需求收集与整理114<br />4.3.3  需求分析与分解116<br />4.3.4  需求实现与测试121<br />4.3.5  一个具体项目的需求管理123<br />4.3.6  State of the Art125<br />4.4  统领全局的汽车电子电气架构126<br />4.4.1  整车EEA简述126<br />4.4.2  SOA与AUTOSAR的对比130<br />4.4.3  系统工程与系统架构的内涵133<br />4.4.4  软件架构的准则与描述137<br />4.5  从软件到整车的集成方法140<br />4.5.1  软件集成与分支划分140<br />4.5.2  软件向硬件集成144<br />4.5.3  产品向整车集成144<br />4.6  汽车软件测试的整体框架144<br />4.6.1  什么是软件测试145<br />4.6.2  测试策略的定义145<br />4.6.3  测试计划与管理147<br />4.6.4  测试执行的分类149<br />4.6.5  测试报告的编写154<br />4.6.6  整体测试状态汇总154<br />4.7  复杂的汽车软件追溯154<br />4.7.1  追溯的4个概念155<br />4.7.2  软件工程逻辑下的追溯158<br />4.7.3  追溯对bug的实用性160<br />4.8  本章小结162<br />第5章  软件开发所面临的<br />    行业体系163<br />5.1  制造业体系基础—ISO 9000164<br />5.1.1  ISO 9000有什么用164<br />5.1.2  5个基本概念164<br />5.1.3  质量管理7个原则165<br />5.2  汽车行业体系基础—IATF 16949167<br />5.2.1  总体概述167<br />5.2.2  整体策划169<br />5.2.3  相关支持170<br />5.2.4  体系运行171<br />5.2.5  绩效评价174<br />5.2.6  持续改进174<br />5.3  汽车软件过程基础—ASPICE175<br />5.3.1  整体介绍175<br />5.3.2  过程能力确定176<br />5.3.3  过程参考模型（1级）181<br />5.3.4  过程能力等级（2～5级）188<br />5.3.5  ASPICE 4.0的宏观变化193<br />5.3.6  ASPICE不同等级的内涵194<br />5.4  汽车软件标准之间的逻辑链195<br />5.4.1  ISO 9000/9001195<br />5.4.2  IATF 16949196<br />5.4.3  CMMI和ASPICE196<br />5.4.4  OEM标准198<br />5.5  软件工程的持续改进198<br />5.5.1  从颠覆回到改进199<br />5.5.2  软件工程的改进对象199<br />5.5.3  软件工程的改进来源200<br />5.5.4  软件工程的改进步骤202<br />5.5.5  改进的3个段位203<br />5.6  本章小结205<br />第6章  软件组织角色的构建<br />    与转型206<br />6.1  汽车软件开发角色大起底206<br />6.1.1  人人无法回避的“角色”206<br />6.1.2  支撑组织的3条角色线207<br />6.1.3  组织角色的分类208<br />6.1.4  项目角色的分类210<br />6.1.5  流程角色的分类212<br />6.2  不同角色的能力发展要求212<br />6.2.1  两条路径看角色能力等级213<br />6.2.2  系统类角色技能点定义217<br />6.2.3  软件类角色技能点定义219<br />6.3  智能汽车对“六边形”人才<br />     的期待221<br />6.3.1  从文艺复兴看汽车变革221<br />6.3.2  既懂汽车，又懂软件221<br />6.4  个体角色职业转型的考虑223<br />6.4.1  先从个体处境出发223<br />6.4.2  两个维度寻找切入点225<br />6.5  从软件开发转向项目经理228<br />6.5.1  脱离执行与秉持逻辑228<br />6.5.2  心态要好229<br />6.5.3  管理要学框架230<br />6.6  本章小结230<br />第7章  软件开发相关的<br />    汽车方法论231<br />7.1  项目管理字典—PMBOK232<br />7.1.1  项目管理的131个工具232<br />7.1.2  项目管理的12个原则235<br />7.2  汽车行业如何践行软件敏捷240<br />7.2.1  敏捷必要性的两种理解240<br />7.2.2  敏捷内涵的多维度解读241<br />7.2.3  敏捷的一些良好实践245<br />7.3  风险分析之FMEA247<br />7.3.1  生活对FMEA的启发247<br />7.3.2  FMEA的新七步法248<br />7.4  软件进入汽车的门槛—<br />     功能安全255<br />7.4.1  功能安全大概是什么257<br />7.4.2  功能安全概念阶段259<br />7.4.3  功能安全产品开发之系统、<br />    硬件及软件264<br />7.4.4  整体功能安全管理266<br />7.5  自动驾驶的安全—预期<br />     功能安全268<br />7.5.1  由功能安全引出268<br />7.5.2  SOTIF基本逻辑270<br />7.5.3  SOTIF迭代模型272<br />7.5.4  SOTIF关键活动展开272<br />7.6  汽车软件的行业挑战—<br />    信息安全277<br />7.6.1  由功能安全引出278<br />7.6.2  TARA分析279<br />7.6.3  信息安全开发概述283<br />7.7  解决复杂软硬件问题的<br />     思路—8D284<br />7.7.1  关于8D的感触284<br />7.7.2  8D的8个步骤284<br />7.8  本章小结288<br />第8章   汽车软件开发工具链289<br />8.1  有关工具链的一些话题289<br />8.1.1  对工具自身意义的思考290<br />8.1.2  不同环节常用的工具类别290<br />8.1.3  如何理解工具链的“链”291<br />8.1.4  对使用者的两个指导原则292<br />8.2  数字化工具里的“项目”293<br />8.2.1  项目的一些基本特点293<br />8.2.2  走进工具的基本思路294<br />8.3  Office上线之需求管理295<br />8.3.1  需求管理的基本形式296<br />8.3.2  场景1：复制粘贴297<br />8.3.3  场景2：定义多重属性298<br />8.3.4  场景3：建立双向链接300<br />8.3.5  场景4：链接其他工作项301<br />8.3.6  场景5：建立配置与基线302<br />8.3.7  场景6：输出统计报告303<br />8.3.8  场景7：人与人的交互303<br />8.4  被驱动型的测试管理303<br />8.4.1  场景1：定义测试计划303<br />8.4.2  场景2：建立用例库304<br />8.4.3  场景3：测试报告的汇总304<br />8.5  协同合作之工作项管理305<br />8.5.1  场景1：变更管理305<br />8.5.2  场景2：bug管理306<br />8.5.3  场景3：需求管理307<br />8.6  计划总赶不上变化的项目计划307<br />8.6.1  汽车软件计划的3个特点307<br />8.6.2  场景1：自动更新309<br />8.6.3  场景2：层级视角的切换309<br />8.6.4  场景3：依赖关系直观展示309<br />8.6.5  场景4：交付物下探310<br />8.7  数据分析工具310<br />8.7.1  透视表311<br />8.7.2  可视化图311<br />8.8  本章小结311<br />第9章  转型软件的痛点与困惑312<br />9.1  互相低不下的头颅312<br />9.2  硬件交样与软件迭代的冲突313<br />9.2.1  硬件交样313<br />9.2.2  软件迭代313<br />9.3  对敏捷自身价值的质疑314<br />9.3.1  水土不太服的敏捷314<br />9.3.2  敏捷的现状约等于“乱”315<br />9.3.3  敏捷和标准化谁更优选315<br />9.3.4  敏捷应作为意识还是框架316<br />9.4  依旧太高的信息壁垒316<br />9.4.1  黑盒交付的后果316<br />9.4.2  互相制衡的文化317<br />9.5  ASPICE的爱与恨317<br />9.5.1  ASPICE很好318<br />9.5.2  ASPICE也很糟318<br />9.6  bug怎么这么多319<br />9.6.1  前期发现不了319<br />9.6.2  后期修复不完319<br />9.7  欲拒还迎的转型320<br />9.7.1  转向讲故事320<br />9.7.2  转向体验感320<br />9.8  本章小结321<br />第10章  展望未来汽车软件<br />    开发模式322<br />10.1  搭积木般造车322<br />10.2  推倒SOP的后墙323<br />10.3  实现本质安全324<br />10.4  再也不写文档325<br />10.5  可视化网状协同326<br />10.6  汽车行业大洗牌327<br />10.7  本章小结328

（1）作者背景权威：现在就职于某头部OEM，曾就职于奥托立夫、博世等头部Tier 1企业，在汽车软件研发和管理领域有广泛的影响力。
（2）作者经验丰富：拥有10余年世界100强汽车Tier 1和OEM技术与管理实战经历，在系统集成、电子系统架构开发、功能安全管理、软件项目管理、软件质量管理方面经验丰富。
（3）全行业推荐：华为、腾讯、广汽、长城、极氪、蔚来、小鹏等20余家车企和机构的25位专家高度评价和推荐。
（4）全景式解读：从行业背景、组织架构、项目管理、软件开发方法、系统集成、流程体系、核心标准、开发工具链等维度全景解读智能汽车电子与软件的开发方法与管理体系。