軟體過程RUP初探

軟體過程RUP初探

摘要：本文介紹了Rational統一過程（RUP）的主要內容，包括開發階段、迭代過程和核心工作流程等，並簡要評述了其在軟體項目開發中的優越及不足之處。

關鍵詞：統一過程 裡程碑 迭代 核心工作流程

Abstract: This paper discuss the important contents of the Rational Unified Process, including Development Phase, Iteration Process, Core Workflows and so on. Additionally, giving some comments about its advantages and weaknesses in the software projects development.

Key Words: Unified Process, Milestone, Iteration ,Core Workflows

一 前言
軟體過程是指實施於軟體開發和維護中的階段、方法、技術、實踐及相關產物(計劃、文檔、模型、代碼、測試案例和手冊等)的集合。行之有效軟體過程可以提高開發軟體組織的生產效率、提高軟體品質、降低成本並減少風險。目前市場上領先的軟體過程主要有RUP(Rational Unified Process)、OPEN Process和OOSP(Object-Oriented Software Process)。
RUP具有較高認知度的原因之一恐怕是因為其提出者Rational軟體公司聚集了物件導向領域三位傑出專家Booch、Rumbaugh和Jacobson，同時它又是物件導向開發的行業標準語言——標準建模語言(UML)的創立者。RUP是由Objectory過程演化而來，其初始版本為5.0，先後經曆了5.1、5.11、5.5等版本直到最新的Rational Unified Process2000版本。本文主要討論RUP的主要內容和特點。
二 RUP的二維開發模型
RUP可以用二維座標來描述。橫軸通過時間組織，是過程展開的生命週期特徵，體現開發過程的動態結構，用來描述它的術語主要包括周期(Cycle)、階段(Phase)、迭代(Iteration)和裡程碑(Milestone)；縱軸以內容來組織為自然的邏輯活動，體現開發過程的靜態結構，用來描述它的術語主要包括活動(Activity)、產物(Artifact)、工作者(Worker)和工作流程(Workflow)。

RUP的二維開發模型
三 開發過程中的各個階段和裡程碑
RUP中的軟體生命週期在時間上被分解為四個順序的階段，分別是：初始階段(Inception)、細化階段(Elaboration)、構造階段(Construction)和交付階段(Transition)。每個階段結束於一個主要的裡程碑(Major Milestones)；每個階段本質上是兩個裡程碑之間的時間跨度。在每個階段的結尾執行一次評估以確定這個階段的目標是否已經滿足。如果評估結果令人滿意的話，可以允許項目進入下一個階段。
1． 初始階段
初始階段的目標是為系統建立商業案例並確定項目的邊界。為了達到該目的必須識別所有與系統互動的外部實體，在較高層次上定義互動的特性。本階段具有非常重要的意義，在這個階段中所關注的是整個項目進行中的業務和需求方面的主要風險。對於建立在原有系統基礎上的開發項目來講，初始階段可能很短。
初始階段結束時是第一個重要的裡程碑：生命週期目標(Lifecycle Objective)裡程碑。生命週期目標裡程碑評價項目基本的生存能力。
2． 細化階段
細化階段的目標是分析問題領域，建立健全的體繫結構基礎，編製專案計劃，淘汰項目中最高風險的元素。為了達到該目的，必須在理解整個系統的基礎上，對體繫結構作出決策，包括其範圍、主要功能和諸如效能等非功能需求。同時為項目建立支援環境，包括建立開發案例，建立模板、準則並準備工具。
細化階段結束時第二個重要的裡程碑：生命週期結構(Lifecycle Architecture)裡程碑。生命週期結構裡程碑為系統的結構建立了管理基準並使項目小組能夠在構建階段中進行衡量。此刻，要檢驗詳細的系統目標和範圍、結構的選擇以及主要風險的解決方案。
3． 構造階段
在構建階段，所有剩餘的構件和應用程式功能被開發並整合為產品，所有的功能被詳細測試。從某種意義上說，構建階段是一個製造過程，其重點放在管理資源及控制運作以最佳化成本、進度和品質。
構建階段結束時是第三個重要的裡程碑：初始功能(Initial Operational)裡程碑。初始功能裡程碑決定了產品是否可以在測試環境中進行部署。此刻，要確定軟體、環境、使用者是否可以開始系統的運作。此時的產品版本也常被稱為“beta”版。
4． 交付階段
交付階段的重點是確保軟體對終端使用者是可用的。交付階段可以跨越幾次迭代，包括為發布做準備的產品測試，基於使用者反饋的少量的調整。在生命週期的這一點上，使用者反饋應主要集中在產品調整，設定、安裝和可用性問題，所有主要的結構問題應該已經在專案生命週期的早期階段解決了。
在交付階段的終點是第四個裡程碑：產品發布(Product Release)裡程碑。此時，要確定目標是否實現，是否應該開始另一個開發週期。在一些情況下這個裡程碑可能與下一個周期的初始階段的結束重合。
四 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提出了迭代的方法，意味著在整個項目中進行測試，從而儘可能早地發現缺陷，從根本上降低了修改缺陷的成本。測試類別似於3D 模型，分別從可靠性、功能性和系統效能來進行。
6． 部署(Deployment)
部署工作流程的目的是成功的產生版本並將軟體分發給終端使用者。部署工作流程描述了那些與確保軟體產品對終端使用者具有可用性相關的活動，包括：軟體打包、產生軟體本身以外的產品、安裝軟體、為使用者提供協助。在有些情況下，還可能包括計劃和進行beta測試版、移植現有的軟體和資料以及正式驗收。
7． 配置和變更管理(Configuration & Change Management)
配置和變更管理工作流程描繪了如何在多個成員組成的項目中控制大量的產物。配置和變更管理工作流程提供了準則來管理演化系統中的多個變體，跟蹤軟體建立過程中的版本。工作流程描述了如何管理並行開發、分布式開發、如何自動化建立工程。同時也闡述了對產品修改原因、時間、人員保持審計記錄。
8． 專案管理(Project Management)
軟體專案管理平衡各種可能產生衝突的目標，管理風險，克服各種約束並成功交付使使用者滿意的產品。其目標包括：為項目的管理提供架構，為計劃、人員配備、執行和監控項目提供實用的準則，為管理風險提供架構等。
9． 環境(Environment)
環境工作流程的目的是向軟體開發組織提供軟體開發環境，包括過程和工具。環境工作流程集中於設定項目過程中所需要的活動，同樣也支援開發項目規範的活動，提供了逐步的指導手冊並介紹了如何在組織中實現過程。
五 RUP的反覆式開發法模式
RUP中的每個階段可以進一步分解為迭代。一個迭代是一個完整的開發迴圈，產生一個可執行檔產品版本，是最終產品的一個子集，它增量式地發展，從一個迭代過程到另一個迭代過程到成為最終的系統。
傳統上的項目組織是順序通過每個工作流程，每個工作流程只有一次，也就是我們熟悉的瀑布生命週期。這樣做的結果是到實現末期產品完成並開始測試，在分析、設計和實現階段所遺留的隱藏問題會大量出現，項目可能要停止並開始一個漫長的錯誤修正周期。

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

RUP的迭代模型
與傳統的瀑布模型相比較，迭代過程具有以下優點：
降低了在一個增量上的開支風險。如果開發人員重複某個迭代，那麼損失只是這一個開發有誤的迭代的花費。
降低了產品無法按照既定進度進入市場的風險。通過在開發早期就確定風險，可以儘早來解決而不至於在開發後期匆匆忙忙。
加快了整個開發工作的進度。因為開發人員清楚問題的焦點所在，他們的工作會更有效率。
由於使用者的需求並不能在一開始就作出完全的界定，它們通常是在後續階段中不斷細化的。因此，迭代過程這種模式使適應需求的變化會更容易些。
六 總結
RUP具有很多長處：提高了團隊生產力，在迭代的開發過程、需求管理、基於組件的體繫結構、可視化軟體建模、驗證軟體品質及控制軟體變更等方面，針對所有關鍵的開發活動為每個開發成員提供了必要的準則、模板和工具指導，並確保全體成員共用相同的知識基礎。它建立了簡潔和清晰的過程結構，為開發過程提供較大的通用性。但同時它也存在一些不足： RUP只是一個開發過程，並沒有涵蓋軟體過程的全部內容，例如它缺少關於軟體運行和支援等方面的內容；此外，它沒有支援多項目的開發結構，這在一定程度上降低了在開發組織內大範圍實現重用的可能性。可以說RUP是一個非常好的開端，但並不完美，在實際的應用中可以根據需要對其進行改進並可以用OPEN和OOSP等其他軟體過程的相關內容對RUP進行補充和完善。
主要參考文獻
1． Rational Software Corporation. Rational Unified Process version 2000.02.1, 2000
2． Ivar Jacobson,Grady Booch,James Rumbaugh. The Unified Software Development Process, Addison Wesley, 1999.1
3． Scott W.Ambler. Enhancing the Unified Process:Software Process for Large Scale,Mission-Critical Systems A Ronin Internatinal White Paper,2000.9