Rational solution for Collaborative Lifecycle Management (CLM) 是一組無縫集成的應用程序，可用 於充當管理您的開發項目完整生命周期的平台。當您在數據倉庫中通過 CLM 創建報告時，可使用您的 團隊為各自項目協同創建的應用程序和生命周期數據。
盡管 CLM 包含 200 多個樣本報告，外加 IBM Rational Reporting for Development Intelligence 組件（後面簡稱為 “Rational Reporting”）或 IBM Rational Insight 性能測量和管理軟件，但它仍然提供了一些功能強大的報告設計工具來定制 CLM 樣本和 創建自己的報告。通過使用這些工具，您就可以訪問數據倉庫中的數據，這些數據可分成兩大類：操作數據（ ODS）和指標。關於如何創建 ODS 報告，已經有一些詳細的指導性資料可供使用，因此本文將深入研究可用的 指標以及如何使用它們。本文的重點不是介紹創造經驗，因為已經有一組新的視頻教程對此進行介紹了。本文 旨在回答一些有關指標和 CLM 的常見問題：
獨立於產品的倉庫提供的哪些指標可推薦用於 CLM 應用程序？
指標的測量和維度在 CLM 術語中有何用途，數據從何而來？
哪些指標是通過 CLM 數據收集作業來提供的，哪些需要 Rational Insight Data Manager？
背景知識
如果到目前為止您還沒有接觸過倉庫指標，那麼您可能會奇怪常見在為 CLM 創建報告時 會出現這些問題。主要原因是 CLM 使用的倉庫遵循了與 Rational Insight 相同的模式。這種模式被設計用 於提供一個獨立於產品的開發數據表示，以便所有 Rational 軟件以及與 Rational 軟件集成在一起的外部產 品都可以使用它。除了模式之外，我們還提供一個共同的核心 Reporting Data Model，該模型可以讓最終用 戶使用報表設計工具中的用戶友好的本地化名稱來訪問倉庫數據。這個報告數據模型定義了屬於它自己的與產 品無關的術語，這些術語不必與應用程序的術語相匹配，因為不同的應用程序可能對類似的東西使用不同的術 語。此外，並非所有應用程序都會采用相同的方式來填充所有的倉庫表，因為每個應用程序會存儲不同的數據 ，即使它們在相同的域內操作。
比如，在使用 IBM Rational Requirements Composer、IBM Rational DOORS 或 IBM Rational RequisitePro 時，會在此倉庫中找到不同的信息，比如需求屬性。 又比如，來自 CLM 的變更和配置管理 (CCM) 應用程序 IBM Rational Team Concert 的工作條目是在同一 個稱為 Requests 的倉庫表中表示的，作為在 IBM Rational ClearQuest 中托管的更改請求。這兩類應用 程序是高度可定制的，因此，每個應用程序可以采用不同的方式使用某些數據列。
不過，通常還會有 一個非常大的常見數據交集。可以根據來自這個倉庫的數據，使用這個交集創建以一些能夠顯示來自所有應用 程序的數據的常見報告。例如，IBM Rational Quality Manager 這個面向 CLM 的 QM 應用程序能夠與上述 所有的需求管理應用程序集成，而 Rational Quality Manager 提供的所有示例報表都能夠顯示來自這些應用 程序的任何連接到測試工件的需求數據。如果使用了多個這樣的需求應用程序，您甚至可以顯示它們的組合。
倉庫還可以隨著您的集成需求而增長。開始時，您可能只使用了 CLM 和 Rational Reporting，之後 ，會添加更多的 Rational 或外部應用程序。正如前面提到的，CLM 倉庫使用了相同的核心倉庫模式和 Reporting Data Model 作為 Rational Insight。（Insight 和 CLM 也有一些私有模式，它們也能很好地符 合這裡描述的場景）。Rational Reporting 目前只支持三個 CLM 應用程序，但通過切換到 Rational Insight，您可以將現有的 CLM 倉庫擴大成為企業級的倉庫，還能存儲來自其他應用程序數據的倉庫，比如前 面段落中提到的那些應用程序。除了不同於 CLM 能夠支持來自應用程序的數據之外，Rational Insight 還提 供了比 CLM 更多的樣本指標。CLM 為這些指標的一個子集提供了數據，本文將介紹在使用 Rational Insight 時可獲得哪些額外的指標。
我們來總結一下這個背景討論：報告創建者的優勢在於他們的報告可以處 理來自不同應用程序的數據。但面臨的挑戰是 Reporting Data Model 所使用的術語，以及如何知道此 Reporting Data Model 的哪些項是由 CLM 或任何其他應用程序填充的。對於操作數據和指標都是如此。對於 操作數據，可以在 Rational 軟件信息中心找到詳盡的文檔：Reporting > Reference information for reporting > Reporting data dictionaries。對於指標，我們提供了本文。
使用指標的優勢和風 險
正如前面提到的，倉庫中有兩類數據：
操作數據（ODS 代表的是 Operational Data Store），通常用於類似查詢的列表報告，能夠顯示倉庫中的 原始應用程序數據的表示，比如測試用例的列表及其屬性。
指標，通常提供數據的分析視圖。換句話說，它們代表的是已處理完的數據，通過將 ODS 數據作為輸入， 並基於它的某些解釋，可以將此數據聚集成為量度。量度 通常是數據項的計數，比如請求的數量或測試執行 結果的數量。它們也可以匯總數值型數據的總數，比如測試用例執行記錄的所有權重分的總數。要限制這些量 度，可以對應於若干維度 收集它們。可以使用這些維度來快速獲得所尋找的特定數字。
圖 1 顯示了在報告開發工具中如何從結構上表示這樣一個指標。您可以看到一個 Request 指標度量故障 （比如 Actual Work 和 Total Requests），由直尺圖標指示；以及維度，（比如 Category 或 Date），由 軸圖標指示。在您創建報告時，基本上是將報告從這個樹拖入一個報告組件中，比如一個圖表。例如，如果對 某個指標使用這些維度，可能是想在其中過濾歸 Project X 所有的、類型為 Defect、處於開放狀態且尚未指 定所有者（如圖 1 中的 Resource 所示）的所有請求的數量。因此，項目、類型、狀態和所有者就構成了一 個 Request 指標的維度，並且有了請求的度量數。之後就可以將這樣一個具有一組維度的指標應用程序稱為 一個報告，這個報告能顯示出 “沒有所有者的開放性缺陷的數量”。
圖 1. 顯示量度和維度的一個指 標的結構
指標會定期收集。在使用 CLM 的情 況下，是每天收集指標，所以它們不僅可以提供數據的最近視圖，還可提供隨時間變化的趨勢。以前面所述的 "沒有所有者的開放性缺陷" 為例，收集到的關於此量度的趨勢信息使您能夠使用 Date 維度在報 告中放上一個圖表，顯示隨時間推移產生的無主缺陷的數量。因此，您可以提供有關一致性的信息，但傳入的 缺陷由所有者負責。
目前，這一指標以及顯示它的那些報告的解釋和有用性高度依賴於您的開發進程 。如果您的進程的價值在於一直將缺陷分配給所有者，鼓勵所有者立即修復，那麼與您的團隊相比，這個報告 更有用一些，您的團隊僅在每次分配間隙處理缺陷時從排名的積壓缺陷中選擇缺陷。那些閱讀該報告的人還需 要知道，該報告只是顯示了開放缺陷的趨勢，並沒有顯示傳入的新缺陷的比率，以及分配這些缺陷所需的時間 。所以您可能需要使用多個指標來支持您的開發進程目標。
正如前面已經提到的，指標的使用和有用 性高度依賴於您的開發進程，CLM 應用程序包含的指標可能是特定於進程的，也可能相當普通，所以，它們適 用於許多情況。CLM 解決方案和 Rational Insight 中的可用指標的創造者選擇了後一種方法。指標對進程的 依賴性也同樣適用於指標的定義。在上面的示例中，進程改變了什麼內容才會構成一個缺陷。例如，在 Rational Team Concert 中，一個提供此處的輸入對請求進行計數的進程可能會定義完全不同類型的工作項， 其中對 Defect 的映射可能會很困難。在最簡單的情況下，缺陷被稱為 bug，而在另一種情況下，工作項的類 型可以是通用的，如 Change Request，因此不能立即區分缺陷與增強請求。此外，Open 狀態的概念在每一個 進程中也可能不同，因為 Rational Team Concert 中的工作項的工作流或 Rational ClearQuest 內的請求可 以全部是用戶定義的。鑒於貢獻於倉庫的每個項目都可以使用不同的進程，因此設計一個能夠提供適用於任何 類型進程的有用指標的倉庫是一項艱巨的挑戰。作為指標的用戶，需要根據以下這些標准評估每個指標：
使用了來自為該域提供數據的每個應用程序的哪些數據？
使用哪個開發進程和應用程序定制來創建數據，這對於指標意味著什麼？
使用哪個進程來解釋和使用這些指標？
開始使用指標
通過選擇一個量度和幾個維度，然後再將其應用到報表設計工具內的各種報告組件， 如圖表或交叉選項卡，就可以編寫使用指標的報告。此外，還可定義提示，以提醒您輸入維度上的過濾器值。 在前面的示例中，它可以是要使用的特定狀態（這就消除上述提到的如何定義 Open 含義的問題）、要關注的 項目等。由於眾所周知的眼見為實耳聽為虛，我們於是准備了幾個演示視頻，講解了報告編寫的步驟。因此， 如果您還沒有在 YouTube 看到過這些視頻，那麼請先停下來觀看這些視頻，然後再回到這裡：
"Introduction to IBM Rational RRDI v2.0 Report Authoring"
"Using the IBM Cognos Query Studio v10.1 User Interface and Data Package"
"Build a list report in Cognos Query Studio v10.1"
"Build a Crosstab and Chart in IBM Cognos Query Studio v10.1"
[Intermission]
歡迎回來！標題為 "Build a Crosstab and Chart in IBM Cognos Query Studio v10.1" 的視頻向您展示了如何通過使用一個計算測試執行結果數量的指標編寫一個交叉選項卡 和柱狀圖報告。它使用了 Query Studio 工具，允許拖入查詢項並立即運行當前報告。
為了開始您自 己對可用指標的探索，我們建議您使用相同的工具開始嘗試。利用接下來的幾個章節，您可以通過使用您有興 趣用於您自己數據的指標創建類似的報告 。在用您自己的數據探索指標的同時，您最好是判斷一下每個指標 如何能很好地適合於您的開發進程以及您的應用程序設置內有哪些數據可用。
CLM 指標概述
以 下章節提供了一些關鍵指標的概述，我們認為這些指標為一系列有趣的場景提供了用於 CLM 解決方案的相關 數據。在 Rational Reporting 和 Rational Insight 報表設計工具中，指標是由 Reporting Data Model 展 示在一個樹浏覽器視圖中，並按照域進行了分組：
Change Management
Configuration Management
Project Management
Quality Management
Requirement Management
圖 2. 指標按照域進行了分組
這種映射有時可能無法滿足您的期 望，因為許多指標使用的數據來自多個域。定位一個指標的經驗規則是：用於此指標量度的數據來自該域。例 如，"Request Metrics with Test Plan" 主要用於 Quality Management 報告。但是，因為它提 供了請求的測量（對具體測試計劃的測試期間發行的缺陷進行計數），所以會將它放置在 Change Management 組中。
以下章節將討論除 CLM 未曾使用的 Project Management 之外的各種組。在 Configuration Management 組中，只有 Build 指標提供了與 CLM 有關的數據，但這裡不會對它們進行討論。
常見的 維度
在介紹各個指標之前，我們還是先來了解一下這些組中使用的所有常見維度吧。表 1 的焦點是維 度，其中來自 CLM 術語的映射並不明顯，或需要關注其他注意事項。此列表雖然詳盡，但不完整。
變更管理指標
變更管理指標 為您提供了與 Rational Team Concert 工作項相關的量度。可以將這些指標用於記分卡或柱形圖，提供有關 開放缺陷的計數，以及缺陷或任何類型的工作項的創建或關閉趨勢。圖 3 顯示了一個包含在 Rational Quality Manager 中的示例報告（數據來自我們自己使用的 Rational Team Concert 和 Rational Quality Manager，用於開發和測試這些產品）。
該報告使用了 Request Creation 和 Request Closure 指標 ，您可以在表 3 中查看有關這些指標的更詳細的記錄。這份報告比較了與遵循測試計劃的測試有關的傳入缺 陷和已解決缺陷的數量。您還可以使用這份報告來評估提前修復缺陷以及在測試過程中發現新缺陷的質量和團 隊效率，對它們進行比較。
圖 3. QM 示例報告：隨時間推移而傳入的缺陷和解決方法
下表展示了 CLM 可以使用的每個變更管理指標。對於每個指標，該表列出了可用於 CLM 數據的量度， 並給出了報告作者需要知道的所有細節。這些指標在 CLM 2011 和 2012 之間是不同的（分別為 IBM Rational Insight 1 0 1 1 和 1.1 和 Rational Insight 1.1.1），下面將對它們進行介紹。此表還告訴您 某個指標是否可用於 CLM Data Collection 作業，以及它是否需要安裝 IBM Rational Insight 及其數據管 理器 ETL。
質量管理指標
質量指標主要 是指測試執行結果和趨勢，但它們也涵蓋了其他一些區域，比如在某個項目的實驗室資產的使用或是測試實例 的狀態。圖 4 顯示了 Execution Trend，這是一個非常流行的包含在 Rational Quality Manager 中的樣本 報告，它使用了以下指標：
帶有迭代的 Execution Result Points 指標
帶有迭代的 Execution Work Item 指標
ODS 表，其中包含了能夠體現團隊的測試執行性能的計劃數據
圖 4 中的報告描繪了執行測試的點（點：一個能表示運行測試成果的指標），對比了每周的計劃點與完 成點。它展示了三對這樣的趨勢：
Planned，它是在測試計劃進度中估算點隨時間的分配。
Computed，它是對分配給第二個指標提供的計劃和裡程碑的每個測試用例執行記錄進行估算的點的總合 。
截至第一個指標提供的特定日期之前，這個團隊實際執行了哪些操作。
圖 4. Execution Trend 報告顯示一個團隊的預計性能與實際性能的對比
下表列出了所有可用 於 CLM 數據的指標，遵循與討論 CCM 指標同樣的模式。
需求管理指標
最後的這一節 將向您展示可用於 CLM 數據的需求指標。一般來說，Rational Requirements Composer 並不提供任何關於變 更和需求版本的數據。因此，目前沒有引用變更管理的量度。
結束語
本文向您全面介紹了在使用 Rational Reporting for Development Intelligence 或使用具有 CLM 的 Rational Insight 時可供您使用的相關指標，還了解了哪些指標可用，哪些指標因為所 需數據在 CLM 可報告的 REST API 中丟失而不可用。為了方便以後進行參考，本文還以表的形式列出了使用 CLM Data Collection 和 Rational Reporting 時可以使用哪些指標，以及哪些指標需要使用擴展的 Rational Insight ETL 來收集數據。
接下來，我們就會開始探索這些指標了。使用視頻中所示的 Query 或 Report Studio，並開始創建使用了本文所列指標的報告。嘗試使用各種維度過濾器
查看 CLM 自帶的 100 多個 Cognos 樣例報告，這對您很有幫助。它們使用指標的方式多種多樣。在 Report Studio 中打開這些報告，並試著理解用來構建它們的查詢。
