从IT方法论来谈RUP

在《从IT方法论来谈Scrum》中我谈到了6Ways方法框架，本篇仍用6Ways方法框架来概括的谈谈RUP方法。

　　软件开发过程描述了软件构造、部署和维护的一种方法。统一过程（Unified Process）是一种流行的构造面向对象系统的软件开发过程。RUP（Rational Unified Process）是对UP的详细精化，并且已经被广泛采纳。有些人可能一看到RUP提供这么多流程和工件，觉得不够敏捷，我认为RUP本身其实是一个方法框架，本身也可以采纳一些现在敏捷实践。采用什么方法重要，但采用方法后的执行更重要，对RUP来说，如果我们做得好就是敏捷，做不好就可能瀑布了。

The way of thinking

　　软件开发中成功的项目比例很少，原因很多，如：没有正确的理解用户需求、没有能力处理需求的改变、模块不能集成、软件很难维护和扩展、很晚才发现重要的项目缺陷、不好的软件质量、不能接收的软件性能等。基于导致项目失败的这些原因，RUP认为下面这些最佳实践可以改善软件的开发状况：

在早期迭代中解决高风险和高价值的问题不断的让用户参与评估、反馈和需求在早期迭代中建立内聚的核心架构不断地验证质量：提早、经常和实际的测试可视化软件建模（使用UML）仔细的管理需求实行变更请求和配置管理

The way of working

　　迭代是UP最重要的思想。RUP重要的概念之一：周期（cycles），如下图由多个周期构成一个软件开发生命周期。

　　对于每个周期，下图展现了更为详细的不同阶段（Phase）和流程：

四个阶段

构想和业务案例：描述高层的目标和约束、业务案例，并提供一个执行摘要用例模型：描述功能需求和相关的非功能需求补充规范：描述其他需求术语表：关键的领域术语风险列表和风险管理计划：描述业务、技术、资源和进度的风险，以及如何减轻这些风险或该如何应对原型和概念验证：阐明构想，验证技术问题。迭代计划：描述在第一次细化迭代中该作什么阶段计划和

软件开发

计划：对细化阶段的持续时间和工作量进行低精度的猜测。开发涉及的工具、人员、培训和其他资源开发案例：描述为本项目定制的统一过程的步骤和工件。在统一过程中，总需要为项目定制一些步骤或工件

细化阶段（Elaboration）：已精化的构想，核心架构的迭代实现，高风险的解决，大多数需求和范围的识别，更为现实的评估。（Lifecycle Architecture）

细化阶段不是一个需求或设计阶段，而是一个迭代实现核心架构并降低高风险的阶段

构造阶段（Construction）：迭代实现遗留下来的风险较低和比较容易的元素，准备部署（Initial Operational Capability）移交阶段（Transition）：beta测试，部署（Product Release）

多个流程

业务建模：在开发单独的应用时，业务建模包括领域对象建模。在从事大规模业务分析或业务过程再工程时，业务建模包括跨越整个企业的业务过程的动态建模。需求：对应用的需求分析，如写出用例和识别非功能性需求分析和设计：设计的所有方面，包括总体架构、对象、数据库、网络连接等。分析强调的是对问题和需求的调查研究，而不是解决方案。设计强调的是满足需求的概念上的解决方案，而不是其实现。分析和设计可以被概括为：作正确的事（分析）和正确的做事（设计）。实现：编程和构建系统，而不是部署系统测试配置和变更管理项目管理环境：指建立工具并为项目定制过程，也就是说，设置工具和过程环境。

　　1－5为核心工作流程，6－8为支持工作流程

The way of controlling

如何计划和管理迭代：需要多少迭代？每次迭代多长时间？每次迭代的目的是什么？如何跟踪每次迭代情况？

The Phase Plan (Project Plan)：一个粗略的计划，每个开发项目只有一份项目计划。包括了一个周期（cycle）内所有的环节（有时也可以包含多个周期）。计划包含主要里程碑的时间，要求的资源。如果能够明确分几个iteratio，则需要标识时每个小里程碑的时间和目的。

The Iteration Plan：迭代计划，包含当前迭代的详细计划，包括时间、任务和资源分配，在当前迭代后半期还需要包含下一个迭代的计划

风险管理度量

The way of modeling

RUP在不同流程中会由不同模型支持，下图为模型和流程对应图：

对于每个模型，RUP描述who在when时how做what。RUP使用五个主要元素来表达：

角色: the who

活动: the how

工件：the what

工作流: the when

规程（Disciplines）: 组合前面四种元素

下图为其中一个示例：

The way of supporting

Rational （现IBM）提供了对RUP的工具支持。

The way of communicating

　　RUP定义了一系列流程和工件，这些工作作为各角色间沟通的主要内容，用例和架构是RUP的两个重要内容。

用例驱动开发：使用用例表达需求，对业务进行描述。用例作为整个开发流程的基础。架构为中心流程：架构使用多个、协调一致的视图来表达系统，作为概念、构建、管理和演进系统的主要工件

其他

IBM Rational Unified Process

developerWorks 中国 RUP资源 RUP搜索

如何做一个成功的架构师——玩转RUP

Enterprise Unified Process(EUP) 一个RUP的扩展

Agile Modeling and the Rational Unified Process (RUP) EUP 引入了许多企业级别的规程，包括操作和支持以及七个企业规程：企业业务建模、组合管理、企业架构、战略重用、人员管理、企业管理、软件流程改进。RUP 与 EUP 之间的一个基本区别在于后者处理完整的 IT 生命周期。RUP 仅处理该生命周期的软件开发部分。

Making the Unified Process Work in Practice

The Agile Unified Process (AUP)

统一过程 UP/AUP/RUP 资源

RUP presentation

书籍

The Rational Unified Process: An Introduction, Third Edition

Applying UML and Patterns：An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition)

编写有效用例

UP和XP

UP建议增量的编写用例和非功能性需求文档（XP不是） UP建议在迭代开始，主要编程之前绘制更多的可视化设计图（例如耗时半天或一天），XP建议用一点点时间来做可视化设计（例如30分钟）