通过使用指标提高 CLM 报告的价值

指标与 Rational Reporting for Development Intelligence and Rational Insight 的使用指导

Rational solution for Collaborative Lifecycle Management (CLM) 是一组无缝集成的应用程序,可用于充当管理您的开发项目完整生命周期的平台。当您在数据仓库中通过 CLM 创建报告时,可使用您的团队为各自项目协同创建的应用程序和生命周期数据。尽管 CLM 包含 200 多个样本报告,外加 Rational Reporting for Development Intelligence (RRDI) 组件或 IBM Rational Insight,但它仍然提供了一些设计工具来定制 CLM 样本和创建自己的报告。通过使用这些工具,您就可以访问数据仓库中的数据,这些数据可分成两大类:操作数据(ODS)和指标。本文将深入研究可用的指标以及如何使用它们。

Peter Haumer, 高级软件工程师, IBM 

Peter Haumer 是 Rational 软件中的 Portfolio Strategy and Management 解决方案的软件架构师。在加入 PSM 团队之前,他是 IBM Rational Quality Manager 应用程序报告的组件主管。您可以从 Rational Experts Web 页面 更多地了解他。


developerWorks 投稿作者

2013 年 5 月 09 日

Rational solution for Collaborative Lifecycle Management (CLM) 是一组无缝集成的应用程序,可用于充当管理您的开发项目完整生命周期的平台。当您在数据仓库中通过 CLM 创建报告时,可使用您的团队为各自项目协同创建的应用程序和生命周期数据。

尽管 CLM 包含 200 多个样本报告,外加 IBM® Rational® Reporting for Development Intelligence 组件(后面简称为 “Rational Reporting”)或 IBM® Rational® Insight 性能测量和管理软件,但它仍然提供了一些功能强大的报告设计工具来定制 CLM 样本和创建自己的报告。通过使用这些工具,您就可以访问数据仓库中的数据,这些数据可分成两大类:操作数据(ODS)和指标。关于如何创建 ODS 报告,已经有一些详细的指导性资料可供使用(参阅 参考资料 中的参考条目2、3 和 4),因此本文将深入研究可用的指标以及如何使用它们。本文的重点不是介绍创造经验,因为已经有一组新的视频教程对此进行介绍了(参阅 参考资料 中的参考条目 5)。本文旨在回答一些有关指标和 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 更多的样本指标。有关这些指标的 Rational Insight 概述,请参阅 参考资料 中的参考条目 6。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 术语的映射并不明显,或需要关注其他注意事项。此列表虽然详尽,但不完整。

表 1. 指标使用的常见域
维度名称 CLM 数据源使用
Category Work Item Category 在工作项的 Rational Team Concert UI 中,它显示为 File Against 字段。
Classification (不适用,N/A) 此维度指示了数据的来源和类型,比如 RTC Work Item (Rational Team Concert)、RRC Requirement (Rational Requirements Composer) 或 RQM Execution Result(Rational Quality Manager)。因此,它可让您区分请求是来自 Rational Team Concert 还是 Rational ClearQuest,是来自 Rational Requirements Composer 还是 Rational RequisitePro,等等。
Creator Work Item Creator Creator 角色,意味着创建工作项的用户已被添加到 CLM 2012 版本的所有 Request 指标中。
Date (参见注释)如果指标的名称中包含单词 Date(比如,Execution Result Date 指标),那么将会使用此指标名称中提及的 ODS 数据元素的实际创建或更改日期(执行结果的实际开始日期)。在极少数的情况下,指标名称中没有包含单词 Date ,但 date 维度实际上只是变换了称谓,比如在 Request Closure 指标中,它被称为 Closure Date。在其他所有情况下, Date 维度均代表了数据收集日期,即数据加载到此指标的事实表中的日期。因此,大多数指标提供了这些收集日期的趋势数据,即日常数据收集时的数据快照。
Iteration Work Item Planned for Test Plan Phase (Iteration) 根据正在使用的指标,此维度指代的要么是将为其解析一个工作项的 Planned For 迭代,要么是一个时间段,在这个时间段内,将会分配一个测试计划,在该计划的测试进度内执行此计划。一般来说,如果一个指标的名称中包含 "with Test Plan" 字样,那么 Iteration 在 CLM 2012 中是指测试计划进度。如果该指标还可以根据需要提供量度,那么此 Iteration 维度表明的是创建请求的测试阶段,或是在测试期间发现缺陷的那个阶段。在 CLM 2011 中,这些 "with Test Plan" 指标被弃用,在这里不再使用此 Iteration 维度。
Project Project Area 此维度将引用量度被拒绝的工件的项目区域。例如,在具有 Test Plan 选项的 Request Metrics 中,Project 将是填充 Request 表的工作项的项目区域,而不是测试计划的项目区域。
Release Work Item Found In Release 被工作项的 Found In 信息所填充。对于 Team Concert 项目区,值的来源被定义为 Release。
Request Priority Work Item Priority 代表的是为工作项定义的优先级。每一个 Rational Team Concert 项目区域可以为工作项类型定义自己的一组优先级,并且所有优先级均被视为各自不同。换句话说,在使用这个维度时,可能会发现很多 High、Medium、Unassigned 等的结果,因为每个项目的优先级将会单独分组。
Request Severity Work Item Severity 代表的是以项目为基础为工作项定义的严重程度。上面关于 Priority 的注释在这里也适用。
Request Status Work Item State Groups 在 Rational Team Concert 中,状态被分组成为状态组。这使得工作项状态在每个项目单独定制的状态之间或多或少有些相似。因此,此维度应被用于基于状态的报告,以显示来自多个 Rational Team Concert 项目区域的数据。
Requirement Requirement 允许您显示所测量的数据,比如说,执行结果是根据相关需求进行分组的。在 CLM 中,这些需求是通过集合(以及存储在 Scrum 进程模板中的所谓的 Implementation Requests)与测试用例和测试计划相关联的。
Resource User Resource用户 的数据仓库的名称。根据不同的指标,它的用法也会有所不同。不过,在大多数情况下,它代表的是被测工件的所有者,即工作项的所有者。(参见 Creator 维度,这是另一个面向用户的维度)。但在这里,其含义从其名称便可以了解。
State Work Item State
Test Case State
State 是工件特定于项目区域的状态。在 CLM 2012 中,此维度覆盖了 Request 指标中的工作项状态以及 Test Case 指标的测试用例。
Team Team Area 此维度代表的是与这些量度有关的工件的项目区域的团队区域。
Test Case Test Case 允许显示被测数据,比如将会根据相关测试用例进行分组的执行结果。
Test Plan Test Plan 允许显示被测数据,比如将会根据相关测试计划进行分组的执行结果或缺陷(请求) 。
Type Work Item Type
Requirements Type
代表的是特定于项目区域的工作项或需求类型。如果想编写一个测量缺陷的报告,可以在此定义一个过滤器。但是仍然需要注意的是,每个项目区域可能都有自己的一组工作项类型,而有可能不是所有这些缺陷都被标记为 Defect
Verdict Execution Result Actual Result 此维度代表的是测试结果类别,比如 Rational Quality Manager 执行结果可用的 Passed、Failed 和 Deferred。虽然它们是以项目为基础而进行定制的,但此数据集的当前实现假定了一组值,因为它们是默认进程模板为 Rational Quality Manager 项目提供的。

表 2 显示了希望能够从 CLM 提供数据但实际上无法提供数据的一些维度。如果将它们添加到您的报告中,通常会得到一个空的结果,或者结果将显示为 "Info not Available"。因此,不应该将这些维度用于特定于 CLM 的报告。

表 2. 不能使用 CLM 数据填充的域
维度名称注释
Component 非来自 Rational Team Concert 的 SCM 组件。未被 CLM 使用。
Fixed in Release 在 CLM 内不提供值,因为工作项在迭代内解析,由 CLM 提供给数据仓库的数据内无到此发布的链接。
Platform CLM 未提供平台信息。
Product 此维度未提供来自 CLM 的数据。
Project (by Portfolio) 这假定按组合(portfolio)对项目进行分组。然而,CLM 不使用任何组合。

变更管理指标

变更管理指标为您提供了与 Rational Team Concert 工作项相关的量度。可以将这些指标用于记分卡或柱形图,提供有关开放缺陷的计数,以及缺陷或任何类型的工作项的创建或关闭趋势。图 3 显示了一个包含在 Rational Quality Manager 中的示例报告(数据来自我们自己使用的 Rational Team Concert 和 Rational Quality Manager,用于开发和测试这些产品)。

该报告使用了 Request Creation 和 Request Closure 指标,您可以在表 3 中查看有关这些指标的更详细的记录。这份报告比较了与遵循测试计划的测试有关的传入缺陷和已解决缺陷的数量。您还可以使用这份报告来评估提前修复缺陷以及在测试过程中发现新缺陷的质量和团队效率,对它们进行比较。

图 3. QM 示例报告:随时间推移而传入的缺陷和解决方法
trend graph

下表展示了 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。

表 3. 使用 CLM 数据提供结果的配置与变更管理指标
指标名称使用 CLM 数据的量度不能对 CLM 使用的量度使用是否需要 Rational Insight ETL
Release Request Metrics Total Request of Pre- Release,
Total Request of Post Release
Total Work 这两个发布前和发布后的量度负责查看发布的可用日期与工作项创建日期之间的时间差,从而确定请求是在发布前还是发布后被发现的。然而,这一指标的效用是有限的,因为它只关注日期,并且总是考虑所有工作项,而不考虑项目区域的边界,因为工作项与发布是不相关的。因此,发布前和发布后的总数永远都是相同的,是项目中所有工作项的数量。 Yes
Release Request Turnaround Metrics (All) 这个指标遵循上一指标的方法,但它关注的是特定状态(参见前面的状态维度)以及工作项处于这些状态的时间。这些量度提供了工作项在发布前后从 Submit 状态转入 Resolve 状态的最大、平均和最小天数。测量包括请求的总数以及发布前后的请求花费的最大、最小和总天数。 Yes
Request Aging Metrics [with Test Plan] (All) 这一指标提供了请求花费在某个状态的最大、平均和最小的天数信息。在这种情况下,它使用的是特定于进程的状态,而不是身份。
该指标的 "with Test Plan" 变体向此指标添加了测试技术维度。该维度对于想要用测试计划分组工作项(缺陷)量度的测试人员而言十分重要。Iteration 维度在这里指的是测试进度,以及 Rational Quality Manager 中定义的迭代;但是,其他指标的迭代维度指的是以 Planned For 值形式分配给这些工作项的 Rational Team Concert 迭代。
Yes
Request Closure Metrics
[with Requirement][with Test Plan]
Closure 这个指标提供了有关请求关闭率的信息。Closed 在这种情况下是指 Closed 工作项组,而不是名称为 Closed 的特定状态。换句话说,这个量度是处于 Closed Status 状态的请求的总数(参见表 1,获得有关 Status 维度的细节)。这一指标使用 Date 维度来表示请求被移入 Closed 状态组内的某个状态的实际日期。包含 Requirement 和 with Test Plan 的此指标的两个变体允许您访问特定的某个(组)要求或测试计划的量度。
注意:Request Resolution 指标未列入此表,因为它们对 CLM 不适用, 而且没有名为 Resolved 的工作项状态组。名为 Resolved 的状态通常都被添加到 Closed 状态组中。
对于基础指标,否
对于两个变体指标,是
Request Creation Metrics [with Requirement]
[with Test Plan]
Arrival Actual or Planned Duration, Story Points 类似于闭包度量,此度量使用 Date 维度来计算通过使用Arrival 量度而创建的请求数量。对于基础指标和 Test Plan 变体,否
对于 requirement 变体,是
Request Failure Metrics
[with Requirement][with Test Plan]
Total Requests 如果有一个工作项类型是 Defect,那么就可以将该指标用于 CLM 数据。本地化的名称行不通。对于这些请求,只计算 Status 从 Closed 转到 Open 的那些请求(参见表 1,获得有关 Status 的更多信息)。这个量度的可能解释是:这些缺陷验证失败或需要重新测试,因此必须重新开放。Yes
Request Metrics [with Requirement]
[with Test Plan]
Total Requests, Actual Work, Planned Work Total Blocking Requests 这是一个基本的指标,它通过使用关键维度对请求(比如工作项)进行计数,该指标包括带有相关测试计划(用于报告在计划测试过程中发现的缺陷)或相关需求的变体。它还提供了对实际工作和计划工作的量度,可以用于基于工作项 Estimate、Correction 和 Time Spent 字段的迭代燃尽图 (burndown chart)。将此量度除以 3600 就可以得到小时数。CLM 不能使用 Blocking 量度,因为它没有在 ODS Request 表列中提供这些信息,而该指标依赖于此信息。No
Request Turnaround Metrics [with Test Plan] (All) 这一指标提供了请求的状态(在使用变体指标时,这可能是一个与测试计划有关的缺陷)从 Open 转变到 Closed 的最大、平均和最小天数。 Yes
Story Metrics Total Story Points, Total Comments, Total Subscribers Total Tags 此指标为类型为 Story 的工作项提供各种量度。本地化的名称不能使用。要想使用此指标,需要使用 Rational Team Concert 3.0.1.2 或更高版本。对于 Story 工作项,之后还可以报告故事总数,为此故事提交的评论数和订户数。Total Tags 量度实际上只提供了具有标签的工作项的数量,并没有对分配给工作项的标签进行计数。 Yes

质量管理指标

质量指标主要是指测试执行结果和趋势,但它们也涵盖了其他一些区域,比如在某个项目的实验室资产的使用或是测试实例的状态。图 4 显示了 Execution Trend,这是一个非常流行的包含在 Rational Quality Manager 中的样本报告,它使用了以下指标:

  • 带有迭代的 Execution Result Points 指标
  • 带有迭代的 Execution Work Item 指标
  • ODS 表,其中包含了能够体现团队的测试执行性能的计划数据

图 4 中的报告描绘了执行测试的点(:一个能表示运行测试成果的指标),对比了每周的计划点与完成点。它展示了三对这样的趋势:

  • Planned,它是在测试计划进度中估算点随时间的分配(参阅 参考资料 中引用的 “Building a Report in Rational Common Reporting” 视频)。
  • Computed,它是对分配给第二个指标提供的计划和里程碑的每个测试用例执行记录进行估算的点的总合。
  • 截至第一个指标提供的特定日期之前,这个团队实际执行了哪些操作。
图 4. Execution Trend 报告显示一个团队的预计性能与实际性能的对比
此屏显示了参数总合和趋势图

下表列出了所有可用于 CLM 数据的指标,遵循与讨论 CCM 指标同样的模式。

表 4. 使用 CLM 数据提供结果的 QM 指标
指标名称使用 CLM 数据的度量不能用于 CLM 的度量用法是否要求 Rational Insight ETL
Execution Result Date Metrics (全部) 这个指标提供了一个执行结果的摘要信息,对 Date 维度使用了结果的实际开始日期。其他执行结果指标则使用数据收集日期来填充此 Date 维度,并对可用于该日期的所有结果进行计数。而该指标将对与实际起始执行日期有关的结果进行计数。因此,它仅对始于该日期的结果进行计数。所提供的度量反映了每个执行结果的判定,比如:Attempted、Failed 或是 Deferred。如测试者分配的那样,它在执行结果的 Web UI 中使用了滚动条。
Execution Result Metrics [with Iteration] Total Execution Results 一个简单的指标,可用于计算在收集时间上可用的执行结果的绝对数。您可以使用 Verdict 维度来重点关注某些特定结果,例如 Attempted 或 Failed。此指标的 “with Iteration” 变体要求使用 Iteration 维度,由它指代测试计划进度中的某个测试阶段。 No
Execution Result Point Metrics [with Iteration] (全部)这是 图 4 所示的 Execution Trend 报告的指标中使用的众多指标中的一个。该指标用于提供此图表的 Actual 值。它通过收集数据收集时可用的结论提供了已完成的执行点的量度。这个迭代变体需要使用迭代维度,方式与上面所讨论过的方式相同。 No
Execution Work Item Metrics [with Iteration]
[with Requirement]
Total Execution Work Items
Total Weight
这是图 4 所示的示例报告中使用的另一个指标,用于提供 Computed 值。它提供了计算可用测试用例执行工作项的总数和总权重的量度。因此,在使用这个指标的 Iteration 变体时,可以使用它来访问执行工作项的数量,以及分配给某个特殊迭代的点的具体数量。在对测试有一定要求时,还可以使用 “with Requirement" 的其他变体,根据一组特定需求来过滤指标,编写在规划测试需求时会显示的报告。
Job Total Number of Job Results 这一指标基于实验室资源提供了关于某个作业执行结果的信息。
Lab Utilization Metrics Total Number of Machines
Reserved Machines
这一指标基于预订日期提供了关于实验室资源使用的信息。 No
Test Case Metrics [with Iteration]
[with Requirement]
Total Test Cases 一个简单指标,用于计算测试用例的总数。但在具有不同维度时,可以将它用于显示特定测试计划迭代的测试用例状态的趋势的报告,并会考虑相关的需求。

需求管理指标

最后的这一节将向您展示可用于 CLM 数据的需求指标。一般来说,Rational Requirements Composer 并不提供任何关于变更和需求版本的数据。因此,目前没有引用变更管理的量度。

表 5. 使用 CLM 数据提供结果的需求管理指标
指标名称使用 CLM 数据的量度无法用于 CLM 的度量 用法是否要求 Rational Insight ETL
Child Requirements Metrics Total Children Requirements 这一指标计算具有父需求的需求数量。
Requirement Metrics [with Test Case]
[with Test Plan]
Total Requirements Total Changes 这三个指标可以计算需求以及通过需求集合连接到测试用例或测试计划的需求的总数。后者也可计算直接与测试计划有关的需求,但 CLM 的需求管理应用程序不支持此操作,但其他的需求管理工作(如 RequisitePro)可以利用这种关系。
注意:这些指标的几个维度可能都无法用于您的需求管理工程,因为所有需求管理中的属性都是自制定义的。只有拥有诸如 Priority 或 Stability 这样的属性(属性名称与维度名称完全相同),才能为这些指标维度提供数据。
Requirement Traceability 树中的这个条目实际上不是一个指标,但可以使用它来访问追溯至其他 CLM 工件的各种需求。与上面列出的指标和维度一样,并不是所有的条目都会受到 CLM 数据的支持。对 Activities、Customer 和 Tasks 进行追踪是不可行的,因为 CLM 不包含那些概念。

结束语

本文向您全面介绍了在使用 Rational Reporting for Development Intelligence 或使用具有 CLM 的 Rational Insight 时可供您使用的相关指标,还了解了哪些指标可用,哪些指标因为所需数据在 CLM 可报告的 REST API 中丢失而不可用。为了方便以后进行参考,本文还以表的形式列出了使用 CLM Data Collection 和 Rational Reporting 时可以使用哪些指标,以及哪些指标需要使用扩展的 Rational Insight ETL 来收集数据。

接下来,我们就会开始探索这些指标了。使用视频(参阅 参考资料 中的 YouTube 视频播放列表)中所示的 Query 或 Report Studio,并开始创建使用了本文所列指标的报告。尝试使用各种维度过滤器

查看 CLM 自带的 100 多个 Cognos 样例报告,这对您很有帮助。它们使用指标的方式多种多样。在 Report Studio 中打开这些报告,并试着理解用来构建它们的查询。


致谢

感谢我的同事 Ashish Apoorva 创建了质量管理指标的早期版本,感谢 Jun BJ Wang 为此提供的反馈。感谢 Amanda Brijpaul 为本文提供了反馈并录制了视频。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=929273
ArticleTitle=通过使用指标提高 CLM 报告的价值
publish-date=05092013