標籤：
更詳細的見：http://www.ibm.com/developerworks/cn/rational/r-rupbp/
本文引用：http://baike.baidu.com/view/2235832.htm#sub2235832
統一軟體開發過程（Rational Unified Process,RUP)是一個物件導向且基於網路的程式開發方法論。它是用例驅動的，以架構為核心，迭代和增量的軟體過程架構，它提供一種演化的特性。
二維結構
開發過程可以用二維結構或沿著兩個座標軸來表達：
- 橫軸代表了制訂開發過程時的時間，體現了過程的動態結構。它以術語周期（cycle）、階段(phase)、迭代（iteration）和裡程碑(milestone)來表達。
- 縱軸表現了過程的靜態結構：如何用術語活動（activity）、產物(artifact)、 角色(worker)和工作流程(workflow)來描述。
RUP中的軟體生命週期在時間上被分解為四個順序的階段，分別是：初始階段(Inception)、細化階段(Elaboration)、構造階段(Construction)和交付階段(Transition)。每個階段結束於一個主要的裡程碑(Major Milestones)；每個階段本質上是兩個裡程碑之間的時間跨度。在每個階段的結尾執行一次評估以確定這個階段的目標是否已經滿足。如果評估結果令人滿意的話，可以允許項目進入下一個階段。
1． 初始階段
- 初始階段的目標是為系統建立商業案例和確定項目的邊界。
為了達到該目的必須識別所有與系統互動的外部實體，在較高層次上定義互動的特性。它包括識別所有用例和描述一些重要的用例。商業案例包括驗收規範、風險評估、所需資源估計、體現主要裡程碑日期的階段計劃。本階段具有非常重要的意義，在這個階段中，關注的是整個項目進行工程中的業務和需求方面的主要風險。對於建立在原有系統基礎上的開發項目來說，初始階段的時間可能很短。
本階段的主要目標如下：
明確軟體系統的範圍和邊界條件，括從功能角度的前景分析、產品驗收標準和哪些做與哪些不做的相關決定
明確區分系統的關鍵用例（Use-case） 和主要的功能情境
展現或者示範至少一種符合主要情境要求的候選軟體體繫結構
對整個項目做最初的項目成本和議程估計(更詳細的估計將在隨後的細化階段中做出)
估計出潛在的風險(主要指各種不確定因素造成的潛在風險)
準備好項目的支援環境
初始階段的產出是:
藍圖文檔核心項目需求關鍵特色主要約束的總體藍圖
原始用例模型(完成10%～20%)
原始項目術語表(可能部分表達為業務模型)
原始商業案例,包括業務的上下文、驗收規範（年度映射、市場認可等等），成本預計
原始的風險評估
一個或多個原型
裡程碑：生命週期的目標
- 初始階段的評審標準：
風險承擔者就範圍定義成本議程估計達成共識
以客觀的主要用例證實對需求的理解
成本/議程、優先順序、風險和開發過程的可信度
被開發體繫結構原型的深度和廣度
實際開支與計劃開支的比較
如果無法通過這些裡程碑，則項目可能被取消或仔細地重新考慮。
2． 細化階段
- 細化階段的目標是分析問題領域，建立健全的體繫結構基礎，編製專案計劃，淘汰項目中最高風險的元素。
為了達到該目的，必須對系統具有"英裡寬和英寸深"的觀察。體繫結構的決策必須在理解整個系統的基礎上作出：它的範圍，主要功能和如效能等非功能性需求。
容易引起爭論，細化階段是四個階段中最關鍵的階段。該階段結束時，硬"工程"可以認為已結束，項目則經曆最後的審判日：決策是否項目提交給構建和交付階段。對於大多數項目，這也相當於從移動的、輕鬆的、靈巧的、低風險的運作過渡到高成本、高風險並帶有較大慣性的運作過程。而過程必須能容納變化，細化階段活動確保了結構、需求和計劃是足夠穩定的，風險被充分減輕，所以可以為開發結果預先決定成本和排程。概念上，其逼真程度一致於機構實行費用固定的構建階段的必要程度。在細化階段，可執行檔結構原形在一個或多個迭代過程中建立，依賴於項目的範圍、規模、風險和先進程度。工作量必須至少處理初始階段中識別的關鍵用例，關鍵用例典型揭示了項目主要技術的風險。通常我們的目標是一個由產品品質層級構件組成的可進化的原型，但這並不排除開發一個或多個探索性、可拋棄的原型來減少如：設計/需求折衷，構件可行性研究，或者給投資者、顧客即終端使用者示範版本等特定的風險。
本階段的主要目標如下：
確保軟體結構、需求、計劃足夠穩定；確保項目風險已經降低到能夠預計完成整個項目的成本和議程的程度。
針對項目的軟體結構上的主要風險已經解決或處理完成。
通過完成軟體結構上的主要情境建立軟體體繫結構的基準。
建立一個包含高品質組件的可演化的產品原型。
說明基準化的軟體體繫結構可以保障系統需求可以控制在合理的成本和時間範圍內。
建立好產品的支援環境。
初始階段的產出是：
用例模型（完成至少80％）-- 所有用例均被識別，大多數用例描述被開發
補充捕獲非功能性要求和非關聯於特定用例要求的需求
軟體體繫結構描述_可執行檔軟體原型
經修訂過的風險清單和商業案例
總體項目的開發計劃，包括紋理較粗糙的專案計劃，顯示迭代過程和對應的審核標準
指明被使用過程的更新過的開發用例
使用者手冊的初始版本（可選）
裡程碑：生命週期的結構
-
細化階段結束是第二個重要的裡程碑：生命週期的結構裡程碑。此刻，檢驗詳細的系統目標
和範圍、結構的選擇以及主要風險的解決方案。 主要的審核標準包括回答以下的問題：
產品的藍圖是否穩定？
體繫結構是否穩定？
可執行檔示範版是否顯示風險要素已被處理和可靠的解決
構建階段的計劃是否足夠詳細和精確？是否被可靠的審核基礎支援？
如果當前計劃在現有的體繫結構環境中被執行而開發出完整系統，是否所有的風險承擔人同意該藍圖是可實現的？
實際的費用開支與計劃開支是否可以接受？
如果無法通過這些裡程碑，則項目可能被取消或仔細地重新考慮。
3． 構造階段
- 在構建階段,所有剩餘的構件和應用程式功能被開發並整合為產品,所有的功能被詳盡的測試。
構建階段，從某種意義上說，是重點在管理資源和控制運作以最佳化成本、議程、品質的生產過程。就這一點而言，管理的理念經曆了初始階段和細化階段的智力資產開發到構建階段和交付階段可發布產品的過渡。許多項目規模大的足夠產生許多平行的增量構建過程，這些平行的活動可以極大地加速版本發布的有效性；同時也增加了資源管理和工作流程同步的複雜性。健壯的體繫結構和易於理解的計劃是高度關聯的。換言之，體繫結構上關鍵的品質是構建的容易程度。這也是在細化階段平衡的體繫結構和計劃被強調的原因。
本階段的主要目標如下：
通過最佳化資源和避免不必要的返工達到開發成本的最小化
根據實際需要達到適當的品質目標
據實際需要形成各個版本（Alpha,Beta,and other test release）
對所有必須的功能完成分析、設計、開發與測試工作
採用迴圈漸進的方式開發出一個可以提交給終端使用者的完整產品
確定軟體網站使用者都為產品的最終部署做好了相關準備
達成一定程度上的並行開發機制
構建階段的產出是可以交付給終端使用者的產品。它最小包括：
特定平台上的整合產品
使用者手冊
目前的版本的描述
裡程碑：初始運作能力
- 建立階段結束是第三個重要的項目裡程碑（初始功能裡程碑）。此刻，決定是否軟體、環境、使用者可以運作而不會將項目暴露在高度風險下。該版本也常被稱為"beta"版。
構建階段主要的審核標準包括回答以下的問題:
產品是否足夠穩定和成熟得發布給使用者?
是否所有的風險承擔人準備好向使用者移交?
實際費用與計劃費用的比較是否仍可被接受?
如果無法通過這些裡程碑,則移交不得不被延遲。
4． 交付階段
- 交付階段的目的是將軟體產品交付給使用者群體。
只要產品發布給終端使用者，問題常常就會出現：要求開發新版本，糾正問題或完成被延遲的問題。當基準成熟得足夠發布到終端使用者時，就進入了交付階段。其典型要求一些可用的系統子集被開發到可接收的品質層級及使用者文檔可供使用，從而交付給使用者的所有部分均可以有正面的效果。這包括：
對照使用者期望值，驗證新系統的"beta測試"
與被替代的已有系統並軌
功能性資料庫的轉換
向市場、部署、銷售團隊移交產品
構建階段關注於向使用者提交產品的活動。典型的，該階段包括若干重複過程，包括 beba 版本、通用版本、bug 修補版和增強版。相當大的工作量消耗在開發面向使用者的文檔，培訓使用者。在初始產品使用時，支援使用者並處理使用者的反饋。開發生命週期的該點，使用者反饋主要限定在產品效能調整、配置、安裝和使用問題。
本階段的目標是確保軟體產品可以提交給終端使用者。本階段根據實際需要可以分為幾個迴圈。
- 本階段的具體目標如下：
進行 Beta 測試以期達到終端使用者的需要
進行 Beta 測試和舊系統的並軌
轉換功能資料庫
對終端使用者和產品技術服務人員的培訓
提交給市場和產品銷售部門
和具體部署相關的工程活動
協調 Bug 修訂/改進效能和可用性(Usability)等工作
基於完整的 Vision 和產品驗收標準對最終部署做出評估
達到使用者要求的滿意度
達成各風險承擔人對產品部署基準已經完成的共識
達成各風險承擔人對產品部署符合 Vision 中標準的共識
該階段依照產品的類型,可能從非常簡單到極端複雜的範圍內變化。例如，現有的案頭產品的新版本可能非常簡單，而替代國際機場的流量系統會非常複雜。
裡程碑：產品發布
- 在交付階段的終點是第四個重要的項目裡程碑，產品發布裡程碑。此時，決定是否目標已達到或開始另一個周期。在許多情況下，裡程碑會與下一個周期的初始階段相重疊。
發布階段的審核標準主要包括以下兩個問題：
使用者是否滿意？
實際費用與計劃費用的比較是否仍可被接受？
RUP中有9個核心工作流程，分為6個核心過程工作流程(Core Process Workflows)和3個核心支援工作流程(Core Supporting Workflows)。儘管6個核心過程工作流程可能使人想起傳統瀑布模型中的幾個階段，但應注意迭代過程中的階段是完全不同的，這些工作流程在整個生命週期中一次又一次被訪問。9個核心工作流程在項目中輪流被使用，在每一次迭代中以不同的重點和強度重複。
1． 商業建模(Business Modeling)
商業建模工作流程描述了如何為新的目標組織開發一個構想，並基於這個構想在商業用例模型和商業物件模型中定義組織的過程，角色和責任。
2． 需求(Requirements)
需求工作流程的目標是描述系統應該做什麼，並使開發人員和使用者就這一描述達成共識。為了達到該目標，要對需要的功能和約束進行提取、組織、文檔化；最重要的是理解系統所解決問題的定義和範圍。藍圖被建立，需求被提取。代表使用者和其他可能與開發系統互動的其它系統的 Actor 被指明。Use case 被識別,表示系統的行為。因為use case 根據 actor 的要求開發,系統與使用者之間的聯絡更緊密。系統展示了用於再生系統的用例模型。
3. 分析和設計(Analysis & Design)
分析和設計工作流程將需求轉化成未來系統的設計，為系統開發一個健壯的結構並調整設計使其與實現環境相匹配，最佳化其效能。分析設計的結果是一個設計模型和一個可選的分析模型。設計模型是原始碼的抽象，由設計類和一些描述組成。設計類被組織成具有良好介面的設計包(Package)和設計子系統(Subsystem)，而描述則體現了類的對象如何協同工作實現用例的功能。 設計活動以體繫結構設計為中心，體繫結構由若干結構視圖來表達，結構視圖是整個設計的抽象和簡化，該視圖中省略了一些細節，使重要的特點體現得更加清晰。體繫結構不僅僅是良好設計模型的承載媒介，而且在系統的開發中能提高被建立模型的品質。
4． 實現(Implementation)
實現工作流程的目的包括以層次化的子系統形式定義代碼的組織圖；以組件的形式(源檔案、二進位檔案、可執行檔)實作類別和對象；將開發出的組件作為單元進行測試以及整合由單個開發人員（或小組）所產生的結果，使其成為可執行檔系統。
5． 測試(Test)
測試工作流程要驗證對象間的互動作用，驗證軟體中所有組件的正確整合，檢驗所有的需求已被正確的實現, 識別並確 認缺陷在軟體部署之前被提出並處理。RUP提出了迭代的方法，意味著在整個項目中進行測試，從而儘可能早地發現缺陷，從根本上降低了修改缺陷的成本。測試類別似於3D 模型，分別從可靠性、功能性和系統效能來進行。
6． 部署(Deployment)
部署工作流程的目的是成功的產生版本並將軟體分發給終端使用者。部署工作流程描述了那些與確保軟體產品對終端使用者具有可用性相關的活動，包括：軟體打包、產生軟體本身以外的產品、安裝軟體、為使用者提供協助。在有些情況下，還可能包括計劃和進行beta測試版、移植現有的軟體和資料以及正式驗收。
7． 配置和變更管理 (Configuration & Change Management)
配置和變更管理工作流程描繪了如何在多個成員組成的項目中控制大量的產物。配置和變更管理工作流程提供了準則來管理演化系統中的多個變體，跟蹤軟體建立過程中的版本。工作流程描述了如何管理並行開發、分布式開發、如何自動化建立工程。同時也闡述了對產品修改原因、時間、人員保持審計記錄。
8． 專案管理(Project Management)
軟體專案管理平衡各種可能產生衝突的目標，管理風險，克服各種約束並成功交付使使用者滿意的產品。其目標包括：為項目的管理提供架構，為計劃、人員配備、執行和監控項目提供實用的準則，為管理風險提供架構等。
9． 環境(Environment)
環境工作流程的目的是向軟體開發組織提供軟體開發環境，包括過程和工具。環境工作流程集中於設定項目過程中所需要的活動，同樣也支援開發項目規範的活動，提供了逐步的指導手冊並介紹了如何在組織中實現過程。
RUP---統一軟體開發過程
