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