RUP

根據Rational（Rational Rose和統一建模語言的開發者）的説法，RUP類似一個在線的指導者，它可以為所有方面和層次的程序開發提供指導方針，模版以及事例支持。RUP和類似的產品--例如面向對象的軟件過程（OOSP），以及OPEN Process都是理解性的軟件工程工具--把開發中面向過程的方面（例如定義的階段，技術和實踐）和其他開發的組件（例如文檔，模型，手冊以及代碼等等）整合在一個統一的框架內。

軟件工程領域，與RUP齊名的軟件方法還有：淨室軟件工程、CMMI；極限編程（extreme programming，簡稱 XP）和其他敏捷軟件開發（agile methodology）方法學。

RUP中定義了一些核心概念，如下圖《RUP核心概念》所示：

角色：RUP預先定義了許多角色，角色描述了在項目開發中，一個人或者一個開發團隊的工作職能與任務。 ^[1] 

活動：它是一個有明確功能的獨立模塊，反映了系統的某個功能。

工件：是在活動進行過程中產生、創建或修改的一段信息，同時也是項目開發的文檔資料。

此外，與這些核心概念相關的內容還有檢查點、模板、工作指南、報告、工具指南等。 ^[1] 

RUP最重要的它有三大特點：1）軟件開發是一個迭代過程，2）軟件開發是由Use Case驅動的，3）軟件開發是以架構設計（Architectural Design）為中心的。

RUP強調軟件開發是一個迭代模型(Iterative Model)，它定義了四個階段(Phase)：初始(Inception)、細化(Elaboration)、構造(Construction)、交付(Transition)。其中每個階段都有可能經歷以上所提到的從商務需求分析開始的各個步驟，只是每個步驟的高峯期會發生在相應的階段，例如開發實現的高峯期是發生在構造階段。實際上這樣的一個開發方法論是一個二維模型，這種迭代模型的實現在很大程度上提供了及早發現隱患和錯誤的機會，因此被現代大型信息技術項目所採用。 ^[2] 

RUP的另一大特徵是用例驅動。用例是RUP方法論中一個非常重要的概念。簡單地説，一個用例就是系統的一個功能。在系統分析和系統設計中，用例被用來將一個複雜的龐大系統分割、定義成一個個小的單元，這個小的單元就是用例。然後以每個小的單元為對象進行開發。按照RUP過程模型的描述，用例貫穿整個軟件開發的生命週期。在需求分析中，客户或用户對用例進行描述，在系統分佈和系統設計過程中，設計師對用例進行分析，在開發實現過程中，開發編程人員對用例進行實現，在測試過程中，測試人員對用例進行檢驗。 ^[2] 

RUP的第三大特徵是它強調軟件開發是以構架為中心的。構架設計(ArchitecturalDesign)是系統設計的一個重要組成部分。在構架設計過程中，設計師(Architect)必須完成對技術和運行平台的選取，整個項目的基礎框架( Framework)的設計，完成對公共組件的設計，如審計( Auditing)系統、日誌(Iog)系統、錯誤處理(Exception Handling)系統、安全(Security)系統等。設計師必須對系統的可擴展性( Extensibility)、安全性(Security)、可維護性( Maintainability)、可延拓性(Scalability)、可重用性(Reusability)和運行速度(Performance)提出可行的解決方案。 ^[2] 

在軟件開發的初期就想完全、準確地獲得用户的需求基本是不可能的。實際上，設計者常常碰到的問題是需求在整個軟件開發過程中經常會發生變化。而迭代式開發允許每次迭代開發過程中需求發生變化，它正是通過不斷迭代來細化對問題的理解。這樣，迭代式開發大大降低了項目開發的風險，提高了軟件開發的效率。 ^[1] 

準確地確定系統的需求是一個連續漸進的過程，開發人員不可能在系統開發之前就完全詳細地理解系統的全部需求。而RUP正是提供瞭如何獲得、組織系統的功能和約束條件並將其文檔化的方法。 ^[1] 

組件是可複用的單位，為了達到軟件複用的目的，可以由組件來組成系統。基於獨立的、可替換的、模塊化組件的體系結構的優點是它方便管理，並能有效地提高軟件的重用性。RUP展示瞭如何設計一個靈活的、有很強適應性的、有利於理解和便於複用的軟件體系結構。 ^[1] 

RUP常常和UML相互聯繫，這就有利於建立軟件系統的可視化模型。RUP提供了對軟件系統進行可視化建模的方法。 ^[1] 

在RUP中，軟件質量的評估不再是事後進行或單獨小組進行的分離活動，而是貫穿於軟件開發的過程中，這樣就有利於及早發現軟件中存在的不足。 ^[1] 

RUP是一個通用的過程模板，包含了很多開發指南、製品、開發過程所涉及到的角色説明，由於它非常龐大所以對具體的開發機構和項目，用RUP時還要做裁剪，也就是要對RUP進行配置。RUP就像一個元過程，通過對RUP進行裁剪可以得到很多不同的開發過程，這些軟件開發過程可以看作RUP的具體實例。RUP裁剪可以分為以下幾步：

1） 確定本項目需要哪些工作流。RUP的9個核心工作流並不總是需要的，可以取捨。

2） 確定每個工作流需要哪些製品。

3） 確定4個階段之間如何演進。確定階段間演進要以風險控制為原則，決定每個階段要哪些工作流，每個工作流執行到什麼程度，製品有哪些，每個製品完成到什麼程度。

4） 確定每個階段內的迭代計劃。規劃RUP的4個階段中每次迭代開發的內容。

5） 規劃工作流內部結構。工作流涉及角色、活動及製品，他的複雜程度與項目規模即角色多少有關。最後規劃工作流的內部結構，通常用活動圖的形式給出。

RUP中的軟件生命週期在時間上被分解為四個順序的階段，分別是：初始階段（Inception）、細化階段（Elaboration）、構造階段（Construction）和交付階段（Transition）。每個階段結束於一個主要的里程碑（Major Milestones）；每個階段本質上是兩個里程碑之間的時間跨度。在每個階段的結尾執行一次評估以確定這個階段的目標是否已經滿足。如果評估結果令人滿意的話，可以允許項目進入下一個階段。

初始階段的目標是為系統建立商業案例並確定項目的邊界。為了達到該目的必須識別所有與系統交互的外部實體，在較高層次上定義交互的特性。本階段具有非常重要的意義，在這個階段中所關注的是整個項目進行中的業務和需求方面的主要風險。對於建立在原有系統基礎上的開發項目來講，初始階段可能很短。初始階段結束時是第一個重要的里程碑：生命週期目標（Lifecycle Objective）里程碑。生命週期目標里程碑評價項目基本的生存能力。

細化階段的目標是分析問題領域，建立健全的體系結構基礎，編制項目計劃，淘汰項目中最高風險的元素。為了達到該目的，必須在理解整個系統的基礎上，對體系結構作出決策，包括其範圍、主要功能和諸如性能等非功能需求。同時為項目建立支持環境，包括創建開發案例，創建模板、準則並準備工具。細化階段結束時第二個重要的里程碑：生命週期結構（Lifecycle Architecture）里程碑。生命週期結構里程碑為系統的結構建立了管理基準並使項目小組能夠在構建階段中進行衡量。此刻，要檢驗詳細的系統目標和範圍、結構的選擇以及主要風險的解決方案。

在構建階段，所有剩餘的構件和應用程序功能被開發並集成為產品，所有的功能被詳細測試。從某種意義上説，構建階段是一個製造過程，其重點放在管理資源及控制運作以優化成本、進度和質量。構建階段結束時是第三個重要的里程碑：初始功能（Initial Operational）里程碑。初始功能里程碑決定了產品是否可以在測試環境中進行部署。此刻，要確定軟件、環境、用户是否可以開始系統的運作。此時的產品版本也常被稱為“beta”版。

交付階段的重點是確保軟件對最終用户是可用的。交付階段可以跨越幾次迭代，包括為發佈做準備的產品測試，基於用户反饋的少量的調整。在生命週期的這一點上，用户反饋應主要集中在產品調整，設置、安裝和可用性問題，所有主要的結構問題應該已經在項目生命週期的早期階段解決了。在交付階段的終點是第四個里程碑：產品發佈（Product Release）里程碑。此時，要確定目標是否實現，是否應該開始另一個開發週期。在一些情況下這個里程碑可能與下一個週期的初始階段的結束重合。

RUP中有9個核心工作流，分為6個核心過程工作流（Core Process Workflows）和3個核心支持工作流（Core Supporting Workflows）。儘管6個核心過程工作流可能使人想起傳統瀑布模型中的幾個階段，但應注意迭代過程中的階段是完全不同的，這些工作流在整個生命週期中一次又一次被訪問。9個核心工作流在項目中輪流被使用，在每一次迭代中以不同的重點和強度重複。

商業建模（Business Modeling）工作流描述瞭如何為新的目標組織開發一個構想，並基於這個構想在商業用例模型和商業對象模型中定義組織的過程，角色和責任。

需求（Requirement）工作流的目標是描述系統應該做什麼，並使開發人員和用户就這一描述達成共識。為了達到該目標，要對需要的功能和約束進行提取、組織、文檔化；最重要的是理解系統所解決問題的定義和範圍。

分析和設計（Analysis & Design）工作流將需求轉化成未來系統的設計，為系統開發一個健壯的結構並調整設計使其與實現環境相匹配，優化其性能。分析設計的結果是一個設計模型和一個可選的分析模型。設計模型是源代碼的抽象，由設計類和一些描述組成。設計類被組織成具有良好接口的設計包（Package）和設計子系統（Subsystem），而描述則體現了類的對象如何協同工作實現用例的功能。設計活動以體系結構設計為中心，體系結構由若干結構視圖來表達，結構視圖是整個設計的抽象和簡化，該視圖中省略了一些細節，使重要的特點體現得更加清晰。體系結構不僅僅是良好設計模型的承載媒介，而且在系統的開發中能提高被創建模型的質量。

實現（Implementation）工作流的目的包括以層次化的子系統形式定義代碼的組織結構；以組件的形式（源文件、二進制文件、可執行文件）實現類和對象；將開發出的組件作為單元進行測試以及集成由單個開發者（或小組）所產生的結果，使其成為可執行的系統。

測試（Test）工作流要驗證對象間的交互作用，驗證軟件中所有組件的正確集成，檢驗所有的需求已被正確的實現，識別並確認缺陷在軟件部署之前被提出並處理。RUP提出了迭代的方法，意味着在整個項目中進行測試，從而儘可能早地發現缺陷，從根本上降低了修改缺陷的成本。測試類似於三維模型，分別從可靠性、功能性和系統性能來進行。

部署（Deployment）工作流的目的是成功的生成版本並將軟件分發給最終用户。部署工作流描述了那些與確保軟件產品對最終用户具有可用性相關的活動，包括：軟件打包、生成軟件本身以外的產品、安裝軟件、為用户提供幫助。在有些情況下，還可能包括計劃和進行beta測試版、移植現有的軟件和數據以及正式驗收。

配置和變更管理工作流描繪瞭如何在多個成員組成的項目中控制大量的產物。配置和變更管理工作流提供了準則來管理演化系統中的多個變體，跟蹤軟件創建過程中的版本。工作流描述瞭如何管理並行開發、分佈式開發、如何自動化創建工程。同時也闡述了對產品修改原因、時間、人員保持審計記錄。

軟件項目管理（Project Management）平衡各種可能產生衝突的目標，管理風險，克服各種約束併成功交付使用户滿意的產品。其目標包括：為項目的管理提供框架，為計劃、人員配備、執行和監控項目提供實用的準則，為管理風險提供框架等。

環境（Environment）工作流的目的是向軟件開發組織提供軟件開發環境，包括過程和工具。環境工作流集中於配置項目過程中所需要的活動，同樣也支持開發項目規範的活動，提供了逐步的指導手冊並介紹瞭如何在組織中實現過程。

RUP中的每個階段可以進一步分解為迭代。一個迭代是一個完整的開發循環，產生一個可執行的產品版本，是最終產品的一個子集，它增量式地發展，從一個迭代過程到另一個迭代過程到成為最終的系統。傳統上的項目組織是順序通過每個工作流，每個工作流只有一次，也就是我們熟悉的瀑布生命週期（見圖2）。這樣做的結果是到實現末期產品完成並開始測試，在分析、設計和實現階段所遺留的隱藏問題會大量出現，項目可能要停止並開始一個漫長的錯誤修正週期。

一種更靈活，風險更小的方法是多次通過不同的開發工作流，這樣可以更好的理解需求，構造一個健壯的體系結構，並最終交付一系列逐步完成的版本。這叫做一個迭代生命週期。在工作流中的每一次順序的通過稱為一次迭代。軟件生命週期是迭代的連續，通過它，軟件是增量的開發。一次迭代包括了生成一個可執行版本的開發活動，還有使用這個版本所必需的其他輔助成分，如版本描述、用户文檔等。因此一個開發迭代在某種意義上是在所有工作流中的一次完整的經過，這些工作流至少包括：需求工作流、分析和設計工作流、實現工作流、測試工作流。其本身就像一個小型的瀑布項目（見圖3所示）。

圖3 RUP的迭代模型與傳統的瀑布模型相比較，迭代過程具有以下優點：

降低了在一個增量上的開支風險。如果開發人員重複某個迭代，那麼損失只是這一個開發有誤的迭代的花費。

降低了產品無法按照既定進度進入市場的風險。通過在開發早期就確定風險，可以儘早來解決而不至於在開發後期匆匆忙忙。

加快了整個開發工作的進度。因為開發人員清楚問題的焦點所在，他們的工作會更有效率。

由於用户的需求並不能在一開始就作出完全的界定，它們通常是在後續階段中不斷細化的。因此，迭代過程這種模式使適應需求的變化會更容易些。

有一個清晰的前景是開發一個滿足涉眾真正需求的產品的關鍵。前景抓住了RUP需求流程的要點：分析問題，理解涉眾需求，定義系統，當需求變化時管理需求。前景給更詳細的技術需求提供了一個高層的、有時候是合同式的基礎。正像這個術語隱含的那樣，它是軟件項目的一個清晰的、通常是高層的視圖，能被過程中任何決策者或者實施者借用。它捕獲了非常高層的需求和設計約束，讓前景的讀者能理解將要開發的系統。它還提供了項目審批流程的輸入，因此就與商業理由密切相關。最後，由於前景構成了“項目是什麼？”和“為什麼要進行這個項目？”，所以可以把前景作為驗證將來決策的方式之一。對前景的陳述應該能回答以下問題，需要的話這些問題還可以分成更小、更詳細的問題：關鍵術語是什麼？（詞彙表） 我們嘗試解決的問題是什麼？（問題陳述） 涉眾是誰？用户是誰？他們各自的需求是什麼？ 產品的特性是什麼？ 功能性需求是什麼？（Use Cases） 非功能性需求是什麼？ 設計約束是什麼？

“產品的質量只會和產品的計劃一樣好。” ⑵ 在RUP中，軟件開發計劃（SDP）綜合了管理項目所需的各種信息，也許會包括一些在先啓階段開發的單獨的內容。SDP必須在整個項目中被維護和更新。SDP定義了項目時間表（包括項目計劃和迭代計劃）和資源需求（資源和工具），可以根據項目進度表來跟蹤項目進展。同時也指導了其他過程內容（原文：process components）的計劃：項目組織、需求管理計劃、配置管理計劃、問題解決計劃、QA計劃、測試計劃、評估計劃以及產品驗收計劃。

在較簡單的項目中，對這些計劃的陳述可能只有一兩句話。比如，配置管理計劃可以簡單的這樣陳述：每天結束時，項目目錄的內容將會被壓縮成ZIP包，拷貝到一個ZIP磁盤中，加上日期和版本標籤，放到中央檔案櫃中。軟件開發計劃的格式遠遠沒有計劃活動本身以及驅動這些活動的思想重要。正如Dwight D.Eisenhower所説：“plan什麼也不是，planning才是一切。” “達成計劃”—和列表中第3、4、5、8條一起—抓住了RUP中項目管理流程的要點。項目管理流程包括以下活動：構思項目、評估項目規模和風險、監測與控制項目、計劃和評估每個迭代和階段。

RUP的要點之一是在項目早期就標識並處理最大的風險。項目組標識的每一個風險都應該有一個相應的緩解或解決計劃。風險列表應該既作為項目活動的計劃工具，又作為確定迭代的基礎。

有一點在任何項目中都是重要的，即連續的分析來源於正在進行的活動和進化的產品的客觀數據。在RUP中，定期的項目狀態評估提供了講述、交流和解決管理問題、技術問題以及項目風險的機制。團隊一旦發現了這些障礙物（籬笆），他們就把所有這些問題都指定一個負責人，並指定解決日期。進度應該定期跟蹤，如有必要，更新應該被髮布。（原文：updates should be issued as necessary。） 這些項目“快照”突出了需要引起管理注意的問題。隨着時間的變化/雖然週期可能會變化（原文：While the period may vary。），定期的評估使經理能捕獲項目的歷史，並且消除任何限制進度的障礙或瓶頸。

商業理由從商業的角度提供了必要的信息，以決定一個項目是否值得投資。商業理由還可以幫助開發一個實現項目前景所需的經濟計劃。它提供了進行項目的理由，並建立經濟約束。當項目繼續時，分析人員用商業理由來正確的估算投資回報率（ROI，即return on investment）。商業理由應該給項目創建一個簡短但是引人注目的理由，而不是深入研究問題的細節，以使所有項目成員容易理解和記住它。在關鍵里程碑處，經理應該回顧商業理由，計算實際的花費、預計的回報，決定項目是否繼續進行。

在RUP中，件系統的構架是指一個系統關鍵部件的組織或結構，部件之間通過接口交互，而部件是由一些更小的部件和接口組成的。即主要的部分是什麼？他們又是怎樣結合在一起的？ RUP提供了一種設計、開發、驗證構架的很系統的方法。在分析和設計流程中包括以下步驟：定義候選構架、精化構架、分析行為（用例分析）、設計組件。要陳述和討論軟件構架，你必須先創建一個構架表示方式，以便描述構架的重要方面。在RUP中，構架表示由軟件構架文檔捕獲，它給構架提供了多個視圖。每個視圖都描述了某一組涉眾所關心的正在進行的系統的某個方面。涉眾有最終用户、設計人員、經理、系統工程師、系統管理員，等等。這個文檔使系統構架師和其他項目組成員能就與構架相關的重大決策進行有效的交流。

在RUP中實現和測試流程的要點是在整個項目生命週期中增量的編碼、構建、測試系統組件，在先啓之後每個迭代結束時生成可執行版本。在精化階段後期，已經有了一個可用於評估的構架原型；如有必 要，它可以包括一個用户界面原型。然後，在構建階段的每次迭代中，組件不斷的被集成到可執行、經過測試的版本中，不斷地向最終產品進化。動態及時的配置管理和複審活動也是這個基本過程元素（原文：essential process element）的關鍵。

顧名思義，RUP的迭代評估捕獲了迭代的結果。評估決定了迭代滿足評價標準的程度，還包括學到的教訓和實施的過程改進。根據項目的規模和風險以及迭代的特點，評估可以是對演示及其結果的一條簡單的紀錄，也可能是一個完整的、正式的測試複審記錄。這兒的關鍵是既關注過程問題又關注產品問題。越早發現問題，就越沒有問題。（原文：The sooner you fall behind，the more time you will have to catch up.）

RUP的配置和變更管理流程的要點是當變化發生時管理和控制項目的規模，並且貫穿整個生命週期。其目的是考慮所有的涉眾需求，儘可能的滿足，同時仍能及時的交付合格的產品。用户拿到產品的第一個原型後（往往在這之前就會要求變更），他們會要求變更。重要的是，變更的提出和管理過程始終保持一致。在RUP中，變更請求通常用於記錄和跟蹤缺陷和增強功能的要求，或者對產品提出的任何其他類型的變更請求。變更請求提供了相應的手段來評估一個變更的潛在影響，同時記錄就這些變更所作出的決策。他們也幫助確保所有的項目組成員都能理解變更的潛在影響。

在RUP中，部署流程的要點是包裝和交付產品，同時交付有助於最終用户學習、使用和維護產品的任何必要的材料。項目組至少要給用户提供一個用户指南（也許是通過聯機幫助的方式提供），可能還有一個安裝指南和版本發佈説明。根據產品的複雜度，用户也許還需要相應的培訓材料。最後，通過一個材料清單（BOM表，即Bill of Materials）清楚地記錄應該和產品一起交付哪些材料。關於需求有人看了我的要素清單後，可能會非常不同意我的選擇。例如，他會問，需求在哪兒呢？他們不重要嗎？我會告訴他我為什麼沒有把它們包括進來。有時，我會問一個項目組（特別是內部項目的項目組）：“你們的需求是什麼？”，而得到的回答卻是：“我們的確沒有什麼需求。” 剛開始我對此非常驚訝（我有軍方的宇航開發背景）。他們怎麼會沒有需求呢？當我進一步詢問時，我發現，對他們來説，需求意味着一套外部提出的強制性的陳述，要求他們必須怎麼樣，否則項目驗收就不能通過。但是他們的確沒有得到這樣的陳述。尤其是當項目組陷入了邊研究邊開發的境地時，產品需求從頭到尾都在演化。因此，我接着問他們另外一個問題：“好的，那麼你們的產品的前景是什麼呢？”。這時他們的眼睛亮了起來。然後，我們非常順利的就第一個要素（“開發一個前景”）中列出的問題進行了溝通，需求也自然而然的流動着（原文：and the requirements just flow naturally.）。也許只有對於按照有明確需求的合同工作的項目組，在要素列表中加入“滿足需求”才是有用的。請記住，我的清單僅僅意味着進行進一步討論的一個起點。

RUP具有很多長處：提高了團隊生產力，在迭代的開發過程、需求管理、基於組件的體系結構、可視化軟件建模、驗證軟件質量及控制軟件變更等方面，針對所有關鍵的開發活動為每個開發成員提供了必要的準則、模板和工具指導，並確保全體成員共享相同的知識基礎。它建立了簡潔和清晰的過程結構，為開發過程提供較大的通用性。但同時它也存在一些不足：RUP只是一個開發過程，並沒有涵蓋軟件過程的全部內容，例如它缺少關於軟件運行和支持等方面的內容；此外，它沒有支持多項目的開發結構，這在一定程度上降低了在開發組織內大範圍實現重用的可能性。可以説RUP是一個非常好的開端，但並不完美，在實際的應用中可以根據需要對其進行改進並可以用OPEN和OOSP等其他軟件過程的相關內容對RUP進行補充和完善。

1、RUP是風險驅動的、基於Use Case技術的、以架構為中心的、迭代的、可配置的軟件開發流程。

2、我們可以針對RUP所規定出的流程，進行客户化定製，定製出適合自己組織的實用的軟件流程。

因此RUP是一個流程定義平台，是一個流程框架。

它們的基礎都是面向對象方法(取代傳統的結構化方法)都重視代碼、文檔的最小化和設計的簡化，採用動態適應變化的演進式迭代週期(取代傳統的瀑布型生命週期)、需求和測試驅動並鼓勵用户積極參與等。 ^[3] 

RUP細化階段的主要目的就是構造出一個可運行的架構原型，作為將來添加需求功能的穩固基礎;而XP沒有包含業務建模、部署等概念，反映了它以編程為中心，節省一切的思想。 ^[3]