1、統一變更管理（UCM）- 一種基于活動的配置管理過程前言二十多年來，Rational軟件一直致力于提供全面可靠的軟件開發管理解決方案，其中軟件配置管理（software configuration management，SCM）解決方案集成了兩個業界領先的工具：用于軟件工件管理（software artifact management，SAM）的Rational ClearCase和用于缺陷及變更跟蹤的Rational ClearQuest。這兩個工具合在一起構成了一個市場領先的軟件配置管理系統，提供了真正用于加速軟件開發周期和流程的解決方案，這一方案已連續四年居市場第一位（摘自IDC報告：&

2、quot;Rationals SCM solution continued to dominate the software configuration management market in 2001, with a 36.5 percent share. Rationals SCM solution market share grew in 2001 despite a decline in revenue in the overall SCM market during the year."）。在大量軟件工程實踐經驗和用戶反饋的基礎上，Rational軟件提出了第三代的配置管

3、理解決方案- 統一變更管理（UCM）。這里，首先，讓我們簡單回顧一下軟件配置管理的發展歷程：軟件配置管理在其不長的發展歷史中不斷進行演化，從七十年代基于文件（File Based）以版本控制、支持check-out/check-in模型和簡單分支為主要特征的第一代軟件配置管理，到基于項目庫（Project Based）將元數據與配置項分開存儲管理從而更好地支持并行開發、團隊協作以及過程管理的第二代軟件配置管理，發展到今天基于文件訪問透明（File Transparency Based，即開發人員可以在不保留本地副本的情況下直接訪問受控配置項）、全面結合變更請求管理（Software Chang

4、e Management）、軟件系統分析設計以及軟件測試等等各個軟件開發環節的完整的軟件配置管理方案。而Rational配置管理解決方案UCM正是體現這一趨勢的代表。以前兩代配置管理方法為基礎上，Rational軟件提出的統一變更管理（UCM）是用于管理軟件開發過程（包括從需求到版本發布）中所有變更的"最佳實踐"流程。UCM定義了一個可以立即用于軟件開發項目的一致并基于活動的變更管理流程。通過Rational ClearCase和ClearQuest的支持，UCM已成為Rational用于軟件開發最佳實踐的全面框架-Rationial統一過程（RUP）的關鍵組成部分。根據軟

5、件開發團隊的具體需要，可以使用相應的過程模型來加速軟件開發進度，提高軟件質量并優化開發過程。UCM通過抽象層次的提升簡化了軟件開發，從而使得軟件開發團隊從更高的層次根據活動（activity）來管理變更。通過UCM，一個開發活動可以自動地同其變更集（封裝了所有用于實現該活動的項目工件）相關聯，這樣避免了管理人員手動跟蹤所有文件變更。使用UCM還可以獲得以下好處：· 預定義的工作流程：可以直接采用預定義的UCM工作流程，快速提升開發組織的軟件配置管理水平； · 項目的跟蹤和組織：項目管理人員可以實時掌握項目的最新動態，合理分配資源和調度開發活動； · 協作自動化：通

6、過將許多耗時較多的任務自動化處理，UCM使得開發人員更多地將注意力集中在更高層次的開發活動上； · 輕松管理基線：UCM將開發活動嵌入到各個基線中，這樣測試人員確切地知道他們將測試什么，而開發人員則確切地知道其他開發人員做了什么； · 支持跨功能開發組：UCM已成為Rational Suite產品中的核心部分，從而可以將從需求到測試各個階段的工件（例如需求文檔、設計模型、應用源代碼、測試用例以及HTML及XML內容等）在UCM框架下進行統一集成，簡化了貫穿整個軟件開發周期的變更過程； · 基于同一代碼構件可以進行多項目開發，簡化了多項目開發管理，增大了代碼共享，節

7、省了開發資源； · 可擴展性：小型團隊可以從ClearCase LT和UCM開始，而大型團隊可以結合ClearCase的高級構建管理（build managment）功能，以及ClearCase MultiSite和ClearQuest MultiSite跨地域的使用UCM。 本文第三代配置管理解決方案：一種基于活動的配置管理過程詳細描述了統一變更管理（UCM）的概念、優點以及開發團隊如何通過使用Rational ClearCase，Rational ClearQuest和Rational Suite來受益。軟件開發過程中的變更變更是非常頻繁并且是不可避免的！今天的軟件開發團隊面臨著

8、巨大的挑戰：一方面Internet驅動下的市場要求以空前的速度來開發高質量的軟件應用；另一方面，軟件應用需求隨著開發環境和結構的日趨復雜而變得更加復雜；加上分布式開發、高性能要求、多平臺、更短和連續的發布周期-這些及其他一些因素加重了軟件開發一直承受的壓力，實際上現在許多軟件開發團隊經常在能否成功開發一個新型應用上"賭博"。由于軟件開發不同于傳統意義的工程技術（如建筑、機械等），市場變化以及技術上的高速更新都注定了軟件變更是非常頻繁并且是不可避免的，可以說變更是軟件開發的基石。一方面在軟件開發環境下的內部活動以新特性、新功能增強以及缺陷修復等方式不停地制造著變更；另一方面外

9、部因素-例如新操作環境，新工具的集成，工程技術和市場條件的改善等以另一種力量驅動著變更。管理變更的能力是項目成敗的關鍵！既然變更是不可避免的，那么如何管理、追蹤和控制變更就顯得尤為重要。盡管有多種方式可以幫助開發團隊提高變更處理能力，但其中最重要的一點是整個團隊的協作性，這是因為以一種可重復和可預測的方式進行高質量軟件的開發需要一組開發人員相互協作。隨著系統變得越來越大和越來越復雜，盡管個人生產率依然十分重要，但是決定項目成敗更多的是作為一個整體的開發團隊的生產率。而軟件開發團隊的生產率很大程度上是由其相互協作和組織活動的能力決定的，并且開發團隊的成功同其如何高效地響應不斷變化的環境因素緊密相

10、連。對在競爭激烈的市場下想占有一席之地的開發團隊而言拒絕變更無疑是行不通的，只有積極面對變更，采取有效的工具、方法和流程有機地管理、追蹤和控制變更才是保證開發團隊成功的關鍵。另外，由于各種因素的變更，原來采用的工具、方法和流程也會隨著組織的成長和不停變化的需求而逐步演化，因此對軟件開發團隊來說另一個關鍵的成功因素是其擴展能力。統一變更管理隨著開發團隊的成長、產品發布周期的加速以及對軟件資產（包括代碼、文檔等）控制的加強，對基于第三代配置管理工具和過程的需要變得越來越大。Rational軟件的統一變更管理（UCM）通過Rational ClearCase，Rational ClearQuest以

11、及Rational Suite所提供的開發平臺實現了貫穿整個軟件開發周期的配置管理過程，即基于活動對軟件構件和項目進行變更管理。活動和工件隨著軟件系統和開發團隊在規模和復雜性上的不斷增長，對開發團隊來說如何圍繞周期性的版本發布來合理地組織開發活動以及高效地管理用于實現這些活動的工件變得日益重要。活動（activity）可以是在現有產品中修復一個缺陷或者新加一個增強功能。工件（artifact）可以是在開發生命周期中涉及的任何東西，例如需求文檔，源代碼，設計模型或者測試腳本等。實際上軟件開發過程就是軟件開發團隊執行活動并生產工件（圖1）。UCM集成了由Rational ClearQuest提供的

12、變更請求活動管理和Rational ClearCase提供的工件管理功能。圖1：UCM集成了Rational ClearQuest提供的活動管理能力和Rational ClearCase提供的工件管理功能活動管理 UCM中的活動管理是由Rational ClearQuest提供的，Rational ClearQuest是一個高度靈活和可擴展的缺陷及變更跟蹤系統，它可以捕獲和跟蹤所有類型的變更請求（例如產品缺陷、增強請求、文檔變動等）。在UCM中這些變更均以活動出現。Rational ClearQuest為活動的跟蹤和管理提供了可定制的工作流，這使得開發團隊可以更容易地：· 將活動分配

13、給某個具體的開發人員 · 標識同活動相關的優先級、當前狀態和其他信息（如負責人、估計工期、影響程度等） · 自動產生查詢、報告和圖表 根據開發團隊或開發過程需求可以靈活地調整ClearQuest工作流引擎：如果開發團隊需要快速部署，那么也可以不進行定制，直接使用ClearQuest預定義的變更過程、表單和相關規則（圖2）；當開發團隊需要在預定義的過程上進行定制時，可以使用ClearQuest對他們的變更過程的各個方面-包括缺陷和變更請求的狀態轉移生命周期，數據庫字段，用戶界面（表單）布局，報告，圖表和查詢等進行定制。貫穿整個開發過程用于管理和跟蹤缺陷和其他變更的一個高效工作

14、流對于滿足當今高質量標準及緊迫的產品工期的需要是非常重要的。UCM提升了這些變更的抽象層次以便可以從活動的角度來觀察變更，然后Rational ClearQuest工作流引擎將活動同相關的開發工件連接在一起。圖2：Rational ClearQuest提供了一個現成的過程框架用于缺陷和變更跟蹤工作流工件管理 Rational ClearCase提供了一個軟件工件管理（SAM）框架，開發團隊可以使用這一框架來管理貫穿項目生命周期的所有工件。UCM將Rational ClearCase基礎框架同Rational ClearQuest中的活動管理結合在一起，從而提供了對工件和活動的集成管理。Rati

15、onal ClearCase提供了： · 安全的工件存儲和版本化 · 并行開發基礎框架-無限分支能力和強大的合并功能 · 自動代碼共享 · 用于選擇正確工件版本的工作空間管理 · 完全的可延展性-從小型本地項目工作組到大型全球分布式開發團隊 另外，Rational ClearCase提供了靈活的SCM的基礎框架，通過使用靈活的元數據，如標簽、分支、屬性、觸發器（trigger）和超級鏈接（hyperlinks）等，開發團隊可以定制他們自己的SCM過程。由此可見，不同開發團隊和項目可以通過Rational ClearCase使用不同的策略，開發團

16、隊可以從這種靈活性中受益。而UCM是基于一個經過驗證的、成功的開發過程，因此UCM為希望快速啟動高效SCM的開發團隊也可以直接使用這一過程來自動實現項目策略。UCM具體在以下六個方面提供了開發過程。UCM：六個過程領域 UCM在六個具體領域提供了所定義的過程：· 開發人員在共享及公共代碼工件上的隔離和協作； · 將一起開發、集成和發布的相關工件組按構件（component）進行組織； · 在項目里程碑創建構件基線（baseline）并根據所建立的質量標準來提升基線； · 將變更組織為變更集（change set）； · 將活動管理和工件管理集成

17、在一起； · 按項目來組織軟件開發并支持多項目之間的代碼共享； 開發人員的隔離和協作 開發人員需要相互隔離的工作環境以隔離彼此的工作，避免其他組成員的變更潛在地影響其工作的穩定性。Rational ClearCase提供了兩種方式來訪問工件的正確版本并在私有工作空間中在這些工件上進行工作。這兩種方式是靜態視圖和獨特的基于MVFS的動態視圖，它們可以據本地或網絡使用而分別進行實施。靜態視圖為開發人員提供了在斷開網絡連接的情況下進行工作的靈活性，另外開發人員也可以容易地將他們的工作同開發主線進行同步。動態視圖則通過一個獨特的虛擬文件系統（MVFS）來實現，它使得開發人員可以透明地訪問正確

18、工件的正確版本而無需將這些工件版本復制到本地硬盤驅動器上。另外由于動態視圖可以實時進行自動更新，因此緊密工作在同一分支上的開發團隊無需手動更新/復制文件即可立即看到其他人員所做的變動。不管使用何種方式，開發人員都可以并行工作在多個發布版本上。例如，一個開發人員工作在發布版本2上，同時他也可以修復發布版本1中的一個缺陷，而不用擔心自己的兩個活動涉及的代碼互相干擾或受其他開發人員的干擾。隔離不穩定的變更對于將錯誤最小化是非常關鍵的，但是將所有的變更集成到一個所有開發團隊成員均可訪問的公共工作區域卻是團隊開發環境下的一個基本要求。今天基于構件的軟件開發方法論的廣泛應用以及代碼變更頻率和幅度的增加都要

19、求開發團隊能經常和較早地將各個開發人員的工作進行集成。以便在盡早解決可能出現的問題。使用Rational ClearCase，開發團隊可以實現多種項目策略來同時進行工作的隔離和協作。通過強大的分支和合并功能Rational ClearCase可以支持大規模的并行開發。在ClearCase中可以根據不同用途來建立分支，如開發人員分支，新特性分支、缺陷修復分支、新需求分支等等，從而開發團隊可以根據需要建立適于自身情況的分支模型，靈活實現軟件配置管理流程。但對于希望能快速利用成熟的軟件開發流程的開發團隊而言，UCM則提供了一個直接可用的分支模型。實際上在UCM中，在分支基礎上對其在更高層次上進行了抽

20、象，從而形成了一個新概念-流（stream）。流表示一個私有或共享的工作空間，它定義了項目版本的一致配置并在UCM項目中的隔離和有效協作之間提供了一種平衡。熟悉ClearCase的讀者可以將流理解為開發人員分支，UCM中既有為每個開發人員配置的私有開發流，同時為負責集成所有交付工作的集成人員配置的公共集成流（圖3）。由于UCM緊密結合了活動管理，因此其他分支用途，如特性分支、缺陷修復分支等將作為活動出現并附加到相應的工作流中。 圖3：UCM提供了公共集成工作區和私有工作區私有開發流為開發人員提供了相互隔離的工作空間，該空間在最開始由滿足一定質量標準的公共工件進行初始化。開發人員使用這些私有工作

21、空間來進行工件的變更，構建和測試。當開發人員對他們的變更感到滿意時，他們可以將這些變更交付（deliver）到公共集成流上。為了使開發人員同其他人員的進度同步，開發人員也可以用來自項目公共集成流上最新的穩定基線來變基（rebase）他們的私有工作流。使用UCM，開發人員可以選擇什么時候進行交付和變基。實際上項目集成流充當了所有開發人員的所有變更的協調點。為了更好地協調所有開發人員的變更集成，UCM引入了基線（baseline）的概念作為對項目進度的度量。基線是一次構建（build）或配置的抽象表示，它實際上是構件的一個版本，而構件是相關工件的集合。項目開發團隊在開發過程期間不斷地創建和提升基線

22、。隨著不同開發人員交付變更給集成流，他們交付的變更將被逐一收集到項目基線中。隨著基線的構建、測試和批準，它們可以被逐步提升到不同的基線級別。基線提升級別具有兩方面的功能：第一，它使項目經理或項目管理人員可以建立軟件質量標準。由于當基線達到某種預定義的質量標準時就可以被標以某種基線級別，因此項目經理可以設置項目策略，標識出在哪一個基線級別（如"通過測試的"）開發人員可以執行變基操作。第二，基線提升級別就具體的開發人員應該如何同其所開發的工件進行交互提供了指導。例如，根據某條基線通過某些冒煙測試的時間可以幫助測試人員確定什么時候開始測試。構件基線 第二個UCM過程領域是將工件組

23、織為構件。在第二代配置管理中，大多以文件版本形式來管理所有的文件，當一個復雜項目中包含成千個文件上萬個版本時，整個項目的開發控制將變得相當復雜，因此對眾多的文件進行合理分類以呈現系統的設計要素可以大大簡化項目開發控制。UCM通過將多個工件組織為構件（在UCM中構件指一個VOB的根目錄或VOB的某個第一層子目錄）從而擴展了軟件工件管理的版本控制能力，并且UCM還提供了用于自動化構件管理的工具和過程。即用基線對構件而不是構件中眾多的版本進行標識，然后用這一基線作為新的開發起點并更新開發人員的工作空間。構件基線是在ClearCase標簽（label）的基礎上結合活動管理所做的擴展，即您可以知道一個U

24、CM構件基線中包含了哪些開發活動，例如一條基線可能包含了三個開發活動，如BUG 101的修復、用戶登錄界面漢化以及新增打印特性的支持。對于包含多個構件的復雜系統，UCM提供了基于多個構件的組合基線，即多個構件之間可以建立依賴關系，一旦底層構件的基線發生變化，例如生成一條新基線，其上層構件相應地也自動建立起一條基線，該基線自動包含底層構件基線。例如，一個較為復雜的MIS系統包含"數據庫訪問"，"業務邏輯處理"和"前端圖形界面"三個構件，其中"前端圖形界面"構件依賴于"業務邏輯處理"構件，而&quo

25、t;業務邏輯處理"構件依賴于"數據庫訪問"構件。這樣當"數據庫訪問"構件發生了變化并新建了一條新基線（如DB_BASELINE_Dec24）后，在"業務邏輯處理"構件和"前端圖形界面"構件各自動建立了一條新基線（如BUSINESS_BASELINE_Dec24和GUI_BASELINE_Dec24）。這樣上層構件的最新基線可以自動跟蹤底層構件的最新基線。構件管理的自動化對于高效無誤地開發可能包含數千個源代碼工件（還有其他相關的工件，如web內容，設計模型，需求說明和測試腳本等）的復雜軟件系統而言意義重大。

26、構件基線提升 項目開發團隊的成員工作在一個UCM項目（project）中，項目經理通過配置軟件構件從而使項目成為由構件構成的體系結構。大多數組織將UCM管理的構件設計為可以反映出他們軟件體系結構的方式（圖4），即將所有相關工件按體系結構組織為有意義的子系統，進而放入不同的構件中。圖4：用UCM構件直接對軟件體系結構建模如上節所描述的，開發人員在交付變更到公共集成流時可以周期性地更新他們私有開發流中的構件。然后開發團隊可以根據開發過程的當前階段和質量級別對構件進行評級。項目策略確定了在開發人員變基之前構件基線必須達到的質量級別以及其他開發團隊成員（如測試人員）應該如何同構件基線交互。在稍后會對項

27、目以及項目策略做更多描述。 UCM提供了五種預定義的基線級別，它們包括被拒絕（rejected），初始（initial），通過構建（built），通過測試（tested）和已發布（released）。另外，UCM允許開發團隊用他們自己的命名規范和提升策略對這些預定義基線級別進行定制。 變更集 第四個UCM過程領域是將獨立的工件變更組織為可作為整體進行交付、跟蹤和管理的變更集中。由于通常當開發人員工作在一個活動（例如缺陷修復）上時，他們很少只修改一個文件，因此用變更集可以表示用以完成某個具體活動的工件的所有變更，例如為修改一個編號為63的缺陷變動了50個目錄/文件的120個版本，則缺陷63的變更

28、集為相關的120個文件/目錄版本。當開發人員同時工作在多個變更請求上的需要使得這一過程更加復雜。例如，一個開發人員在進行一個新發布版本的開發，這時由于當前發布版本的一個錯誤要求他不得不中斷當前的開發工作轉而去修復這一缺陷，這樣該開發人員必須在同一工件上進行兩種不同的變更，一種是在未來發布版本中的增強功能變更，另一種是在前一發布版本中修復缺陷的變更。通過將同一個開發活動相關的所有變更收集到一個變更集中，UCM簡化了管理多個工件變更或者多個工件版本的過程。UCM圍繞具體的開發活動來進行工作組織，同時UCM還確保已完成的活動包含所有必要工件上發生的所有變更。活動和工件管理 第五個UCM過程領域是通過

29、使用一個可將活動及其相關工件集鏈接起來的自動化工作流（圖5）將活動管理和工件管理集成起來。這給了開發團隊極大的靈 活性來為不同類型活動的管理指定不同的工作流。UCM提供了最常用活動類型的預定義工作流，包括缺陷修復和增強請求。圖5：UCM工作流概覽開發團隊還可以使用ClearQuest Designer這一模塊來對這些預定義過程進行定制，項目經理或者項目管理人員可以用它來創建所有需要的活動類型，包括缺陷修復，增強功能請求，文檔變動以及Web網站變動等。使用ClearQuest Designer的圖形用戶界面，項目經理也可以定義字段，表單以及每個記錄類型的狀態轉移。為了方便開發人員更容易地標識活動

30、和項目代碼庫中工件間的關系，UCM自動將活動和其相關的變更集鏈接起來（圖6）。當在一個UCM項目中工作時，開發人員所交付的是活動（見開發人員隔離和協作一節）而不是文件形式的工件。類似的，當開發人員變基時，他們根據新構件基線提供的活動（而不是文件形式的工件）來重審將要在他們的私有開發流中接收的變更內容。這樣，開發人員不僅可以看到所有相關工件完整的版本歷史，而且可以看到實現每個變更的所有活動。這給了開發團隊一個項目是如何從一個階段演進到下一個階段演進的全面視圖，當需要標識出一個工件版本的變更是如何影響另一個版本時，這一優點所帶來的價值是無法估計的。使用UCM一致、可重復的用于活動管理的過程，通過活

31、動管理和工件管理的集成可以幫助開發團隊減少錯誤，開發人員還可以避免許多通常需要手工作業的單調工作，從而更有效率地完成開發任務。圖6：UCM將活動和相關的工件鏈接起來項目和項目策略 UCM中的項目可以和實際軟件開發中的各種項目對應，每個UCM項目包含一個集成工作流和若干個私有開發流，項目可由一組構件構成。這里需要強調的是一個構件可以被多個項目共享，進而項目A中的開發人員可以對一個構件進行修改，創建新的構件基線；而項目B的開發人員可以參照同一構件以及該構件在項目A中生成的基線，但不能對該構件進行任何改動。因而UCM項目從代碼級提供了軟件共享及重用的良好基礎。例如某系統集成公司的湖北分公司剛剛結束了

32、為某銀行開發的客服系統1.0的開發（我們可以將最終交付的版本稱之為XBANK_CRM_HuBei_1.0），與此同時該系統集成公司的北京分公司正準備為另一家銀行進行類似系統的開發。另外XBANK_CRM_HuBei_1.0在推廣過程中出現了一些問題，亟待解決。還有該客服系統2.0版XBANK_CRM_HuBei_2.0的需求分析準備在下月開始。此時如果利用UCM的多項目機制則可以為在北京的開發團隊建立一個新項目CRM_Beijing_1.0，但該項目并不是從零開始的，它可以從XBANK_CRM_HuBei_1.0開始，有選擇地借鑒XBANK_CRM_HuBei_1.0中可共享的部分。同時原有的

33、XBANK_CRM_HuBei_1.0的開發人員可以繼續進行2.0版的研制工作。而為了解決XBANK_CRM_HuBei_1.0中在推廣中出現的問題又可以新建一個XBANK_CRM_HuBei_1.0版的維護項目XBANK_CRM_HuBei_1.0_BUGFIX，部分原有開發人員既可以加入該項目進行原有1.0版的錯誤修復，又可以互不干擾地在原有項目中進行2.0版的需求分析。 UCM在項目上另一個突出特點是不同項目中的開發流之間可以進行跨項目的工作交付。即一個項目可以將一條構件基線中包含的工件交付給另一個項目，也可以將一個開發流上的活動變更集交付給另一個項目。緊接上例，假設過了三個月后項目XB

34、ANK_CRM_HuBei_1.0_BUGFIX修復了8個缺陷，而項目CRM_Beijing_1.0也根據北京用戶的特點實現了3個不同的新特性，這時如果需要可以在恰當時機將這兩個項目中的成果有選擇地交付給正在湖北進行的客服2.0版的開發，從而使得2.0版不僅修復了前一版本中的錯誤，而且具備了3個新特性。可以看出項目從一個更高層次上支持了傳統意義上基于分支的并行開發，這對于軟件開發組織從面向項目到面向產品的轉變，合理利用軟件開發人力資源，改善軟件產品體系結構從而支持更為復雜的軟件開發具有重大意義。由于同一代碼構件上多項目開發的引入，相應地UCM加入了多種項目策略來進行支持，用戶可以根據需要靈活定

35、義項目策略。例如上面提到的基線級別，可以定義只有基線級別提升到"Tested"才能作為其他開發工作流的推薦基線。另外，對于多項目間的代碼交付和共享，還可以定義是否允許接受其他項目的變更等。除了項目一級的策略以外，在工作流一級UCM也有類似的訪問策略，如某個工作流是否允許接受來自本項目或其他項目的工作流上的變更，是否允許向本項目或其他項目的工作流交付變更等等。開發團隊采用 成功的軟件配置管理需要同時重視人的活動和得到整個開發團隊的全體接受。如果開發團隊成員不能或不采用SCM方法論的話，SCM實現將會失敗。Rational軟件多年來從成功的軟件開發團隊和自身的軟件開發中吸取最佳

36、實踐經驗，將UCM作為一個可為開發團隊采用的優化過程來進行設計。UCM的功能已全部嵌入到Rational統一開發過程管理（Rational Unified Process，RUP）中，RUP是在軟件開發的各個生命周期應用最佳軟件開發經驗的一個實用框架。軟件開發團隊通過直接訪問RUP并通過Rational ClearCase，Rational ClearQuest和Rational Suite的工具專家可以得到關于UCM過程及其詳細描述。UCM通過使開發人員可以完成下面的工作而簡化了他們的工作：· 快速準確地訪問正確工件的正確版本 · 在他們的工作空間中相互隔離地進行各自的工

37、作，但可以選擇什么時候交付自己的工作及接收其他人員的變更 · 使用項目策略來標識什么時候質量達到了可以接受的級別從而可以在自己的私有工作空間中接收其他人員的變更 · 從他們自己的桌面透明地訪問SCM工具。使用可同他們最常使用的工具（如Visual C+）進行集成的工具來進行他們的工作-在開發活動上沒有附加不適當約束或增加工作時間 · 自動而透明地將變更集同活動進行集成 · 自動進行活動的跟蹤、管理和報告。 另外，UCM還減輕了項目經理的負擔，從而項目經理可以· 通過一個預定義的生命周期工作流在任何時間標識一個具體活動的狀態 · 用統一

38、的報告來監控最新的項目狀態 · 將精力集中在高優先級或緊急的事件（活動）上 · 確定工作負載并平衡任務分配 貫穿生命周期的工件到現在為止，本文主要集中在源代碼和其相關工件上，如對象文件和頭文件等。但是使用UCM時貫穿生命周期的變更也可以由非開發人員進行管理，這樣就最佳實現了統一變更管理的全部好處。這些非開發人員包括分析人員，設計人員以及測試人員（圖7）。相應的工件包括他們在相關領域產生的工件，例如分析人員所創建的需求文檔和用例（use cases），設計人員所建立的設計模型和用例，測試人員建立的測試腳本，測試數據和測試結果。為了高效地通信和協作工作，開發團隊成員需要有效地共

39、享這些工件。Rational Suite包含有一個集成平臺，通過這一公共平臺可以訪問貫穿多個領域的所有類型的開發工件。作為Rational Suite的一部分，UCM提供了一個用于管理貫穿軟件開發生命周期的信息共享的過程層。現在每個Rational Suite產品套件中均包含了這兩個產品，這樣每個Rational Suite產品都包含了對UCM過程的支持。非軟件開發人員（如分析人員、設計人員以及測試人員）可以應用UCM原理象控制代碼變更一樣來控制他們生產的工件（如需求文檔，用例，設計模型，測試腳本及測試數據）。Rational ClearQuest工作流引擎強化了活動管理，另外一致的工作流使得

40、所有的團隊成員都可以容易地標識優先級，而ClearQuest提供的工作列表（to do list）特性可以使每個人均可從他們的桌面透明訪問待進行的工作（活動）列表，從而容易地標識出他們下一步需要進行的工作。同樣構件基線是新工作（分析、設計、開發及測試）的基礎并指導團隊成員什么時候更新他們工作空間。圖7：開發團隊成員在生命周期的不同階段產生不同的工件來自分析的工件 分析人員扮演著定義項目范圍的重要角色，分析人員需要確定解決方案是什么以及系統邊界。在分析期間這些專業人員創建了多種不同的工件來幫助解釋說明所建議的解決方案，這些工件包括需求文檔，用例以及可視化模型。開發團隊在整個開發過程中不斷使用這些

41、工件來管理項目變更是必不可少的。成功的項目依賴于正確的需求管理。高效的需求管理包括減少開發的進度風險和系統的不穩定性，以及跟蹤需求變更。項目管理，風險評估以及相關評估標準的產生都依賴于需求管理和需求的可追溯性-即開發團隊以一種規范過程接受變更并審查需求變更的歷史。Rational RequisitePro是Rational Suite 開發團隊統一平臺（Team Unifying Platform）中用于需求管理的工具。軟件開發團隊可以使用RequisitePro來創建、管理和跟蹤分析工件-例如需求屬性、需求說明和管理計劃，以及用例模型，術語表以及涉眾（stakeholder）請求。UCM項目

42、以同管理代碼相似的方式管理需求，此外UCM還將這些需求工件包含在構件基線中。這樣分析人員不僅知道哪些活動構成了一條構件基線中的工件，還知道哪些需求指導著這些工件的開發。來自設計的工件 設計人員對系統基礎結構建模并使用用例和設計模型進一步細化系統定義。通過設計工件對系統進行抽象，可以減少整個系統的復雜性。在實際開發過程中經常會出現這樣一種情況：一些開發團隊不能繼續使用一些設計模型，因為正式的編碼工作已經開始。這是一個錯誤，因為這些設計模型在幫助規劃整個工作，另外對于協助新的組成員快速上手，度量正在進行中的變更請求的影響，以及評估整個項目風險都非常有價值。由Rational Rose提供的雙向工程功能可以幫助開發團隊保持當前編碼進度和這些模型之間的同步（圖8），而UCM確保模型與代碼是最新的。在UCM項目中，構件基線包含模型工件和代碼工件。Rose Model Integrator和ClearCase 比較/合并特性的緊密集成使得開發團隊可以盡可能方便地在設計模型的同時進行編碼。這時UCM中的變更集（參