智慧汽車電子與軟體：開發方法、系統整合、流程系統與專案管理

目　　錄　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