Java軟件工程與項目案例教程(八)課件

Java軟件工程與項目案例教程

（八）

Java軟件工程與項目案例教程

（八）

主要內(nèi)容1、軟件配置管理工具——CVS2、統(tǒng)一變更管理主要內(nèi)容1、軟件配置管理工具——CVS第8章軟件配置和變更管理8.1軟件配置管理概述配置管理作為軟件開發(fā)活動中的一項重要工作，其工作范圍主要包括以下4個方面：（1）標(biāo)識軟件工作產(chǎn)品（又稱標(biāo)識配置項）；（2）進行配置控制；（3）記錄配置狀態(tài)；（4）執(zhí)行配置審計。配置控制是配置管理的核心，它主要包括存取控制、版本控制、變更控制和產(chǎn)品發(fā)布控制等各個方面。8.2軟件配置管理工具——CVS1．代碼集中的配置2．保存修改記錄3．調(diào)整代碼8.3軟件變更管理概述今天的軟件開發(fā)團隊面臨著巨大的挑戰(zhàn)：一方面，市場要求以更快的速度來開發(fā)高質(zhì)量的軟件應(yīng)用；另一方面，軟件需求隨著開發(fā)環(huán)境和結(jié)構(gòu)的日趨多樣而變得更加復(fù)雜；再加上分布式開發(fā)、高性能要求、多平臺、更短和連續(xù)的發(fā)布周期——這些都加重了軟件開發(fā)所承受的壓力。由于軟件開發(fā)不同于傳統(tǒng)意義的工程技術(shù)，市場變化及技術(shù)上的高速更新都注定了軟件變更是非常頻繁并且是不可避免的，可以說變更是軟第8章軟件配置和變更管理8.1軟件配置管理概述8.3軟件變更管理概述件開發(fā)的基石。一方面，在軟件開發(fā)環(huán)境下的內(nèi)部活動以新特性、新功能增強及缺陷修復(fù)等方式不停地制造著變更；另一方面，外部因素例如新操作環(huán)境、新工具的集成、工程技術(shù)和市場條件的改善等以另一種力量驅(qū)動著變更。8.3軟件變更管理概述件開發(fā)的基石。一方面，在軟件開發(fā)環(huán)境8.4統(tǒng)一變更管理8.4.1統(tǒng)一變更管理概述使用UCM可以獲得以下好處：基于活動的配置管理過程：開發(fā)活動可以自動地與其變更集（封裝了所有用于實現(xiàn)該活動的項目工件）相關(guān)聯(lián)，這樣避免了管理人員手動跟蹤所有文件變更；預(yù)定義的工作流程：可以直接采用預(yù)定義的UCM工作流程，快速提升開發(fā)組織的軟件配置管理水平；項目的跟蹤和組織：項目管理人員可以實時掌握項目的最新動態(tài)，合理分配資源和調(diào)度開發(fā)活動；協(xié)作自動化：通過將許多耗時較多的任務(wù)自動化處理，UCM使得開發(fā)人員更多地將注意力集中在更高層次的開發(fā)活動上；輕松管理基線：UCM將開發(fā)活動嵌入到各個基線中，這樣測試人員確切地知道他們將測試什么，而開發(fā)人員則確切地知道其他開發(fā)人員做了什么；支持跨功能開發(fā)組：UCM已成為RationalSuite產(chǎn)品中的核心部分，從而可以將從需求到測試各個階段的工件（例如需求文檔、設(shè)計模型、應(yīng)用源代碼、測試用例及XML內(nèi)容等）在UCM框架下進行統(tǒng)一集成，簡化了貫穿整個軟件開發(fā)周期的變更過程；基于同一代碼構(gòu)件可以進行多項目開發(fā)，簡化了多項目開發(fā)管理，增大了代碼共享，節(jié)省了開發(fā)資源。8.4統(tǒng)一變更管理8.4.1統(tǒng)一變更管理概述8.4統(tǒng)一變更管理8.4.2統(tǒng)一變更管理原理1．活動和工件管理（1）活動管理UCM中的活動管理是由RationalClearQuest提供的，RationalClearQuest是一個高度靈活和可擴展的缺陷及變更跟蹤系統(tǒng)，它可以捕獲和跟蹤所有類型的變更請求（例如產(chǎn)品缺陷、增強請求、文檔變動等）。在UCM中這些變更均以活動出現(xiàn)。RationalClearQuest為活動的跟蹤和管理提供了可定制的工作流，這使得開發(fā)團隊可以更容易地：將活動分配給某個具體的開發(fā)人員；標(biāo)識與活動相關(guān)的優(yōu)先級、當(dāng)前狀態(tài)和其他信息（如負責(zé)人、估計工期、影響程度等）；自動產(chǎn)生查詢、報告和圖表。根據(jù)開發(fā)團隊或開發(fā)過程需求可以靈活地調(diào)整ClearQuest工作流引擎：如果開發(fā)團隊需要快速部署，那么也可以不進行定制，直接使用ClearQuest預(yù)定義的變更過程、表單和相關(guān)規(guī)則；當(dāng)開發(fā)團隊需要在預(yù)定義的過程上進行定制時，可以使用ClearQuest對他們的變更過程的各個方面——包括缺陷和變更請求的狀態(tài)轉(zhuǎn)移生命周期、數(shù)據(jù)庫字段、用戶界面（表單）布局、報告、圖表和查詢等進行定制。8.4統(tǒng)一變更管理8.4.2統(tǒng)一變更管理原理8.4統(tǒng)一變更管理貫穿整個開發(fā)過程用于管理和跟蹤缺陷及其他變更的一個高效工作流對于滿足當(dāng)今高質(zhì)量標(biāo)準(zhǔn)及緊迫的產(chǎn)品工期的需要是非常重要的。UCM提升了這些變更的抽象層次，以便可以從活動的角度來觀察變更，然后RationalClearQuest工作流引擎將活動與相關(guān)的開發(fā)工件連接在一起。（2）工件管理RationalClearCase提供了一個軟件工件管理（SAM）框架，開發(fā)團隊可以使用這一框架來管理貫穿項目生命周期的所有工件。UCM將RationalClearCase基礎(chǔ)框架與RationalClearQuest中的活動管理結(jié)合在一起，從而提供了對工件和活動的集成管理。RationalClearCase提供了：安全的工件存儲和版本化；并行開發(fā)基礎(chǔ)框架——無限分支能力和強大的合并功能；自動代碼共享；用于選擇正確工件版本的工作空間管理；完全的可延展性——從小型本地項目工作組到大型全球分布式開發(fā)團隊。8.4統(tǒng)一變更管理貫穿整個開發(fā)過程用于管理和跟蹤缺陷及其他8.4統(tǒng)一變更管理2．UCM：6個過程領(lǐng)域UCM在6個具體領(lǐng)域提供了所定義的過程：開發(fā)人員在共享及公共代碼工件上的隔離和協(xié)作；將一起開發(fā)、集成和發(fā)布的相關(guān)工件組按構(gòu)件（component）進行組織；在項目里程碑創(chuàng)建構(gòu)件基線（baseline）并根據(jù)所建立的質(zhì)量標(biāo)準(zhǔn)來提升基線；將變更組織為變更集（changeset）；將活動管理和工件管理集成在一起；按項目來組織軟件開發(fā)并支持多項目之間的代碼共享。（1）開發(fā)人員的隔離和協(xié)作8.4統(tǒng)一變更管理2．UCM：6個過程領(lǐng)域8.4統(tǒng)一變更管理IntegrationStreamDevelopmentStream2DevelopmentStream1圖8-2UCM提供了公共集成工作區(qū)和私有工作區(qū)8.4統(tǒng)一變更管理IntegrationStreamD8.4統(tǒng)一變更管理

私有開發(fā)流為開發(fā)人員提供了相互隔離的工作空間，該空間在最開始由滿足一定質(zhì)量標(biāo)準(zhǔn)的公共工件進行初始化。開發(fā)人員使用這些私有工作空間來進行工件的變更、構(gòu)建和測試。當(dāng)開發(fā)人員對他們的變更感到滿意時，他們可以將這些變更交付（deliver）到公共集成流上。為了使開發(fā)人員與其他人員的進度同步，開發(fā)人員也可以用來自項目公共集成流上最新的穩(wěn)定基線來變基（rebase）他們的私有工作流。使用UCM，開發(fā)人員可以選擇什么時候進行交付和變基。實際上，項目集成流充當(dāng)了所有開發(fā)人員的所有變更的協(xié)調(diào)點。為了更好地協(xié)調(diào)所有開發(fā)人員的變更集成，UCM引入了基線（baseline）的概念作為對項目進度的度量?；€是一次構(gòu)建（build）或配置的抽象表示，它實際上是構(gòu)件的一個版本，而構(gòu)件是相關(guān)工件的集合。項目開發(fā)團隊在開發(fā)過程期間不斷地創(chuàng)建和提升基線。隨著不同開發(fā)人員交付變更給集成流，他們交付的變更將被逐一收集到項目基線中。隨著基線的構(gòu)建、測試和批準(zhǔn)，它們可以被逐步提升到不同的基線級別。8.4統(tǒng)一變更管理私有開發(fā)流為開發(fā)人員提供了相互隔離8.4統(tǒng)一變更管理

基線提升級別具有兩方面的功能：第一，它使項目經(jīng)理或項目管理人員可以建立軟件質(zhì)量標(biāo)準(zhǔn)。由于當(dāng)基線達到某種預(yù)定義的質(zhì)量標(biāo)準(zhǔn)時就可以被標(biāo)以某種基線級別，因此項目經(jīng)理可以設(shè)置項目策略，標(biāo)識出在哪一個基線級別（如“通過測試的”）開發(fā)人員可以執(zhí)行變基操作。第二，基線提升級別就具體的開發(fā)人員應(yīng)該如何與其所開發(fā)的工件進行交互提供了指導(dǎo)。例如，根據(jù)某條基線通過某些冒煙測試的時間可以幫助測試人員確定什么時候開始測試。（2）構(gòu)件基線第二個UCM過程領(lǐng)域是將工件組織為構(gòu)件。在第二代配置管理中，大多以文件版本形式來管理所有的文件，當(dāng)一個復(fù)雜項目中包含成千個文件上萬個版本時，整個項目的開發(fā)控制將變得相當(dāng)復(fù)雜，因此對眾多的文件進行合理分類以呈現(xiàn)系統(tǒng)的設(shè)計要素可以大大簡化項目開發(fā)控制。UCM通過將多個工件組織為構(gòu)件（在UCM中構(gòu)件指一個VOB的根目錄或VOB的某個第一層子目錄），從而擴展了軟件工件管理的版本控制能力，并且UCM還提供了用于自動化構(gòu)件管理的工具和過程。即用基線對構(gòu)件而不是構(gòu)件中眾多的版本進行標(biāo)識，然后用這一基線作為新的開發(fā)起點并更新開發(fā)人員的工作空間。8.4統(tǒng)一變更管理基線提升級別具有兩方面的功能：第一8.4統(tǒng)一變更管理構(gòu)件基線是在ClearCase標(biāo)簽（label）的基礎(chǔ)上結(jié)合活動管理所做的擴展，即您可以知道一個UCM構(gòu)件基線中包含了哪些開發(fā)活動。例如，一條基線可能包含了3個開發(fā)活動，如BUG101的修復(fù)、用戶登錄界面漢化及新增打印特性的支持。對于包含多個構(gòu)件的復(fù)雜系統(tǒng)，UCM提供了基于多個構(gòu)件的組合基線，即多個構(gòu)件之間可以建立依賴關(guān)系，一旦底層構(gòu)件的基線發(fā)生變化，例如生成一條新基線，其上層構(gòu)件相應(yīng)地也自動建立起一條基線，該基線自動包含底層構(gòu)件基線。例如，一個較為復(fù)雜的MIS系統(tǒng)包含“數(shù)據(jù)庫訪問”、“業(yè)務(wù)邏輯處理”和“前端圖形界面”3個構(gòu)件，其中“前端圖形界面”構(gòu)件依賴于“業(yè)務(wù)邏輯處理”構(gòu)件，而“業(yè)務(wù)邏輯處理”構(gòu)件依賴于“數(shù)據(jù)庫訪問”構(gòu)件。這樣當(dāng)“數(shù)據(jù)庫訪問”構(gòu)件發(fā)生了變化并新建了一條新基線（如DB_BASELINE_Dec24）后，在“業(yè)務(wù)邏輯處理”構(gòu)件和“前端圖形界面”構(gòu)件中自動建立了一條新基線（如BUSINESS_BASELINE_Dec24和GUI_BASELINE_Dec24）。這樣上層構(gòu)件的最新基線可以自動跟蹤底層構(gòu)件的最新基線。構(gòu)件管理的自動化對于高效無誤地開發(fā)可能包含數(shù)千個源代碼工件（還有其他相關(guān)的工件，如Web內(nèi)容、設(shè)計模型、需求說明和測試腳本等）的復(fù)雜軟件系統(tǒng)而言意義重大。8.4統(tǒng)一變更管理構(gòu)件基線是在ClearCase標(biāo)簽（la8.4統(tǒng)一變更管理（3）構(gòu)件基線提升項目開發(fā)團隊的成員工作在一個UCM項目（project）中，項目經(jīng)理通過配置軟件構(gòu)件從而使項目成為由構(gòu)件構(gòu)成的體系結(jié)構(gòu)。大多數(shù)組織將UCM管理的構(gòu)件設(shè)計為可以反映出他們軟件體系結(jié)構(gòu)的方式（見圖8-3），即將所有相關(guān)工件按體系結(jié)構(gòu)組織為有意義的子系統(tǒng)，進而放入不同的構(gòu)件中。SystemUserInterfaceAdministration圖8-3用UCM構(gòu)件直接對軟件體系結(jié)構(gòu)建模8.4統(tǒng)一變更管理（3）構(gòu)件基線提升SystemUser8.4統(tǒng)一變更管理如上節(jié)所描述的，開發(fā)人員在交付變更到公共集成流時可以周期性地更新他們私有開發(fā)流中的構(gòu)件，然后開發(fā)團隊可以根據(jù)開發(fā)過程的當(dāng)前階段和質(zhì)量級別對構(gòu)件進行評級。項目策略確定了在開發(fā)人員變基之前構(gòu)件基線必須達到的質(zhì)量級別，以及其他開發(fā)團隊成員（如測試人員）應(yīng)該如何與構(gòu)件基線交互。在稍后會對項目及項目策略做更多的描述。UCM提供了5種預(yù)定義的基線級別，包括被拒絕（rejected）、初始（initial）、通過構(gòu)建（built）通過測試（tested）和已發(fā)布（released）。另外，UCM允許開發(fā)團隊用他們自己的命名規(guī)范和提升策略對這些預(yù)定義基線級別進行定制。8.4統(tǒng)一變更管理如上節(jié)所描述的，開發(fā)人員在交付變更到公共8.4統(tǒng)一變更管理（4）變更集第4個UCM過程領(lǐng)域是將獨立的工件變更組織為可作為整體進行交付、跟蹤和管理的變更集中。由于通常當(dāng)開發(fā)人員工作在一個活動（例如缺陷修復(fù)）上時，他們很少只修改一個文件，因此用變更集可以表示用以完成某個具體活動的工件的所有變更。例如，為修改一個編號為36的缺陷變動了30個目錄/文件的100個版本，則缺陷36的變更集為相關(guān)的100個文件/目錄版本。開發(fā)人員同時工作在多個變更請求上的需要使得這一過程更加復(fù)雜。例如，一個開發(fā)人員在進行一個新發(fā)布版本的開發(fā)，這時由于當(dāng)前發(fā)布版本的一個錯誤要求他不得不中斷當(dāng)前的開發(fā)工作轉(zhuǎn)而去修復(fù)這一缺陷，這樣該開發(fā)人員必須在同一工件上進行兩種不同的變更：一種是在未來發(fā)布版本中的增強功能變更；另一種是在前一發(fā)布版本中修復(fù)缺陷的變更。通過將同一個開發(fā)活動相關(guān)的所有變更收集到一個變更集中，UCM簡化了管理多個工件變更或者多個工件版本的過程。UCM圍繞具體的開發(fā)活動來進行工作組織，同時UCM還確保已完成的活動包含所有必要工件上發(fā)生的所有變更。8.4統(tǒng)一變更管理（4）變更集8.4統(tǒng)一變更管理（5）活動和工件管理第5個UCM過程領(lǐng)域是通過使用一個可將活動及其相關(guān)工件集鏈接起來的自動化工作流（見圖8-4），將活動管理和工件管理集成起來。這給了開發(fā)團隊極大的靈活性來為不同類型活動的管理指定不同的工作流。UCM提供了最常用活動類型的預(yù)定義工作流，包括缺陷修復(fù)和增強請求。8.4統(tǒng)一變更管理（5）活動和工件管理8.4統(tǒng)一變更管理圖8-4UCM工作流概覽8.4統(tǒng)一變更管理圖8-4UCM工作流概覽8.4統(tǒng)一變更管理開發(fā)團隊還可以使用ClearQuestDesigner這一模塊來對這些預(yù)定義過程進行定制，項目經(jīng)理或者項目管理人員可以用它來創(chuàng)建所有需要的活動類型，包括缺陷修復(fù)、增強功能請求、文檔變動及Web網(wǎng)站變動等。使用ClearQuestDesigner的圖形用戶界面，項目經(jīng)理也可以定義字段、表單及每個記錄類型的狀態(tài)轉(zhuǎn)移。為了方便開發(fā)人員更容易地標(biāo)識活動和項目代碼庫中工件間的關(guān)系，UCM自動將活動和其相關(guān)的變更集鏈接起來（見圖8-5）。當(dāng)在一個UCM項目中工作時，開發(fā)人員所交付的是活動而不是文件形式的工件。類似的，當(dāng)開發(fā)人員變基時，他們根據(jù)新構(gòu)件基線提供的活動（而不是文件形式的工件）來重審將要在他們的私有開發(fā)流中接收的變更內(nèi)容。這樣，開發(fā)人員不僅可以看到所有相關(guān)工件完整的版本歷史，而且可以看到實現(xiàn)每個變更的所有活動。這給了開發(fā)團隊一個項目是如何從一個階段演進到下一個階段的全面視圖，當(dāng)需要標(biāo)識出一個工件版本的變更是如何影響另一個版本時，這一優(yōu)點所帶來的價值是無法估計的。使用UCM一致、可重復(fù)的用于活動管理的過程，通過活動管理和工件管理的集成可以幫助開發(fā)團隊減少錯誤，開發(fā)人員還可以避免許多通常需要手工作業(yè)的單調(diào)工作，從而更有效率地完成開發(fā)任務(wù)。8.4統(tǒng)一變更管理開發(fā)團隊還可以使用ClearQuest8.4統(tǒng)一變更管理圖8-5UCM將活動和相關(guān)的工件鏈接起來8.4統(tǒng)一變更管理圖8-5UCM將活動和相關(guān)的工件鏈接8.4統(tǒng)一變更管理（6）項目和項目策略UCM中的項目可以和實際軟件開發(fā)中的各種項目對應(yīng)，每個UCM項目包含一個集成工作流和若干個私有開發(fā)流，項目可由一組構(gòu)件構(gòu)成。這里需要強調(diào)的是一個構(gòu)件可以被多個項目共享，進而項目A中的開發(fā)人員可以對一個構(gòu)件進行修改，創(chuàng)建新的構(gòu)件基線；而項目B的開發(fā)人員可以參照同一構(gòu)件及該構(gòu)件在項目A中生成的基線，但不能對該構(gòu)件進行任何改動。因而UCM項目從代碼級提供了軟件共享及重用的良好基礎(chǔ)。UCM在項目上的另一個突出特點是不同項目中的開發(fā)流之間可以進行跨項目的工作交付。即一個項目可以將一條構(gòu)件基線中包含的工件交付給另一個項目，也可以將一個開發(fā)流上的活動變更集交付給另一個項目?？梢钥闯鲰椖繌囊粋€更高層次上支持了傳統(tǒng)意義上基于分支的并行開發(fā)，這對于軟件開發(fā)組織從面向項目到面向產(chǎn)品的轉(zhuǎn)變，合理利用軟件開發(fā)人力資源，改善軟件產(chǎn)品體系結(jié)構(gòu)，從而支持更為復(fù)雜的軟件開發(fā)具有重大意義。8.4統(tǒng)一變更管理（6）項目和項目策略8.4統(tǒng)一變更管理由于同一代碼構(gòu)件上多項目開發(fā)的引入，相應(yīng)的UCM加入了多種項目策略來進行支持，用戶可以根據(jù)需要靈活定義項目策略。例如對于基線級別，可以定義只有基線級別提升到“Tested”才能作為其他開發(fā)工作流的推薦基線。另外，對于多項目間的代碼交付和共享，還可以定義是否允許接受其他項目的變更等。除了項目一級的策略以外，在工作流一級UCM也有類似的訪問策略，如某個工作流是否允許接受來自本項目或其他項目的工作流上的變更，是否允許向本項目或其他項目的工作流交付變更等。3．貫穿生命周期的工件到現(xiàn)在為止，我們的討論主要集中在源代碼和其相關(guān)工件上，如對象文件和頭文件等。但是使用UCM時貫穿生命周期的變更也可以由非開發(fā)人員進行管理，這樣就最佳實現(xiàn)了統(tǒng)一變更管理的全部好處。這些非開發(fā)人員包括分析人員、設(shè)計人員及測試人員（見圖8-6）。相應(yīng)的工件包括他們在相關(guān)領(lǐng)域產(chǎn)生的工件，例如分析人員所創(chuàng)建的需求文檔和用例（UseCase）、設(shè)計人員所建立的設(shè)計模型和用例，以及測試人員所建立的測試腳本、測試數(shù)據(jù)和測試結(jié)果。8.4統(tǒng)一變更管理由于同一代碼構(gòu)件上多項目開發(fā)的引入，相應(yīng)8.4統(tǒng)一變更管理圖8-6開發(fā)團隊成員在生命周期的不同階段產(chǎn)生不同的工件8.4統(tǒng)一變更管理圖8-6開發(fā)團隊成員在生命周期的不同8.4統(tǒng)一變更管理為了高效地通信和協(xié)作工作，開發(fā)團隊成員需要有效地共享這些工件。RationalSuite包含有一個集成平臺，通過這一公共平臺可以訪問貫穿多個領(lǐng)域的所有類型的開發(fā)工件。作為RationalSuite的一部分，UCM提供了一個用于管理貫穿軟件開發(fā)生命周期的信息共享的過程層?，F(xiàn)在每個RationalSuite產(chǎn)品套件中均包含了這兩個產(chǎn)品，這樣每個RationalSuite產(chǎn)品都包含了對UCM過程的支持。非軟件開發(fā)人員（如分析人員、設(shè)計人員及測試人員）可以應(yīng)用UCM原理像控制代碼變更一樣來控制他們生產(chǎn)的工件（如需求文檔、用例、設(shè)計模型、測試腳本及測試數(shù)據(jù)）。RationalClearQuest工作流引擎強化了活動管理，另外一致的工作流使得所有的團隊成員都可以容易地標(biāo)識優(yōu)先級，而ClearQuest提供的工作列表（todolist）特性可以使每個人均可從他們的桌面透明訪問待進行的工作（活動）列表，從而容易地標(biāo)識出他們下一步需要進行的工作。同樣構(gòu)件基線是新工作（分析、設(shè)計、開發(fā)及測試）的基礎(chǔ)，并指導(dǎo)團隊成員什么時候更新他們的工作空間。（1）來自分析的工件分析人員扮演著定義項目范圍的重要角色，分析人員需要確定解決方案是什么及系統(tǒng)邊界。在分析期間這些專業(yè)人員創(chuàng)建了多種不同的工件來幫助解釋說明所建議的解決方案，這些工件包括需求文檔、用例及可視化模型。開發(fā)團隊在整個開發(fā)過程中不斷使用這些工件來管理項目變更是必不可少的。8.4統(tǒng)一變更管理為了高效地通信和協(xié)作工作，開發(fā)團隊成員需8.4統(tǒng)一變更管理成功的項目依賴于正確的需求管理。高效的需求管理包括減少開發(fā)的進度風(fēng)險和系統(tǒng)的不穩(wěn)定性，以及跟蹤需求變更。項目管理、風(fēng)險評估及相關(guān)評估標(biāo)準(zhǔn)的產(chǎn)生都依賴于需求管理和需求的可追溯性——即開發(fā)團隊以一種規(guī)范過程接受變更并審查需求變更的歷史。RationalRequisitePro是RationalSuite開發(fā)團隊統(tǒng)一平臺（TeamUnifyingPlatform）中用于需求管理的工具。軟件開發(fā)團隊可以使用RequisitePro來創(chuàng)建、管理和跟蹤分析工件，例如需求屬性、需求說明和管理計劃、用例模型、術(shù)語表及涉眾（stakeholder）請求。UCM項目以與管理代碼相似的方式管理需求，此外UCM還將這些需求工件包含在構(gòu)件基線中。這樣分析人員不僅知道哪些活動構(gòu)成了一條構(gòu)件基線中的工件，還知道哪些需求指導(dǎo)著這些工件的開發(fā)。（2）來自設(shè)計的工件設(shè)計人員對系統(tǒng)基礎(chǔ)結(jié)構(gòu)建模并使用用例和設(shè)計模型進一步細化系統(tǒng)定義。通過設(shè)計工件對系統(tǒng)進行抽象，可以減少整個系統(tǒng)的復(fù)雜性。8.4統(tǒng)一變更管理成功的項目依賴于正確的需求管理。高效的需8.4統(tǒng)一變更管理在實際開發(fā)過程中經(jīng)常會出現(xiàn)這樣一種情況：一些開發(fā)團隊不能繼續(xù)使用一些設(shè)計模型，因為正式的編碼工作已經(jīng)開始。這是一個錯誤，因為這些設(shè)計模型在幫助規(guī)劃整個工作，另外對于協(xié)助新的組成員快速上手，度量正在進行中的變更請求的影響，以及評估整個項目風(fēng)險都非常有價值。由RationalRose提供的雙向工程功能可以幫助開發(fā)團隊保持當(dāng)前編碼進度和這些模型之間的同步（見圖8-7），而UCM確保模型與代碼是最新的。ModelsC圖8-7并行開發(fā)過程中模型和代碼之間的交互8.4統(tǒng)一變更管理在實際開發(fā)過程中經(jīng)常會出現(xiàn)這樣一種情況：8.4統(tǒng)一變更管理在UCM項目中，構(gòu)件基線包含模型工件和代碼工件。RoseModelIntegrator和ClearCase比較/合并特性的緊密集成，使得開發(fā)團隊可以盡可能方便地在設(shè)計模型的同時進行編碼。這時UCM中的變更集可以擴展到模型元素，這樣變更集便包含了代碼工件上的變更，以及模型工件上的變更。RationalRose支持UCM交付（deliver）和變基（rebase）操作（參見活動和工件管理部分），使得多個設(shè)計人員可以在Rose模型上同時工作，如同開發(fā)人員并發(fā)工作在代碼上一樣。（3）來自測試的工件傳統(tǒng)的開發(fā)方法將測試工作放到開發(fā)的末期，在編碼工作之后進行。成功的構(gòu)件開發(fā)團隊都體會到單元測試（UnitTest）對于項目成功是非常重要的，使用單元測試就是不將構(gòu)件的質(zhì)量保證放到集成階段，而是預(yù)先對單元、子系統(tǒng)和系統(tǒng)進行測試。所有這些并發(fā)測試產(chǎn)生了大量的測試工件，包括測試需求、測試腳本、測試數(shù)據(jù)和大量的測試結(jié)果。RationalSuiteTestStudio及RationalQualityArchitect為開發(fā)團隊提供了可持續(xù)地生產(chǎn)高質(zhì)量軟件工件所需的集成框架。借助UCM，開發(fā)團隊可以并發(fā)地管理他們的測試工件和相關(guān)的開發(fā)工件。今天，大多數(shù)開發(fā)團隊都意識到將這些測試工件和構(gòu)件基線集成到一起的好處。在UCM項目中，可以在一條構(gòu)件基線中包含所有的代碼工件，以及相關(guān)的測試需求、測試程序和測試數(shù)據(jù)。8.4統(tǒng)一變更管理在UCM項目中，構(gòu)件基線包含模型工件和代8.4統(tǒng)一變更管理這樣前面描述的變更集就可以擴展到測試用例、測試腳本和測試數(shù)據(jù)。集成的活動和工件管理將活動的整個范圍——從對代碼變更的測試校驗活動到由其活動描述的UCM變更集鏈接起來。（4）分析、設(shè)計、編碼和測試工件RationalSuite和UCM提供的優(yōu)點是無價的。構(gòu)件基線在一條基線中包容了所有的項目工件——從需求文檔到測試包——這對于任何需要進行維護和升級任務(wù)的開發(fā)團隊都是一個大優(yōu)點。借助UCM基線級別，使用RationalSuite跨功能的多個組可以更容易地：標(biāo)識所需的活動；確定什么時候變更；標(biāo)識需測試的活動；評估開發(fā)中的工件。另外，UCM基線級別幫助開發(fā)團隊識別什么時候開始跨功能的活動。例如，在編碼結(jié)束后，經(jīng)過一系列單元測試和冒煙測試（SmokeTest），一條基線達到了可以進行集成測試的質(zhì)量級別，這時可以提升該構(gòu)件基線，從而啟動集成測試活動。在UCM中，質(zhì)量監(jiān)控是依靠RationalClearQuest提供的快速報告功能來進一步進行加強的。通過這些報告功能，組成員可以生成清晰而簡明的項目狀態(tài)數(shù)據(jù)，以8.4統(tǒng)一變更管理這樣前面描述的變更集就可以擴展到測試用例8.4統(tǒng)一變更管理便快速探測問題、評估風(fēng)險并快速達成解決方案。另外，項目管理人員可以將工作圍繞高優(yōu)先級的活動展開，并且確保所有的發(fā)布版本都滿足預(yù)定義的質(zhì)量級別。8.4統(tǒng)一變更管理便快速探測問題、評估風(fēng)險并快速達成解決方8.5項目案例8.5.1學(xué)習(xí)目標(biāo)了解軟件配置管理的概述和原理。掌握軟件配置管理工具——CVS的使用。8.5.2案例描述本案例講述的是CVS服務(wù)器的安裝和配置和CVSEclipse客戶端的配置和使用。8.5.3案例要點CVS是是主流的開放源碼、網(wǎng)絡(luò)透明的配置管理系統(tǒng)。CVS的客戶機/服務(wù)器（Client/Server）存取方法使得開發(fā)者可以從任何Internet的接入點存取最新的代碼。本案例介紹了CVS服務(wù)器的安裝和配置以及CVSEclipse客戶端的配置和使用。8.5.4案例實施CVS服務(wù)器的安裝和配置

第一步就是去得到適合你的平臺的CVS軟件。安裝CVS通常就是將其從下載的壓縮包中解壓這么一件事。配置CVS可能要小心一些，它非常依賴于你使用的平臺和CVS代碼倉庫的存放地。CVS存放了大量的CVS文檔。8.5項目案例8.5.1學(xué)習(xí)目標(biāo)8.5項目案例首先我們要正確安裝并配置好CVS服務(wù)器，通常LinuxServer都自帶CVS服務(wù)。首先介紹CVS在Linux下的配置。（1）我們用的Linux服務(wù)器是RedHat9.0的。（2）首先以root用戶登錄，確定服務(wù)器是否安裝了CVS。使用命令rpm-qa|grepcvs，如果系統(tǒng)安裝了CVS，那么就會出現(xiàn)類似于cvs-1.11.2-10的提示證明你的系統(tǒng)已經(jīng)安裝了。如果沒有，那么你需要到下載或者在光盤上找到。下面我們來具體安裝和配置。1．選定CVS資源庫CVS資源庫是CVS服務(wù)器保存各種軟件資源的地方，項目中所用的軟件資源和不同版本都存放在CVS資源庫中。對于其具體概念請參看相關(guān)書籍，這里不再贅述。首先選擇CVS資源庫的位置，這里選擇的是/cvs/rpository。使用命令：mkdir/cvscd/cvsmkdir/repository在CVS資源庫下為項目源碼創(chuàng)建一個目錄：cd/cvs/repositorymkdir/project8.5項目案例首先我們要正確安裝并配置好CVS服務(wù)器，通常8.5項目案例2．初始化CVS服務(wù)器在選定CVS資源庫后，要進行CVS服務(wù)器的初始化操作。在此過程中，CVS服務(wù)器會創(chuàng)建所需要的文件系統(tǒng)。cvs–d/cvs/repository/init查看/cvs/repository/CVSROOT目錄下的文件：ls–a/cvs/repository/CVSROOT/8.5項目案例2．初始化CVS服務(wù)器8.5項目案例3．CVS服務(wù)器權(quán)限設(shè)定CVS資源庫建立好了，下一步就是建立用戶組和用戶，并為他們設(shè)定權(quán)限。在實際開發(fā)中分為項目管理小組和項目使用小組，管理小組負責(zé)維護，這里設(shè)定兩個用戶小組。首先創(chuàng)建CVS管理小組cvsmanager：groupaddcvsmanager然后創(chuàng)建CVS管理員賬號：adduser-gcvsmanagercvsadm-pcvsadmabc8.5項目案例3．CVS服務(wù)器權(quán)限設(shè)定8.5項目案例paswdcvsadm接著創(chuàng)建使用小組：groupaddcvsuser8.5項目案例paswdcvsadm接著創(chuàng)建使用小組：8.5項目案例然后創(chuàng)建用戶賬號：adduser-gcvsusercvsuserapasswdcvsusera8.5項目案例然后創(chuàng)建用戶賬號：passwdcvsuse8.5項目案例adduser–gcvsusercvsuserbpasswdcvsuserb接下來，配置文件夾/cvs/repository/CVSROOT設(shè)定權(quán)限。CVS服務(wù)器管理小組的成員是CVS服務(wù)器的管理員，擁有對配置文件夾/cvs/repository/CVSROOT下所有文件和目錄的讀/寫權(quán)限，同時，使用小組對該文件夾擁有讀的權(quán)限。下面對文件夾/cvs/repository/CVSROOT的權(quán)限進行設(shè)定：chmod777/cvs/repository/8.5項目案例adduser–gcvsusercvs8.5項目案例chgrp-rcvsmanager/cvs/repository/CVSROOTchmod-R075/cvs/repository/CVSROOT8.5項目案例chgrp-rcvsmanager/c8.5項目案例為使用小組追加對/cvs/repository/CVSROOT/history文件的寫權(quán)限：chmod077/cvs/repository/CVSROOT/history修改/cvs/repository/project目錄的權(quán)限：chgrp-Rcvsuser/cvs/repository/projectchmod770/cvs/repository/project然后，設(shè)置CVS口令服務(wù)器。還是用root身份。因為使用的是xinetd系統(tǒng)，所以需要修改/etc/xinetd.conf文件。命令如下：vi/etc/xinetd.conf需要將以下內(nèi)容寫入你打開的文件中：

servicecvspserver8.5項目案例為使用小組追加對/cvs/repositor8.5項目案例{port=2401socket_type=streamwait=nouser=rootserver=cvs的可執(zhí)行路徑

server_args=-f--allow-root=cvs資源庫目錄pserverlog_on_failure+=USERIDbind=本機的IP地址}8.5項目案例{8.5項目案例其中：CVS可執(zhí)行路徑，可以使用命令whereiscvs查看。例如：[root@localhostroot]#whereiscvscvs:/usr/bin/cvs/usr/share/cvs/usr/share/man/man1/cvs.1.gz/usr/share/man/man5/cvs.5.gzCVS資源庫目錄就是建立CVS資源庫的位置，這里是/cvs/repository。本機的IP地址，可以用ifconfig查看，這里是51。對文件xinetd.conf添加的內(nèi)容如下：8.5項目案例其中：8.5項目案例8.5項目案例8.5項目案例修改/etc/services文件：vi/etc/services添加如下內(nèi)容：8.5項目案例修改/etc/services文件：8.5項目案例cvspserver2401/tcp（有可能你的系統(tǒng)已經(jīng)存在，就不需要寫入了）8.5項目案例cvspserver24018.5項目案例啟動ineted/xinetd超級服務(wù)器，查看CVS服務(wù)器運行情況。重啟inetd使修改生效：/etc/rc.d/init.d/xinetdrestart至此，CVS服務(wù)器就配置好了，再確認一下CVS服務(wù)器是否已經(jīng)運行：netstat–lnp|grep24018.5項目案例啟動ineted/xinetd超級服務(wù)器，查8.5項目案例如果出現(xiàn)類似下面的提示就成功了：[root@localhostroot]#netstat-lnp|grep2401tcp0000:2401:*LISTEN32366/xinetd另外補充一下，Windows下也有簡單易用的CVS服務(wù)器，這里我們推薦CVSNT，可以下載CVSNT2.0.51a，安裝并啟動CVSNT，如圖1所示。然后切換到Repositories面板，添加一個Repository，命名為“/cvs-java”，CVSNT會提示是否初始化這個Repository，選擇“是”，如圖2所示。然后在Advanced面板上選中“PretendtobeaUnixCVSversion”，如圖3所示。8.5項目案例如果出現(xiàn)類似下面的提示就成功了：8.5項目案例圖1啟動CVSNT圖2Repositories面板圖3Advanced面板8.5項目案例圖1啟動CVSNT圖28.5項目案例最后，在Windows賬戶中為每一個開發(fā)人員添加用戶名和口令。CVSEclipse客戶端的配置和使用現(xiàn)在，CVS服務(wù)器上的安裝配置已經(jīng)完成。著名的開源IDEEclipse本身就內(nèi)置了對CVS的客戶端支持，只需簡單配置，即可使用CVS。首先啟動Eclipse，我們可以使用原有的工程，或者新建一個Project，然后選擇菜單“Window→ShowView→Other”，如圖4所示，打開“ShowView”對話框，如圖5所示。圖4選擇“Window→ShowView→Other”圖5“ShowView”對話框8.5項目案例最后，在Windows賬戶中為每一個開發(fā)人員8.5項目案例選中“CVSRepositories”選項，單擊

按鈕，則會出現(xiàn)如圖6所示的CVS資源庫的配置界面。圖6CVS資源庫的配置界面8.5項目案例選中“CVSRepositories”選項8.5項目案例在CVSRepositories的空白處單擊右鍵，彈出如圖7所示的右鍵菜單。圖7右鍵菜單8.5項目案例在CVSRepositories的空白處單8.5項目案例選擇“New→RepositoryLocation”選項，如圖8所示，彈出AddCVSRepository對話框，如圖9所示。圖8選擇“New→RepositoryLocation”8.5項目案例選擇“New→RepositoryLoca8.5項目案例圖9“AddCVSRepository”對話框8.5項目案例圖9“AddCVSRepository8.5項目案例要想和CVS服務(wù)器連通，必須要配置如下屬性（見圖10）：Host選項CVS服務(wù)器所在主機的IP地址或計算機名。Repositorypath選項資源文件放置的路徑，即CVSROOT目錄在CVS服務(wù)器上的路徑，用于上傳文件時存放的路徑。User選項系統(tǒng)管理員添加的CVS小組的用戶。Password選項登錄密碼。Connectiontype選項用于CVS客戶端與服務(wù)器端被確認連接的方式。Port選項CVS客戶端與服務(wù)器端連接的端口。8.5項目案例要想和CVS服務(wù)器連通，必須要配置如下屬性（8.5項目案例圖10配置CVS客戶端與服務(wù)器端連接的屬性8.5項目案例圖10配置CVS客戶端與服務(wù)器端連接的屬8.5項目案例連接之后的結(jié)果如圖11所示。圖11連接之后的結(jié)果8.5項目案例連接之后的結(jié)果如圖11所示。圖11連接之8.5項目案例如果成功，那么就可以進行上傳和下載項目了。在一個小組使用CVS之前必須要先上傳根項目，也就是要讓服務(wù)器上先有項目，然后各個組員CheckOut項目?，F(xiàn)在就介紹一個上傳和下載項目的例子。上傳項目：右鍵單擊等待上傳的項目，這里是electrones，然后選擇“Team→ShareProject”，如圖12所示。共享根項目：選擇CVS服務(wù)器，有兩個選項供選擇：建立一個新的和選擇已經(jīng)存在的數(shù)據(jù)倉庫。因為之前我們已經(jīng)創(chuàng)建過數(shù)據(jù)倉庫了，所以這里選擇已經(jīng)存在的“Useexistingrepositorylocation”，即默認選項，如圖13所示。8.5項目案例如果成功，那么就可以進行上傳和下載項目了。在8.5項目案例圖12選擇“Team→ShareProject”圖13選擇已經(jīng)存在的數(shù)據(jù)倉庫選項8.5項目案例圖12選擇“Team→SharePro8.5項目案例

按鈕，進入下一步，如圖14所示。出現(xiàn)3個選項，就是使用項目名稱、指定項目名稱以及選擇數(shù)據(jù)倉庫中已有的項目，這里選擇第1項“Useprojectnameasmodulename”。圖14選擇使用項目名稱8.5項目案例按鈕，進入下一步，如圖14所示。出現(xiàn)3個選8.5項目案例單擊這是上傳項目的最后一步。大家都應(yīng)該知道，程序的最后一步必然是確認信息的正確性及完整性，這里也不例外。如果這里顯示的信息和我們上傳的信息一致，那么就可以單擊

按鈕上傳了，如圖16所示。按鈕，進入下一步，如圖15所示。圖15確認信息8.5項目案例單擊這是上傳項目的最后一步。大家都應(yīng)該知道8.5項目案例圖16進行注釋并完成上傳8.5項目案例圖16進行注釋并完成上傳8.5項目案例在上傳文件前要進行必要的注釋并且完成上傳，然后單擊按鈕這時我們可以在本地項目中看到Eclipse中所有的文件都帶上了一個小數(shù)據(jù)庫模樣的圖標(biāo)，這證明已經(jīng)和CVS服務(wù)器同步了，如圖17所示。再看一下在本地建立的CVS客戶端中的版本，如圖18所示。圖17客戶端和CVS服務(wù)器同步圖18查看CVS客戶端中的版本8.5項目案例在上傳文件前要進行必要的注釋并且完成上傳，然8.5項目案例已經(jīng)都是1.1版本的文件了，這表示CVS服務(wù)器已經(jīng)正確接收了我們上傳的根項目，這時就要CVS管理員將這個已經(jīng)上傳的項目在服務(wù)器端設(shè)置一下組權(quán)限，那么其他人也可以下載開發(fā)了，如圖19所示。圖19設(shè)置組權(quán)限8.5項目案例已經(jīng)都是1.1版本的文件了，這表示CVS服務(wù)8.5項目案例將electrones項目加入cvsuser組以便供組成員使用，并且給cvsuser追加項目的使用權(quán)限，如圖20所示。圖20為用戶追加項目的使用權(quán)限8.5項目案例將electrones項目加入cvsuser8.5項目案例現(xiàn)在屬于cvsuser組的所有成員都可以在CVS服務(wù)器上CheckOut項目進行項目團隊開發(fā)了。當(dāng)然還有一些細節(jié)需要補充一下，以一個CVS小組成員b為例，它要CheckOut這個項目做自己的工作，那么首先他也要創(chuàng)建一個本地的CVS客戶端。假定他已經(jīng)按照cvsusera的創(chuàng)建步驟建好了，只等待CheckOut項目了，如圖21所示。圖21用戶開始CheckOut項目8.5項目案例現(xiàn)在屬于cvsuser組的所有成員都可以在C8.5項目案例如圖8-21所示，在項目上右擊，會出現(xiàn)一個下拉菜單，有CheckOut和CheckOutAs兩個下載選項，第一個是直接下載，而第二個是可以選擇項目名稱的，這里選擇第一個“CheckOut”進行操作如圖22所示。圖22用戶CheckOut項目過程8.5項目案例如圖8-21所示，在項目上右擊，會出現(xiàn)一個下8.5項目案例如果沒有意外就已經(jīng)完成了，如圖23所示。圖23用戶CheckOut項目結(jié)果8.5項目案例如果沒有意外就已經(jīng)完成了，如圖23所示。圖28.5項目案例

剛才的cvsusera是一樣的，都帶有小數(shù)據(jù)庫圖標(biāo)，證明我們的配置已經(jīng)成功。8.5.5特別提示在CVS系統(tǒng)中，一個開發(fā)者檢出（CheckOut）一個文件，修改（Update）它，然后將其檢入（CheckIn）回去。檢出文件的開發(fā)者擁有對這個文件修改的排他權(quán)，沒有其他的開發(fā)者可以檢出和修改這個文件。8.5.6拓展與提高在使用CVS過程中，一個常見的難點是多用戶代碼更新的沖突問題，如何解決？8.5項目案例剛才的cvsusera是一樣的，都Java軟件工程與項目案例教程(八)課件Java軟件工程與項目案例教程

（八）

Java軟件工程與項目案例教程

（八）

主要內(nèi)容1、軟件配置管理工具——CVS2、統(tǒng)一變更管理主要內(nèi)容1、軟件配置管理工具——CVS第8章軟件配置和變更管理8.1軟件配置管理概述配置管理作為軟件開發(fā)活動中的一項重要工作，其工作范圍主要包括以下4個方面：（1）標(biāo)識軟件工作產(chǎn)品（又稱標(biāo)識配置項）；（2）進行配置控制；（3）記錄配置狀態(tài)；（4）執(zhí)行配置審計。配置控制是配置管理的核心，它主要包括存取控制、版本控制、變更控制和產(chǎn)品發(fā)布控制等各個方面。8.2軟件配置管理工具——CVS1．代碼集中的配置2．保存修改記錄3．調(diào)整代碼8.3軟件變更管理概述今天的軟件開發(fā)團隊面臨著巨大的挑戰(zhàn)：一方面，市場要求以更快的速度來開發(fā)高質(zhì)量的軟件應(yīng)用；另一方面，軟件需求隨著開發(fā)環(huán)境和結(jié)構(gòu)的日趨多樣而變得更加復(fù)雜；再加上分布式開發(fā)、高性能要求、多平臺、更短和連續(xù)的發(fā)布周期——這些都加重了軟件開發(fā)所承受的壓力。由于軟件開發(fā)不同于傳統(tǒng)意義的工程技術(shù)，市場變化及技術(shù)上的高速更新都注定了軟件變更是非常頻繁并且是不可避免的，可以說變更是軟第8章軟件配置和變更管理8.1軟件配置管理概述8.3軟件變更管理概述件開發(fā)的基石。一方面，在軟件開發(fā)環(huán)境下的內(nèi)部活動以新特性、新功能增強及缺陷修復(fù)等方式不停地制造著變更；另一方面，外部因素例如新操作環(huán)境、新工具的集成、工程技術(shù)和市場條件的改善等以另一種力量驅(qū)動著變更。8.3軟件變更管理概述件開發(fā)的基石。一方面，在軟件開發(fā)環(huán)境8.4統(tǒng)一變更管理8.4.1統(tǒng)一變更管理概述使用UCM可以獲得以下好處：基于活動的配置管理過程：開發(fā)活動可以自動地與其變更集（封裝了所有用于實現(xiàn)該活動的項目工件）相關(guān)聯(lián)，這樣避免了管理人員手動跟蹤所有文件變更；預(yù)定義的工作流程：可以直接采用預(yù)定義的UCM工作流程，快速提升開發(fā)組織的軟件配置管理水平；項目的跟蹤和組織：項目管理人員可以實時掌握項目的最新動態(tài)，合理分配資源和調(diào)度開發(fā)活動；協(xié)作自動化：通過將許多耗時較多的任務(wù)自動化處理，UCM使得開發(fā)人員更多地將注意力集中在更高層次的開發(fā)活動上；輕松管理基線：UCM將開發(fā)活動嵌入到各個基線中，這樣測試人員確切地知道他們將測試什么，而開發(fā)人員則確切地知道其他開發(fā)人員做了什么；支持跨功能開發(fā)組：UCM已成為RationalSuite產(chǎn)品中的核心部分，從而可以將從需求到測試各個階段的工件（例如需求文檔、設(shè)計模型、應(yīng)用源代碼、測試用例及XML內(nèi)容等）在UCM框架下進行統(tǒng)一集成，簡化了貫穿整個軟件開發(fā)周期的變更過程；基于同一代碼構(gòu)件可以進行多項目開發(fā)，簡化了多項目開發(fā)管理，增大了代碼共享，節(jié)省了開發(fā)資源。8.4統(tǒng)一變更管理8.4.1統(tǒng)一變更管理概述8.4統(tǒng)一變更管理8.4.2統(tǒng)一變更管理原理1．活動和工件管理（1）活動管理UCM中的活動管理是由RationalClearQuest提供的，RationalClearQuest是一個高度靈活和可擴展的缺陷及變更跟蹤系統(tǒng)，它可以捕獲和跟蹤所有類型的變更請求（例如產(chǎn)品缺陷、增強請求、文檔變動等）。在UCM中這些變更均以活動出現(xiàn)。RationalClearQuest為活動的跟蹤和管理提供了可定制的工作流，這使得開發(fā)團隊可以更容易地：將活動分配給某個具體的開發(fā)人員；標(biāo)識與活動相關(guān)的優(yōu)先級、當(dāng)前狀態(tài)和其他信息（如負責(zé)人、估計工期、影響程度等）；自動產(chǎn)生查詢、報告和圖表。根據(jù)開發(fā)團隊或開發(fā)過程需求可以靈活地調(diào)整ClearQuest工作流引擎：如果開發(fā)團隊需要快速部署，那么也可以不進行定制，直接使用ClearQuest預(yù)定義的變更過程、表單和相關(guān)規(guī)則；當(dāng)開發(fā)團隊需要在預(yù)定義的過程上進行定制時，可以使用ClearQuest對他們的變更過程的各個方面——包括缺陷和變更請求的狀態(tài)轉(zhuǎn)移生命周期、數(shù)據(jù)庫字段、用戶界面（表單）布局、報告、圖表和查詢等進行定制。8.4統(tǒng)一變更管理8.4.2統(tǒng)一變更管理原理8.4統(tǒng)一變更管理貫穿整個開發(fā)過程用于管理和跟蹤缺陷及其他變更的一個高效工作流對于滿足當(dāng)今高質(zhì)量標(biāo)準(zhǔn)及緊迫的產(chǎn)品工期的需要是非常重要的。UCM提升了這些變更的抽象層次，以便可以從活動的角度來觀察變更，然后RationalClearQuest工作流引擎將活動與相關(guān)的開發(fā)工件連接在一起。（2）工件管理RationalClearCase提供了一個軟件工件管理（SAM）框架，開發(fā)團隊可以使用這一框架來管理貫穿項目生命周期的所有工件。UCM將RationalClearCase基礎(chǔ)框架與RationalClearQuest中的活動管理結(jié)合在一起，從而提供了對工件和活動的集成管理。RationalClearCase提供了：安全的工件存儲和版本化；并行開發(fā)基礎(chǔ)框架——無限分支能力和強大的合并功能；自動代碼共享；用于選擇正確工件版本的工作空間管理；完全的可延展性——從小型本地項目工作組到大型全球分布式開發(fā)團隊。8.4統(tǒng)一變更管理貫穿整個開發(fā)過程用于管理和跟蹤缺陷及其他8.4統(tǒng)一變更管理2．UCM：6個過程領(lǐng)域UCM在6個具體領(lǐng)域提供了所定義的過程：開發(fā)人員在共享及公共代碼工件上的隔離和協(xié)作；將一起開發(fā)、集成和發(fā)布的相關(guān)工件組按構(gòu)件（component）進行組織；在項目里程碑創(chuàng)建構(gòu)件基線（baseline）并根據(jù)所建立的質(zhì)量標(biāo)準(zhǔn)來提升基線；將變更組織為變更集（changeset）；將活動管理和工件管理集成在一起；按項目來組織軟件開發(fā)并支持多項目之間的代碼共享。（1）開發(fā)人員的隔離和協(xié)作8.4統(tǒng)一變更管理2．UCM：6個過程領(lǐng)域8.4統(tǒng)一變更管理IntegrationStreamDevelopmentStream2DevelopmentStream1圖8-2UCM提供了公共集成工作區(qū)和私有工作區(qū)8.4統(tǒng)一變更管理IntegrationStreamD8.4統(tǒng)一變更管理

私有開發(fā)流為開發(fā)人員提供了相互隔離的工作空間，該空間在最開始由滿足一定質(zhì)量標(biāo)準(zhǔn)的公共工件進行初始化。開發(fā)人員使用這些私有工作空間來進行工件的變更、構(gòu)建和測試。當(dāng)開發(fā)人員對他們的變更感到滿意時，他們可以將這些變更交付（deliver）到公共集成流上。為了使開發(fā)人員與其他人員的進度同步，開發(fā)人員也可以用來自項目公共集成流上最新的穩(wěn)定基線來變基（rebase）他們的私有工作流。使用UCM，開發(fā)人員可以選擇什么時候進行交付和變基。實際上，項目集成流充當(dāng)了所有開發(fā)人員的所有變更的協(xié)調(diào)點。為了更好地協(xié)調(diào)所有開發(fā)人員的變更集成，UCM引入了基線（baseline）的概念作為對項目進度的度量?；€是一次構(gòu)建（build）或配置的抽象表示，它實際上是構(gòu)件的一個版本，而構(gòu)件是相關(guān)工件的集合。項目開發(fā)團隊在開發(fā)過程期間不斷地創(chuàng)建和提升基線。隨著不同開發(fā)人員交付變更給集成流，他們交付的變更將被逐一收集到項目基線中。隨著基線的構(gòu)建、測試和批準(zhǔn)，它們可以被逐步提升到不同的基線級別。8.4統(tǒng)一變更管理私有開發(fā)流為開發(fā)人員提供了相互隔離8.4統(tǒng)一變更管理

基線提升級別具有兩方面的功能：第一，它使項目經(jīng)理或項目管理人員可以建立軟件質(zhì)量標(biāo)準(zhǔn)。由于當(dāng)基線達到某種預(yù)定義的質(zhì)量標(biāo)準(zhǔn)時就可以被標(biāo)以某種基線級別，因此項目經(jīng)理可以設(shè)置項目策略，標(biāo)識出在哪一個基線級別（如“通過測試的”）開發(fā)人員可以執(zhí)行變基操作。第二，基線提升級別就具體的開發(fā)人員應(yīng)該如何與其所開發(fā)的工件進行交互提供了指導(dǎo)。例如，根據(jù)某條基線通過某些冒煙測試的時間可以幫助測試人員確定什么時候開始測試。（2）構(gòu)件基線第二個UCM過程領(lǐng)域是將工件組織為構(gòu)件。在第二代配置管理中，大多以文件版本形式來管理所有的文件，當(dāng)一個復(fù)雜項目中包含成千個文件上萬個版本時，整個項目的開發(fā)控制將變得相當(dāng)復(fù)雜，因此對眾多的文件進行合理分類以呈現(xiàn)系統(tǒng)的設(shè)計要素可以大大簡化項目開發(fā)控制。UCM通過將多個工件組織為構(gòu)件（在UCM中構(gòu)件指一個VOB的根目錄或VOB的某個第一層子目錄），從而擴展了軟件工件管理的版本控制能力，并且UCM還提供了用于自動化構(gòu)件管理的工具和過程。即用基線對構(gòu)件而不是構(gòu)件中眾多的版本進行標(biāo)識，然后用這一基線作為新的開發(fā)起點并更新開發(fā)人員的工作空間。8.4統(tǒng)一變更管理基線提升級別具有兩方面的功能：第一8.4統(tǒng)一變更管理構(gòu)件基線是在ClearCase標(biāo)簽（label）的基礎(chǔ)上結(jié)合活動管理所做的擴展，即您可以知道一個UCM構(gòu)件基線中包含了哪些開發(fā)活動。例如，一條基線可能包含了3個開發(fā)活動，如BUG101的修復(fù)、用戶登錄界面漢化及新增打印特性的支持。對于包含多個構(gòu)件的復(fù)雜系統(tǒng)，UCM提供了基于多個構(gòu)件的組合基線，即多個構(gòu)件之間可以建立依賴關(guān)系，一旦底層構(gòu)件的基線發(fā)生變化，例如生成一條新基線，其上層構(gòu)件相應(yīng)地也自動建立起一條基線，該基線自動包含底層構(gòu)件基線。例如，一個較為復(fù)雜的MIS系統(tǒng)包含“數(shù)據(jù)庫訪問”、“業(yè)務(wù)邏輯處理”和“前端圖形界面”3個構(gòu)件，其中“前端圖形界面”構(gòu)件依賴于“業(yè)務(wù)邏輯處理”構(gòu)件，而“業(yè)務(wù)邏輯處理”構(gòu)件依賴于“數(shù)據(jù)庫訪問”構(gòu)件。這樣當(dāng)“數(shù)據(jù)庫訪問”構(gòu)件發(fā)生了變化并新建了一條新基線（如DB_BASELINE_Dec24）后，在“業(yè)務(wù)邏輯處理”構(gòu)件和“前端圖形界面”構(gòu)件中自動建立了一條新基線（如BUSINESS_BASELINE_Dec24和GUI_BASELINE_Dec24）。這樣上層構(gòu)件的最新基線可以自動跟蹤底層構(gòu)件的最新基線。構(gòu)件管理的自動化對于高效無誤地開發(fā)可能包含數(shù)千個源代碼工件（還有其他相關(guān)的工件，如Web內(nèi)容、設(shè)計模型、需求說明和測試腳本等）的復(fù)雜軟件系統(tǒng)而言意義重大。8.4統(tǒng)一變更管理構(gòu)件基線是在ClearCase標(biāo)簽（la8.4統(tǒng)一變更管理（3）構(gòu)件基線提升項目開發(fā)團隊的成員工作在一個UCM項目（project）中，項目經(jīng)理通過配置軟件構(gòu)件從而使項目成為由構(gòu)件構(gòu)成的體系結(jié)構(gòu)。大多數(shù)組織將UCM管理的構(gòu)件設(shè)計為可以反映出他們軟件體系結(jié)構(gòu)的方式（見圖8-3），即將所有相關(guān)工件按體系結(jié)構(gòu)組織為有意義的子系統(tǒng)，進而放入不同的構(gòu)件中。SystemUserInterfaceAdministration圖8-3用UCM構(gòu)件直接對軟件體系結(jié)構(gòu)建模8.4統(tǒng)一變更管理（3）構(gòu)件基線提升SystemUser8.4統(tǒng)一變更管理如上節(jié)所描述的，開發(fā)人員在交付變更到公共集成流時可以周期性地更新他們私有開發(fā)流中的構(gòu)件，然后開發(fā)團隊可以根據(jù)開發(fā)過程的當(dāng)前階段和質(zhì)量級別對構(gòu)件進行評級。項目策略確定了在開發(fā)人員變基之前構(gòu)件基線必須達到的質(zhì)量級別，以及其他開發(fā)團隊成員（如測試人員）應(yīng)該如何與構(gòu)件基線交互。在稍后會對項目及項目策略做更多的描述。UCM提供了5種預(yù)定義的基線級別，包括被拒絕（rejected）、初始（initial）、通過構(gòu)建（built）通過測試（tested）和已發(fā)布（released）。另外，UCM允許開發(fā)團隊用他們自己的命名規(guī)范和提升策略對這些預(yù)定義基線級別進行定制。8.4統(tǒng)一變更管理如上節(jié)所描述的，開發(fā)人員在交付變更到公共8.4統(tǒng)一變更管理（4）變更集第4個UCM過程領(lǐng)域是將獨立的工件變更組織為可作為整體進行交付、跟蹤和管理的變更集中。由于通常當(dāng)開發(fā)人員工作在一個活動（例如缺陷修復(fù)）上時，他們很少只修改一個文件，因此用變更集可以表示用以完成某個具體活動的工件的所有變更。例如，為修改一個編號為36的缺陷變動了30個目錄/文件的100個版本，則缺陷36的變更集為相關(guān)的100個文件/目錄版本。開發(fā)人員同時工作在多個變更請求上的需要使得這一過程更加復(fù)雜。例如，一個開發(fā)人員在進行一個新發(fā)布版本的開發(fā)，這時由于當(dāng)前發(fā)布版本的一個錯誤要求他不得不中斷當(dāng)前的開發(fā)工作轉(zhuǎn)而去修復(fù)這一缺陷，這樣該開發(fā)人員必須在同一工件上進行兩種不同的變更：一種是在未來發(fā)布版本中的增強功能變更；另一種是在前一發(fā)布版本中修復(fù)缺陷的變更。通過將同一個開發(fā)活動相關(guān)的所有變更收集到一個變更集中，UCM簡化了管理多個工件變更或者多個工件版本的過程。UCM圍繞具體的開發(fā)活動來進行工作組織，同時UCM還確保已完成的活動包含所有必要工件上發(fā)生的所有變更。8.4統(tǒng)一變更管理（4）變更集8.4統(tǒng)一變更管理（5）活動和工件管理第5個UCM過程領(lǐng)域是通過使用一個可將活動及其相關(guān)工件集鏈接起來的自動化工作流（見圖8-4），將活動管理和工件管理集成起來。這給了開發(fā)團隊極大的靈活性來為不同類型活動的管理指定不同的工作流。UCM提供了最常用活動類型的預(yù)定義工作流，包括缺陷修復(fù)和增強請求。8.4統(tǒng)一變更管理（5）活動和工件管理8.4統(tǒng)一變更管理圖8-4UCM工作流概覽8.4統(tǒng)一變更管理圖8-4UCM工作流概覽8.4統(tǒng)一變更管理開發(fā)團隊還可以使用ClearQuestDesigner這一模塊來對這些預(yù)定義過程進行定制，項目經(jīng)理或者項目管理人員可以用它來創(chuàng)建所有需要的活動類型，包括缺陷修復(fù)、增強功能請求、文檔變動及Web網(wǎng)站變動等。使用ClearQuestDesigner的圖形用戶界面，項目經(jīng)理也可以定義字段、表單及每個記錄類型的狀態(tài)轉(zhuǎn)移。為了方便開發(fā)人員更容易地標(biāo)識活動和項目代碼庫中工件間的關(guān)系，UCM自動將活動和其相關(guān)的變更集鏈接起來（見圖8-5）。當(dāng)在一個UCM項目中工作時，開發(fā)人員所交付的是活動而不是文件形式的工件。類似的，當(dāng)開發(fā)人員變基時，他們根據(jù)新構(gòu)件基線提供的活動（而不是文件形式的工件）來重審將要在他們的私有開發(fā)流中接收的變更內(nèi)容。這樣，開發(fā)人員不僅可以看到所有相關(guān)工件完整的版本歷史，而且可以看到實現(xiàn)每個變更的所有活動。這給了開發(fā)團隊一個項目是如何從一個階段演進到下一個階段的全面視圖，當(dāng)需要標(biāo)識出一個工件版本的變更是如何影響另一個版本時，這一優(yōu)點所帶來的價值是無法估計的。使用UCM一致、可重復(fù)的用于活動管理的過程，通過活動管理和工件管理的集成可以幫助開發(fā)團隊減少錯誤，開發(fā)人員還可以避免許多通常需要手工作業(yè)的單調(diào)工作，從而更有效率地完成開發(fā)任務(wù)。8.4統(tǒng)一變更管理開發(fā)團隊還可以使用ClearQuest8.4統(tǒng)一變更管理圖8-5UCM將活動和相關(guān)的工件鏈接起來8.4統(tǒng)一變更管理圖8-5UCM將活動和相關(guān)的工件鏈接8.4統(tǒng)一變更管理（6）項目和項目策略UCM中的項目可以和實際軟件開發(fā)中的各種項目對應(yīng)，每個UCM項目包含一個集成工作流和若干個私有開發(fā)流，項目可由一組構(gòu)件構(gòu)成。這里需要強調(diào)的是一個構(gòu)件可以被多個項目共享，進而項目A中的開發(fā)人員可以對一個構(gòu)件進行修改，創(chuàng)建新的構(gòu)件基線；而項目B的開發(fā)人員可以參照同一構(gòu)件及該構(gòu)件在項目A中生成的基線，但不能對該構(gòu)件進行任何改動。因而UCM項目從代碼級提供了軟件共享及重用的良好基礎(chǔ)。UCM在項目上的另一個突出特點是不同項目中的開發(fā)流之間可以進行跨項目的工作交付。即一個項目可以將一條構(gòu)件基線中包含的工件交付給另一個項目，也可以將一個開發(fā)流上的活動變更集交付給另一個項目?？梢钥闯鲰椖繌囊粋€更高層次上支持了傳統(tǒng)意義上基于分支的并行開發(fā)，這對于軟件開發(fā)組織從面向項目到面向產(chǎn)品的轉(zhuǎn)變，合理利用軟件開發(fā)人力資源，改善軟件產(chǎn)品體系結(jié)構(gòu)，從而支持更為復(fù)雜的軟件開發(fā)具有重大意義。8.4統(tǒng)一變更管理（6）項目和項目策略8.4統(tǒng)一變更管理由于同一代碼構(gòu)件上多項目開發(fā)的引入，相應(yīng)的UCM加入了多種項目策略來進行支持，用戶可以根據(jù)需要靈活定義項目策略。例如對于基線級別，可以定義只有基線級別提升到“Tested”才能作為其他開發(fā)工作流的推薦基線。另外，對于多項目間的代碼交付和共享，還可以定義是否允許接受其他項目的變更等。除了項目一級的策略以外，在工作流一級UCM也有類似的訪問策略，如某個工作流是否允許接受來自本項目或其他項目的工作流上的變更，是否允許向本項目或其他項目的工作流交付變更等。3．貫穿生命周期的工件到現(xiàn)在為止，我們的討論主要集中在源代碼和其相關(guān)工件上，如對象文件和頭文件等。但是使用UCM時貫穿生命周期的變更也可以由非開發(fā)人員進行管理，這樣就最佳實現(xiàn)了統(tǒng)一變更管理的全部好處。這些非開發(fā)人員包括分析人員、設(shè)計人員及測試人員（見圖8-6）。相應(yīng)的工件包括他們在相關(guān)領(lǐng)域產(chǎn)生的工件，例如分析人員所創(chuàng)建的需求文檔和用例（UseCase）、設(shè)計人員所建立的設(shè)計模型和用例，以及測試人員所建立的測試腳本、測試數(shù)據(jù)和測試結(jié)果。8.4統(tǒng)一變更管理由于同一代碼構(gòu)件上多項目開發(fā)的引入，相應(yīng)8.4統(tǒng)一變更管理圖8-6開發(fā)團隊成員在生命周期的不同階段產(chǎn)生不同的工件8.4統(tǒng)一變更管理圖8-6開發(fā)團隊成員在生命周期的不同8.4統(tǒng)一變更管理為了高效地通信和協(xié)作工作，開發(fā)團隊成員需要有效地共享這些工件。RationalSuite包含有一個集成平臺，通過這一公共平臺可以訪問貫穿多個領(lǐng)域的所有類型的開發(fā)工件。作為RationalSuite的一部分，UCM提供了一個用于管理貫穿軟件開發(fā)生命周期的信息共享的過程層?，F(xiàn)在每個RationalSuite產(chǎn)品套件中均包含了這兩個產(chǎn)品，這樣每個RationalSuite產(chǎn)品都包含了對UCM過程的支持。非軟件開發(fā)人員（如分析人員、設(shè)計人員及測試人員）可以應(yīng)用UCM原理像控制代碼變更一樣來控制他們生產(chǎn)的工件（如需求文檔、用例、設(shè)計模型、測試腳本及測試數(shù)據(jù)）。RationalClearQuest工作流引擎強化了活動管理，另外一致的工作流使得所有的團隊成員都可以容易地標(biāo)識優(yōu)先級，而ClearQuest提供的工作列表（todolist）特性可以使每個人均可從他們的桌面透明訪問待進行的工作（活動）列表，從而容易地標(biāo)識出他們下一步需要進行的工作。同樣構(gòu)件基線是新工作（分析、設(shè)計、開發(fā)及測試）的基礎(chǔ)，并指導(dǎo)團隊成員什么時候更新他們的工作空間。（1）來自分析的工件分析人員扮演著定義項目范圍的重要角色，分析人員需要確定解決方案是什么及系統(tǒng)邊界。在分析期間這些專業(yè)人員創(chuàng)建了多種不同的工件來幫助解釋說明所建議的解決方案，這些工件包括需求文檔、用例及可視化模型。開發(fā)團隊在整個開發(fā)過程中不斷使用這些工件來管理項目變更是必不可少的。8.4統(tǒng)一變更管理為了高效地通信和協(xié)作工作，開發(fā)團隊成員需8.4統(tǒng)一變更管理成功的項目依賴于正確的需求管理。高效的需求管理包括減少開發(fā)的進度風(fēng)險和系統(tǒng)的不穩(wěn)定性，以及跟蹤需求變更。項目管理、風(fēng)險評估及相關(guān)評估標(biāo)準(zhǔn)的產(chǎn)生都依賴于需求管理和需求的可追溯性——即開發(fā)團隊以一種規(guī)范過程接受變更并審查需求變更的歷史。RationalRequisitePro是RationalSuite開發(fā)團隊統(tǒng)一平臺（TeamUnifyingPlatform）中用于需求管理的工具。軟件開發(fā)團隊可以使用RequisitePro來創(chuàng)建、管理和跟蹤分析工件，例如需求屬性、需求說明和管理計劃、用例模型、術(shù)語表及涉眾（stakeholder）請求。UCM項目以與管理代碼相似的方式管理需求，此外UCM還將這些需求工件包含在構(gòu)件基線中。這樣分析人員不僅知道哪些活動構(gòu)成了一條構(gòu)件基線中的工件，還知道哪些需求指導(dǎo)著這些工件的開發(fā)。（2）來自設(shè)計的工件設(shè)計人員對系統(tǒng)基礎(chǔ)結(jié)構(gòu)建模并使用用例和設(shè)計模型進一步細化系統(tǒng)定義。通過設(shè)計工件對系統(tǒng)進行抽象，可以減少整個系統(tǒng)的復(fù)雜性。8.4統(tǒng)一變更管理成功的項目依賴于正確的需求管理。高效的需8.4統(tǒng)一變更管理在實際開發(fā)過程中經(jīng)常會出現(xiàn)這樣一種情況：一些開發(fā)團隊不能繼續(xù)使用一些設(shè)計模型，因為正式的編碼工作已經(jīng)開始。這是一個錯誤，因為這些設(shè)計模型在幫助規(guī)劃整個工作，另外對于協(xié)助新的組成員快速上手，度量正在進行中的變更請求的影響，以及評估整個項目風(fēng)險都非常有價值。由RationalRose提供的雙向工程功能可以幫助開發(fā)團隊保持當(dāng)前編碼進度和這些模型之間的同步（見圖8-7），而UCM確保模型與代碼是最新的。ModelsC圖8-7并行開發(fā)過程中模型和代碼之間的交互8.4統(tǒng)一變更管理在實際開發(fā)過程中經(jīng)常會出現(xiàn)這樣一種情況：8.4統(tǒng)一變更管理在UCM項目中，構(gòu)件基線包含模型工件和代碼工件。RoseModelIntegrator和ClearCase比較/合并特性的緊密集成，使得開發(fā)團隊可以盡可能方便地在設(shè)計模型的同時進行編碼。這時UCM中的變更集可以擴展到模型元素，這樣變更集便包含了代碼工件上的變更，以及模型工件上的變更。RationalRose支持UCM交付（deliver）和變基（rebase）操作（參見活動和工件管理部分），使得多個設(shè)計人員可以在Rose模型上同時工作，如同開發(fā)人員并發(fā)工作在代碼上一樣。（3）來自測試的工件傳統(tǒng)的開發(fā)方法將測試工作放到開發(fā)的末期，在編碼工作之后進行。成功的構(gòu)件開發(fā)團隊都體會到單元測試（UnitTest）對于項目成功是非常重要的，使用單元測試就是不將構(gòu)件的質(zhì)量保證放到集成階段，而是預(yù)先對單元、子系統(tǒng)和系統(tǒng)進行測試。所有這些并發(fā)測試產(chǎn)生了大量的測試工件，包括測試需求、測試腳本、測試數(shù)據(jù)和大量的測試結(jié)果。RationalSuiteTestStudio及RationalQualityArchitect為開發(fā)團隊提供了可持續(xù)地生產(chǎn)高質(zhì)量軟件工件所需的集成框架。借助UCM，開發(fā)團隊可以并發(fā)地管理他們的測試工件和相關(guān)的開發(fā)工件。今天，大多數(shù)開發(fā)團隊都意識到將這些測試工件和構(gòu)件基線集成到一起的好處。在UCM項目中，可以在一條構(gòu)件基線中包含所有的代碼工件，以及相關(guān)的測試需求、測試程序和測試數(shù)據(jù)。8.4統(tǒng)一變更管理在UCM項目中，構(gòu)件基線包含模型工件和代8.4統(tǒng)一變更管理這樣前面描述的變更集就可以擴展到測