次の方法で共有


Visual Studio ALM におけるレポート作成に関する新機能

Visual Studio Team Foundation Server の現在のリリースを使用すると、複数の既定のレポートとダッシュボードによって、チーム プロジェクトを監視し、開発中のソフトウェアの品質を追跡できます。 さらに、現在および過去の傾向レポートを作業項目クエリからすばやく作成できます。 このトピックでは、現在のリリースで提供される新機能と変更点について説明します。このリリースではレポートの作成とカスタマイズがサポートされています。

このトピックの内容

  • すぐに使用できるレポートとダッシュボード

  • 作業項目クエリからの迅速なレポート生成

  • データ フィールドのレポート属性の変更

  • チーム プロジェクト全体のレポート生成

  • データ ウェアハウスへの変更

  • リレーショナル データベースのレポート生成

すぐに使用できるレポートとダッシュボード

すぐに使用できる多数のレポートのいずれかを使用して、進行状況を表示および追跡できます。これらのレポートは、MSF (Microsoft Solutions Framework) のプロセス テンプレートと共に提供されます。 Team Foundation の旧リリースで提供されていたレポート マネージャーで表示できるレポートに加え、現在のリリースでは、SQL Server Reporting Services に基づく追加のレポートと多数のレポートの Excel バージョンが追加されています。 新しいレポートを使用すると、ストーリーまたは要件、バグの傾向、問題の傾向およびテストの進行状況と生産性の状態を追跡することができます。

MSF プロセス テンプレートの現在のリリースと共に提供されるレポートとダッシュボードの概要については、次の表のトピックを参照してください。

成果物

MSF for Agile Software Development v5.0

  • MSF for CMMI Process Improvement v5.0

レポート マネージャー レポート

レポート (アジャイル)

レポート (CMMI)

Excel レポート

Excel レポート (アジャイル)

Excel レポート (CMMI)

ダッシュボード

ダッシュボード (アジャイル)

ダッシュボード (CMMI)

次の表に、現在のリリースに該当するレポートを示します。レポートは名前が変更されているか、作成し直されています。

旧リリースのレポート

このリリースで該当するレポート

実際の品質と予定速度

"すべてのイテレーションの状態" レポート

"すべてのイテレーションの状態" レポート (CMMI)

速度

バーンダウンと書き込みレート レポート (アジャイル)

バーンダウンと書き込みレート レポート (CMMI)

バグ率

バグの状態レポート

バグ (優先度順)

バグの状態レポート

品質指標

ビルド品質指標レポート

作業項目クエリからのレポートの生成

フラット リスト作業項目クエリで指定したフィルター条件に基づいて現在の状態と履歴データを表示する、複数の Microsoft Excel レポートを生成できます。 これは、選択した基準に従って作業項目の配分を表示したり、過去数週間の傾向を表示したりする場合に便利です。 また、この方法を使用すると、他のレポート ビューをサポートするようにカスタマイズできるピボットテーブル レポートおよびピボットグラフ レポートをすばやく効果的に生成できます。

クエリから Excel レポートを作成するときは、クエリのフィルター処理に使用する変数と選択した条件に基づいて生成するレポートを選択できます。 これらの方法を使用して、次の種類のレポートを生成できます。

  • 現在のレポート: 作業項目クエリで指定したフィルター条件に従って作業項目の数を示す円グラフ。

  • 傾向レポート: 作業項目クエリで指定したフィルター条件に従って、過去 6 週間の作業項目の配分を示す折れ線グラフ。 日付範囲は、レポートの生成後に簡単に変更できます。

各レポートには複数のワークシートが含まれ、それらの各ワークシートに、SQL Server Analysis Services キューブのデータを使用したピボットテーブル レポートおよびピボットグラフ レポートが表示されます。

詳細については、「作業項目クエリを使用した Microsoft Excel でのレポートの作成」を参照してください。

データ フィールドのレポート属性の変更

現在のリリースには、作業項目フィールドの定義に 2 つのレポート属性が追加され、既存のフィールドの属性を変更する機能が追加されています。 追加されたレポート属性は次のとおりです。

  • reportingrefname. reportable として指定されたフィールドに、別の参照名を割り当てることができます。 値を指定しなかった場合は、refname 属性に割り当てられた値が使用されます。

    この属性を使用して、レポートに含まれているフィールドを結合または分岐することができます。 別の参照名があり、かつ別のチーム プロジェクト コレクションで定義された 2 つのフィールドを結合するには、両方に同じ reportingrefname を割り当てる必要があります。 同じ参照名が設定されているが別々のプロジェクト コレクションで定義されている 2 つのフィールドを分岐するには、各フィールドに別々の reportingrefname を設定します。

  • reportingname. レポートにデータを表示するために使用されるフィールドに、別のラベルを割り当てることができます。 値を指定しなかった場合は、name 属性に割り当てられた表示名が使用されます。 reportingname に割り当てられた値は、キューブ内に表示されます。 reportingrefname に割り当てられた値は表示されません。

フィールドへの属性の割り当てを変更するには、witadmin changefield コマンドを使用します。 詳細については、「作業項目フィールドの追加および修正とレポート作成」を参照してください。

チーム プロジェクト コレクション全体のレポート生成

異なるプロジェクト コレクションに保存されている複数のチーム プロジェクトからデータを収集し、レポートを作成できます。 Visual Studio Team Foundation Server の 1 つの配置内の各プロジェクト コレクションで定義されている全チーム プロジェクトのレポート可能データは、すべて 1 つのリレーショナル データ ウェアハウスに書き込まれます。 次に、このデータ ウェアハウスのデータは、処理されて Analysis Services キューブに書き込まれます。 このようにデータを 1 つのデータ ウェアハウスに集めることで、グループ間にまたがるレポートを作成できます。 次の図に、チーム プロジェクトおよびプロジェクト コレクション間にまたがるレポートを生成するときに、使用できるフィルターのいくつかを示します。

ピボットテーブルのチーム プロジェクト フィールド

注意

作業項目フィールドはプロジェクト コレクションごとに別々に管理されるので、別の定義が 1 つ以上のフィールドのレポート属性に割り当てられた場合に競合が発生する可能性があります。 詳細については、「データ ウェアハウスで発生しているスキーマ競合の解消」を参照してください。

データ ウェアハウスへの変更

Team Foundation Server の 1 つの配置内の各プロジェクト コレクションで定義されている全チーム プロジェクトのレポート可能データは、すべて 1 つのリレーショナル データ ウェアハウスに書き込まれます。 次に、このデータ ウェアハウスのデータは、処理されて Analysis Services キューブに書き込まれます。 このようにデータを 1 つのデータ ウェアハウスに集めることで、複数のチーム プロジェクト コレクション間にまたがるレポートを作成できます。

重要

Team Foundation Server の旧バージョンからアップグレードした場合は、アップグレード後のレポートを表示できます。 詳細については、「Team Foundation Server 2010 にアップグレードした後のレポートの場所の確認」を参照してください。

ID 値の一意性

現在のリリースにおけるチーム プロジェクト コレクションの概要で記載しているように、チーム プロジェクトの名前はコレクションで一意である必要があります。 作業項目の ID は、コレクション内でのみ一意ですが、コレクションの配置間にわたっては一意ではありません。 データ ウェアハウスには、すべてのチーム プロジェクト コレクションからのデータが格納されているため、ウェアハウスに対して作業項目のクエリを作成するときは、その作業項目のチーム プロジェクトの GUID も含める必要があります。

スキーマへの変更と追加

現在のリリースでは、多数の変更が Analysis Services キューブのスキーマに対して行われています。 これらの変更により、キューブの利便性、パフォーマンス、変換効率が高まりました。 さらに、Team Foundation Server でサポートされている幅広いインフラストラクチャをサポートするために、およびリンクの種類、カテゴリ、テスト ケースなどの作業項目を追跡するオブジェクトの追加をサポートするために、多くの変更が導入されています。 スキーマに対する変更内容のいくつかは次のとおりです。

  • ディメンションの数は、60 をわずかに超える数から 25 未満に減っています。

  • 旧スキーマ バージョンのディメンションの多くは、"テスト ケース" ディメンションおよび "作業項目" ディメンションの属性になりました。

  • "区分" ディメンションおよび "イテレーション" ディメンションは、真の階層としての "テスト ケース" ディメンションおよび "作業項目" ディメンションの属性として設計変更されました。また、作業項目トラッキング (WIT) 運営ストアによって提供されている深さと同様に 14 レベルの深さになっています。

  • メジャー グループ、メジャー、ディメンションおよび属性の名前が変更されました。

  • 作業項目トラッキングの新機能をサポートするために、新しいディメンションが追加されました。

  • 使い勝手を良くするために、"テスト ケース" ディメンションおよび "作業項目" ディメンションに表示フォルダーが追加されました。 フィールドは、割り当てられている参照名に基づいて、各フォルダーの下にグループ化されます。 ディメンションの属性は、作業項目の種類の定義の中で割り当てられているレポート内参照名に基づいて、各フォルダーに分類されます。

キューブに対するすべての変更と追加の詳細については、「Analysis Services キューブにおけるスキーマに対する修正および追加」を参照してください。

データ ウェアハウスの処理

ウェアハウス コントロール Web サービスを使用すると、データ ウェアハウスを管理できます。 この Web サービスは現在のリリースでは名前が変更され、設計変更されています。 さらに、キューブの既定のリフレッシュ レートは、以前のリリースから変更され、2 時間に設定されました。 この値は、ChangeSetting サービスを使用して変更できます。 詳細については、「データ ウェアハウスと Analysis Services キューブの管理」を参照してください。

リレーショナル データベースのレポート生成

リレーショナル データベースに関するレポートの作成が正式にサポートされました。 通常は、Analysis Services キューブを使用して、履歴レポート、または集計データの複数のパラメーターを分割するのに必要なレポートを使用できます。 キューブは、このようなタイプのレポートの処理に最も適しています。 ただし、リレーショナル データベースは、キューブでは扱えない方法で、関連するデータを大まかに引き出してレポートを作成します。

ビュー

いくつかのパブリック ビューにより、ウェアハウスでの作業がしやすくなりました。 これらのパブリック ビューの名前には、WorkItemHistoryView のように、最後に "View" が付けられています。 次の図に、レポートを生成できるパブリック ビューを示します。

リレーショナル データベースのビュー

注意

"v" で始まり "Overlay" で終わるビューは、キューブの処理に使用されます。 これらのビューは、リレーショナル データベースに基づくレポートを生成するときには使用しないでください。

テーブル名

リレーショナル データベースの現在のバージョンでは、ほとんどのテーブル名が変更されています。 旧バージョンでは、多くのテーブル名に空白が含まれており、いくつかのレポート ツールで問題が発生する原因になっていました。 テーブルの名前が変更されたことにより、データ ウェアハウス内のテーブルと、キューブ内で対応するエンティティとの関連性を容易に判断することができます。

注意

アンダースコア (_) で始まるテーブルは、将来変更される可能性があります。 これらのテーブルは、リレーショナル データベースに基づくレポートを生成するときには使用しないでください。

新しいデータ ウェアハウスでは、名前には空白が含まれません。また、次の表に示すように、用途別にプレフィックスが付けられます。

プレフィックス

説明

dbo.Dim

ディメンション データを含むテーブルで、キューブのディメンション部分にデータが表示されることを意味します。 通常は、ディメンション内の属性または階層ごとに、1 つの列が用意されます。 次の図は、Team Foundation のディメンション テーブルを示しています。

リレーショナル データベースのディメンション テーブル

キューブでは、作業項目のディメンション階層に DimWorkItem テーブルが表示されます。

dbo.Fact

セルの値を格納するファクト テーブルで、キューブ内のメジャーとして表示されます。 次の図は、Team Foundation のファクト テーブルを示しています。

リレーショナル データベースのファクト テーブル

ファクト テーブルには、さまざまなディメンション テーブルへの外部キーがあります。 たとえば、FactWorkItemHistory テーブルには、StateChangeCount という列が格納されます。この列は、作業項目メジャー フォルダー内のメジャーの下にあるキューブに表示されます。

補正レコード

ウェアハウス内の履歴データで作業するときは、補正レコードについて考慮する必要があります。 補正レコードは、WorkItemHistoryView などの履歴情報が含まれるテーブルおよびビューで定義されます。 補正レコードを使用して、データの集計を生成します。

チーム メンバーが作業項目を更新すると、リビジョンが作成され、レコードのペアがウェアハウスに追加されます。 1 つのレコードが最新のレコードを元に戻し、次のレコードが作業項目の変更値を追加します。 それぞれが作業項目の以前のリビジョンを効率的に否定または補正します。

また、補正レコードに関連している列は、System_ChangedDate と System_RevisedDate の 2 つです。 最初の列である System_ChangedDate は、作業項目への変更が行われた日時を示します。 その他の日付は、作業項目が次に変更された日時を示します。 たとえば、タスクを 2009 年 5 月 15 日の 10 時 53 分に作成し、その作業項目を次の日の 11 時 23 分に変更したとします。 レコードは、次の表のように表示されます。

System_ChangedDate

System_RevisedDate

残存作業

RecordCount

10:53 5/15/2009

11:23 5/16/2009

20

1

10:53 5/15/2009

11:23 5/16/2009

-20

-1

11:23 5/16/2009

0:00 1/1/9999

10

1

最初のレコードは、11 時 23 分に変更された元のレコードです。 次のレコードは、最初のレコードを取り消して、3 つ目のレコードとして同じ時刻に追加されました。 最後が現在のレコードで、System_RevisedDate で示されています。これは、DATETIME 列の最大値に設定されています。

Sum ベースのクエリ

特定の日付を起点とした現在の残存作業時間を、次の SUM ベース クエリで示すように設定できます。

SELECT SUM(Microsoft_VSTS_Scheduling_RemainingWork)
  FROM WorkItemHistoryView WHERE System_Id = 108
   AND ProjectNodeGUID = 'A8657108-E085-4DE5-B14C-97DAA378D46E'

SUM ベース クエリを生成できますが、"As Of" クエリを使用するとパフォーマンスがより向上します。

As Of クエリ

特定の日付より前に変更された作業項目ごとに、最後のレコードのみを返す "as of" クエリを作成できます。 たとえば、次の "as of" クエリは、2009 年 5 月 16 日の最後の残存作業時間を返します。

SELECT System_Id, Microsoft_VSTS_Scheduling_RemainingWork
  FROM WorkItemHistoryView WHERE System_ChangedDate < '5/16/2009'
   AND System_RevisedDate >= '5/16/2009'
   AND RecordCount > 0
   AND ProjectNodeGUID = 'A8657108-E085-4DE5-B14C-97DAA378D46E'

この順序は、キューブをクエリするときに返される結果と同じです。 このクエリは、2009 年 5 月 16 日以前に変更された作業項目ごとに、最後のレコードのみを返します。 System_RevisedDate 句は、2009 年 5 月 16 日以前に変更された最後のレコードのみを取得します。これは、この日付以前に変更されると共にこの日付以降に修正された 1 つのレコードを、このクエリが検索するためです。 レコードがまったく変更されていない場合、日付は 9999 年と記録されます。 さらに、このクエリでは、正の RecordCount がテストされます。 直前のレコードを取り消す補正レコードは、常に -1 の RecordCount を持ちます。

参照

概念

Visual Studio ALM のレポートの作成、カスタマイズ、および管理

その他の技術情報

作業項目フィールドの追加および修正とレポート作成

データ ウェアハウスと Analysis Services キューブの管理

Team Foundation Server 2010 にアップグレードした後のレポートの場所の確認

Analysis Services キューブにおけるスキーマに対する修正および追加