新書推薦：
《
养育男孩：官方升级版
》
售價：HK$
50.4
《
小原流花道技法教程
》
售價：HK$
109.8
《
少女映像室 唯美人像摄影从入门到实战
》
售價：HK$
110.9
《
詹姆斯·伍德系列：不负责任的自我：论笑与小说（“美国图书评论奖”入围作品 当代重要文学批评家詹姆斯·伍德对“文学中的笑与喜剧”的精湛研究）
》
售價：HK$
87.4
《
武当内家散手
》
售價：HK$
50.4
《
诛吕：“诸吕之乱”的真相与吕太后时期的权力结构
》
售價：HK$
99.7
《
炙野（全2册）
》
售價：HK$
78.2
《
女人的胜利
》
售價：HK$
55.9
|
| 編輯推薦： |
（1）作者背景权威：现在就职于某头部OEM，曾就职于奥托立夫、博世等头部Tier 1企业，在汽车软件研发和管理领域有广泛的影响力。
（2）作者经验丰富：拥有10余年世界100强汽车Tier 1和OEM技术与管理实战经历，在系统集成、电子系统架构开发、功能安全管理、软件项目管理、软件质量管理方面经验丰富。
（3）全行业推荐：华为、腾讯、广汽、长城、极氪、蔚来、小鹏等20余家车企和机构的25位专家高度评价和推荐。
（4）全景式解读：从行业背景、组织架构、项目管理、软件开发方法、系统集成、流程体系、核心标准、开发工具链等维度全景解读智能汽车电子与软件的开发方法与管理体系。
|
| 內容簡介： |
这是一本从技术与管理角度全景式介绍智能汽车电子与软件的著作，涵盖行业背景、组织架构、项目管理、开发方法、系统集成、流程体系、人员搭建、核心标准、开发工具链、痛点及展望等核心内容。本书是作者在博世等头部Tier 1与OEM企业10余年技术与管理经验总结，得到了来自华为、腾讯、广汽、长城、极氪、蔚来、小鹏等20余家车企和机构的25位专家高度评价和推荐。
第1章从行业发展的里程碑、技术演变、行业格局、安全问题、量产落地、传统汽车与互联网的融合等角度阐释了汽车行业的特点，有助于读者理解软件在汽车行业落地与深化时碰到的一些现象或问题。
第2章从Tier 1与OEM的组织模式特点及软件所处位置开始，引出组织变化与融合的趋势，并以软件质量为例提出了软件体系进入汽车企业的路径，为读者提供参考思路。
第3章从汽车软件全生命周期和交付的角度对开发的主干进行梳理，摘取质量门、bug管理、变更管理、文档管理、配置管理、风险管理、成本估算等重要主题，进行了不同角度和相互贯通的阐述。
第4章基于软硬件一体的ECU产品视角，从产品开发的角度，梳理了汽车软件开发及产品系统集成的主体脉络，具体从需求、架构、集成、测试以及整体的追溯关系上进行了展开叙述，以期搭建一个具备一定普适性的汽车软件开发的工程框架。
第5章侧重体系框架的梳理，依次对ISO 9000、IATF 16949、ASPICE等标准进行了详细解读，让读者能够对普适性体系标准在汽车软件领域的落实情况有所了解。
第6章从一个典型的软件组织角色定义说起，依次梳理了组织、项目、流程3条角色线的相关内容，以便读者快速理解对应组织的人员组成及其与自身的映射关系。
第7章重点介绍方法论与开发标准，包括项目管理、敏捷实践、FMEA（失效模式及影响分析）、三大安全、8D等主题，从不同的维度引出了一些实际工作中经常遇到的问题。
第8章从汽车软件开发工具链应用场景的角度进行了梳理。考虑到专业软件开发属于更细分的领域，而且与汽车行业本身的关联性不大，所以该章整体侧重介绍开发管理类工具。
第9章总结了整个转型过程中始终面临的一些具体问题，包括从业者心态难以调整、软硬件差异、敏捷无法奏效、信息壁垒高筑、ASPICE繁重、转型迟缓等。
第10章通过一个轻松简短的幻想场景来为全书收尾，不追求可操作性，但希望能够引发读者的一些思考。这也是对全书主题的升华和总结，希望能对广大读者有所启示。
|
| 關於作者： |
|
杨修文，资深汽车软件研发管理专家，现就职于某头部OEM，致力于智能汽车软件开发体系搭建、转型及改善等方向的研究与实践。拥有10余年世界100强汽车Tier 1和OEM技术与管理实战经历，曾在奥托立夫、博世等企业负责整车系统集成、电子系统架构开发、功能安全管理、软件项目管理、软件质量管理等工作，积累了汽车电子与软件头部企业的全流程经验。曾负责20 项目交付，与业内主流车企都有过密切的工作交互，对中国汽车行业现状有深刻理解，在软件研发管理领域内有着广泛的影响力。
|
| 目錄：
|
目 录 Contents
赞誉
前言
第1章 汽车向软件转型的行业背景1
1.1 百年汽车走向软件1
1.1.1 手工打造奢侈品的法系车2
1.1.2 面向95％平民的福特2
1.1.3 欧洲汽车品牌百花齐放3
1.1.4 通用汽车推进汽车组织现代化4
1.1.5 丰田与精益互相成就5
1.1.6 环保与安全法规的约束5
1.1.7 汽车全球模块化供应6
1.1.8 汽车智能的前身与延续6
1.2 汽车工业的特点—技术隐形化7
1.2.1 NVH正在淡出理论研究7
1.2.2 Know-How构筑技术壁垒8
1.3 软件工程化与汽车工业化的结合9
1.3.1 工程化的内涵与模式9
1.3.2 工业化的大批量要求10
1.4 安全成为汽车智能化的红线12
1.4.1 总是上热搜的安全事件12
1.4.2 当我们谈安全时我们在谈什么12
1.4.3 怎么保障软件的安全15
1.5 软件正在改变汽车格局16
1.5.1 从几个故事看形势与趋势16
1.5.2 销量为王—行业地位的变化17
1.5.3 顾客在逐渐被视为“上帝”17
1.6 传统汽车的没落18
1.6.1 变局来得出其不意18
1.6.2 一些仍在混战的观点19
1.6.3 传统汽车确实呈现疲态20
1.7 本章小结21
第2章 软件开发与汽车组织的融合22
2.1 Tier 1和OEM常见的组织模式22
2.1.1 Tier 123
2.1.2 OEM26
2.2 软件开发在整车交付中的位置29
2.2.1 功能、ECU、域和中央计算30
2.2.2 软件仍需进入汽车31
2.2.3 合作模式持续变化31
2.3 软件自研成为OEM的期望32
2.3.1 自研与外购的决策要素33
2.3.2 如何选择自研对象33
2.4 OEM如何融入软件供应商内部34
2.4.1 入局资格—承诺34
2.4.2 打到“七寸”的承诺—详细标准35
2.4.3 再深入一点—审计36
2.4.4 持续深入—工具36
2.5 软件供应商如何进入OEM体系37
2.5.1 资质认证37
2.5.2 开发前移38
2.5.3 定制化38
2.5.4 能力共建38
2.6 走向开放协同与敏捷迭代的 汽车组织39
2.6.1 开放协同39
2.6.2 敏捷迭代39
2.7 汽车企业文化与软件的冲突40
2.7.1 文化就是游戏规则40
2.7.2 文化与软件的冲突41
2.8 从软件质量看组织转型路径42
2.8.1 无所适从的汽车软件质量42
2.8.2 传统汽车质量的启发43
2.8.3 质量管理的目标—干掉质量44
2.8.4 软件质量的落地路径44
2.9 本章小结46
第3章 面向整车的软件项目管理47
3.1 汽车软件全生命周期47
3.1.1 技术推动与市场拉动48
3.1.2 六大环节48
3.2 软件项目的开端—裁剪53
3.2.1 裁剪的通俗理解53
3.2.2 裁剪的理论逻辑53
3.2.3 裁剪的落地思路54
3.3 软件与样件产品交付的方法55
3.3.1 软件交付的3个关注点56
3.3.2 样件交付成熟度的划分—ABCD样件57
3.4 软件里程碑质量评审流程59
3.4.1 里程碑和质量门的关系59
3.4.2 如何开展质量门评审60
3.4.3 略显尴尬的评审66
3.5 软件bug的管理模式67
3.5.1 机械与软件的不同67
3.5.2 汽车与互联网的不同68
3.5.3 最“好”的开发过程—bug管理69
3.6 软件项目变更管理72
3.6.1 是不是变更的争论72
3.6.2 变很痛，那不变呢72
3.6.3 如何做好变更管理73
3.7 软件项目文档管理74
3.7.1 图书馆学五定律74
3.7.2 过程法与要素法75
3.8 软件项目配置管理76
3.8.1 从一张“标签”说起76
3.8.2 一项完美的配置管理工作78
3.8.3 配置管理的最大价值79
3.8.4 烦琐之处在哪里80
3.8.5 基于价值，删繁就简81
3.9 软件项目风险管理82
3.9.1 风险的含义82
3.9.2 风险管理的形式化83
3.9.3 风险形式之外的价值83
3.10 软件项目成本估算84
3.10.1 3个估算对象84
3.10.2 2个估算方法85
3.11 数据驱动软件开发86
3.11.1 开发是否有必要关注数据86
3.11.2 怎么理解汽车软件的数据分析87
3.11.3 数据分析的3个段位88
3.12 软件开发数字化转型91
3.12.1 转型之道—高层的决心91
3.12.2 转型之术—流程与数据92
3.13 软件项目复杂性的驾驭思路94
3.13.1 如何理解软件项目复杂性95
3.13.2 平台化项目的要素及特点96
3.13.3 复杂性的表现及应对思路98
3.14 软件项目经理的汇报技巧99
3.14.1 纸上谈兵1.0之能上能下99
3.14.2 纸上谈兵2.0之细节100
3.14.3 一个实用的汇报框架100
3.15 本章小结101
第4章 软件开发与产品系统集成流程102
4.1 从一个旋钮看智能汽车102
4.1.1 莫名其妙的客户需求103
4.1.2 机械结构的设计103
4.1.3 电子硬件的设计104
4.1.4 软件、架构与安全的设计105
4.2 汽车软件开发基础模型—V模型107
4.2.1 瀑布模型是一种认知逻辑107
4.2.2 V模型的本质108
4.3 汽车软件需求开发与管理111
4.3.1 一些有关需求的感触111
4.3.2 需求收集与整理114
4.3.3 需求分析与分解116
4.3.4 需求实现与测试121
4.3.5 一个具体项目的需求管理123
4.3.6 State of the Art125
4.4 统领全局的汽车电子电气架构126
4.4.1 整车EEA简述126
4.4.2 SOA与AUTOSAR的对比130
4.4.3 系统工程与系统架构的内涵133
4.4.4 软件架构的准则与描述137
4.5 从软件到整车的集成方法140
4.5.1 软件集成与分支划分140
4.5.2 软件向硬件集成144
4.5.3 产品向整车集成144
4.6 汽车软件测试的整体框架144
4.6.1 什么是软件测试145
4.6.2 测试策略的定义145
4.6.3 测试计划与管理147
4.6.4 测试执行的分类149
4.6.5 测试报告的编写154
4.6.6 整体测试状态汇总154
4.7 复杂的汽车软件追溯154
4.7.1 追溯的4个概念155
4.7.2 软件工程逻辑下的追溯158
4.7.3 追溯对bug的实用性160
4.8 本章小结162
第5章 软件开发所面临的行业体系163
5.1 制造业体系基础—ISO 9000164
5.1.1 ISO 9000有什么用164
5.1.2 5个基本概念164
5.1.3 质量管理7个原则165
5.2 汽车行业体系基础—IATF 16949167
5.2.1 总体概述167
5.2.2 整体策划169
5.2.3 相关支持170
5.2.4 体系运行171
5.2.5 绩效评价174
5.2.6 持续改进174
5.3 汽车软件过程基础—ASPICE175
5.3.1 整体介绍175
5.3.2 过程能力确定176
5.3.3 过程参考模型（1级）181
5.3.4 过程能力等级（2～5级）188
5.3.5 ASPICE 4.0的宏观变化193
5.3.6 ASPICE不同等级的内涵194
5.4 汽车软件标准之间的逻辑链195
5.4.1 ISO 9000/9001195
5.4.2 IATF 16949196
5.4.3 CMMI和ASPICE196
5.4.4 OEM标准198
5.5 软件工程的持续改进198
5.5.1 从颠覆回到改进199
5.5.2 软件工程的改进对象199
5.5.3 软件工程的改进来源200
5.5.4 软件工程的改进步骤202
5.5.5 改进的3个段位203
5.6 本章小结205
第6章 软件组织角色的构建与转型206
6.1 汽车软件开发角色大起底206
6.1.1 人人无法回避的“角色”206
6.1.2 支撑组织的3条角色线207
6.1.3 组织角色的分类208
6.1.4 项目角色的分类210
6.1.5 流程角色的分类212
6.2 不同角色的能力发展要求212
6.2.1 两条路径看角色能力等级213
6.2.2 系统类角色技能点定义217
6.2.3 软件类角色技能点定义219
6.3 智能汽车对“六边形”人才的期待221
6.3.1 从文艺复兴看汽车变革221
6.3.2 既懂汽车，又懂软件221
6.4 个体角色职业转型的考虑223
6.4.1 先从个体处境出发223
6.4.2 两个维度寻找切入点225
6.5 从软件开发转向项目经理228
6.5.1 脱离执行与秉持逻辑228
6.5.2 心态要好229
6.5.3 管理要学框架230
6.6 本章小结230
第7章 软件开发相关的汽车方法论231
7.1 项目管理字典—PMBOK232
7.1.1 项目管理的131个工具232
7.1.2 项目管理的12个原则235
7.2 汽车行业如何践行软件敏捷240
7.2.1 敏捷必要性的两种理解240
7.2.2 敏捷内涵的多维度解读241
7.2.3 敏捷的一些良好实践245
7.3 风险分析之FMEA247
7.3.1 生活对FMEA的启发247
7.3.2 FMEA的新七步法248
7.4 软件进入汽车的门槛—功能安全255
7.4.1 功能安全大概是什么257
7.4.2 功能安全概念阶段259
7.4.3 功能安全产品开发之系统、硬件及软件264
7.4.4 整体功能安全管理266
7.5 自动驾驶的安全—预期功能安全268
7.5.1 由功能安全引出268
7.5.2 SOTIF基本逻辑270
7.5.3 SOTIF迭代模型272
7.5.4 SOTIF关键活动展开272
7.6 汽车软件的行业挑战—信息安全277
7.6.1 由功能安全引出278
7.6.2 TARA分析279
7.6.3 信息安全开发概述283
7.7 解决复杂软硬件问题的思路—8D284
7.7.1 关于8D的感触284
7.7.2 8D的8个步骤284
7.8 本章小结288
第8章 汽车软件开发工具链289
8.1 有关工具链的一些话题289
8.1.1 对工具自身意义的思考290
8.1.2 不同环节常用的工具类别290
8.1.3 如何理解工具链的“链”291
8.1.4 对使用者的两个指导原则292
8.2 数字化工具里的“项目”293
8.2.1 项目的一些基本特点293
8.2.2 走进工具的基本思路294
8.3 Office上线之需求管理295
8.3.1 需求管理的基本形式296
8.3.2 场景1：复制粘贴297
8.3.3 场景2：定义多重属性298
8.3.4 场景3：建立双向链接300
8.3.5 场景4：链接其他工作项301
8.3.6 场景5：建立配置与基线302
8.3.7 场景6：输出统计报告303
8.3.8 场景7：人与人的交互303
8.4 被驱动型的测试管理303
8.4.1 场景1：定义测试计划303
8.4.2 场景2：建立用例库304
8.4.3 场景3：测试报告的汇总304
8.5 协同合作之工作项管理305
8.5.1 场景1：变更管理305
8.5.2 场景2：bug管理306
8.5.3 场景3：需求管理307
8.6 计划总赶不上变化的项目计划307
8.6.1 汽车软件计划的3个特点307
8.6.2 场景1：自动更新309
8.6.3 场景2：层级视角的切换309
8.6.4 场景3：依赖关系直观展示309
8.6.5 场景4：交付物下探310
8.7 数据分析工具310
8.7.1 透视表311
8.7.2 可视化图311
8.8 本章小结311
第9章 转型软件的痛点与困惑312
9.1 互相低不下的头颅312
9.2 硬件交样与软件迭代的冲突313
9.2.1 硬件交样313
9.2.2 软件迭代313
9.3 对敏捷自身价值的质疑314
9.3.1 水土不太服的敏捷314
9.3.2 敏捷的现状约等于“乱”315
9.3.3 敏捷和标准化谁更先进315
9.3.4 敏捷应作为意识还是框架316
9.4 依旧太高的信息壁垒316
9.4.1 黑盒交付的后果316
9.4.2 互相制衡的文化317
9.5 ASPICE的爱与恨317
9.5.1 ASPICE很好318
9.5.2 ASPICE也很糟318
9.6 bug怎么这么多319
9.6.1 前期发现不了319
9.6.2 后期修复不完319
9.7 欲拒还迎的转型320
9.7.1 转向讲故事320
9.7.2 转向体验感320
9.8 本章小结321
第10章 展望未来汽车软件开发模式322
10.1 搭积木般造车322
10.2 推倒SOP的后墙323
10.3 实现本质安全324
10.4 再也不写文档325
10.5 可视化网状协同326
10.6 汽车行业大洗牌327
10.7 本章小结328
|
| 內容試閱：
|
Preface 前 言
为什么要写这本书
在汽车行业工作了十几年，我见证了行业的飞速发展，也一直在不断地转型，尝试了多个不同的岗位，涉及汽车产业链的各个领域。按理说，我这样一个汽车行业的持续探索者、践行者和观察者，应该能与行业同频同调，但我仍时常对行业变革之剧烈与迅猛感到惊讶。
所以，当本书策划编辑杨福川向我约稿时，我的第一反应是忐忑：行业变化如此剧烈，概念满天飞，争论此起彼伏，观点间歇性矛盾，有多少能为读者提供稳定价值的东西？
作为一个工程师，我秉持着务实与较真的态度，对行业内一系列概念进行了详细梳理，诸如软件定义汽车、SOA（面向服务的架构）、软硬件解耦、Scrum（敏捷开发）、SAFe（大规模敏捷框架）、CMMI（能力成熟度模型集成）、ASPICE（汽车软件过程改进及能力评定）、数字化、用户体验、场景化、智能座舱、无人驾驶、中央计算等。
不可否认的是，行业正在快速变化，但很多核心的东西并没有彻底改变，更多是在持续演进，所谓的“颠覆”不过是开始于某个时间点的媒体铺天盖地的宣传。比如：软硬件解
耦，早在20年前开始的AUTOSAR（汽车开放系统架构）就已经致力于此；ASPICE也是类似，汽车电子十几年来一直就是按照这个思路在开展相关工作；而敏捷（Scrum、SAFe等），到现在也没有形成行业普遍认可的最佳实践。
此外，本书更侧重于探讨汽车电子与软件行业的技术管理，而非具体的技术细节。因为后者的迭代速度更快，而前者的内涵更持久。
从技术管理的视角再往下看，我发现市面上只有一两本译著的小部分章节对这一主题有所涉及。同时，中国市场和国外市场的特点截然不同，我们自己的软件开发及造车的思路也与国外有很大差异，因此，我们需要知道如何在自己的文化背景下开发自己的软件、集成自己的产品及制造自己的汽车。
鉴于大量行业内外的人士正在向汽车电子与软件领域转型，行业亟须统一沟通语言和搭建转型框架。如果本书能够作为一座桥梁，站在汽车工业的肩膀上，面向软件定义的未来，取其精华，去其糟粕，融其先进，展现一个在汽车行业进行软件开发的全景式方法与管理体系，那么这也是我这个汽车人对汽车行业发展贡献的一点绵薄之力。
从上面总结的可行性、专业性、稀缺性和必要性几个角度看下来，我的忐忑情绪有所缓解，我对这个项目的热情越发高涨。
我偶尔喜欢写一些文章，但也因为如此，我深知利用业余时间写书很不容易，不仅需要将分散的知识点和经验串联起来，还需要查阅大量资料来建立整本书的体系架构，并填补知识空缺，这将是一项非常耗费时间和精力的工作。
此外，写书是一件公开的、严肃的事情，绝不仅仅是个人行为。尽管写起来十分辛苦，但这并不是对文字懈怠和对专业不负责任的理由。而且，汽车软件是一个知识密度极高而又迭代非常快的领域，专业的读者拥有各自精深的领域，让他们满意实非易事。
在这种无法消除的忐忑之下，经过深思熟虑，我决定在写书时践行以下3个原则：尊重自己、尊重读者、尊重工程。
尊重自己
虽然写书不是为了取悦自己，但言要由衷，尊重自己的感受，只有遂了自己的内心和达到自己的要求，才能最大限度地发挥自己的价值，这是我写作本书的首要原则。
回头来看，我大抵是尊重自己的，也是尊重自己所处的汽车行业的。
在整个写作过程中，我投入了十二分的精力，努力保持热情，克制松懈情绪，反刍了自己在汽车行业十几年间的所见所闻、所学所想，也查阅了超过全书文字百倍的资料，力求让每一句话、每一个知识点、每一个概念、每一张图都有理有据。
当然，写书时的毫不保留并不能保证书的最终品质，还要继续看下面两个原则。
尊重读者
毋庸置疑，书籍出版离不开商业范畴，读者就是“客户”。服务于客户是理所应当的，也是商业社会的基础规则。写书要满足“客户需求”，这也是汽车软件开发最基本的逻辑起点。
关于尊重读者原则，我总结了3个具体的方法论：
第一，从朴素的经验逐步推进到汽车软件、汽车产品、汽车流程、汽车术语及整车，尽量层层递进，深入浅出，避免堆砌专业词汇。
第二，保证内容完整且成体系，帮助非汽车电子与软件背景的从业者快速搭建一个体系，进而掌握基本知识、行业意识和入门思路。
第三，这一点算是普遍性需求，我尽量将文字写得流畅一些，交流感强一些，还增加了一些必要的故事案例和类比，让读者读起来轻松有趣，不至于晦涩难懂。
尊重工程
第三个原则是尊重工程，本来我想用“尊重逻辑”这个词，因为对于偏技术实战类的书来说，逻辑与系统是必不可少的。然而，从我写作和工作的经验来看，逻辑很美丽，但对于我们的实际工作还远远不够，逻辑自洽与实用有效完全是两回事。
所以，我将“逻辑”改为“工程”，工程来源于一线、真实和细节。在表达的过程中，注重梳理逻辑，但工程本身的逻辑是需要探索的，是阶段性的，很多时候它的逻辑并不清晰。这样说似乎有些矛盾，但我希望通过这个原则把控表达的分寸，不为了看起来正确而隐藏必要信息。
在写作
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
