从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）和流程：

四个阶段

初始阶段（Inception)：预见项目的范围、构想和业务案例 （Lifecycle Objective）
初始阶段不是一个需求阶段，而是类似与可行性阶段，项目相关人员是否就项目的构想达成基本的一致，项目是否值得继续进行认真的研究 时间不应超过一周，只需要确定这个项目是否值得认真研究，而不是真正去深入研究项目（这个工作留待细化阶段进行）如果预选就决定项目必须进行，而且项目明显是可行的，那么初始阶段会很短，可能只包含一次需求研讨会，并为第一次迭代执行计划，然后就快速的进入细化阶段 主要实践活动－用例建模 对于迭代开发的一个关键理解在于：过程中的工件在初始阶段只是部分完成，在之后的迭代中在逐步精化提炼。例如，用例模型可以列举大多数所需的用例和参与者，但其中可能只有10％的用例会被详细描述，这样就足以建立起有关系统的范围、目标和风险的高层的大致构想。 主要工件：是否意味着大量的文档？工件是可选的，只需要从下面选择对项目确实有价值的工件，放弃哪些不必要的工件，工件的关键不是文档或图表本身，而是其中蕴含的思想、分析和前期准备。
构想和业务案例：描述高层的目标和约束、业务案例，并提供一个执行摘要 用例模型：描述功能需求和相关的非功能需求 补充规范：描述其他需求 术语表：关键的领域术语 风险列表和风险管理计划：描述业务、技术、资源和进度的风险，以及如何减轻这些风险或该如何应对 原型和概念验证：阐明构想，验证技术问题。 迭代计划：描述在第一次细化迭代中该作什么 阶段计划和

软件开发

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