统一软件开发过程

第一部分   统一软件开发过程
第1章   统一过程的特点：用况驱动. 以构架
为中心. 迭代和增量的 3
1.1   统一过程概述 3
1.2   统一过程是用况驱动的 4
1.3   统一过程是以构架为中心的 5
1.4   统一过程是迭代和增量的过程 6
1.5   统一过程的生命周期 7
1.5.1   产品 8
1.5.2   一次循环所包含的阶段 9
1.6   一个综合的过程 11
第2章   软件开发的四个要素：人员. 项目. 
产品和过程 12
2.1   人员至关重要 12
2.1.1   开发过程影响人员 13
2.1.2   角色会发生变化 13
2.1.3   将“资源”转化为“工作人员” 14
2.2   项目创造产品 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   用况驱动开发概述 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   参与者是系统的环境 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   组织开发 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   构架设计师创建构架 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   以细小的步骤开发 65
5.1.2   迭代不是什么 66
5.2   为什么采用迭代和增量的开发方法？ 66
5.2.1   降低风险 67
5.2.2   获得一个健壮的构架 68
5.2.3   处理不断变化的需求 68
5.2.4   允许灵活改变 69
5.2.5   实现持续的集成 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   规划迭代过程 75
5.4.3   确定迭代次序 75
5.5   一次迭代产生一个增量结果 76
5.6   在整个生命周期上的迭代 77
5.7   由迭代过程来进化模型 79
5.8   迭代对开发组织具有挑战性 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   使用业务模型来理解系统的语境 93
6.6.1   什么是业务模型？ 93
6.6.2   如何建立业务模型 95
6.6.3   根据业务模型确定用况 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   活动：区分用况的优先级 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   活动：执行单元测试 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   制品：测试规程 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   活动：执行集成测试 240
11.5.5   活动：执行系统测试 240
11.5.6   活动：评估测试 241
11.6   测试小结 242
11.7   参考资料 242
第三部分   迭代和增量的开发过程
第12章   一般的迭代工作流 245
12.1   对平衡的需要 245
12.2   阶段是开发工作的第一次划分 246
12.2.1   初始阶段确立系统可行性 246
12.2.2   细化阶段关注“做的能力” 247
12.2.3   构造阶段建造系统 248
12.2.4   移交阶段转移到用户环境 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   用况优先级排序 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   把项目融入到开发环境中 269
13.3.3   找出关键风险 270
13.4   执行五个核心工作流—从捕获需求到
测试 270
13.4.1   捕获需求 270
13.4.2   分析 273
13.4.3   设计 274
13.4.4   实现 274
13.4.5   测试 275
13.5   构造初始业务案例 275
13.5.1   对业务标书的勾画 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   组建开发组 280
14.2.3   改变开发环境 280
14.2.4   设立评价准则 280
14.3   原型的细化迭代工作流 281
14.3.1   捕获并细化绝大多数需求 282
14.3.2   开发构架基线 282
14.3.3   开发组较小时的迭代 282
14.4   执行五个核心工作流—从捕获需求到
测试 283
14.4.1   捕获需求 283
14.4.2   分析 286
14.4.3   设计 288
14.4.4   实现 290
14.4.5   测试 292
14.5   产生业务案例 293
14.5.1   准备业务标书 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   执行五个核心工作流—从捕获需求到
测试 299
15.4.1   捕获需求 301
15.4.2   分析 301
15.4.3   设计 302
15.4.4   实现 303
15.4.5   测试 304
15.5   控制业务案例 305
15.6   评估构造阶段的迭代 305
15.7   制定移交阶段计划 306
15.8   关键的可交付内容 306
第16章   移交阶段完成产品发布 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   发行beta版本 311
16.4.2   安装beta版本 312
16.4.3   响应测试结果 312
16.4.4   让产品适应不同的用户环境 313
16.4.5   完成制品 314
16.4.6   项目什么时候结束 314
16.5   业务案例的完成 314
16.5.1   控制进度 315
16.5.2   业务计划的审查 315
16.6   评估移交阶段 315
16.6.1   对迭代和阶段的评估 315
16.6.2   项目的事后分析 316
16.7   制定下一版本或升级版本开发计划 316
16.8   关键的可交付内容 316
第17章   统一过程的运用 318
17.1   统一过程帮助你解决复杂性问题 318
17.1.1   生命周期的目标 318
17.1.2   生命周期的构架 319
17.1.3   可初步运行的能力 319
17.1.4   产品发布 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