Nouveautés de la création de rapports pour Visual Studio ALM

Article
08/10/2011

À l'aide de la version actuelle de Visual Studio Team Foundation Server, vous pouvez surveiller des projets d'équipe et suivre la qualité du logiciel en cours de développement en utilisant plusieurs rapports et tableaux de bord par défaut. En outre, vous pouvez créer rapidement des rapports de tendances historiques et actuels à partir de requêtes d'élément de travail. Dans cette rubrique, vous pouvez en apprendre davantage sur les nouvelles fonctionnalités et les modifications fournies dans la version actuelle qui prennent en charge la création et la personnalisation de rapports.

Dans cette rubrique

Rapports et tableaux de bord prédéfinis
Créer rapidement des rapports à partir de requêtes d'élément de travail
Modifier les attributs de création de rapports pour des champs de données
Créer des rapports entre projets d'équipe
Modifications apportées à l'entrepôt de données
Créer des rapports sur la base de données relationnelle

Rapports et tableaux de bord prédéfinis

Vous pouvez afficher et suivre la progression en utilisant l'un des nombreux rapports prédéfinis qui sont fournis avec les modèles de processus Microsoft Solutions Framework (MSF). Outre les rapports que vous pouvez afficher via le Gestionnaire de rapports fourni dans les versions précédentes de Team Foundation, la version actuelle inclut d'autres rapports ainsi que les versions Excel de nombreux rapports reposant sur SQL Server Reporting Services. Les nouveaux rapports vous permettent de suivre l'état des récits ou des spécifications, des tendances des bogues, des tendances des problèmes, ainsi que la progression et la productivité des tests.

Pour une vue d'ensemble des rapports et des tableaux de bord fournis avec la version actuelle des modèles de processus MSF, consultez l'une des rubriques du tableau suivant :

Artefact	MSF for Agile Software Development v5.0	MSF for CMMI Process Improvement v5.0
Rapports du Gestionnaire de rapports	Rapports (Agile)	Rapports (CMMI)
Rapports Excel	Rapports Excel (Agile)	Rapports Excel (CMMI)
Tableaux de bord	Tableaux de bord (Agile)	Tableaux de bord (CMMI)

Le tableau suivant spécifie le rapport comparable fourni dans la version actuelle, qui a été renommé ou retravaillé :

Rapport fourni dans les versions précédentes	Rapport comparable fourni dans présente version
Qualité réelle et rapidité planifiée	Rapport État de toutes les itérations Rapport État de toutes les itérations (CMMI)
Rapidité	Avancement et taux d'avancement, rapport (Agile) Rapport sur l'avancement et le taux d'avancement (CMMI)
Taux de bogue	État des bogues, rapport
Bogues par priorité	État des bogues, rapport
Indicateurs de qualité	Indicateurs de qualité de build, rapport

Générer des rapports à partir de requêtes d'élément de travail

Vous pouvez créer plusieurs rapports dans Microsoft Excel, qui indiquent l'état actuel et des données d'historique, en fonction des critères de filtre que vous spécifiez dans une requête d'élément de travail de liste plate. Ceci est utile pour afficher la distribution des éléments de travail selon les critères sélectionnés ou pour visualiser les tendances des dernières semaines. De plus, cela représente un moyen efficace de générer rapidement des rapports PivotTable et PivotChart que vous pouvez personnaliser pour prendre en charge d'autres vues Rapport.

Lorsque vous créez un rapport Excel à partir d'une requête, vous pouvez choisir les rapports à générer selon les variables utilisées pour filtrer la requête et les critères que vous sélectionnez. Grâce à ces méthodes, vous pouvez générer les types suivants de rapports :

Rapports actuels : graphiques en secteurs qui indiquent le nombre d'éléments de travail en fonction des critères de filtre spécifiés dans la requête d'élément de travail.
Rapports de tendance : graphiques en courbes qui indiquent la distribution des éléments de travail au cours des six dernières semaines en fonction des critères de filtre spécifiés dans la requête d'élément de travail. Une fois les rapports créés, vous pouvez facilement modifier la plage de dates.

Chaque rapport inclut plusieurs feuilles de calcul, et chaque feuille de calcul contient un rapport PivotTable et un rapport PivotChart qui utilise les données du cube de SQL Server Analysis Services.

Pour plus d'informations, consultez Création de rapports dans Microsoft Excel à l'aide de requêtes d'élément de travail.

Modifier les attributs de création de rapports pour des champs de données

Dans la version actuelle, deux attributs de création de rapports ont été ajoutés à la définition de champs d'élément de travail, et il est désormais possible de modifier les attributs d'un champ existant. Les attributs de création de rapports qui ont été ajoutés sont les suivants :

reportingrefname. Vous pouvez assigner un autre nom de référence à un champ marqué comme signalable. Si aucune valeur n'est spécifiée, la valeur assignée à l'attribut refname est utilisée.

Vous pouvez utiliser cet attribut pour fusionner ou différencier des champs inclus dans les rapports. Pour fusionner deux champs ayant des noms de référence distincts et étant définis dans des collections de projets d'équipe différentes, vous assignez le même attribut reportingrefname à ces deux champs. Pour différencier deux champs ayant le même nom de référence et étant définis dans des collections de projets différentes, vous assignez un attribut reportingrefname distinct à chacun d'eux.
reportingname. Vous pouvez assigner une étiquette différente à un champ qui est utilisé pour afficher des données dans les rapports. Si vous ne spécifiez pas de valeur, le nom convivial assigné à l'attribut name est utilisé. La valeur assignée à l'attribut reportingname s'affiche dans le cube. La valeur assignée à l'attribut reportingrefname ne s'affiche pas.

Vous pouvez utiliser la commande witadmin changefield pour modifier une assignation d'attribut à un champ. Pour plus d'informations, consultez Ajout et modification de champs d'éléments de travail pour prendre en charge la création de rapports.

Créer des rapports entre collections de projets d'équipe

Vous pouvez désormais créer des rapports qui contiennent des données collectées à partir de plusieurs projets d'équipe stockés dans différentes collections de projets. Toutes les données signalables issues de tous les projets d'équipe définis dans toutes les collections de projets relatives à un déploiement de Visual Studio Team Foundation Server sont écrites dans un seul et même entrepôt de données relationnelles. Les données de cet entrepôt sont ensuite traitées et écrites dans le cube Analysis Services. La collecte de données dans un seul et même entrepôt de données prend en charge la création de rapports entre groupes. L'illustration suivante présente certains des filtres que vous pouvez utiliser lorsque vous construisez des rapports entre des projets d'équipe et des collections de projets.

Champs de projet d'équipe dans PivotTable

Notes

Étant donné que les champs d'élément de travail sont gérés de façon distincte pour chaque collection de projets, des conflits peuvent se produire lorsque des définitions différentes sont assignées à l'un ou plusieurs des attributs de création de rapports d'un champ. Pour plus d'informations, consultez Résolution de conflits de schéma qui se produisent dans l'entrepôt de données.

Modifications apportées à l'entrepôt de données

Toutes les données signalables issues de tous les projets d'équipe définis dans toutes les collections de projets relatives à un déploiement de Team Foundation Server sont écrites dans un seul et même entrepôt de données relationnelles. Les données de cet entrepôt sont ensuite traitées et écrites dans le cube Analysis Services. La collecte de données dans un seul et même entrepôt de données prend en charge la création de rapports entre collections de projets d'équipe.

Important

Si vous avez effectué une mise à niveau à partir d'une version précédente de Team Foundation Server, vous avez peut-être mis à niveau des rapports que vous pouvez afficher. Pour plus d'informations, consultez Localisation des rapports après la mise à niveau vers Team Foundation Server 2010.

Unicité des valeurs d'ID

Avec les collections de projets d'équipe introduites dans la version actuelle, l'unicité des noms de projets d'équipe n'est requise que dans une collection. Les ID d'éléments de travail ne sont uniques que dans une collection, et non dans le déploiement de collections. Étant donné que l'entrepôt de données contient des données issues de toutes les collections de projets d'équipe, lorsque vous construisez des requêtes pour un élément de travail à partir de l'entrepôt, vous devez également inclure le GUID du projet d'équipe pour cet élément de travail.

Modifications et ajouts apportés au schéma

Dans la version actuelle, plusieurs modifications ont été apportées au schéma pour le cube Analysis Services. Ces modifications ont été apportées afin de faciliter l'utilisation du cube, d'augmenter les performances et d'améliorer la traduction. En outre, de nombreuses modifications ont été ajoutées pour prendre en charge l'infrastructure étendue qui est désormais acceptée par Team Foundation Server et permettre l'ajout d'objets destinés au suivi d'éléments de travail, tels que les types de liens, les catégories et les cas de test. Certaines des modifications apportées au schéma sont les suivantes :

Le nombre de dimensions est passé d'un peu plus de 60 à moins de 25.
De nombreuses dimensions fournies dans les précédentes versions de schéma sont désormais des attributs des dimensions Élément de travail et Cas de test.
Les dimensions Zone et Itération ont été refondues sous la forme d'attributs pour les dimensions Élément de travail et Cas de test comme de vraies hiérarchies et imbriquent 14 niveaux, ce qui est similaire à la profondeur fournie par le magasin opérationnel de suivi des éléments de travail.
De nombreux groupes de mesures, mesures, dimensions et attributs ont été renommés.
De nouvelles dimensions ont été ajoutées pour prendre en charge les nouvelles fonctionnalités relatives au suivi des éléments de travail.
Pour assurer la facilité d'utilisation, des dossiers d'affichage ont été ajoutés aux dimensions Élément de travail et Cas de test. Les champs sont regroupés sous des dossiers en fonction des noms de référence assignés à chacun d'eux. Les attributs de dimension sont organisés dans des dossiers en fonction du nom de référence de création de rapports assigné dans la définition du type d'élément de travail.

Pour une description complète de tous les ajouts et modifications apportés au cube, consultez Modifications et ajouts apportés au schéma pour le cube Analysis Services.

Traitement de l'entrepôt de données

Vous pouvez gérer l'entrepôt de données à l'aide du service Web de contrôle d'entrepôt. Ce service Web a été renommé et refondu dans la version actuelle. En outre, la fréquence d'actualisation par défaut du cube est de deux heures, ce qui constitue un changement par rapport à la version précédente. Vous pouvez modifier cette valeur à l'aide du service ChangeSetting. Pour plus d'informations, consultez Gestion de l'entrepôt de données et du cube Analysis Services.

Créer des rapports sur la base de données relationnelle

La création de rapports sur la base de données relationnelle est désormais officiellement prise en charge. En général, vous souhaiterez utiliser le cube Analysis Services pour des rapports historiques ou pour des rapports dans lesquels il est nécessaire de segmenter plusieurs paramètres de données agrégées. Le cube représente le choix le plus approprié pour gérer ce type de rapport. Toutefois, la base de données relationnelle vous permet de créer des rapports qui rassemblent des données faiblement liées, ce qui n'est pas possible à l'aide du cube.

Vues

De nombreuses vues publiques sont désormais disponibles afin de vous aider à utiliser l'entrepôt. Toutes ces vues publiques portent des noms qui se terminent par « View », comme WorkItemHistoryView. L'illustration suivante représente les vues publiques sur lesquelles vous pouvez créer des rapports.

Vues de la base de données relationnelle

Notes

Les vues qui commencent par « v » et se terminent par « Overlay » sont utilisées pour traiter le cube. Vous ne devez pas utiliser ces vues lorsque vous créez des rapports reposant sur la base de données relationnelle.

Noms des tables

Dans la version actuelle de la base de données relationnelle, la plupart des noms de tables ont été modifiés. Dans les précédentes versions, de nombreux noms de tables comportaient des espaces, ce qui créait des problèmes avec certains outils de création de rapports. Les tables ainsi renommées vous permettent de déterminer plus facilement la connexion entre des tables de l'entrepôt de données et les entités qui leur sont associées dans le cube.

Notes

Les tables qui commencent par un trait de soulignement (_) sont susceptibles d'être modifiées ultérieurement. Vous ne devez pas utiliser ces tables lorsque vous créez des rapports reposant sur la base de données relationnelle.

Dans le nouvel entrepôt de données, les noms ne contiennent pas d'espaces et comportent un préfixe destiné à indiquer leur utilisation, comme décrit dans le tableau suivant.

Préfixe	Description
dbo.Dim	La table contient des données de dimension, ce qui signifie que les données s'afficheront dans la partie des dimensions du cube. Une colonne est généralement fournie pour chaque attribut ou hiérarchie de la dimension. L'illustration suivante représente les tables de dimension de Team Foundation. Dans le cube, la table DimWorkItem s'affiche dans la hiérarchie de dimension sous Élément de travail.
dbo.Fact	Les tables de faits contiennent des valeurs de cellules qui s'affichent comme des mesures dans le cube. L'illustration suivante représente les tables de faits de Team Foundation. Les tables de faits comportent des clés étrangères sur différentes tables de dimension. Par exemple, la table FactWorkItemHistory contient une colonne appelée StateChangeCount qui s'affiche dans le cube sous des mesures, dans le dossier de mesure Élément de travail.

dbo.Dim

La table contient des données de dimension, ce qui signifie que les données s'afficheront dans la partie des dimensions du cube. Une colonne est généralement fournie pour chaque attribut ou hiérarchie de la dimension. L'illustration suivante représente les tables de dimension de Team Foundation.

Tables de dimension de la base de données relationnelle

Dans le cube, la table DimWorkItem s'affiche dans la hiérarchie de dimension sous Élément de travail.

dbo.Fact

Les tables de faits contiennent des valeurs de cellules qui s'affichent comme des mesures dans le cube. L'illustration suivante représente les tables de faits de Team Foundation.

Tables de faits de la base de données relationnelle

Les tables de faits comportent des clés étrangères sur différentes tables de dimension. Par exemple, la table FactWorkItemHistory contient une colonne appelée StateChangeCount qui s'affiche dans le cube sous des mesures, dans le dossier de mesure Élément de travail.

Enregistrements de compensation

Lorsque vous utilisez des données historiques dans l'entrepôt, vous devez tenir compte des enregistrements de compensation. Les enregistrements de compensation sont définis dans les tables et les vues qui comportent des informations historiques, telles que WorkItemHistoryView. Les enregistrements de compensation vous permettent de générer un agrégat de données.

Chaque fois qu'un membre de l'équipe met à jour un élément de travail, une révision est créée et une paire d'enregistrements est ajoutée à l'entrepôt. Un enregistrement annule l'enregistrement précédent le plus récent et l'enregistrement suivant ajoute les valeurs modifiées pour l'élément de travail. Chacun de ces enregistrements inverse ou compense la précédente révision de cet élément de travail.

Les deux colonnes System_ChangedDate et System_RevisedDate sont également associées à des enregistrements de compensation. La première colonne, System_ChangedDate, indique à quel moment l'élément de travail a été modifié. L'autre date indique à quel moment l'élément de travail a été modifié pour la seconde fois. Par exemple, supposons que vous avez créé une tâche à 10 h 53 le 15/05/2009 et que vous avez modifié cet élément de travail à 11 h 23 le jour suivant. Les enregistrements qui s'affichent sont semblables à ceux présentés dans le tableau suivant.

System_ChangedDate	System_RevisedDate	Travail restant	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

Le premier enregistrement, modifié à 11 h 23, était l'enregistrement d'origine. L'enregistrement suivant annule le premier enregistrement et il est ajouté en même temps que le troisième enregistrement. Pour finir, le troisième enregistrement est l'enregistrement actif, comme indiqué dans la colonne System_RevisedDate, qui prend la valeur maximale admise pour une colonne DATETIME.

Requête basée sur une somme

Vous pouvez déterminer le travail restant à effectuer à compter d'une date spécifique, comme indiqué par la requête suivante basée sur une somme.

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

Bien que vous puissiez construire vous-même cette requête basée sur une somme, vous obtiendrez de meilleures performances en utilisant une requête « As Of ».

Requête As Of

Vous pouvez construire une requête « As Of » afin d'obtenir uniquement les derniers enregistrements de chaque élément de travail ayant été modifié avant une date définie. Par exemple, la requête « As Of » suivante renvoie le travail restant à effectuer à compter de la fin de la journée du 16/05/2009.

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'

Vous obtiendriez le même résultat si vous interrogiez le cube. Cette requête renvoie uniquement les derniers enregistrements de chaque élément de travail ayant été modifié avant le 16/05/2009. La clause System_RevisedDate extrait uniquement le dernier enregistrement ayant été modifié avant le 16/05/2009 car la requête trouve l'enregistrement qui a été modifié avant et révisé après cette date. Si l'enregistrement n'a fait l'objet d'aucune révision, la date enregistrée se situe dans l'année 9999. En outre, cette requête effectue des tests pour rechercher un nombre d'enregistrements positif. Les enregistrements de compensation qui annulent un enregistrement précédent ont toujours un nombre d'enregistrements égal à -1.