RUP方法RUP方法

一、六大經驗

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

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

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

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

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

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

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

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

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

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

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

4) 确定每個階段内的疊代計劃。規劃RUP的4個階段中每次疊代開發的内容。

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

1． 初始階段

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

2． 細化階段

3． 構造階段

4． 傳遞階段

　　傳遞階段的重點是確定軟體對最終使用者是可用的。傳遞階段可以跨越幾次疊代，包括為釋出做準備的産品測試，基于使用者回報的少量的調整。在生命周期的這一點上，使用者回報應主要集中在産品調整，設定、安裝和可用性問題，所有主要的結構問題應該已經在項目生命周期的早期階段解決了。 在傳遞階段的終點是第四個裡程碑：産品釋出(Product Release)裡程碑。此時，要确定目标是否實作，是否應該開始另一個開發周期。在一些情況下這個裡程碑可能與下一個周期的初始階段的結束重合。

六、統一軟體開發過程RUP的核心工作流(Core Workflows)

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

2． 需求(Requirements)

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

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

4． 實作(Implementation)

5． 測試(Test)

測試工作流要驗證對象間的互動作用，驗證軟體中所有元件的正确內建，檢驗所有的需求已被正确的實作, 識别并确　　認缺陷在軟體部署之前被提出并處理。RUP提出了疊代的方法，意味着在整個項目中進行測試，進而盡可能早地發現缺陷，從根本上降低了修改缺陷的成本。測試類似于三維模型，分别從可靠性、功能性和系統性能來進行。

6． 部署(Deployment)

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

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

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

9． 環境(Environment)

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

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

圖3 RUP的疊代模型

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

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

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

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

　　由于使用者的需求并不能在一開始就作出完全的界定，它們通常是在後續階段中不斷細化的。是以，疊代過程這種模式使适應需求的變化會更容易些。

八、統一軟體開發過程RUP的十大要素

1. 開發前景 2. 達成計劃 3. 辨別和減小風險 4. 配置設定和跟蹤任務。。 5. 檢查商業理由 6. 設計元件構架 7. 對産品進行增量式的建構和測試 8. 驗證和評價結果 9. 管理和控制變化 10. 提供使用者支援

      在較簡單的項目中，對這些計劃的陳述可能隻有一兩句話。比如，配置管理計劃可以簡單的這樣陳述：每天結束時，項目目錄的内容将會被壓縮成ZIP包，拷貝到一個ZIP磁盤中，加上日期和版本标簽，放到中央檔案櫃中。 軟體開發計劃的格式遠遠沒有計劃活動本身以及驅動這些活動的思想重要。正如Dwight D.Eisenhower所說：“plan什麼也不是，planning才是一切。” “達成計劃”—和清單中第3、4、5、8條一起—抓住了RUP中項目管理流程的要點。項目管理流程包括以下活動：構思項目、評估項目規模和風險、監測與控制項目、計劃和評估每個疊代和階段。

3. 辨別和減小風險       RUP的要點之一是在項目早期就辨別并處理最大的風險。項目組辨別的每一個風險都應該有一個相應的緩解或解決計劃。風險清單應該既作為項目活動的計劃工具，又作為确定疊代的基礎。

5. 檢查商業理由       商業理由從商業的角度提供了必要的資訊，以決定一個項目是否值得投資。商業理由還可以幫助開發一個實作項目前景所需的經濟計劃。它提供了進行項目的理由，并建立經濟限制。當項目繼續時，分析人員用商業理由來正确的估算投資回報率(ROI，即return on investment)。 商業理由應該給項目建立一個簡短但是引人注目的理由，而不是深入研究問題的細節，以使所有項目成員容易了解和記住它。在關鍵裡程碑處，經理應該回顧商業理由，計算實際的花費、預計的回報，決定項目是否繼續進行。

10. 提供使用者支援       在RUP中，部署流程的要點是包裝和傳遞産品，同時傳遞有助于最終使用者學習、使用和維護産品的任何必要的材料。 項目組至少要給使用者提供一個使用者指南（也許是通過聯機幫助的方式提供），可能還有一個安裝指南和版本釋出說明。 根據産品的複雜度，使用者也許還需要相應的教育訓練材料。最後，通過一個材料清單（BOM表，即Bill of Materials）清楚地記錄應該和産品一起傳遞哪些材料。 關于需求 有人看了我的要素清單後，可能會非常不同意我的選擇。例如，他會問，需求在哪兒呢？他們不重要嗎？我會告訴他我為什麼沒有把它們包括進來。有時，我會問一個項目組（特别是内部項目的項目組）：“你們的需求是什麼？”，而得到的回答卻是：“我們的确沒有什麼需求。” 剛開始我對此非常驚訝（我有軍方的宇航開發背景）。他們怎麼會沒有需求呢？當我進一步詢問時，我發現，對他們來說，需求意味着一套外部提出的強制性的陳述，要求他們必須怎麼樣，否則項目驗收就不能通過。但是他們的确沒有得到這樣的陳述。尤其是當項目組陷入了邊研究邊開發的境地時，産品需求從頭到尾都在演化。 是以，我接着問他們另外一個問題：“好的，那麼你們的産品的前景是什麼呢？”。這時他們的眼睛亮了起來。然後，我們非常順利的就第一個要素（“開發一個前景”）中列出的問題進行了溝通，需求也自然而然的流動着（原文：and the requirements just flow naturally.）。 也許隻有對于按照有明确需求的合同工作的項目組，在要素清單中加入“滿足需求”才是有用的。請記住，我的清單僅僅意味着進行進一步讨論的一個起點。

九、總結

　　RUP具有很多長處：提高了團隊生産力，在疊代的開發過程、需求管理、基于元件的體系結構、可視化軟體模組化、驗證軟體品質及控制軟體變更等方面，針對所有關鍵的開發活動為每個開發成員提供了必要的準則、模闆和工具指導，并確定全體成員共享相同的知識基礎。它建立了簡潔和清晰的過程結構，為開發過程提供較大的通用性。但同時它也存在一些不足： RUP隻是一個開發過程，并沒有涵蓋軟體過程的全部内容，例如它缺少關于軟體運作和支援等方面的内容；此外，它沒有支援多項目的開發結構，這在一定程度上降低了在開發組織内大範圍實作重用的可能性。可以說RUP是一個非常好的開端，但并不完美，在實際的應用中可以根據需要對其進行改進并可以用OPEN和OOSP等其他軟體過程的相關内容對RUP進行補充和完善。

<a href="http://www.nianlunnet.cn/"></a>