一、摘要：
本文将比较Microsoft解决方案框架和Rational统一过程两个软件开发过程。在第二部分中，我们将简要介绍这两种过程方法。在接下来的第三部分中，我们先比较了二者的整体目标，接着从核心思想、过程模型、组队模型和准则四个角度对二者进行了比较，在每小节的结束位置，都进行了认真、细致的比较小结。在第四部分中，我们对两种软件过程方法从整体，模型，思想以及实际操作等角度进行总结。
二、介绍：
2.1 Microsoft解决方案框架
Microsoft解决方案框架（Microsoft Solutions Framework，以下简称MSF）是一种成熟的、系统的技术项目方法，它基于一套制定好的原理、模型、准则、概念、指南，以及来自 Microsoft 的、经过检验的做法。
MSF是一组建立、开发和实现分布式企业系统应用的工作模型、开发准则和应用指南。它帮助企业融合商业和技术的目标，降低采用新技术后系统整体的费用，以及成功的应用微软技术整合商业过程的方法。
按期并在预算范围内创建行之有效的业务解决方案需要一种经过检验的方法。Microsoft 解决方案框架提供了一个适应性的框架，用于以更快的速度、更少的人员、更少的风险来成功地交付信息技术解决方案，同时取得更高质量的结果。
MSF指出为成功设计、构建和管理技术基础结构或商业解决方案，所需了解的重要风险、重要的设计基础假设和关键的依赖关系。它包括明确的知识库、应用指南和实践经验。
2.2 Rational统一过程
Rational统一过程（Rational Unified Process，以下简称RUP）是软件工程的过程。它提供了在开发组织中分派任务和责任的纪律化方法。它的目标是在可预见的日程和预算前提下，确保满足最终用户需求的高质量产品。RUP可以提高了团队生产力。对于所有的关键开发活动，它为每个团队成员提供了使用准则、模板、工具指导来进行访问的知识基础。
RUP 的活动创建和维护模型。 RUP 强调开发和维护模型--语义丰富的软件系统表达，而非强调大量的文本工作。
RUP 能对大部分开发过程提供自动化的工具支持。它们被用来创建和维护软件开发过程（可视化建模、编程、测试等）的各种各样的产物--特别是模型。另外在每个迭代过程的变更管理和配置管理相关的文档工作支持方面也是非常有价值的。
RUP 是可配置的过程。没有一个开发过程能适合所有的软件开发。RUP 既适用小的开发团队也适合大型开发组织。RUP建立简洁和清晰的过程结构为开发过程家族提供通用性。并且，它可以变更以容纳不同的情况。它还包含了开发工具包，为配置适应特定组织机构的开发过程提供了支持。
三、比较
从目标角度上讲，二者似乎“不谋而合”。他们的目标都是在可预见的日程和预算前提下，确保满足最终用户需求的高质量产品，或者说是用于以更快的速度、更少的人员、更少的风险来成功地交付信息技术解决方案，同时取得更高质量的结果。
目标基本相同，那么需要关注的就是如何来实现这个目标了。在本章中，我们将从核心思想，过程模型，小组模型和原则四个角度进行分析比较。
3.1 核心思想――基础原理VS 最佳实践
无论是框架还是过程，它们都需要一些理论基础和铺垫。微软和IBM，这两个软件巨头，分别通过对他们长期的开发经验的总结，给出了他们的核心思想。
3.1.1 MSF 八个基础原理
MSF 的核心有八个基础原理：
1) 推动开放式沟通
2) 为共同的前景而工作
3) 赋予小组成员权力
4) 建立清晰的责任和共同的职责
5) 关注交付业务价值
6) 保持灵巧，预测变化
7) 质量投资
8) 学习所有的经验
这些原理共同传达了 MSF 观点，构成了一种统一方法的基础，这一方法用来组织项目所需的人员和过程，以便交付技术解决方案。它们是 MSF 结构和应用的基础。尽管每个原理都已经显示出了自身的优势，但是它们很多都是相互依存的，因为其中任何一个的应用都对另一个的成功起到了支持作用。在依次应用的时候，它们建立了一个稳固的基础，使得 MSF 能够很好地适用于规模、复杂程度和类型都不相同的多种项目。
3.1.2 RUP 六个最佳实践的有效部署
RUP描述了如何为软件开发团队有效的部署经过商业化验证的软件开发方法。它们被称为"最佳实践"不仅仅因为你可以精确地量化它们的价值，而且它们被许多成功的机构普遍的运用。为使整个团队有效利用最佳实践，RUP为每个团队成员提供了必要准则、模板和工具指导：
1) 迭代的开发软件
2) 需求管理
3) 使用基于构件的体系结构
4) 可视化软件建模
5) 验证软件质量
6) 控制软件变更
3.1.3 比较小结
相对而言，RUP更加是从准则、模板和工具指导的角度对整个理论进行了铺垫，它把整个软件工程分成了可以迭代的一些过程，并通过对这些过程的规范管理，实现它的最终目标。而MSF则更偏重于人的角度，对贯穿整个开发过程中的一些要素进行了强调，对小组和成员的行为进行了规范。
虽然他们的出发角度不同，但是最终实现的效果似乎有些异曲同工。都是对一些行为进行规范，无论是开发中的一些过程，还是成员的行为，都会最终落实到软件开发上去。很难评价孰优孰劣，但是有一点可以肯定地是：这些原理和有效部署，都是长期开发的经验结晶。无论是否采用这种开发过程管理软件，这些都值得我们去认真学习。
3.2 过程模型
过程模型，很大程度上讲，在瀑布模型和螺旋模型上已经基本成熟。后来的各种软件开发方法的过程模型，很大程度上都是对二者的结合，优化。MSF和RUP也基本是按照这个思路进行设计的。
3.2.1 MSF的过程模型
MSF 过程模型把来自传统的瀑布模型和螺旋模型的概念结合起来，并利用了两者各自的长处。过程模型把瀑布模型基于里程碑的规划的优势与螺旋模型不断增加的反复项目交付内容的长处结合了起来。
MSF过程模型解释了如何基于：范围、进度和资源，规划和控制面向结果的项目。它是基于四个可见里程碑交互的、允许修改的过程模型。
阶段和里程碑
MSF 过程模型以阶段和里程碑为基础。MSF 阶段是普通意义上的完成特定任务的一段时间。每个阶段都有其自身的特色，每个阶段的结束都代表了项目进展和中心点的变化。里程碑是检查和同步点，用来确定阶段的目标是否已经实现。里程碑为小组提供了明确的机会，以调整项目的范围，反映客户或者业务要求的变化，并解决项目过程中可能会出现的实际风险和问题。
下表给出了MSF过程模型的活动与里程碑
|
主要里程碑 |
模型区间 |
关键活动 |
|
想象性描述与范围确定被核准 |
想象 |
建立项目范围与用户需求 |
|
项目计划被核准 |
计划 |
开发功能详述与开发计划 |
|
完成所有交付物
首次使用 |
开发 |
完成设计 |
|
发布 |
稳定 |
完成系统测试 |
3.2.2 RUP的过程模型
在RUP中，开发过程是用二维结构或沿着两个坐标轴来表达：
l 横轴代表了制订开发过程时的时间，体现了过程的动态结构。它以术语周期（cycle）、阶段(phase)、迭代（iteration）和里程碑(milestone)来表达。
l 纵轴表现了过程的静态结构：如何用术语活动（activity）、产物(artifact)、 角色(worker)和工作流(workflow)来描述。
迭代模型图显示了过程的二维结构。
阶段和迭代--时间轴
 |
软件生命周期被分解为周期，每一个周期工作在产品新的一代上。RUP将周期又划分为四个连续的阶段。分别是初始阶段，细化阶段，构造阶段和交付阶段。开发过程沿时间进行动态组织。
每个阶段终结于良好定义的里程碑――某些关键决策必须做出的时间点，因此关键的目标必须被达到。每个阶段均有明确的目标。下图说明了各个阶段的目标和对应的里程碑。
|
|
阶段目标 |
里程碑 |
|
初始阶段 |
为系统建立商业案例和确定项目的边界 |
生命周期的目标 |
|
细化阶段 |
分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素 |
生命周期的结构 |
|
构建阶段 |
所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详尽的测试 |
初始运作能力 |
|
交付阶段 |
将软件产品交付给用户群体 |
产品发布 |
3.2.3 比较小结
由上面的介绍我们可以明显看出，MSF和RUP在过程模型设计的时候，都是结合瀑布模型和螺旋模型进行设计的。把瀑布模型基于里程碑的规划的优势与螺旋模型不断增加的反复项目交付内容的长处结合了起来。阶段和里程碑的概念在各自的模型里都有明确的定义。
与MSF不同的是，RUP并没有走螺旋模型的老路――它将螺旋型转化成了一个二维的结构，在这样的结构里，我们同样可以清晰地看到各种性质的工作的各个阶段中的工作量。
在这个二维结构里，RUP提出了迭代过程的概念。RUP 的每个阶段可以进一步被分解为迭代过程。迭代过程是导致可执行产品版本（内部和外部）的完整开发循环，是最终产品的一个子集，从一个迭代过程到另一个迭代过程递增式增长形成最终的系统。
与传统的瀑布式方法相比，迭代过程具有以下的优点：
1) 减小了风险
2) 更容易对变更进行控制
3) 高度的重用性
4) 项目小组可以在开发中学习
5) 较佳的总体质量
利用迭代过程和二维结构，RUP也成功地实现了瀑布模型和螺旋模型的成功结合。
3.3 组队模型
软件开发中除了“技术”要素以外，还有一个更加重要的因素，就是“人”。比起技术要素，人的因素更加的不好把握。因此，为了充分的发挥人在软件开发中的重要作用，我们需要有良好的团队，优秀的组队模型。
3.3.1 MSF的小组模型
MSF 小组模型定义了小组同级成员的一些角色和职责，这些成员都在以相互依存的跨学科角色进行信息技术项目工作。模型展示了如何组织项目队伍，在时间控制和连续不断发展计划的要求下，有效的交付系统的解决方案。它描述了六种基本的角色（程序管理、产品管理、开发、测试、系统实现和用户教育）。下面的图表对该模型的逻辑进行了描述。
MSF 小组模型基于这样一种前提，即任何技术项目都必须达到特定的关键质量目标才能够被认为是成功的项目。达到每个目标都需要相关的、不同技能及知识领域的应用，它们每一个都包括在一个小组角色群（通常被简称为角色）里。相关的技能和知识领域被叫做基础领域，它们定义了每个角色的域。总体来说，这些角色都具有这样的广度来满足项目成功的所有标准；如何任何一个角色无法实现其目标，这都会将危及整个项目。因此，这个同级小组里的每个角色都被认为是同等重要的，重要的决定都要共同做出。相关的目标和角色见下面的表格。
|
关键质量目标 |
MSF 小组角色群 |
|
在项目约束内的交付 |
程序管理 |
|
对产品规范的交付 |
开发 |
|
解决所有问题之后的发布 |
测试 |
|
顺利的部署和前进中的管理 |
发布管理 |
|
增强的用户表现 |
用于体验 |
|
满意的客户 |
产品管理 |
MSF 小组模型是行业里用于被赋予权力的小组工作和技术项目的最佳做法的汇编，它把重点放在了取得这些目标上。它们然后被应用到 MSF 过程模型里，以概括活动并创建小组所要生产的具体交付内容。这些主要的质量目标会定义和推动小组进行工作。
MSF 小组模型可能是 MSF 里最与众不同的部分。小组模型的核心是，技术项目必须符合各种利益相关人完全不同的，且常常并列的质量观点，这包括操作、业务和用户。MSF 小组模型推动了各种观点的这种融合，因此承认技术项目不单单就是 IT 的工作。
3.3.2 RUP的角色
RUP中的角色定义了个人或由若干人所组成小组的行为和责任。可以认为角色是项目组中个人戴的"帽子"。单个人可以佩戴多个不同的帽子。这是一个非常重要的区别。因为通常容易将角色认为是个人或小组本身，在 RUP 中，角色还定义了如何完成工作。所分派给角色的责任既包括某系列的活动，还包括成为产物的拥有者。
对于RUP中的角色，存在着两种观点。首先，它促进团队理解整体解决方案，然后在每一次迭代中基于上一次迭代重新评估并调整整体解决方案。第二，在每次迭代中，它促进团队主要着重于解决方案的一个方面 ―― 每次后继迭代构建解决方案的一个方面，直至整体完成。
中的广度及深度角色
RUP角色定义与分离广度和深度的概念相一致。进行广度工作与进行深度工作的成员类型差异很大。广度工作速度快，不精确并且有弹性。深度工作任务需要更多的时间，关注于细节，并且需要能够得到更好的质量。
RUP九个规程中的每一个都有一个集中于此规程广度的角色，以及另一个不同的集中于此规程深度的角色。一旦你理解了基本原理，记住这些角色将变得非常容易。下列出了每个RUP规程及其所对应的广度及深度角色，并粗略解释了角色的功能。
|
规 程 |
广度角色 |
深度角色 |
|
业务建模 |
业务过程分析师 |
业务设计 |
|
需求 |
系统分析师 |
需求定义 |
|
分析和设计 |
软件架构师 |
设计师 |
|
执行 |
集成人员 |
执行人员 |
|
测试 |
测试经理 |
测试设计师 |
|
开发 |
开发经理 |
技术文档作者，课程开发者，图形绘制者。 |
|
项目管理 |
项目经理 |
项目经理 |
|
环境 |
过程工程师 |
工具专家 |
|
配置变更管理 |
配置经理 |
配置经理 |
RUP中的角色是和活动、产物和工作流紧密联系在一起的。
某个角色的活动是可能要求该角色中的个体执行的工作单元。活动具有明确的目的，通常表现为一些产物，如模型、类、计划等。每个活动分派给特定的角色。活动通常占用几个小时至几天，常常牵涉一个角色，影响到一个或少量的产物。活动应可以用来作为计划和进展的组成元素；如果活动太小，它将被忽略，而如果太大，则进展不得不表现为活动的组成部分
产物是被产生的、修改，或为过程所使用的一段信息。产物是项目的实际产品、项目产生的事物，或者供向最终产品迈进时使用。产物用作角色执行某个活动的输入，同时也是该活动的输出。在面向对象的设计术语中，如活动是活动对象（角色）上的操作一样，产物是这些活动的参数。
产物可以具有不同的形式：
· 模型，如 Use-Case 模型或设计模型
· 模型组成元素,即模型中的元素，比如类，用例（use case）或子系统般的元素
· 文档,如商业案例或软件结构文档
· 源代码
· 可执行文件
工作流是产生具有可观察结果的活动序列，它是用来描述能产生若干有价值的有意义结果的活动序列，显示角色之间的交互作用。 UML 术语中,工作流可以表达为序列图、协同图，或活动图。在本文中，使用活动图的形式来描述。下图给出了工作流的一个样例。
要表达活动之间的所有依赖关系并不是总可能或切合实际的。常常两个活动较表现的交织得更紧密，特别是在涉及到同一个角色或个人时。人不是机器，对于人而言，工作流不能按字面地翻译成程序，被精确地、机械地执行。
开发流程定义了"谁""何时""如何"做"某事"。在RUP中，四种主要的建模元素：角色(Workers)，工作流（Workflows），活动(Activities)，产物(Artifacts)，就分别定义了"谁"，"何时"，"如何"，"某事" 。
3.3.3 比较小结
MSF和RUP都是使用了角色的概念。通过比较很容易发现，MSF中的角色比较言简意赅，而且融入了大量的“人”的要素，而RUP中的角色和开发过程中的其他三个建模因素紧密的结合成一个整体，但是关于角色的定义似乎略显复杂。
在RUP中的角色，工作流，活动和产物已经融入了整个软件开发过程中，工作流的思想很好的解决了各种活动的有机组织。工作流中的重要部分核心工作流将在3.4中进行介绍。
但是RUP引入了广度角色和深度角色的概念，但是角色的复杂性（不可否认，在大型的软件项目中需要有良好的人员安排）的确会给人望而却步的感觉。
相比较而言，MSF则是另一番景象。
毫不夸张的说，小组模型是MSF里最出众的地方，MSF的八个基础原理在这里有着淋漓尽致的表现。换句话说，MSF的核心思想源于小组模型。小组模型十分成功的实现了开发的良性循环并把软件开发中的“技术”和“人”的两个要素进行了近似完美的结合。
如果真的要分出孰优孰劣的话，在组队模型方面，IBM的RUP只能甘拜下风。
3.4 准则 VS核心工作流
在软件开发过程中，有一些工作需要贯穿整个过程始终。而这些，也往往决定着整个软件开发的成败。MSF和RUP分别就这些问题进行了分类和探讨。
3.4.1 MSF的准则
MSF 准则包括项目管理准则、风险管理准则和就绪管理准则。
这些准则对于 MSF 小组和过程模型的良好运作十分重要。它们起源不在 MSF 之内；它们在行业内部得到了很好的检验，并有全面的知识体系来支持。MSF 具有与基础原理和模型相配套的特定准则，并在需要的时候用它们对框架的其他元素进行补充。总的来说，MSF 并没有尝试去完全重建这些准则，而是去突出在被应用到 MSF 环境里的时候它们是如何去适应的。这些准则由 MSF 和 MOF 共享，预计在将来会有其他的准则被采用。
项目管理准则
项目管理是用来实现项目目标的一套知识、技能、工具和技术，而项目目标就是一致认同的质量、成本、日程安排和约束等的参数。
风险管理准则
风险管理是对技术项目里固有的不确定性的响应，固有的不确定性意味着不可避免的风险。但是，这并不意味着就是要去承认和管理风险就一定会阻碍对机遇的创造性追求。
就绪管理准则
MSF 就绪管理准把其主要焦点限制到项目小组的就绪上。项目小组里担当特定角色的每个人都必须能够完成该角色必备的所有关键功能。就绪管理用来确保小组成员都能够完全满足他们所要从事的工作的需要。
3.4.2 RUP的核心工作流
RUP 中有9个核心工作流,代表了所有角色和活动的逻辑分组情况。
核心工作流分为6个核心"工程"工作流
1) 商业建模工作流
2) 需求工作流
3) 分析和设计工作流
4) 实现工作流
5) 测试工作流
6) 分发工作流
和3个核心"支持"工作流
1) 项目管理工作流
2) 配置和变更控制工作流
3) 环境工作流
尽管6个核心工程工作流能使人想起传统瀑布流程中的几个阶段，但应注意迭代过程中的阶段是不同的，这些工作流在整个生命期中一次又一次被访问。9个核心工作流在项目中的实际完整的工作流中轮流被使用，在每一次迭代中以不同的重点和强度重复。
3.4.3 比较小结
就他们的内涵而言，二者存在着很大的交集。比较而言，RUP的理论更加完备一些，但是，RUP这里提到的很多工作流是和之前的过程模型相重合的。
从设计角度上看，MSF和RUP采用的是完全不同的思路。MSF是根据目前的软件开发行业的现有的经验，加上自身对于软件开发的体会，总结出三条规则。而RUP则是根据自身的理论，把这些归结在整个开发的工作流中――核心工作流。把这些贯穿整个开发过程的模块紧密的结合在软件开发过程中，更加容易进行实际操作。
通过第三部分的比较，我们可以会发现，其实MSF和RUP在“做什么”方面，也就是第三部分开头探讨的总体目标上，是一致的，但是在“怎么做”方面，二者采用的是不同的思路。
就整体性而言，RUP比MSF更加的浑然一体。它通过二维结构来描述整个软件开发过程，并通过角色、活动、产物和工作流四个建模因素组织了整个过程。这样似乎可以更好完成整个软件开发过程。而MSF，虽然各个原则，模型也是协同工作，但相对略显独立一些。或者说是RUP的耦合性更多些，MSF的内聚性更多些。
就各个模型而言，在过程模型上，RUP和MSF基本上都是在原有的瀑布模型和螺旋模型基础上的改进，相对而言，RUP采用了二维结构更加直观的现实各种工作在整个过程中分布；而在组队模型上，MSF则凸现了微软在长期的大规模的软件工程实践中总结出来的经验，尤其是它在“人”和“技术”两个要素的有机结合方面。RUP的角色概念虽然提出了工作流的概念，但是角色的错综复杂真的很令人难以接受，当然不可否认的是，它在一些大的软件开发过程中，可能起到很好的效果。
在核心思想和原则方面，基本都是一些贯穿于整个开发过程中的重要思想或者是模块，工作。二者各有千秋，都充分体现了各自在软件开发领域的长期积累。
但是有一点一定要说明的是，二者都是追求“以不变应万变”，即以一个软件开发方法适应所有的软件开发工作。虽然他们也说自身是可配置的，既适用小的开发团队也适合大型开发组织，但是毕竟每个软件开发都是特殊的个体而且没有一个开发过程能适合所有的软件开发，如果要想取得最终的成功，一定要根据自身的规模等实际情况，合理的结合这两个软件开发方法，进行软件开发。
1、Microsoft 解决方案框架版本 3.0 概述
http://www.microsoft.com/china/technet/itsolutions/techguide/msf/msfovrvw.mspx#EMFAC
2、Rational统一过程――软件开发团队的最佳实践
http://www-128.ibm.com/developerworks/cn/rational/r-rupbp/
3、Saif Mandik，Comparing Microsoft Solution Framework & Rational Unified Process，27 March 2004
4、Bill Wood，Richard Pethia,Lauren Roberts Gold, Robert Firth，A Guide to the Assessment of Software Development Methods，April 1988
5、Anthony Crain，理解 RUP 角色，2005.7
http://www-128.ibm.com/developerworks/cn/rational/rationaledge/content/jun05/crain/
6、MSF 组队模型（白皮书）v. 3.1
http://www.microsoft.com/china/technet/itsolutions/techguide/msf/msftm31.mspx#EOC
法律声明：本文章受到知识产权法保护，任何单位或个人若需要转载此文，必需保证文章的完整性（未经作者许可的任何删节或
改动将视为侵权行为）。若您需要转载，请务必注明文章出处；请务必注明文章作者为chiefsailor，并向
chiefsailor[a]126.com发送邮件，标明文章位置及用途。转载时请将此法律声明一并转载，谢谢！