完美軟件：缺陷預(yù)防最佳實踐

第Ⅰ部分 缺陷預(yù)防簡介
第1章 缺陷預(yù)防 3
1.1 什么是軟件缺陷 5
1.2 以高質(zhì)量軟件為目標 6
1.3 理解軟件缺陷的產(chǎn)生原因 7
1.4 可以做些什么 9
1.4.1 使用檢測、分析與預(yù)防技術(shù) 9
1.4.2 進行缺陷預(yù)防的組織有何不同 10
1.5 使用缺陷預(yù)防技術(shù) 11
1.5.1 缺陷檢測技術(shù) 11
1.5.2 缺陷分析技術(shù) 12
1.5.3 缺陷預(yù)防技術(shù) 12
1.6 選擇質(zhì)量提高技術(shù) 12
1.6.1 考慮的因素 13
1.6.2 選擇一種策略 14
1.7 組織考慮的因素 14
1.8 在上游階段提高質(zhì)量 15
1.9 從錯誤中學(xué)習(xí) 15
1.10 為未來投入 15
1.11 小結(jié) 16
第2章 缺陷預(yù)防框架 17
2.1 研究一種示例框架 19
2.2 提出模型 20
2.3 缺陷預(yù)防模型 20
2.3.1 能力成熟度模型 21
2.3.2 能力成熟度模型集成 26
2.3.3 Malcolm Baldrige框架 26
2.3.4 ISO模型 29
2.3.5 其他模型 30
2.3.6 對比這些模型 30
2.4 選擇和使用模型 30
2.5 小結(jié) 32
第3章 缺陷預(yù)防的經(jīng)濟學(xué) 34
3.1 預(yù)防缺陷對企業(yè)有好處 35
3.1.1 缺陷預(yù)防的經(jīng)濟理論與價值 36
3.1.2 盈利能力 37
3.2 對軟件開發(fā)進行邊際成本分析 38
3.2.1 估計成本 39
3.2.2 確定回報 45
3.3 小結(jié) 47
第Ⅱ部分 缺陷檢測技術(shù)
第4章 質(zhì)量與開發(fā)過程 51
4.1 什么是軟件質(zhì)量 52
4.1.1 開發(fā)方法與質(zhì)量 52
4.1.2 完全可測試性的神話 53
4.1.3 當前測試方法與質(zhì)量 54
4.1.4 不可能測試所有內(nèi)容 56
4.2 作為一種轉(zhuǎn)換過程的產(chǎn)品開發(fā) 57
4.2.1 向產(chǎn)品周期內(nèi)添加驗證步驟 58
4.2.2 承認原始說明書中的缺陷 61
4.2.3 將設(shè)計轉(zhuǎn)換為代碼 62
4.3 小結(jié) 72
第5章 利用生產(chǎn)效率游戲預(yù)防缺陷 73
5.1 什么是游戲理論 75
5.1.1 歷史上的游戲 76
5.1.2 游戲玩家時代 77
5.1.3 游戲為什么改變行為 79
5.2 游戲的類型 79
5.2.1 機會游戲和技能游戲 80
5.2.2 微型游戲 80
5.2.3 預(yù)測市場 81
5.2.4 交替現(xiàn)實游戲 82
5.3 缺陷預(yù)防游戲的實踐指導(dǎo) 82
5.3.1 從排名榜開始 82
5.3.2 保持簡單 82
5.3.3 仔細考慮記分方式 83
5.3.4 獎勵正確的行為 83
5.3.5 利用記分方式鼓勵參與 84
5.3.6 使玩家時常查看自己的分數(shù) 84
5.3.7 競賽內(nèi)容多樣 84
5.3.8 留出調(diào)整空間——設(shè)置一個時間段 85
5.3.9 通過分級來保持興趣 85
5.3.10 保留玩家的歷史 85
5.3.11 以小型實驗版本作為開始 85
5.3.12 讓人們按自己的步調(diào)進行 86
5.3.13 使用現(xiàn)金和獎品來提高興趣 86
5.3.14 使用隨機抽獎 86
5.4 應(yīng)用缺陷預(yù)防游戲的實例 86
5.5 游戲設(shè)計的提示 87
5.6 游戲設(shè)計的清單 88
5.7 小結(jié) 88
5.8 推薦閱讀資料 89
第6章 提高軟件的可測試性 90
6.1 認識可測試性的好處 91
6.2 實施可測試性 92
6.2.1 簡單性：開發(fā)不復(fù)雜的軟件 92
6.2.2 可觀察性：使軟件可觀察 95
6.2.3 控制：加強對被測試軟件的控制 97
6.2.4 知識：明白期待什么樣的結(jié)果 98
6.3 避免實施可測試性的風(fēng)險 100
6.4 小結(jié) 100
第Ⅲ部分 缺陷分析技術(shù)
第7章 軟件測量與量度 103
7.1 理解構(gòu)建一個成功記分卡的關(guān)鍵 104
7.2 明確確定戰(zhàn)略目標 106
7.2.1 確定客戶戰(zhàn)略 106
7.2.2 確定內(nèi)部業(yè)務(wù)戰(zhàn)略 107
7.2.3 確定財務(wù)戰(zhàn)略 108
7.2.4 定義創(chuàng)新戰(zhàn)略 108
7.3 明確定義業(yè)務(wù)、過程和改進目標 109
7.3.1 理解目標類型 109
7.3.2 確定目標 110
7.3.3 確定量度 110
7.3.4 劃定量度的優(yōu)先級 111
7.3.5 確定量度的權(quán)重 111
7.3.6 避免量度操縱 113
7.3.7 適當確定目標的范圍 114
7.3.8 劃定目標的優(yōu)先級 114
7.3.9 創(chuàng)建SMART目標 114
7.4 將所確定的目標通知各級管理人員 115
7.4.1 收集并顯示數(shù)據(jù) 115
7.4.2 自動收集和報告數(shù)據(jù) 117
7.4.3 回顧 118
7.5 使人們廣泛接受已確定的目標 118
7.6 小結(jié) 120
第8章 風(fēng)險分析 121
8.1 什么是風(fēng)險 122
8.2 什么是風(fēng)險分析 122
8.2.1 將風(fēng)險分析應(yīng)用于漂流 124
8.2.2 確定風(fēng)險分析階段 125
8.2.3 風(fēng)險分析的好處 127
8.2.4 理解風(fēng)險 128
8.2.5 實施風(fēng)險分析 129
8.3 創(chuàng)建風(fēng)險預(yù)測模型 129
8.3.1 特征：確定代碼特征 129
8.3.2 數(shù)量：跟蹤改動 133
8.3.3 影響：理解變更的結(jié)果 133
8.3.4 理由：理解為什么進行變更 137
8.3.5 所有權(quán)：知道一個改變歸誰擁有 138
8.4 應(yīng)用風(fēng)險預(yù)測模型 139
8.5 小結(jié) 142
第9章 利用仿真和建模進行組織改革 144
9.1 理解隨機建模 145
9.2 使用建模過程 153
9.2.1 定義目標 154
9.2.2 確定起始過程 154
9.2.3 確定過程的輸入和輸出 155
9.2.4 構(gòu)建所倡導(dǎo)的過程 156
9.2.5 將過程結(jié)果與組織結(jié)果進行對比 157
9.2.6 開發(fā)實際過程 157
9.2.7 根據(jù)需要進行重復(fù) 157
9.3 基線過程模型舉例 158
9.3.1 簡單規(guī)劃模型 158
9.3.2 經(jīng)過改進的計劃模型 161
9.3.3 詳盡的質(zhì)量模型 165
9.3.4 過程改進模型 170
9.3.5 開發(fā)生產(chǎn)能力模型 176
9.4 與CMM框架的關(guān)系 180
9.5 小結(jié) 181
第10章 缺陷分類法 182
10.1 從大型軟件項目中的缺陷進行學(xué)習(xí) 183
10.2 指定缺陷分類的目標 185
10.3 理解缺陷分類的組織原則 185
10.4 明確缺陷分類法中做出的假設(shè) 186
10.4.1 假設(shè)：我們只能進行特定類型的更改 187
10.4.2 假設(shè)：人們是會犯錯誤的 187
10.4.3 假設(shè)：缺陷在產(chǎn)品周期的后期被發(fā)現(xiàn) 187
10.4.4 假設(shè)：在產(chǎn)品周期中生成缺陷的階段未能檢查出這些缺陷 188
10.4.5 假設(shè)：測試可能是不平衡的 188
10.4.6 假設(shè)：您可能過度使用工具和過程 189
10.4.7 假設(shè)：您可能是在進行后期設(shè)計糾正 189
10.5 構(gòu)建缺陷分類法實例 189
10.5.1 發(fā)生階段 192
10.5.2 促成原因階段 196
10.5.3 改變階段 200
10.5.4 檢測階段 202
10.5.5 緩解階段 204
10.6 經(jīng)過分類的缺陷舉例 205
10.7 小結(jié) 208
第11章 根本原因分析 209
11.1 理解根本原因分析研究如何幫助預(yù)防缺陷 210
11.2 何時進行RCA研究 211
11.3 合理配置人員以成功完成研究 211
11.4 RCA研究的階段 212
11.4.1 階段一：事件確定 213
11.4.2 階段二：數(shù)據(jù)收集 216
11.4.3 階段三：數(shù)據(jù)分析與評估 218
11.4.4 階段四：糾正操作 222
11.4.5 執(zhí)行縱向分析 223
11.4.6 階段五：通知與應(yīng)用 224
11.4.7 階段六：遵循、測量和建議 225
11.5 根本原因分析的好處 227
11.6 根本原因分析的風(fēng)險 228
11.7 小結(jié) 229
第Ⅳ部分 缺陷預(yù)防技術(shù)
第12章 采用過程 233
12.1 理解傳統(tǒng)的開發(fā)過程 235
12.2 實施敏捷過程 236
12.2.1 需求管理 237
12.2.2 項目計劃 237
12.2.3 項目跟蹤與監(jiān)督 238
12.2.4 軟件質(zhì)量保證 239
12.2.5 軟件配置管理 240
12.3 Scrum 240
12.4 個體軟件過程 241
12.5 團隊軟件過程 244
12.6 鼓勵采用創(chuàng)新性的實踐方式 244
12.7 部署一體化過程 245
12.8 小結(jié) 246
第13章 FMEA、FTA與故障建模 248
13.1 故障模式和效果分析 249
13.2 實施FMEA 250
13.2.1 預(yù)備知識 250
13.2.2 程序 251
13.2.3 FMEA小結(jié) 262
13.3 故障樹分析 263
13.4 實施FTA 264
13.4.1 預(yù)備知識 265
13.4.2 程序 265
13.4.3 故障樹開發(fā)過程 269
13.4.4 故障樹小結(jié) 275
13.5 故障建模：結(jié)合FMEA和FTA 275
13.5.1 故障建模 276
13.5.2 對比威脅建模與故障建模 277
13.6 小結(jié) 277
第14章 預(yù)防標簽 279
14.1 預(yù)防標簽如何工作 282
14.2 在整個生產(chǎn)周期中使用預(yù)防標簽 284
14.2.1 編寫高質(zhì)量的預(yù)防標簽 284
14.2.2 誰可以推動預(yù)防技術(shù) 284
14.2.3 尋找“缺陷引入”行為的樣式 287
14.3 實施預(yù)防標簽計劃 287
14.3.1 確定目標 288
14.3.2 確定進度跟蹤和交流方法 288
14.3.3 確定存儲預(yù)防數(shù)據(jù)的位置 288
14.3.4 為預(yù)防相關(guān)工作提供激勵機制 288
14.3.5 確保有足夠的分析人員 289
14.3.6 定期報告并進行更改測量 289
14.4 對預(yù)防標簽數(shù)據(jù)采取行動 289
14.4.1 對預(yù)防技術(shù)進行分類 290
14.4.2 深入分析 292
14.5 使用預(yù)防標簽的好處 292
14.5.1 幫助個人轉(zhuǎn)向全局考慮 293
14.5.2 預(yù)防技術(shù)和知識易于共享 293
14.5.3 預(yù)防數(shù)據(jù)與發(fā)現(xiàn)和修復(fù)數(shù)據(jù)存儲在一起 293
14.5.4 提供用于過程改進的反饋機制 293
14.5.5 簡化數(shù)據(jù)收集 293
14.5.6 可用于所有階段 294
14.6 使用預(yù)防標簽的風(fēng)險 294
14.6.1 變?yōu)橐粋€指責(zé)平臺 294
14.6.2 面對有偏差的數(shù)據(jù) 294
14.6.3 容易過分重視或反應(yīng)過度 294
14.6.4 需要編譯與分析 295
14.6.5 預(yù)防方法可能過于籠統(tǒng)或者過于具體 295
14.7 小結(jié) 295
第Ⅴ部分 預(yù)防文化
第15章 方案投票 299
15.1 應(yīng)用大數(shù)定律 300
15.2 利用方案投票來幫助預(yù)防缺陷 301
15.3 理解方案投票流程 303
15.3.1 創(chuàng)建功能說明文件 304
15.3.2 編寫高質(zhì)量的方案 305
15.3.3 對方案進行分類 305
15.3.4 了解投票人員都是哪些人 306
15.4 實施方案投票計劃 307
15.4.1 了解適當?shù)捻椖侩A段 307
15.4.2 了解產(chǎn)品 308
15.4.3 開發(fā)體驗樹 308
15.4.4 為反饋設(shè)定明確目標 309
15.4.5 為方案建立文檔以及制訂方案 309
15.4.6 征集用戶制訂的方案 311
15.4.7 理解用戶群 312
15.4.8 獲取反饋 313
15.4.9 啟動引導(dǎo)項目 314
15.4.10 部署投票項目 315
15.4.11 保持項目的活力 316
15.4.12 報告結(jié)果 316
15.4.13 分析結(jié)果 317
15.4.14 鼓勵投票者持續(xù)參與 318
15.4.15 將結(jié)果提交給支持團隊 319
15.4.16 采取行動 321
15.5 方案投票的好處 323
15.5.1 簡化數(shù)據(jù)收集 323
15.5.2 能夠收集涉及大范圍功能和用戶的大量數(shù)據(jù) 323
15.5.3 適用于項目周期的所有階段 324
15.6 方案投票的風(fēng)險 325
15.6.1 投票結(jié)果受投票人群構(gòu)成的影響 325
15.6.2 投票結(jié)果僅提供了用戶意見的概要信息 325
15.6.3 不完整的方案選擇可能會使結(jié)果產(chǎn)生偏差 326
15.6.4 設(shè)計不佳的方案可能會使結(jié)果產(chǎn)生偏差 326
15.7 小結(jié) 327
15.8 推薦閱讀資料 327
第16章 創(chuàng)建一種質(zhì)量文化 328
16.1 評價您的現(xiàn)有文化 329
16.1.1 常見的文化缺陷 330
16.1.2 用于檢測設(shè)計不當?shù)牧慷?332
16.2 改進您的文化 333
16.3 小結(jié) 338
第17章 在上游階段提高質(zhì)量 339
17.1 質(zhì)量與客戶導(dǎo)向是相互聯(lián)系的 340
17.2 將開發(fā)過程理解為一系列轉(zhuǎn)換 341
17.3 避免阻礙上游質(zhì)量的提高 344
17.3.1 測試不會提高質(zhì)量 344
17.3.2 質(zhì)量是不可見的 344
17.3.3 重功能，輕質(zhì)量 345
17.3.4 工程態(tài)度妨礙了注重質(zhì)量的文化 346
17.3.5 任務(wù)和團隊的短視妨礙了全局觀 346
17.3.6 團隊回避適當行為 347
17.3.7 價值和獎勵沒有促進質(zhì)量的提高 348
17.4 缺陷具有不同風(fēng)險 349
17.5 查明下游質(zhì)量不佳的原因 350
17.6 未來產(chǎn)品開發(fā)的模型 351
17.6.1 開發(fā)工作以客戶為導(dǎo)向 352
17.6.2 產(chǎn)品信息是可執(zhí)行的 354
17.6.3 客戶方案被移向上游 355
17.6.4 測試過程和測試生成被自動化 355
17.6.5 靜態(tài)測試普遍深入 356
17.6.6 開發(fā)過程被修改 357
17.6.7 在組織、角色和職業(yè)生涯中所導(dǎo)致的變化 358
17.7 小結(jié) 359
第18章 回報、動機和激勵 360
18.1 應(yīng)用激勵技巧 361
18.1.1 消除“抑制激勵”的因素 362
18.1.2 為缺陷預(yù)防工作設(shè)立SMART目標 362
18.1.3 衡量在缺陷預(yù)防工作上花費的時間和精力 363
18.1.4 確保領(lǐng)導(dǎo)者行為體現(xiàn)了對缺陷預(yù)防工作的重視 363
18.1.5 創(chuàng)造缺陷預(yù)防的文化 363
18.1.6 使組織目標與缺陷預(yù)防工作保持一致 364
18.1.7 在設(shè)計組織進程時，要考慮到缺陷預(yù)防 364
18.1.8 建立獎勵機制，鼓勵員工發(fā)表不同觀點 365
18.2 激勵——不只是金錢獎勵 365
18.2.1 慶祝成功 366
18.2.2 使用游戲和競賽 366
18.3 理解個人的動機 366
18.4 明白什么是成功 368
18.5 衡量成功 368
18.6 小結(jié) 369
第19章 知識管理與交流 370
19.1 交流不暢所產(chǎn)生的問題 371
19.1.1 孤立知識 372
19.1.2 知識傳播不足 372
19.1.3 不能找出最佳實踐 373
19.1.4 缺乏向上交流 373
19.2 交流方法 373
19.3 利用規(guī)模優(yōu)勢 374
19.3.1 優(yōu)秀交流模型的特性 374
19.3.2 分類法 375
19.3.3 有機的專家系統(tǒng) 375
19.3.4 預(yù)防標簽 377
19.3.5 方案投票 378
19.4 小結(jié) 378
第20章 融為一體 379
20.1 了解標準與約定 380
20.1.1 火車、汽車和PF 381
20.1.2 公共結(jié)果標準 382
20.2 各司其職 383
20.2.1 質(zhì)量保證 383
20.2.2 代碼開發(fā) 388
20.2.3 項目管理 394
20.3 小結(jié) 397