RUP(Rational Unified Process)是Rational公司开发的一种软件工程过程，是开发组织用于分配和管理任务及职责的规范化方法，其目标是帮助开发人员在预定的进度和预算范围内开发出符合最终用户需求的产品。
　　本书依照RUP 2003进行编写，全面而简洁地介绍了RUP的概念、结构、内容和动机，帮助读者学会如何开发出高质量的软件。本书作者是RUP的首席体系结构师，本书融入作者几十年的开发经验，极具实用性。本书适合所有参与软件开发的人员阅读。

无

RUP (Rational Unified Process)最初是由Rational软件公司（现在已合并到IBM公司）开发并向市场推广的一个软件工程过程。它是开发组织用以分配和管理任务及职责的一个规范化方法。RUP的目标是在预定的进度和预算范围内开发出符合最终用户需要的高质量软件。
　　RUP综合了许多现代软件开发的最佳实践，并使用一种可裁剪的方式来体现这些实践，以适用于各种项目和组织。它以一种详尽、实用的方式将这些最佳实践在线地提供给项目团队。
　　本书介绍了RUP的概念、结构、内容以及动机。

本书的目标
　　利用本书，你将学习到如下内容：
　　* 何为RUP。
　　* RUP的术语及如何理解其结构。
　　* 在RUP中综合的最佳实践的优点。
　　* 在一个项目中，RUP如何向你提供完成特定职责所需要的指导。
　　本书没有涵盖完整的RUP，而只涉及其中一部分内容，用以介绍RUP。在完整的RUP中，你可以找到进行开发工作所需要的详细指导。完整的RUP产品—在线知识库，可从IBM获得。
　　本书大量引用统一建模语言（Unified Modeling Language，UML）的内容，但它并不是一本介绍UML的书。如果读者希望了解UML，请参考以下两本书：《UML用户指南》和《UML参考手册》。
　　本书还讲授了建模和面向对象技术，但并没有讲授设计方法，也没有讲解如何建模。有关嵌入RUP中的各种技术的详尽步骤和指南，只能在过程产品中找到。
　　本书有几章讨论了项目管理问题，描述迭代开发计划和风险管理等主题。然而本书决不是一本完整的有关项目管理和软件经济学的手册。如果要得到这方面的更多信息，请参考《软件项目管理：一个统一的框架》这本书。《统一软件开发过程》这本书描述了更加通用的软件开发过程，而本书只介绍一个特殊而详细的实例。

致谢
　　RUP凝聚了来自Rational软件公司以及其他各方面软件专业人员的共同智慧。本书第2章介绍了这一过程的历史。但是要把各个方面人员的共同智慧综合成一本书，即使是像这样一本概论式的书，也需要一批人付出极大的热忱和努力。在这里，我把他们一一介绍给读者。
　　过程开发组(Process Development Group)的早期成员创建了RUP，并对本书做出了贡献。首先是Stefan Bylund，然后是Kurt Bittner，最后是Bruce Macisaac对有关分析和设计的章做出了贡献。Maria Ericsson与Leslee Probasco开发了业务工程和需求管理的有关内容。测试部分开始于Bruce Katz，然后由Paul Szymkowiak完全重新设计。John Smith扩展了RUP 2000的项目管理方面的内容。Jas Madhur对配置管理、变更管理和部署贡献了很多见解。H宬an Dyrhage对过程的组织和结构及其实施和配置贡献了许多想法。Margaret Chan和Susan Buie负责产品集成以及本书绝大多数原图的汇编工作。Sigurd Hopen在Bj歳n Gustafsson的帮助下开发了PEP。
　　Per Kroll是开发组的经理，Mike Barnard是产品经理。Alfredo Bencomo、Chinh Vo、Philip Denno、Lars Jenzer、Glenys Macisaac以及Fionna Chong开发了产品的基础结构。Debbie Gray是这个横跨9个时区的团队的尽职尽责的行政助理。
　　RUP以及本书得益于过去8年来许多人的评阅和思想。他们包括：Stefan Ahlqvist、 Dave Bernstein、Grady Booch、Murray Cantor、Geoff Clemm、Catherine Connor、Mike Devlin、Christian Ehrenborg、Ian Gavin、Christina Gisselberg、Sam Guckenheimer、Bj歳n Gustafsson、Matt Herdon、Ivar Jacobson、Paer Jansson、Ron Krubek、Dean Leffingwell、Andrew Lyons、Bruce Malasky、Roger Oberg、Gary Pollice、Terri Quatrani、Walker Royce、Jim Rumbaugh、Ian Spence、John Smith以及Brian White。
　　我们非常感谢Grady Booch为本书撰写了第1章。
　　特别感谢Rational领域的人员、我们的Chat_RUP列表中的成员以及RUP论坛的成员所提供的反馈意见和做出的贡献。
　　最后要深深感谢本书的编辑Mary O誃rien、本书前任编辑J.Carter Shanklin以及Brenda Mulligan、Amy Fleischer和她的团队，还要感谢Addison-Wesley的所有员工，正是由于他们的努力才使得本书能够尽快问世。


Philippe Kruchten
温哥华 B.C., 加拿大

(美)Philippe Kruchten：Philippe Kruchten: Philippe Kruchten博士是Rational统一过程的首席体系结构师。他对电信、国防、航空以及运输领域的大型软件密集系统的开发有30多年的经验。本书的前两版已经被翻译成8种语言，前两版的销售量超过了160，000本。

麻志毅 申成磊 杨智：暂无简介

目前，越来越多的领域中的用户都希望把更多、更难的问题交给计算机去解决。这使得计算机软件的规模和复杂性与日俱增，软件技术也不断地受到新的挑战。开发一个具有一定规模和复杂性的软件系统和编写一个简单的程序大相径庭。大型的、复杂的软件系统开发是一项工程，必须按照工程学的方法组织软件的生产与管理，这是人们从软件危机中获得的最重要的教益。开发软件系统时，建模和编程都很重要，但是也要遵循合适的开发过程。统一软件开发过程就是目前流行的开发过程之一。
　　针对统一软件开发过程中所描述的更通用的过程，RUP为其一个特定的详尽实例。RUP综合了许多现代软件开发的最佳实践，并使用一种可裁剪的方式来表达，以适用于各种各样的项目和组织。它以一种详尽、实用的方式将这些最佳实践在线地提供给项目组。其目的是帮助软件开发人员在预定的进度和预算范围内，开发出符合最终用户需要的高质量软件。
　　本书讲述了RUP中的主要概念、结构、内容以及动机，有关各种技术细节可从IBM的在线知识库中获得。
　　本书按照RUP 2003进行了更新。与第2版相比，本书中的几个术语发生了变动，引入了新元素，对部分过程进行了一些重新设计，并更深入地将RUP开发为一个过程框架。在本书中结合了许多读者的反馈意见。
　　本书适合所有参加软件开发的人员，如项目经理、质量工程师、过程工程师、研究方法的专家、系统工程师和程序员等。打算采用RUP的单位可根据自己的实际需要，对该过程进行裁剪。
　　RUP本身处于不断的进化之中。机械工业出版社已于2002年出版了《The Rational Unified Process: An Introduction》第2版的中文译本《Rational统一过程引论》，本书是第3版中文译本。在翻译本书的过程中，有很多地方借鉴了第2版的中文译法，在此向第2版的译者表示感谢。
　　由于译者自身的水平有限，译文难免存在着错误和疏漏，希望读者给予批评与指正。

译者
2004年5月于北京

第一部分　 过　　　程
第1章　 最佳的软件开发实践 2
1.1　 软件的价值 2
1.2　 软件开发问题的症状和根本原因 2
1.3　 最佳的软件实践 3
1.4　 软件的迭代开发 4
1.5　 管理需求 5
1.6　 应用基于构件的架构 6
1.7　 为软件建立可视化模型 7
1.8　 对软件的质量进行持续的验证 8
1.9　 控制软件的变更 9
1.10　 RUP 9
1.11　 小结 10
第2章　 RUP 11
2.1　 什么是RUP 11
2.2　 作为产品的RUP 11
2.2.1　 过程产品的组织 12
2.2.2　 关于过程工程师 14
2.2.3　 二维过程结构 14
2.3　 RUP中的最佳软件实践 15
2.3.1　 迭代开发 15
2.3.2　 需求管理 16
2.3.3　 架构和构件的使用 17
2.3.4　 建模和UML 18
2.3.5　 配置管理和变更管理 18
2.4　 RUP中的其他重要特征 18
2.4.1　 用况驱动的开发 18
2.4.2　 过程配置 19
2.4.3　 工具支持 19
2.4.4　 谁在使用RUP 19
2.5　 RUP的发展简史 20
2.6　 小结 21
第3章　 静态结构：过程描述 22
3.1　 RUP的模型 22
3.2　 角色 22
3.3　 活动 24
3.4　 制品 25
3.4.1　 报告 26
3.4.2　 制品集 26
3.5　 规程 28
3.6　 工作流 29
3.6.1　 核心工作流 30
3.6.2　 工作流细节 30
3.6.3　 迭代计划 30
3.7　 附加过程元素 30
3.7.1　 指南 31
3.7.2　 模板 31
3.7.3　 工具指南 32
3.7.4　 概念 32
3.8　 过程框架 32
3.9　 小结 32
第4章　 动态结构：迭代开发 33
4.1　 顺序开发过程 33
4.1.1　 一个合理的方法 33
4.1.2　 错误假设1：需求是固定的 34
4.1.3　 错误假设2：我们可以在进行开发之前做出正确的书面设计 35
4.1.4　 提出风险分析 35
4.1.5　 延长时间 36
4.1.6　 减少文书工作 36
4.1.7　 基于规模和基于时间的计划 37
4.2　 克服困难：迭代 37
4.3　 获取控制：阶段和里程碑 38
4.4　 生命周期中焦点的转移 40
4.5　 阶段重访 40
4.5.1　 初始阶段 41
4.5.2　 里程碑：生命周期目标 42
4.5.3　 细化阶段 43
4.5.4　 里程碑：生命周期架构 44
4.5.5　 构造阶段 44
4.5.6　 里程碑：最初的可操作能力 45
4.5.7　 移交阶段 45
4.5.8　 里程碑：产品发布 46
4.6　 迭代方法的好处 47
4.6.1　 缓解风险 47
4.6.2　 适应变更 47
4.6.3　 在过程中不断学习 48
4.6.4　 增加复用机会 48
4.6.5　 更好的整体品质 48
4.7　 小结 48
第5章　 以架构为中心的过程 50
5.1　 模型的重要性 50
5.2　 架构 50
5.3　 架构的重要性 50
5.4　 架构的定义 51
5.5　 架构的表示 52
5.5.1　 多重视图 53
5.5.2　 架构的4+1视图模型 53
5.5.3　 模型和视图 55
5.5.4　 架构不仅仅是一个蓝图 55
5.6　 以架构为中心的过程 56
5.7　 架构的目标 56
5.7.1　 智能控制 56
5.7.2　 复用 57
5.7.3　 开发的基础 57
5.8　 基于构件的开发 57
5.9　 其他的架构概念 58
5.9.1　 架构风格 58
5.9.2　 架构机制 58
5.9.3　 架构模式 58
5.10　 小结 59
第6章　 用况驱动的过程 60
6.1　 定义 60
6.1.1　 用况和活动者 60
6.1.2　 事件流 62
6.1.3　 场景 62
6.1.4　 用况模型 63
6.2　 确定用况 63
6.3　 用况的进化 64
6.4　 用况的组织 64
6.5　 在过程中使用用况 65
6.6　 小结 67
第二部分　 过程规程
第7章　 项目管理规程 70
7.1　 目的 70
7.2　 计划迭代项目 70
7.3　 风险的概念 73
7.3.1　 什么是风险 73
7.3.2　 策略：如何处理风险 73
7.4　 度量的概念 74
7.5　 角色和制品 76
7.6　 工作流 77
7.6.1　 工作流细节 77
7.6.2　 制定一个阶段计划 80
7.7　 制定一个迭代计划 83
7.7.1　 细化阶段的迭代 84
7.7.2　 构造阶段的迭代 85
7.7.3　 移交阶段的迭代 85
7.7.4　 迭代中的工作细节 86
7.8　 小结 86
第8章　 业务建模规程 87
8.1　 目的 87
8.2　 为什么要进行业务建模 87
8.3　 在业务建模中使用软件工程技术 88
8.4　 业务建模场景 89
8.5　 角色和制品 90
8.6　 工作流 91
8.7　 从业务模型到系统 91
8.7.1　 业务模型和系统活动者 93
8.7.2　 自动业务工作人员 93
8.7.3　 分析模型中的业务模型和实体类 94
8.7.4　 在资源计划中使用业务分析模型 94
8.7.5　 系统需求的其他来源 95
8.7.6　 业务模型和系统架构 96
8.8　 为软件开发业务建模 96
8.9　 工具支持 96
8.10　 小结 97
第9章　 需求规程 98
9.1　 目的 98
9.2　 什么是需求 98
9.2.1　 功能性需求 98
9.2.2　 非功能性需求 99
9.3　 需求的种类 99
9.3.1　 项目相关人员：请求与需求 100
9.3.2　 系统特征 100
9.3.3　 软件需求 101
9.3.4　 通过用况详细说明软件需求 101
9.4　 捕获和管理需求 101
9.5　 需求工作流 102
9.6　 需求中的角色 103
9.7　 需求中使用的制品 104
9.8　 工具支持 106
9.9　 小结 106
第10章　 分析和设计规程 107
10.1　 目的 107
10.2　 分析与设计 107
10.3　 到底要设计到什么程度 107
10.4　 角色和制品 108
10.5　 设计以用户为中心的界面 109
10.6　 设计模型 109
10.7　 分析模型 109
10.8　 接口扮演的角色 109
10.9　 实时系统的制品 110
10.10　 基于构件的设计 110
10.11　 工作流 110
10.12　 工具支持 113
10.13　 小结 113
第11章　 实现规程 114
11.1　 目的 114
11.2　 构造 114
11.3　 集成 114
11.4　 原型 115
11.5　 角色和制品 117
11.6　 工作流 118
11.7　 工具支持 119
11.8　 小结 120
第12章　 测试规程 121
12.1　 目的 121
12.2　 在迭代生命周期中进行测试 122
12.2.1　 质量 122
12.2.2　 产品质量所有权 123
12.3　 测试的维 123
12.3.1　 质量维 123
12.3.2　 测试的阶段 124
12.3.3　 测试的类型 124
12.3.4　 回归测试 125
12.4　 角色和制品 125
12.5　 工作流 128
12.5.1　 定义评估任务 129
12.5.2　 验证测试方法 129
12.5.3　 验证构造的稳定性 129
12.5.4　 测试和评估 130
12.5.5　 完成验收任务 130
12.5.6　 改进测试资产 130
12.6　 工具支持 131
12.7　 小结 131
第13章　 配置和变更管理规程 133
13.1　 目的 133
13.2　 CCM立方体 133
13.2.1　 配置管理 134
13.2.2　 变更请求管理 135
13.2.3　 状态和度量 136
13.3　 角色和制品 137
13.4　 工作流 138
13.4.1　 计划项目配置和变更控制 138
13.4.2　 建立项目CM环境 138
13.4.3　 变更和交付配置条款 139
13.4.4　 管理基线和发布 140
13.4.5　 监控和报告配置状态 140
13.4.6　 管理变更请求 140
13.5　 工具支持 140
13.6　 小结 141
第14章　 环境规程 142
14.1　 目的 142
14.1.1　 配置RUP 142
14.1.2　 实例化RUP 143
14.1.3　 定制RUP 143
14.1.4　 实现RUP 144
14.2　 角色和制品 144
14.3　 工作流 145
14.3.1　 为项目准备环境 145
14.3.2　 为迭代准备环境 146
14.3.3　 为迭代提供支持环境 146
14.4　 工具支持 146
14.5　 小结 147
第15章　 部署规程 148
15.1　 目的 148
15.2　 角色和制品 149
15.3　 工作流 150
15.3.1　 计划部署 150
15.3.2　 开发支持材料 150
15.3.3　 产品部署单元 151
15.3.4　 在开发地点管理接受测试 151
15.3.5　 beta测试产品 151
15.3.6　 在安装现场管理接受测试 152
15.3.7　 打包产品 153
15.3.8　 提供对下载地点的访问 153
15.4　 小结 153
第16章　 典型的迭代计划 154
16.1　 定义产品构想和业务用况 154
16.1.1　 结果 155
16.1.2　 初始阶段的后继迭代 156
16.2　 建立架构原型 156
16.2.1　 结果 159
16.2.2　 细化阶段中的后继迭代 159
16.3　 实现系统 159
16.4　 小结 161
第17章　 实施RUP 162
17.1　 概述 162
17.2　 实施过程的效果 162
17.3　 逐步实施RUP 163
17.3.1　 步骤1：评估当前状态 164
17.3.2　 步骤2：建立或修订目标 165
17.3.3　 步骤3：识别风险 165
17.3.4　 步骤4：计划过程实施 166
17.3.5　 步骤5：执行过程实施 167
17.3.6　 步骤6：评价过程实施 168
17.4　 实施过程也是一个项目 168
17.5　 小结 169
附　　　录
附录A　 角色小结 172
附录B　 制品小结 175
附录C　 缩写词 179
术语表 181
参考文献 187
索引 195