統(tǒng)一軟件開發(fā)過程（RUP）又稱為統(tǒng)一軟件過程，是一個面向?qū)ο笄一诰W(wǎng)絡的程序開發(fā)方法論。根據(jù)Rational(Rational Rose和統(tǒng)一建模語言的開發(fā)者)的說法，好像一個在線的指導者，它可以為所有方面和層次的程序開發(fā)提供指導方針，模版以及事例支持。統(tǒng)一軟件開發(fā)過程和類似的產(chǎn)品，如面向?qū)ο蟮能浖^程（OOSP），以及OPEN Process都是理解性的軟件工程工具，把開發(fā)中面向過程的方面（例如定義的階段，技術和實踐）和其他開發(fā)的組件（例如文檔，模型，手冊以及代碼等等）整合在一個統(tǒng)一的框架內(nèi)。

RUP軟件開發(fā)生命周期是一個二維的軟件開發(fā)模型。橫軸通過時間組織，是過程展開的生命周期特征，體現(xiàn)開發(fā)過程的動態(tài)結構，用來描述它的術語主要包括周期(Cycle)、階段(Phase)、迭代 (Iteration)和里程碑(Milestone)；縱軸以內(nèi)容來組織為自然的邏輯活動，體現(xiàn)開發(fā)過程的靜態(tài)結構，用來描述它的術語主要包括活動 (Activity)、產(chǎn)物(Artifact)、工作者(Worker)和工作流(Workflow)。如下圖：

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

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

2、確定每個工作流需要哪些制品。

3、確定4個階段之間如何演進。確定階段間演進要以風險控制為原則，決定每個階段要那些工作流，每個工作流執(zhí)行到什么程度，制品有那些，每個制品完成到什么程度。

4、確定每個階段內(nèi)的迭代計劃。規(guī)劃RUP的4個階段中每次迭代開發(fā)的內(nèi)容。

5、規(guī)劃工作流內(nèi)部結構。工作流涉及角色、活動及制品，他的復雜程度與項目規(guī)模即角色多少有關。最后規(guī)劃工作流的內(nèi)部結構，通常用活動圖的形式給出。

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

1、初始階段

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

2、細化階段

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

3、構造階段

在構建階段，所有剩余的構件和應用程序功能被開發(fā)并集成為產(chǎn)品，所有的功能被詳細測試。從某種意義上說，構建階段是一個制造過程，其重點放在管理資源及控制運作以優(yōu)化成本、進度和質(zhì)量。 構建階段結束時是第三個重要的里程碑：初始功能(Initial Operational)里程碑。初始功能里程碑決定了產(chǎn)品是否可以在測試環(huán)境中進行部署。此刻，要確定軟件、環(huán)境、用戶是否可以開始系統(tǒng)的運作。此時的產(chǎn)品版本也常被稱為“beta”版。

4、交付階段

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

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

1、商業(yè)建模(Business Modeling)

商業(yè)建模工作流描述了如何為新的目標組織開發(fā)一個構想，并基于這個構想在商業(yè)用例模型和商業(yè)對象模型中定義組織的過程，角色和責任。

2、需求(Requirements)

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

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

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

4、實現(xiàn)(Implementation)

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

5、測試(Test)

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

6、部署(Deployment)

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

7、配置和變更管理(Configuration & Change Management)

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

8、項目管理(Project Management)

軟件項目管理平衡各種可能產(chǎn)生沖突的目標，管理風險，克服各種約束并成功交付使用戶滿意的產(chǎn)品。其目標包括：為項目的管理提供框架，為計劃、人員配備、執(zhí)行和監(jiān)控項目提供實用的準則，為管理風險提供框架等。

9、環(huán)境(Environment)

環(huán)境工作流的目的是向軟件開發(fā)組織提供軟件開發(fā)環(huán)境，包括過程和工具。環(huán)境工作流集中于配置項目過程中所需要的活動，同樣也支持開發(fā)項目規(guī)范的活動，提供了逐步的指導手冊并介紹了如何在組織中實現(xiàn)過程。

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

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

與傳統(tǒng)的瀑布模型相比較，迭代過程具有以下優(yōu)點：

1）降低了在一個增量上的開支風險。如果開發(fā)人員重復某個迭代，那么損失只是這一個開發(fā)有誤的迭代的花費。

2）降低了產(chǎn)品無法按照既定進度進入市場的風險。通過在開發(fā)早期就確定風險，可以盡早來解決而不至于在開發(fā)后期匆匆忙忙。

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

4）由于用戶的需求并不能在一開始就作出完全的界定，它們通常是在后續(xù)階段中不斷細化的。因此，迭代過程這種模式使適應需求的變化會更容易些。

1、開發(fā)一個前景

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

2、達成計劃

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

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

3、標識和減小風險

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

4、分配和跟蹤任務

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

5、檢查商業(yè)理由

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

6、設計組件構架

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

7、對產(chǎn)品進行增量式的構建和測試

在RUP中實現(xiàn)和測試流程的要點是在整個項目生命周期中增量的編碼、構建、測試系統(tǒng)組件，在先啟之后每個迭代結束時生成可執(zhí)行版本。在精化階段后期，已經(jīng)有了一個可用于評估的構架原型;如有必要，它可以包括一個用戶界面原型。然后，在構建階段的每次迭代中，組件不斷的被集成到可執(zhí)行、經(jīng)過測試的版本中，不斷地向最終產(chǎn)品進化。動態(tài)及時的配置管理和復審活動也是這個基本過程元素(原文：essential process element)的關鍵。

8、驗證和評價結果

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

9、管理和控制變化

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

10、提供用戶支持

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

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