The Rational solution for Collaborative Lifecycle Management (CLM) is a set of seamlessly integrated applications that work together as one platform for managing the complete lifecycle of your development projects. The application and lifecycle data that your teams create collaboratively for their projects is provided to you for reporting by CLM in a data warehouse.
Although CLM applications include more than 200 sample reports, with the additional IBM® Rational® Reporting for Development Intelligence component ("Rational Reporting" hereafter) or with IBM® Rational® Insight performance measurement and management software, you have access to powerful report design tools for customizing CLM samples and creating your own reports. With these tools, you have access to the data in the warehouse, which is mainly grouped into two categories: operational data (ODS) and metrics. There is already detailed instructional material available for creating ODS reports (see citations 2, 3, and 4 in Resources), so this article gives you a more in-depth look at the metrics available and how to use them. It focuses less on the authoring experience, which is covered by a new set of video tutorials (citation 5 in Resources). Instead, this article answers these frequently asked questions about metrics and CLM:
- Which metrics provided by the product-independent warehouse are recommended for use with CLM applications?
- What do the metrics' measures and dimensions mean in CLM terms, and where does that data come from?
- Which metrics are provided through the CLM Data Collection jobs, and which require the Rational Insight Data Manager?
If you had no exposure to the warehouse metrics until now, you might wonder why these questions come up when authoring reports for CLM. The main reason is that the warehouse used by CLM follows the same schema that Rational Insight uses. This schema has been designed to provide a product-independent representation of development data so that it can be used with all Rational software, as well as external products that Rational software integrates with. In addition to the schema, we also provide a common core Reporting Data Model, which is the model that provides end users access to the warehouse data with user-friendly and localized names that you see in the report design tools. This Reporting Data Model defines its own product-independent terminology, which does not necessarily match your applications' terminology, because different applications use different terms for similar things. Moreover, not all warehouse tables are populated by all applications in the same way, because each application stores different data even if they operate in the same domain.
For example, you find different information in the warehouse, such as requirement attributes, when you use IBM® Rational® Requirements Composer, IBM® Rational® DOORS®, or IBM® Rational® RequisitePro®. Another example is that work items from CLM's change and configuration management (CCM) application, IBM® Rational Team Concert™, are represented in the same warehouse table, called Requests, as change requests that are managed in IBM® Rational® ClearQuest®. Both of those applications are highly customizable; therefore, some data columns can be used differently by each application.
However, there is also often a very large intersection of data that is common. This intersection can then be used for creating common reports that can show data from all apps together, based on the data from this one warehouse. For example, the IBM® Rational® Quality Manager, the QM application for CLM, integrates with all of the requirements management applications listed above, and all sample reports provided with Rational Quality Manager can show requirements data linked to test artifacts from any of these applications. You can even show a mix of these if you use more than one of these requirements applications.
The warehouse can also grow with your integration needs. You might start with CLM and Rational Reporting, and then later add more Rational or external applications to the mix. As mentioned before, the CLM warehouse uses the same core warehouse schema and Reporting Data Model as Rational Insight. (Insight and CLM have some private schemata as well, but these also fit nicely into the scenarios described here.) Rational Reporting currently supports only the three CLM applications, but by switching to Rational Insight, you can expand your existing CLM warehouse to become an enterprise-wide warehouse that also stores data from other applications, such as the ones mentioned in the previous paragraph. In addition to supporting data from applications other than CLM, Rational Insight provides more sample metrics than CLM does. See citation 6 in Resources for the Rational Insight overview of these metrics. CLM provides data for a subset of these metrics, and this article tells you which additional metrics you get when using Rational Insight.
To summarize this background discussion, the advantage for report authors is that their reports can work with the data from different applications. But the challenge is to map the terminology used by the Reporting Data Model, as well as to know which items of this Reporting Data Model are populated by CLM or any other application. This is true for operational data, as well as metrics. For operational data, you can find detailed documentation in the Rational software information center: Reporting > Reference information for reporting > Reporting data dictionaries. For metrics, we provide this article.
The benefits and risks of using metrics
As mentioned previously, there are two categories of data in the warehouse:
- Operational data (ODS stands for Operational Data Store), which is typically used for query-like list reports that show a representation of the raw application data in the warehouse, such as the list of test cases and their attributes.
- Metrics, which provide an analytics view of the data. In other words, they represent processed data by taking the ODS data as input and aggregating this data into measures, based on some interpretation of it. Measures are typically counts of data items, such as the number of requests, or the number of test execution results. They can also be aggregated sums of numeric data, such as the sum of all weight points of test case execution records. To qualify these measures, they are collected in relation to a number of dimensions. You can use these dimensions to get to the specific numbers that you are looking for quickly.
Figure 1 shows you how such a metric is represented structurally in the report development tools. You see a breakdown of the Request metrics into measures, indicated by the ruler icons, such as Actual Work and Total Requests, as well as dimensions, such as Category or Date, indicated by the axis icons. When you create reports, you basically drag and drop from this tree into a report component, such as a chart graph. You use the dimensions, for example, for a metric in which you might want to filter the Total Number of Requests to the ones that are owned by Project X, are of the Defect type, are in the Open state, and have no owner assigned (owner is referred to by the metrics as Resource in Figure 1). Hence, project, type, state, and owner would be dimensions of a Request metric, with the measure number of requests. You can then call the application of this metric with this set of dimensions a report that shows the "Number of open defects that have no owner."
Figure 1. The structure of a metric showing the measures and dimensions
Metrics are collected at regular intervals. In the CLM case, they are collected daily, so they provide not only the most recent view of the data but the trends over time. Using the previous "Number of open defects that have no owner" example, the collected trend information of this measure would then allow you to plot a graph in a report showing the number of defects with no owner over time, using the Date dimension. Therefore, you can provide information about the consistency in which incoming defects are triaged to owners.
The interpretation and usefulness of this metric and the reports that show it are now very much dependent on your development process. If your process values the consistent allocation of defects to owners to encourage immediate fixing, then this report is more useful than if your team just picks defects from a ranked backlog whenever they work on defects in allocated time slots. Those who read this report also need to understand that it shows only the trend of open defects, not the rate of incoming new defects nor the time it takes to assign them. So you might require multiple metrics to support the goals of your development process.
As already mentioned, the use and usefulness of metrics is highly dependent on your development process, and metrics included with a CLM application could be either very process-specific or fairly general, so that they work in many cases. The authors of the metrics available in the CLM solution and Rational Insight chose the latter approach. The dependency of the metrics against the process also holds true for the definition of the metrics. In the example above, the process might change what actually constitutes a defect. For example, a process in Rational Team Concert that provides the input here for counting requests might define completely different types of work items, where the mapping to Defect might be difficult. In the simplest case, defects might be called bugs or, in another case, the type of the work item might be generic, such as Change Request, so that it is not immediately possible to distinguish defects from enhancement requests. Moreover, the notion of the Open state could be different in each process, because the workflow of work items in Rational Team Concert or requests in Rational ClearQuest can be completely user-defined. Given that each project contributing to the warehouse might use a different process, designing a warehouse that provides useful metrics that work with any kind of process is a major challenge. As a user of metrics, you need to evaluate each metric in terms of these criteria:
- What data does it use from each application that provides data in that domain?
- Which development process and application customization were used to create the data, and what does that mean for the metric?
- Which process is used to interpret and use the metrics?
Getting started with metrics
You write reports that use metrics by selecting a measure and dimensions and then applying them to various report components in the report design tool, such as graphs or cross-tabs. You also define prompts that remind you to enter filter values on the dimensions. In the previous example, this could be the specific state to be used (which would eliminate the problem mentioned above of defining what Open means), the projects to focus on, and so on. Because it is generally well known that a picture tells more than thousand words and a video tells more than ten thousand words, we have prepared a couple of demonstration videos that walk you through the report-writing steps. Therefore, if you have not seen these videos on YouTube yet, please stop reading now, watch them, and return here afterward:
- "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"
Welcome back! The video titled "Build a Crosstab and Chart in IBM Cognos Query Studio v10.1" showed you how you can write a cross-tab and bar chart report by using a metric that counts test execution results. It used the Query Studio tool that allowed dragging in query items and immediately ran the current report.
To start your own exploration of the metrics available, we recommend that you use this same tool and begin experimenting. Using the sections that follow, you can start creating similar reports by using the metrics that you are interested in with your own data. While exploring the metrics with your own data, you can better judge how well each metric fits into your development process and what data you have available in your application setup.
A review of metrics for CLM
The following sections provide a review of key metrics that we think provide relevant data for use with the CLM solution for a range of interesting scenarios. In the Rational Reporting and Rational Insight report design tools, metrics are presented by the Reporting Data Model in a tree browser view that groups metrics by domain:
- Change Management
- Configuration Management
- Project Management
- Quality Management
- Requirement Management
Figure 2. Metrics are grouped by these domains
This mapping might not meet your expectations sometimes, because many metrics use data from more than one domain. The rule of thumb for locating a metric is that the data used for the metric's measures comes from that domain. For example, "Request Metrics with Test Plan" would be used primarily for Quality Management reports. However, because it provides measurements of requests (counting defects found during testing of specific test plans), it has been placed in the Change Management group.
The following sections review each of these groups except the Project Management one, which is not used by CLM. In the Configuration Management group, only the Build metrics provide data related to CLM, but those will not be discussed here either.
Before you review the individual metrics, however, go through the list of common dimensions as they are used throughout the groups. The focus of Table 1 is on dimensions where the mapping from CLM terminology is not obvious or where additional considerations are required. It is an exhaustive but not complete list.
Table 1. Common domains used by the metrics
|Dimension name||CLM data source||Use|
|Category||Work Item Category||In the Rational Team Concert UI for work items, it is shown as the File Against field.|
|Classification||(not applicable, N/A)||This dimension indicates the origin and type of data such as RTC Work Item (Rational Team Concert), RRC Requirement (Rational Requirements Composer), or RQM Execution Result (Rational Quality Manager). Therefore, it lets you distinguish requests coming from Rational Team Concert from the ones from Rational ClearQuest and distinguish requirements from Rational Requirements Composer from those in Rational RequisitePro, and so on.|
|Creator||Work Item Creator||The Creator role, meaning the user who created a work item, has been added to all Request metrics in the CLM 2012 release.|
|Date||(See comments)||If the word Date is in the name of the metric (Execution Result Date metrics, for example), the actual creation or change dates of the ODS data element mentioned in the metric name is used (the actual start date of the execution results). In rare cases, the word Date is not in the metrics name, but then the date dimension is actually called differently, such as Closure Date in the Request Closure metrics. In all other cases, the Date dimension represents the data collection date, meaning the date when the data was loaded into to the metric's fact table. Therefore, most metrics provide trend data over these collection dates, thus a snapshot of the data at the time of the daily data collection.|
|Iteration||Work Item Planned for Test Plan Phase (Iteration)||Depending on which metric you are using, this dimension refers either to the Planned For iteration for which a work item is to be resolved or the time period in which tests assigned to a test plan are to be executed within the plan's test schedule. Generally, if a metric has "with Test Plan" in the name, Iteration refers to the test plan schedule in CLM 2012. If such a metric provides measures on requests, the Iteration dimension indicates the test phase in which the request were created, or the phase in which defects were found during testing. In CLM 2011, these "with Test Plan" metrics were broken, and the Iteration dimension cannot be used here.|
|Project||Project Area||This dimension will reference the project area of the artifact for which the measures have been defined. For example, in Request Metrics with Test Plan option, Project will be the project area of the work items that populated the Request table, not the project area of the test plan.|
|Release||Work Item Found In||Release is populated with the work item's Found In information. The source of the values are defined as Releases for a Team Concert project area.|
|Request Priority||Work Item Priority||Represents priorities defined for work items. Each Rational Team Concert project area can potentially define its own set of priorities for its work item types, and all priorities are regarded as individually different. In other words, when you use this dimension, you might find many results for High, Medium, Unassigned, and so forth, because each project's priority will be grouped individually.|
|Request Severity||Work Item Severity||Represents the severities defined for work items on a project basis. The comments above about Priority apply.|
|Request Status||Work Item State Groups||States are grouped in Rational Team Concert into state groups. This makes work item states somewhat comparable across the individually customized states of each project. Therefore, this dimension should be used for state-based reports that show data from more than one Rational Team Concert project area.|
|Requirement||Requirement||Allows you to show measured data, such as execution results to be grouped by linked requirements. In CLM, requirements are linked to test cases and to test plans through collections, as well as so-called Implementation Requests, which are Stories in the Scrum process template.|
|Resource||User||Resource is the data warehouses name for user. Its usage is different, depending on the metric. In most cases, however, it represents the owner of the measured artifact, thus the owner of a work item. (See the Creator dimension, which is another dimension for users.) But here, the meaning is clear by the name.|
|State||Work Item State|
Test Case State
|State is the project area-specific state of artifacts. In CLM 2012, this dimension covers work item states in Request metrics and test cases in Test Case metrics.|
|Team||Team Area||This dimension represents team areas of the project area of the artifact that the measures are related to.|
|Test Case||Test Case||Allows you to show measured data, such as execution results to be grouped by linked test case.|
|Test Plan||Test Plan||Allows you to show measured data, such as execution results or defects (requests) to be grouped by linked test plans.|
|Type||Work Item Type|
|Represents the project area-specific work item or requirement type. If you want to write a report that measures Defect, you would define a filter here. But you need to be aware that every project area might have its own set of work item types, and it is possible that not all of those label defects as Defect.|
|Verdict||Execution Result Actual Result||This dimension represents the test result categories such as Passed, Failed, and Deferred that are available for Rational Quality Manager execution results. Although they are customizable on a per-project basis, the current implementation of the data collection assumes one set of values, because they are provided by the default process template for Rational Quality Manager projects.|
Table 2 shows dimensions that you would, perhaps, expect to provide data from CLM, but they do not. If you add them to your reports, you will typically get an empty result or the result will show "Info not Available." Therefore, these dimensions should not be used for CLM-specific reports.
Table 2. Domains that are not populated by CLM data
|Component||Not the SCM components from Rational Team Concert. Not used by CLM.|
|Fixed in Release||Does not provide values in CLM, because work items are resolved in iterations, and the link to the release is missing in the data provided by CLM to the data warehouse.|
|Platform||No information for platform is provided by CLM.|
|Product||This dimension does not provide data from CLM.|
|Project (by Portfolio)||This assumes the grouping of projects by portfolio. However, CLM does not use portfolios.|
Change management metrics
Change management metrics provide you with measures relevant to your Rational Team Concert work items. They can be used for scorecards or bar charts that give you counts on open defects, as well as for trends of the creation or closure of defects or work items of any type. Figure 3 shows a sample report that is included with Rational Quality Manager (with data from our own use of Rational Team Concert and Rational Quality Manager for development and testing of these products).
The report uses the Request Creation and the Request Closure metrics that you see documented further down in Table 3. This report compares the number of arriving and resolved defects linked to testing that follows a test plan. It can be used to evaluate the quality and team efficiency in being ahead of fixing defects compared to discovering new defects during testing.
Figure 3. QM sample report: Defect Arrival and Resolution Over Time
The following table reviews each of the Change Management metrics that can be used with CLM. For each metric, this table lists which measures work with CLM data and points out any specifics that report authors need to know. There were changes to these metrics between CLM 2011 and 2012 (IBM Rational Insight 220.127.116.11 and 1.1 and Rational Insight 1.1.1, respectively), and those are mentioned here. The table also tells you if a metric is available with CLM Data Collection jobs or if it requires the installation of IBM Rational Insight and its Data Manager ETL.
Table 3. Configuration and change management metrics that provide results with CLM data
|Metric name||Measures that use CLM data||Measures that do not work with CLM||Use||Requires Rational Insight ETL|
|Release Request Metrics||Total Request of Pre- Release,|
Total Request of Post Release
|Total Work||The two measures for pre- and post-release look at the time difference between the availability date of the release versus the creation of the work item to determine whether the request was found before or after the release. However, this metric has only a limited usefulness, because it looks only at dates and always considers all work items without boundaries of a project area, because work items are not associated with the release. Therefore, the sums of post-and pre-release will always be the same: the number of all work items in a project.||Yes|
|Release Request Turnaround Metrics||(All)||This metric follows the approach of the metric above, but it looks at specific statuses (see Status dimension above) and the time that work items stayed in these statuses. The measures provide information about the maximum, average and minimum days for a work item to move from Submit state to Resolve state pre- and post-release. The measurements include total number of requests, maximum, minimum, and total days requests spent before and after the release.||Yes|
|Request Aging Metrics [with Test Plan]||(All)||This metric provides information about the maximum, average and minimum days that requests spend in a particular state. It uses process-specific states, not the status, in this case.|
The "with Test Plan" variant of this metric adds the test plan dimension to the metric. That dimension is essential for testers to group work item (defect) measures with test plans. To address the needs of testers, the Iteration dimension here refers to the test plan schedule and the iterations defined in Rational Quality Manager; whereas, the other metric’s Iteration dimension refers to the Rational Team Concert iterations assigned to the work items as Planned For values.
|Request Closure Metrics |
[with Requirement][with Test Plan]
|Closure||This metrics provides information about the closure rate of requests. Closed refers in this case to the Closed work item group and not specific states with the name Closed. In other words, the measurement is total number of requests that are in the Status of Closed (see Table 1 for more details about the Status dimension). The Date dimension is used for this metric to express the actual date when request where moved to a state in the Closed state group. The metrics variants with Requirement and with Test Plan allow you to access the measure for a specific (set of) requirement or test plan. |
“Note: The Request Resolution metrics are not listed in this table, because they do not work for CLM as there is no work item state group called Resolved. States with the name Resolved are typically added to this Closed state group.
|No, for the base metrics|
Yes, for the two variant metrics
|Request Creation Metrics [with Requirement]|
[with Test Plan]
|Arrival||Actual or Planned Duration, Story Points||Similar to the closure metrics, this metric uses the Date dimension to count requests created by using the Arrival measure.||No, for the base and Test Plan variant|
yes, for the requirement variant
|Request Failure Metrics |
[with Requirement][with Test Plan]
|Total Requests||This metric will work with your CLM data if you have a work item type that is spelled Defect. Localized names will not work. For these requests, it counts the ones where Status was transitioned from Closed to Open (see Table 1 for more information on Status). The interpretation of this measure could be that these defects failed validation or re-testing and had to be reopened.||Yes|
|Request Metrics [with Requirement]|
[with Test Plan]
|Total Requests, Actual Work, Planned Work||Total Blocking Requests||This is a basic metric that counts requests (work items, for example) by using key dimensions, including variants that include linked test plans (to report on defects found during testing of a plan) or linked requirements. It also provides measures for actual and planned work, which can be used for iteration burndown charts that are based on the work items Estimate, Correction, and Time Spent fields. Divide the measure by 3600 to get to hours. The Blocking measure does not work with CLM, because it does not provide this information in the ODS Request table column, and the metric relies on that information.||No|
|Request Turnaround Metrics [with Test Plan]||(All)||This metric provides information about the maximum, average, and minimum days for a request (could be a defect related to a test plan when using the variant metric) to move from the Open status to Closed.||Yes|
|Story Metrics||Total Story Points, Total Comments, Total Subscribers||Total Tags||This metric provides various measures for work items for the type that is spelled Story. Localized names will not work. You need to use at least Rational Team Concert 18.104.22.168 or later for the metric to work. For these Story work items, you can then report on the total number of stories, the number of comments submitted against the story, and the number of subscribers. The Total Tags measure actually provides only the number of work items that have tags and does not count the number of tags assigned to work items.||Yes|
Quality management metrics
Quality metrics refer mainly to test execution results and trends, but they also cover areas such as the use of lab assets or the status of test case authoring within a project. Figure 4 shows the Execution Trend, a very popular sample report included with Rational Quality Manager that uses these metrics:
- The Execution Result Points metrics with the iteration
- The Execution Work Item metrics with the iteration
- ODS tables that contain plan data to show a team's test execution performance
The report in Figure 4 plots points for executed tests (points: a metric that allows expressing the effort of running tests), comparing attempted points to completed points for each week. It presents three pairs of these trends:
- Planned, which was an allocation of estimated points over time in the test plan schedule (see the "Building a Report in Rational Common Reporting" video cited in Resources).
- Computed, which is a summation of the points estimated for each test case execution record assigned to the plan and milestone provided by the second metric
- What the team actually executed by a certain date provided by the first metric.
Figure 4. Execution Trend report shows a teams estimated vs. actual test performance
The following table lists all metrics that can be used with CLM data, following the same schema as the CCM metrics discussion.
Table 4. QM metrics that provide results with CLM data
|Metric name||Measures that use CLM data||Measures that do not work with CLM||Use||Requires Rational Insight ETL|
|Execution Result Date Metrics||(all)||This metric provides a summary of execution results, using the result's actual start date for the Date dimension. Other execution result metrics populate the Date dimension with the data collection date and count all of the results available at that date. his metric counts results in relation to the actual start date of the execution, instead. Therefore, it counts only results started at that date. The measures provided reflect the individual execution result's verdicts, such as Attempted, Failed, or Deferred, as allocated by the tester, using the sliders in the execution result web UI.||No|
|Execution Result Metrics [with Iteration]||Total Execution Results||A simple metric that allows you to count the absolute number of execution results available at the time of collection. You can use the Verdict dimension to focus on specific results, such as Attempted or Failed. The "with Iteration" variant of the metric requires use of the Iteration dimension, which refers to a test phase in the schedule of a test plan.||No|
|Execution Result Point Metrics [with Iteration]||(All)||This is one of the metrics that is used for the Execution Trend report shown in Figure 4. It is used to provide the Actual values of the graph. It provides measures for performed execution points by verdict available at the time of the data collection. The iteration variant requires the use of the iteration dimension in the same way as discussed in the row above.||No|
|Execution Work Item Metrics [with Iteration]|
|Total Execution Work Items|
|This is the other metric used by the sample report of Figure 4. It is used to provide the Computed values. It provides measures that count the total number of test case execution work items available, as well as their total weight. Therefore, when using the Iteration variant of the metric, it can be used to access the number of execution work items and their specific sum of points allocated to a particular iteration. You can use the other variant, "with Requirement," to filter the metric with sets of specific requirements to write reports that show when requirements are planned for testing.||No|
|Job||Total Number of Job Results||This metric provides information about a job execution result based on a lab resource.||No|
|Lab Utilization Metrics||Total Number of Machines|
|This metric provides information about use of lab resources, based on their reservation date.||No|
|Test Case Metrics [with Iteration]|
|Total Test Cases||This is a simple metric that counts the total number of test cases. But with various dimensions, it can be used for reports that show the trends of the state of the test cases for specific test plan iterations, as well as considering linked requirements.||No|
Requirements management metrics
This final section walks you through the requirements metrics that work with CLM data. In general, Rational Requirements Composer does not provide any data about changes and requirements versions. Therefore, no measure that refers to changes works, currently.
Table 5. Requirements management metrics that provide results with CLM data
|Metric name||Measures that use CLM data||Measures that do not work with CLM||Use||Requires Rational Insight ETL|
|Child Requirements Metrics||Total Children Requirements||This metric counts the number of requirements that have a parent requirement.||Yes|
|Requirement Metrics [with Test Case]|
[with Test Plan]
|Total Requirements||Total Changes||These three metrics provide counts for the total number of requirements and requirements that are linked to test cases or test plans through requirements collections. The latter would also count requirements directly linked to test plans, but that is not supported by CLM's requirements management application, Other requirements management tools, such as RequisitePro, do use this relationship.|
Note: Several dimensions of these metrics might not work with your requirements management project, because all attributes in requirements management are custom-defined. Only if you have attributes such as Priority or Stability that are spelled exactly as the dimension names will they provide data for these metric dimensions.
|Requirement Traceability||This entry in the tree is actually not a metric, but you can use it to access various ways of requirements that trace to other CLM artifacts. As with the metrics and dimensions listed above, not all entries here are supported by CLM data. Traces to Activities, Customer, and Tasks are not available, because CLM does not cover those concepts.||No|
Conclusions and next steps
This article walked you through the relevant metrics available to you using Rational Reporting for Development Intelligence or Rational Insight with CLM. You also learned which parts of the metrics work, which parts do not because the required data is missing in CLM reportable REST APIs. For easy reference later, tables also listed which metrics are available when using CLM Data Collection and Rational Reporting and which metrics require the extended Rational Insight ETL for data collection.
As a next step, start exploring these metrics. Use Query or Report Studio as show in the videos (see the YouTube videos playlist, in Resources), and start creating reports that use the metrics listed in this article. Experiment with various dimension filters.
It will also be helpful to review the more than 100 Cognos sample reports that are included with CLM. They use most of these metrics in various ways. Open these reports in Report Studio and try to understand the queries that are used to build them.
I want to thank my colleague Ashish Apoorva for creating an early version of the Quality Management metrics review and Jun BJ Wang for feedback on those. Thanks to Amanda Brijpaul for feedback on the article and for recording the videos.
- Citations in this article:
- What's new in Rational Reporting for Development Intelligence 2.0
- CLM 2011 reporting workshop
- Building a report in Rational Common Reporting
- CLM Online Help Reporting Tutorials
- IBM Rational Reporting for Development Intelligence (RRDI), YouTube playlist
- IBM Rational Insight online help: Rational Insight sample metadata model
- IBM Rational CLM solution online help: Reporting data dictionaries
- For related information, see the Development intelligence with the CLM solution page on Jazz.net.
- For more information on Rational Insight performance measurement and management software, start with the Rational Insight page on developerWorks, which provides links to important related information, and check the product overview page. For detailed instructions, see the Rational Insight information center.
- Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
- Subscribe to the developerWorks weekly email newsletter, and choose the topics to follow. Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Improve your skills. Check the Rational training and certification catalog, which includes many types of courses on a wide range of topics. You can take some of them anywhere, any time, and many of the "Getting Started" ones are free.
Get products and technologies
- Download Rational Insight to evaluate it at no charge.
- Download a free trial version of other Rational software.
- Try out Collaborative Lifecycle Management tools in our CLM sandbox.
- Evaluate other IBM software in the way that suits you best: Download it for a trial, try it online, use it in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture efficiently.
- Get involved in the Performance Management with Rational Insight forum on developerWorks and the Using Insight forum on Jazz.net.
- Rate or review Rational software. It's quick and easy.
- Share your knowledge and help others who use Rational software by writing a developerWorks article. Find out what makes a good developerWorks article and how to proceed.
- Follow Rational software on Facebook, Twitter (@ibmrational), and YouTube, and add your comments and requests.
- Ask and answer questions and increase your expertise when you get involved in the Rational forums, cafés, and wikis.
- Get connected. Join the Rational community to share your Rational software expertise and get connected with your peers.