統一軟件過程
因業務需要，“中科永聯”正式更名為“中程在線”，歡迎大家瀏覽新網站“中程在線信息產業培訓網”

中科永聯高級技術培訓中心（www.itisedu.com）

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

一、六大經驗

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

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

      基于組件的體系結構。組件使重用成為可能，系統可以由組件組成。基于獨立的、可替換的、模塊化組件的體系結構有助于管理復雜性，提高重用率。RUP描述了如何設計一個有彈性的、能適應變化的、易于理解的、有助于重用的軟件體系結構。

       可視化建模。RUP往往和UML聯系在一起，對軟件系統建立可視化模型幫助人們提供管理軟件復雜性的能力。RUP告訴我們如何可視化的對軟件系統建模，獲取有關體系結構于組件的結構和行為信息。

      驗證軟件質量。在RUP中軟件質量評估不再是事后進行或單獨小組進行的分離活動，而是內建于過程中的所有活動，這樣可以及早發現軟件中的缺陷。

      控制軟件變更。迭代式開發中如果沒有嚴格的控制和協調，整個軟件開發過程很快就陷入混亂之中，RUP描述了如何控制、跟蹤、監控、修改以確保成功的迭代開發。RUP通過軟件開發過程中的制品，隔離來自其他工作空間的變更，以此為每個開發人員建立安全的工作空間。

 

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

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




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

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




      角色：描述某個人或者一個小組的行為與職責。RUP預先定義了很多角色。
      活動：是一個有明確目的的獨立工作單元。
      工件：是活動生成、創建或修改的一段信息。

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

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

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

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

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

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

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

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

　　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)