軟件發(fā)布記錄是其它基于狀態(tài)的記錄類型的一個(gè)父記錄，它向發(fā)布經(jīng)理提供了發(fā)布的一個(gè)全局的視圖，但是我確信，你正在問自己，怎樣管理一個(gè)詳細(xì)視圖呢?

　　更深入一步進(jìn)入過程，我們可以產(chǎn)生兩個(gè)額外的基于狀態(tài)的記錄類型，事件(Incident) 和工作請(qǐng)求(Work Request)記錄。

　　事件記錄類型可被規(guī)類為缺陷、問題、風(fēng)險(xiǎn)、變更請(qǐng)求等等，由于這些不同的分類，事件記錄類型有一個(gè)相當(dāng)復(fù)雜的狀態(tài)轉(zhuǎn)換矩陣：

圖4. 事件記錄

　　事件記錄類型獲取描述信息、標(biāo)題(一個(gè)簡(jiǎn)短描述)、所有人名稱、優(yōu)先級(jí)、嚴(yán)重度，以及相關(guān)軟件發(fā)布記錄、相關(guān)事件記錄和相關(guān)工作請(qǐng)求。

　　當(dāng)一個(gè)事件記錄進(jìn)入了 Slotted 狀態(tài)，那么它一定跟軟件發(fā)布記錄是相關(guān)聯(lián)的。

　　經(jīng)常從用戶那里聽到的一個(gè)抱怨是，他們什么時(shí)候需要重新創(chuàng)建一個(gè)記錄，因?yàn)榘旬?dāng)前記錄拷貝和粘貼到新的記錄上是十分單調(diào)乏味的工作，雖然工作很簡(jiǎn)單但是很可能出錯(cuò)，比如粘貼一個(gè)值到一個(gè)錯(cuò)誤的字段或者忘記將值從原始記錄拷貝到新的記錄。解決這個(gè)問題的辦法是給用戶一個(gè)不用拷貝和粘貼可以克隆記錄的方法。這樣不僅創(chuàng)建了一個(gè)記錄，并用來自原始記錄的數(shù)據(jù)在板上進(jìn)行組裝，同時(shí)還在兩個(gè)記錄之間創(chuàng)建了一個(gè)鏈接。這個(gè)克隆記錄的代碼可以通過下面參考資源部分中 Shmuel Bashan 的 developerWorks 文章中得到。

　　developerWorks 上的代碼必須分散到不同腳本中與各種事件類型一起操作。第一個(gè)腳本 clone_record.zip)是確定用戶想要克隆的事件記錄類型，它然后將執(zhí)行適當(dāng)?shù)母郊幽_本來克隆這個(gè)記錄。

　　使用 ClearCase/UCM/ClearQuest 實(shí)現(xiàn)集成的一個(gè)局限性是一個(gè)記錄只能分配到一個(gè)項(xiàng)目/流程/視圖，并且一次只能一個(gè)人對(duì)它進(jìn)行操作。然而，很可能有同時(shí)有好幾個(gè)人操作一個(gè)變更或者他們可能在世界的不同地方，在不同的工作流程中對(duì)同一個(gè)變更進(jìn)行操作。

　　為了克服這種局限性，你可以執(zhí)行工作請(qǐng)求記錄類型。工作請(qǐng)求記錄類型是一個(gè)可以運(yùn)用統(tǒng)一變更管理(UCM)包的基于狀態(tài)的記錄類型。

　　這個(gè)工作請(qǐng)求記錄的創(chuàng)建必須來自于事件記錄內(nèi)部，因?yàn)樵S多數(shù)據(jù)元素是直接從事件記錄拷貝到這個(gè)工作請(qǐng)求記錄的，并且這兩個(gè)記錄后來是相互連接的。這個(gè)工作請(qǐng)求記錄幾乎是可任意使用的，它內(nèi)部有一個(gè)非常短的生命周期，因?yàn)橛脩舨恍枰�輸入很多�?shù)據(jù)，這個(gè)工作請(qǐng)求可以很容易地被創(chuàng)建、分配、繼續(xù)操作，然后關(guān)閉。一旦開發(fā)者完成了編碼變更，通過了代碼評(píng)審，單元測(cè)試變更的記錄將結(jié)束。它將提醒事件管理者，這個(gè)記錄即將進(jìn)入下一個(gè)狀態(tài)。