IBM Rational Unified Process®(或简称 RUP®)是一个完善的软件开发过程框架，它具有若干种即装即用的实例。源自 RUP 的过程范围很广，从满足短周期的小型项目需要的轻量级 RUP，到满足大型的、可能是分布式的项目团队需要的更加完备的过程。各种类型和规模的项目都已成功地使用了 RUP。本白皮书说明了如何在小型项目中以轻量级的方式应用 RUP。我们将要讲解如何在一个完整项目的上下文范围内应用极限编程(XP)技术。
摘要
IBM Rational Unified Process®(或简称 RUP®)是一个完善的软件开发过程框架，它具有若干种即装即用的实例。源自 RUP 的过程范围很广，从满足短周期的小型项目需要的轻量级 RUP，到满足大型的、可能是分布式的项目团队需要的更加完备的过程。各种类型和规模的项目都已成功地使用了 RUP。本白皮书说明了如何在小型项目中以轻量级的方式应用 RUP。我们将要讲解如何在一个完整项目的上下文范围内应用极限编程(XP)技术。
引言
一个小故事
一天早上，一名经理找到我询问我是否可以花几个星期为一家公司刚刚启动的投资建立一个简单的信息系统。我正厌烦手头的项目而渴望新项目启动带来刺激，于是我为这个机会欢欣雀跃--我快速开始行动，为新的伟大解决方案进行开发，而摆脱我工作的大型机构的官僚和手续的束缚。
事情在开始阶段进行得很顺利。在头六个月中，我都工作很长时间并且自得其乐。我的工作效率不可思议，并且一些工作堪称是我职业生涯中的杰作。开发周期是快速的，而且我每隔几周就可以完成系统中一些新的主要部分。与用户的交互过程简单而直接，我们都属于一个紧密联系的团队，而且可以免除一些手续和文档。也没有什么正式的设计;代码就是设计，设计也就是代码。一切都是这样的完美!
这种完美只持续了一段时间。随着系统开发的进行，我们需要开展更多的工作。现有代码随着问题的变更而必须进行完善，而且我们也相应精化了所需工作的概念。我雇了一些开发人员帮助进行开发。我们就像一个单元一样工作，经常对一些问题互相讨论。这加强了沟通同时也免除了形式。
一年过去了。
我们还在增加开发人员。整个团队从 3 个人到 5 个人，然后是 7 个人。每次增加人员时，都要花很长的时间来学习，如果没有经验，那么就很难理解和解释整套系统，即使是一个概览。我们开始使用白板图来更加正式地展示系统的整体结构、主要概念和接口。
我们仍然在使用测试作为验证系统是否满足需要的主要手段。很多新来的开发人员都站在用户的立场上，我们发现项目早期非正式的需求和个人联系已经不能满足需要了。我们花费了更长的时间来计划我们要建立的目标内容。结果由于我们保留了讨论的文字记录，而不用频繁地回想已经做过的决定。我们还发现描述需求和使用场景有助于向系统的新用户介绍情况。
系统的规模和复杂度不断增加，意外的情况发生了--需要清楚地描述系统的构架。在项目初期，构架大部分存于我的头脑中，后来潦草地记在笔记或活动挂图中。不过，随着项目的人员越来越多，构架有些失控。由于不是每个人都和我一样富有经验，他们无法发现某些变更对整个构架带来的影响。我们不得不使用更精确的术语定义对系统构架的约束。任何可能影响构架的变更都需要团队进行商讨，并且最终获得我的同意。我们绕了一圈后才发现了这个问题，接受了一些重大教训之后，这在真正认识到构架的重要性。
这是一段真实经历。它只讲述了这个项目中的一部分困难经历。这些经历只在一个方面是不同寻常的：我们中的一部分人从开始的最后一直在一起，时间一年有余。开发人员经常在一个项目中半途而来，没等结束就已经离开，丝毫看不到他们的所作所为带来的后续影响。
这个项目本该使用一些过程进行管理。过程太多会误事，但是不使用过程会带来新的风险。就像投资高风险股票的人仅仅看到高回报一样，几乎不使用过程 的项目组忽略了项目环境中的关键风险，其实是在"期望得到最好的结果，但是没有为最坏的情况做打算"。
概述
本文讨论了如何将过程应用到例如上文所述的项目中。我们的目的是为了得到使用过程的"恰当级别"。了解开发团队所面对的挑战以及其所处的来务环境，可以得出过程使用的恰当级别。如果我们理解了这些挑战，就可以使用刚好足够的过程来降低风险。不论是轻量级的还是其他，"一刀切"过程是不存在的。在以下内容中，我们来研究这一思想，即过程的恰当级别可以作为一个风险的函数。
我们集中讨论如何通过使用两个流行的方法得到过程的恰当级别：Rational Unified Process 或简称 RUP 以及极限编程(XP)。我们展示如何在小型项目中使用 RUP 以及 RUP 如何处理 XP 没有涉及到的领域。二者融合为项目团队提供了所需的指南--减少风险同时完成交付软件产品的目标。
RUP 是由 IBM Rational 开发的过程框架。它是一种迭代的开发方法，基于六个经过行业验证的最佳实践(参见 RUP 附录)。随着时间的推进，一个基于 RUP 的项目将经历四个阶段：起始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)、交付阶段(Transition)。每个阶段都包括一次或者多次的迭代。在每次迭代中，您根据不同的要求或工作流(如需求、分析和设计等)投入不同的工作量。RUP 的关键驱动因素就是降低风险。RUP 通过数千个项目中数千名 IBM Rational 客户和合作伙伴使用而得到精化。下图展示了一个典型迭代过程的工作流：
典型迭代流
作为风险如何影响过程的一个例子，我们应该考虑是否需要为业务建模。如果由于对业务的理解中没有考虑到一些重大风险，将导致我们所构建的系统是错误的，那么我们就应该执行一些业务建模工作。我们需要正式进行建模工作吗?这取决于我们的涉众--如果一个小团队将非正式地使用结果，那么我们也许只进行非正式的记录就可以。如果组织中的其他人也将使用结果或者查看结果，那么我们可能就要投入更大的努力，并且确保该结果的正确性和可理解性。
您可以定制 RUP 使其满足几乎任何项目的需要。如果没有满足您特定需要的即装即用的过程或路线图，您可以轻松地创建您自己的路线图。路线图描述了该项目如何计划使用过程，因此代表了该项目的特定过程实例。这就意味着，RUP 可以按需要变得简单或复杂，我们将在本文中详细解释。
XP 是一个用于小型项目中的以代码为中心的轻量级过程(参见 XP 附录)。它来自 Kent Beck 的创意，在大概 1997 年 Chrysler 公司的 C 3 工资单项目中得到软件界的关注。如同 RUP 一样，XP 也是基于迭代的，并且体现了诸如小规模发布、简单设计、测试以及持续迭代几项实践，。XP 为恰当的项目和环境引入了一些有效的技术;不过，其中也存在隐藏的假设、活动和角色。
RUP 和 XP 具有不同的基本原理。RUP 是过程组件、方法以及技术的框架，您可以将其应用于任何特定的软件项目，我们希望用户限定 RUP 的使用范围。XP，从另一方面来说，是一个具有更多限制的过程，需要附加内容以使其适合完整的开发项目。这些不同点解释了软件开发界的一个观点：开发大型系统的人员使用 RUP 解决问题，而开发小型系统的人员使用 XP 作为解决方案。我们的经验表明大部分的软件项目都处于两者之间--尽力找寻适用于各自情况的过程的恰当级别。单纯地使用两者之一是不充分的。
当您在 RUP 中融合了 XP 技术时，您会得到过程的正确量，既满足了项目所有成员的需要，又解决了所有主要的项目风险问题。对于一个工作于高信任环境中的小型项目团队，其中用户是团队的一部分，那么 XP 完全可以胜任。对于团队越来越分散，代码量越来越大，或者构架没有很好定义的情况，您需要做一些其他工作。在用户交互具有"契约"风格的项目中，仅有 XP 是不够的。RUP 是一个框架，您可以从 RUP 出发，在必要时以一组更健壮的技术来扩展 XP。
本文的以下部分描述了一个基于 RUP 四个阶段的小型项目。在每个阶段中，我们都确定了所产生的活动和工件 。虽然 RUP 和 XP 具有不同的角色和职责，但是我们在这里不会处理这些差异。对于任何组织或项目，实际项目成员必须在过程中与正确的角色关联起来。
项目启动-起始阶段
对于新的开发项目来说，起始阶段是很重要的，在项目继续进行前，您必须处理重要的业务与需求风险。对于那些增强现有系统的项目，起始阶段是比较短暂的，但是其目的仍是确定该项目的实施价值及可行性。
在起始阶段中，为了构建软件您可以创建业务案例。视图是起始过程中的关键工件。它是系统的高级描述。它为每个人解释该系统是什么、可能使用系统的用户、使用系统的原因、必须具备的功能，以及存在的约束。视图可能很短，也许只有一两段。视图往往包括软件必须为客户提供的关键功能。
下面的例子展示了一个项目的很短视图，该项目对 Rational 的外部网站进行了改造。
为使 Rational 的地位达到电子开发(包括工具、服务和最佳实践)的世界领先程度，可以通过动态的、个性化的网站加强客户关系，为访问者提供自助服务、支持和目标内容。新的过程和技术启用可以使内容供应商通过一种简化的、自动的解决方案加速发布并提高内容的质量。
RUP 起始阶段中 4 个重要活动为：
制定项目的范围。如果我们打算构建一个系统，我们需要知道其内容以及它如何满足涉众的需要。在这个活动中，我们捕获内容和最重要的需求的足够详细的信息，从而得出产品可接受的标准。
计划并准备业务案例。我们使用视图作为指导，定义风险缓和策略，开发起始的项目计划，并确定已知成本、日程计划，以及盈利率平衡。
综合得出备选构架。如果正在计划中的系统没什么新颖性，而且使用的框架广为人之，那么您可以跳过这一步。我们一旦知道客户的需求，就要开始分配时间研究可行的备选构架。新技术能够带来解决软件问题的新的并且经过改进的解决方案。在过程的早期花些时间评估购买还是创建系统，并选择技术，也可以开发出一个起始原型，这些都可以减少项目的一些主要风险。
准备项目环境。任何项目都需要项目环境。不论您使用 XP 技术(例如结对编程)，还是较传统的技术，您都需要确定团队将要使用的物理资源、软件工具以及步骤。
进行小型项目开发时，并不需要太多的"过程时间"来执行起始过程。您往往可以在几天中或者更少的时间里完成，下面的内容说明了本阶段除了视图之外的预期工件。
一个经批准的业务案例
涉众有机会从业务的角度认定项目是值得进行的。RUP 和 XP 都承认最好在早期就得出项目是否值得进行的结论，以免在一个注定将要失败的项目中花费宝贵的资源。如同在"Planning Extreme Programming" 一书描述的那样，XP 对于项目是如何形成的以及涉及哪些角色这两个问题的回答是比较模糊的(似乎在现有项目或系统的环境中是最清晰的)，但是在研究阶段，XP 处理的工件与 RUP 起始过程中的是相同的。
不论您在 XP 中非正式地考虑业务问题，还是在 RUP 中将业务案例做成一流的项目工件，您都需要考虑这些问题。风险清单您应该在整个项目开发过程中都保持记录 Risk List(风险清单)。使用有风险清单可以是一个具有经过计划的风险缓和策略的简单清单。为各个风险设定优先级。任何与项目有关的人员都可以随时看到风险的内容以及如何处理风险，但是没有提供解决风险的一般方式 。
初步项目计划
本计划包括资源估算、规模以及阶段计划。对于任何项目，这些估算都是不断变化的，您必须监控它们。
项目验收计划
您的计划正式与否依赖于项目的类型。您必须判断客户会如何才能认为您的项目取得了成功。对于一个 XP 项目，客户会采取验收测试的形式。在更普遍的过程中，客户可能不会真正地进行测试，但是接受的标准必须直接由客户作出，或者由另一个角色作出，例如与客户直接接触的系统分析员。也可能存在其他的验收标准，例如创建最终用户文档和帮助，但是XP并不涉及此内容。
起始细化迭代计划
在基于 RUP 的项目中，在上次迭代的最后，您将详细计划下次迭代。在迭代的最后，您可以评估迭代开始时设立的标准。XP 提供了探监控与衡量迭代成功的一些优秀技巧。衡量标准是简单的，您可以轻松地将它们合并到迭代计划和评估标准中。
起始用例模型
虽然这听起来比较正式而让人望之却步，但是它却相当简单。用例与客户在XP中编写的"故事"相对应。其间的差异就是一个用例就是一套完整的动作，由参与者或系统外部的人员或事物发起，这正是用例的价值所在。用例可能包括若干个XP"故事"。RUP 为了定义项目的边界，推荐在起始过程中确定用户与角色。从用户的观点关注整套操作有助于将系统分为有价值的部分。这有助于判定恰当的实施特性，因此我们能够在每次迭代的最后向客户交付一些成果(可能在起始迭代与细化迭代早期除外)。
RUP 与 XP 都可以帮助我们确保避免一种情况，即整个项目已完成 80%，但都不是可交付的形式。我们一直希望发布的系统对用户都是有价值的。
在这一点上，用例模型在识别用例和参与者方面几乎没有或只有很少提供支持的细节。它可以是手工或使用工具绘制的简单的文本或者 UML(统一建模语言)图。该模型帮助我们确保已经包含了涉众所关心的正确的功能，并且没用忘记任何功能，并允许我们轻松地查看整个系统。用例根据若干因素设定优先级，这些因素包括风险、对客户的重要程度以及技术难点。起始阶段中不需要过于正式的或过大的工件。按照您的需求让它们保持简单或者正式就可以。XP 包括对计划与系统验收的指南，但是 RUP 需要在项目的早期添加更多的一些内容。这些少量添加可能通过处理一套更完整的风险而为项目提供很大的价值。
细化阶段
细化阶段的目标是为系统构架设立基线，为在构建阶段大量的设计与实施工作打下坚实的基础。构架通过考虑最重要的需求(那些对系统构架影响最大的需求)与评估风险演进而来。构架的稳定性是通过一个或多个构架原型进行评估的。
在 RUP 中，设计活动主要关注系统构架的概念，对于软件密集型的系统来说，就是软件构架的概念。使用组件构架是在 RUP 中体现的软件开发 6 项最佳实践其中之一，该实践推荐在开发与所作所为构架上要投入一些时间。在这项工作花费的时间可以减缓与脆弱的、僵化日系统有关的风险。
XP 使用"隐喻"替换了构架的概念。隐喻只捕获构架的一部分，而其余构架部分则随着代码开发的自然结果而演进。XP假定构架的形成是从生成简单的代码开始，然后进行持续的代码重构。
在 RUP 中，构架不只是"隐喻"。在细化阶段中，您构建可执行的构架，从中可能降低与是否满足非功能性需求相关的许多风险，例如性能、可靠性以及健壮性。通过阅读XP文献，很可能推断出一些 RUP 为细化阶段所描述的内容，尤其是过于 XP 所称的基础设施的过分关注，都是徒劳无功的。XP 认为在没有必要的情况下创建基础设施所做的工作导致了解决方案过于复杂，并且所创建的结果对客户没有价值。在 RUP 中，构架与基础设施不是等同的。
在 RUP 与 XP 中创建构架的方法是截然不同。RUP 建议您关注构架，避免随时间变化而产生的范围蔓延、增加项目规模以及采用新技术带来的风险。XP 采用足够简单或是很好理解的现有构架，该构架能够随着代码而演进。XP 建议您不要为明天而设计，而要为今天而实施。XP 相信如果您尽可能地保持设计简单，那么将来管理起来也轻而易举。RUP 希望您考虑该主张带来的风险。如果系统或者部分系统在未来不得不重写，那么 XP 认为这种举措比现在就计划这种可能性更明智而且花费更少。对于一些系统，这是千真万确的，而且使用 RUP 时，在您细化阶段考虑风险也会得出同一结论。RUP 并不认为对于所有系统这都是正确的，而且经验表明对于那些较大型、较复杂和没有先例的系统来说，这可能是灾难性的。
虽然为未来的可能性(可能永远不会生生)花费太多的精力可能是一种浪费但是对未来进行足够的关注不失为一件精明之举。多少公司能花得起代价不断重写或者甚至是重构代码呢?
