4.3
用户推荐指数
自我提升 类型
可以朗读 语音朗读
260千字 字数
2024-04-01 发行日期
展开全部

主编推荐语

一本从技术与管理角度全景式介绍智能汽车电子与软件的著作。

内容简介

本书涵盖行业背景、组织架构、项目管理、开发方法、系统集成、流程体系、人员搭建、核心标准、开发工具链、痛点及展望等核心内容。本书是作者在博世等头部Tier 1与OEM企业10余年技术与管理经验总结，得到了来自华为、腾讯、广汽、长城、极氪、蔚来、小鹏等20余家车企和机构的25位专家高度评价和推荐。

目录

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

评分及书评

4.3
3个评分
  • 用户头像
    给这本书评了
    4.0
    汽车软件开发

    汽车的未来在于软件，也在于硬件，重要的是两者需要融合，才能实现超过顾客预期的产品。很多人来自于互联网，房地产，为传统汽车行业带来了天量的资本，也带来了新思维和新方法，当然也有失败的教训。这种软件与硬件的差异，传统汽车与新兴势力之间的思维上的矛盾冲突在软件开发过程中很明显，考验决策者和管理者如何在敏捷、成本、质量中平衡好风险和收益。

      转发
      评论

    出版方

    机械工业出版社

    机械工业出版社是全国优秀出版社，自1952年成立以来，坚持为科技、为教育服务，以向行业、向学校提供优质、权威的精神产品为宗旨，以“服务社会和人民群众需求，传播社会主义先进文化”为己任，产业结构不断完善，已由传统的图书出版向着图书、期刊、电子出版物、音像制品、电子商务一体化延伸，现已发展为多领域、多学科的大型综合性出版社，涉及机械、电工电子、汽车、计算机、经济管理、建筑、ELT、科普以及教材、教辅等领域。