Rational 统一过程引论（原书第2版） (2010 年度畅销榜NO.3125 )

Rational统一过程是由Rational软件公司开发和营销的一种软件工程过程，是开发组织用以分配与管理任务和职责的一种规范化方法，它能提高开发队伍的开发效率，并能给所有开发人员提供最佳的软件开发实践。\r\n本书简明扼要地介绍了Rational统一过程的概念、结构、内容和动机。以本书为指导，开发人员可以在预定的进度和合理的预算范围内开发出高质量的软件产品。本书的作者是Rational统一过程这一产品的首席构架师，他在本书中与读者分享他所拥有的过程知识，并将重点放在掌握这种行之有效的软件开发方法的核心技术上。本书是为所有参与软件开发的人员撰写的，尤其适合那些已经或即将采纳Rational统一过程的开发组织的成员；同时，本书也可以作为广大读者学习软件开发相关课程的补充教材。\r\n\r\n
\r\n

\r\n第一部分 过 程\r\n第1章 最佳的软件开发实践 2\r\n1.1 软件的价值 2\r\n1.2 软件开发问题的症状和根本原因 2\r\n1.3 最佳的软件实践 3\r\n1.4 迭代地开发软件 4\r\n1.5 管理需求 6\r\n1.6 应用基于构件的构架 6\r\n1.7 为软件建立可视化的模型 8\r\n1.8 不断地验证软件质量 9\r\n1.9 控制软件的变更 10\r\n1.10 Rational统一过程 11\r\n1.11 小结 12\r\n第2章 Rational统一过程 13\r\n2.1 什么是Rational统一过程 13\r\n2.2 作为一个产品的Rational统一过程 13\r\n2.2.1 过程产品的组织 14\r\n2.2.2 谁在使用Rational统一过程 16\r\n2.3 二维过程结构 17\r\n2.4 Rational统一过程中软件的最佳实践 18\r\n2.4.1 迭代开发 18\r\n2.4.2 需求管理 19\r\n2.4.3 构架和构件的使用 20\r\n2.4.4 建模和UML 21\r\n2.4.5 过程质量和产品质量 22\r\n2.4.6 配置管理和变更管理 22\r\n2.5 Rational统一过程的其它重要特征 22\r\n2.5.1 用况驱动的开发 23\r\n2.5.2 过程配置 23\r\n2.5.3 工具支持 24\r\n2.6 Rational统一过程的简要历史 24\r\n2.7 小结 25\r\n第3章 静态结构：过程描述 27\r\n3.1 Rational统一过程的模型 27\r\n3.2 工作人员 28\r\n3.3 活动 29\r\n3.4 制品 31\r\n3.4.1 报告 33\r\n3.4.2 制品集 33\r\n3.5 工作流 34\r\n3.5.1 核心工作流 36\r\n3.5.2 工作流细节 37\r\n3.5.3 迭代计划 37\r\n3.6 附加过程元素 37\r\n3.6.1 指南 38\r\n3.6.2 模板 39\r\n3.6.3 工具指南 40\r\n3.6.4 概念 40\r\n3.7 过程框架 40\r\n3.8 小结 40\r\n第4章 动态结构：迭代开发 41\r\n4.1 顺序开发过程 41\r\n4.1.1 一个合理方法 42\r\n4.1.2 错误假设1：需求是固定的 43\r\n4.1.3 错误假设2：我们可以在进行实际\r\n开发之前做出正确的设计 44\r\n4.1.4 提出风险分析 44\r\n4.1.5 延长开发时间 45\r\n4.1.6 减少文书工作 46\r\n4.1.7 基于规模和基于时间的计划 46\r\n4.2 克服困难的方法：迭代式开发 46\r\n4.3 通过阶段和里程碑对项目进行控制 47\r\n4.4 生命周期中焦点的转移 50\r\n4.5 阶段重访 51\r\n4.5.1 初始阶段 51\r\n4.5.2 里程碑：生命周期目标 53\r\n4.5.3 细化阶段 54\r\n4.5.4 里程碑：生命周期构架 55\r\n4.5.5 构造阶段 56\r\n4.5.6 里程碑：最初运作能力 57\r\n4.5.7 移交阶段 57\r\n4.5.8 里程碑：产品发布 59\r\n4.6 迭代方法的好处 59\r\n4.6.1 缓解风险 60\r\n4.6.2 适应变更 60\r\n4.6.3 在工作过程中学习 61\r\n4.6.4 增加重用机会 61\r\n4.6.5 更好的整体品质 61\r\n4.7 小结 62\r\n第5章 以构架为中心的过程 63\r\n5.1 模型的重要性 63\r\n5.2 构架 63\r\n5.3 构架的重要性 64\r\n5.4 构架的定义 65\r\n5.5 构架的表示 66\r\n5.5.1 多重视图 67\r\n5.5.2 构架的4+1视图模型 68\r\n5.5.3 模型和视图 69\r\n5.5.4 构架不仅仅是一个蓝图 70\r\n5.6 以构架为中心的过程 71\r\n5.7 构架的目标 71\r\n5.7.1 智能控制 72\r\n5.7.2 重用 72\r\n5.7.3 开发的基础 72\r\n5.8 基于构件的开发 73\r\n5.9 其它的构架概念 74\r\n5.9.1 构架风格 74\r\n5.9.2 构架机制 74\r\n5.9.3 构架模式 74\r\n5.10 小结 75\r\n第6章 用况驱动的过程 76\r\n6.1 定义 76\r\n6.1.1 用况和参与者 76\r\n6.1.2 事件流 78\r\n6.1.3 情景 79\r\n6.1.4 用况模型 80\r\n6.2 识别用况 81\r\n6.3 用况的进化 81\r\n6.4 用况的组织 82\r\n6.5 在过程中使用用况 83\r\n6.6 小结 85\r\n第二部分 过程工作流\r\n第7章 项目管理工作流 88\r\n7.1 目的 88\r\n7.2 计划迭代项目 89\r\n7.3 风险的概念 91\r\n7.3.1 什么是风险 92\r\n7.3.2 策略：如何处理风险 92\r\n7.4 度量元的概念 93\r\n7.5 什么是度量元 95\r\n7.6 工作人员和制品 95\r\n7.7 工作流 97\r\n7.7.1 工作流细节 97\r\n7.7.2 制定一个阶段计划 100\r\n7.8 制定一个迭代计划 105\r\n7.8.1 细化阶段的迭代 106\r\n7.8.2 构造阶段的迭代 107\r\n7.8.3 移交阶段的迭代 108\r\n7.8.4 迭代中的工作细节 108\r\n7.9 小结 109\r\n第8章 业务建模工作流 110\r\n8.1 目的 110\r\n8.2 为什么要进行业务建模 110\r\n8.3 在业务建模中使用软件建模技术 112\r\n8.4 业务建模情景 112\r\n8.5 工作人员和制品 114\r\n8.6 工作流 115\r\n8.7 从业务模型到系统 117\r\n8.7.1 业务模型和系统参与者 117\r\n8.7.2 自动业务工作人员 117\r\n8.7.3 在分析模型中的业务模型\r\n和实体类 118\r\n8.7.4 在资源计划中使用业务对象模型 118\r\n8.7.5 系统需要的其它资源 119\r\n8.7.6 业务模型和系统构架 120\r\n8.8 对软件开发业务建模 121\r\n8.9 工具支持 121\r\n8.10 小结 122\r\n第9章 需求工作流 123\r\n9.1 目的 123\r\n9.2 什么是需求 123\r\n9.2.1 功能性需求 124\r\n9.2.2 非功能性需求 124\r\n9.3 需求的种类 125\r\n9.3.1 项目相关人员：请求与需要对比 125\r\n9.3.2 系统特性 126\r\n9.3.3 软件需求 127\r\n9.3.4 通过用况详细说明软件需求 127\r\n9.4 捕获需求和管理需求 127\r\n9.5 设计以用户为中心的界面 128\r\n9.6 需求工作流 129\r\n9.7 需求分析中的工作人员 130\r\n9.8 需求分析中使用的制品 132\r\n9.9 工具支持 133\r\n9.10 小结 134\r\n第10章 分析和设计工作流 135\r\n10.1 目的 135\r\n10.2 分析与设计 135\r\n10.3 到底要设计到什么程度 135\r\n10.4 工作人员和制品 136\r\n10.5 设计模型 137\r\n10.6 分析模型 138\r\n10.7 接口扮演的角色 138\r\n10.8 实时系统的制品 138\r\n10.9 基于构件的设计 139\r\n10.10 工作流 139\r\n10.11 工具支持 143\r\n10.12 小结 143\r\n第11章 实现工作流 144\r\n11.1 目的 144\r\n11.2 构造 144\r\n11.3 集成 145\r\n11.4 原型 146\r\n11.5 工作人员和制品 148\r\n11.6 工作流 149\r\n11.7 工具支持 151\r\n11.8 小结 151\r\n第12章 测试工作流 153\r\n12.1 目的 153\r\n12.2 质量 153\r\n12.3 在迭代生命周期中进行测试 154\r\n12.4 测试的层面 154\r\n12.4.1 质量的层面 155\r\n12.4.2 测试的阶段 155\r\n12.4.3 测试的类型 156\r\n12.4.4 回归测试 157\r\n12.5 测试模型 157\r\n12.6 工作人员和制品 158\r\n12.7 工作流 160\r\n12.7.1 计划测试 161\r\n12.7.2 设计测试 162\r\n12.7.3 实现测试 162\r\n12.7.4 在集成测试阶段执行测试 162\r\n12.7.5 在系统测试阶段执行测试 162\r\n12.7.6 评价测试 163\r\n12.8 工具支持 163\r\n12.9 小结 164\r\n第13章 配置和变更管理工作流 165\r\n13.1 目的 165\r\n13.2 CCM立方体 165\r\n13.2.1 配置管理 167\r\n13.2.2 变更需求管理 168\r\n13.2.3 状态和度量 169\r\n13.3 工作人员和制品 170\r\n13.4 工作流 171\r\n13.4.1 计划项目配置和变更控制 171\r\n13.4.2 建立项目CM环境 172\r\n13.4.3 变更和交付配置条款 173\r\n13.4.4 管理基线和发布 173\r\n13.4.5 监控和报告配置状态 173\r\n13.4.6 管理变更请求 173\r\n13.5 工具支持 174\r\n13.6 小结 174\r\n第14章 环境工作流 176\r\n14.1 目的 176\r\n14.2 工作人员和制品 176\r\n14.3 工作流 178\r\n14.3.1 为项目准备环境 178\r\n14.3.2 为迭代准备环境 179\r\n14.3.3 为迭代准备指南 179\r\n14.3.4 为迭代提供支持环境 180\r\n14.4 小结 180\r\n第15章 实施工作流 181\r\n15.1 目的 181\r\n15.2 工作人员和制品 183\r\n15.3 工作流 184\r\n15.3.1 计划实施 184\r\n15.3.2 开发支持材料 185\r\n15.3.3 在开发地点测试产品 185\r\n15.3.4 创建发布 187\r\n15.3.5 Beta测试发布 187\r\n15.3.6 在安装现场测试产品 187\r\n15.3.7 打包产品 187\r\n15.3.8 提供对下载站点的访问 187\r\n15.4 小结 188\r\n第16章 典型的迭代计划 189\r\n16.1 目的 189\r\n16.2 定义产品构想和业务用况 189\r\n16.2.1 结果 191\r\n16.2.2 初始阶段中的后继迭代 191\r\n16.3 建立构架原型 191\r\n16.3.1 结果 194\r\n16.3.2 细化阶段中的后继迭代 194\r\n16.4 实现系统 194\r\n16.5 小结 197\r\n第17章 配置和实现Rational统一过程 198\r\n17.1 介绍 198\r\n17.2 实现过程的效果 198\r\n17.3 逐步实现Rational统一过程 200\r\n17.3.1 步骤1：评估当前状态 200\r\n17.3.2 步骤2：建立(或修订)目的 201\r\n17.3.3 步骤3：识别风险 202\r\n17.3.4 步骤4：计划过程实现 202\r\n17.3.5 步骤5：执行过程实现 204\r\n17.3.6 步骤6：评价过程实现 205\r\n17.4 配置过程 205\r\n17.5 实现过程也是一个项目 206\r\n17.6 小结 207\r\n附录A 工作人员小结 209\r\n附录B 制品小结 212\r\n缩写词 218\r\n术语表 220\r\n参考文献 226\r\n索引 237 \r\n
\r\n

50多年来计算事业的发展使人们认识到, 要高效率. 高质量和低成本地开发和生产软件, 必须依靠高素质的人才. 先进的技术和优化的过程. 这三者是软件开发和生产的不可分割的三要素. 早在20世纪50年代中期, 人们就注意到人才和技术的因素, 但是直到20世纪80年代中期, 人们才认识到需要改善软件生产的过程. 一些人认为, 受过严格技能训练的人在工作时几乎不需要过程方面的指导, 这种想法在绝大多数情况下是错误的, 对于软件开发就更是如此. 这就像一支交响乐队, 单靠各个成员熟练的演奏技巧是远远不够的. 每个乐队成员都必须遵循预先选定的乐谱, 按照指挥的指令, 协调地演奏, 才能演奏出悦耳动听的音乐. 软件开发群组是不能独立行动的, 这不仅需要开发人员之间的密切配合, 还需要与项目主管和用户的友好协作. 因而, 不仅要求有一个能指导开发人员协同工作的良好过程（乐谱）, 而且要求有一个既熟悉过程又具有管理才能的经理（指挥）. 本书为读者提供了一个经过30年的发展和实际运用后在20世纪90年代中后期发展成熟起来的新一代软件开发过程.
一个过程定义了为达到某个确定的目标, 需要什么人在什么时间以何种方式进行的一系列活动. 用数学的语言来说, 过程是这一系列活动的偏序集, 其中每一个活动可用输入及其输入准则. 输出及其输出准则. 控制（或称约束）. 资源（或称支持）. 活动内容以及对活动性能的度量等8个元素来描述. 一个过程需要对这8个方面的元素作出恰当. 合理的规定. 一个有效的过程是指能为有效地开发高质量的软件提供方针指导, 是在当前技术条件下可行的最佳实践. 按照这样的过程开发软件, 所有与项目相关的人员都可以充分理解自己所扮演的角色, 从而降低风险, 增强预见性, 在发生偏离时也比较容易进行纠正.
为了充分发挥过程在软件生产中的积极作用, 过程工程师需要权衡与过程有关的技术. 工具. 人员和组织模式等四方面的因素. 这种权衡不仅现在必要, 而且在过程的整个进化过程中, 都需要项目管理人员对这些因素进行动态权衡, 以适应技术. 工具. 人员以及组织模式的变化, 使其发挥最大的效益.
本书介绍的Rational统一过程（RUP）是《统一软件开发过程》这本书中所描述的更通用的过程的一个特定. 详尽的实例. 通过本书, 可以了解到RUP的概念. 结构. 内容和动机, 认识到在这个过程中合成的最佳实践的优点, 学会用RUP指导项目的管理. 但本书仅是Rational统一过程的主要部分, 有关RUP的各种技术的细节, 可以从Rational软件公司的“在线知识库”获得. 此外, 本书是根据原书第2版翻译的, 在内容的广度和深度上, 都比原书的第1版有所扩充和改进.
本书是为所有参与软件开发的人员撰写的, 尤其适合那些已经或即将采纳Rational统一过程的开发组织的成员. 其中包括项目经理. 开发人员. 质量工程师. 过程工程师. 方法学专家. 系统工程师和分析员等.
在统一软件开发过程的进化中, 最具贡献意义的两个因素是强调构架优先和迭代式开发. 其中有关构架的文献一般都主张将构架表达为逻辑. 过程. 物理和开发等四个方面的视图, 并加上一种用用况来阐述前面四种视图的视图. 多视图法使得各类项目相关人员都能从适当的角度去发掘他们所想要的东西. 其中有关生命周期的文献都主张采用初始. 细化. 构造和移交四个阶段, 每个阶段包含一个或若干个迭代, 并强制迭代按照一定的顺序进行.
现在软件产业界普遍认为, 开发复杂软件项目必须采用基于UML的. 以构架为中心. 用况驱动与风险驱动相结合的迭代式增量开发过程, 它是世界公认的开发复杂项目的最好的过程, 已经成为软件界的“圣经”. 这一开发过程目前已经稳定. 成熟, 然而由于过程是基于知识的创新, 要将其精华转化为可用的技术, 仍有相当大的一段距离, 需要软件业内各界人士的共同努力以及有关主管的强有力支持.
我们翻译本书奉献给读者, 目的是期望引起广大读者对这种方法的重视, 共同为推进这种以构架为中心. 用况驱动与风险驱动相结合的迭代式增量开发过程贡献力量, 并注意对技术. 工具. 人员和组织模式等四种因素作出恰当的权衡, 以便对我国的软件产业的发展和壮大起到有力的推动作用. 最后, 由于我们的水平有限, 本书翻译中的缺点和错误在所难免, 希望读者提出批评指正.


北京航空航天大学软件工程研究所
周伯生 吴超英 王佳丽
2002年3月25日

Rational统一过程（Rational Unified Process, RUP）是由Rational软件公司开发和营销的一种软件工程过程, 是开发组织用以分配与管理任务和职责的一种规范化方法. 这个过程的目的是在预定的进度和预算范围内, 开发出满足最终用户需要的高质量软件.
Rational统一过程综合了很多最佳的现代软件开发实践, 用一种可剪裁的形式表达, 以适应各种各样的项目和组织的需要, 它以一种详尽. 实用的方式将这些最佳实践在线提供给项目组.
本书介绍了Rational统一过程的概念. 结构. 内容和动机.
本书的目的
通过本书, 你将：
学习什么是(以及什么不是)Rational统一过程,
掌握Rational统一过程的词汇并理解其结构,
认识到我们在这个过程中合成的最好实践的优点,
理解在一个项目中Rational统一过程如何向你提供完成特定职责所需要的指导.
本书中的内容是Rational统一过程的主要部分, 但并不是它的全部, 而只是其中很小的一个子集. 在完整的Rational统一过程中, 你可以找到进行开发工作所需要的详细指导. 完整的Rational统一过程产品在线的“知识库”可以从Rational软件公司获得.
本书大量引用统一建模语言（UML）的内容, 但它并不是一本介绍UML的书. 如果读者希望了解UML, 请参考以下两本书：《UML用户指南》和《UML参考手册》.
这本入门书还讲授了建模和面向对象技术, 但并不讲授设计方法, 也不教你如何建模. 有关嵌入RUP中的各种技术的详尽步骤和指南, 只能在Rational软件公司的过程产品中找到.
本书有几章讨论了项目管理问题, 描述迭代开发计划和风险管理等主题. 然而本书决不是一个完整的有关项目管理和软件经济学的手册. 如果要得到有关这方面的更多信息, 请参考《软件项目管理：一个统一的框架》这本书.
Rational统一过程是《统一软件开发过程》这本书中所描述的更通用的过程的一个特殊而详尽的实例.
谁应该读这本书
《Rational统一过程引论》（第2版）是为参与软件开发的各种人员撰写的, 其中包括：项目经理. 开发人员. 质量工程师. 过程工程师. 方法专家. 系统工程师和分析员.
本书尤其与那些已经采纳或即将采纳Rational统一过程的开发组织中的成员相关. 通常, 这些组织将会对Rational统一过程进行裁剪, 以适应自己的需求, 但是本书所描述的核心过程, 在Rational统一过程的所有实例中都通用.
本书对于学生学习由Rational软件公司及其工业界和学术界的伙伴发表的专业教程也是一本很好的补充教材. 它提供了这些教程中涉及的一些主题的相关内容.
本书假定读者已对软件开发具有一定的理解, 但不要求读者具备编程语言. 面向对象方法或统一建模语言（UML）方面更深入的知识.
如何使用这本书
本书各章采用了自然进展的组织结构. 因此, 在一个全部采用或部分采用Rational统一过程的开发组织中工作的软件专业人员应该顺序地阅读本书.
项目经理可以只读第1. 2. 4和7章. 这些章节介绍了风险驱动的迭代开发过程的含义.
过程工程师或方法学专家可能需要裁剪Rational统一过程, 并在他们的开发组织中建立起这种过程. 他们应该认真学习第3章和第17章, 这些章节描述了过程结构以及全面实现Rational统一过程的方法.
书的组织和特征
本书分为两部分.
第一部分介绍过程. 内容. 历史. 结构和软件开发生命周期. 它还描述Rational统一过程区别于其他软件开发过程的关键特征.
第1章：最佳的软件开发实践
第2章：Rational统一过程
第3章：静态结构：过程描述
第4章：动态结构：迭代开发
第5章：以构架为中心的过程
第6章：用况驱动的过程
第二部分给出各种过程构件或工作流的概况. 每一章对应一个核心过程工作流.
第7章：项目管理工作流
第8章：业务建模工作流
第9章：需求工作流
第10章：分析和设计工作流
第11章：实现工作流
?第12章：测试工作流
第13章：配置和变更管理工作流
第14章：环境工作流
第15章：实施工作流
第16章：典型的迭代计划
第17章：配置和实现Rational统一过程 大多数关于章节由六部分组成：
工作流的目的
定义和关键的概念
工作人员和制品
一个典型的工作流：活动的概况
工具支持
总结
书后的两个附录总结了从第7章到第15章中介绍的所有工作人员（过程中的角色）和制品（过程的工作产品）. 最后提供了缩写词和术语表以及一个简短的带注释的参考文献.
获取更多的信息
关于Rational统一过程的资料, 如数据表和可下载的演示版本, 可以通过因特网从Rational软件公司的网站www.rational.com/rup_info/获得.
假如你已经在使用Rational统一过程, 可以从Rational统一过程资源中心获取附加的资料, 这个资源中心负责向合作伙伴提供额外的有用资料. 更新和链接. 从在线版本可以找到与资源中心的超级链接.
学术机构可以与Rational软件公司取得联系, 获取某个特定计划中有关Rational统一过程的课程方面的资料.
第2版
《Rational统一过程引论》（第2版）按照“Rational统一过程2000”进行了更新. 在这个最新版本中, Rational统一过程在广度和深度两个方面都有所扩充. 在内容的广度上, 增加了关于业务工程. 非功能性需求管理以及多级分布式应用程序的开发与实施等内容. 原有内容也有所改进, 包括应用程序接口设计（尤其适用于开发有效的Web应用程序）以及使用模式与框架设计系统的内容, 同时增加了开发实时和反应式系统的知识. 测试工作扩展到从确认构架原型到验证交付产品的整个生命周期. 最后, 还增加了过程路线图, 以概述如何将Rational统一过程应用于各种不同项目和各种不同技术. 此外, 在内容的深度上, 扩展了关于过程制品. 活动和阶段的检测表与指南等方面的内容.
致谢
Rational统一过程凝聚了来自Rational软件公司和其他各方面的软件专业人员的共同智慧. 本书第2章介绍了这一过程的历史. 但是要把各方面人员的共同智慧综合成一本书, 即使是写这样一本引言, 也需要一批人投入很大的热诚和努力. 在这里, 我把他们一一介绍给读者.
Rational过程开发组的成员组合了Rational统一过程, 并对本书许多章节做出了贡献. 其中做出贡献的人与本书各章节的关系如下：
Kurt Bittner对分析和设计以及项目管理和测试等章节做出了贡献, 并开发了数据工程的有关内容.
Maria Ericsson开发了业务工程和需求管理的有关内容, 她曾是过程构架的管理员.
Leslee Probasco对需求管理工作流做出了贡献.
Stefan Bylund对分析和设计以及集成用户界面设计等章节做出了贡献.
H宬an Dyrhage对过程的组织和结构及其实现和配置等章节贡献了很多设想, 同时他还协调了在线版本的开发工作.
John Smith扩展了RUP 2000的项目管理方面的内容.
Jas Madhur对配置管理. 变更管理和实施贡献了很多见解.
Bruce Katz对过程的测试方面做出了贡献.
Margaret Chan负责产品集成以及本书绝大多数原图的汇编工作.
Debbie Gray是这支横跨9个时区的工作组的尽职尽责的行政助理.
我们非常感谢Grady Booch为本书撰写了第1章.
Per Kroll是Rational统一过程的营销经理, Paer Jansson是Rational统一过程的产品经理（最近由Matt Herdon与她共同管理）. Christina Gisselberg和Eric Turesson共同设计和开发了Rational统一过程的在线版本. Stefan Ahlqvist开发了用户界面设计的概念. Chinh Vo协助汇编了本书.
Dave Bernstein. Grady Booch. Geoff Clemm. Catherine Connor. Mike Devlin. Christian Ehrenborg (Dr. Usecase). Sam Guckenheimer. Bj歳n Gustafsson. Ivar Jacobson. Ron Krubek. Dean Leffingwell. Andrew Lyons. Bruce Malasky. Roger Oberg. Gary Pollice. Leslee Probasco. Terri Quatrani. Walker Royce. Jim Rumbaugh. John Smith和Brian White等人对Rational统一过程和本书进行了评阅, 提出了很多见解, 获益匪浅.
我们还要感谢Scott Ambler. Ensemble Systems. IBM Global Services和Content Integration等合作伙伴对Rational统一过程和本书做出的贡献.
特别要感谢Rational领域的所有工作人员, 尤其要感谢我们的英国朋友Ian Gavin. Ian Spence和Mike Tudball, 他们始终对Rational过程怀有极大的兴趣.
Frenglish和Swenglish这两个词是由Joy Hemphill和Pamela Clarke铸造的.
最后要深深感谢本书的编辑J. Carter Shanklin. Kristin Erickson. Marilyn Rash与她的工作小组以及Addison Wesley Longman公司的所有工作人员, 正是由于他们的努力才使本书尽快问世.


Philippe Kruchten
Vancouver, B.C., Canada