Rational统一过程（Rational Unified Process）

转自： http://blog.csdn.net/shadowyelling/article/details/7412336
和： http://www.ibm.com/developerworks/cn/rational/r-rupbp/

软件的生命周期就好比人的生命周期——从婴儿时期，幼儿时期，少年时期，青年时期，中年时期到老年时期以及最后死亡的过程一样，软件也有从生产期消亡期的过程。而统一软件过程就是在软件生命周期过程中以用例为驱动、构架为中心来进行一次一次的增量式的迭代，每次迭代都是以上一次迭代为基础并生成包括构件的源代码体、需求说明、测试用例等的制品。
每次的迭代又具体分为四个阶段：初始、细化、提交和转移，而在每个阶段又分为五个工作流：需求、分析、设计、实现和测试。统一软件开发过程是基于面向对象方法和UML统一建模语言的，用这种方法论来指导软件开发主要可以解决两个问题：1.软件复用问题；2.需求变化问题。

软件过程：将用户需求转化为软件系统所需要的活动的集合。

统一软件过程：不仅仅是一个简单的软件过程，而是一个通用的过程框架，可用于不同类型的应用系统、各种不同的应用领域、各种不同类型的组织、各种不同功能和规模的项目。它是基于构件（Component-based）的，即所构造的软件系统是由软件构件通过明确定义的接口相互链接所建造起来的。并且它使用统一建模语言（Unified Modeling Language，UML）来制定系统的所有蓝图。

1.特点

用例驱动、以构架为中心、迭代和增量的软件过程框架。

1）统一过程是用例驱动的

用户（User）：软件系统是为了解决用户的需求的，因此对于一个系统必须首先确定它的用户（User），即参与者。这个User不仅仅指人，也可以是其他系统。即用户是与系统进行交互的事物。

用例（User Case）：是用户对系统的业务需求，即用例是能够像用户提供有价值结果的系统中的一种功能。

所有的用户和用例组合在一起就是用例模型，它描述了系统的全部功能。用例图促使我们从系统对用户的价值方面来考虑问题，是站在用户的角度出发，以人为本。并且用例图不仅能确定用户的需求，还可以驱动系统设计、实现和测试的进行，也就是说用例可以驱动开发过程。用例驱动表明开发过程是沿着一个流——一系列从用例得到的工作流前进的：用例被确定、用例被设计、最后用例又称为测试人员构造测试用例的基础。

2）统一过程是以构架为中心的

什么是软件构架？

软件构架的作用与建筑构架所起的作用类似。软件系统的构架是从不同的角度描述即将构造的系统。

注意：软件架构（software architecture），是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。它描述的对象是直接构成系统的抽象组件，各个组件之间的连接明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，在面向对象领域中，组件之间的连接通常用接口来实现。

软件构架包含了系统中最重要的静态和动态特征。构架刻画了系统的整体设计，去掉了细节部分，突出了系统的重要特性，然而“究竟什么是重要的”部分依赖于判断，而判断由来自于经验，所以构架的价值也就依赖于执行该任务的人的素质，在构架的过程中可以帮助构架师确定正确的目标。

用例和架构之间是什么关系？

每一种产品都具有功能和表现形式两个方面，其中功能与用例相对应，表现形式与构架相对应。因此用例在实现时必须适应于构架，然而随着系统的发展，用例也在不断的进化，所以构架必须设计得使系统能够进化，不仅要考虑系统的初始开发，而且要考虑将来的发展。为了能够找到这样的一种表现形式（构架），构架师必须从全面了解系统的主要功能（即主要用例）入手，这些主要的用例构成了系统的核心功能。

构架应该遵循什么步骤？

首先，从不是专门针对用例的那部分架构开始，如平台，创建一个粗略的构架轮廓。

其次，着手处理已经确定重要的用例子集，这些用例代表着即将开发系统的主要功能，详细描述每一个用例，并通过子系统、类和构件来实现。随着用例的描述趋于完善，构架的更多部分便会显现出来，从而也使更多的用例趋于完善。

最后，迭代这个工程直到确信得到一个稳定的构架为止。

3）统一过程是迭代和增量的过程

软降开发是一项复杂的过程，因此可以将这些项目划分为切实可行并能够产生一个增量的迭代过程。

什么是迭代和增量？

迭代：工作流中的步骤；

增量：产品中增加的部分。

迭代的原则是什么？

为了获得最佳的效果，迭代过程必须是受控的（Controlled），也就是说他们必须按照计划好的步骤有选择地执行。

如何确定迭代过程中要实现的目标呢？

首先迭代过程就是用来处理一组用例的，这些用例组合起来就能够扩展所开发产品的可用性。其次迭代过程要解决最突出的风险问题。只有这样后续的迭代过程才能建立在前一次迭代过程的基础上。

迭代的过程是什么？

以选定的构架为向导，用构件来实现设计前期已经标识并详细描述好的有关用例。如果一次迭代达到了目的，就可以进入下一次迭代，如果一次迭代没有带到预期的目标，那么必须重新审核前面的方法，并尝试一种新的方法。

迭代过程
Rational Unified Process 的每个阶段可以进一步被分解为迭代过程。迭代过程是导致可执行产品版本（内部和外部）的完整开发循环，是最终产品的一个子集，从一个迭代过程到另一个迭代过程递增式增长形成最终的系统。
与传统的瀑布式方法相比，迭代过程具有以下的优点：
1）减小了风险
2）更容易对变更进行控制
3）高度的重用性
4）项目小组可以在开发中学习
5）较佳的总体质量

对增量的理解：一个增量不一定是对原有制品的增加，在生命周期初始期，增量是对最初简单设计的完善和改进；而在以后的阶段增量通常是对原有制品的增加。

3.统一过程的软件生命周期

统一过程的软件生命周期就是从软件的产生到消亡期间进行的一次次迭代，每次迭代都会产生一个产品版本，并且本次迭代是基于上次迭代的。

2.阶段：

统一过程主要分五个阶段：初始阶段(inception)，细化阶段(elaboration)，构建阶段(construction)，移交阶段(transition)，生产阶段(production)

2.1初始阶段

初始阶段的目标是为系统建立商业案例和确定项目的边界。
具体目标：
1 明确软件系统的范围和边界条件，括从功能角度的前景分析、产品验收标准和哪些做与哪些不做的相关决定
2 明确区分系统的关键用例（Use-case） 和主要的功能场景
3 展现或者演示至少一种符合主要场景要求的候选软件体系结构
4 对整个项目做最初的项目成本和日程估计(更详细的估计将在随后的细化阶段中做出)
5 估计出潜在的风险(主要指各种不确定因素造成的潜在风险)
6 准备好项目的支持环境

产出:
1 蓝图文档核心项目需求关键特色主要约束的总体蓝图
2 原始用例模型(完成10%～20%)
3 原始项目术语表(可能部分表达为业务模型)
4 原始商业案例,包括业务的上下文、验收规范（年度映射、市场认可等等），成本预计
5 原始的风险评估
6 一个或多个原型

2.2细化阶段

细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。
具体目标：
1 确保软件结构、需求、计划足够稳定；确保项目风险已经降低到能够预计完成整个项目的成本和日程的程度。
2 针对项目的软件结构上的主要风险已经解决或处理完成。
3 通过完成软件结构上的主要场景建立软件体系结构的基线。
4 建立一个包含高质量组件的可演化的产品原型。
5 说明基线化的软件体系结构可以保障系统需求可以控制在合理的成本和时间范围内。
6 建立好产品的支持环境。

产出
1 用例模型（完成至少80％）– 所有用例均被识别，大多数用例描述被开发
2 补充捕获非功能性要求和非关联于特定用例要求的需求
3 软件体系结构描述_可执行的软件原型
4 经修订过的风险清单和商业案例
5 总体项目的开发计划，包括纹理较粗糙的项目计划，显示迭代过程和对应的审核标准
6 指明被使用过程的更新过的开发用例
7 用户手册的初始版本（可选）

2.3构建阶段

在构建阶段,所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详尽的测试。
具体目标：
1 通过优化资源和避免不必要的返工达到开发成本的最小化
2 根据实际需要达到适当的质量目标
3 据实际需要形成各个版本（Alpha,Beta,and other test release）
4 对所有必须的功能完成分析、设计、开发和测试工作
5 采用循环渐进的方式开发出一个可以提交给最终用户的完整产品
6 确定软件站点用户都为产品的最终部署做好了相关准备
7 达成一定程度上的并行开发机制

产出是可以交付给最终用户的产品。它最小包括：
1 特定平台上的集成产品
2 用户手册
3 当前版本的描述

2.4交付阶段

交付阶段的目的是将软件产品交付给用户群体。

3.开发过程中的静态结构(Static Structure of the Process)

开发流程定义了”谁”“何时”“如何”做”某事”。四种主要的建模元素被用来表达 Rational Unified Process：
* 角色(Workers),”谁”
* 活动(Activities),”如何”
* 产物(Artifacts),”某事”
* 工作流（Workflows），”何时”

角色、活动和工作产物：

1. 角色
   角色定义了个人或由若干人所组成小组的行为和责任。可以认为角色是项目组中个人戴的”帽子”。单个人可以佩戴多个不同的帽子。这是一个非常重要的区别。因为通常容易将角色认为是个人或小组本身，在 Unified Process 中，角色还定义了如何完成工作。所分派给角色的责任既包括某系列的活动，还包括成为产物的拥有者。
   

2. 活动
   某个角色的活动是可能要求该角色中的个体执行的工作单元。活动具有明确的目的，通常表现为一些产物，如模型、类、计划等。每个活动分派给特定的角色。活动通常占用几个小时至几天，常常牵涉一个角色，影响到一个或少量的产物。活动应可以用来作为计划和进展的组成元素；如果活动太小，它将被忽略，而如果太大，则进展不得不表现为活动的组成部分。
   活动的例子：

   • 计划一个迭代过程，对应角色：项目经理
   • 寻找 use cases 和 actors, 对应角色:系统分析员
   • 审核设计,对应角色:设计审核人员
   • 执行性能测试,对应角色:性能测试人员

3. 产物
   产物是被产生的、修改，或为过程所使用的一段信息。产物是项目的实际产品、项目产生的事物，或者供向最终产品迈进时使用。产物用作角色执行某个活动的输入，同时也是该活动的输出。在面向对象的设计术语中，如活动是活动对象（角色）上的操作一样，产物是这些活动的参数。
   产物可以具有不同的形式：

   • 模型，如 Use-Case 模型或设计模型
   • 模型组成元素,即模型中的元素，比如类,用例（use case） 或子系统般的元素
   • 文档,如商业案例或软件结构文档
   • 源代码
   • 可执行文件

4. 工作流
   仅依靠角色、活动和产物的列举并不能组成一个过程。需要一种方法来描述能产生若干有价值的有意义结果的活动序列，显示角色之间的交互作用。
   工作流是产生具有可观察结果的活动序列。
   UML 术语中,工作流可以表达为序列图、协同图，或活动图。在本文中，使用活动图的形式来描述。
   

4.核心工作流(Core workflows)

Rational Unified Process 中有9个核心工作流,代表了所有角色和活动的逻辑分组情况。

9个核心的过程工作流:
核心工作流分为6个核心”工程”工作流:

1. 商业建模工作流
2. 需求工作流
3. 分析和设计工作流
4. 实现工作流
5. 测试工作流
6. 分发工作流

和3个核心”支持”工作流

1. 项目管理工作流
2. 配置和变更控制工作流
3. 环境工作流

4.1需求工作流

需求工作流的目标是描述系统应做”什么”，并允许开发人员和用户就该描述达成共识。为了达到该目标，进行提取、组织、文档化需要的功能和约束；跟踪、为折衷方案及决定形成文档。
蓝图被创建，需求被提取。代表用户和其他可能与开发系统交互的其它系统的 Actor 被指明。Use case 被识别,表示系统的行为。因为use case 根据 actor 的要求开发,系统与用户之间的联系更紧密。系统展示了用于再生系统的用例模型：

样例用例模型：
每一个用例被仔细地描述。用例描述显示了系统如何与 actor 交互及系统的行为.非功能性的需求在补充说明中体现。Use case 起到贯穿整个系统的开发周期线索的作用。相同的用例模型在需求捕获阶段、分析设计阶段和测试阶段中使用。

4.2分析和设计工作流

分析设计工作流的目标是显示系统”如何”在实现阶段被”实现”的。你需要一个如下系统：
* 在特定的实现环境中完成用例描述中指定的任务和功能
* 满足了所有的需求
* 健壮的被建造（如果功能需求发生变化，易于更改）

分析设计结果是一个设计模型和可选的分析模型。设计模型是源代码的抽象；即设计模型充当源代码如何被组建和编制的”蓝图”。
设计模型由设计类和一些描述组成。设计类被组织成具有良好接口的设计包和设计子系统，而描述则体现了类的对象如何协同工作实现用例的功能。
下图是上例 use-case 模型的设计模型示例的一个部分:

设计活动以体系结构设计为中心。结构的产物和验证是早期迭代的主要焦点。结构由若干结构视图来表达，这些视图捕获了主要的构架设计的决定。本质上，结构视图是整个设计的抽象和简化，该视图中细节被放在了一旁，使重要的特点体现得更加清晰。结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高任何被创建模型的质量。

4.3实现工作流

实现阶段的目的：
* 定义代码的组织结构–以层次化的实施子系统的形式
* 实现类和对象–以构件的形式（源文件、二进制文件、可执行文件等）
* 将开发出的构件作为单元进行测试
* 对由单个实现者（或小组）产生的结构集成为可执行的系统

系统通过完成构件而实现。Rational Unified Process 描绘了如何重用现有的组件,或实现经过良好责任定义的新构件,使系统更易于使用,提高了系统的可重用性。
构件被构造成实施子系统。子系统被表现为带有附加结构或管理信息的目录形式。例如，子系统可以被创建为文件系统中的文件夹或目录，或 Rational Apex for C++ or Ada,或 Java中的包。

2.4.4测试

测试的目的是：
* 验证对象间的交互作用
* 验证软件构件的正确集成
* 验证所有需求被正确的实现
* 识别并确保载软件发布之前缺陷被处理

Rational Unified Process 提出了迭代的方法，意味着在整个项目中进行测试，从而允许尽可能早的发现缺陷，从根本上降低了修改缺陷的成本。测试类似于三维模型，分别从可靠性、功能性、应用和系统性能来进行。流程从每个维度描述了如何经历测试生命周期的几个阶段，计划、设计、实现、执行和审核。
另外，描述了何时及如何引入测试自动化的策略。使用迭代的方法，测试自动化是非常重要的，它允许在每次迭代结束及为每个新产品进行回归测试。