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