RUP简介

RUP是Rational Unified Process的缩写，中译文为瑞理统一过程。

 

一、RUP简史

　　上个世纪80年代未至90年代初，面向对象方法学进入鼎盛时期，当时比较著名的面向对象方法学已有50多种。其表示法和分析设计方法各有特点，但是，这些方法学具有着一定的一致性和兼容性。于是，James Rumbaugh、Grady Booch以及Ivar Jacobson决心吸收各家所长，创建一个统一的方法学。最终在他们努力和推动下，诸多面向对象的方法学在表示法和分析设计理论上达成了一致，并先后推出了UML和RUP。2002年12月6日IBM宣布将以21亿美元现金收购Rational软件公司，此后不久Rational公司并入IBM麾下。由于Rational在面向对象方法学领域的强大号召力，Rational品版保留至今。

 

二、RUP是什么

　　首先，RUP是一套面向对象方法学。

　　RUP是以面向对象方法为基础的方法学，在业务建模、需求、分析设计、实现、测试等各个规程中，面向对象方法惯穿始终。即便是在与系统构建关系不大的业务工程中，RUP也使用OOA/D人员熟悉的面对象方法。因此，RUP更适合OO类项目。

　　RUP坚持以用例驱动，以架构为中心，迭代和增量的开发方法。用例驱动既做到了以客户为中心，以客户的角度看系统，为客户创建真正可用的系统的构造方式，又解决了传统面向对象方法面临的无法有效的从需求中提取对象的困难，从而填平了需求分析方法和对象设计方法之间的鸿沟。以架构为中心，坚持综合考虑软件系统的各个方面，并优先解决各个方面的主要问题，同时创建常见问题的通用解决方案，从而为解决软件项目的主要风险、准确估算项目进度、提高软件复用、保证软件的整体风格打下了坚实基础。迭代和增量式开发，以风险为驱动，分阶段针对不同的风险制定对策，以保证软件项目的成功完成。

　　除此之外，RUP还吸收了各家所长，以契约设计、测试驱动方法保证软件质量，以架构模式、设计模式增强系统的可扩展性和易维护性，以统一变更管理加强代码等资源质量，以组件架构提高软件复用等。

　　其次，RUP是一种适用范围较广的适应性软件过程。

　　它定义了进行软件开发的工作步骤，亦即定义了软件开发过程中的，什么时候做，做什么，怎么做，谁来做的问题，以保证软件项目有序地、可控地、高质量地完成。

    RUP是一种适应性软件过程，区别于瀑布模型类的预见性软件过程。RUP不假设从一开始就可以掌握软件开发的全过程，而是坚持以迭代方式推进软件开发，结合不断演进的项目状态和现实变化做出相应的调整，制定出新的计划。实践证明适应性过程比预见性过程更能保证项目成功。

　　另一方面，RUP并没有对软件开发的规范化程度做出明确规定。换言之，RUP允许我们根据项目的实际情况，对其进行裁剪，以决定哪些文档、过程是必须的。从而为我们在敏捷式开发和规范化开发的选择上提供了灵活性。这一点与以XP为代表的敏捷过程有所不同，后者除了强调适应性开发外，也强调尽可能减少文档数量和不必要的管理，以提高主要活动（即软件开发活动）的效率。目前，敏捷过程在产品周期短、变化快和规模相对小的项目中倍受推崇。对RUP做适度裁剪，轻装上阵，亦可成为敏捷过程。同理，对RUP进行调整也可以使其符合CMM或CMMI的要求，配置成规范化的过程，从而应对规模较大、相对复杂、但变化不快的软件项目。

　　最后，RUP本身也是一个提供了可定制框架的软件过程产品。

　　RUP提供了一个可定制软件产品，其中包括RUP方法学指导、过程定义和文档模板，也还包括一些示例工程。除此之外，为了支持RUP的方法学理论和最佳实践，Rational还提供了一系列CASE产品，如RequisitePro(需求管理)、ROSE(可视化建模工具)、ClearCase&ClearQuest(配置和变更管理工具)等。

 

三、实施RUP可以带来哪些好处

　　创建用户真正需要的系统，提高客户满意度。RUP以用例描述需求。用例以客户的角度看待系统，将系统需求描述为使用系统的业务办理过程，从而保证需求获取的正确性。此外，在开发过程中，RUP坚持用例驱动，在分析、设计、实现、测试等过程中，一直保持用例的完整性，从而为需求的正确实现提供了保障。

　　创建组件化架构，提高软件系统的复用程度。RUP以架构为中心来构建系统。架构关注软件系统的功能、设计、实现、运行结构、部署结构等诸方面的重点问题。其中，在逻辑模型中，RUP使用架构机制和分层等手段分别将通用机制组件和通用业务组件抽取出来，从而提高了系统的复用度。RUP以OO的方式组织系统，将复杂的业务逻辑划分成一个个相对隔离的子系统，并在子系统的层次上集成（而不是在数据层上集成），从而保证了子系统在不同系统间移植和复用。

　　以迭代开发不断处理重大风险，保证项目可控性。项目的可控性源于对未知的、重大且具有破坏性事件的掌握程度。而这些事件就是风险。RUP坚持风险驱动的开发方式，并以迭代开发优先处理对项目有重大影响的风险，从而不断增强项目的可预见性、可管理性，为项目的成功完成提供了保障。

　　以可视见化建模，增强组织内部的沟通。RUP使用可视化建模方式进行系统构建。可视化模型简捷、明快，忽略了不必要的细节，为人们掌握系统概要提供了方便的手段。RUP使用UML作为模型的表述语言，通过UML，能够将抽象的设计思路以可视化方式表述出来，增进了组织内部的沟通。

　　以持续的质量验证，提高软件质量。RUP坚持持续的质量验证。持续的质量验证，可以尽早地识别缺陷，以降低修复成本。以评估通过或测试通过作为任务的结束标准，可以使进度评估更客观。将测试集中在高风险的领域，可以提高软件质量。

　　以配置和变更管理，增强代码等资源的管理能力。RUP研究了开发过程中，隔离与集成之间的关系，制定了多种配置管理策略，从而既避免了并行开发中每人一个工作区时所带来的系统集成困难，也避免了共享工作区时所面临的互相干扰的问题。此外，RUP亦推荐基线策略，从而提高了系统代码及其它资源的可追溯性。RUP实行变更管理，从而可以避免需求蔓延和功能蔓延，也避免了不良变更对系统造成的冲击。

 

四、实施RUP将会面临哪些问题

　　RUP博大精深，初学者容易无所适从。RUP既是面向对象方法学，也是定义清晰的软件过程。RUP作为软件过程是以其方法学理论为基础的。在没有深刻理解其方法学的条件下实施RUP，将不可避免的流于形式，难以取得成效。RUP的方法学覆盖软件开发过程的各个领域，集各家精华于一身，在不断发展的过程中，相互融合。这使得初学者无论从任何一个方面切入，都难以窥其全貌，从而加大了RUP的学习难度。

　　RUP以面向对象为核心，长期以面向过程为核心的组织将面临广泛的调整。RUP定义了9个规程，其中6个是开发规程，3个是支持规程。面向对象方法在开发规程中贯穿始终，另外，支持规程也多以开发规程为基础。由此，可以看出RUP深深地烙上了面向对象的痕迹。在我们的组织中，面向过程的分析、设计及编程方式根深蒂固，这不仅体现在人员的工作方式上，也体现在我们的技术路线上。这里进行的不是面向对象方法和面向过程方法的优劣性比较，而是一种适用性比较。换言之，只有我们的组织、人员和技术路线及管理方式逐渐地做出相应调整，RUP才能为我所用。

　　RUP使用迭代式开发方法，高层组织需要有新的项目管理方法与之相适应。与上一问题类似，RUP使用迭代式开发方法，区别于瀑布模型类的预见性软件过程。而我们目前都是以瀑布模型的开发方式进行项目管理。这将影响使用RUP项目的开发。

　　RUP成功实施依赖于技能相对全面的人员，这将对组织的人才观形成考验。四五个人，三两条枪就可以做项目的日子，已经渐渐离我们远去。我们开始面临规模越来越大、周期越来越短、变化越来越快的项目。也正是因为这种项目才使我们决心进行过程改进，引入RUP。然而，RUP不是救世主，在它给我们提出解决方案的同时，也对我们的人员提出了更高的要求，以往似乎只有专家学者们才研究的AM、SOA、CBD、OOA/D、AOP、TDD、模式、契约设计等理论与实践，将会渐渐地走入架构师抑或是普通开发人员的视野。这将对组织的人才培养、招聘、考核等提出更高的要求。

五、如何在组织内成功实施RUP

　　首先，要将过程改进与商业价值联系起来。引入RUP进行过程改进，必须针对当前过程和组织的问题或目标来开展。这就意味着我们必须首先对过程、组织进行评估，发现问题、确定目标，有针对性的引入RUP中的相关实践。否则，RUP的实施就会没有方向、没有动力、成败与否也没有了衡量的标准。

　　其次，要坚持方法学优先、过程稍后的实施策略。RUP方法学是RUP软件过程的基石，没有方法学支撑的过程必然流于形式。因此，应该在组织中优先鼓励迭代开发、用例建模、OOA/D、测试驱动等方法的学习与实践。并在人员充分掌握了相关理论与实践的基础上定制和规范软件过程。

　　另外，要坚持RUP的渐进式实施策略。在以RUP为指导进行项目开发的过程中，应不断的实践各规程所对应的方法学，然而不宜操之过急，全面严格要求所有方面。应用RUP应坚持渐进式推进，针对组织目标，有侧重地推进相关实践。如首先推进迭代开发、需求管理，在对其已基本掌握之后，再逐渐强化组件架构、变更管理实践等。