[转]比较 Rational Unified Process (RUP) 和 Microsoft Solutions Framework (MSF)

文档选项

将此页作为电子邮件发送

级别： 初级

Sandra Sergi Santos, 软件工程专家, IBM

2007 年 6 月 15 日

本文来自于 Rational Edge：Microsoft Solutions Framework 和 Rational 统一过程（Rational Unified Process ，RUP）都为软件开发团队提供过程指导，但您如何对二者进行比较呢？本文指出了两个框架主要的结构上的差别和相似之处。

Rational Edge 读者的新论坛

在本文的最后，您将找到一个特别为 Rational Edge 电子杂志的作者创办的新论坛的链接。准备添加一些您对在我们的网页上找到的本文或其他主题的想法。

如果您是过程工程师、过程分析人员，或者是想要为了组织的软件工作而将市场上可以买到的框架标准化的团队领导，那么本文很适合您。我的目标是指出 Rational Unified Process®，或 RUP® 和 Microsoft Solutions Framework (MSF) 之间的相似点和差别。

是的，两者都包含过程规程、角色、原则、最佳实践和工件。但在某些情况下，这些元素拥有不同的定义和用途。这意味着很难将 RUP 元素直接映射到 MSF 元素上，但尽管如此，我也可以提出相似之处，并且提供一些比较两个框架的方法。

RUP 和 MSF 的定义

目前 RUP 7.0 版将其本身定义为规程和阶段中安排的软件工程的过程。RUP 基于软件工程的最佳实践。除了包含开发过程中的所有基本元素（角色、任务、活动、工件、工作流）之外，RUP 展示了关于和软件工程相关的元素的广泛概念库。就像 Per Kroll 和 Philippe Kruchten 提到的，¹RUP 定义了一种迭代、以架构为中心，及用例驱动的软件开发方法。RUP 目前是 IBM Rational Method Composer 的一部分，您可以将过程环境按照您具体的组织需求来裁剪。您可以通过访问 IBM Rational 网站来更多地了解 RUP。²

目前的 MSF 4.0 版将其本身定义为一种定义了一组已经由 Microsoft 证明了的规则、模型、规程、概念、指导和实践的开发项目的方法。Microsoft 没有将 MSF 分类为方法，相反，MSF 是作为软件开发的大范围的指导，以及大量的最佳实践。³

第一印象：从 MSF 到 RUP 的高层的映射

首先，映射两个框架似乎是微不足道的事 —— 就是分析阶段、里程碑、迭代和工件的问题。但是进一步观察阶段和规程的整个分类，会发现该映射不是那样直接的。让我们考虑两种在高层上比较两个框架的方法。

一种方法

由于两种框架使用了类似的术语，所以我们可能总想将软件开发的 RUP 生命周期映射到 MSF 的迭代概念上：也就是说，1 RUP 开发周期 = 1 MSF 迭代。该比较将把每个框架中建立的四个阶段都等同起来，如下：

RUP Inception（初始） = MSF Envisioning（展望）
RUP Elaboration（精化） = MSF Planning（计划）
RUP Construction（构建） = MSF Developing（开发）
RUP Transition（产品化） = MSF Stabilizing（稳定化）及 MSF Deploying（部署）

MSF 描述了一个迭代过程，它指出对于小型且普通的项目，单个迭代就足够了，而对于较大的项目，在产品完成，且达到所需的质量之前，需要更多的迭代。我们可以说，每个 MSF 迭代都把其目标定为拥有所有必要工件的“最终”交付。

根据 RUP 所说的开发周期有多个迭代，且在每个迭代的末尾，我们都将拥有部分的“内部”或“外部”版本，而只有在开发生命周期的末尾，我们才会拥有带有完整工件的“最终”版本。

依我看，无论如何，这都是比较 RUP 和 MSF 的错误方法。

更好的方法

我相信比较这两个框架的更好方法要包括，将 RUP 迭代映射到 MSF 迭代上，这将导致把 MSF 阶段映射为 RUP 规程。该方法表明，在每个 RUP 迭代的末尾，我们将会有已经完成的外部版本，由于在 MSF 迭代的末尾，生成了“稳定”且“完整”的版本。

总之，就像我们看到的，映射不像我们想象的那样直接。如果我们有机会比较解决同一问题的两个项目，一个使用 MSF，而另一个使用 RUP，那么一个阶段接一个阶段的现象将不可能出现。

过程设想

比较 RUP 和 MSF 的另一个困难是关于不同的设想或过程模型。

简单的说，RUP 根据拥有迭代的阶段来描述开发过程。每个迭代都包含规程，其中有角色、任务和工件。在迭代的末尾，我们会得到迭代里程碑，而在每个阶段的末尾，我们会得到阶段里程碑。

阶段、迭代和规程的集合组成了完整的基于 RUP 的生命周期，如图 1 所示。在该生命周期的末尾，我们得到了“完整的”版本。

图 1：RUP 生命周期

相反，MSF 划分为两个不同的过程模型：“团队模型”和“过程模型”。两个模型都可以分类为根据生命周期中的团队和活动，可视化地表示项目安排的描述。“团队模型”定义了在项目中工作的人，及其各自的活动，而“过程模型”在高层次上，安排了项目活动的顺序。MSF 过程模型分为多个阶段，每个阶段都描述了一组副产品和应该达到的里程碑。

图 2：MSF 团队模型和过程模型

映射其他元素

RUP 和 MSF 定义的其他过程元素更容易比较。例如：

工件

MSF 使用通用的术语“可交付的产品”，而 RUP 定义了三种不同类型的“工作产品”：可交付的产品、工件和结果。大多数 MSF 的工件可以映射到 RUP 工件上。但是，反过来就不总是对的了，因为 RUP 拥有许多 MSF 中目前不存在的工件。

在 RUP 中，工作产品总是任务的结果，其中包含任务将如何执行的细节，而对于 MSF，工件是阶段的结果，没有那么多关于如何生产该工件的细节。

角色

RUP 和 MSF 之间的角色比较揭示出了这两个过程框架之间的主要差别之一。非常重要的是要识别出该术语“角色”所定义的不同概念。

MSF 中的团队模型，通称“团队角色”，是基于多组活动的，而 RUP 中所描述的角色是基于职责的。

如图 2 所示，MSF 有六个角色，并将它们定义为“团队角色”。这些可以映射到 RUP 角色上，表 1 中提供了一个这样的实例。RUP 有与开发规程相关的更大量的角色（商业建模、需求、分析 & 设计、实现、测试，部署）并支持规程（配置及变更管理、项目管理和环境）。

尽管有这些差别 —— 也就是，MSF 中的角色定义没有 RUP 中的角色描述详细 —— 但执行两个框架之间的角色映射也是可能的，如表 1 中的测试实例所示。

表 1：MSF 和 RUP 之间的测试角色映射

MSF 团队角色	RUP 角色
测试	测试分析人员
	测试设计师
	测试经理
	测试人员

规程

对于 MSF，单词“规程”指的是比 RUP 中更加全面和一般的过程集合。RUP 将规程与开发过程的“步骤”相关联，而这些被分为不同的主题，如下一部分中所描述的。

表 2 展示了 MSF 和 RUP 中被分为规程类的内容。

MSF 规程

项目管理
风险管理
预备管理

RUP 开发规程

商业建模
需求
分析 & 设计
实现
测试
部署

支持规程

配置和变更管理
项目管理
环境

活动、任务和步骤

两个框架的活动、任务和步骤之间没有直接的映射。RUP 中的一个“活动”与带有任务安排的工作流相关联。

RUP 活动中的每项任务的步骤都很详细。这意味着，在 RUP 中，我们拥有关于过程将“如何”执行的较大量的细节。图 3 展示了需求规程中 RUP 工作流的实例。对于每个活动，我们可以深入到任务、角色和步骤的更多细节上。对于大多数 RUP 规程来说，您将会找到展示了经常一起执行的任务分组的图，如图 4 所示。

图 3：说明了 RUP 需求规程的活动图

图 4：RUP 需求规程中的典型活动

相反，MSF 以更表面的方式，为三个规程中的每一个规程定义了工作流。事实上，这些工作流简单地称为“过程步骤”，如图 5 所示。

图 5：MSF 预备管理规程中的过程步骤

其他关键的概念

出于本文的原因，我将不会详细地讨论两个框架剩余的关键概念。然而，值得提到的是 MSF 关键概念 Customers、Stakeholders、 Solution、Baselining、Scope 和 Tradeoff 在 RUP 中命名不同。这应该不会引起任何混乱，但 RUP 术语对类似的关键概念使用了不同的名称。特别是 RUP 将方法元素定义为关键概念，而主要的是“角色”、“工作产品”和“任务”。

原则

再次说到，RUP 和 MSF 原则之间应该不存在混乱。事实上，人们可以证明两种框架都是基于相似的原则。

MSF 使用八条原则：

• 培养开放的交流
• 为共同的目标工作
• 授权团队成员
• 建立清晰的责任，及共享的职责
• 关注商业价值的交付
• 保持灵活，预计变更
• 为质量进行投入
• 吸取所有经验教训

作为过程框架，RUP 是迭代的、以架构为中心的，并且是用例驱动的。这融入进 RUP 的六条原则中：

• 适应过程
• 平衡相互竞争的涉众优先权
• 跨团队合作
• 迭代地证明价值
• 提升抽象层次
• 持续地关注质量

结束语

我们可以说 MSF 和 RUP 在某些方面不同，而在其他方面相象。RUP 拥有更大量的与开发过程相关的细节和内容，而 MSF 以不太详细，更一般的方式来对待类似的概念。

一个要提到的重点是，MSF 有两个公共的裁剪，一个用于 Agile，一个用于 CMMI。对于 RUP 来说，有针对小项目或大项目的裁剪，还有针对不同需要的其他裁剪 —— 举例来说，RUP for SOA Governance、RUP for COTS 开发、RUP for Java 及 .Net 环境，等等。

我们可以说，RUP 是一个完整的过程框架，因为它描述了谁做什么、在什么时候，以及怎样做。MSF 和 RUP 之间的一个主要差别是与“怎样做”相关的 —— 换句话说，MSF 常常不提供关于如何达到特定目标（制造工件、执行任务）的指导。例如，MSF 说，您必须执行功能规范，但并没有指出应该使用什么技术，什么符号，等等。

两种框架都极力倡导早点减小风险。在这一点上，RUP 通过展示用例和架构稳定性的优先化技术来提供广泛的指导。

致谢：

特别感谢 Ricardo Balduino 帮助将本文从原来的葡萄牙语翻译过来，并且感谢 Ricardo 和 Scott Ambler 仔细的技术检查。

注释

¹ Per Kroll 和 Philippe Kruchten， Rational Unified Process Made Easy，Addison-Wesley Professional：2003。ISBN-10：0321166094。

² IBM 网站的 “Process and Portfolio Management” 部分提供了大量参考资料。要了解 Rational 统一过程的具体细节，请阅读这里的文章：Rational 统一过程 —— 软件开发团队的最佳实践

³ 要了解更多关于 MSF 的信息，请访问 Microsoft TechNet Microsoft Solutions Framework 页面。

回页首

参考文献：

IBM Rational 统一过程（IBM Rational Unified Process）资源页面

MSF 过程模型（MSF Process Model）

Microsoft Solutions Framework 3.0 —— 概述

现在对本文进行讨论！

尊敬的读者：现在开办了一个特别为 Rational Edge 的文章创办的新论坛，现在您就可以分享您对本文或本期杂志或以前杂志中的其他文章的想法。阅读世界各地您的同行们所说的内容，生成您自己的讨论，或者加入正在进行的讨论。单击 这里开始。

参考资料

• 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
• 您可以参阅 Rational Edge 电子月刊中文版 的其他文章。

关于作者

		Sandra Sergi Santos 毕业于 Mackenzie University，并且在巴西圣保罗的 Fundação Armando Álvares Penteado 完成了她的研究生工作。她已经在软件开发领域工作过十五年了，在金融和电信部门中拥有行业经验，而且她是 IBM Rational 工具实施和项目协调工作中的过程专家。她拥有 Project Management Professional 和 Scrum Master 认证，还在取得了 IBM Rational Unified Process、IBM Rational SCM Tools 和需求管理方面的认证。她目前是 IBM Brazil Rational 品牌的软件工程专家，您可以通过 ssergi@br.ibm.com 联系到她。