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