软件过程--XP 与 RUP 的比较与分析

1 背景

软件过程：人们用来开发和维护软件以 及相关产品( 工程计划 、设计文档 、规章等) 的一组活动 、方法 、实践及转换 。
常用软件过程：
统一过程( Rational Unifed Process, RUP)
极端编程( Extreme Programming,XP)
RUP 实质是一个软件工程化过程, 是Rational 公司为软件开发提供的完整的解决方案 。并且已经在世界上许多著名的公司中, 诸如爱立信 、惠普等, 得到很好的应用 。 由于RUP 过于庞大, 包含了软件开发过程的方方面面, 所以更适合于大型的组织开发复杂的、难度大及规模大的项目 。而当大多数小型的组织开发简单的、难度小 、规模 小而且时间紧的项目时, 常常感到无从下手 。 1999 年, Kent Beck 最早在他本人出版的 Extreme Programming Explained 一书中提出来了XP。Kent Beck 最初提出了12 种 XP的方法, 涵盖了设计、编码 、测试和反馈 。为软件开发提供了最为简洁且最易于应用的开发流程, 可以使小型的组织在开发软件过程中, 抓住最主要的矛盾, 快速而高效的开发软件 。在实际应用中, RUP 和 XP 有着各自的优缺点, 照搬任何一种方法可能都不能满足我们的要求 。因此有必要对两者进行比较分析, 使我们更清楚地了解什么是对 软件开发最重要的事情, 以便去其糟粕取其精华, 将两者融合在一起, 以适合不同的实际情况 。

2 简述

(1) RUP

RUP 提供了在软件开发中涉及到的几乎所有方面的内容。实际上组织并不需要执行所有的细节活动或 者是生成所有的详细工件 。不同的组织可以根据本组 织的情况裁剪 RUP以适合特定的应用 。整个Rational Unified Process 是一个两维的结构, 如图 1 所示 。 横轴代表软件的生命周期, 描述了 RUP 的动态结 构 。RUP 是一种迭代式的开发方法。它把整个软件开发周期分成四个阶段:起始阶段(Inception), 加工 阶段( Elabo ration), 构造阶段(Construction)和移交阶段(T ransition)。每个阶段要进行一次或多次迭 代 ,这就形成了一种两维空间结构(如图 1)。 在每个阶段中 ,为了达到一定的目标(Objective),要进行一系列活动(Activity),最后完成相应的制品 (A rtifacts)。

(2) XP

相比之下, XP (极限编程)则是针对小型项目, 以代码为中心的轻量级开发过程。它也基于迭代式开发方法,并结合了一 些工业界的实践经验。比如小型发布(Small releases),简化设计(Simple desig n), 测试驱动(Testing),重 构(Refactoring)等。 XP 在小型项目中工作地很好 。 XP 以 4 种价值为基础 :交流 、简化 、反馈和勇气 。 强调在整个开发的生命周期中, 客户和开发团队成员通过现场客户不断地进行交流 。现场客户决定要构建什么以及以什么顺序构建 。开发团队通过不断地重新划分 代码和生成最小的非代码工件来保持简单 。以若干发行的版本和不断的单元测试作为反馈系统 。

Kent Beck 在他的书中提到了 12 种方法 :

• 计划策略(The Planning Game) 通过综合确定了优先级和在技术实现上的估计, 决定下一个发行版本的特性 。
• 简单设计( Simple Design) 通过保持代码简单,来保持设计简单 。不断地检查代码的复杂性, 及时修改 。
• 测试(Testing) 由客户编写验收测试, 程序员编写检查代码中任何 可能崩溃的地方的单元测试 。这些测试要在编写代码 之前编写 。
• 重新划分( Refractoring) 重新编写代码并加以改进, 以去除重复的和复杂的 代码 。
• 成对编程( Pair Programming) 在一台计算机上以两个程序员一组来开发所有代码 。一个编写代码而另一个复查代码以及检查代码的 正确性和易理解性 。
• 不断地集成(Continuous Integration) 每天当所有任务完成之后, 进行一次或多次系统集 成 。
• 现场客户(On-site Customer) 在开发团队中需要一个真正的全职客户帮助定义 系统 、编写测试 、回答问题 。
• 系统比喻(System Metaphor) 系统比喻是简单的故事或者关于系统如何工作的 描述 。
• 集体代码所有权(Collective Code Ownership) 开发团队中的每一个人都拥有全部代码 。这意味着任何一个人能够在任何时候修改任何代码 。
• 每星期工作 40 小时( 40-hour Work) 不能允许程序员连续两个星期的超时工作 。
• 编码标准(Coding Standards) 程序员要采取一致的编码标准 。
• 小发行版本(Small Releases) 经常发布给客户小的增强版本 。

3 XP 和 RUP 的比较分析
我们已经知道, XP 实际上是 RUP 的一个最小实现 。 但是两者并不完全一致, 尤其是在一些具体做法上 。由于XP 涵盖了软件开发过程中最重要的几个方面, 同时又是最精练的 RUP 的实现 。因此我们将按照上面提到 的XP 的 12 种方法中的几种关键方法来与 RUP 作对比 分析 。

(1) 计划策略 在进行计划时, RUP 和 XP 实际上是一致的, 两者都认为, 我们不可能计划出整个项目的所有细节, 所以计 划是可以改变的 。最好的办法是预期这些变化, 尽量保 证我们可以控制相关的风险 。UML 中提出的用例驱动 的思想, 在两种开发过程中都至关重要 。RUP 和 XP 都是由用例驱动的, 用例贯穿于整个生命周期, 但是略有不同的是在 XP中称之为“故事( Stories)”, 两者并不完全相同 。故事描绘的仅是一系列工作, 而用例描绘了使用系统的用户的完整操作 ;用例是面向所有涉众的, 而故 事只是为开发人员提供更多的细节 ;用例可以通过对故 事补充更详细 、完整的上下文细节来实现用例 。

(2) 简单设计 XP 要求面向当前的需求构建最简单的系统, 而不去实现将来才可能需要的功能 。在这一点上, RUP 用不同的语言以不同的程度表达了相同的意思：管理需求, 不断地确定用例的优先级, 估计进展情况 。

(3) 测试 对于测试, RUP 和 XP 都十分重视 。因为测试对于保证最终产品的质量有着重大意义 。XP 强调首先要编写测试, 然后再进行编码 。它要求的测试包括两种 :一 种是由客户编写的验收测试, 作为客户判断产品是否达 到最终要求的标准 ;另一种是由开发人员编写的单元测 试, 作为衡量代码是否符合要求的标准 。而在 RUP 中测试贯穿于整个生命周期,并提供了一个更为通用的测试 框架以及怎样编写有效测试指南 。

(4) 重新划分 重新划分就是重写代码并加以改进, 以此来保证去 除冗余的 、复杂的代码, 保持简单的设计 。重新划分代 码可以由两个时机进行, 即功能实现之前和之后 。当我 们发现更好的方法可以使代码更简单 、更合理, 就要进 行重新划分, 力争编写出最好的代码 。 另外, 一定要明 白重新划分可能带来的风险, 进行得太多, 可能会陷入混乱, 所以严格的管理是必需的 。RUP 并没有明确表明这一点 。

(5) 成对编程 XP 提出的成对编程很特别 。意思是要求由两个人 来检查产生的每一行代码 。这一点在 RUP 中并没有表 明 。这样做的好处是 :所有设计决策都牵涉到至少两个 人 ;至少有两个人熟悉系统的每一部分 ;几乎不可能出 现两个人同时疏忽测试或其它任务 ;改变组合可以在团 队范围内传播知识 。

(6) 不断地集成 XP 提出每一天都要进行一次或多次集成 。因为如果到最后才进行集成的话, 产生问题的原因太多, 难以 确定 。然而如果每天都进行集成, 产生问题的原因的范 围很小, 更容易确定, 可以及时改正错误确保系统的正确性, 也有助于加快开发速度 。 RUP 持同样的观点, 而 且还提供了集成的工作指南和管理集成的配置管理工 具的使用指南 。

(7) 现场客户 实际上 RUP 和 XP 都强调了客户参与开发的重要 性 。XP 中, 要求团队中必须有一个真正的客户 。由现场 客户来回答问题, 编写验收测试, 设置优先级 。RUP 则 更加灵活, 承认现场客户并不总是可能的 。相应的, RUP 定义了几个具有决定项目目标及范围的责任的角色, 由 他们来保证与客户以及与开发人员的交流。

(8) 集合代码所有权 XP 提出的集合代码所有权, 不同于以往的方法 。 意思是每一个人不需要授权就可以修改代码的任何部 分, 同时无论改动哪一部分代码都必须编译代码并使其 通过测试 。RUP 并没有类似的表述 。

(9) 系统比喻 XP 提出的系统比喻实际上与 RUP 中的体系结构类 似 。系统比喻是描述系统怎么工作的故事, 这个故事包 括少数类和系统核心工作流 。实际上, 对小规模的系 统,系统比喻可以替代体系结构 。但是当系统规模变大 时, 不可能在一个简单的故事当中捕获所有的 信息 。 RUP 则提供了关于构件和体系结构的丰富指南, 可以根 据不同的目的从不同角度建立体系结构 。

(10) 其它 在 RUP 中包括了 XP 中并没有包括的内容 。

○ 业务建模 。XP 中没有包含整个业务建模的主 题 。实际上当组织需要展开目标系统时, 需要确定需求 和理解怎样的解决方法可能被接受, 这时组织对业务的 认识十分重要 。
○ 部署阶段 。XP 不包括这个领域 。任何一个系统 都需要支持材料, 最少需要在线文档 。商业软件产品更 需要打包 、分发 、用户手册 、培训材料以及一个支持组 织 。RUP 为此提供了完整详细的要求以及相应的工作 指南 。

4 总结

综上所述, 我们看到 RUP 和 XP 提供了两种不同的 软件开发过程, 彼此可以相互补充 。XP 集中于无论在 哪一种过程中都必须做的事情, 设计 、编码 、测试和反 馈,而去除了其它细枝末节强调面对面的交流和最小化 非代码的工件 。而 RUP是一个过程框架, 包含的内容涉 及到软件开发的方方面面, 非常注重风险以及如何最大 限度的减少风险 。任何组织可以对不同类型的项目进 行配置 。Rational 公司并不认为 RUP 是重量级的过程 。 因为作为一个框架, 它提供了适合许多类型的项目的过 程信息。而实际上, 一个对 RUP 进行过配置的实例可能 是非常“轻”的, 这取决于需要明确多少风险 。同时 RUP 是可扩展的, 如果 XP 或者其它过程中有好的适合某些 特定情况的技术, RUP 可以同它们相结合 。如果项目仅 仅是关于创建代码, 就可以使用 XP 。但是, 几乎所有的 项目都需要最初的商业决定和计划, 完整的文档, 支持 和客户配置 。 出于这个原因, 我们可以开始阶段使用 RUP 做业务建模 、需求分析等, 随后在开发代码过程中 用适当的 XP 的方法帮助团队快速地前进, 减少项目面 对的实际风险 。

基于 RUP 四个阶段,并集成 XP 技术的小型开发过程：

1 起始阶段(Inception)

起始阶段需要为软件系统建立业务模型, 其关键制品是视图(Vision)文档。视图描述了系统的主要 功能,系统的用户 ,以及系统中的约束等信息。

1. 1 活动 阐明系统的范围。

在构造一个软件系统之前,我们需要明确客户的需求 。通过阐明系统的范围, 我们 可以捕获系统的边界以及关键功能, 并得出最终产品是否可以被接受的标准 。 制定项目计划 。根据视图, 制定风险规避策略。制定原始项目计划 ,指出成本 ,进度表 ,以及利润上的 取舍。 选择候选架构 。对于使用成熟技术的项目 ,可以忽略这一步。当客户有特殊需求的时候,就需要对潜 在的候选架构进行评估 。在过程的早期就选择技术并开发出原型 ,可以有效降低项目的风险。 筹备项目环境 。不论使用什么技术,任何项目都需要环境。需要决定物理资源, 软件工具, 团队将遵 循的工序等。 一般的小型项目不会在起始阶段花太多的时间 ,通常是几天或更少。下面是除了视图文档之外的一 些制品 。

1. 2 制品 项目可行性报告。

客户有权最终决定项目是否可行 。 RUP 和 XP 都认为应尽早决定项目是否值得 继续,而不是把有限的资源浪费在没有前途的项目上 。 风险列表 。整个开发阶段都需要对风险列表进行维护。在简单情况下, 仅仅罗列一下风险和风险规 避策略即可。 初步项目计划书。包括资源 ,边界和各阶段的计划 。项目标准计划书 。必须指出什么样的产品可以 被客户所接受 。在 XP 中, 以产品最终通过由客户提供的测试用例为准 。然而通常情况下, 客户也许不会 亲自进行测试 ,这时就要由系统分析员制定出标准。 初步加工阶段计划书。在使用 RUP 的项目中 ,在每一次迭代的末期 ,都需要对本次迭带进行评估, 并计划下一次迭代 。 初步用例模型 。 综上所述 ,起始阶段的制品要尽可能简单, 是否采用形式化方法则要根据需求的规模而定。

2 加工阶段(Elaboration)

加工阶段的目标是固定系统架构 ,从而为构造阶段的设计和分析活动打下坚实的基础。架构的演化 第 20 卷第 3 期 王建一 一种适用于小型项目并集成 XP 的 RUP 软件过程 39 取决于最显著的(也是对架构影响最大的)需求和对风险的评估。架构的稳定性则要参考一些架构模型。 RUP 和 XP 中设计架构的方法非常不同。 RU P 认为, 必须考虑到时间的推移, 项目的扩大以及新技 术的使用所带来的风险 。XP 则多采用已有架构 ,或认为架构足够简单可以随着对代码的重构进行演化。 XP 建议, 与其为了未来的可能进行设计, 不如仅仅实现当前的需求 。对于一些系统, 这是比较现实的做 法 ;但是对于一些更大 ,更复杂的系统 ,这就未必行得通。

2. 1 活动

定义、验证和固定架构 。在起始阶段已经根据风险列表确定了候选架构 。这里将着重于架构的可行 性 。伴随着这个活动, 通常还要对一些构件做出购买 、自行开发或是重用的决定。 精化视图 。随着对系统理解的深入, 通常会在加工阶段对视图文挡进行修改 ,这也要得到客户的认 同 。 创建构造阶段的迭代计划。 加工阶段也可以包括其它活动, 比如配置测试环境, 编写测试用例等等。

2. 2 制品

除了对上一阶段的制品进行必要的更新之外,加工阶段要完成的制品有 :软件架构文档 。包含了整个 项目所需的技术信息。 构造阶段迭代计划书。在加工阶段计划好构造阶段迭代的次数。每个迭代都包括其特定的用例 ,场 景等信息。

3 构造阶段(Construction)

构造阶段的目标是完成系统的开发。如果强调对资源、成本 、进度和质量的管理和控制 ,构造阶段从 某种意义上可以说是一个制造过程。这是一种从起始阶段和加工阶段的智力产品的开发活动, 到构造可 实施产品的开发活动的一种转换 。

3. 1 活动

资源管理和过程控制。 开发测试构件 。针对每次迭代, 开发满足用例、场景等功能的测试构件。包括单元测试和集成测试。 评估迭代 。 测试优先 。程序员先写测试后写代码 。测试可以反映用例 ,并迫使你更深刻地理解它。要确保在每 次代码改动后运行测试代码 。重构 。在不改变系统行为的前提下 ,不断调整系统的结构 ,使其更加简单灵 活 。编程搭档。 XP 认为这可以花更少的时间写出更好的代码 。当然, 这也受到许多因素的制约 。简化设 计 。伴随着重构, 不断修改系统以降低复杂度。编码约定。采用什么标准并不重要, 关键是大家都愿意使 用它。

3. 2 制品构件

一个构件可能是一段软件代码(不管是源代码 ,二进制代码还是可执行代码),也可能是包含了 一段信息的文件, 或者是一些构件的集合。 培训材料 。对于用户界面比较复杂的项目 ,可以编写初步的用户说明书和培训材料。 实施计划书。描述了安装, 测试 ,移交时的一些工作 。 移交阶段迭代计划 。

4 移交阶段(Transition)

移交阶段着重于软件的发布 。包括在准备发布阶段对软件的测试 , 通过用户反馈而做的微小调整。 用户反馈要着眼于产品的调试、配置 、安装等问题。

4. 1 活动完成客户支持材料

在客户的环境中测试产品。尽可能模拟用户的环境 ,或带着产品到客户处安装以确保它正常工作 。 根据客户反馈对产品进行微调。可能的话 ,做几次β 发布。 40 安徽科技学院学报 2006 年 向客户移交最终产品。根据软件和发布的类型 ,有不少打包, 生产方面的细节问题 。 和其它阶段一样, 移交过程的形式,复杂度可能有所不同。然而如果不对实施细节加以重视, 就可能 会使几个月的努力付诸东流 。

4. 2 制品实施计划

完成构造阶段开始的实施计划书。 发布说明 。 培训材料和文档。 6 结论 构造软件系统决不仅仅是编写代码。软件开发过程 ,则是着重于能向用户提供满意产品的活动 。一 个完整的开发过程不必是复杂和面面俱到的。通过突出项目中的关键活动和制品 ,本文展示了一个小巧、 完整的开发过程。项目成功的关键在于规避潜在的风险 。如何根据项目的特点 ,定制恰当的软件开发过 程往往决定了项目的成败。

参考文献：

《一种适用于小型项目并集成XP的RUP软件过程》王建一

《XP 与 RUP 的比较与分析》易剑光等