幫助中心 | 我的帳號 | 關於我們

智能汽車電子與軟體(開發方法系統集成流程體系與項目管理)

  • 作者:楊修文|責編:楊福川
  • 出版社:機械工業
  • ISBN:9787111751168
  • 出版日期:2024/04/01
  • 裝幀:平裝
  • 頁數:328
人民幣:RMB 109 元      售價:
放入購物車
加入收藏夾

內容大鋼
    這是一本從技術與管理角度全景式介紹智能汽車電子與軟體的著作,涵蓋行業背景、組織架構、項目管理、開發方法、系統集成、流程體系、人員搭建、核心標準、開發工具鏈、痛點及展望等核心內容。本書是作者在博世等頭部Tier 1與OEM企業10余年技術與管理經驗總結,得到了來自華為、騰訊、廣汽、長城、極氪、蔚來、小鵬等20余家車企和機構的25位專家高度評價和推薦。
    第1章從行業發展的里程碑、技術演變、行業格局、安全問題、量產落地、傳統汽車與互聯網的融合等角度闡釋了汽車行業的特點,有助於讀者理解軟體在汽車行業落地與深化時碰到的一些現象或問題。
    第2章從Tier 1與OEM的組織模式特點及軟體所處位置開始,引出組織變化與融合的趨勢,並以軟體質量為例提出了軟體體系進入汽車企業的路徑,為讀者提供參考思路。
    第3章從汽車軟體全生命周期和交付的角度對開發的主幹進行梳理,摘取質量門、bug管理、變更管理、文檔管理、配置管理、風險管理、成本估算等重要主題,進行了不同角度和相互貫通的闡述。
    第4章基於軟硬體一體的ECU產品視角,從產品開發的角度,梳理了汽車軟體開發及產品系統集成的主體脈絡,具體從需求、架構、集成、測試以及整體的追溯關係上進行了展開敘述,以期搭建一個具備一定普適性的汽車軟體開發的工程框架。
    第5章側重體系框架的梳理,依次對ISO 9000、IATF16949、ASPICE等標準進行了詳細解讀,讓讀者能夠對普適性體系標準在汽車軟體領域的落實情況有所了解。
    第6章從一個典型的軟體組織角色定義說起,依次梳理了組織、項目、流程3條角色線的相關內容,以便讀者快速理解對應組織的人員組成及其與自身的映射關係。
    第7章重點介紹方法論與開發標準,包括項目管理、敏捷實踐、FMEA(失效模式及影響分析)、三大安全、8D等主題,從不同的維度引出了一些實際工作中經常遇到的問題。
    第8章從汽車軟體開發工具鏈應用場景的角度進行了梳理。考慮到專業軟體開發屬於更細分的領域,而且與汽車行業本身的關聯性不大,所以該章整體側重介紹開發管理類工具。
    第9章總結了整個轉型過程中始終面臨的一些具體問題,包括從業者心態難以調整、軟硬體差異、敏捷無法奏效、信息壁壘高築、ASPICE繁重、轉型遲緩等。
    第10章通過一個輕鬆簡短的幻想場景來為全書收尾,不追求可操作性,但希望能夠引發讀者的一些思考。這也是對全書主題的升華和總結,希望能對廣大讀者有所啟示。

作者介紹
楊修文|責編:楊福川
    楊修文,資深汽車軟體研發管理專家,現就職于某頭部OEM,致力於智能汽車軟體開發體系搭建、轉型及改善等方向的研究與實踐。擁有10余年世界100強汽車Tier 1和OEM技術與管理實戰經歷,曾在奧托立夫、博世等企業負責整車系統集成、電子系統架構開發、功能安全管理、軟體項目管理、軟體質量管理等工作,積累了汽車電子與軟體頭部企業的全流程經驗。曾負責20+項目交付,與業內主流車企都有過密切的工作交互,對中國汽車行業現狀有深刻理解,在軟體研發管理領域內有著廣泛的影響力。

目錄
讚譽
前言
第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
    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  汽車軟體開發基礎模型V模型
    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  製造業體系基礎——ISO
    5.1.1  ISO 9000有什麼用
    5.1.2  5個基本概念
    5.1.3  質量管理7個原則
  5.2  汽車行業體系基礎——IATF
    5.2.1  總體概述
    5.2.2  整體策劃
    5.2.3  相關支持
    5.2.4  體系運行
    5.2.5  績效評
    5.2.6  持續改進
  5.3  汽車軟體過程基礎——ASPICE
    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
    5.4.2  IATF
    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  項目管理字典——PMBOK
    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  解決複雜軟硬體問題的思路——8D
    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  本章小結

  • 商品搜索:
  • | 高級搜索
首頁新手上路客服中心關於我們聯絡我們Top↑
Copyrightc 1999~2008 美商天龍國際圖書股份有限公司 臺灣分公司. All rights reserved.
營業地址:臺北市中正區重慶南路一段103號1F 105號1F-2F
讀者服務部電話:02-2381-2033 02-2381-1863 時間:週一-週五 10:00-17:00
 服務信箱:bookuu@69book.com 客戶、意見信箱:cs@69book.com
ICP證:浙B2-20060032