RUP軟件開發設計模式

RUP（Rational Unified Process，統一軟件開發過程，統一軟件過程)是一個面向對象且基於網絡的程序開發方法論。根據Rational(Rational Rose和統一建模語言的開發者)的說法，好像一個在線的指導者，它能夠爲全部方面和層次的程序開發提供指導方針，模版以及事例支持。 RUP和相似的產品--例如面向對象的軟件過程（OOSP），以及OPEN Process都是理解性的軟件工程工具--把開發中面向過程的方面（例如定義的階段，技術和實踐）和其餘開發的組件（例如文檔，模型，手冊以及代碼等等）整合在一個統一的框架內。

　　1、六大經驗

　　一、迭代式開發。在軟件開發的早期階段就想徹底、準確的捕獲用戶的需求幾乎是不可能的。實際上，咱們常常遇到的問題是需求在整個軟件開發工程中常常會改變。迭代式開發容許在每次迭代過程當中需求可能有變化，經過不斷細化來加深對問題的理解。迭代式開發不只能夠下降項目的風險，並且每一個迭代過程均可以執行版本結束，能夠鼓舞開發人員。

　　二、管理需求。肯定系統的需求是一個連續的過程，開發人員在開發系統以前不可能徹底詳細的說明一個系統的真正需求。RUP描述瞭如何提取、組織系統的功能和約束條件並將其文檔化，用例和腳本的使用以被證實是捕獲功能性需求的有效方法。

　　三、基於組件的體系結構。組件使重用成爲可能，系統能夠由組件組成。基於獨立的、可替換的、模塊化組件的體系結構有助於管理複雜性，提升重用率。RUP描述瞭如何設計一個有彈性的、能適應變化的、易於理解的、有助於重用的軟件體系結構。

　　四、可視化建模。RUP每每和UML聯繫在一塊兒，對軟件系統創建可視化模型幫助人們提供管理軟件複雜性的能力。RUP告訴咱們如何可視化的對軟件系統建模，獲取有關體系結構於組件的結構和行爲信息。

　　五、驗證軟件質量。在RUP中軟件質量評估再也不是過後進行或單獨小組進行的分離活動，而是內建於過程當中的全部活動，這樣能夠及早發現軟件中的缺陷。

　　六、控制軟件變動。迭代式開發中若是沒有嚴格的控制和協調，整個軟件開發過程很快就陷入混亂之中，RUP描述瞭如何控制、跟蹤、監控、修改以確保成功的迭代開發。RUP經過軟件開發過程當中的製品，隔離來自其餘工做空間的變動，以此爲每一個開發人員創建安全的工做空間。

　　2、統一軟件開發過程RUP的二維開發模型

　　RUP軟件開發生命週期是一個二維的軟件開發模型。橫軸經過時間組織，是過程展開的生命週期特徵，體現開發過程的動態結構，用來描述它的術語主要包括週期(Cycle)、階段(Phase)、迭代(Iteration)和里程碑(Milestone)；縱軸之內容來組織爲天然的邏輯活動，體現開發過程的靜態結構，用來描述它的術語主要包括活動(Activity)、產物(Artifact)、工做者(Worker)和工做流(Workflow)。如圖1：

　　3、統一軟件開發過程RUP核心概念

　　RUP中定義了一些核心概念，以下圖：

RUP核心概念

 

　　角色：描述某我的或者一個小組的行爲與職責。RUP預先定義了不少角色。

　　活動：是一個有明確目的的獨立工做單元。

　　工件：是活動生成、建立或修改的一段信息。

　　4、統一軟件開發過程RUP裁剪

　　RUP是一個通用的過程模板，包含了不少開發指南、製品、開發過程所涉及到的角色說明，因爲它很是龐大因此對具體的開發機構和項目，用RUP時還要作裁剪，也就是要對RUP進行配置。RUP就像一個元過程，經過對RUP進行裁剪能夠獲得不少不一樣的開發過程，這些軟件開發過程能夠看做RUP的具體實例。RUP裁剪能夠分爲如下幾步：

　　1) 肯定本項目須要哪些工做流。RUP的9個核心工做流並不老是須要的，能夠取捨。

　　2) 肯定每一個工做流須要哪些製品。

　　3) 肯定4個階段之間如何演進。肯定階段間演進要以風險控制爲原則，決定每一個階段要那些工做流，每一個工做流執行到什麼程度，製品有那些，每一個製品完成到什麼程度。

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

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

　　5、開發過程當中的各個階段和里程碑

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

　　1． 初始階段

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

　　2． 細化階段

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

　　3． 構造階段

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

　　4． 交付階段

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

　　6、統一軟件開發過程RUP的核心工做流(Core Workflows)

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

　　1． 商業建模(Business Modeling)

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

　　2． 需求(Requirements)

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

　　3． 分析和設計(Analysis & Design)

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

　　4． 實現(Implementation)

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

　　5． 測試(Test)

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

　　6． 部署(Deployment)

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

　　7． 配置和變動管理(Configuration & Change Management)

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

　　8． 項目管理(Project Management)

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

　　9． 環境(Environment)

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

　　7、RUP的迭代開發模式

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

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

　　圖3 RUP的迭代模型

RUP的迭代模型

 

　　與傳統的瀑布模型相比較，迭代過程具備如下優勢：

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

　　下降了產品沒法按照既定進度進入市場的風險。經過在開發早期就肯定風險，能夠儘早來解決而不至於在開發後期匆匆忙忙。

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

　　因爲用戶的需求並不能在一開始就做出徹底的界定，它們一般是在後續階段中不斷細化的。所以，迭代過程這種模式使適應需求的變化會更容易些。

　　8、統一軟件開發過程RUP的十大要素
　　

　　1. 開發前景

　　2. 達成計劃

　　3. 標識和減少風險

　　4. 分配和跟蹤任務。。

　　5. 檢查商業理由

　　6. 設計組件構架

　　7. 對產品進行增量式的構建和測試

　　8. 驗證和評價結果

　　9. 管理和控制變化

　　10. 提供用戶支持

　　讓咱們逐一的審視這些要素，看一看它們什麼地方適合ＲＵＰ，找出它們可以成爲十大要素的理由。

　　1. 開發一個前景

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

　　2. 達成計劃

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

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

　　3. 標識和減少風險

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

　　4. 分配和跟蹤任務

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

　　5. 檢查商業理由

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

　　6. 設計組件構架

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

　　7. 對產品進行增量式的構建和測試

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

　　8. 驗證和評價結果

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

　　9. 管理和控制變化

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

　　10. 提供用戶支持

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

　　9、總結

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