Improving the value of CLM reports by using indicators

The Rational solution for Collaborative Lifecycle Management (CLM) is a seamless set of integrated applications that serve as a platform to manage the full lifecycle of your development project. When you create reports through CLM in the Data Warehouse, you can use the application and lifecycle data that your team has created in collaboration with their projects.

Although CLM contains more than 200 sample reports, plus the IBM Rational Reporting for Development Intelligence component (hereafter referred to as "rational Reporting") or IBM Rational I Nsight performance measurement and management software, but it still provides some powerful reporting design tools to customize CLM samples and create your own reports. By using these tools, you can access the data in the Data warehouse, which can be divided into two broad categories: operational data (ODS) and metrics. There are some detailed guidance materials available on how to create an ODS report, so this article will delve into the metrics available and how to use them. The focus of this article is not on creating experience, because a new set of video tutorials has been introduced. This article is intended to answer some common questions about metrics and CLM:

What metrics are available from a product-independent warehouse that can be recommended for CLM applications?

What is the use of measurement and dimensions of metrics in CLM terminology, and where does the data come from?

What metrics are available through CLM data collection jobs, and which require Rational Insight data Manager?

Background knowledge

If you have not been exposed to warehouse metrics so far, you may find it common to see these problems when you create reports for CLM. The main reason is that the warehouse used by CLM follows the same pattern as the Rational Insight. This pattern is designed to provide a product-independent development data representation so that all rational software and external products integrated with rational software can be used. In addition to the schema, we provide a common Core Reporting data model that allows end users to access warehouse data using the user-friendly localized names in the report design tool. This reporting data model defines its own product-independent terminology that does not have to match the terms of the application, because different applications may use different terms for similar things. In addition, not all applications will populate all warehouse tables in the same way, because each application stores different data, even if they operate within the same domain.

For example, when using IBM Rational Requirements Composer, IBM Rational DOORS, or IBM rational RequisitePro, different information, such as requirements attributes, is found in this warehouse. For example, change and configuration management (CCM) applications from CLM the work items of IBM Rational Team concert are represented in the same warehouse table called Requests, which is hosted in the IBM Rational ClearQuest Change the request. These two types of applications are highly customizable, so each application can use some data columns in different ways.

However, there is usually a very large common data intersection. You can use this intersection to create common reports that can display data from all applications based on data from this warehouse. For example, IBM rational Quality Manager, an CLM-oriented QM application, integrates with all of these requirements management applications, and all of the sample reports provided by Rational Quality Manager can display any He Lian received the requirement data for the test artifacts. If you use more than one of these requirements applications, you can even display their combinations.

Warehouses can also grow with your integration needs. At the beginning, you may have only used CLM and rational Reporting, and then you will add more Rational or external applications. As mentioned earlier, the CLM warehouse uses the same core warehouse model and Reporting Data model as the Rational Insight. (The Insight and CLM also have some proprietary patterns that fit well with the scenario described here). Rational Reporting currently supports only three CLM applications, but by switching to the Rational Insight, you can expand existing CLM warehouses into enterprise-class warehouses, as well as store warehouses from other application data, such as the former The applications mentioned in the face paragraph. In addition to the fact that CLM can support data from applications, the Rational Insight provides more sample metrics than CLM. CLM provides data for a subset of these metrics, and this article describes what additional metrics are available when using the Rational Insight.

Let's summarize this background discussion: The advantage of report creators is that their reports can handle data from different applications. The challenge, however, is to Reporting the terminology used in the data model and how to know which items in this Reporting data model are populated by CLM or any other application. This is true for operational data and metrics. For operational data, you can find detailed documentation in the Rational Software Information Center: Reporting > Reference information for Reporting > Reporting data Dictionaries. For indicators, we provide the article.

Advantages and risks of using indicators

As mentioned earlier, there are two types of data in the warehouse:

Operational data (ODS represents the operational data Store), typically used for a list of similar queries, to display representations of raw application data in a warehouse, such as a list of test cases and their attributes.

Metrics, which typically provide an analytic view of the data. In other words, they represent processed data that can be aggregated into metrics by using ODS data as input and based on some of its interpretations. A metric is usually a count of data items, such as the number of requests or the number of test execution results. They can also summarize the total number of numeric data, such as the total number of ownership points of the test case execution record. To limit these metrics, you can collect them for a number of dimensions. You can use these dimensions to quickly get the specific number you are looking for.

Figure 1 shows how to represent such an indicator structurally in the reporting development tool. You can see a Request metric that measures failures (such as Actual Work and Total Requests), indicated by a ruler icon, and dimensions, such as Category or Date, indicated by an axis icon. When you create a report, you basically drag the report from the tree into a reporting component, such as a chart. For example, if you use these dimensions for an indicator, you might want to filter the number of all requests that belong to Project X that are of type Defect, open, and have not yet been specified by the owner (as shown in Resource in Figure 1). Therefore, the project, type, state, and owner form the dimension of a request metric and have the requested metric. You can then call an indicator application with a set of dimensions as a report that shows "the number of open defects without owners."

Figure 1. Structure of an indicator that shows metrics and dimensions