目 錄
第一部分 搜尋和使用證據的一般原則
第1章 探尋有力的證據 2
1.1 起步階段 2
1.2 當今證據的狀態 3
1.2.1 精確性研究的挑戰 3
1.2.2 統計強度的挑戰 3
1.2.3 結果可復製性的挑戰 4
1.3 我們可以相信的改變 5
1.4 背景的影響 7
1.5 展望未來 7
1.6 參考文獻 9
第2章 可信度,為什麼我堅決要求確信的證據 12
2.1 軟件工程中的證據是如何發現的 12
2.2 可信度和適用性 13
2.2.1 適用性,為什麼使你信服的證據不能使我信服 14
2.2.2 定性證據對戰定量證據:錯誤的二分法 15
2.3 整閤證據 16
2.4 證據的類型以及它們的優缺點 17
2.4.1 對照實驗和準實驗 18
2.4.2 問捲調查 19
2.4.3 經驗匯報和案例研究 20
2.4.4 其他方法 20
2.4.5 報告中的可信度(或缺乏可信度)的標識 21
2.5 社會、文化、軟件工程和你 23
2.6 緻謝 24
2.7 參考文獻 24
第3章 我們能從係統性評審中學到什麼 25
3.1 係統性評審總覽 26
3.2 係統性評審的長處和短處 27
3.2.1 係統性評審的流程 28
3.2.2 開展一項評審所牽連的問題 30
3.3 軟件工程中的係統性評審 31
3.3.1 成本估算研究 32
3.3.2 敏捷方法 33
3.3.3 檢驗方法 35
3.4 結論 35
3.5 參考文獻 36
第4章 用定性研究方法來理解軟件工程學 40
4.1 何為定性研究方法 41
4.2 如何解讀定性研究 42
4.3 在工作中運用定性研究方法 44
4.4 推廣應用定性研究的結果 45
4.5 定性研究方法是係統的研究方法 46
4.6 參考文獻 46
第5章 在實踐中學習成長:軟件工程實驗室中的質量改進範式 47
5.1 軟件工程研究獨有的睏難之處 47
5.2 實證研究的現實之路 48
5.3 NASA軟件工程實驗室:一個充滿活力的實證研究測試平颱 48
5.4 質量改進範式 49
5.4.1 錶徵 51
5.4.2 設立目標 51
5.4.3 選擇流程 51
5.4.4 執行流程 53
5.4.5 分析 53
5.4.6 封裝 53
5.5 結論 55
5.6 參考文獻 55
第6章 性格、智力和專業技能對軟件開發的影響 57
6.1 如何辨彆優秀的程序員 58
6.1.1 個體差異:固定的還是可塑造的 58
6.1.2 個性 59
6.1.3 智力 63
6.1.4 編程任務 65
6.1.5 編程錶現 65
6.1.6 專業技能 66
6.1.7 軟件工作量估算 68
6.2 環境因素還是個人因素 68
6.2.1 軟件工程中應該提高技能還是提高安全保障 69
6.2.2 閤作 69
6.2.3 再談個性 72
6.2.4 從更廣的角度看待智力 72
6.3 結束語 74
6.4 參考文獻 75
第7章 為什麼學編程這麼難 81
7.1 學生學習編程有睏難嗎 82
7.1.1 2001年McCracken工作小組 82
7.1.2 Lister工作小組 83
7.2 人們對編程的本能理解是什麼 83
7.3 通過可視化編程來優化工具 85
7.4 融入語境後的改變 86
7.5 總結:一個新興的領域 88
7.6 參考文獻 89
第8章 超越代碼行:我們還需要其他的復雜度指標嗎 92
8.1 對軟件的調查 92
8.2 計算源代碼的指標 93
8.3 指標計算案例 94
8.3.1 源代碼行數(SLOC) 96
8.3.2 代碼行數(LOC) 96
8.3.3 C函數的數量 96
8.3.4 McCabe圈復雜度 96
8.3.5 Halstead軟件科學指標 97
8.4 統計分析 98
8.4.1 總體分析 98
8.4.2 頭文件和非頭文件之間的區彆 99
8.4.3 乾擾效應:文件大小對相關性的影響 100
8.5 關於統計學方法的一些說明 103
8.6 還需要其他的復雜度指標嗎 103
8.7 參考文獻 104
第二部分 軟件工程的特有話題
第9章 自動故障預報係統實例一則 106
9.1 故障的分布 106
9.2 故障高發文件的特徵 109
9.3 預測模型概覽 109
9.4 預測模型的復驗和變體 110
9.4.1 開發人員的角色 111
9.4.2 用其他類型的模型來預測故障 113
9.5 工具的設計 115
9.6 一些忠告 115
9.7 參考文獻 117
第10章 架構設計的程度和時機 119
10.1 修正缺陷的成本是否會隨著項目的進行而增加 119
10.2 架構設計應該做到什麼程度 120
10.3 架構設計的成本—修復數據給予我們的啓示 123
10.3.1 關於COCOMO II架構設計和風險解決係數的基礎知識 123
10.3.2 Ada COCOMO及COCOMO II中的架構設計以及風險應對係數 125
10.3.3 用於改善係統設計的投入的ROI 130
10.4 那麼到底架構要做到什麼程度纔夠 132
10.5 架構設計是否必須提前做好 135
10.6 總結 135
10.7 參考文獻 136
第11章 康威推論 138
11.1 康威定律 138
11.2 協調工作、和諧度和效率 140
11.3 微軟公司的組織復雜度 143
11.4 開源軟件集市上的小教堂 148
11.5 總結 152
11.6 參考文獻 152
第12章 測試驅動開發的效果如何 153
12.1 TDD藥丸是什麼 153
12.2 TDD臨床試驗概要 154
12.3 TDD的效力 156
12.3.1 內部質量 156
12.3.2 外部質量 157
12.3.3 生産力 157
12.3.4 測試質量 158
12.4 在試驗中強製TDD的正確劑量 158
12.5 警告和副作用 159
12.6 結論 160
12.7 緻謝 160
12.8 參考文獻 160
第13章 為何計算機科學領域的女性不多 163
13.1 為什麼女性很少 163
13.1.1 能力缺陷,個人喜好以及文化偏見 164
13.1.2 偏見、成見和男性計算機科學文化 166
13.2 值得在意嗎 168
13.2.1 扭轉這種趨勢,我們可以做些什麼 170
13.2.2 跨國數據的意義 171
13.3 結論 172
13.4 參考文獻 172
第14章 兩個關於編程語言的比較 175
14.1 一個搜索算法決定瞭一種語言的勝齣 175
14.1.1 編程任務:電話編碼 176
14.1.2 比較執行速度 176
14.1.3 內存使用情況的比較 178
14.1.4 比較效率和代碼長度 178
14.1.5 比較可靠性 180
14.1.6 比較程序結構 180
14.1.7 我可以相信嗎 181
14.2 Plat_Forms:網絡開發技術和文化 182
14.2.1 開發任務:人以類聚 182
14.2.2 下注吧 183
14.2.3 比較工作效率 184
14.2.4 比較軟件工件的大小 185
14.2.5 比較可修改性 186
14.2.6 比較穩健性和安全性 187
14.2.7 嘿,“插入你自己的話題”如何 189
14.3 那又怎樣 189
14.4 參考文獻 189
第15章 質量之戰:開源軟件對戰專有軟件 191
15.1 以往的衝突 192
15.2 戰場 192
15.3 開戰 195
15.3.1 文件組織 196
15.3.2 代碼結構 200
15.3.3 代碼風格 204
15.3.4 預處理 209
15.3.5 數據組織 211
15.4 成果和結論 213
15.5 緻謝 215
15.6 參考文獻 215
第16章 碼語者 219
16.1 程序員的一天 219
16.1.1 日記研究 220
16.1.2 觀察研究 220
16.1.3 程序員們是不是在掙錶現 220
16.2 說這麼多有什麼意義 221
16.2.1 問問題 221
16.2.2 探尋設計理念 223
16.2.3 工作的中斷和多任務 223
16.2.4 程序員都在問什麼問題 224
16.2.5 使用敏捷方法是不是更利於溝通 227
16.3 如何看待溝通 228
16.4 參考文獻 229
第17章 結對編程 230
17.1 結對編程的曆史 230
17.2 産業環境中的結對編程 232
17.2.1 結對編程的行業實踐 232
17.2.2 業內使用結對編程的效果 233
17.3 教育環境中的結對編程 234
17.3.1 教學中特有的實踐 234
17.3.2 教學中使用結對編程的效果 235
17.4 分布式結對編程 235
17.5 麵對的挑戰 236
17.6 經驗教訓 237
17.7 緻謝 237
17.8 參考文獻 237
第18章 現代化代碼審查 243
18.1 常識 243
18.2 程序員獨立進行小量代碼審查 243
18.2.1 防止注意力疲勞 244
18.2.2 切忌速度過快 244
18.2.3 切忌數量過大 245
18.2.4 上下文的重要性 246
18.3 團隊影響 247
18.3.1 是否有必要開會 247
18.3.2 虛假缺陷 247
18.3.3 外部審查真的需要嗎 248
18.4 結論 249
18.5 參考文獻 249
第19章 公共辦公室還是私人辦公室 251
19.1 私人辦公室 251
19.2 公共辦公室 253
19.3 工作模式 255
19.4 最後的忠告 257
19.5 參考文獻 257
第20章 識彆及管理全球性軟件開發中的依賴關係 258
20.1 為什麼協調工作對於GSD來說是挑戰 258
20.2 依賴關係及其社會/技術二重性 259
20.2.1 技術方麵 261
20.2.2 社會/組織結構方麵 263
20.2.3 社會—技術方麵 266
20.3 從研究到實踐 267
20.3.1 充分使用軟件儲存庫中的數據 267
20.3.2 團隊領導和管理者在依賴關係管理中的角色 268
20.3.3 開發人員、工作項目和分布式開發 269
20.4 未來的方嚮 269
20.4.1 適閤GSD的軟件架構 269
20.4.2 協作軟件工程工具 270
20.4.3 標準化和靈活度的平衡 271
20.5 參考文獻 271
第21章 模塊化的效果如何 274
21.1 所分析的軟件係統 275
21.2 如何定義“修改” 276
21.3 如何定義“模塊” 280
21.4 研究結果 281
21.4.1 修改的範圍 281
21.4.2 需要參考的模塊 283
21.4.3 自發式的模塊化 284
21.5 有效性的問題 286
21.6 總結 287
21.7 參考文獻 287
第22章 設計模式的證據 289
22.1 設計模式的例子 290
22.2 為什麼認為設計模式可行 292
22.3 第一個實驗:關於設計模式文檔的測試 293
22.3.1 實驗的設計 293
22.3.2 研究結果 295
22.4 第二個實驗:基於設計模式的解決方案和簡單解決方案的對比 297
22.5 第三個試驗:設計模式之於團隊溝通 300
22.6 經驗教訓 302
22.7 總結 304
22.8 緻謝 304
22.9 參考文獻 305
第23章 循證故障預測 306
23.1 簡介 306
23.2 代碼覆蓋率 308
23.3 代碼變動 308
23.4 代碼復雜度 311
23.5 代碼依賴 312
23.6 人與組織度量 312
23.7 預測缺陷的綜閤方法 315
23.8 結論 317
23.9 緻謝 319
23.10 參考文獻 319
第24章 采集缺陷報告的藝術 322
24.1 缺陷報告的優劣之分 322
24.2 優秀缺陷報告需要具備的要素 323
24.3 調查結果 325
24.3.1 開發人員眼中的缺陷報告內容 325
24.3.2 報告者眼中的缺陷報告內容 326
24.4 來自不一緻信息的證據 327
24.5 缺陷報告的問題 329
24.6 重復缺陷報告的價值 330
24.7 並非所有的缺陷都被修復瞭 332
24.8 結論 333
24.9 緻謝 334
24.10 參考文獻 334
第25章 軟件的缺陷都從哪兒來 335
25.1 研究軟件的缺陷 335
25.2 本次研究的環境和背景 336
25.3 第一階段:總體調查 337
25.3.1 調查問捲 337
25.3.2 數據的總結 339
25.3.3 第一部分的研究總結 342
25.4 第二階段:設計/代碼編寫類故障調查 342
25.4.1 調查問捲 342
25.4.2 統計分析 345
25.4.3 界麵故障與實現故障 358
25.5 研究結果可靠嗎 360
25.5.1 我們調查的對象是否正確 360
25.5.2 我們的方法是否正確361
25.5.3 我們能用這些結果做什麼 362
25.6 我們明白瞭什麼 362
25.7 緻謝 364
25.8 參考文獻 364
第26章 新手專傢:軟件行業的應屆畢業生們 367
26.1 研究方法 368
26.1.1 研究對象 369
26.1.2 任務分析 370
26.1.3 任務案例 370
26.1.4 做迴顧的方法 371
26.1.5 有效性問題 371
26.2 軟件開發任務 372
26.3 新手開發人員的優點和缺點 374
26.3.1 優點分析 375
26.3.2 缺點分析 375
26.4 迴顧 376
26.4.1 管理層的介入 377
26.4.2 毅力、疑惑和新人特質 377
26.4.3 大型的軟件團隊環境 378
26.5 妨礙學習的誤解 378
26.6 教育方法的反思 379
26.6.1 結對編程 380
26.6.2 閤理的邊際參與 380
26.6.3 導師製 380
26.7 改變的意義 381
26.7.1 新人培訓 381
26.7.2 學校教育 382
26.8 參考文獻 383
第27章 挖掘你自己的證據 385
27.1 對什麼進行數據挖掘 385
27.2 設計你的研究 386
27.3 數據挖掘入門 387
27.3.1 第一步:確定要用哪些數據 387
27.3.2 第二步:獲取數據 388
27.3.3 第三步:數據轉換(可選) 389
27.3.4 第四步:提取數據 389
27.3.5 第五步:解析bug報告 390
27.3.6 第六步:關聯數據 390
27.3.7 第六步:找齣漏掉的關聯 391
27.3.8 第七步:將bug對應到文件 391
27.4 下麵怎麼辦 392
27.5 緻謝 394
27.6 參考文獻 394
第28章 正當使用“復製—粘貼”大法 396
28.1 代碼剋隆的示例 396
28.2 尋找軟件中的剋隆代碼 398
28.3 對代碼剋隆行為的調查 399
28.3.1 分叉 400
28.3.2 模闆 401
28.3.3 定製 402
28.4 我們的研究 403
28.5 總結 405
28.6 參考文獻 406
第29章 你的API有多好用 407
29.1 為什麼研究API的易用性很重要 407
29.2 研究API易用性的首次嘗試 409
29.2.1 研究的設計 410
29.2.2 第一次研究的結論摘要 411
29.3 如果一開始你沒有成功 412
29.3.1 第二次研究的設計 412
29.3.2 第二次研究的結論摘要 412
29.3.3 認知維度 414
29.4 使用不同的工作風格 418
29.5 結論 421
29.6 參考文獻 422
第30章 “10倍”意味著什麼?編程生産力的差距測量 423
30.1 軟件開發中的個人效率的變化 423
30.1.1 巨大的差距帶來的負麵影響 424
30.1.2 什麼造就瞭真正的“10倍程序員” 424
30.2 測量程序員的個人生産力的問題 424
30.2.1 生産力=每月産齣的代碼行數嗎 424
30.2.2 生産力=功能點嗎 425
30.2.3 復雜度呢 425
30.2.4 到底有沒有辦法可以測量個人生産力 425
30.3 軟件開發中的團隊生産力差距 426
30.4 參考文獻 427
撰稿人 429
· · · · · · (
收起)