通過使用指標提高 CLM 報告的價值

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. 顯示量度和維度一個指 標的結構