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

6． 部署(Deployment) 

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

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

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

8． 項目管理(Project Management) 

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

9． 環境(Environment) 

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

七、RUP的迭代開發模式 

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

 


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

 

 

圖3 RUP的迭代模型 

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

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

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

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

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

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

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

讓我們逐一的審視這些要素，看一看它們什么地方適合ＲＵＰ，找出它們能夠成為十大要素的理由。
 
1. 開發一個前景 
      有一個清晰的前景是開發一個滿足涉眾真正需求的產品的關鍵。 前景抓住了ＲＵＰ需求流程的要點：分析問題，理解涉眾需求，定義系統，當需求變化時管理需求。 前景給更詳細的技術需求提供了一個高層的、有時候是合同式的基礎。正像這個術語隱含的那樣，它是軟件項目的一個清晰的、通常是高層的視圖，能被過程中任何決策者或者實施者借用。它捕獲了非常高層的需求和設計約束，讓前景的讀者能理解將要開發的系統。它還提供了項目審批流程的輸入，因此就與商業理由密切相關。最后，由于前景構成了“項目是什么？”和“為什么要進行這個項目？”，所以可以把前景作為驗證將來決策的方式之一。 對前景的陳述應該能回答以下問題，需要的話這些問題還可以分成更小、更詳細的問題： ? 關鍵術語是什么？（詞匯表） ? 我們嘗試解決的問題是什么？（問題陳述） ? 涉眾是誰？用戶是誰？他們各自的需求是什么？ ? 產品的特性是什么？ ? 功能性需求是什么？（Ｕｓｅ Ｃａｓｅｓ） ? 非功能性需求是什么？ ? 設計約束是什么？ 

2. 達成計劃 
        “產品的質量只會和產品的計劃一樣好。” (2) 在ＲＵＰ中，軟件開發計劃（ＳＤＰ）綜合了管理項目所需的各種信息，也許會包括一些在先啟階段開發的單獨的內容。SDP必須在整個項目中被維護和更新。 ＳＤＰ定義了項目時間表（包括項目計劃和迭代計劃）和資源需求（資源和工具），可以根據項目進度表來跟蹤項目進展。同時也指導了其他過程內容（原文：process components）的計劃：項目組織、需求管理計劃、配置管理計劃、問題解決計劃、QA計劃、測試計劃、評估計劃以及產品驗收計劃。 

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

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

4. 分配和跟蹤任務
      有一點在任何項目中都是重要的，即連續的分析來源于正在進行的活動和進化的產品的客觀數據。在RUP中，定期的項目狀態評估提供了講述、交流和解決管理問題、技術問題以及項目風險的機制。團隊一旦發現了這些障礙物（籬笆），他們就把所有這些問題都指定一個負責人，并指定解決日期。進度應該定期跟蹤，如有必要，更新應該被發布。（原文：updates should be issued as necessary。） 這些項目“快照”突出了需要引起管理注意的問題。隨著時間的變化/雖然周期可能會變化（原文：While the period may vary。），定期的評估使經理能捕獲項目的歷史，并且消除任何限制進度的障礙或瓶頸。 

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

6. 設計組件構架 
      在RUP中，件系統的構架是指一個系統關鍵部件的組織或結構，部件之間通過接口交互，而部件是由一些更小的部件和接口組成的。即主要的部分是什么？他們又是怎樣結合在一起的？ RUP提供了一種設計、開發、驗證構架的很系統的方法。在分析和設計流程中包括以下步驟：定義候選構架、精化構架、分析行為（用例分析）、設計組件。 要陳述和討論軟件構架，你必須先創建一個構架表示方式，以便描述構架的重要方面。在RUP中，構架表示由軟件構架文檔捕獲，它給構架提供了多個視圖。每個視圖都描述了某一組涉眾所關心的正在進行的系統的某個方面。涉眾有最終用戶、設計人員、經理、系統工程師、系統管理員，等等。這個文檔使系統構架師和其他項目組成員能就與構架相關的重大決策進行有效的交流。 

7. 對產品進行增量式的構建和測試 
      在RUP中實現和測試流程的要點是在整個項目生命周期中增量的編碼、構建、測試系統組件，在先啟之后每個迭代結束時生成可執行版本。在精化階段后期，已經有了一個可用于評估的構架原型；如有必 要，它可以包括一個用戶界面原型。然后，在構建階段的每次迭代中，組件不斷的被集成到可執行、經過測試的版本中，不斷地向最終產品進化。動態及時的配置管理和復審活動也是這個基本過程元素（原文：essential process element）的關鍵。 

8. 驗證和評價結果 
      顧名思義，RUP的迭代評估捕獲了迭代的結果。評估決定了迭代滿足評價標準的程度，還包括學到的教訓和實施的過程改進。 根據項目的規模和風險以及迭代的特點，評估可以是對演示及其結果的一條簡單的紀錄，也可能是一個完整的、正式的測試復審記錄。 這兒的關鍵是既關注過程問題又關注產品問題。越早發現問題，就越沒有問題。（原文：The sooner you fall behind, the more time you will have to catch up.） 

9. 管理和控制變化 
      RUP的配置和變更管理流程的要點是當變化發生時管理和控制項目的規模，并且貫穿整個生命周期。其目的是考慮所有的涉眾需求，盡可能的滿足，同時仍能及時的交付合格的產品。 用戶拿到產品的第一個原型后（往往在這之前就會要求變更），他們會要求變更。重要的是，變更的提出和管理過程始終保持一致。 在RUP中，變更請求通常用于記錄和跟蹤缺陷和增強功能的要求，或者對產品提出的任何其他類型的變更請求。變更請求提供了相應的手段來評估一個變更的潛在影響，同時記錄就這些變更所作出的決策。他們也幫助確保所有的項目組成員都能理解變更的潛在影響。 

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

九、總結 

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