RUP

RUP

一 前言
軟件過程是指實施於軟件開發和維護中的階段、方法、技術、實踐及相關產物(計劃、文檔、模型、代碼、測試用例和手冊等)的集合。行之有效的軟件過程可以提高開發軟件組織的生產效率、提高軟件質量、降低成本並減少風險。

RUP具有較高認知度的原因之一恐怕是因為其提出者Rational軟件公司聚集了物件導向領域三位傑出專家Booch、Rumbaugh和 Jacobson，同時它又是物件導向開發的行業標準語言——標準建模語言(UML)的創立者。RUP是由Objectory過程演化而來。本文主要討論 RUP的主要內容和特點。

二 RUP的二維開發模型

RUP可以用二維坐標來描述。橫軸通過時間組織，是過程展開的生命週期特徵，體現開發過程的動態結構，用來描述它的術語主要包括週期 (Cycle)、階段(Phase)、迭代(Iteration)和里程碑(Milestone)；縱軸以內容來組織為自然的邏輯活動，體現開發過程的靜態結構，用來描述它的術語主要包括活動(Activity)、產物(Artifact)、工作者(Worker)和工作流(Workflow)。

三 開發過程中的各個階段和里程碑

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

初始階段(Inception Phase)

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

初始階段結束時是第一個重要的里程碑：生命週期目標(Lifecycle Objective)里程碑。生命週期目標里程碑評價項目基本的生存能力。

細化階段(Elaboration Phase)

細化階段的目標是分析問題領域，建立健全的體系結構基礎，編製項目計劃，淘汰項目中最高風險的元素。為了達到該目的，必須在理解整個系統的基礎上，對體系結構作出決策，包括其範圍、主要功能和諸如性能等非功能需求。同時為項目建立支持環境，包括創建開發案例，創建模板、準則並準備工具。

細化階段結束時第二個重要的里程碑：生命週期結構(Lifecycle Architecture)里程碑。生命週期結構里程碑為系統的結構建立了管理基準並使項目小組能夠在構建階段中進行衡量。此刻，要檢驗詳細的系統目標和範圍、結構的選擇以及主要風險的解決方案。

構建階段(Construction Phase)

在構建階段，所有剩餘的構件和應用程序功能被開發並集成為產品，所有的功能被詳細測試。從某種意義上說，構建階段是一個製造過程，其重點放在管理資源及控制運作以優化成本、進度和質量。

構建階段結束時是第三個重要的里程碑：初始功能(Initial Operational)里程碑。初始功能里程碑決定了產品是否可以在測試環境中進行部署。此刻，要確定軟件、環境、用戶是否可以開始系統的運作。此時的產品版本也常被稱為「beta」版。

交付階段(Transition Phase)

交付階段的重點是確保軟件對最終用戶是可用的。交付階段可以跨越幾次迭代，包括為發佈做準備的產品測試，基於用戶反饋的少量的調整。在生命週期的這一點上，用戶反饋應主要集中在產品調整，設置、安裝和可用性問題，所有主要的結構問題應該已經在項目生命週期的早期階段解決了。

在交付階段的終點是第四個里程碑：產品發佈(Product Release)里程碑。此時，要確定目標是否實現，是否應該開始另一個開發週期。在一些情況下這個里程碑可能與下一個週期的初始階段的結束重合。

四 RUP的核心工作流(Core Workflows)

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

商業建模(Business Modeling)

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

需求(Requirements)

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

分析和設計(Analysis & Design)

分析和設計工作流將需求轉化成未來系統的設計，為系統開發一個健壯的結構並調整設計使其與實現環境相匹配，優化其性能。分析設計的結果是一個設計模型和一個可選的分析模型。設計模型是源代碼的抽像，由設計類和一些描述組成。設計類被組織成具有良好接口的設計包(Package)和設計子系統 (Subsystem)，而描述則體現了類的對象如何協同工作實現用例的功能。

設計活動以體系結構設計為中心，體系結構由若干結構視圖來表達，結構視圖是整個設計的抽像和簡化，該視圖中省略了一些細節，使重要的特點體現得更加清晰。體系結構不僅僅是良好設計模型的承載媒介，而且在系統的開發中能提高被創建模型的質量。

實現(Implementation)

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

測試(Test)

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

部署(Deployment)

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

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

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

項目管理(Project Management)

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

環境(Environment)

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

五 RUP的迭代開發模式

RUP中的每個階段可以進一步分解為迭代。一個迭代是一個完整的開發循環，產生一個可執行的產品版本，是最終產品的一個子集，它增量式地發展，從一個迭代過程到另一個迭代過程到成為最終的系統。

傳統上的項目組織是順序通過每個工作流，每個工作流只有一次，也就是我們熟悉的瀑布生命週期。這樣做的結果是到實現末期產品完成並開始測試，在分析、設計和實現階段所遺留的隱藏問題會大量出現，項目可能要停止並開始一個漫長的錯誤修正週期。

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

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

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

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

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

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

六 總結

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