Rational统一过程概览
摘要
Rational Unified Process(Rational统一过程，简称RUP)是由Rational软件公司开发的一套软件过程框架，很多通过CMM认证的软件公司都采用RUP对其软件开发过程进行规范和改进。在当前国内软件行业对CMM给于极大关注的时候，理解、借鉴并采用业界认可的软件过程也是很有必要的。本文主要介绍RUP的主要内容，包括包括开发阶段、核心工作流以及迭代过程等。
关键词
RUP 阶段 里程碑 迭代 核心工作流
前言 软件过程的含义及其意义
什么是软件过程？概括地讲，软件过程是指实施于软件开发和维护中的阶段、方法、技术、实践及相关产物(计划、文档、模型、代码、测试用例和手册等)的集合。
那么，软件过程对于软件企业来说有什么重要意义呢？行之有效的软件过程可以是提高软件企业的开发效率：首先，通过理解软件开发的基本原则有助于对软件开发过程中一些重要的问题作出明智的决定；其次，可以促进开发工作的标准化、促进项目小组之间的可重用性和一致性；第三，它提供了一个可以使软件企业引进行业内先进实践技术的机会，这些技术包括代码检测、配置管理、变更控制以及体系结构建模等等。有效地软件过程还有助于改进软件企业的软件维护和技术支持等工作：首先，它定义了如何管理软件的变更并将这些变更的维护工作适当地分配到软件的未来版本中，这样使整个变更的过程无缝地进行；其次，它定义了如何将软件产品平稳地过渡到运行实施和技术支持阶段以及如何有效地开展这些工作。
对于软件企业而言，有必要采用某种业界认可的软件过程，或是利用新的技术改进自身业已存在软件过程。因为现在的软件规模越来越大，复杂程度越来越高，在软件的开发和维护过程中缺乏有效管理和控制对于一个软件企业的成功是非常不利的。不仅仅是软件变得更复杂，现在的软件企业也通常需要同时进行多个软件的开发，需要对项目进行有效地管理。今天，我们需要的软件应该是交互性的、国际化的、用户友好的、高处理效率的、高可靠性的系统，这就要求软件企业提高产品的质量并且最大可能地实现软件复用，以较低的成本和较高效率的完成工作。行之有效的软件过程为实现这些目标提供的基础。目前，行业内有多种成熟的软件过程可供借鉴，比较具有代表性、采用较广泛的软件过程主要包括以下几种：
l Rational Unified Process（RUP）
l OPEN Process
l Object-Oriented Software Process(OOSP)
l Extreme Programming(XP)
l Catalysis
l Dynamic System Development Method(DSDM)
本文将对RUP的核心内容，包括开发阶段、核心工作流以及迭代过程等进行讨论。
RUP是由Rational软件公司开发的一种预定义好的软件过程框架，它作为Rational Suite Enterprise套件中的一个组成部分以Web文档的形式发布，此套件中包括著名的UML建模工具Rose以及多种用于软件开发各个阶段的辅助性工具。RUP的主要创始人是面向对象领域中最杰出的三位科学家，标准建模语言(UML)的缔造者——Booch、Rumbaugh和Jacobson。RUP的核心是Objectory Process，后者是Rational软件公司几年前合并Jacobson的Objectory Organization 时所获得的产品之一，之后Rational用其自己的过程对Objectory进行改进和增强，最终形成RUP。记得笔者第一次接触到RUP是读了出自三位大师之手的一本书(Addison Wesley出版的The Unified Software Development Process，此书的中译本正由机械工业出版社组织翻译出版，估计很快就可以看到了)，当时RUP的名称是“统一开发过程(Unified Development Process)”，不过后来将Rational的头衔加上成为“Rational统一过程”之后，不免让人觉得商业味道过浓。
图1所示的是RUP的开发模型，从中可以直观的看到RUP的整体框架组成，包括四个顺序的开发阶段(Phases)、九个核心工作流(Core Workflows)以及迭代(Iterations)式的开发过程。
图1 RUP的开发模型
RUP的开发阶段和里程碑
RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段(Transition)。每个阶段结束于一个主要的里程碑(Major Milestones)；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。RUP的开发阶段和各个阶段的里程碑如图2所示。
图2 RUP的开发阶段和里程碑
通过四个阶段的一次过程是一个开发周期(development cycle)；在四个阶段通过的每个过程都产生软件的一个改进型(generation)。除非软件中途夭折，它将重复同样的初始、细化、构建和移交阶段进入到下一个改进型，但这一次重点在不同的阶段。这些接下来的周期叫做进化周期(evolution cycles)。随着产品经历若干个周期，产生新的改进型，实际上也就是前面所提到的迭代式的开发过程，关于迭代将在后文中介绍。
1． 初始阶段
初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。
初始阶段结束时是第一个重要的里程碑：生命周期目标(Lifecycle Objective)里程碑。生命周期目标里程碑评价项目基本的生存能力。
2． 细化阶段
细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。为了达到该目的，必须在理解整个系统的基础上，对体系结构作出决策，包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。
细化阶段结束时第二个重要的里程碑：生命周期结构(Lifecycle Architecture)里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。
3． 构造阶段
在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。
构建阶段结束时是第三个重要的里程碑：初始功能(Initial Operational)里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版。
4． 交付阶段
交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。
在交付阶段的终点是第四个里程碑：产品发布(Product Release)里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。
RUP的核心工作流
RUP中有9个核心工作流，分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。
1． 商业建模(Business Modeling)
商业建模工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象模型中定义组织的过程，角色和责任。
2． 需求(Requirements)
需求工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。
3． 分析和设计(Analysis & Design)
分析和设计工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。设计类被组织成具有良好接口的设计包(Package)和设计子系统(Subsystem)，而描述则体现了类的对象如何协同工作实现用例(Use case)的功能。
设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化，该视图中省略了一些细节，使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高被创建模型的质量。
4． 实现(Implementation)
实现工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式(源文件、二进制文件、可执行文件)实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。
5． 测试(Test)
测试工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现, 识别并确认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。测试类似于三维模型，分别从可靠性、功能性和系统性能来进行。
6． 部署(Deployment)
部署工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。
7． 配置和变更管理(Configuration & Change Management)
配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录。
8． 项目管理(Project Management)
软件项目管理平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。
9． 环境(Environment)
环境工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。
RUP的迭代开发过程
RUP中的每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环，产生一个可执行的产品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统。
传统上的项目组织是顺序通过每个工作流，每个工作流只有一次，也就是我们熟悉的瀑布生命周期，见图3。这样做的结果是到实现末期产品完成并开始测试，在分析、设计和实现阶段所遗留的隐藏问题会大量出现，项目可能要停止并开始一个漫长的错误修正周期。
图3 传统的瀑布模型
一种更灵活，风险更小的方法是多次通过不同的开发工作流，这样可以更好的理解需求，构造一个健壮的体系结构，并最终交付一系列逐步完成的版本。这叫做一个迭代生命周期。在工作流中的每一次顺序的通过称为一次迭代。软件生命周期是迭代的连续，通过它，软件是增量的开发。一次迭代包括了生成一个可执行版本的开发活动，还有使用这个版本所必需的其他辅助成分，如版本描述、用户文档等。因此一个开发迭代在某种意义上是在所有工作流中的一次完整的经过，这些工作流至少包括：需求工作流、分析和设计工作流、实现工作流、测试工作流。其本身就像一个小型的瀑布项目，见图4。
图4 RUP的迭代模型
与传统的瀑布模型相比较，迭代过程具有以下优点：
1. 降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
2. 降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早解决而不至于在开发后期匆匆忙忙。
3. 加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
4. 由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。
RUP中的人员、活动和产物
RUP框架中还有一些非常重要的方面没有在图1中体现出来，主要包括人员(Workers)、活动(Activities)和产物(Artifacts)。这三者实际上是紧密相关的，人员是一种抽象的角色定义，可以是一个人或是由若干人组成的小组。在RUP中定义的人员主要有这么几类：分析人员、开发人员、测试人员、管理人员以及其他辅助人员，每种类型中还有进一步的细分。每种类型的人员要执行一系列相关的活动，这些活动紧密相关并具有功能性耦合。活动与产物也紧密相关，产物是最终的或者是中间工作产品，它们在项目过程中产生并被使用，产物为活动提供输入和输出并提供了在活动之间进行信息交换的机制。RUP中的产物可以是文档，例如业务案例或软件结构文档；可以是模型，例如用例模型或者设计模型；也可以是模型元素，也就是在一个模型之内元素，例如一个类，或一个子系统，等等。为了使整个系统的开发具有可管理性，产物通常按照相应的核心工作流组织成集合。
人员、活动、产物以及下文将要介绍的工作流结合在一起描述整个开发过程的静态结构，RUP中关于人员、活动和产物的分类和定义可以说非常细致，在实际的应用中可能根本用不到这么细致的分类，可以根据具体的情况进行选择，能够满足项目的要求即可。限于篇幅，这部分的内容就简单介绍这些，有兴趣的朋友可以参阅RUP的文档，理解起来还是比较容易的。
RUP的主要优点及不足
总的来说，RUP具有不少优点：首先，它基于诸如迭代开发、需求驱动以及基于构架的开发等一些合理的软件工程准则；其次，它提供了将管理的可见性引入开发过程的机制，例如每次迭代结束时的工作原型以及在每个阶段末尾的是否继续的决策点等等。同时，它在可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础并建立了简洁和清晰的过程结构，为开发过程提供较大的通用性；最后，Rational公司对RUP的热情以及资源的投入将会继续保持，目前最新版本是RUP 2001A。同时也要注意到RUP所存在一些不足： 首先，RUP只是一个开发过程，并没有涵盖软件过程的全部内容，例如它缺少关于软件运行和支持等方面的内容；其次，它没有支持多项目的开发结构，这在一定程度上降低了在开发组织内大范围实现重用的可能性。可以说RUP是一个非常好的开端，但并不完美。
结束语
软件的开发和维护随着其规模的扩大和复杂程度的升高变得愈加困难，我们需要优秀的人员、好的工具、完善的体系架构，同时也需要有效地软件过程。可以说软件过程是解决软件危机问题的一个十分重要的组成部分，然而却往往被忽视。今天，当我们的软件行业对CMM的实施给予极大地关注和热情的时候，摆在软件企业面前的首要任务就是形成规范的软件开发过程或是改进已有的但还不尽如人意的软件开发过程，包括RUP在内的受到业界认可的软件过程框架对我们来说是很好的选择。限于篇幅，本文只讨论了RUP，实际上这个讨论也是很肤浅的，谨希望能够抛砖引玉，让我们共同对软件过程给予更多的更深层次的关注。
