第三代配置管理解決方案: 統一變更管理（UCM）
作者：不詳 來(lái)源：IBM 發(fā)布時(shí)間：2006-3-13 21:16:58 發(fā)布人：admin
增大字體
二十多年來(lái)，Rational軟件一直致力于提供全面可靠的軟件開(kāi)發(fā)管理解決方案，其中軟件配置管理（software configuration management，SCM）解決方案集成了兩個(gè)業(yè)界領(lǐng)先的工具：用于軟件工件管理（software artifact management，SAM）的Rational ClearCase和用于缺陷及變更跟蹤的Rational ClearQuest。這兩個(gè)工具合在一起構成了一個(gè)市場(chǎng)領(lǐng)先的軟件配置管理系統，提供了真正用于加速軟件開(kāi)發(fā)周期和流程的解決方案，這一方案已連續四年居市場(chǎng)第一位（摘自IDC報告："Rational′s SCM solution continued to dominate the software configuration management market in 2001, with a 36.5 percent share. Rational′s SCM solution market share grew in 2001 despite a decline in revenue in the overall SCM market during the year."）。
在大量軟件工程實(shí)踐經(jīng)驗和用戶(hù)反饋的基礎上，Rational軟件提出了第三代的配置管理解決方案- 統一變更管理（UCM）。這里，首先，讓我們簡(jiǎn)單回顧一下軟件配置管理的發(fā)展歷程：軟件配置管理在其不長(cháng)的發(fā)展歷史中不斷進(jìn)行演化，從七十年代基于文件（File Based）以版本控制、支持check-out/check-in模型和簡(jiǎn)單分支為主要特征的第一代軟件配置管理，到基于項目庫（Project Based）將元數據與配置項分開(kāi)存儲管理從而更好地支持并行開(kāi)發(fā)、團隊協(xié)作以及過(guò)程管理的第二代軟件配置管理，發(fā)展到今天基于文件訪(fǎng)問(wèn)透明（File Transparency Based，即開(kāi)發(fā)人員可以在不保留本地副本的情況下直接訪(fǎng)問(wèn)受控配置項）、全面結合變更請求管理（Software Change Management）、軟件系統分析設計以及軟件測試等等各個(gè)軟件開(kāi)發(fā)環(huán)節的完整的軟件配置管理方案。而Rational配置管理解決方案UCM正是體現這一趨勢的代表。
以前兩代配置管理方法為基礎上，Rational軟件提出的統一變更管理（UCM）是用于管理軟件開(kāi)發(fā)過(guò)程（包括從需求到版本發(fā)布）中所有變更的"最佳實(shí)踐"流程。UCM定義了一個(gè)可以立即用于軟件開(kāi)發(fā)項目的一致并基于活動(dòng)的變更管理流程。通過(guò)Rational ClearCase和ClearQuest的支持，UCM已成為Rational用于軟件開(kāi)發(fā)最佳實(shí)踐的全面框架--Rationial統一過(guò)程（RUP）的關(guān)鍵組成部分。根據軟件開(kāi)發(fā)團隊的具體需要，可以使用相應的過(guò)程模型來(lái)加速軟件開(kāi)發(fā)進(jìn)度，提高軟件質(zhì)量并優(yōu)化開(kāi)發(fā)過(guò)程。
UCM通過(guò)抽象層次的提升簡(jiǎn)化了軟件開(kāi)發(fā)，從而使得軟件開(kāi)發(fā)團隊從更高的層次根據活動(dòng)（activity）來(lái)管理變更。通過(guò)UCM，一個(gè)開(kāi)發(fā)活動(dòng)可以自動(dòng)地同其變更集（封裝了所有用于實(shí)現該活動(dòng)的項目工件）相關(guān)聯(lián)，這樣避免了管理人員手動(dòng)跟蹤所有文件變更。使用UCM還可以獲得以下好處：
預定義的工作流程：可以直接采用預定義的UCM工作流程，快速提升開(kāi)發(fā)組織的軟件配置管理水平； 項目的跟蹤和組織：項目管理人員可以實(shí)時(shí)掌握項目的最新動(dòng)態(tài)，合理分配資源和調度開(kāi)發(fā)活動(dòng)； 協(xié)作自動(dòng)化：通過(guò)將許多耗時(shí)較多的任務(wù)自動(dòng)化處理，UCM使得開(kāi)發(fā)人員更多地將注意力集中在更高層次的開(kāi)發(fā)活動(dòng)上； 輕松管理基線(xiàn)：UCM將開(kāi)發(fā)活動(dòng)嵌入到各個(gè)基線(xiàn)中，這樣測試人員確切地知道他們將測試什么，而開(kāi)發(fā)人員則確切地知道其他開(kāi)發(fā)人員做了什么； 支持跨功能開(kāi)發(fā)組：UCM已成為Rational Suite產(chǎn)品中的核心部分，從而可以將從需求到測試各個(gè)階段的工件（例如需求文檔、設計模型、應用源代碼、測試用例以及HTML及XML內容等）在UCM框架下進(jìn)行統一集成，簡(jiǎn)化了貫穿整個(gè)軟件開(kāi)發(fā)周期的變更過(guò)程； 基于同一代碼構件可以進(jìn)行多項目開(kāi)發(fā)，簡(jiǎn)化了多項目開(kāi)發(fā)管理，增大了代碼共享，節省了開(kāi)發(fā)資源； 可擴展性：小型團隊可以從ClearCase LT和UCM開(kāi)始，而大型團隊可以結合ClearCase的高級構建管理（build managment）功能，以及ClearCase MultiSite和ClearQuest MultiSite跨地域的使用UCM。
本文第三代配置管理解決方案：一種基于活動(dòng)的配置管理過(guò)程詳細描述了統一變更管理（UCM）的概念、優(yōu)點(diǎn)以及開(kāi)發(fā)團隊如何通過(guò)使用Rational ClearCase，Rational ClearQuest和Rational Suite來(lái)受益。
今天的軟件開(kāi)發(fā)團隊面臨著(zhù)巨大的挑戰：一方面Internet驅動(dòng)下的市場(chǎng)要求以空前的速度來(lái)開(kāi)發(fā)高質(zhì)量的軟件應用；另一方面，軟件應用需求隨著(zhù)開(kāi)發(fā)環(huán)境和結構的日趨復雜而變得更加復雜；加上分布式開(kāi)發(fā)、高性能要求、多平臺、更短和連續的發(fā)布周期--這些及其他一些因素加重了軟件開(kāi)發(fā)一直承受的壓力，實(shí)際上現在許多軟件開(kāi)發(fā)團隊經(jīng)常在能否成功開(kāi)發(fā)一個(gè)新型應用上"賭博"。
由于軟件開(kāi)發(fā)不同于傳統意義的工程技術(shù)（如建筑、機械等），市場(chǎng)變化以及技術(shù)上的高速更新都注定了軟件變更是非常頻繁并且是不可避免的，可以說(shuō)變更是軟件開(kāi)發(fā)的基石。一方面在軟件開(kāi)發(fā)環(huán)境下的內部活動(dòng)以新特性、新功能增強以及缺陷修復等方式不停地制造著(zhù)變更；另一方面外部因素--例如新操作環(huán)境，新工具的集成，工程技術(shù)和市場(chǎng)條件的改善等以另一種力量驅動(dòng)著(zhù)變更。
既然變更是不可避免的，那么如何管理、追蹤和控制變更就顯得尤為重要。盡管有多種方式可以幫助開(kāi)發(fā)團隊提高變更處理能力，但其中最重要的一點(diǎn)是整個(gè)團隊的協(xié)作性，這是因為以一種可重復和可預測的方式進(jìn)行高質(zhì)量軟件的開(kāi)發(fā)需要一組開(kāi)發(fā)人員相互協(xié)作。隨著(zhù)系統變得越來(lái)越大和越來(lái)越復雜，盡管個(gè)人生產(chǎn)率依然十分重要，但是決定項目成敗更多的是作為一個(gè)整體的開(kāi)發(fā)團隊的生產(chǎn)率。
而軟件開(kāi)發(fā)團隊的生產(chǎn)率很大程度上是由其相互協(xié)作和組織活動(dòng)的能力決定的，并且開(kāi)發(fā)團隊的成功同其如何高效地響應不斷變化的環(huán)境因素緊密相連。
對在競爭激烈的市場(chǎng)下想占有一席之地的開(kāi)發(fā)團隊而言拒絕變更無(wú)疑是行不通的，只有積極面對變更，采取有效的工具、方法和流程有機地管理、追蹤和控制變更才是保證開(kāi)發(fā)團隊成功的關(guān)鍵。另外，由于各種因素的變更，原來(lái)采用的工具、方法和流程也會(huì )隨著(zhù)組織的成長(cháng)和不停變化的需求而逐步演化，因此對軟件開(kāi)發(fā)團隊來(lái)說(shuō)另一個(gè)關(guān)鍵的成功因素是其擴展能力。
隨著(zhù)開(kāi)發(fā)團隊的成長(cháng)、產(chǎn)品發(fā)布周期的加速以及對軟件資產(chǎn)（包括代碼、文檔等）控制的加強，對基于第三代配置管理工具和過(guò)程的需要變得越來(lái)越大。Rational軟件的統一變更管理（UCM）通過(guò)Rational ClearCase，Rational ClearQuest以及Rational Suite所提供的開(kāi)發(fā)平臺實(shí)現了貫穿整個(gè)軟件開(kāi)發(fā)周期的配置管理過(guò)程，即基于活動(dòng)對軟件構件和項目進(jìn)行變更管理。
隨著(zhù)軟件系統和開(kāi)發(fā)團隊在規模和復雜性上的不斷增長(cháng)，對開(kāi)發(fā)團隊來(lái)說(shuō)如何圍繞周期性的版本發(fā)布來(lái)合理地組織開(kāi)發(fā)活動(dòng)以及高效地管理用于實(shí)現這些活動(dòng)的工件變得日益重要?；顒?dòng)（activity）可以是在現有產(chǎn)品中修復一個(gè)缺陷或者新加一個(gè)增強功能。工件（artifact）可以是在開(kāi)發(fā)生命周期中涉及的任何東西，例如需求文檔，源代碼，設計模型或者測試腳本等。實(shí)際上軟件開(kāi)發(fā)過(guò)程就是軟件開(kāi)發(fā)團隊執行活動(dòng)并生產(chǎn)工件（圖1）。UCM集成了由Rational ClearQuest提供的變更請求活動(dòng)管理和Rational ClearCase提供的工件管理功能。
活動(dòng)管理
UCM中的活動(dòng)管理是由Rational ClearQuest提供的，Rational ClearQuest是一個(gè)高度靈活和可擴展的缺陷及變更跟蹤系統，它可以捕獲和跟蹤所有類(lèi)型的變更請求（例如產(chǎn)品缺陷、增強請求、文檔變動(dòng)等）。在UCM中這些變更均以活動(dòng)出現。
Rational ClearQuest為活動(dòng)的跟蹤和管理提供了可定制的工作流，這使得開(kāi)發(fā)團隊可以更容易地：
將活動(dòng)分配給某個(gè)具體的開(kāi)發(fā)人員 標識同活動(dòng)相關(guān)的優(yōu)先級、當前狀態(tài)和其他信息（如負責人、估計工期、影響程度等） 自動(dòng)產(chǎn)生查詢(xún)、報告和圖表
根據開(kāi)發(fā)團隊或開(kāi)發(fā)過(guò)程需求可以靈活地調整ClearQuest工作流引擎：如果開(kāi)發(fā)團隊需要快速部署，那么也可以不進(jìn)行定制，直接使用ClearQuest預定義的變更過(guò)程、表單和相關(guān)規則（圖2）；當開(kāi)發(fā)團隊需要在預定義的過(guò)程上進(jìn)行定制時(shí)，可以使用ClearQuest對他們的變更過(guò)程的各個(gè)方面--包括缺陷和變更請求的狀態(tài)轉移生命周期，數據庫字段，用戶(hù)界面（表單）布局，報告，圖表和查詢(xún)等進(jìn)行定制。
貫穿整個(gè)開(kāi)發(fā)過(guò)程用于管理和跟蹤缺陷和其他變更的一個(gè)高效工作流對于滿(mǎn)足當今高質(zhì)量標準及緊迫的產(chǎn)品工期的需要是非常重要的。UCM提升了這些變更的抽象層次以便可以從活動(dòng)的角度來(lái)觀(guān)察變更，然后Rational ClearQuest工作流引擎將活動(dòng)同相關(guān)的開(kāi)發(fā)工件連接在一起。
工件管理
Rational ClearCase提供了一個(gè)軟件工件管理（SAM）框架，開(kāi)發(fā)團隊可以使用這一框架來(lái)管理貫穿項目生命周期的所有工件。UCM將Rational ClearCase基礎框架同Rational ClearQuest中的活動(dòng)管理結合在一起，從而提供了對工件和活動(dòng)的集成管理。Rational ClearCase提供了：
安全的工件存儲和版本化 并行開(kāi)發(fā)基礎框架--無(wú)限分支能力和強大的合并功能 自動(dòng)代碼共享 用于選擇正確工件版本的工作空間管理 完全的可延展性--從小型本地項目工作組到大型全球分布式開(kāi)發(fā)團隊
另外，Rational ClearCase提供了靈活的SCM的基礎框架，通過(guò)使用靈活的元數據，如標簽、分支、屬性、觸發(fā)器（trigger）和超級鏈接（hyperlinks）等，開(kāi)發(fā)團隊可以定制他們自己的SCM過(guò)程。
由此可見(jiàn)，不同開(kāi)發(fā)團隊和項目可以通過(guò)Rational ClearCase使用不同的策略，開(kāi)發(fā)團隊可以從這種靈活性中受益。而UCM是基于一個(gè)經(jīng)過(guò)驗證的、成功的開(kāi)發(fā)過(guò)程，因此UCM為希望快速啟動(dòng)高效SCM的開(kāi)發(fā)團隊也可以直接使用這一過(guò)程來(lái)自動(dòng)實(shí)現項目策略。UCM具體在以下六個(gè)方面提供了開(kāi)發(fā)過(guò)程。
UCM：六個(gè)過(guò)程領(lǐng)域
UCM在六個(gè)具體領(lǐng)域提供了所定義的過(guò)程：
開(kāi)發(fā)人員在共享及公共代碼工件上的隔離和協(xié)作； 將一起開(kāi)發(fā)、集成和發(fā)布的相關(guān)工件組按構件（component）進(jìn)行組織； 在項目里程碑創(chuàng )建構件基線(xiàn)（baseline）并根據所建立的質(zhì)量標準來(lái)提升基線(xiàn)； 將變更組織為變更集（change set）； 將活動(dòng)管理和工件管理集成在一起； 按項目來(lái)組織軟件開(kāi)發(fā)并支持多項目之間的代碼共享；
開(kāi)發(fā)人員的隔離和協(xié)作
開(kāi)發(fā)人員需要相互隔離的工作環(huán)境以隔離彼此的工作，避免其他組成員的變更潛在地影響其工作的穩定性。Rational ClearCase提供了兩種方式來(lái)訪(fǎng)問(wèn)工件的正確版本并在私有工作空間中在這些工件上進(jìn)行工作。這兩種方式是靜態(tài)視圖和獨特的基于MVFS的動(dòng)態(tài)視圖，它們可以據本地或網(wǎng)絡(luò )使用而分別進(jìn)行實(shí)施。
靜態(tài)視圖為開(kāi)發(fā)人員提供了在斷開(kāi)網(wǎng)絡(luò )連接的情況下進(jìn)行工作的靈活性，另外開(kāi)發(fā)人員也可以容易地將他們的工作同開(kāi)發(fā)主線(xiàn)進(jìn)行同步。動(dòng)態(tài)視圖則通過(guò)一個(gè)獨特的虛擬文件系統（MVFS）來(lái)實(shí)現，它使得開(kāi)發(fā)人員可以透明地訪(fǎng)問(wèn)正確工件的正確版本而無(wú)需將這些工件版本復制到本地硬盤(pán)驅動(dòng)器上。另外由于動(dòng)態(tài)視圖可以實(shí)時(shí)進(jìn)行自動(dòng)更新，因此緊密工作在同一分支上的開(kāi)發(fā)團隊無(wú)需手動(dòng)更新/復制文件即可立即看到其他人員所做的變動(dòng)。不管使用何種方式，開(kāi)發(fā)人員都可以并行工作在多個(gè)發(fā)布版本上。例如，一個(gè)開(kāi)發(fā)人員工作在發(fā)布版本2上，同時(shí)他也可以修復發(fā)布版本1中的一個(gè)缺陷，而不用擔心自己的兩個(gè)活動(dòng)涉及的代碼互相干擾或受其他開(kāi)發(fā)人員的干擾。
隔離不穩定的變更對于將錯誤最小化是非常關(guān)鍵的，但是將所有的變更集成到一個(gè)所有開(kāi)發(fā)團隊成員均可訪(fǎng)問(wèn)的公共工作區域卻是團隊開(kāi)發(fā)環(huán)境下的一個(gè)基本要求。今天基于構件的軟件開(kāi)發(fā)方法論的廣泛應用以及代碼變更頻率和幅度的增加都要求開(kāi)發(fā)團隊能經(jīng)常和較早地將各個(gè)開(kāi)發(fā)人員的工作進(jìn)行集成。以便在盡早解決可能出現的問(wèn)題。
使用Rational ClearCase，開(kāi)發(fā)團隊可以實(shí)現多種項目策略來(lái)同時(shí)進(jìn)行工作的隔離和協(xié)作。通過(guò)強大的分支和合并功能Rational ClearCase可以支持大規模的并行開(kāi)發(fā)。
在ClearCase中可以根據不同用途來(lái)建立分支，如開(kāi)發(fā)人員分支，新特性分支、缺陷修復分支、新需求分支等等，從而開(kāi)發(fā)團隊可以根據需要建立適于自身情況的分支模型，靈活實(shí)現軟件配置管理流程。但對于希望能快速利用成熟的軟件開(kāi)發(fā)流程的開(kāi)發(fā)團隊而言，UCM則提供了一個(gè)直接可用的分支模型。實(shí)際上在UCM中，在分支基礎上對其在更高層次上進(jìn)行了抽象，從而形成了一個(gè)新概念--流（stream）。流表示一個(gè)私有或共享的工作空間，它定義了項目版本的一致配置并在UCM項目中的隔離和有效協(xié)作之間提供了一種平衡。熟悉ClearCase的讀者可以將流理解為開(kāi)發(fā)人員分支，UCM中既有為每個(gè)開(kāi)發(fā)人員配置的私有開(kāi)發(fā)流，同時(shí)為負責集成所有交付工作的集成人員配置的公共集成流 （圖3）。由于UCM緊密結合了活動(dòng)管理，因此其他分支用途，如特性分支、缺陷修復分支等將作為活動(dòng)出現并附加到相應的工作流中。
私有開(kāi)發(fā)流為開(kāi)發(fā)人員提供了相互隔離的工作空間，該空間在最開(kāi)始由滿(mǎn)足一定質(zhì)量標準的公共工件進(jìn)行初始化。開(kāi)發(fā)人員使用這些私有工作空間來(lái)進(jìn)行工件的變更，構建和測試。當開(kāi)發(fā)人員對他們的變更感到滿(mǎn)意時(shí)，他們可以將這些變更交付（deliver）到公共集成流上。為了使開(kāi)發(fā)人員同其他人員的進(jìn)度同步，開(kāi)發(fā)人員也可以用來(lái)自項目公共集成流上最新的穩定基線(xiàn)來(lái)變基（rebase）他們的私有工作流。使用UCM，開(kāi)發(fā)人員可以選擇什么時(shí)候進(jìn)行交付和變基。
實(shí)際上項目集成流充當了所有開(kāi)發(fā)人員的所有變更的協(xié)調點(diǎn)。為了更好地協(xié)調所有開(kāi)發(fā)人員的變更集成，UCM引入了基線(xiàn)（baseline）的概念作為對項目進(jìn)度的度量?；€(xiàn)是一次構建（build）或配置的抽象表示，它實(shí)際上是構件的一個(gè)版本，而構件是相關(guān)工件的集合。項目開(kāi)發(fā)團隊在開(kāi)發(fā)過(guò)程期間不斷地創(chuàng )建和提升基線(xiàn)。隨著(zhù)不同開(kāi)發(fā)人員交付變更給集成流，他們交付的變更將被逐一收集到項目基線(xiàn)中。隨著(zhù)基線(xiàn)的構建、測試和批準，它們可以被逐步提升到不同的基線(xiàn)級別。
基線(xiàn)提升級別具有兩方面的功能：第一，它使項目經(jīng)理或項目管理人員可以建立軟件質(zhì)量標準。由于當基線(xiàn)達到某種預定義的質(zhì)量標準時(shí)就可以被標以某種基線(xiàn)級別，因此項目經(jīng)理可以設置項目策略，標識出在哪一個(gè)基線(xiàn)級別（如"通過(guò)測試的"）開(kāi)發(fā)人員可以執行變基操作。第二，基線(xiàn)提升級別就具體的開(kāi)發(fā)人員應該如何同其所開(kāi)發(fā)的工件進(jìn)行交互提供了指導。例如，根據某條基線(xiàn)通過(guò)某些冒煙測試的時(shí)間可以幫助測試人員確定什么時(shí)候開(kāi)始測試。
構件基線(xiàn)
第二個(gè)UCM過(guò)程領(lǐng)域是將工件組織為構件。在第二代配置管理中，大多以文件版本形式來(lái)管理所有的文件，當一個(gè)復雜項目中包含成千個(gè)文件上萬(wàn)個(gè)版本時(shí)，整個(gè)項目的開(kāi)發(fā)控制將變得相當復雜，因此對眾多的文件進(jìn)行合理分類(lèi)以呈現系統的設計要素可以大大簡(jiǎn)化項目開(kāi)發(fā)控制。
UCM通過(guò)將多個(gè)工件組織為構件（在UCM中構件指一個(gè)VOB的根目錄或VOB的某個(gè)第一層子目錄）從而擴展了軟件工件管理的版本控制能力，并且UCM還提供了用于自動(dòng)化構件管理的工具和過(guò)程。即用基線(xiàn)對構件而不是構件中眾多的版本進(jìn)行標識，然后用這一基線(xiàn)作為新的開(kāi)發(fā)起點(diǎn)并更新開(kāi)發(fā)人員的工作空間。
構件基線(xiàn)是在ClearCase標簽（label）的基礎上結合活動(dòng)管理所做的擴展，即您可以知道一個(gè)UCM構件基線(xiàn)中包含了哪些開(kāi)發(fā)活動(dòng)，例如一條基線(xiàn)可能包含了三個(gè)開(kāi)發(fā)活動(dòng)，如BUG 101的修復、用戶(hù)登錄界面漢化以及新增打印特性的支持。
對于包含多個(gè)構件的復雜系統，UCM提供了基于多個(gè)構件的組合基線(xiàn)，即多個(gè)構件之間可以建立依賴(lài)關(guān)系，一旦底層構件的基線(xiàn)發(fā)生變化，例如生成一條新基線(xiàn)，其上層構件相應地也自動(dòng)建立起一條基線(xiàn)，該基線(xiàn)自動(dòng)包含底層構件基線(xiàn)。例如，一個(gè)較為復雜的MIS系統包含"數據庫訪(fǎng)問(wèn)"，"業(yè)務(wù)邏輯處理"和"前端圖形界面"三個(gè)構件，其中"前端圖形界面"構件依賴(lài)于"業(yè)務(wù)邏輯處理"構件，而"業(yè)務(wù)邏輯處理"構件依賴(lài)于"數據庫訪(fǎng)問(wèn)"構件。這樣當"數據庫訪(fǎng)問(wèn)"構件發(fā)生了變化并新建了一條新基線(xiàn)（如DB_BASELINE_Dec24）后，在"業(yè)務(wù)邏輯處理"構件和"前端圖形界面"構件各自動(dòng)建立了一條新基線(xiàn)（如BUSINESS_BASELINE_Dec24和GUI_BASELINE_Dec24）。這樣上層構件的最新基線(xiàn)可以自動(dòng)跟蹤底層構件的最新基線(xiàn)。
構件管理的自動(dòng)化對于高效無(wú)誤地開(kāi)發(fā)可能包含數千個(gè)源代碼工件（還有其他相關(guān)的工件，如web內容，設計模型，需求說(shuō)明和測試腳本等）的復雜軟件系統而言意義重大。
構件基線(xiàn)提升
項目開(kāi)發(fā)團隊的成員工作在一個(gè)UCM項目（project）中，項目經(jīng)理通過(guò)配置軟件構件從而使項目成為由構件構成的體系結構。大多數組織將UCM管理的構件設計為可以反映出他們軟件體系結構的方式（圖4），即將所有相關(guān)工件按體系結構組織為有意義的子系統，進(jìn)而放入不同的構件中。
如上節所描述的，開(kāi)發(fā)人員在交付變更到公共集成流時(shí)可以周期性地更新他們私有開(kāi)發(fā)流中的構件。然后開(kāi)發(fā)團隊可以根據開(kāi)發(fā)過(guò)程的當前階段和質(zhì)量級別對構件進(jìn)行評級。項目策略確定了在開(kāi)發(fā)人員變基之前構件基線(xiàn)必須達到的質(zhì)量級別以及其他開(kāi)發(fā)團隊成員（如測試人員）應該如何同構件基線(xiàn)交互。在稍后會(huì )對項目以及項目策略做更多描述。 UCM提供了五種預定義的基線(xiàn)級別，它們包括被拒絕（rejected），初始（initial），通過(guò)構建（built），通過(guò)測試（tested）和已發(fā)布（released）。另外，UCM允許開(kāi)發(fā)團隊用他們自己的命名規范和提升策略對這些預定義基線(xiàn)級別進(jìn)行定制。
變更集
第四個(gè)UCM過(guò)程領(lǐng)域是將獨立的工件變更組織為可作為整體進(jìn)行交付、跟蹤和管理的變更集中。由于通常當開(kāi)發(fā)人員工作在一個(gè)活動(dòng)（例如缺陷修復）上時(shí)，他們很少只修改一個(gè)文件，因此用變更集可以表示用以完成某個(gè)具體活動(dòng)的工件的所有變更，例如為修改一個(gè)編號為63的缺陷變動(dòng)了50個(gè)目錄/文件的120個(gè)版本，則缺陷63的變更集為相關(guān)的120個(gè)文件/目錄版本。當開(kāi)發(fā)人員同時(shí)工作在多個(gè)變更請求上的需要使得這一過(guò)程更加復雜。例如，一個(gè)開(kāi)發(fā)人員在進(jìn)行一個(gè)新發(fā)布版本的開(kāi)發(fā)，這時(shí)由于當前發(fā)布版本的一個(gè)錯誤要求他不得不中斷當前的開(kāi)發(fā)工作轉而去修復這一缺陷，這樣該開(kāi)發(fā)人員必須在同一工件上進(jìn)行兩種不同的變更，一種是在未來(lái)發(fā)布版本中的增強功能變更，另一種是在前一發(fā)布版本中修復缺陷的變更。
通過(guò)將同一個(gè)開(kāi)發(fā)活動(dòng)相關(guān)的所有變更收集到一個(gè)變更集中，UCM簡(jiǎn)化了管理多個(gè)工件變更或者多個(gè)工件版本的過(guò)程。UCM圍繞具體的開(kāi)發(fā)活動(dòng)來(lái)進(jìn)行工作組織，同時(shí)UCM還確保已完成的活動(dòng)包含所有必要工件上發(fā)生的所有變更。
活動(dòng)和工件管理
第五個(gè)UCM過(guò)程領(lǐng)域是通過(guò)使用一個(gè)可將活動(dòng)及其相關(guān)工件集鏈接起來(lái)的自動(dòng)化工作流（圖5）將活動(dòng)管理和工件管理集成起來(lái)。這給了開(kāi)發(fā)團隊極大的靈 活性來(lái)為不同類(lèi)型活動(dòng)的管理指定不同的工作流。UCM提供了最常用活動(dòng)類(lèi)型的預定義工作流，包括缺陷修復和增強請求。
開(kāi)發(fā)團隊還可以使用ClearQuest Designer這一模塊來(lái)對這些預定義過(guò)程進(jìn)行定制，項目經(jīng)理或者項目管理人員可以用它來(lái)創(chuàng )建所有需要的活動(dòng)類(lèi)型，包括缺陷修復，增強功能請求，文檔變動(dòng)以及Web網(wǎng)站變動(dòng)等。使用ClearQuest Designer的圖形用戶(hù)界面，項目經(jīng)理也可以定義字段，表單以及每個(gè)記錄類(lèi)型的狀態(tài)轉移。
為了方便開(kāi)發(fā)人員更容易地標識活動(dòng)和項目代碼庫中工件間的關(guān)系，UCM自動(dòng)將活動(dòng)和其相關(guān)的變更集鏈接起來(lái)（圖6）。當在一個(gè)UCM項目中工作時(shí)，開(kāi)發(fā)人員所交付的是活動(dòng)（見(jiàn)開(kāi)發(fā)人員隔離和協(xié)作一節）而不是文件形式的工件。類(lèi)似的，當開(kāi)發(fā)人員變基時(shí)，他們根據新構件基線(xiàn)提供的活動(dòng)（而不是文件形式的工件）來(lái)重審將要在他們的私有開(kāi)發(fā)流中接收的變更內容。這樣，開(kāi)發(fā)人員不僅可以看到所有相關(guān)工件完整的版本歷史，而且可以看到實(shí)現每個(gè)變更的所有活動(dòng)。這給了開(kāi)發(fā)團隊一個(gè)項目是如何從一個(gè)階段演進(jìn)到下一個(gè)階段 演進(jìn)的全面視圖，當需要標識出一個(gè)工件版本的變更是如何影響另一個(gè)版本時(shí)，這一優(yōu)點(diǎn)所帶來(lái)的價(jià)值是無(wú)法估計的。
使用UCM一致、可重復的用于活動(dòng)管理的過(guò)程，通過(guò)活動(dòng)管理和工件管理的集成可以幫助開(kāi)發(fā)團隊減少錯誤，開(kāi)發(fā)人員還可以避免許多通常需要手工作業(yè)的單調工作，從而更有效率地完成開(kāi)發(fā)任務(wù)。
項目和項目策略
UCM中的項目可以和實(shí)際軟件開(kāi)發(fā)中的各種項目對應，每個(gè)UCM項目包含一個(gè)集成工作流和若干個(gè)私有開(kāi)發(fā)流，項目可由一組構件構成。這里需要強調的是一個(gè)構件可以被多個(gè)項目共享，進(jìn)而項目A中的開(kāi)發(fā)人員可以對一個(gè)構件進(jìn)行修改，創(chuàng )建新的構件基線(xiàn)；而項目B的開(kāi)發(fā)人員可以參照同一構件以及該構件在項目A中生成的基線(xiàn)，但不能對該構件進(jìn)行任何改動(dòng)。因而UCM項目從代碼級提供了軟件共享及重用的良好基礎。例如某系統集成公司的湖北分公司剛剛結束了為某銀行開(kāi)發(fā)的客服系統1.0的開(kāi)發(fā)（我們可以將最終交付的版本稱(chēng)之為XBANK_CRM_HuBei_1.0），與此同時(shí)該系統集成公司的北京分公司正準備為另一家銀行進(jìn)行類(lèi)似系統的開(kāi)發(fā)。另外XBANK_CRM_HuBei_1.0在推廣過(guò)程中出現了一些問(wèn)題，亟待解決。還有該客服系統2.0版XBANK_CRM_HuBei_2.0的需 求分析準備在下月開(kāi)始。此時(shí)如果利用UCM的多項目機制則可以為在北京的開(kāi)發(fā)團隊建立一個(gè)新項目CRM_Beijing_1.0，但該項目并不是從零開(kāi)始的，它可以從XBANK_CRM_HuBei_1.0開(kāi)始，有選擇地借鑒XBANK_CRM_HuBei_1.0中可共享的部分。同時(shí)原有的XBANK_CRM_HuBei_1.0的開(kāi)發(fā)人員可以繼續進(jìn)行2.0版的研制工作。而為了解決XBANK_CRM_HuBei_1.0中在推廣中出現的問(wèn)題又可以新建一個(gè)XBANK_CRM_HuBei_1.0版的維護項目XBANK_CRM_HuBei_1.0_BUGFIX，部分原有開(kāi)發(fā)人員既可以加入該項目進(jìn)行原有1.0版的錯誤修復，又可以互不干擾地在原有項目中進(jìn)行2.0版的需求分析。
UCM在項目上另一個(gè)突出特點(diǎn)是不同項目中的開(kāi)發(fā)流之間可以進(jìn)行跨項目的工作交付。即一個(gè)項目可以將一條構件基線(xiàn)中包含的工件交付給另一個(gè)項目，也可以將一個(gè)開(kāi)發(fā)流上的活動(dòng)變更集交付給另一個(gè)項目。緊接上例，假設過(guò)了三個(gè)月后項目XBANK_CRM_HuBei_1.0_BUGFIX修復了8個(gè)缺陷，而項目CRM_Beijing_1.0也根據北京用戶(hù)的特點(diǎn)實(shí)現了3個(gè)不同的新特性，這時(shí)如果需要可以在恰當時(shí)機將這兩個(gè)項目中的成果有選擇地交付給正在湖北進(jìn)行的客服2.0版的開(kāi)發(fā)，從而使得2.0版不僅修復了前一版本中的錯誤，而且具備了3個(gè)新特性。
可以看出項目從一個(gè)更高層次上支持了傳統意義上基于分支的并行開(kāi)發(fā)，這對于軟件開(kāi)發(fā)組織從面向項目到面向產(chǎn)品的轉變，合理利用軟件開(kāi)發(fā)人力資源，改善軟件產(chǎn)品體系結構從而支持更為復雜的軟件開(kāi)發(fā)具有重大意義。
由于同一代碼構件上多項目開(kāi)發(fā)的引入，相應地UCM加入了多種項目策略來(lái)進(jìn)行支持，用戶(hù)可以根據需要靈活定義項目策略。例如上面提到的基線(xiàn)級別，可以定義只有基線(xiàn)級別提升到"Tested"才能作為其他開(kāi)發(fā)工作流的推薦基線(xiàn)。另外，對于多項目間的代碼交付和共享，還可以定義是否允許接受其他項目的變更等。除了項目一級的策略以外，在工作流一級UCM也有類(lèi)似的訪(fǎng)問(wèn)策略，如某個(gè)工作流是否允許接受來(lái)自本項目或其他項目的工作流上的變更，是否允許向本項目或其他項目的工作流交付變更等等。
開(kāi)發(fā)團隊采用
成功的軟件配置管理需要同時(shí)重視人的活動(dòng)和得到整個(gè)開(kāi)發(fā)團隊的全體接受。如果開(kāi)發(fā)團隊成員不能或不采用SCM方法論的話(huà)，SCM實(shí)現將會(huì )失敗。Rational軟件多年來(lái)從成功的軟件開(kāi)發(fā)團隊和自身的軟件開(kāi)發(fā)中吸取最佳實(shí)踐經(jīng)驗，將UCM作為一個(gè)可為開(kāi)發(fā)團隊采用的優(yōu)化過(guò)程來(lái)進(jìn)行設計。UCM的功能已全部嵌入到Rational統一開(kāi)發(fā)過(guò)程管理（Rational Unified Process，RUP）中，RUP是在軟件開(kāi)發(fā)的各個(gè)生命周期應用最佳軟件開(kāi)發(fā)經(jīng)驗的一個(gè)實(shí)用框架。軟件開(kāi)發(fā)團隊通過(guò)直接訪(fǎng)問(wèn)RUP并通過(guò)Rational ClearCase，Rational ClearQuest和Rational Suite的工具專(zhuān)家可以得到關(guān)于UCM過(guò)程及其詳細描述。
UCM通過(guò)使開(kāi)發(fā)人員可以完成下面的工作而簡(jiǎn)化了他們的工作：
快速準確地訪(fǎng)問(wèn)正確工件的正確版本 在他們的工作空間中相互隔離地進(jìn)行各自的工作，但可以選擇什么時(shí)候交付自己的工作及接收其他人員的變更 使用項目策略來(lái)標識什么時(shí)候質(zhì)量達到了可以接受的級別從而可以在自己的私有工作空間中接收其他人員的變更 從他們自己的桌面透明地訪(fǎng)問(wèn)SCM工具。使用可同他們最常使用的工具（如Visual C++）進(jìn)行集成的工具來(lái)進(jìn)行他們的工作--在開(kāi)發(fā)活動(dòng)上沒(méi)有附加不適當約束或增加工作時(shí)間 自動(dòng)而透明地將變更集同活動(dòng)進(jìn)行集成 自動(dòng)進(jìn)行活動(dòng)的跟蹤、管理和報告。
另外，UCM還減輕了項目經(jīng)理的負擔，從而項目經(jīng)理可以
通過(guò)一個(gè)預定義的生命周期工作流在任何時(shí)間標識一個(gè)具體活動(dòng)的狀態(tài) 用統一的報告來(lái)監控最新的項目狀態(tài) 將精力集中在高優(yōu)先級或緊急的事件（活動(dòng)）上 確定工作負載并平衡任務(wù)分配
到現在為止，本文主要集中在源代碼和其相關(guān)工件上，如對象文件和頭文件等。但是使用UCM時(shí)貫穿生命周期的變更也可以由非開(kāi)發(fā)人員進(jìn)行管理，這樣就最佳實(shí)現了統一變更管理的全部好處。這些非開(kāi)發(fā)人員包括分析人員，設計人員以及測試人員（圖7）。相應的工件包括他們在相關(guān)領(lǐng)域產(chǎn)生的工件，例如分析人員所創(chuàng )建的需求文檔和用例（use cases），設計人員所建立的設計模型和用例，測試人員建立的測試腳本，測試數據和測試結果。
為了高效地通信和協(xié)作工作，開(kāi)發(fā)團隊成員需要有效地共享這些工件。Rational Suite包含有一個(gè)集成平臺，通過(guò)這一公共平臺可以訪(fǎng)問(wèn)貫穿多個(gè)領(lǐng)域的所有類(lèi)型的開(kāi)發(fā)工件。作為Rational Suite的一部分，UCM提供了一個(gè)用于管理貫穿軟件開(kāi)發(fā)生命周期的信息共享的過(guò)程層?，F在每個(gè)Rational Suite產(chǎn)品套件中均包含了這兩個(gè)產(chǎn)品，這樣每個(gè)Rational Suite產(chǎn)品都包含了對UCM過(guò)程的支持。非軟件開(kāi)發(fā)人員（如分析人員、設計人員以及測試人員）可以應用UCM原理象控制代碼變更一樣來(lái)控制他們生產(chǎn)的工件（如需求文檔，用例，設計模型，測試腳本及測試數據）。Rational ClearQuest工作流引擎強化了活動(dòng)管理，另外一致的工作流使得所有的團隊成員都可以容易地標識優(yōu)先級，而ClearQuest提供的工作列表（to do list）特性可以使每個(gè)人均可從他們的桌面透明訪(fǎng)問(wèn)待進(jìn)行的工作（活動(dòng)）列表，從而容易地標識出他們下一步需要進(jìn)行的工作。同樣構件基線(xiàn)是新工作（分析、設計、開(kāi)發(fā)及測試）的基礎并指導團隊成員什么時(shí)候更新他們工作空間。
來(lái)自分析的工件
分析人員扮演著(zhù)定義項目范圍的重要角色，分析人員需要確定解決方案是什么以及系統邊界。在分析期間這些專(zhuān)業(yè)人員創(chuàng )建了多種不同的工件來(lái)幫助解釋說(shuō)明所建議的解決方案，這些工件包括需求文檔，用例以及可視化模型。開(kāi)發(fā)團隊在整個(gè)開(kāi)發(fā)過(guò)程中不斷使用這些工件來(lái)管理項目變更是必不可少的。
成功的項目依賴(lài)于正確的需求管理。高效的需求管理包括減少開(kāi)發(fā)的進(jìn)度風(fēng)險和系統的不穩定性，以及跟蹤需求變更。項目管理，風(fēng)險評估以及相關(guān)評估標準的產(chǎn)生都依賴(lài)于需求管理和需求的可追溯性--即開(kāi)發(fā)團隊以一種規范過(guò)程接受變更并審查需求變更的歷史。
Rational RequisitePro是Rational Suite 開(kāi)發(fā)團隊統一平臺（Team Unifying Platform）中用于需求管理的工具。軟件開(kāi)發(fā)團隊可以使用RequisitePro來(lái)創(chuàng )建、管理和跟蹤分析工件--例如需求屬性、需求說(shuō)明和管理計劃，以及用例模型，術(shù)語(yǔ)表以及涉眾（stakeholder）請求。
UCM項目以同管理代碼相似的方式管理需求，此外UCM還將這些需求工件包含在構件基線(xiàn)中。這樣分析人員不僅知道哪些活動(dòng)構成了一條構件基線(xiàn)中的工件，還知道哪些需求指導著(zhù)這些工件的開(kāi)發(fā)。
來(lái)自設計的工件
設計人員對系統基礎結構建模并使用用例和設計模型進(jìn)一步細化系統定義。通過(guò)設計工件對系統進(jìn)行抽象，可以減少整個(gè)系統的復雜性。
在實(shí)際開(kāi)發(fā)過(guò)程中經(jīng)常會(huì )出現這樣一種情況：一些開(kāi)發(fā)團隊不能繼續使用一些設計模型，因為正式的編碼工作已經(jīng)開(kāi)始。這是一個(gè)錯誤，因為這些設計模型在幫助規劃整個(gè)工作，另外對于協(xié)助新的組成員快速上手，度量正在進(jìn)行中的變更請求的影響，以及評估整個(gè)項目風(fēng)險都非常有價(jià)值。由Rational Rose提供的雙向工程功能可以幫助開(kāi)發(fā)團隊保持當前編碼進(jìn)度和這些模型之間的同步（圖8），而UCM確保模型與代碼是最新的。
在UCM項目中，構件基線(xiàn)包含模型工件和代碼工件。Rose Model Integrator和ClearCase 比較/合并特性的緊密集成使得開(kāi)發(fā)團隊可以盡可能方便地在設計模型的同時(shí)進(jìn)行編碼。這時(shí)UCM中的變更集（參見(jiàn)變更集部分）可以擴展到模型元素，這樣變更集便包含了代碼工件上的變更以及模型工件上的變更。Rational Rose支持UCM交付（deliver）和變基（rebase）操作（參見(jiàn)活動(dòng)和工件管理部分），使得多個(gè)設計人員可以在Rose模型上同時(shí)工作，如同開(kāi)發(fā)人員并發(fā)工作在代碼上一樣。
來(lái)自測試的工件
傳統的開(kāi)發(fā)方法將測試工作放到開(kāi)發(fā)的末期，在編碼工作之后進(jìn)行。成功的構件開(kāi)發(fā)團隊都體會(huì )到單元測試（unit test）對于項目成功是非常重要的，使用單元測試就是不將構件的質(zhì)量保證放到集成階段，而是預先對單元、子系統和系統進(jìn)行測試。
所有這些并發(fā)測試產(chǎn)生了大量的測試工件--包括測試需求、測試腳本、測試數據和大量的測試結果。Rational Suite TestStudio以及Rational QualityArchitect為開(kāi)發(fā)團隊提供了可持續地生產(chǎn)高質(zhì)量軟件工件所需的集成框架。借助UCM，開(kāi)發(fā)團隊可以并發(fā)地管理他們的測試工件和相關(guān)的開(kāi)發(fā)工件。
今天，大多數開(kāi)發(fā)團隊都意識到將這些測試工件和構件基線(xiàn)集成到一起的好處。在UCM項目中，可以在一條構件基線(xiàn)中包含所有的代碼工件以及相關(guān)的測試需求，測試程序和測試數據。
這樣前面描述的變更集就可以擴展到測試用例，測試腳本和測試數據。集成的活動(dòng)和工件管理將活動(dòng)的整個(gè)范圍--從對代碼變更的測試校驗活動(dòng)--到由其活動(dòng)描述的UCM變更集鏈接起來(lái)。
分析，設計，編碼和測試工件
Rational Suite和UCM提供的優(yōu)點(diǎn)是無(wú)價(jià)的。構件基線(xiàn)在一條基線(xiàn)中包容了所有的項目工件--從需求文檔到測試包--這對于任何需要進(jìn)行維護和升級任務(wù)的開(kāi)發(fā)團隊都是一個(gè)大優(yōu)點(diǎn)。借助UCM基線(xiàn)級別，使用Rational Suite跨功能的多個(gè)組可以更容易地：
標識所需的活動(dòng) 確定什么時(shí)候變基 標識需測試的活動(dòng) 評估開(kāi)發(fā)中的工件
另外，UCM基線(xiàn)級別幫助開(kāi)發(fā)團隊識別什么時(shí)候開(kāi)始跨功能的活動(dòng)，例如，在編碼結束后經(jīng)過(guò)一系列單元測試和冒煙測試（smoke test）一條基線(xiàn)達到了可以進(jìn)行集成測試的質(zhì)量級別，這時(shí)可以提升該構件基線(xiàn)從而啟動(dòng)集成測試活動(dòng)。 在UCM中，質(zhì)量監控是依靠Rational ClearQuest提供的快速報告功能來(lái)進(jìn)一步進(jìn)行加強的。通過(guò)這些報告功能，組成員可以生成清晰而簡(jiǎn)明的項目狀態(tài)數據以便快速探測問(wèn)題，評估風(fēng)險并快速達成解決方案。另外項目管理人員可以將工作圍繞高優(yōu)先級的活動(dòng)展開(kāi)并且確保所有的發(fā)布版本都滿(mǎn)足預定義的質(zhì)量級別。
隨著(zhù)Internet持續增長(cháng)并逐步成為同客戶(hù)交易和收集戰略信息的主要渠道，軟件開(kāi)發(fā)團隊建立支持這些功能應用的壓力也在增長(cháng)。這一趨勢使得軟件開(kāi)發(fā)團隊（包括所有類(lèi)型和所有規模的軟件開(kāi)發(fā)團隊）對用于管理變更的、可預測和 可重復的過(guò)程的需要變得日趨迫切。通過(guò)Rational ClearCase，Rational ClearQuest以及Rational Suite中的統一變更管理能力，Rational軟件提供了用于控制軟件開(kāi)發(fā)中變更的全面軟件配置管理方案?；诙嗄陙?lái)對軟件開(kāi)發(fā)領(lǐng)域的觀(guān)察和Rational軟件開(kāi)發(fā)而得到的最佳經(jīng)驗，Rational UCM通過(guò)活動(dòng)來(lái)組織變更并通過(guò)構件和項目在更高的層次上抽象軟件開(kāi)發(fā)，從而提供了一種實(shí)用的解決方案來(lái)解決Internet時(shí)代高質(zhì)量軟件應用帶來(lái)的挑戰。
