http://www-128.ibm.com/developerworks/cn/rational/r-rupbp/
軟件開發團隊的最佳實踐
IBM Rational
2004 年 3 月
Rational Unified Process 是軟件工程的過程。它提供了在開發組織中分派任務和責任的紀律化方法。它的目標是在可預見的日程和預算前提下，確保滿足最終用戶需求的高質量產品。
什么是 Rational 統一過程（ Rational Unified Process）?
Rational Unified Process 是軟件工程的過程。它提供了在開發組織中分派任務和責任的紀律化方法。它的目標是在可預見的日程和預算前提下，確保滿足最終用戶需求的高質量產品。
Rational Unified Process 是 Rational 公司開發和維護的過程產品。Rational Unified Process 的開發團隊同顧客、合作伙伴、Rational 產品小組及顧問公司共同協作，確保開發過程持續地更新和提高以反映新的經驗和不斷演化的實踐經驗。
Rational Unified Process 提高了團隊生產力。對于所有的關鍵開發活動，它為每個團隊成員提供了使用準則、模板、工具指導來進行訪問的知識基礎。而通過對相同知識基礎的理解，
無論你是進行需求分析、設計、測試項目管理或配置管理，均能確保全體成員共享相同的知識、過程和開發軟件的視圖。
Rational Unified Process 的活動創建和維護模型。 Rational Unified Process 強調開發和維護模型--語義豐富的軟件系統表達，而非強調大量的文本工作。
Rational Unified Process是有效使用 Unified Modeling Language (UML)的指南。UML是良好溝通需求、體系結構和設計的工業標準語言。UML 由 Rational 軟件公司創建，現在由標準化對象管理機構（OMG）維護。
Rational Unified Process 能對大部分開發過程提供自動化的工具支持。它們被用來創建和維護軟件開發過程（可視化建模、編程、測試等）的各種各樣的產物--特別是模型。另外在每個迭代過程的變更管理和配置管理相關的文檔工作支持方面也是非常有價值的。
Rational Unified Process 是可配置的過程。沒有一個開發過程能適合所有的軟件開發。Rational Unified Process 既適用小的開發團隊也適合大型開發組織。Rational Unified Process 建立簡潔和清晰的過程結構為開發過程家族提供通用性。并且，它可以變更以容納不同的情況。它還包含了開發工具包，為配置適應特定組織機構的開發過程提供了支持。
Rational Unified Process 以適合于大范圍項目和機構的方式捕捉了許多現代軟件開發過程的最佳實踐。部署這些最佳實踐經驗--使用 Rational Unified Process 作為指南--給開發團隊提供了大量的關鍵優勢。在下節中，我們對 Rational Unified Process 的6個基本最佳實踐經驗進行描述。
6個最佳實踐的有效部署
Rational Unified Process 描述了如何為軟件開發團隊有效的部署經過商業化驗證的軟件開發方法。它們被稱為"最佳實踐"不僅僅因為你可以精確地量化它們的價值，而且它們被許多成功的機構普遍的運用。為使整個團隊有效利用最佳實踐，Rational Unified Process 為每個團隊成員提供了必要準則、模板和工具指導；
- 迭代的開發軟件
- 需求管理
- 使用基于構件的體系結構
- 可視化軟件建模
- 驗證軟件質量
- 控制軟件變更
迭代的開發產品 -- 面對當今的復雜的軟件系統，使用連續的開發方法：如首先定義整個問題，設計完整的解決方案，編制軟件并最終測試產品，是不可能的。需要一種能夠通過一系列細化，若干個漸進的反復過程而生成有效解決方案的迭代方法。Rational Unified Process 支持專注于處理生命周期中每個階段中最高風險的迭代開發方法，極大地減少了項目的風險性。迭代方法通過可驗證的方法來幫助減少風險--經常性的、可執行版本使最終用戶不斷的介入和反饋。因為每個迭代過程以可執行版本告終，開發團隊停留在產生結果上，頻繁的狀態檢查幫助確保項目能按時進行。迭代化方法同樣使得需求、特色、日程上戰略性的變化更為容易。
需求管理 -- Rational Unified Process 描述了如何提取、組織和文檔化需要的功能和限制；跟蹤和文檔化折衷方案和決策； 捕獲和進行商業需求交流。過程中用例和場景的使用被證明是捕獲功能性需求的卓越方法，并確保由它們來驅動設計、實現和軟件的測試，使最終系統更能滿足最終用戶的需要。它們給開發和發布系統提供了連續的和可跟蹤的線索。 __
基于構件的體系結構 -- 該過程在全力以赴開發之前，關注于早期的開發和健壯可執行體系結構的基線。它描述了如何設計靈活的，可容納修改的，直觀便于理解的，并且促進有效軟件重用的彈性結構。Rational Unified Process 支持基于構件的軟件開發。構件是實現清晰功能的模塊、子系統。Rational Unified Process 提供了使用新的及現有構件定義體系結構的系統化方法。它們被組裝為良好定義的結構，或是特殊的、底層結構如Internet、CORBA 和 COM 等的工業級重用構件。
可視化軟件建模-- 開發過程顯示了對軟件如何可視化建模，捕獲體系結構和構件的構架和行為。這允許你隱藏細節和使用"圖形構件塊"來書寫代碼。可視化抽象幫助你溝通軟件的不同方面，觀察各元素如何配合在一起，確保構件模塊一致于代碼，保持設計和實現的一致性，促進明確的溝通。Rational軟件公司創建的工業級標準 Unified Modeling Language(UML)是成功可視化軟件建模的基礎。
驗證軟件質量 -- 拙劣的應用程序性能和可靠性是戲劇性展示當今軟件可接受性的特點。從而，質量應該基于可靠性、功能性、應用和系統性能根據需求來進行驗證。Rational Unified Process幫助計劃、設計、實現、執行和評估這些測試類型。質量評估被內建于過程、所有的活動，包括全體成員，使用客觀的度量和標準，并且不是事后型的或單獨小組進行的分離活動。
控制軟件的變更 -- 管理變更的能力--確定每個修改是可接受的，能被跟蹤的--在變更不可避免環境中是必須的。開發過程描述了如何控制、跟蹤和監控修改以確保成功的迭代開發。它同時指導如何通過隔離修改和控制整個軟件產物（例如，模型、代碼、文檔等）的修改來為每個開發者建立安全的工作區。另外，它通過描述如何進行自動化集成和建立管理使小隊如同單個單元來工作。
過程簡介
二維結構
開發過程可以用二維結構或沿著兩個坐標軸來表達：
- 橫軸代表了制訂開發過程時的時間，體現了過程的動態結構。它以術語周期（cycle）、階段(phase)、迭代（iteration）和里程碑(milestone)來表達。
- 縱軸表現了過程的靜態結構：如何用術語活動（activity）、產物(artifact)、 角色(worker)和工作流(workflow)來描述。
迭代模型圖顯示了過程的二維結構
階段和迭代--時間軸
這是開發過程沿時間的動態組織結構。
軟件生命周期被分解為周期，每一個周期工作在產品新的一代上。Rational Unified Process將周期又劃分為四個連續的階段。
每個階段終結于良好定義的里程碑--某些關鍵決策必須做出的時間點，因此關鍵的目標必須被達到。
過程中的階段和主要里程碑
每個階段均有明確的目標。
初始階段
初始階段的目標是為系統建立商業案例和確定項目的邊界。
為了達到該目的必須識別所有與系統交互的外部實體，在較高層次上定義交互的特性。它包括識別所有用例和描述一些重要的用例。商業案例包括驗收規范、風險評估、所需資源估計、體現主要里程碑日期的階段計劃。
本階段具有非常重要的意義，在這個階段中，關注的是整個項目進行工程中的業務和需求方面的主要風險。對于建立在原有系統基礎上的開發項目來說，初始階段的時間可能很短。
本階段的主要目標如下：
- 明確軟件系統的范圍和邊界條件，括從功能角度的前景分析、產品驗收標準和哪些做與哪些不做的相關決定
- 明確區分系統的關鍵用例（Use-case） 和主要的功能場景
- 展現或者演示至少一種符合主要場景要求的候選軟件體系結構
- 對整個項目做最初的項目成本和日程估計(更詳細的估計將在隨后的細化階段中做出)
- 估計出潛在的風險(主要指各種不確定因素造成的潛在風險)
- 準備好項目的支持環境
初始階段的產出是:
- 藍圖文檔核心項目需求關鍵特色主要約束的總體藍圖
- 原始用例模型(完成10%～20%)
- 原始項目術語表(可能部分表達為業務模型)
- 原始商業案例,包括業務的上下文、驗收規范（年度映射、市場認可等等），成本預計
- 原始的風險評估
- 一個或多個原型
里程碑：生命周期的目標
初始階段結束時是第一個重要的里程碑：生命周期目標里程碑。初始階段的評審標準：
- 風險承擔者就范圍定義成本日程估計達成共識
- 以客觀的主要用例證實對需求的理解
- 成本/日程、優先級、風險和開發過程的可信度
- 被開發體系結構原型的深度和廣度
- 實際開支與計劃開支的比較
如果無法通過這些里程碑，則項目可能被取消或仔細地重新考慮。
細化階段
細化階段的目標是分析問題領域，建立健全的體系結構基礎，編制項目計劃，淘汰項目中最高風險的元素。
為了達到該目的，必須對系統具有"英里寬和英寸深"的觀察。體系結構的決策必須在理解整個系統的基礎上作出：它的范圍，主要功能和如性能等非功能性需求。
容易引起爭論，細化階段是四個階段中最關鍵的階段。該階段結束時，硬"工程"可以認為已結束，項目則經歷最后的審判日：決策是否項目提交給構建和交付階段。對于大多數項目，這也相當于從移動的、輕松的、靈巧的、低風險的運作過渡到高成本、高風險并帶有較大慣性的運作過程。而過程必須能容納變化，細化階段活動確保了結構、需求和計劃是足夠穩定的，風險被充分減輕，所以可以為開發結果預先決定成本和日程安排。概念上，其逼真程度一致于機構實行費用固定的構建階段的必要程度。
在細化階段，可執行的結構原形在一個或多個迭代過程中建立，依賴于項目的范圍、規模、風險和先進程度。工作量必須至少處理初始階段中識別的關鍵用例，關鍵用例典型揭示了項目主要技術的風險。通常我們的目標是一個由產品質量級別構件組成的可進化的原型，但這并不排除開發一個或多個探索性、可拋棄的原型來減少如：設計/需求折衷，構件可行性研究，或者給投資者、顧客即最終用戶演示版本等特定的風險。
本階段的主要目標如下：
- 確保軟件結構、需求、計劃足夠穩定；確保項目風險已經降低到能夠預計完成整個項目的成本和日程的程度。
- 針對項目的軟件結構上的主要風險已經解決或處理完成。
- 通過完成軟件結構上的主要場景建立軟件體系結構的基線。
- 建立一個包含高質量組件的可演化的產品原型。
- 說明基線化的軟件體系結構可以保障系統需求可以控制在合理的成本和時間范圍內。
- 建立好產品的支持環境。
初始階段的產出是：
- 用例模型（完成至少80％）-- 所有用例均被識別，大多數用例描述被開發
- 補充捕獲非功能性要求和非關聯于特定用例要求的需求
- 軟件體系結構描述_可執行的軟件原型
- 經修訂過的風險清單和商業案例
- 總體項目的開發計劃，包括紋理較粗糙的項目計劃，顯示迭代過程和對應的審核標準
- 指明被使用過程的更新過的開發用例
- 用戶手冊的初始版本（可選）
里程碑：生命周期的結構
細化階段結束是第二個重要的里程碑：生命周期的結構里程碑。此刻，檢驗詳細的系統目標
和范圍、結構的選擇以及主要風險的解決方案。主要的審核標準包括回答以下的問題：
- 產品的藍圖是否穩定？
- 體系結構是否穩定？
- 可執行的演示版是否顯示風險要素已被處理和可靠的解決
- 構建階段的計劃是否足夠詳細和精確？是否被可靠的審核基礎支持？
- 如果當前計劃在現有的體系結構環境中被執行而開發出完整系統，是否所有的風險承擔人同意該藍圖是可實現的？
- 實際的費用開支與計劃開支是否可以接受？
如果無法通過這些里程碑，則項目可能被取消或仔細地重新考慮。
構建階段
在構建階段,所有剩余的構件和應用程序功能被開發并集成為產品,所有的功能被詳盡的測試。
構建階段，從某種意義上說，是重點在管理資源和控制運作以優化成本、日程、質量的生產過程。就這一點而言，管理的理念經歷了初始階段和細化階段的智力資產開發到構建階段和交付階段可發布產品的過渡。
許多項目規模大的足夠產生許多平行的增量構建過程，這些平行的活動可以極大地加速版本發布的有效性；同時也增加了資源管理和工作流同步的復雜性。健壯的體系結構和易于理解的計劃是高度關聯的。換言之，體系結構上關鍵的質量是構建的容易程度。這也是在細化階段平衡的體系結構和計劃被強調的原因。
本階段的主要目標如下：
- 通過優化資源和避免不必要的返工達到開發成本的最小化
- 根據實際需要達到適當的質量目標
- 據實際需要形成各個版本（Alpha,Beta,and other test release）
- 對所有必須的功能完成分析、設計、開發和測試工作
- 采用循環漸進的方式開發出一個可以提交給最終用戶的完整產品
- 確定軟件站點用戶都為產品的最終部署做好了相關準備
- 達成一定程度上的并行開發機制
構建階段的產出是可以交付給最終用戶的產品。它最小包括：
里程碑：初始運作能力
創建階段結束是第三個重要的項目里程碑（初始功能里程碑）。此刻，決定是否軟件、環境、用戶可以運作而不會將項目暴露在高度風險下。該版本也常被稱為"beta"版。
構建階段主要的審核標準包括回答以下的問題:
- 產品是否足夠穩定和成熟得發布給用戶?
- 是否所有的風險承擔人準備好向用戶移交?
- 實際費用與計劃費用的比較是否仍可被接受?
如果無法通過這些里程碑,則移交不得不被延遲。
交付階段
交付階段的目的是將軟件產品交付給用戶群體。
只要產品發布給最終用戶，問題常常就會出現：要求開發新版本，糾正問題或完成被延遲的問題。
當基線成熟得足夠發布到最終用戶時，就進入了交付階段。其典型要求一些可用的系統子集被開發到可接收的質量級別及用戶文檔可供使用，從而交付給用戶的所有部分均可以有正面的效果。這包括：
- 對照用戶期望值，驗證新系統的"beta測試"
- 與被替代的已有系統并軌
- 功能性數據庫的轉換
- 向市場、部署、銷售團隊移交產品
構建階段關注于向用戶提交產品的活動。典型的，該階段包括若干重復過程，包括 beba 版本、通用版本、bug 修補版和增強版。相當大的工作量消耗在開發面向用戶的文檔，培訓用戶。在初始產品使用時，支持用戶并處理用戶的反饋。開發生命周期的該點，用戶反饋主要限定在產品性能調整、配置、安裝和使用問題。
本階段的目標是確保軟件產品可以提交給最終用戶。本階段根據實際需要可以分為幾個循環。本階段的具體目標如下：
- 進行 Beta 測試以期達到最終用戶的需要
- 進行 Beta 測試和舊系統的并軌
- 轉換功能數據庫
- 對最終用戶和產品支持人員的培訓
- 提交給市場和產品銷售部門
- 和具體部署相關的工程活動
- 協調 Bug 修訂/改進性能和可用性(Usability)等工作
- 基于完整的 Vision 和產品驗收標準對最終部署做出評估
- 達到用戶要求的滿意度
- 達成各風險承擔人對產品部署基線已經完成的共識
- 達成各風險承擔人對產品部署符合 Vision 中標準的共識
該階段依照產品的類型,可能從非常簡單到極端復雜的范圍內變化。例如，現有的桌面產品的新版本可能非常簡單，而替代國際機場的流量系統會非常復雜。
里程碑：產品發布
在交付階段的終點是第四個重要的項目里程碑，產品發布里程碑。此時，決定是否目標已達到或開始另一個周期。在許多情況下，里程碑會與下一個周期的初始階段相重疊。
發布階段的審核標準主要包括以下兩個問題：
- 用戶是否滿意？
- 實際費用與計劃費用的比較是否仍可被接受？
迭代過程
Rational Unified Process 的每個階段可以進一步被分解為迭代過程。迭代過程是導致可執行產品版本（內部和外部）的完整開發循環，是最終產品的一個子集，從一個迭代過程到另一個迭代過程遞增式增長形成最終的系統。
迭代方法的益處
與傳統的瀑布式方法相比，迭代過程具有以下的優點：
- 減小了風險
- 更容易對變更進行控制
- 高度的重用性
- 項目小組可以在開發中學習
- 較佳的總體質量
開發過程中的靜態結構(Static Structure of the Process)
開發流程定義了"誰""何時""如何"做"某事"。四種主要的建模元素被用來表達 Rational Unified Process：
- 角色(Workers),"誰"
- 活動(Activities),"如何"
- 產物(Artifacts),"某事"
- 工作流（Workflows），"何時"
活動、產物、角色
角色、活動和工作產物
角色
角色定義了個人或由若干人所組成小組的行為和責任。可以認為角色是項目組中個人戴的"帽子"。單個人可以佩戴多個不同的帽子。這是一個非常重要的區別。因為通常容易將角色認為是個人或小組本身，在 Unified Process 中，角色還定義了如何完成工作。所分派給角色的責任既包括某系列的活動，還包括成為產物的擁有者。
人與角色
活動
某個角色的活動是可能要求該角色中的個體執行的工作單元。活動具有明確的目的，通常表現為一些產物，如模型、類、計劃等。每個活動分派給特定的角色。活動通常占用幾個小時至幾天，常常牽涉一個角色，影響到一個或少量的產物。活動應可以用來作為計劃和進展的組成元素；如果活動太小，它將被忽略，而如果太大，則進展不得不表現為活動的組成部分。
活動的例子：
- 計劃一個迭代過程，對應角色：項目經理
- 尋找 use cases 和 actors, 對應角色:系統分析員
- 審核設計,對應角色:設計審核人員
- 執行性能測試,對應角色:性能測試人員
產物
產物是被產生的、修改，或為過程所使用的一段信息。產物是項目的實際產品、項目產生的事物，或者供向最終產品邁進時使用。產物用作角色執行某個活動的輸入，同時也是該活動的輸出。在面向對象的設計術語中，如活動是活動對象（角色）上的操作一樣，產物是這些活動的參數。
產物可以具有不同的形式：
- 模型，如 Use-Case 模型或設計模型
- 模型組成元素,即模型中的元素，比如類,用例（use case） 或子系統般的元素
- 文檔,如商業案例或軟件結構文檔
- 源代碼
- 可執行文件
工作流
僅依靠角色、活動和產物的列舉并不能組成一個過程。需要一種方法來描述能產生若干有價值的有意義結果的活動序列，顯示角色之間的交互作用。
工作流是產生具有可觀察結果的活動序列。
UML 術語中,工作流可以表達為序列圖、協同圖，或活動圖。在本文中，使用活動圖的形式來描述。
工作流樣例
注意要表達活動之間的所有依賴關系并不是總可能或切合實際的。常常兩個活動較表現的交織得更緊密，特別是在涉及到同一個角色或個人時。人不是機器，對于人而言，工作流不能按字面地翻譯成程序，被精確地、機械地執行。
下節中，我們將討論開發過程中最基本的工作流，稱之為核心工作流。
核心工作流(Core workflows)
Rational Unified Process 中有9個核心工作流,代表了所有角色和活動的邏輯分組情況。
9個核心的過程工作流
核心工作流分為6個核心"工程"工作流
- 商業建模工作流
- 需求工作流
- 分析和設計工作流
- 實現工作流
- 測試工作流
- 分發工作流
和3個核心"支持"工作流
- 項目管理工作流
- 配置和變更控制工作流
- 環境工作流
盡管6個核心工程工作流能使人想起傳統瀑布流程中的幾個階段，但應注意迭代過程中的階段是不同的，這些工作流在整個生命期中一次又一次被訪問。9個核心工作流在項目中的實際完整的工作流中輪流被使用，在每一次迭代中以不同的重點和強度重復。
商業建模
決大多數商業工程化的主要問題，是軟件工程人員和商業工程人員之間不能正確地交流。這導致了商業工程的產出沒有作為軟件開發輸入而正確地被使用，反之亦然。Rational Unified Process 針對該情況為兩個群體提供了相同的語言和過程，同時顯示了如何在商業和軟件模型中創建和保持直接的可跟蹤性。
在商業建模中，使用商業用例來文檔化商業過程，從而確保了組織中所有支持商業過程人員達到共識。商業用例被分析以理解商業過程如何被業務支持，而這些在商業對象模型中被核實。
許多項目可能不進行商業建模。
需求
需求工作流的目標是描述系統應做"什么"，并允許開發人員和用戶就該描述達成共識。為了達到該目標，進行提取、組織、文檔化需要的功能和約束；跟蹤、為折衷方案及決定形成文檔。
藍圖被創建，需求被提取。代表用戶和其他可能與開發系統交互的其它系統的 Actor 被指明。Use case 被識別,表示系統的行為。因為use case 根據 actor 的要求開發,系統與用戶之間的聯系更緊密。系統展示了用于再生系統的用例模型。
樣例用例模型
每一個用例被仔細地描述。用例描述顯示了系統如何與 actor 交互及系統的行為.非功能性的需求在補充說明中體現。
Use case 起到貫穿整個系統的開發周期線索的作用。相同的用例模型在需求捕獲階段、分析設計階段和測試階段中使用。
分析和設計
分析設計工作流的目標是顯示系統"如何"在實現階段被"實現"的。你需要一個如下系統：
- 在特定的實現環境中完成用例描述中指定的任務和功能
- 滿足了所有的需求
- 健壯的被建造（如果功能需求發生變化，易于更改）
分析設計結果是一個設計模型和可選的分析模型。設計模型是源代碼的抽象；即設計模型充當源代碼如何被組建和編制的"藍圖"。
設計模型由設計類和一些描述組成。設計類被組織成具有良好接口的設計包和設計子系統，而描述則體現了類的對象如何協同工作實現用例的功能。
下圖是上例 use-case 模型的設計模型示例的一個部分。
設計模型的一部分
設計活動以體系結構設計為中心。結構的產物和驗證是早期迭代的主要焦點。結構由若干結構視圖來表達，這些視圖捕獲了主要的構架設計的決定。本質上，結構視圖是整個設計的抽象和簡化，該視圖中細節被放在了一旁，使重要的特點體現得更加清晰。結構不僅僅是良好設計模型的承載媒介，而且在系統的開發中能提高任何被創建模型的質量。
實現
實現階段的目的：
- 定義代碼的組織結構--以層次化的實施子系統的形式
- 實現類和對象--以構件的形式（源文件、二進制文件、可執行文件等）
- 將開發出的構件作為單元進行測試
- 對由單個實現者（或小組）產生的結構集成為可執行的系統
系統通過完成構件而實現。Rational Unified Process 描繪了如何重用現有的組件,或實現經過良好責任定義的新構件,使系統更易于使用,提高了系統的可重用性。
構件被構造成實施子系統。子系統被表現為帶有附加結構或管理信息的目錄形式。例如，子系統可以被創建為文件系統中的文件夾或目錄，或 Rational Apex for C++ or Ada,或 Java中的包。
測試
測試的目的是：
- 驗證對象間的交互作用
- 驗證軟件構件的正確集成
- 驗證所有需求被正確的實現
- 識別并確保載軟件發布之前缺陷被處理
Rational Unified Process 提出了迭代的方法，意味著在整個項目中進行測試，從而允許盡可能早的發現缺陷，從根本上降低了修改缺陷的成本。測試類似于三維模型，分別從可靠性、功能性、應用和系統性能來進行。流程從每個維度描述了如何經歷測試生命周期的幾個階段，計劃、設計、實現、執行和審核。
另外，描述了何時及如何引入測試自動化的策略。使用迭代的方法，測試自動化是非常重要的，它允許在每次迭代結束及為每個新產品進行回歸測試。
發布
發布工作流的目標是成功地生成版本，將軟件分發給最終用戶。它包括了范圍廣泛的活動。
- 生成軟件本身外的產品
- 軟件打包
- 安裝軟件
- 給用戶提供幫助
許多情況下，還包括如下的活動
- 計劃和進行 Beta 測試版
- 移植現有的軟件或數據
- 正式驗收
盡管發布工作流主要被集中在交付階段,但早期階段需要加入為創建階段后期的發布做準備的許多活動。
Rational Unified Process 中的發布和環境工作較其它工作流包含了較少的內容。
項目管理
軟件項目管理是一門藝術，它平衡了互相沖突的目標，管理風險，克服各種限制來成功地發布滿足投資用戶和使用者需要地軟件。如此少的無爭議的成功項目無疑是該項任務難度的證明。
工作流主要集中在迭代開發過程的特殊方面。本節我們的目標是提供以下的事物來使該任務更簡單。
- 管理項目的框架
- 計劃、配備、執行、監控項目的實踐準則
- 管理風險的框架
它并不是成功的靈丹妙藥，但提供了管理項目能顯著提高軟件成功發布的方法。
配置和變更管理
本工作流中，描繪了如何在多個成員組成的項目中控制大量的產出物。控制有助于避免混亂，確保不會由以下的問題而造成產品的沖突。
- 同步更新--當兩個或兩個以上的角色各自工作在同一產物上時，最后一個修改者會破壞前者的工作。
- 通知不達--當被若干開發者共享的產品中的問題被解決時，修改未被通知到一些開發者
- 多個版本--許多大型項目以演化的方式開發。一個版本可能供顧客使用，另一個版本用于測試，而第三個版本處于開發階段。如果問題在其中任何一個版本中被發現，則修改需要在所有版本中繁衍，從而可能產生混亂導致昂貴的修改和重復勞動，除非變更被很好地控制和監控。
工作流提供了準則管理演化系統中的多個變體，跟蹤給定軟件創建過程中的版本。根據用戶定義地版本規則建造程序或整個版本，實施特定于現場的開發策略。
工作流描述了了如何管理并行開發、分布式開發，如何自動化創建工程。這在如每天均需要頻繁編譯鏈接的重復過程中尤為重要。如果沒有有力的自動化是不可能的同，時也闡述了對產品修改原因、時間、人員保持審計記錄。
工作流也涵蓋了變更需求管理，即如何報告缺陷，在它們的是生命周期中如何管理，及如何使用缺陷來跟蹤進展和發展的傾向。
環境
環境工作流的目的是給軟件開發組織提供軟件開發環境--過程和工具--軟件開發團隊需要它們的支持。
工作流集中在項目環境中配置過程的活動，同樣著重支持項目的開發規范的活動。提供了逐步指導手冊，介紹了如何在組織中實現過程。
環境工作流還包含了提供了定制流程所必須的準則、模板、工具的開發工具箱。開發工具箱在本文后續的"定制流程的開發工具箱"中更詳盡的討論。
環境工作流沒有被牽涉到如選擇、獲取、使其運行和維護開發環境等的具體方面。
Rational Unified Process －具體產品
Rational Unified Process 產品包括：
- 能使用 web 搜索的知識基礎--為全部團隊成員就所有關鍵的開發活動提供準則、模板、工具指導。知識基礎進一步劃分為：
- 擴展的準則供全部成員對軟件生命期所有組成部分進行參考。提供了既為高層次的思考過程，也為日常沉悶的活動進行指導的指南。該指南發布為 HTML 格式以利于獨立于平臺的桌面訪問。
- 工具指導涵蓋整個生命周期工具的指引。同樣，它以 HTML 格式發布.詳細情況參見"工具集成"。
- Rational Rose 的例子和模板為在遵循 Rational Unified Process 時如何組織Rational Rose 的信息提供參考。
- SoDA 模板提供10個以上 SoDA 模板以協助軟件文檔自動化。
- Microsoft Word 模板提供了超過30個模板以幫助工作流和生命期所有部分文檔化。
- Microsoft Project Plans 許多項目經理發現很難做出反映迭代開發方法的項目計劃。該模板根據 Rational Unified Process 為該方法提供一個好的開端。
- Development kit 介紹了如何定制和擴展 Rational Unified Process 至采用該方法機構或項目的特定需求,同時提供了工具和模板來輔助該工作.開發工具包在本節的后續部分闡述。
- Addison-Wesley 出版，Philippe Kruchten 所著的 《Rational Unified Process A Introduction》。本書共 277頁，對開發過程和知識基礎提供了很好的介紹和概括。
知識基礎的瀏覽
Rational Unified Process 允許使用任何流行的瀏覽器如：IE、Netscape Navigator 進行瀏覽。使用 Rational Unified Process ，你僅需少許的鼠標點擊即可獲得所需的信息。該知識基礎包含了許多超文本鏈接，各種過程元素用交互的圖案來表達，很容易直觀的尋找相關信息。功能強大的搜索引擎、索引、"資源管理器式外觀"的樹狀瀏覽使得使用該過程很容易。瀏覽按鈕允許如同讀書一般前后翻頁。
信息在若干不同的視圖中表現，允許你相關于角色、特定活動或工作流來查看信息。對于關鍵的項目角色，提供易于學習的指導過程。
交互式的圖象和可導航的按鈕使查找特定的信息更加方便
定制過程的開發工具包
Rational Unified Process 足夠通用及完備，如同它名字所描述的一般。然而，在某些情況下，該軟件開發過程需要被修改、調整和剪裁以容納具體的特性、約束和機構的歷史情況。特別的，該過程不應該盲目的被遵循，形成許多無用的工作，產生無用產物。它應盡可能的精煉并能夠快速地、可預見地產生高質量的軟件。
開發過程包含了開發工具包，它包括了指導如何定制過程以滿足機構或項目特定需要的指南。工具包還包括了創建過程，以及搜索引擎、索引、場所地圖、樹型瀏覽器等的衍生和操作的模板。開發工具包使得能定制組織結構維持 Rational Unified Process 的感觀。
開發過程定制程度越高，則定制化向未來過程版本的移植越困難。開發工具包描述了減少定制化移植時工作的策略、工具和技術。
工具集成
軟件工程化過程需要工具支持系統生命期的所有活動，尤其是支持開發、維護和各種各樣產物的簿記--特別是模型。迭代的開發過程對使用的工具集提出了特殊的要求，如工具的集成和模型代碼之間的雙向工程。同樣，還需要支持跟蹤需求，文檔自動化以及測試自動化如促進回歸測試等的工具。Rational Unified Process 可以與各種各樣的工具一同使用，包括 Rational公司和其它供應商的產品。而 Rational提供許多有效支持 Rational Unified Process 良好集成的工具。
下面提供了支持 Rational Unified Process 的工具清單。
Rational Unified Process 對于大多數產品均提供了工具指引（Tool Mentors）。工具指引是詳細介紹如何操作工具以實現開發過程的指南（即彈出什么樣的窗口，對話框中的信息及如何漫游的工具）。工具指引允許將獨立于工具的過程鏈接至日常工作的實際操作工具。
- Rational Requisite ? Pro --通過使需求更易于書寫，交流和修改使在整個應用開發中全體開發小組能實時更新和跟蹤。
- Rational ClearQuest? -- 基于窗口的和 Web 的需求變更管理產品,時項目小組能跟蹤和管理開發生命期中的所有變更活動。
- Rational Rose?98 -- 世界領先的用于商業過程建模，需求分析，構建結構設計的可視化建模工具。
- Rational SoDA? -- 為整個軟件開發過程提供產品文檔自動化的工具，極大減少了文檔工作的時間和成本。
- Rational Purify? -- C/C++構件和應用程序開發者使用的運行錯誤檢查工具,幫助檢查內存錯誤。
- Rational Visual Quantify? -- C/C++、VB、Java構件和應用程序開發者使用的高級性能評測工具,幫助評估性能瓶頸。
- Rational Visual PureCoverage? -- 自動的軟件測試覆蓋率工具，使開發者能全面地有效地測試他們的應用程序。
- Rational TeamTest -- 創建、維護和執行自動化的功能測試，允許全面地測試代碼和決定軟件是否滿足期望的需求和性能。
- Rational PerformanceStudio? -- 評測和預計 Client/Server 和 Web 系統性能的易于使用、準確和可升級的工具。
- Rational ClearCase? --主導市場的軟件配置工具，為項目經理提供跟蹤每個軟件開發項目進化的能力。
Rational Unified Process 的歷史
Rational Unified Process 經過了許多年的成熟期并反映了許多人和公司的集體經驗。讓我們簡要地看一下如下圖所示它的歷史：
Rational 統一過程的演進歷史
從時間上回顧，Rational Unified Process 是 Rational Objectory Process(version 4)的直接繼承者。Rational Unified Process 合并了數據工程、商業建模、項目管理和配置管理領域更多的東西，后者作為與 Prue Atria 的歸并結果。它更緊密地集成至 Rational 軟件工具集。Rational Unified Process 是"Rational Approach" 與Objectory process (version 3)的綜合,在1995年 Rational 軟件公司與 Objectory AB 合并之后。從它的 Objectory 前任,繼承了過程結構和 use case 的中心概念。從它的 Rational 背景,得到了迭代開發和體系結構的系統闡述。該版本同樣包括了Requisite,Inc 配置管理部分和從 SQA,?Inc 繼承的詳細測試過程。最后，該開發過程是第一個使用了統一建模語言(UML0.8)。
Objectory process 作為 Ivar Jacobson 的 Ericsson 經驗于1987在瑞典被創建。該過程稱為他公司 Objectory AB 的產品。由于以 use case 概念和面向對象的方法為中心,它很快得到了軟件工業的認可并被許多世界級的公司集成。Objectory process 的簡單版本作為課本在1992年被出版。
Rational Unified Process 是更為通用方法的一個特定的、詳細的實例，該通用方法在 Ivar Jacobson,Grady Booch,和James Rumbaugh 所著的課本《The Unified Software Development Process》有介紹。
參考資料
- Barry W. Boehm, A Spiral Model of Software Development and Enhancement, Computer, May 1988,IEEE, pp.61-72
- Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82.
- Grady Booch, Object Solutions, Addison-Wesley, 1995.
- Grady Booch, Ivar Jacobson, and James Rumbaugh, Unified Modeling Language 1.3, White paper,Rational Software Corp., 1998.
- Alan W. Brown (ed.), Component-Based Software Engineering, IEEE Computer Society, LosAlamitos, CA, 1996, pp.140.
- Michael T. Devlin, and Walker E. Royce, Improving Software Economics in the Aerospace and Defense Industry, Technical paper TP-46, Santa Clara, CA, Rational Software Corp., 1995
- Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar ?vergaard, Object-Oriented Software Engineering-A Use Case Driven Approach, Wokingham, England, Addison-Wesley, 1992, 582p.
- Ivar Jacobson, M. Griss, and P. Jonsson, Software Reuse-Architecture, Process and Organization for Business Success, Harlow, England, AWL, 1997.
- Philippe Kruchten, The 4+1 View Model of Architecture, IEEE Software, 12 (6), November 1995, IEEE, pp.42-50.
- Philippe Kruchten, A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.
- Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.
- Grady Booch, Jim Rumbaugh, and Ivar Jacobson, Unified Modeling Language-User's Guide, Addison-Wesley, 1999.
- Philippe Kruchten, Rational Unified Process-An Introduction, Addison-Wesley, 1999.
- Walker Royce, Software Project Management . A Unified Framework, Addison-Wesley, 1998.