您知道何時使用 IBM Rational ClearQuest MultiSite 以及何時使用 ClearQuest Web 麼？何時電子郵件規則是相關的，以及何時它們僅僅是更多的垃圾郵件？如何將分離的用戶數據庫集中爲一個用戶數據庫？一位變更管理的專家將向您提供 ClearQuest 實施方面的建議。
IBM® Rational® ClearQuest® 爲生產企業級的 Software Change Management (SCM) 提供了一個十分強大和用戶定製的平臺。但是您應該何時使用 ClearQuest MultiSite 和 ClearQuest Web 呢？何時電子郵件規則是相關的，以及何時它們僅僅是更多的垃圾郵件？如何將分開的用戶數據庫合併爲一個用戶數據庫？
本文列舉了我克服苦難併成功實施 ClearQuest 的十個技巧。
隨着 ClearQuest MultiSite 2002 版的引入，ClearQuest 的配置又增加了一個選項，那就是地理分佈的定位。但是您如何決定到底是應該將時間和金錢等資源投入到潛在的複雜的 MultiSite 實施呢，還是隻是簡單的使用 ClearQuest Web 接口？
答案是由多方面因素決定的，包括地理分佈的團隊使用本地配置的客戶端的需要（用於 Windows 的 ClearQuest 和 ClearQuest Eclipse Rich Client Platform (RCP)），以及機構在不同地點之間所能提供的帶寬。通常來說，如果地理分佈的團隊中的用戶需要使用本地配置的客戶端的話，您就需要 MultiSite。如果您僅僅是需要向地理分佈的用戶提供訪問 ClearQuest 從而實施那些不需要本地客戶端的操作的話，那麼您就不需要 ClearQuest Web 了。無論如何，ClearQuest 和 IBM Rational ClearCase® 之間的結合，將使通過 ClearQuest Web 來利用新的 ClearQuest Test Management 性能變得更加困難。參見圖 1。
隨着 ClearQuest 和 ClearCase 7.0.1 的發佈，需要 ClearQuest MultiSite 來推動集成的 Unified Change Management (UCM) 環境的強制情形應該被重新考查。ClearCase Remote Client (CCRC) 和 ClearQuest Web 之間緊密的集成允許用戶在一個 “Web 爲中心的” 環境下進行操作，利用 Rational Web Platform （ClearCase Web 和 ClearQuest Web）。然而，CCRC 內動態視圖的缺乏將成爲大多數機構的一個破壞者，唯一的解決方法就是允許 ClearCase 和 ClearQuest MultiSite 達到團隊所需要的特性集。 ![Rational ClearQuest 安裝環境]()
ClearQuest Test Manager 對於不在現場的測試人員來說，會使 ClearQuest Multisite 的配置變得複雜
在 7.0 版本中引入的 ClearQuest Test Management (CQTM) 包也可能成爲決定配置 MultiSite 的一個因素。如果一個機構有遠程位置使用 CQTM 來維護 IBM Rational ManualTester、IBM Rational FunctionalTester、或者 IBM Rational PerformanceTester 所進行的測試方案、測試用例、以及測試結果記錄的話，MultiSite 將是唯一合理的解決方案。將測試工具和 Eclipse ClearQuest Perspective 結合起來以及記錄測試結果的能力，對於測試人員來說是一項必不可少的要求。ClearQuest Web 爲執行測試計劃功能和生成報告提供了足夠的支持；然而，對於一個嚴謹的測試環境來說，ClearQuest Web 將不能提供所需要的全部功能。
ClearQuest 7.0.1 爲結合應用程序提供了四種不同的用戶選項：用於 Windows 的 ClearQuest、ClearQuest Web、ClearQuest Eclipse Plug-In、和 ClearQuest Eclipse RCP。您必須考慮清楚哪一種客戶端應該被用於哪一種功能。表1列出了 ClearQuest 的不同的“風味”，並展示了它們都提供了哪些功能。 表 1: 當工作於集成環境時，需要考慮和計劃一下如何決定將哪一個 ClearQuest 客戶端給用戶
| |
ClearQuest 客戶端（Eclipse RCP） |
ClearQuest Eclipse 插件 |
ClearQuest Windows 客戶端 |
ClearQuest Web |
|---|
| 測試計劃 |
X |
X |
X |
X |
|---|
| 測試設計（Test 和 Configured Test Case 之間的關聯） |
X |
X |
|
|
|---|
| 測試執行 |
|
X |
|
|
|---|
| 測試報告 |
X |
X |
X |
X |
|---|
| 與 Eclipse IDE (Rational Application Developer) 的集成 |
|
X |
|
|
|---|
| 與 ClearCase Windows 客戶端的集成 |
X |
X |
X |
|
|---|
| 與 ClearCase Remote 客戶端的集成 |
|
|
|
X |
|---|
| 與 IBM Rational RequisitePro® Windows 客戶端的集成 |
|
|
X |
|
|---|
| 同與 RequisiteWeb 的集成 |
|
|
|
X |
|---|
| 設計者報告 |
|
|
|
X |
|---|
在創建您的軟件發行方案時，記得回顧不同的 ClearQuest 客戶端的性能以及您所在的機構是如何配置的。如果您在一個獨立的、無需結合的環境中的使用 ClearQuest，那麼您可以將 ClearQuest Web 配置爲主要客戶端。然而，即使在一個“以 Web 爲中心的環境”中，還是有一部分用戶將要求用於 Windows 的 ClearQuest 客戶端同 Crystal Reports 一起生成報告格式，這是標準化改變管理系統所帶給機構的價值的一部分。
在一個更具結合性的設置中，您將需要將您的環境劃分爲“類”，從而決定哪一些客戶端配置到用戶系統中。“開發者類”將需要 Eclipse 的插入來同它們的 Eclipse Integrated Development Environment (IDE) 環境進行整合。“分析師類”可能需要用於 Windows 的 ClearQuest 客戶端允許 同它們的 用於 Windows 的 RequisitePro 客戶端進行整合，以及提供追溯 ClearQuest 中保存的需求和變更需求（許多情況下）的能力。
不要重複發明輪胎。對於一位新的 ClearQuest 管理員來說，Rational ClearQuest 論壇是最值得訪問的站點，它的網址是：IBM developerWorks。該論壇提供了尋找用戶貢獻的 hook 例子的去處，並且可以尋找您在配置過程中所遇到的問題的答案。
除了討論，在 ClearQuest hooks index 裏還有許多 hook 執行的例子。如果您試圖添加一個 Choicelist、添加 auditing functions、或者使用 ClearQuest 來加強特定域的約束或者驗證，那麼這裏有許多例子可以幫助您完成您的個性化定製。
在 ClearQuest hooks index 中濃縮了數百小時的開發時間。應用別人的經驗來加強您的執行將是一個不錯的選擇。
ClearQuest 和 Crystal Reports 之間的關係有時將會使該工具的初始配置變得混淆，對於新人來說尤其如此。最簡單的解釋就是，在其當前形式下，每一個客戶端的所有用戶都能夠運行報告。該報告是報告格式和定義需求的結合體。然而，問題在於細節，並不是每一個客戶端都能夠製作 Report Formats。
只有用於 Windows 的 ClearQuest 客戶端，並且在其系統中加載了 Crystal Reports 的支持版本，才能夠創建出生成報告所需要的 Report Formats。由於 Crystal Reports 是一個單獨的應用程序（需要額外的許可證費用和額外的產品安裝），所以經常有人向管理員出售 Crystal Reports 許可證，並且爲 Report Formats 建立一個“票據交換所”。
這種事情您應該避免。只需不到 600 美元，您就能購買到 Crystal Reports 的一個副本。對於機構來說，一個更有利的情景就是“培訓和培訓者”模型。ClearQuest 管理員培訓不同項目團隊中的核心成員，這些成員購買 Crystal Reports 並且在其系統上裝載了 ClearQuest Windows 客戶端。這樣一來，ClearQuest 管理員將有能力使得團隊使用任何滿足其需要的方式，利用儲存在 ClearQuest 中的數據來生成報告。
這或許聽起來像是一個技術之外、無關痛癢的話題然而，這正是許多新的 ClearQuest 設計者經常掉進的一個陷阱。
當使用 ClearQuest Designer 的時候，選擇一個操作，經驗欠缺的開發者往往會添加一個用戶羣到操作中。假定該操作是 Approve。您或許創建了一個名爲 Java_Project_Approvers 的用戶組，並向其中添加了三位管理者。然後您將那個 Java_Project_Approvers 用戶組連接到 Group Permission，在圖表中核查，並且更新數據庫。
一週以後，C# 項目發送了一封電子郵件，要求他們的管理團隊獲得 Approve 操作同樣地約束。於是您必須重複所有的步驟；即連接 C#_Project_Approvers 用戶組到 Group Permission，在圖表中核查，並且更新數據庫。
更好的方法是創建一個名爲 Approvers 的“頂級”用戶組。。然後，根據需要添加單獨的、特定項目的用戶羣，作爲與該操作相關聯的子用戶羣。
在我們的例子中，我們創建一個名爲 Approvers 的“頂級”用戶羣，它有兩個子羣，分別叫做 Java_Project_Approvers 和 C#_Project_Approvers。然後，當 C++ 用戶羣在第二週時再次申請時，您就能夠不用再進行在圖表中核查、添加用戶羣和更新圖表的工作了。Group Permissions 的管理現在僅僅是一個用戶和用戶羣的管理功能了。
通過連接被稱作 Approvers 的高級別用戶羣的約束，向約束中添加額外的用戶或者用戶羣僅僅需要您在用戶管理工具中修改 Approvers 用戶羣的成員，而不是修改圖表和更新數據庫（請見圖2）。這一過程幫助我們避免了頻繁地更新圖表和數據庫所產生的大量的推理。 ![通過同高級別的羣體聯合行動，您能夠將“團隊特定的”子羣體添加到行動中，而且不需要對計劃做出改變]()
圖 2: 通過同高級別的羣體聯合行動，您能夠將“團隊特定的”子羣體添加到行動中，而且不需要對計劃做出改變
由於 ClearQuest 的強大功能和簡單易用，經驗並不豐富的設計者頻繁的試圖過度改造 ClearQuest 的電子郵件規則功能性。我曾經遇到過一個超過 100 條電子郵件規則記錄的配置，其中 90% 都是基於查詢的。這樣做不僅產生了大量的電子郵件，而且會動態的影響任何操作的執行。
由於基於查詢的電子郵件規則都是基於主要的 Defect 記錄的，每一次進行操作，這 90 多條規則就將決定該查詢條件是否曾經被滿足過。無疑，客戶端將會非常疑惑爲什麼在點擊 Apply 按鈕後需要等待這麼長時間才能得到 ClearQuest 的迴應，完成修改記錄的操作。
對於新近配置 ClearQuest 的機構，我的建議是制定在 ClearQuest 以及 State 和 Action 工作流中將要跟蹤的角色，並且決定在過程中需要佈告的重要階段何時發生。經驗欠缺的 ClearQuest 用戶試圖在每一次狀態變更時發送提交佈告。Submitter 域在提交時期被填滿，將 Submitter 參考域添加到 CC 中非常簡單：讓電子郵件規則排隊。
然而，容易完成並不意味着就應該完成。想一想個體所提交的缺陷將收到多少非 ClearQuest 的電子郵件規則。使用一個基本的 Defect 工作流，他們就有可能收到 6 至 7 封基於狀態變更的電子郵件。將您自己置身於提交者的位置，您應該能夠就能夠快速的將佈告降至兩至三個動作。
對於提交者來說，最明顯的佈告就是提交動作。這將影響到檢驗他們的缺陷已經進入到系統中，爲他們提供一個系統爲該缺陷指派的 ID，並讓他們有機會回顧一下他們所提交的細節，開發團隊將會使用它來分析該缺陷。一旦缺陷被提交，您可以選擇再一次通知提交者（僅僅是提交者）通過或者終止該缺陷。這樣的話，當該缺陷被成功解決之後，提交者將被告知他們的請求正在被處理（或者被拒絕，或者標記爲副本，等等）。
基於這些“里程碑”狀態變更的電子郵件通知將爲提交者提供價值。持續不變的電子郵件通知，比如缺陷被開發人員指派或者打開、或者記錄被升級，將會被提交者當作“背景噪聲”，甚至是垃圾郵件。
應當仔細的思考和計劃，從而確保在整個 Defect 週期中所有收到通知的活動者都能通過電子郵件收到相關的細節的同時，最小限度的向那些已經被淹沒在要求他們詳審的電子郵件中的用戶發送通知。
新的甚至是有一定經驗的 ClearQuest 設計人員可能被 API Guide 中所略述的，利用一個操作的通知特性直接在 ClearQuest 的圖表內部執行電子郵件通知這一功能所困惑。
經常有人嘗試使用內部的基於 hook 的電子郵件規則，並且繞過電子郵件包和相應的電子郵件規則所提供的“即時可用”的通知功能。這是典型的“三思而後行”，因爲執行基於 hook 的電子郵件規則反映了您的 ClearQuest 實施的複雜性中的重要跳躍。
有一種情況是，與我一起工作的客戶端想要一封電子郵件，其內容是定製的，而不是“即時可用”的包可以完成的。由於用戶要提交變更要求，所以他們想要發送給用戶一封措辭更好的電子郵件。比如 “親愛的 <提交者姓名>, 您的請求號 <ID 號碼> 已經被收到。您的請求將被好好處理。如果需要額外信息的話，會有一名團隊成員與您取得聯繫。謝謝您使用 Acme ClearQuest Change Management 系統”。
在這個例子中，對於那些“即時可用”的通知所提供的被稱之爲 “祕密的” 格式沒有其他選擇，基於 hook 的規則被使用。
然而，這個例子是該規則的一個例外。在大多數情況下，基於 hook 的電子郵件規則同基於電子郵件規則包的規則的目的是一樣的。基於 hook 的規則的靈活性（以及更新規則所要求的煩人的圖表變更）應當同前面所提的“即時可用”的電子郵件規則包的易用性相比較。（請見圖3） ![爲基於代碼郵件的定製]()
圖 3: 基於 hook 的電子郵件能夠通過功能強大的 ClearQuest API 被定製。
現在比較一下，哪一個能夠不費力的將域添加到一個無狀態的電子郵件規則記錄中。簡單的方法允許您將一個電子郵件規則記錄設置爲活動的或者非活動的。每一種對於基於 hook 的規則的簡單變更都將需要描述圖表和更新用戶數據庫。如果您從另外一個設計者那裏 “繼承了” 圖表，並且對您的前任所編寫的 hook 並不熟悉的話，您就會增加一個額外的複雜級別。
這幾年來，我經常遇到這樣的情況：一些 IBM Rational FAQ 引發新手犯錯誤。經驗欠缺的 ClearQuest Administrators 將會在以下兩種情景下開始配置 ClearQuest：
- “我們對於每一個項目都將從用戶數據庫起步。如果管理層決定將這些數據庫同一個企業級用戶數據庫（基於報告或者數據管理方面的原因）結合起來將會有價值的話，那麼我們就會將它們結合起來。”
或者
- “我們對於所有項目都將從同一個用戶數據庫起步。如果該項目要求特定的定製，或者該數據庫變得太笨拙了，那麼我們就創建一個爲項目定做的用戶數據庫，並且從用戶數據庫中引入相應的數據。”
這兩種理由充分的選項都是基於同一件事：在不同的 ClearQuest 用戶數據庫之間可以輕易的移動數據。如果瞭解到該過程有時會提出挑戰的話，您就會爲您的機構設定一個更加合理的預期。
使用所提供的 ClearQuest Import 和 Export 功能，您就肯定可以從一個用戶數據庫導出數據（即使是基於一個查詢），並且將其導入到另一個用戶數據庫中（即使這些用戶數據庫是基於不同的圖表的）。只要在源和目的數據庫中都支持您所要求的源和目的域，該導入工具就將支持它。
然而，和許多情形中所出現的情況一樣，細節最令人頭疼。如果您擁有一個多行的域——例如 Description （請見圖4）——多行字符串中的每一個回車符都扮演了一個記錄分隔符的角色，這就意味着源數據庫中所呈現的域的格式最終和目的數據庫中的不一樣。 ![使用導入嚮導可以很容易的完成映射]()
圖 4: 使用導入嚮導可以很容易的完成映射。允許數據被導入所要求的格式需要計劃和測試。
請記住，由於記錄 ID 是系統創建的域，所以無法在用戶數據庫之間移植 ID。爲了緩解這一矛盾，您可以創建一個新的域，例如可將其稱作 old_id，並且從源用戶數據庫中將原來的 ID 導入到目的數據庫中，同時將所有相關的信息也一併導入。參考信息域同樣需要在不同數據庫之間加以區別。如果我的登錄 ID 在源數據庫中是 giliod 而在目的數據庫中是 dg1111，那麼諸如擁有者和提交者之類的參考信息域就將變得沒有意義了。
在不同的用戶數據庫之間移植數據當然是可以做到的，但是做起來會很痛苦。最好事先與出資方就數據的限制和變更問題進行溝通（您的 Notes_Log 域此刻看起來毫無用處），並且執行若干數據導入的試驗來確保您擁有所有獲得一個可以接受的結果的格式變更的文檔。
IBM Rational Unified Process® (RUP®) 聲稱，“Tool Specialist” 的角色就是負責在項目中支持工具，包括選擇和獲得工具；配置和設置工具；以及檢驗工具的工作。實際上，ClearQuest 管理員就是在變更管理系統中扮演了 Tool Specialist 的角色。
在大多數情況下，服務於一個複雜的變更管理系統的企業級配置的機構，最希望擁有設計和貢獻該進程的利益相關者，該過程應當在工具中被反映出來。無論是不是一個正式的過程團隊，Project Management Office 或者 Quality Assurance 部門，都經常有各種將同變更管理系統發生交互的用戶。
您應當避免嘗試設計或者重新設計您的變更管理過程；相反，您應當用該工具執行您預先定義的過程。我所見過的最好的方法，就是您按照配置其他業務應用程序的方式來配置 ClearQuest。對該應用程序的需求將從業務利益相關者流到執行操作的開發團隊。
我在若干場合所採用的一種有趣的方式是，實際利用 IBM Rational Suite 來配置 IBM 工具。在 RequisitePro 中將您的缺陷和增強要求集中起來。使用一個基於企業級圖表的用戶數據庫來創建 Enhancement Requests，並且對系統的缺陷加以記錄。這樣的話，您就成爲過程機構中的一員，並且任何使其進入 ClearQuest 的需求都被記錄在 RequisitePro 中。
即使在一個不太正式的環境中，一個包含業務利益相關者的需求的 Excel 電子數據表也能夠滿足我們的要求。它提供了兩個好處：一方面提供了您作爲 ClearQuest 管理員所期望的清晰的方向，另一方面當“爲什麼當您轉移到 Approved 狀態時需要 Owner 域？”這一不可迴避的問題提出時，它提供了到接合需求的回溯。通過記錄完整的需求，您能夠提供答案：“這是由 SOX 依從團隊指定的需求，對於他們的報告來說需要這些數據。”
我的十項提示的最後一項是：伴隨頻繁的圖表變更而來的繼承的問題。一位新手 ClearQuest 管理員也許在更新一個用戶數據庫到新的圖表版本時（請見圖5），不會理會彈出的提示窗口。該窗口中顯示：“該操作不能被撤銷。請確認您已經備份了圖表倉庫和用戶數據庫。是否繼續？” ![請回答“是”，因爲如果您沒有準備好的話，那麼您的 ClearQuest 的實施將面臨潛在的災難]()
圖 5: 請回答“是”，因爲如果您沒有準備好的話，那麼您的 ClearQuest 的實施將面臨潛在的災難。
經驗豐富的 ClearQuest 管理員每當網絡在用戶數據庫升級期間出現“小故障”時都會被召回數次，也許是因爲丟失了設計者客戶端和數據庫服務器之間的連接，或者是因爲在升級期間他們的 Windows 系統出現“藍屏”。他們還會被迫尋找一名數據庫管理員，要求他將圖表和用戶數據庫恢復到其升級之前的狀態。
一種可行的解決方案是使用 ClearQuest Designer 所提供的 Test Database 功能。然而，這可能像是一位拉緊繩索的行人在沒有網的情況下工作。如果出現任何問題，您就像是步履蹣跚的高高走在沒有安全網保護的中心環之上，因爲該方法掩蓋了一個關鍵的概念。如果您將您的當前生產圖表同一個測試數據庫連接起來，對圖表進行變更並且將其應用到測試數據庫中，您就將在其被用於生產環境的同時編輯您的生產圖表。
這同當賽車繞圈行駛在賽道上時變換其輪胎的情景十分相似。當更新一個數據庫時，您將收到如圖5所示的警告消息。您可能會問：如果在升級時出現圖表“不一致狀態”的問題會怎麼樣？我的生產用戶數據庫沒有問題，它僅僅影響我的測試數據庫，不是麼？最好的答案就是：永遠不會。由於圖表和用戶數據庫之間的複雜關係，圖表的變壞——無論您在升級（測試與否）哪一個用戶數據庫——都可能要求圖表的恢復，這又將要求所有相連接的數據庫（包括生產數據）的恢復來保持一致性。
除了修改生產圖表所帶來的問題之外，如果您的圖表利用了動態列表或者無狀態列表，那麼您也許還要花費大量的時間用於在生產服務器上重新下載數據到一個新創建的空的測試數據庫。如果您的圖表異常複雜的話，您將到達一個更高層的上限，而且 Microsoft Access 將不再是一個快速創建測試數據庫的選項。
一種行之有效的方法是，利用 ClearQuest 所提供的命令行指令 “installutil” 來創建您將會修訂的圖表和用戶數據庫的備份。軟件開發人員通常將他們的開發努力隔離在不同的物理系統或者實例（開發、系統測試、用戶容忍測試）上，同樣地，該方法允許您在隔離狀態下開發您的 ClearQuest 圖表變更。
一旦圖表變更被驗證，您就能夠使用 “cqload” 命令導出圖表的修訂版本，並且執行一個受控的導入到生產中。這樣，您就能夠以環境中其他任何生產系統相同的控制級別來計劃升級操作。您可以聯繫您的數據庫管理員，要求一個備份，通告您的用戶中斷操作的消息，並且生產發佈提示那些可能會受到影響的終端用戶關於變更的詳細信息。
通過使用該方法來更新 ClearQuest 圖表（以及相關聯的用戶數據庫），當您採取這一措施來更新數據庫並且收到令人不安的警告消息的時候，請不必擔心，您將擁有一套十五分鐘前的安全備份，而且在一些無法預料的事件擾亂升級操作時，您只需請求 Database Administrator 來恢復圖表和用戶數據庫的備份即可。
學習
討論
| 
