|
|
在《从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的两个重要内容。
- 用例驱动开发：使用用例表达需求，对业务进行描述。用例作为整个开发流程的基础。
- 架构为中心流程：架构使用多个、协调一致的视图来表达系统，作为概念、构建、管理和演进系统的主要工件
其他
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)
书籍
The Rational Unified Process: An Introduction, Third Edition
UP和XP
- UP建议增量的编写用例和非功能性需求文档（XP不是）
- UP建议在迭代开始，主要编程之前绘制更多的可视化设计图（例如耗时半天或一天），XP建议用一点点时间来做可视化设计（例如30分钟）
it知识库：从IT方法论来谈RUP，转载需保留来源！
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
