RUP 方法简介

1.什么是RUP：

Rational Unified Process（以下简称RUP） 是一套软件工程方法，主要由 Ivar Jacobson的 The Objectory Approch 和 The Rational Approch发展而来。同时，它又是文档化的软件工程产品，所有RUP的实施细节及方法导引均以Web文档的方式集成在一张光盘上，由Rational公司开发、维护并销售，当前版本是5.0。RUP又是一套软件工程方法的框架，各个组织可根据自身的实际情况，以及项目规模对RUP进行裁剪和修改，以制定出合乎需要的软件工程过程。

RUP 吸收了多种开发模型的优点，具有很好的可操作性和实用性。从它一推出市场，凭借Booch、Ivar Jacobson、以及Rumbagh 在业界的领导地位以及与统一建模语言（Unified Model Language , 以下简称UML）的良好集成、多种CASE工具的支持、不断的升级与维护，迅速得到业界广泛的认同，越来越多的组织以它作为软件开发模型框架。

RUP是一种迭代的、以架构为中心 的、用例驱动的软件开发方法；RUP是一种具有明确定义和结构的软件工程过程，它明确规定了人员的职责、如何完成各项工作以及何时完成各项工作，以及软件 开发生命周期的结构，定义了主要里程碑和决策的关系；RUP也是一个过程产品，提供了可定制的软件工程的过程框架，支持过程定制、过程创作和多种类型的开 发过程，可通过装配过程产品得到过程配置。RUP配置可以用于不同规模的开发团队和规范程度不同的开发方法，RUP产品包含过程配置和过程视图，以指导项 目经理、开发人员、测试人员等角色协作开发软件

2. 二维的软件开发模型

传统的软件开发模型瀑布式开发模型是一个单维的模型，开发工作划分为多个连续的阶段。在一个时间段内，只能作某一个阶段的工作比如，分析、设计或者实现。

在RUP中，软件开发生生命周期根据时间和RUP的核心工作流划分为二维空间。

时间维从组织管理的角度描述整个软件开发生命周期，是RUP的动态组成部分。它可进一步描述为周期（Cycle）、阶段（phase）、Iteration(迭代)。核心工作流从技术角度描述RUP的静态组成部分，它可进一步描述为行为（activities）、工作流（workflow）、产品（artifact）、角色（worker）。

不同的工作流在不同的时间段内工作量的不同。值得注意的是，几乎所有的工作流，在所有的时间段内均有工作量，只是工作程度不同而已。这与Waterfall process(瀑布式开发模型)有明显的不同。

3.静态结构：方法描述

软件开发过程描述了什么时候，什么人，做什么事，以及怎样实现某一特定的目标。RUP采用以下四个基本模型元素组织和构造系统开发过程。

角色 : the who

行为 : the how

产品 : the what

工作流 : the when

角色描述某个人或一个小组的行为与职责。一个开发人员可以同时是几个角色，一个角色也可以由多个开发人员共同承担。RUP预先定义了很多角色，例如：Architect、Use-Case Designer、Course Developer、Implementer …，并对每一个角色的工作和职责都作了详尽的说明。

行为是一个有明确目的的独立工作单元。产品是行为生成、创建或修改的一段信息。它是行为的输入同时又是它的输出结果。产品以多种形式存在，例如：模型（Model）、源代码、可执行文件、文档等。

模型是从某一个角度对系统的完全描述。RUP的很大一部分工作就是设计和维护一系列的模型，这其中有Use Case Model、Business Model、Analysis Model、Design Model等。所有的这些模型都以UML描述，因此它们是标准的并为多种CASE工具支持。RUP并不鼓励写在字面上的文挡，产品应尽可能地在CASE工具中创建和修改并为版本管理工具跟踪和维护，它们在整个软件开发周期中动态地增加和修改。当然也可以根据需要为模型生成报告（Reports），但它们是静态的，是某一时刻模型的快照不需要维护和修改。

工作流描述了一个有意义的连续的行为序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。RUP主要提供两种组织工作流的方式：核心工作流（Core Workflow）和迭代工作流（Iteration Workflow）。

核心工作流从逻辑上把相关角色和行为划分为组，以描述RUP的逻辑组成部件。它们相当于模板一样，并不在开发过程中真正的执行。迭代工作流是RUP的一个具体的实现过程，它们对核心工作流进行裁剪，是核心工作流的具体实现。每类工作流都会同一个或多个模型打交道。

4、RUP的核心包含几个基本原理，它们支持应用迭代方法进行软件开发：
尽早并且不断的化解重大风险 
确保满足客户的需求 
把注意力集中放到可执行的软件上 
尽早在项目中适应变化 
在早期确定一个可执行架构 
使用构件构造软件系统 
建立高效团结的开发团队 
始终重视质量 
5、从管理角度观察RUP，即业务和经济方面，对应项目的进展，软件生命周期包括四个阶段：
起始阶段－构建最终产品的设想和业务案例，确定项目范围 
细化阶段－计划必要的活动和资源，详细确定功能并设计架构 
构建阶段－构建产品，直到一个可交付用户的产品完成 
移交阶段－产品交付用户，包括制造、交付、培训、支持、维护等

6、UP有九个核心的工作流

以下简单描述这些工作流的目的：

商业建模（Business Modeling）：理解待开发系统的组织结构及其商业运作，确保所有参与人员对待开发系统有共同的认识。

需求分析（Requirements）：定义系统功能及用户界面，使客户知道系统的功能，开发人员知道系统的需求，为项目预算及计划提供基础。

分析与设计（Analysis and Design）：把需求分析的结果转化为实现规格。

实现（Implementation）：定义代码的组织结构、实现代码、单元测试、系统集成。

测试（Test）：校验各自子系统的交互与集成。确保所有的需求被正确实现并在系统发布前发现错误。

发布（Deployment）：打包、分发、安装软件，升级旧系统；培训用户及销售人员，并提供技术支持。制定并实施beta测试。

配置管理（Configuration and Change Management）：跟踪并维护系统所有产品s的完整性和一致性。

项目管理（Project Management）：为计划、执行和监控软件开发项目提供可行性的指导；为风险管理提供框架。

环境（Environment）：为组织提供过程管理和工具的支持。

由于版面所限，无法详细解释每一个工作流。前六个核心工作流的名字，很可能使人们同Waterfall Process的顺序工作阶段相混淆。但我们知道核心工作流并不是具体的实现，而核心工作流中的某些行为有可能在软件开发周期中，一遍又一遍地在迭代工作流中得以细化。

从技术角度看，软件开发可视为一连串的迭代过程，通过迭代开发软件得以增量演进，每个迭代都以一个可执行的产品发布而结束，每次发布都伴随支持性工件：版 本描述、用户文档等。一次迭代可包括以下活动：计划、分析、设计、实现、测试，据其在开发周期的位置不同，所占比重也不同。

7、动态结构：迭代式开发

在时间维上，为了能够方便地管理软件开发过程，监控软件开发状态，RUP把软件开发周期划分为Cycles,每个Cycle生成一个产品的新的版本。每个Cycle都依次由四个连续的阶段(pahse)组成，每个阶段都应完成确定的任务。

起始阶段（Inception）：定义最终产品视图、商业模型并确定系统范围。

演化阶段（evaluation）：设计及确定系统的体系结构，制定工作计划及资源要求。

构造阶段（construction）：构造产品并继续演进需求、体系结构、计划直至产品提交。

8、RUP小型项目

敏捷方法考虑到迅速和紧密的增加或者阶段；减少开销；并且确保开发人员与客户之间的紧密联系。

      敏捷方法以及类似的方法（SCRUM，Paired Programming）在软件构建中是革新的、有用的。然而，在RUP中也可以使用敏捷方法。那些轻量级的方法可以很好地在新系统的构建阶段、解决方案，或者程序中得到运用；但是仍然需要管理其它三个阶段的上游和下游活动，比如决定需要做什么（需求）以及操作环境将受到什么影响（发布管理）。RUP并不关注先启阶段、细化阶段、构建阶段和产品化阶段所有业务原则的使用，事实上，它是为这些活动提供了一个最佳框架。

RUP以及类似的指导，比如PMBOK, 软件工程协会(SEI)的集成的能力成熟度模型 (CMMI)，或 UK 的 IT Infrastructure Library (ITIL)标准给小型项目强加了一些不必要的过程。他们其实仅适用于一千万以上的大型项目。

方法、知识体系，或者成熟模型不会强加过程。他们只为估算需要做什么，以及如何做得更好而提供一定的基础。“如何做”这部分是由实施组织来决定的。

PMBOK并没有规定2000版本中的39个过程或者2004版本中的44个过程在项目中都必须得到使用。它是一个知识体系，为项目管理者可能遇到的各种情况提供了一个起点。例如，它有助于定义组织的变更控制过程应该包括哪些内容。现在，项目管理专业人员（PMP®）在项目管理协会（PMI）监督之下，当然必须遵循PMBOK。PMI提供PMP资格认证，这样，聘用专业人员的组织机构就能够放心该专业人员懂得PMBOK。但是这并不意味着专业人员必须在每个项目中都使用到PMBOK的每一项知识。

SEI的能力成熟度模型（CMM）和CMMI从五个级别来评估并验证某组织的成熟度。按照SEI的规定，很清楚地评估和验证一个组织做什么，以及在某种程度上，他们如何完成。然而，这并不是规定一个“可重复过程”（二级）必须利用过程、工具和组织角色来完成。

相似地，“RUP的精髓”-- 以及已开发的许多实施RUP的工具 -- 培养逐渐细化的理念，即增量开发的本质。RUP的观点是组织应当设计并构建部分而不是全部解决方案，需求是已知的。现实中，验证某特色或者系统是“受人欢迎的应用程序”（比如，想法），还是“失败”（比如，Coca-Cola's New Coke，自1984）的一个最有效办法就是将产品交付给用户。

应用RUP，探寻SEI CMM/CMMI评估，或者使用PMI PMBOK时，最佳实践是成体系地使用这些向导。例如，你应该首先懂得业务需要（a.k.a 需求），从本质的用例开始，基于那些用例和UML的强大功能进行建模。在2004年《The Rational Unified Process Made Easy》一书中，Per Kroll和Philippe Krutchen很好地描述了这个方法：

．．．人们采用RUP时最常出现的错误是使用太多工件或者做太多活动。过量使用RUP将会降低你的开发效率；RUP过程框架类似于自助餐，如果你还想保持健康和快乐，那么就不能吃光所有的饭菜。

转载请注明原文地址：http://www.cnblogs.com/chenliangcl/p/7363139.html