![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
コラボレーティブ・ライフサイクル管理 (CLM) のための Rational ソリューションは、お客様の開発プロジェクトの全ライフサイクルを管理するために、1 つのプラットフォームとしてまとまって機能する 1 セットのシームレスな統合アプリケーションです。お客様のチームがプロジェクトのために協力して作成するアプリケーションおよびライフサイクル・データが CLM によるレポートのためにデータ・ウェアハウス内で提供されます。
CLM アプリケーションには 200 以上のサンプル・レポートが含まれますが、IBM® Rational® Reporting for Development Intelligence コンポーネント (これ以降、「Rational Reporting」と呼びます)、または IBM® Rational® Insight パフォーマンス測定および管理ソフトウェアを追加することにより、CLM サンプルをカスタマイズし、お客様独自のレポートを作成するための強力なレポート設計ツールを利用できます。こうしたツールにより、主に運用データ (ODS) およびメトリックの 2 つのカテゴリーにグループ化されたウェアハウス内のデータにアクセスできます。ODS レポートの作成に利用できる詳細な学習資料が既に用意されていますので (参考文献 2、3、および 4 を参照)、この資料では利用可能なメトリックおよびその使用方法について詳細に説明します。ここでは、新しいビデオ・チュートリアル・セット (参考文献 5) で取り上げられているオーサリング作業については重点を置きません。その代わりに、この資料ではメトリックと CLM についてよく寄せられる以下の質問に回答します。
- CLM アプリケーションで使用する場合、製品に依存しないウェアハウスにより提供されるどのメトリックが推奨されますか?
- CLM の用語でメトリックの尺度およびディメンションは何を意味しますか? また、そのデータはどこから得られますか?
- CLM データ収集ジョブを通じて提供されるのはどのメトリックですか? また、Rational Insight Data Manager を必要とするのはどのメトリックですか?
今までウェアハウス・メトリックに触れたことがない場合、CLM のためのレポート作成時になぜこうした質問が生じるのか疑問に思われるかもしれません。この主な理由は、CLM で使用するウェアハウスが Rational Insight で使用する同じスキーマに従っているためです。このスキーマは、すべての Rational ソフトウェア、および Rational ソフトウェアと統合する外部製品とともに使用できるように、製品に依存せず開発データを表示できる設計になっています。また、このスキーマに加えて、共通のコア・レポート・データ・モデルを提供します。これは、レポート設計ツールに表示されるわかりやすくローカライズされた名前で、エンド・ユーザーがウェアハウス・データにアクセスすることを可能にするモデルです。このレポート・データ・モデルは、製品に依存しない独自の用語を定義します。これは、類似する対象に対してアプリケーションによって異なる用語を使用するため、必ずしもご使用のアプリケーションの用語には一致しません。さらに、同じドメイン内で運用されているアプリケーションでも、それぞれが異なるデータを保存するため、すべてのウェアハウス・テーブルがすべてのアプリケーションによって同じ方法でデータを入力されるとは限りません。
例えば、IBM® Rational® Requirements Composer、IBM® Rational® DOORS®、または IBM® Rational® RequisitePro® を使用する場合に、ウェアハウスには要求属性などの異なる情報が格納されます。別の例は、CLM の変更および構成管理 (CCM) アプリケーションである IBM® Rational Team Concert™ からのワーク・アイテムと、IBM® Rational® ClearQuest® で管理されている変更要求が、要求と呼ばれる同じウェアハウス・テーブル内で表示されることです。両アプリケーションは大幅にカスタマイズ可能です。したがって、一部のデータ列は各アプリケーションによって異なる方法で使用される可能性があります。
ただし多くの場合、共通するデータの非常に大きな交差が存在します。こうした交差は、この 1 つのウェアハウスからのデータに基づいて、すべてのアプリケーションからのデータをまとめて表示できる共通のレポートを作成するために使用できます。例えば、CLM 用の QM アプリケーションである IBM® Rational® Quality Manager は、上記の要件管理アプリケーションすべてと統合しており、Rational Quality Manager で提供されるすべてのサンプル・レポートではこれらのアプリケーションのいずれかからテスト成果物にリンクされた要件データを表示できます。こうした要件アプリケーションを複数使用する場合は、そのようなデータの組み合わせを表示することもできます。
ウェアハウスはまた、統合のニーズに伴って拡張する場合があります。まず CLM と Rational Reporting により開始し、後で、追加の Rational アプリケーションまたは外部アプリケーションを組み合わせることができます。前述した CLM ウェアハウスでは、Rational Insight と同じコア・ウェアハウス・スキーマおよびレポート・データ・モデルを使用します(Insight および CLM も同様に、いくつかのプライベート・スキーマを持ちますが、これらもここで説明するシナリオに該当します)。Rational Reporting は現在、3 つの CLM アプリケーションのみをサポートしていますが、Rational Insight に切り替えることによって、前述のような他のアプリケーションからのデータも格納するエンタープライズ規模のウェアハウスとするために既存の CLM ウェアハウスを拡張できます。Rational Insight では、CLM 以外のアプリケーションからのサポート・データに加えて、CLM よりも多くのサンプル・メトリックを提供しています。このようなメトリックに関する Rational Insight の概要については、参考文献 6 を参照してください。CLM は、このメトリックのサブセットに対するデータを提供します。この資料では、Rational Insight を使用する場合に得られる追加のメトリックについて説明しています。
こうした背景議論を要約すれば、レポート作成者にとっての利点は、異なるアプリケーションからのデータをレポートで使用できるということです。しかし問題は、レポート・データ・モデルで使用される用語を対応させること、およびこのレポート・データ・モデルのどのアイテムが CLM またはその他のアプリケーションによって入力されるかを認識することです。これは運用データおよびメトリックに当てはまります。運用データに関する詳細な資料については、Rational ソフトウェア・インフォメーション・センターで、「レポート作成」>「レポート作成用の参照情報」>「レポート・データ・ディクショナリー」を参照してください。メトリックについては、この資料で説明します。
前述したように、ウェアハウスには以下の 2 つのカテゴリーのデータがあります。
- 運用データ (ODS は、運用データ・ストアを表します)。通常は、テスト・ケースとその属性のリストなど、ウェアハウス内の未加工のアプリケーション・データを表すクエリーに似たリスト・レポートに使用されます。
- メトリック。 データの分析ビューを提供します。つまり、入力として ODS データを取得し、データをその解釈に基づいて尺度に集約することにより、処理済みのデータを表示します。尺度は通常、要求数、テスト実施結果数など、データ・アイテムの数となります。また、テスト・ケース実行レコードのすべての重みポイントの合計など、数値データの集約された合計値が使用される場合もあります。これらの尺度は、修飾のために多くのディメンションに関連して収集されます。こうしたディメンションを使用することにより、検索対象の特定の数を迅速に見つけることができます。
図 1 は、そのようなメトリックがレポート開発ツールで構造的にどのように表されるかを示しています。「実績作業時間」や「要求合計」などのルーラー・アイコンによって示される尺度と、軸アイコンによって示される「カテゴリー」や「日付」などのディメンションによって、要求メトリックがさらに細かく分類されています。レポートを作成する場合には、基本的にはこのツリーからグラフなどのレポート・コンポーネントにドラッグ・アンド・ドロップします。例えば、プロジェクト X によって所有され、指定の障害タイプであり、未完了の状態で、所有者が割り当てられていないものに「要求の合計数」をフィルターしたいメトリックについて、ディメンションを使用します (図 1 で所有者は、メトリックにより「リソース」として表されます)。したがって、プロジェクト、タイプ、状態、および所有者は、要求メトリックのディメンションになり、要求の尺度数が適用されます。次に、このディメンション・セットにより、このメトリックのアプリケーション、「所有者がいない未完了の障害の数」を表示するレポートを呼び出すことができます。
図 1. 尺度とディメンションを示すメトリックの構造
メトリックは、定期的な間隔で収集されます。CLM ケースではメトリックは毎日収集されるので、データの最新のビューだけでなく、時間経過に伴う傾向も把握できます。前述の「所有者がいない未完了の障害の数」の例を使用してこの尺度で収集された傾向情報により、「日付」のディメンションを使用して所有者のいない障害数の時間経過を示すグラフをレポート内に作成できます。したがって、着信する障害が所有者にトリアージされる際の整合性について情報を提供できます。
このメトリックの解釈と有用性およびそれを表示するレポートは、開発プロセスに大きく依存することになります。開発プロセスにおいて、即座の修正を促すために障害を所有者に一貫して割り当てることに重きが置かれる場合、割り当てられた時間スロット内の障害に対処する際に常にチームがランク付けされたバックログから障害を選択するよりも、このレポートはより有用であるといえます。また、このレポートを表示するユーザーは、レポートが新しい障害の着信率または障害の割り当てにかかった時間ではなく、未完了の障害の傾向のみを示すことを理解する必要があります。したがって、開発プロセスの目標を達成するには、複数のメトリックが必要になる場合があります。
前述したように、メトリックの使用方法および有用性は、開発プロセスに大きく依存します。また、CLM アプリケーションに含まれるメトリックは、非常にプロセス固有になる場合も、多くのケースで使用するためにかなり汎用的になる場合もあります。CLM ソリューションおよび Rational Insight で利用可能なメトリックの作成者は、後者のアプローチを選択することになります。このプロセスに対するメトリックの依存関係はまた、メトリックの定義にも当てはまります。上記の例では、障害が実際に何であるかはプロセスによって変わる場合があります。例えば、要求をカウントするためにここで入力を提供する Rational Team Concert 内のプロセスでは、まったく異なるタイプのワーク・アイテムが定義される場合があり、そうすると障害に対するマッピングは困難となります。最も簡単なケースでは障害はバグと呼ばれるものになりますが、別のケースではワーク・アイテムのタイプは変更要求のように汎用的なものになるため、障害と機能拡張要求を直ちに区別することができません。さらに、Rational Team Concert 内のワーク・アイテムまたは Rational ClearQuest 内の要求のワークフローは、完全にユーザー定義になるため、未完了の状態の概念は各プロセスで異なる場合があります。ウェアハウスにデータを提供する各プロジェクトが異なるプロセスを使用する可能性がある場合、どのような種類のプロセスでも使用可能な有用なメトリックを提供するウェアハウスを設計することが主な課題になります。メトリックのユーザーは、以下の条件について各メトリックを評価する必要があります。
- ドメイン内でデータを提供する各アプリケーションからメトリックでどのデータが使用されますか?
- データを作成するためにどの開発プロセスおよびアプリケーションのカスタマイズが使用されましたか? またそれはメトリックに対して何を意味しますか?
- メトリックを解釈および使用するためにどのプロセスを使用しますか?
尺度とディメンションを選択した後、グラフやクロス集計など、レポート設計ツールのさまざまなレポート・コンポーネントに適用することにより、メトリックを使用するレポートを作成します。また、ディメンションでフィルター値を入力するための通知プロンプトを定義します。上記の例では、これは使用する特定の状態 (未完了が何を意味するかを定義する前述の問題を解決します)、重点を置くプロジェクトなどになります。百聞は一見にしかずということはよく知られていますので、ここではレポート作成ステップを案内するいくつかのデモ・ビデオを用意しました。したがって、これらのビデオを YouTube でまだ見ていない場合は、ここでいったん読むのを中断し、ビデオを見てから、次に進んでください。
- 「Introduction to IBM Rational RRDI v2.0 Report Authoring (IBM Rational RRDI v2.0 Report Authoring 入門)」(US)
- 「Using the IBM® Cognos® Query Studio v10.1 User Interface and Data Package (IBM® Cognos® Query Studio v10.1 ユーザー・インターフェースおよびデータ・パッケージの使用)」(US)
- 「Build a list report in Cognos Query Studio v10.1 (Cognos Query Studio v10.1 でのリスト・レポートの作成)」(US)
- 「Build a Crosstab and Chart in IBM Cognos Query Studio v10.1 (IBM Cognos Query Studio v10.1 でのクロス集計およびグラフの作成)」(US)
[中断]
さあ、それでは再開です。ビデオ「Build a Crosstab and Chart in IBM Cognos Query Studio v10.1 (IBM Cognos Query Studio v10.1 でのクロス集計およびグラフの作成)」では、テスト実施結果をカウントするメトリックを使用することにより、クロス集計および棒グラフ・レポートを作成する方法を示しています。ここでは、クエリー・アイテム間でドラッグでき、現在のレポートを直ちに実行する Query Studio ツールを使用しています。
利用可能なメトリックについて独自の探索を開始するために、この同じツールを使用して実験を開始することをお勧めします。以降のセクションでは、独自のデータで関心のあるメトリックを使用することにより、類似のレポートの作成を開始できます。独自のデータによりメトリックを探索することで、メトリックがお客様の開発プロセスにどれほどよく適合するか、またお使いのアプリケーションのセットアップでどのデータを利用できるかについて、より的確に判断できます。
以降では、一連の興味深いシナリオにおいて CLM ソリューションで使用するための関連データを提供すると思われる主なメトリックについて説明します。Rational Reporting および Rational Insight のレポート設計ツールでは、以下のドメインごとにメトリックをグループ化するツリー・ブラウザー・ビュー内で、レポート・データ・モデルによってメトリックが表示されます。
- 変更管理
- 構成管理
- プロジェクト管理
- 品質管理
- 要件管理
図 2. メトリックは、以下のドメイン別にグループ化される
多くのメトリックでは複数のドメインからのデータが使用されるので、このマッピングが期待に沿わないこともあります。メトリックを特定するための経験則として、メトリックの尺度に使用されるデータは、該当するドメインから得られるということがあります。例えば、「テスト計画の要求メトリック」は主に、品質管理レポートで使用されます。ただし、これは (特定のテスト計画のテスト時に検出された障害をカウントする) 要求の測定を実行するため、変更管理グループに配置されています。
以降では、CLM によって使用されない「プロジェクト管理」グループを除いて、これらの各グループについて説明します。「構成管理」グループでは、「作成」メトリックのみが CLM に関連するデータを提供しますが、ここでは説明しません。
ただし、個々のメトリックについてレビューする前に、グループ全体に渡って使用される共通のディメンションのリストについて検討しましょう。表 1 では、CLM 用語からのマッピングが明確でないか、追加の考慮事項が必要なディメンションに焦点を置いています。これは包括的ではあっても完全なリストではありません。
表 1. メトリックによって使用される共通のドメイン
| ディメンション名 | CLM データ・ソース | 使用方法 |
|---|---|---|
| カテゴリー | ワーク・アイテム・カテゴリー (Work Item Category) | ワーク・アイテムに対する Rational Team Concert UI では、「対ファイル (File Against)」フィールドとして表示されます。 |
| 種別 | (該当なし) | このディメンションは、RTC ワーク・アイテム (Rational Team Concert)、RRC 要件 (Rational Requirements Composer)、RQM 実行結果 (Rational Quality Manager) など、データの取得元およびタイプを示します。したがって、Rational Team Concert からの要求と Rational ClearQuest からの要求、Rational Requirements Composer からの要件と Rational RequisitePro からの要件などを区別できます。 |
| 作成者 | ワーク・アイテム作成者 (Work Item Creator) | CLM 2012 リリースでは、ワーク・アイテムを作成したユーザーを示す作成者の役割がすべての要求メトリックに追加されました。 |
| 日付 | (コメントを参照) | 単語「日付」がメトリック名に含まれる場合 (例えば、実行結果の日付メトリックなど)、メトリック名に記述された ODS データ要素の実際の作成日または変更日が使用されます (実行結果の実際の開始日)。まれなケースとして、単語「日付」がメトリック名に含まれていなくても、要求クローズ・メトリックの「クローズ日付」のように、日付ディメンションが実際には異なる方法で呼び出されていることがあります。その他の場合はすべて、「日付」ディメンションはデータ収集日、つまりデータがメトリックのファクト表にロードされた日付を意味します。したがって、大半のメトリックではこのような収集日にまたがった傾向データを提供するとともに、毎日のデータ収集時点におけるデータのスナップショットを提供します。 |
| 反復 | テスト計画フェーズで計画されたワーク・アイテム (反復) | このディメンションは、使用中のメトリックに応じて、ワーク・アイテムの解決対象となる「計画対象」反復、またはテスト計画に割り当てられたテストが計画のテスト・スケジュール内に実行される期間のいずれかを示します。一般的に、メトリックの名前に「テスト計画の」が含まれる場合、反復は CLM 2012 のテスト計画スケジュールを表します。そのようなメトリックで要求に尺度を提供する場合、「反復」ディメンションは要求が作成されたテスト・フェーズ、またはテスト中に障害が検出されたフェーズを示します。CLM 2011 では、「テスト計画の」を含むメトリックは機能せず、この場合に「反復」ディメンションは使用できません。 |
| プロジェクト | プロジェクト・エリア | このディメンションは、尺度が定義された成果物のプロジェクト・エリアを示します。例えば、「テスト計画の」オプションを含む要求メトリックでは、プロジェクトはテスト計画のプロジェクト・エリアではなく、「要求」テーブルに入力されるワーク・アイテムのプロジェクト・エリアになります。 |
| リリース | ワーク・アイテムの検出元 | リリースには、ワーク・アイテムの「検出元」の情報が入力されます。値のソースは、Team Concert プロジェクト・エリアのリリースとして定義されます。 |
| 要求優先順位 | 優先順位 | ワーク・アイテムに対して定義された優先順位を表します。各 Rational Team Concert プロジェクト・エリアは、ワーク・アイテム・タイプの独自の優先順位セットを定義する場合があります。すべての優先順位は、異なる個別のものと見なされます。つまり、このディメンションを使用する場合、各プロジェクトの優先順位が個別にグループ化されるため、「高」、「中」、「未割り当て」など多数の結果がヒットする可能性があります。 |
| 要求重大度 | 重大度 | プロジェクト・ベースでワーク・アイテムに対して定義された重大度を表します。優先順位に関する上記のコメントが適用されます。 |
| 要求状況 | ワーク・アイテムの状態グループ | Rational Team Concert 内で状態は状態グループにグループ化されます。これにより、各プロジェクトの個別にカスタマイズされた状態間で、ワーク・アイテムの状態がある程度比較可能になります。したがってこのディメンションは、複数の Rational Team Concert プロジェクト・エリアからデータを表示する状態ベースのレポートに使用すべきです。 |
| 要件 | 要件 | リンクされた要件によってグループ化される実行結果などの、測定済みデータを表示できます。CLM では、要件は収集を通じてテスト・ケースおよびテスト計画、さらにスクラム・プロセス・テンプレート内のストーリーであるいわゆる実装依頼にリンクされます。 |
| リソース | ユーザー | リソースは、ユーザーを表すデータ・ウェアハウスでの名前です。この使用法は、メトリックに応じて異なります。ただしほとんどの場合、測定された成果物の所有者、したがってワーク・アイテムの所有者を表します(ユーザーの別のディメンションである「作成者」ディメンションを参照してください)。しかしここでは、その意味は名前から明らかです。 |
| 状態 | ワーク・アイテムの状態 (Work Item State)、 テスト・ケースの状態 (Test Case State) | 「状態」は、成果物のプロジェクト・エリア固有の状態です。CLM 2012 では、このディメンションは要求メトリックのワーク・アイテムの状態、およびテスト・ケース・メトリックのテスト・ケースに対応します。 |
| チーム | チーム・エリア | このディメンションは、尺度が関連する成果物のプロジェクト・エリアのチーム・エリアを表します。 |
| テスト・ケース | テスト・ケース | リンクされたテスト・ケースによってグループ化される実行結果などの、測定済みデータを表示できます。 |
| テスト計画 | テスト計画 | リンクされたテスト計画によってグループ化される実行結果または障害 (要求) などの、測定済みデータを表示できます。 |
| タイプ | ワーク・アイテム・タイプ 要求タイプ | プロジェクト・エリア固有のワーク・アイテムまたは要求タイプを表します。障害を尺度とするレポートを作成する場合は、ここでフィルターを定義します。ただし、各プロジェクト・エリアに独自のワーク・アイテム・タイプ・セットが存在する場合があり、そのすべてにおいて障害に「障害」という名前が付けられるとは限らないことに注意してください。 |
| 判断 | 実行結果実際の結果 | このディメンションは、Rational Quality Manager の実行結果で利用可能な「成功」、「失敗」、「延期済み」などのテスト結果のカテゴリーを表します。プロジェクトごとにカスタマイズ可能ですが、データ収集の現在の実装では、Rational Quality Manager プロジェクトのデフォルトのプロセス・テンプレートによって提供される 1 つの値セットを前提とします。 |
表 2 に、CLM からデータが提供されるとおそらく期待されていても、実際にはそうではないディメンションを示します。こうしたディメンションをレポートに追加した場合、通常空の結果が返されるか、または結果に「情報が利用できません」と表示されます。したがって、このようなディメンションは CLM 固有のレポートでは使用するべきではありません。
表 2. CLM データによって入力されないドメイン
| ディメンション名 | コメント |
|---|---|
| コンポーネント | Rational Team Concert からの SCM コンポーネントではありません。CLM では使用されません。 |
| リリース修正 | 反復内でワーク・アイテムが解決されるので、CLM では値は提供されません。また、CLM によってデータ・ウェアハウスに提供されるデータ内で、リリースへのリンクは存在しません。 |
| プラットフォーム | プラットフォームの情報は、CLM では提供されません。 |
| 製品 | このディメンションでは、CLM からのデータは提供されません。 |
| プロジェクト (ポートフォリオ別) | このディメンションでは、ポートフォリオ別のプロジェクトのグループ化が前提とされています。しかし、CLM ではポートフォリオを使用しません。 |
変更管理メトリックは、Rational Team Concert ワーク・アイテムに関連する尺度を提供します。このメトリックは、未完了の障害の数ならびに障害または任意のタイプのワーク・アイテムの作成またはクローズの傾向を示すスコアカードまたは棒グラフで使用できます。図 3 に、Rational Quality Manager に含まれているサンプル・レポートを (製品の開発およびテストのために Rational Team Concert および Rational Quality Manager を独自に使用して得られたデータとともに) 示します。
このレポートでは、表 3 に詳細を示した要求作成および要求クローズ・メトリックを使用し、テスト計画に従ってテストにリンクされた発生障害数と解決障害数を比較します。テスト中の新しい障害の発見と比較して、障害を修正する前の品質およびチームの効率性を評価するためにこのレポートを使用できます。
図 3. QM サンプル・レポート: 時間経過に伴う障害の発生および解決
次の表に、CLM で使用できる各変更管理メトリックについて示します。この表では、各メトリックについて、CLM データとともに使用可能な尺度とレポート作成者が理解する必要がある詳細について説明しています。CLM 2011 および 2012 の間で (それぞれ IBM Rational Insight 1.0.1.1 / 1.1、および Rational Insight 1.1.1 に対応)、これらのメトリックに対する変更があり、この変更についても記載しています。この表ではまた、CLM データ収集ジョブでメトリックが利用可能であるかどうか、または IBM Rational Insight およびその Data Manager ETL のインストールが必要であるかどうかを示します。
表 3. CLM データによる結果を提供する構成管理および変更管理のメトリック
| メトリック名 | CLM データを使用する尺度 | CLM とともに使用できない尺度 | 使用方法 | Rational Insight ETL を必要とするかどうか |
|---|---|---|---|---|
| リリース要求 メトリック | リリース前の要求合計、 リリース後の要求合計 | 合計作業時間 | リリースの前および後の 2 つの尺度は、リリースの前後に要求が検出されたかどうかを特定するために、使用可能になったワーク・アイテムの使用可能日と作成日の期間差を示します。ただし、このメトリックは日付のみを示し、プロジェクト・エリアの境界を考慮せずにすべてのワーク・アイテムが常に含まれることから (ワーク・アイテムはリリースに関連付けられていないため)、有用性は限られています。したがって、リリース前およびリリース後の合計数は常に同じ、つまりプロジェクト内のすべてのワーク・アイテムの数になります。 | はい |
| リリース依頼 ターンアラウンド・ メトリック | (すべて) | このメトリックは、上記のメトリックのアプローチに従いますが、特定のステータス (上記の「ステータス)」ディメンションを参照)、およびワーク・アイテムがそのステータスに留まった時間を示します。この尺度は、リリース前およびリリース後に、ワーク・アイテムが送信状態から解決状態に移動する最大、平均、および最小日数に関する情報を提供します。この測定値には、リリース前後での要求の合計数、および要求に費やされた最大、最小、合計の日数が含まれます。 | はい | |
| 要求経時メトリック [テスト計画の] | (すべて) | このメトリックは、要求がある特定の状態で過ごした最大、平均、および最小の日数に関する情報を提供します。この場合、ステータスではなく、プロセス固有の状態が使用されます。このメトリックの「テスト計画の」のバリアントでは、メトリックにテスト計画のディメンションを追加します。このディメンションは、テスターがワーク・アイテム (障害) の尺度をテスト計画でグループ化するために不可欠です。テスターのニーズに対応するために、「反復」ディメンションはここで Rational Quality Manager で定義されたテスト計画スケジュールおよび反復を参照するのに対して、もう一方のメトリックの「反復」ディメンションは「計画対象」値としてワーク・アイテムに割り当てられた Rational Team Concert 反復を参照します。 | はい | |
| 要求クローズ・ メトリック[要件の][テスト計画の] | クローズ | このメトリックは、要求のクローズ率に関する情報を提供します。この場合「クローズ」は、名前「完了」を持つ特定の状態ではなく、「クローズ」されたワーク・アイテム・グループを示します。つまり、この測定値は「クローズ」のステータスにある要求の総数です (「ステータス」ディメンションの詳細については、表 1 を参照してください)。「日付」ディメンションは、要求が「完了」状態グループの状態に移行した実際の日付を示すためにこのメトリックで使用されます。
このメトリックの「要件の」および「テスト計画の」のバリアントでは、特定の要件またはテスト計画 (セット) の尺度を利用できます。
“注: 「解決済み」というワーク・アイテム状態グループが存在しないため、要求解決メトリックは CLM とともに使用できません。そのため、この表には含まれていません。「解決済み」という名前を持つ状態は通常、この「クローズ」状態グループに追加されます。 | 基本メトリックについては、いいえ 2 つのバリアントのメトリックについては、はい | |
| 要求作成メトリック[要件の] [テスト計画の] | 発生 | 実際の所要時間または予定所要時間、ストーリー・ポイント | このメトリックは、クローズ・メトリックと同様に、「発生」尺度により作成された要求をカウントするために「日付」ディメンションを使用します。 | 基本およびテスト計画バリアントについてはいいえ、 要件バリアントについてははい |
| 要求失敗メトリック [要件の][テスト計画の] | 要求合計 | このメトリックは、「障害」を含む名前のワーク・アイテム・タイプが存在する場合に、CLM データとともに使用できます。ローカライズされた名前は使用できません。これらの要求について、このメトリックはステータスが「クローズ」から「オープン」に移行した要求をカウントします (ステータスの詳細については、表 1 を参照してください)。この尺度の解釈として、こうした障害が検証または再テストに失敗し、再度オープンする必要があったことが考えられます。 | はい | |
| 要求メトリック [要件あり] [テスト計画あり] | 要求合計、実績作業時間、計画された作業 | 合計ブロッキング要求数 | これは、(計画のテスト中に検出された障害についてレポートするための) リンクされたテスト計画、またはリンクされた要件を伴うバリアントを含めて、主要なディメンションを使用することにより、要求 (例えばワーク・アイテム) をカウントする基本メトリックです。また、実績作業および計画された作業に対する尺度を提供します。これは、ワーク・アイテムの「見積もり」、「修正」、および「消費時間」フィールドに基づく反復バーンダウン・グラフに使用できます。時間数を得るには、尺度を 3600 で除算します。ブロッキング尺度は、ODS 要求テーブル列でこの情報を提供せず、メトリックはこの情報に依存するので、CLM では使用できません。 | いいえ |
| 要求ターンアラウンド・メトリック [テスト計画の] | (すべて) | このメトリックは、「オープン」ステータスから「クローズ」ステータスに移行する要求 (バリアントのメトリックを使用する場合、テスト計画に関連する障害である場合があります) の最大日数、平均日数、および最小日数に関する情報を提供します。 | はい | |
| ストーリー・メトリック | 合計ストーリー・ポイント、合計コメント数、合計サブスクライバー数 | 合計タグ数 | このメトリックは、「ストーリー」を含む名前のタイプについて、ワーク・アイテムのさまざまな尺度を提供します。ローカライズされた名前は使用できません。このメトリックを使用するには、少なくとも Rational Team Concert 3.0.1.2 以降を使用する必要があります。これらのストーリー・ワーク・アイテムについて、ストーリーの総数、ストーリーに対して送信されたコメント数、およびサブスクライバー数をレポートできます。「合計タグ数」尺度には、実際にはタグを含むワーク・アイテムの数のみが示され、ワーク・アイテムに割り当てられたタグの数はカウントされません。 | はい |
品質メトリックは、主にテストの実施結果および傾向を示しますが、Lab アセットの使用やプロジェクト内のテスト・ケース作成状況などの分野にも対応します。図 4 は、こうしたメトリックを使用する Rational Quality Manager に含まれる非常に一般的なサンプル・レポートとして「テスト実行傾向」を示しています。
- 反復の実行結果ポイント・メトリック
- 反復の実行記録・メトリック
- チームのテスト実行パフォーマンスを示すための計画データを含む ODS テーブル
図 4 のレポートは、各週の試行ポイントと実行されたポイントを比較するために、実行されたテストに関するポイントを描画しています (ポイント: テスト実行の負荷を示すことができるメトリック)。これは、以下の 3 つの傾向の組み合わせを示すものです。
- 計画。テスト計画スケジュールの時間経過に伴う見積もりポイントの割り当て (参考文献「Building a Report in Rational Common Reporting (Rational の共通レポート機能によるレポートの構築)」ビデオを参照してください)。
- 計算。2 番目のメトリックによって提供される計画およびマイルストーンに割り当てられた各テスト・ケース実行記録に対して見積もられたポイントの合計。
- 第 1 のメトリックによって提供される特定の日付までにチームが実際に実行した内容。
図 4. テスト実行傾向レポートは、チームの見積もられたテスト・パフォーマンスと実際のテスト・パフォーマンスを示しています。
次の表に、CCM メトリックで説明した同じスキーマに従って CLM データとともに使用できるすべてのメトリックを示します。
表 4. CLM データによる結果を提供する QM メトリック
| メトリック名 | CLM データを使用する尺度 | CLM とともに使用できない尺度 | 使用方法 | Rational Insight ETL を必要とするかどうか |
|---|---|---|---|---|
| 実行結果の日付メトリック | (すべて) | このメトリックは、「日付」ディメンションの結果の実際開始日を使用して、実行結果の要約を提供します。他の実行結果のメトリックは、「日付」ディメンションにデータ収集日を入力し、その日付で利用可能なすべての結果をカウントしますが、このメトリックはそうではなく、実際の実行開始日について結果をカウントします。したがって、該当する日付に開始された結果のみがカウントされます。 提供される尺度は、実行結果の Web UI でスライダーを使用してテスターによって割り当てられた「試行」、「失敗」、「延期済み」などの個々の実行結果の判断を反映します。 | いいえ | |
| 実行結果メトリック [反復の] | 合計実行結果数 | 収集時に利用可能な実行結果の絶対数をカウントできる単純なメトリックです。「試行」や「失敗」などの特定の結果に絞り込むために「判断」ディメンションを使用できます。このメトリックの「反復の」バリアントでは、テスト計画のスケジュール内のテスト・フェーズを参照する「反復」ディメンションを使用する必要があります。 | いいえ | |
| 実行結果ポイント・メトリック [反復の] | (すべて) | これは、図 4 に示したテスト実行傾向レポートに使用されるメトリックの 1 つです。これは、グラフの実際の値を提供するために使用されます。これは、データ収集時に利用可能な判断によって、実行された実行ポイントに関する尺度を提供します。「反復」のバリアントでは、上記の説明と同様に、「反復」ディメンションを使用する必要があります。 | いいえ | |
| 実行記録・メトリック [反復の] [要件の] | 合計実行記録数 重み合計 | これは、図 4 のサンプル・レポートによって使用されているもう 1 つのメトリックです。このメトリックは算出値を提供するために使用されます。利用可能なテスト・ケース実行記録の合計数と重み合計をカウントする尺度を提供します。したがって、このメトリックの「反復」バリアントを使用する場合は、特定の反復に割り当てられた実行記録数、およびそれらの特定の合計ポイントにアクセスできます。もう一方の「要件の」バリアントを使用すると、要件のテストが計画された時期を示すレポートを作成するために、特定の要件セットによりメトリックをフィルターできます。 | いいえ | |
| ジョブ | 合計ジョブ結果数 (Total Number of Job Results) | このメトリックは、Lab リソースに基づいて、ジョブの実行結果に関する情報を提供します。 | いいえ | |
| ラボ使用効率メトリック | 合計マシン数 (Total Number of Machines) 予約済みマシン | このメトリックは、予約日に基づく Lab リソースの使用に関する情報を提供します。 | いいえ | |
| テスト・ケース・メトリック [反復の] [要件の] | テスト・ケース総数 | これは、テスト・ケースの合計数をカウントする単純なメトリックです。ただし、特定のテスト計画の反復について、リンクした要件を考慮しながら、テスト・ケースの状態の傾向を示すレポートにさまざまなディメンションとともに使用できます。 | いいえ |
この最後の節では、CLM データとともに使用可能な要件のメトリックについて説明します。通常、Rational Requirements Composer は変更および要件のバージョンに関するデータを提供しません。したがって、現在変更を示す尺度は機能しません。
表 5. CLM データによる結果を提供する要件管理メトリック
| メトリック名 | CLM データを使用する尺度 | CLM とともに使用できない尺度 | 使用方法 | Rational Insight ETL を必要とするかどうか |
|---|---|---|---|---|
| 子要件メトリック | 子要件の合計数 | このメトリックは、親要件を持つ要件の数をカウントします。 | はい | |
| 要件メトリック[テスト・ケースの] [テスト計画の] | 合計要件数 | 合計変更数 | この 3 つのメトリックは、要件収集を通じて、要件の合計数、テスト・ケースまたはテスト計画にリンクされた要件の数を示します。後者ではまた、テスト計画に直接リンクされていても、CLM の要件管理アプリケーションによりサポートされない要件をカウントします。RequisitePro などの他の要件管理ツールでは、この関係を使用します。 注: これらのメトリックのいくつかのディメンションは、要件管理のすべての属性がカスタム定義されるため、独自の要件管理プロジェクトでは機能しない場合があります。「優先順位」や「安定度」などの属性がディメンション名として正確に記述されている場合にのみ、こうしたメトリックのディメンションについてデータが提供されます。 | いいえ |
| 要件の追跡 | ツリーのこのエントリーは実際にはメトリックではありませんが、要件で他の CLM 成果物にトレースするさまざまな方法を参照するために使用できます。前述のメトリックおよびディメンションの場合と同様に、このすべてのエントリーが CLM データによりサポートされるわけではありません。アクティビティー、顧客、およびタスクへの追跡は、CLM がこれらの概念に対応していないため、利用できません。 | いいえ |
この資料では、CLM とともに Rational Reporting for Development Intelligence または Rational Insight を使用して利用可能な関連するメトリックについて説明しました。また、どのメトリックが機能するか、また CLM のレポート可能 REST API に必要なデータが欠如しているためにどのメトリックが機能しないかを解説しました。後で簡単に参照できるように、CLM Data Collection および Rational Reporting の使用時に利用可能なメトリック、およびデータ収集のために拡張された Rational Insight ETL を必要とするメトリックを示す表を掲載しました。
次のステップとして、これらのメトリックの探索を開始しましょう。ビデオに従って Query Studio または Report Studio を使用し (「参考文献」の YouTube ビデオ・プレイリストを参照)、この資料に記載されたメトリックを使用するレポートの作成を開始してください。さまざまなディメンションのフィルターを実験してみます。
また、CLM に含まれる 100 以上の Cognos サンプル・レポートをレビューすることも役立ちます。これらのレポートは、さまざまな方法でこれらのメトリックのほとんどを使用しています。Report Studio でこれらのレポートを開き、レポート作成のために使用されているクエリーについて理解してください。
品質管理メトリックのレビューの初期バージョンを作成してくれた同僚の Ashish Apoorva 氏、およびそのフィードバックを提供してくれた Jun BJ Wang 氏に感謝の意を表します。また、この資料に対するフィードバックを提供し、ビデオを記録してくれた Amanda Brijpaul 氏に感謝します。
学ぶために
- この資料での引用:
- What's new in Rational Reporting for Development Intelligence 2.0 (Rational Reporting for Development Intelligence 2.0 の新機能) (US)
- CLM 2011 reporting workshop(CLM 2011 レポート作成ワークショップ) (US)
- Building a report in Rational Common Reporting (Rational Common Reporting によるレポートの作成) (US)
- CLM Online Help Reporting Tutorials (CLM オンライン・ヘルプ・レポート作成チュートリアル) (US)
- IBM Rational Reporting for Development Intelligence (RRDI)、 YouTube プレイリスト
- IBM Rational Insight online help: Rational Insight sample metadata model(Rational Insight サンプル・メタデータ・モデル) (US)
- IBM Rational CLM オンライン・ヘルプ:レポート・データ・ディクショナリー
- 関連情報については、Jazz.net の 「Development intelligence with the CLM solution (CLM ソリューションによる開発インテリジェンス)」 ページ (US) を参照してください。
- Rational Insight
のパフォーマンス測定および管理ソフトウェアの詳細については、重要な関連情報へのリンクを提供する developerWorks の Rational Insight のページから 製品概要のページをチェックしてください。詳細な手順については、Rational Insight のインフォメーション・センターを参照してください。(US)
- Rational Software Delivery Platform
製品の技術的な資料およびベスト・プラクティスについては、developerWorks の Rational ソフトウェア分野 (US)を参照してください。
- developerWorks 週刊電子メール・ニュースレターに登録し、フォローするトピックを選択してください。さまざまな IBM 製品および IT 業界の動向に焦点を合わせた developerWorks の技術イベントおよび Web キャスト (US) を定期的にチェックしてください。
- 無料の developerWorks Live! ブリーフィング に参加して、IBM の製品およびツール、そして IT 業界のトレンドも素早くキャッチしてください。
- developerWorks のオン・デマンド・デモで、初心者向けの製品インストールとセットアップから、ベテラン開発者向けの高度な機能に至るまで、さまざまに揃ったデモをご覧ください。
- ご自身のスキル向上を図ってください。さまざまなトピックに関する多数のコース・タイプを含む Rational トレーニングおよび認定 (US) カタログをチェックしてください。一部はいつでもどこでも受講できます。また、「入門」講座の多くは無料で受講できます。
製品や技術を入手するために
- Rational Insight を評価用に無料でダウンロード (US)してください。
- その他の Rational ソフトウェアの 試用版を無料 (US)でダウンロードしてください。
- CLM サンドボックスの Collaborative Lifecycle Management ツール (US)を試してみてください。
- ご自分に最適な方法でIBM ソフトウェアを評価 してください。評価の方法としては、試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、 SOA Sandbox では数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。 (US)
議論するために
- developerWorks での 「Performance Management with Rational Insight (Rational Insight によるパフォーマンスの管理)」 フォーラム 、および Jazz.net の 「Using Insight (Insight の使用)」 フォーラム に参加してください。 (US)
- Rational ソフトウェアを評価またはレビュー (US)してください。簡単で、時間もかかりません。
- developerWorks の記事を書いて、ご自分の知識の共有や、Rational ソフトウェアを試用する他のユーザーへの支援を行うことができます。 developerWorks の記事をより良くする方法 や進め方を理解しましょう。 (US)
- Facebook、 Twitter (@ibmrational)、および YouTubeで Rational ソフトウェアをフォローし、コメントやリクエストを追加しましょう。(US)
- Rational
フォーラム、 cafés、および
Wiki に参加すると、質疑応答を通じて、専門知識を増やすことができます。(US)
- コミュニティーにご参加ください。Rational ソフトウェアの専門知識の共有、情報交換のために Rational コミュニティー (US) をご活用ください。
Peter Haumer は、Rational ソフトウェアのポートフォリオ戦略および管理ソリューションのソフトウェア設計者です。PSM チームに参加する前は、IBM Rational Quality Manager アプリケーションのレポート機能を担当するコンポーネント・リーダーでした。詳細については、Rational Experts Web ページを参照してください。
