統一軟件開發(fā)過程

第一部分   統一軟件開發(fā)過程
第1章   統一過程的特點：用況驅動. 以構架
為中心. 迭代和增量的 3
1.1   統一過程概述 3
1.2   統一過程是用況驅動的 4
1.3   統一過程是以構架為中心的 5
1.4   統一過程是迭代和增量的過程 6
1.5   統一過程的生命周期 7
1.5.1   產品 8
1.5.2   一次循環(huán)所包含的階段 9
1.6   一個綜合的過程 11
第2章   軟件開發(fā)的四個要素：人員. 項目. 
產品和過程 12
2.1   人員至關重要 12
2.1.1   開發(fā)過程影響人員 13
2.1.2   角色會發(fā)生變化 13
2.1.3   將“資源”轉化為“工作人員” 14
2.2   項目創(chuàng)造產品 15
2.3   產品不僅僅是代碼 16
2.3.1   什么是軟件系統？ 16
2.3.2   制品 16
2.3.3   系統包含一組模型 17
2.3.4   什么是模型？ 18
2.3.5   每個模型是系統自包含的視圖 18
2.3.6   模型的內部 18
2.3.7   模型間的關系 19
2.4   過程指導項目 19
2.4.1   過程：一個模板 19
2.4.2   相關活動組成工作流 20
2.4.3   過程具體化 21
2.4.4   過程的價值 22
2.5   工具對于過程不可或缺 22
2.5.1   工具對過程的影響 22
2.5.2   過程驅動工具 23
2.5.3   平衡過程和工具 23
2.5.4   支持UML的可視化建模 24
2.5.5   支持整個生命周期的工具 24
2.6   參考資料 25
第3章   用況驅動過程 26
3.1   用況驅動開發(fā)概述 27
3.2   為什么使用用況？ 29
3.2.1   為了捕獲附加在需求上的價值 29
3.2.2   為了驅動過程 30
3.2.3   為了設計構架以及其他 30
3.3   捕獲用況 31
3.3.1   用況模型表示功能性需求 31
3.3.2   參與者是系統的環(huán)境 31
3.3.3   用況確定系統 32
3.4   實現用況的分析. 設計和實現 32
3.4.1   根據用況建立分析模型 33
3.4.2   每個類必須履行其所有的協作角色 36
3.4.3   根據分析模型建立設計模型 36
3.4.4   按子系統對類分組 39
3.4.5   根據設計模型建立實現模型 40
3.5   用況的測試 42
3.6   小結 43
3.7   參考資料 43
第4章   以構架為中心的過程 45
4.1   構架概述 46
4.2   為什么需要構架？ 47
4.2.1   理解系統 47
4.2.2   組織開發(fā) 48
4.2.3   鼓勵重用 48
4.2.4   進化系統 49
4.3   用況和構架 49
4.4   建立構架的步驟 52
4.4.1   構架基線是一個“小的. 皮包骨架的”
系統 52
4.4.2   使用構架模式 54
4.4.3   描述構架 56
4.4.4   構架設計師創(chuàng)建構架 58
4.5   最后是構架描述！ 58
4.5.1   用況模型的構架視圖 59
4.5.2   設計模型的構架視圖 59
4.5.3   實施模型的構架視圖 61
4.5.4   實現模型的構架視圖 62
4.6   三個應關注的概念 62
4.6.1   什么是構架？ 62
4.6.2   如何獲得構架？ 63
4.6.3   如何描述構架？ 63
4.7   參考資料 63
第5章   迭代和增量過程 64
5.1   迭代和增量概述 65
5.1.1   以細小的步驟開發(fā) 65
5.1.2   迭代不是什么 66
5.2   為什么采用迭代和增量的開發(fā)方法？ 66
5.2.1   降低風險 67
5.2.2   獲得一個健壯的構架 68
5.2.3   處理不斷變化的需求 68
5.2.4   允許靈活改變 69
5.2.5   實現持續(xù)的集成 69
5.2.6   盡早得到有關知識 70
5.3   迭代方法是風險驅動的 71
5.3.1   迭代降低了技術風險 72
5.3.2   管理對非技術性風險負責 73
5.3.3   處理風險 73
5.4   通用迭代過程 74
5.4.1   迭代是什么 74
5.4.2   規(guī)劃迭代過程 75
5.4.3   確定迭代次序 75
5.5   一次迭代產生一個增量結果 76
5.6   在整個生命周期上的迭代 77
5.7   由迭代過程來進化模型 79
5.8   迭代對開發(fā)組織具有挑戰(zhàn)性 80
5.9   參考資料 80
第二部分   核心工作流
第6章   捕獲需求：從構想到需求 85
6.1   為什么捕獲需求很困難 85
6.2   需求工作流的目的 86
6.3   需求捕獲概述 86
6.4   需求在軟件生命周期中的作用 90
6.5   運用領域模型來理解系統的語境 91
6.5.1   什么是領域模型？ 91
6.5.2   建立領域模型 92
6.5.3   領域模型的使用 92
6.6   使用業(yè)務模型來理解系統的語境 93
6.6.1   什么是業(yè)務模型？ 93
6.6.2   如何建立業(yè)務模型 95
6.6.3   根據業(yè)務模型確定用況 96
6.7   補充需求 97
6.8   小結 98
6.9   參考資料 98
第7章   捕獲需求作為用況 100
7.1   引言 100
7.2   制品 101
7.2.1   制品：用況模型 101
7.2.2   制品：參與者 102
7.2.3   用況 103
7.2.4   制品：構架描述（用況模型視圖） 105
7.2.5   制品：術語表 106
7.2.6   制品：用戶界面原型 106
7.3   工作人員 106
7.3.1   工作人員：系統分析人員 106
7.3.2   工作人員：用況描述人員 107
7.3.3   工作人員：用戶界面設計人員 108
7.3.4   工作人員：構架設計師 108
7.4   工作流 108
7.4.1   活動：確定參與者和用況 110
7.4.2   活動：區(qū)分用況的優(yōu)先級 116
7.4.3   活動：詳細描述一個用況 117
7.4.4   活動：構造用戶界面原型 122
7.4.5   活動：構造用況模型 126
7.5   需求工作流小結 129
7.6   參考資料 130
第8章   分析 132
8.1   引言 132
8.2   分析概述 134
8.2.1   為什么分析不同于設計與實現 134
8.2.2   分析目的：小結 135
8.2.3   何時使用分析的具體實例 135
8.3   分析在軟件生命周期中的作用 136
8.4   制品 137
8.4.1   制品：分析模型 137
8.4.2   制品：分析類 138
8.4.3   制品：用況實現—分析 141
8.4.4   制品：分析包 144
8.4.5   制品：構架描述（分析模型的視圖） 146
8.5   工作人員 147
8.5.1   工作人員：構架設計師 147
8.5.2   工作人員：用況工程師 148
8.5.3   工作人員：構件工程師 148
8.6   工作流 149
8.6.1   活動：構架分析 150
8.6.2   活動：分析用況 155
8.6.3   活動：分析類 157
8.6.4   活動：分析包 161
8.7   分析小結 162
8.8   參考資料 163
第9章   設計 164
9.1   引言 164
9.2   設計在軟件生命周期中的作用 165
9.3   制品 166
9.3.1   制品：設計模型 166
9.3.2   制品:   設計類 167
9.3.3   制品：用況實現—設計 168
9.3.4   制品：設計子系統 170
9.3.5   制品：接口 172
9.3.6   制品：構架描述（設計模型的視圖） 173
9.3.7   制品：實施模型 173
9.3.8   制品：構架描述（實施模型的視圖） 174
9.4   工作人員 175
9.4.1   工作人員：構架設計師 175
9.4.2   工作人員：用況工程師 175
9.4.3   工作人員：構件工程師 176
9.5   工作流 177
9.5.1   活動：構架設計 177
9.5.2   活動：設計一個用況 191
9.5.3   活動：設計一個類 196
9.5.4   活動：設計一個子系統 201
9.6   設計小結 203
9.7   參考資料 204
第10章   實現 205
10.1   引言 205
10.2   實現在軟件生命周期中的作用 205
10.3   制品 206
10.3.1   制品：實現模型 206
10.3.2   制品：構件 207
10.3.3   制品：實現子系統 208
10.3.4   制品：接口 210
10.3.5   制品：構架描述（實現模型的視圖） 212
10.3.6   制品：集成構造計劃 212
10.4   工作人員 213
10.4.1   工作人員：構架設計師 213
10.4.2   工作人員：構件工程師 214
10.4.3   工作人員：系統集成人員 214
10.5   工作流 215
10.5.1   活動：構架實現 215
10.5.2   活動：系統集成 217
10.5.3   活動：實現一個子系統 219
10.5.4   活動：實現一個類 221
10.5.5   活動：執(zhí)行單元測試 223
10.6   實現小結 226
10.7   參考資料 226
第11章   測試 227
11.1   引言 227
11.2   測試在軟件生命周期中的作用 227
11.3   制品 228
11.3.1   制品：測試模型 228
11.3.2   制品：測試用例 229
11.3.3   制品：測試規(guī)程 231
11.3.4   制品：測試構件 232
11.3.5   制品：制定測試計劃 233
11.3.6   制品：缺陷 233
11.3.7   制品：評估測試 233
11.4   工作人員 233
11.4.1   工作人員：測試設計人員 233
11.4.2   工作人員：構件工程師 234
11.4.3   工作人員：集成測試人員 234
11.4.4   工作人員：系統測試人員 234
11.5   工作流 234
11.5.1   活動：制定測試計劃 235
11.5.2   活動：設計測試 236
11.5.3   活動：實現測試 239
11.5.4   活動：執(zhí)行集成測試 240
11.5.5   活動：執(zhí)行系統測試 240
11.5.6   活動：評估測試 241
11.6   測試小結 242
11.7   參考資料 242
第三部分   迭代和增量的開發(fā)過程
第12章   一般的迭代工作流 245
12.1   對平衡的需要 245
12.2   階段是開發(fā)工作的第一次劃分 246
12.2.1   初始階段確立系統可行性 246
12.2.2   細化階段關注“做的能力” 247
12.2.3   構造階段建造系統 248
12.2.4   移交階段轉移到用戶環(huán)境 248
12.3   再論一般的迭代 248
12.3.1   在每次迭代中重復的核心工作流 249
12.3.2   參與到工作流中的工作人員 249
12.4   計劃先于行動 251
12.4.1   制定四個階段的計劃 251
12.4.2   制定迭代計劃 252
12.4.3   長遠考慮 253
12.4.4   制定評估準則 253
12.5   影響項目計劃的風險 254
12.5.1   管理風險清單 254
12.5.2   影響迭代計劃的風險 254
12.5.3   風險處理進度安排 255
12.6   用況優(yōu)先級排序 255
12.6.1   針對特定產品的風險 256
12.6.2   沒有正確獲得構架的風險 256
12.6.3   沒有正確獲得需求的風險 257
12.7   所需要的資源 258
12.7.1   項目間存在廣泛的差異 258
12.7.2   一個典型的項目 259
12.7.3   復雜項目具有更大的需要 259
12.7.4   新的產品線要求經驗 260
12.7.5   資源消耗所需費用的支付 261
12.8   迭代和階段的評估 261
12.8.1   沒有達標時的處理 262
12.8.2   準則本身 262
12.8.3   下一次迭代 262
12.8.4   模型集的進化 263
第13章   初始階段啟動項目 264
13.1   初始階段概述 264
13.2   初始階段初期 265
13.2.1   初始階段開始之前 265
13.2.2   制定初始階段計劃 265
13.2.3   擴展系統構想 266
13.2.4   設立評價準則 266
13.3   原型的初始迭代工作流 268
13.3.1   五個核心工作流引言 268
13.3.2   把項目融入到開發(fā)環(huán)境中 269
13.3.3   找出關鍵風險 270
13.4   執(zhí)行五個核心工作流—從捕獲需求到
測試 270
13.4.1   捕獲需求 270
13.4.2   分析 273
13.4.3   設計 274
13.4.4   實現 274
13.4.5   測試 275
13.5   構造初始業(yè)務案例 275
13.5.1   對業(yè)務標書的勾畫 275
13.5.2   對投資回報的估計 276
13.6   評估初始階段中的迭代 276
13.7   制定細化階段的計劃 277
13.8   初始階段的可交付內容 278
第14章   細化階段構造構架基線 279
14.1   細化階段概述 279
14.2   細化階段初期 279
14.2.1   制定細化階段計劃 280
14.2.2   組建開發(fā)組 280
14.2.3   改變開發(fā)環(huán)境 280
14.2.4   設立評價準則 280
14.3   原型的細化迭代工作流 281
14.3.1   捕獲并細化絕大多數需求 282
14.3.2   開發(fā)構架基線 282
14.3.3   開發(fā)組較小時的迭代 282
14.4   執(zhí)行五個核心工作流—從捕獲需求到
測試 283
14.4.1   捕獲需求 283
14.4.2   分析 286
14.4.3   設計 288
14.4.4   實現 290
14.4.5   測試 292
14.5   產生業(yè)務案例 293
14.5.1   準備業(yè)務標書 293
14.5.2   更新投資回報 293
14.6   評估細化階段的迭代 294
14.7   制定構造階段計劃 294
14.8   關鍵的可交付內容 295
第15章   構造階段形成初步可運行能力 296
15.1   構造階段概述 296
15.2   構造階段初期 296
15.2.1   本階段人員安排 297
15.2.2   設立評價準則 297
15.3   原型的構造迭代工作流 298
15.4   執(zhí)行五個核心工作流—從捕獲需求到
測試 299
15.4.1   捕獲需求 301
15.4.2   分析 301
15.4.3   設計 302
15.4.4   實現 303
15.4.5   測試 304
15.5   控制業(yè)務案例 305
15.6   評估構造階段的迭代 305
15.7   制定移交階段計劃 306
15.8   關鍵的可交付內容 306
第16章   移交階段完成產品發(fā)布 307
16.1   移交階段概述 307
16.2   移交階段初期 308
16.2.1   制定移交階段計劃 308
16.2.2   移交階段人員安排 309
16.2.3   設立評價準則 310
16.3   核心工作流在本階段中扮演了很小的
角色 310
16.4   在移交階段要干些什么 311
16.4.1   發(fā)行beta版本 311
16.4.2   安裝beta版本 312
16.4.3   響應測試結果 312
16.4.4   讓產品適應不同的用戶環(huán)境 313
16.4.5   完成制品 314
16.4.6   項目什么時候結束 314
16.5   業(yè)務案例的完成 314
16.5.1   控制進度 315
16.5.2   業(yè)務計劃的審查 315
16.6   評估移交階段 315
16.6.1   對迭代和階段的評估 315
16.6.2   項目的事后分析 316
16.7   制定下一版本或升級版本開發(fā)計劃 316
16.8   關鍵的可交付內容 316
第17章   統一過程的運用 318
17.1   統一過程幫助你解決復雜性問題 318
17.1.1   生命周期的目標 318
17.1.2   生命周期的構架 319
17.1.3   可初步運行的能力 319
17.1.4   產品發(fā)布 319
17.2   主題 319
17.3   通過管理引導向統一過程的轉化 320
17.3.1   行動案例 321
17.3.2   重建工程指南的宣傳和貫徹 321
17.3.3   實現轉變 322
17.4   統一過程專題 323
17.4.1   裁剪過程 324
17.4.2   填充過程框架 324
17.5   聯系更廣泛的社團 325
17.6   采用統一過程的好處 325
17.7   參考資料 326
附錄A   UML綜述 327
A.1   引言 327
A.1.1   詞匯 327
A.1.2   擴展機制 328
A.2   圖符 328
A.2.1   結構類的事物 328
A.2.2   行為類的事物 329
A.2.3   分組類的事物 330
A.2.4   注解類的事物 330
A.2.5   依賴關系 331
A.2.6   關聯關系 331
A.2.7   泛化關系 331
A.2.8   擴展機制 331
A.3   術語表 332
A.4   參考資料 337
附錄B   針對統一過程的UML擴展 338
B.1   引言 338
B.2   構造型 338
B.3   標記值 339
B.4   圖符 340
B.5   參考資料 340
附錄C   常用術語 341
C.1   引言 341
C.2   術語 341
索引 349