：
本文將比較Microsoft解決方案框架和Rational統(tǒng)一過程兩個軟件開發(fā)過程。在第二部分中，我們將簡要介紹這兩種過程方法。在接下來的第三部分中，我們先比較了二者的整體目標，接著從核心思想、過程模型、組隊模型和準則四個角度對二者進行了比較，在每小節(jié)的結(jié)束位置，都進行了認真、細致的比較小結(jié)。在第四部分中，我們對兩種軟件過程方法從整體，模型，思想以及實際操作等角度進行總結(jié)。
Microsoft解決方案框架
Microsoft解決方案框架（Microsoft Solutions Framework，以下簡稱MSF）是一種成熟的、系統(tǒng)的技術(shù)項目方法，它基于一套制定好的原理、模型、準則、概念、指南，以及來自 Microsoft 的、經(jīng)過檢驗的做法。
MSF是一組建立、開發(fā)和實現(xiàn)分布式企業(yè)系統(tǒng)應(yīng)用的工作模型、開發(fā)準則和應(yīng)用指南。它幫助企業(yè)融合商業(yè)和技術(shù)的目標，降低采用新技術(shù)后系統(tǒng)整體的費用，以及成功的應(yīng)用微軟技術(shù)整合商業(yè)過程的方法。
按期并在預(yù)算范圍內(nèi)創(chuàng)建行之有效的業(yè)務(wù)解決方案需要一種經(jīng)過檢驗的方法。Microsoft 解決方案框架提供了一個適應(yīng)性的框架，用于以更快的速度、更少的人員、更少的風險來成功地交付信息技術(shù)解決方案，同時取得更高質(zhì)量的結(jié)果。
MSF指出為成功設(shè)計、構(gòu)建和管理技術(shù)基礎(chǔ)結(jié)構(gòu)或商業(yè)解決方案，所需了解的重要風險、重要的設(shè)計基礎(chǔ)假設(shè)和關(guān)鍵的依賴關(guān)系。它包括明確的知識庫、應(yīng)用指南和實踐經(jīng)驗。
Rational統(tǒng)一過程
Rational統(tǒng)一過程（RationalUnifiedProcess，以下簡稱RUP）是軟件工程的過程。它提供了在開發(fā)組織中分派任務(wù)和責任的紀律化方法。它的目標是在可預(yù)見的日程和預(yù)算前提下，確保滿足最終用戶需求的高質(zhì)量產(chǎn)品。RUP可以提高了團隊生產(chǎn)力。對于所有的關(guān)鍵開發(fā)活動，它為每個團隊成員提供了使用準則、模板、工具指導來進行訪問的知識基礎(chǔ)。
RUP 的活動創(chuàng)建和維護模型。 RUP 強調(diào)開發(fā)和維護模型--語義豐富的軟件系統(tǒng)表達，而非強調(diào)大量的文本工作。
RUP 能對大部分開發(fā)過程提供自動化的工具支持。它們被用來創(chuàng)建和維護軟件開發(fā)過程（可視化建模、編程、測試等）的各種各樣的產(chǎn)物--特別是模型。另外在每個迭代過程的變更管理和配置管理相關(guān)的文檔工作支持方面也是非常有價值的。
RUP是可配置的過程。沒有一個開發(fā)過程能適合所有的軟件開發(fā)。RUP既適用小的開發(fā)團隊也適合大型開發(fā)組織。RUP建立簡潔和清晰的過程結(jié)構(gòu)為開發(fā)過程家族提供通用性。并且，它可以變更以容納不同的情況。它還包含了開發(fā)工具包，為配置適應(yīng)特定組織機構(gòu)的開發(fā)過程提供了支持。
從目標角度上講，二者似乎“不謀而合”。他們的目標都是在可預(yù)見的日程和預(yù)算前提下，確保滿足最終用戶需求的高質(zhì)量產(chǎn)品，或者說是用于以更快的速度、更少的人員、更少的風險來成功地交付信息技術(shù)解決方案，同時取得更高質(zhì)量的結(jié)果。
目標基本相同，那么需要關(guān)注的就是如何來實現(xiàn)這個目標了。在本章中，我們將從核心思想，過程模型，小組模型和原則四個角度進行分析比較。
核心思想――基礎(chǔ)原理VS 最佳實踐
無論是框架還是過程，它們都需要一些理論基礎(chǔ)和鋪墊。微軟和IBM，這兩個軟件巨頭，分別通過對他們長期的開發(fā)經(jīng)驗的總結(jié)，給出了他們的核心思想。
八個基礎(chǔ)原理
MSF 的核心有八個基礎(chǔ)原理：
1) 推動開放式溝通
2) 為共同的前景而工作
3) 賦予小組成員權(quán)力
4) 建立清晰的責任和共同的職責
5) 關(guān)注交付業(yè)務(wù)價值
6) 保持靈巧，預(yù)測變化
7) 質(zhì)量投資
8) 學習所有的經(jīng)驗
這些原理共同傳達了 MSF觀點，構(gòu)成了一種統(tǒng)一方法的基礎(chǔ)，這一方法用來組織項目所需的人員和過程，以便交付技術(shù)解決方案。它們是 MSF結(jié)構(gòu)和應(yīng)用的基礎(chǔ)。盡管每個原理都已經(jīng)顯示出了自身的優(yōu)勢，但是它們很多都是相互依存的，因為其中任何一個的應(yīng)用都對另一個的成功起到了支持作用。在依次應(yīng)用的時候，它們建立了一個穩(wěn)固的基礎(chǔ)，使得 MSF 能夠很好地適用于規(guī)模、復雜程度和類型都不相同的多種項目。
RUP描述了如何為軟件開發(fā)團隊有效的部署經(jīng)過商業(yè)化驗證的軟件開發(fā)方法。它們被稱為"最佳實踐"不僅僅因為你可以精確地量化它們的價值，而且它們被許多成功的機構(gòu)普遍的運用。為使整個團隊有效利用最佳實踐，RUP為每個團隊成員提供了必要準則、模板和工具指導：
1) 迭代的開發(fā)軟件
2) 需求管理
3) 使用基于構(gòu)件的體系結(jié)構(gòu)
4) 可視化軟件建模
5) 驗證軟件質(zhì)量
6) 控制軟件變更
比較小結(jié)
相對而言，RUP更加是從準則、模板和工具指導的角度對整個理論進行了鋪墊，它把整個軟件工程分成了可以迭代的一些過程，并通過對這些過程的規(guī)范管理，實現(xiàn)它的最終目標。而MSF則更偏重于人的角度，對貫穿整個開發(fā)過程中的一些要素進行了強調(diào)，對小組和成員的行為進行了規(guī)范。
雖然他們的出發(fā)角度不同，但是最終實現(xiàn)的效果似乎有些異曲同工。都是對一些行為進行規(guī)范，無論是開發(fā)中的一些過程，還是成員的行為，都會最終落實到軟件開發(fā)上去。很難評價孰優(yōu)孰劣，但是有一點可以肯定地是：這些原理和有效部署，都是長期開發(fā)的經(jīng)驗結(jié)晶。無論是否采用這種開發(fā)過程管理軟件，這些都值得我們?nèi)フJ真學習。
MSF和RUP也基本是按照這個思路進行設(shè)計的。
的過程模型
MSF 過程模型把來自傳統(tǒng)的瀑布模型和螺旋模型的概念結(jié)合起來，并利用了兩者各自的長處。過程模型把瀑布模型基于里程碑的規(guī)劃的優(yōu)勢與螺旋模型不斷增加的反復項目交付內(nèi)容的長處結(jié)合了起來。
MSF過程模型解釋了如何基于：范圍、進度和資源，規(guī)劃和控制面向結(jié)果的項目。它是基于四個可見里程碑交互的、允許修改的過程模型。
階段和里程碑
MSF 過程模型以階段和里程碑為基礎(chǔ)。MSF 階段是普通意義上的完成特定任務(wù)的一段時間。每個階段都有其自身的特色，每個階段的結(jié)束都代表了項目進展和中心點的變化。里程碑是檢查和同步點，用來確定階段的目標是否已經(jīng)實現(xiàn)。里程碑為小組提供了明確的機會，以調(diào)整項目的范圍，反映客戶或者業(yè)務(wù)要求的變化，并解決項目過程中可能會出現(xiàn)的實際風險和問題。
下表給出了MSF過程模型的活動與里程碑
主要里程碑
模型區(qū)間
關(guān)鍵活動
想象性描述與范圍確定被核準
想象
建立項目范圍與用戶需求
項目計劃被核準
計劃
開發(fā)功能詳述與開發(fā)計劃
草圖設(shè)計
設(shè)定發(fā)布日期
完成所有交付物
首次使用
開發(fā)
完成設(shè)計
實現(xiàn)并測試代碼
開發(fā)文檔
開發(fā)培訓
貝塔測試準備
發(fā)布
穩(wěn)定
完成系統(tǒng)測試
完成首次展示準備
的過程模型
在RUP中，開發(fā)過程是用二維結(jié)構(gòu)或沿著兩個坐標軸來表達：
l 橫軸代表了制訂開發(fā)過程時的時間，體現(xiàn)了過程的動態(tài)結(jié)構(gòu)。它以術(shù)語周期（cycle）、階段(phase)、迭代（iteration）和里程碑(milestone)來表達。
l 縱軸表現(xiàn)了過程的靜態(tài)結(jié)構(gòu)：如何用術(shù)語活動（activity）、產(chǎn)物(artifact)、 角色(worker)和工作流(workflow)來描述。
迭代模型圖顯示了過程的二維結(jié)構(gòu)。
--時間軸
軟件生命周期被分解為周期，每一個周期工作在產(chǎn)品新的一代上。RUP將周期又劃分為四個連續(xù)的階段。分別是初始階段，細化階段，構(gòu)造階段和交付階段。開發(fā)過程沿時間進行動態(tài)組織。每個階段終結(jié)于良好定義的里程碑――某些關(guān)鍵決策必須做出的時間點，因此關(guān)鍵的目標必須被達到。每個階段均有明確的目標。下圖說明了各個階段的目標和對應(yīng)的里程碑。
階段目標
里程碑
初始階段
為系統(tǒng)建立商業(yè)案例和確定項目的邊界
生命周期的目標
細化階段
分析問題領(lǐng)域，建立健全的體系結(jié)構(gòu)基礎(chǔ)，編制項目計劃，淘汰項目中最高風險的元素
生命周期的結(jié)構(gòu)
構(gòu)建階段
所有剩余的構(gòu)件和應(yīng)用程序功能被開發(fā)并集成為產(chǎn)品,所有的功能被詳盡的測試
初始運作能力
交付階段
將軟件產(chǎn)品交付給用戶群體
產(chǎn)品發(fā)布
比較小結(jié)
由上面的介紹我們可以明顯看出，MSF和RUP在過程模型設(shè)計的時候，都是結(jié)合瀑布模型和螺旋模型進行設(shè)計的。把瀑布模型基于里程碑的規(guī)劃的優(yōu)勢與螺旋模型不斷增加的反復項目交付內(nèi)容的長處結(jié)合了起來。階段和里程碑的概念在各自的模型里都有明確的定義。
與MSF不同的是，RUP并沒有走螺旋模型的老路――它將螺旋型轉(zhuǎn)化成了一個二維的結(jié)構(gòu)，在這樣的結(jié)構(gòu)里，我們同樣可以清晰地看到各種性質(zhì)的工作的各個階段中的工作量。
在這個二維結(jié)構(gòu)里，RUP提出了迭代過程的概念。RUP 的每個階段可以進一步被分解為迭代過程。迭代過程是導致可執(zhí)行產(chǎn)品版本（內(nèi)部和外部）的完整開發(fā)循環(huán)，是最終產(chǎn)品的一個子集，從一個迭代過程到另一個迭代過程遞增式增長形成最終的系統(tǒng)。
與傳統(tǒng)的瀑布式方法相比，迭代過程具有以下的優(yōu)點：
1) 減小了風險
2) 更容易對變更進行控制
3) 高度的重用性
4) 項目小組可以在開發(fā)中學習
5) 較佳的總體質(zhì)量
利用迭代過程和二維結(jié)構(gòu)，RUP也成功地實現(xiàn)了瀑布模型和螺旋模型的成功結(jié)合。
軟件開發(fā)中除了“技術(shù)”要素以外，還有一個更加重要的因素，就是“人”。比起技術(shù)要素，人的因素更加的不好把握。因此，為了充分的發(fā)揮人在軟件開發(fā)中的重要作用，我們需要有良好的團隊，優(yōu)秀的組隊模型。
的小組模型
MSF 小組模型定義了小組同級成員的一些角色和職責，這些成員都在以相互依存的跨學科角色進行信息技術(shù)項目工作。模型展示了如何組織項目隊伍，在時間控制和連續(xù)不斷發(fā)展計劃的要求下，有效的交付系統(tǒng)的解決方案。它描述了六種基本的角色（程序管理、產(chǎn)品管理、開發(fā)、測試、系統(tǒng)實現(xiàn)和用戶教育）。下面的圖表對該模型的邏輯進行了描述。
MSF小組模型基于這樣一種前提，即任何技術(shù)項目都必須達到特定的關(guān)鍵質(zhì)量目標才能夠被認為是成功的項目。達到每個目標都需要相關(guān)的、不同技能及知識領(lǐng)域的應(yīng)用，它們每一個都包括在一個小組角色群（通常被簡稱為角色）里。相關(guān)的技能和知識領(lǐng)域被叫做基礎(chǔ)領(lǐng)域，它們定義了每個角色的域。總體來說，這些角色都具有這樣的廣度來滿足項目成功的所有標準；如何任何一個角色無法實現(xiàn)其目標，這都會將危及整個項目。因此，這個同級小組里的每個角色都被認為是同等重要的，重要的決定都要共同做出。相關(guān)的目標和角色見下面的表格。
關(guān)鍵質(zhì)量目標
MSF 小組角色群
在項目約束內(nèi)的交付
程序管理
對產(chǎn)品規(guī)范的交付
開發(fā)
解決所有問題之后的發(fā)布
測試
順利的部署和前進中的管理
發(fā)布管理
增強的用戶表現(xiàn)
用于體驗
滿意的客戶
產(chǎn)品管理
MSF 小組模型是行業(yè)里用于被賦予權(quán)力的小組工作和技術(shù)項目的最佳做法的匯編，它把重點放在了取得這些目標上。它們?nèi)缓蟊粦?yīng)用到 MSF 過程模型里，以概括活動并創(chuàng)建小組所要生產(chǎn)的具體交付內(nèi)容。這些主要的質(zhì)量目標會定義和推動小組進行工作。
MSF 小組模型可能是 MSF 里最與眾不同的部分。小組模型的核心是，技術(shù)項目必須符合各種利益相關(guān)人完全不同的，且常常并列的質(zhì)量觀點，這包括操作、業(yè)務(wù)和用戶。MSF 小組模型推動了各種觀點的這種融合，因此承認技術(shù)項目不單單就是 IT 的工作。
的角色
RUP中的角色定義了個人或由若干人所組成小組的行為和責任?？梢哉J為角色是項目組中個人戴的"帽子"。單個人可以佩戴多個不同的帽子。這是一個非常重要的區(qū)別。因為通常容易將角色認為是個人或小組本身，在 RUP 中，角色還定義了如何完成工作。所分派給角色的責任既包括某系列的活動，還包括成為產(chǎn)物的擁有者。
對于RUP中的角色，存在著兩種觀點。首先，它促進團隊理解整體解決方案，然后在每一次迭代中基于上一次迭代重新評估并調(diào)整整體解決方案。第二，在每次迭代中，它促進團隊主要著重于解決方案的一個方面――每次后繼迭代構(gòu)建解決方案的一個方面，直至整體完成。
中的廣度及深度角色
RUP角色定義與分離廣度和深度的概念相一致。進行廣度工作與進行深度工作的成員類型差異很大。廣度工作速度快，不精確并且有彈性。深度工作任務(wù)需要更多的時間，關(guān)注于細節(jié)，并且需要能夠得到更好的質(zhì)量。
RUP九個規(guī)程中的每一個都有一個集中于此規(guī)程廣度的角色，以及另一個不同的集中于此規(guī)程深度的角色。一旦你理解了基本原理，記住這些角色將變得非常容易。下列出了每個RUP規(guī)程及其所對應(yīng)的廣度及深度角色，并粗略解釋了角色的功能。
規(guī)程
廣度角色
深度角色
業(yè)務(wù)建模
業(yè)務(wù)過程分析師
發(fā)掘所有的業(yè)務(wù)使用用例。
業(yè)務(wù)設(shè)計
細化一套單獨的業(yè)務(wù)使用用例。
需求
系統(tǒng)分析師
發(fā)掘所有的需求使用用例。
需求定義
細化一套單獨的需求使用用例。
分析和設(shè)計
軟件架構(gòu)師
決定整個解決方案的技術(shù)
設(shè)計師
為一套單獨的使用用例進行分析和設(shè)計。
執(zhí)行
集成人員
擁有哪些類會集成到一起的構(gòu)建計劃 。
執(zhí)行人員
編制單獨的一套類或一套單獨的類操作。
測試
測試經(jīng)理
保證完成測試和測試管理。
測試分析師
基于這個測試目的選擇測試什么。
測試設(shè)計師
決定什么測試使用自動測試，對比手動測試，并且創(chuàng)建自動測試。
測試設(shè)計師
為集成自動執(zhí)行測試設(shè)計的一部分。
測試員
運行一個特定的測試。
開發(fā)
開發(fā)經(jīng)理
檢查所有的開發(fā)單元。
技術(shù)文檔作者，課程開發(fā)者，圖形繪制者。
構(gòu)建詳細的資源保證成功的開發(fā)。
項目管理
項目經(jīng)理
創(chuàng)建業(yè)務(wù)用例，以及簡單的計劃；制定做或不做的決定。
項目經(jīng)理
計劃，跟蹤，以及管理單一迭代的風險。
環(huán)境
過程工程師
掌握項目的過程。
工具專家
為使用特定工具創(chuàng)建方針。
配置變更管理
配置經(jīng)理
設(shè)置配置環(huán)境，方針，和計劃。
變更控制經(jīng)理
建立一個變更控制過程。
配置經(jīng)理
創(chuàng)建一個開發(fā)單元，報告配置狀態(tài)，執(zhí)行審計，等等。
變更控制經(jīng)理
檢查并管理變更請求
RUP中的角色是和活動、產(chǎn)物和工作流緊密聯(lián)系在一起的。
某個角色的活動是可能要求該角色中的個體執(zhí)行的工作單元?；顒泳哂忻鞔_的目的，通常表現(xiàn)為一些產(chǎn)物，如模型、類、計劃等。每個活動分派給特定的角色?；顒油ǔＵ加脦讉€小時至幾天，常常牽涉一個角色，影響到一個或少量的產(chǎn)物?；顒討?yīng)可以用來作為計劃和進展的組成元素；如果活動太小，它將被忽略，而如果太大，則進展不得不表現(xiàn)為活動的組成部分
產(chǎn)物是被產(chǎn)生的、修改，或為過程所使用的一段信息。產(chǎn)物是項目的實際產(chǎn)品、項目產(chǎn)生的事物，或者供向最終產(chǎn)品邁進時使用。產(chǎn)物用作角色執(zhí)行某個活動的輸入，同時也是該活動的輸出。在面向?qū)ο蟮脑O(shè)計術(shù)語中，如活動是活動對象（角色）上的操作一樣，產(chǎn)物是這些活動的參數(shù)。
產(chǎn)物可以具有不同的形式：
· 模型，如 Use-Case 模型或設(shè)計模型
· 模型組成元素,即模型中的元素，比如類，用例（use case）或子系統(tǒng)般的元素
· 文檔,如商業(yè)案例或軟件結(jié)構(gòu)文檔
· 源代碼
· 可執(zhí)行文件
工作流是產(chǎn)生具有可觀察結(jié)果的活動序列，它是用來描述能產(chǎn)生若干有價值的有意義結(jié)果的活動序列，顯示角色之間的交互作用。 UML 術(shù)語中,工作流可以表達為序列圖、協(xié)同圖，或活動圖。在本文中，使用活動圖的形式來描述。下圖給出了工作流的一個樣例。
要表達活動之間的所有依賴關(guān)系并不是總可能或切合實際的。常常兩個活動較表現(xiàn)的交織得更緊密，特別是在涉及到同一個角色或個人時。人不是機器，對于人而言，工作流不能按字面地翻譯成程序，被精確地、機械地執(zhí)行。
開發(fā)流程定義了"誰""何時""如何"做"某事"。在RUP中，四種主要的建模元素：角色(Workers)，工作流（Workflows），活動(Activities)，產(chǎn)物(Artifacts)，就分別定義了"誰"，"何時"，"如何"，"某事" 。
比較小結(jié)
MSF和RUP都是使用了角色的概念。通過比較很容易發(fā)現(xiàn)，MSF中的角色比較言簡意賅，而且融入了大量的“人”的要素，而RUP中的角色和開發(fā)過程中的其他三個建模因素緊密的結(jié)合成一個整體，但是關(guān)于角色的定義似乎略顯復雜。
在RUP中的角色，工作流，活動和產(chǎn)物已經(jīng)融入了整個軟件開發(fā)過程中，工作流的思想很好的解決了各種活動的有機組織。工作流中的重要部分核心工作流將在3.4中進行介紹。
但是RUP引入了廣度角色和深度角色的概念，但是角色的復雜性（不可否認，在大型的軟件項目中需要有良好的人員安排）的確會給人望而卻步的感覺。
相比較而言，MSF則是另一番景象。
毫不夸張的說，小組模型是MSF里最出眾的地方，MSF的八個基礎(chǔ)原理在這里有著淋漓盡致的表現(xiàn)。換句話說，MSF的核心思想源于小組模型。小組模型十分成功的實現(xiàn)了開發(fā)的良性循環(huán)并把軟件開發(fā)中的“技術(shù)”和“人”的兩個要素進行了近似完美的結(jié)合。
如果真的要分出孰優(yōu)孰劣的話，在組隊模型方面，IBM的RUP只能甘拜下風。
VS核心工作流
開發(fā)過程中，有一些工作需要貫穿整個過程始終。而這些，也往往決定著整個軟件開發(fā)的成敗。MSF和RUP分別就這些問題進行了分類和探討。
的準則
MSF 準則包括項目管理準則、風險管理準則和就緒管理準則。
這些準則對于 MSF小組和過程模型的良好運作十分重要。它們起源不在 MSF 之內(nèi)；它們在行業(yè)內(nèi)部得到了很好的檢驗，并有全面的知識體系來支持。MSF具有與基礎(chǔ)原理和模型相配套的特定準則，并在需要的時候用它們對框架的其他元素進行補充?？偟膩碚f，MSF并沒有嘗試去完全重建這些準則，而是去突出在被應(yīng)用到 MSF 環(huán)境里的時候它們是如何去適應(yīng)的。這些準則由 MSF 和 MOF共享，預(yù)計在將來會有其他的準則被采用。
項目管理準則
項目管理是用來實現(xiàn)項目目標的一套知識、技能、工具和技術(shù)，而項目目標就是一致認同的質(zhì)量、成本、日程安排和約束等的參數(shù)。
風險管理準則
風險管理是對技術(shù)項目里固有的不確定性的響應(yīng)，固有的不確定性意味著不可避免的風險。但是，這并不意味著就是要去承認和管理風險就一定會阻礙對機遇的創(chuàng)造性追求。
就緒管理準則
MSF 就緒管理準把其主要焦點限制到項目小組的就緒上。項目小組里擔當特定角色的每個人都必須能夠完成該角色必備的所有關(guān)鍵功能。就緒管理用來確保小組成員都能夠完全滿足他們所要從事的工作的需要。
的核心工作流
RUP 中有9個核心工作流,代表了所有角色和活動的邏輯分組情況。
核心工作流分為6個核心"工程"工作流
1) 商業(yè)建模工作流
2) 需求工作流
3) 分析和設(shè)計工作流
4) 實現(xiàn)工作流
5) 測試工作流
6) 分發(fā)工作流
和3個核心"支持"工作流
1) 項目管理工作流
2) 配置和變更控制工作流
3) 環(huán)境工作流
盡管6個核心工程工作流能使人想起傳統(tǒng)瀑布流程中的幾個階段，但應(yīng)注意迭代過程中的階段是不同的，這些工作流在整個生命期中一次又一次被訪問。9個核心工作流在項目中的實際完整的工作流中輪流被使用，在每一次迭代中以不同的重點和強度重復。
比較小結(jié)
就他們的內(nèi)涵而言，二者存在著很大的交集。比較而言，RUP的理論更加完備一些，但是，RUP這里提到的很多工作流是和之前的過程模型相重合的。
從設(shè)計角度上看，MSF和RUP采用的是完全不同的思路。MSF是根據(jù)目前的軟件開發(fā)行業(yè)的現(xiàn)有的經(jīng)驗，加上自身對于軟件開發(fā)的體會，總結(jié)出三條規(guī)則。而RUP則是根據(jù)自身的理論，把這些歸結(jié)在整個開發(fā)的工作流中――核心工作流。把這些貫穿整個開發(fā)過程的模塊緊密的結(jié)合在軟件開發(fā)過程中，更加容易進行實際操作。
通過第三部分的比較，我們可以會發(fā)現(xiàn)，其實MSF和RUP在“做什么”方面，也就是第三部分開頭探討的總體目標上，是一致的，但是在“怎么做”方面，二者采用的是不同的思路。
就整體性而言，RUP比MSF更加的渾然一體。它通過二維結(jié)構(gòu)來描述整個軟件開發(fā)過程，并通過角色、活動、產(chǎn)物和工作流四個建模因素組織了整個過程。這樣似乎可以更好完成整個軟件開發(fā)過程。而MSF，雖然各個原則，模型也是協(xié)同工作，但相對略顯獨立一些?；蛘哒f是RUP的耦合性更多些，MSF的內(nèi)聚性更多些。
就各個模型而言，在過程模型上，RUP和MSF基本上都是在原有的瀑布模型和螺旋模型基礎(chǔ)上的改進，相對而言，RUP采用了二維結(jié)構(gòu)更加直觀的現(xiàn)實各種工作在整個過程中分布；而在組隊模型上，MSF則凸現(xiàn)了微軟在長期的大規(guī)模的軟件工程實踐中總結(jié)出來的經(jīng)驗，尤其是它在“人”和“技術(shù)”兩個要素的有機結(jié)合方面。RUP的角色概念雖然提出了工作流的概念，但是角色的錯綜復雜真的很令人難以接受，當然不可否認的是，它在一些大的軟件開發(fā)過程中，可能起到很好的效果。
在核心思想和原則方面，基本都是一些貫穿于整個開發(fā)過程中的重要思想或者是模塊，工作。二者各有千秋，都充分體現(xiàn)了各自在軟件開發(fā)領(lǐng)域的長期積累。
但是有一點一定要說明的是，二者都是追求“以不變應(yīng)萬變”，即以一個軟件開發(fā)方法適應(yīng)所有的軟件開發(fā)工作。雖然他們也說自身是可配置的，既適用小的開發(fā)團隊也適合大型開發(fā)組織，但是畢竟每個軟件開發(fā)都是特殊的個體而且沒有一個開發(fā)過程能適合所有的軟件開發(fā)，如果要想取得最終的成功，一定要根據(jù)自身的規(guī)模等實際情況，合理的結(jié)合這兩個軟件開發(fā)方法，進行軟件開發(fā)。
1、Microsoft 解決方案框架版本 3.0 概述
http://www.microsoft.com/china/technet/itsolutions/techguide/msf/msfovrvw.mspx#EMFAC
2、Rational統(tǒng)一過程――軟件開發(fā)團隊的最佳實踐
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 DevelopmentMethods，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
