Cette section contient la description des tableaux de bord disponibles.
Les tableaux de bord exemple du dossier Dashboard by category contient des raccourcis vers les tableaux de bord exemple. Les véritables tableaux de bord se trouvent dans Sample Report Definitions > Dashboard Definitions.
Tableaux de bord d'administration
Les tableaux de bord d'administration permettent de récapituler des informations de tous les groupes de projets d'une organisation.
Les tableaux de bord sont dans IBM® Cognos Connection, sous Public Folders > Dashboards by Category > Executive dashboards. Les tableaux de bord suivants sont des tableaux de bord exemple au niveau cadre :
- Performances
- Productivité
- Exigence
- Qualité
- Incident
Tableau de bord de performances
Ce tableau de bord contient les rapports suivants :
- Productivity vs project size : ce rapport montre la façon dont la productivité du projet varie au sein de l'organisation avec la taille du projet. Le nuage de points graphique permet de comparer des projets en fonction de la taille relative du code.
- Quality vs project size : ce rapport présente la façon dont la qualité des projets varie au sein de l'organisation (par exemple, mesurée par le nombre d'incidents dans le système) avec la taille du projet. Le nuage de points graphique permet de comparer les projets en fonction de la taille relative du code.
- Time-to-Deliverable vs Project Size : ce rapport montre la façon dont le 'temps d'accès au marché' des projets varie au sein de l'organisation avec la taille du projet. Le temps d'accès au marché représente la durée du projet depuis son démarrage jusqu'à sa date d'édition. Le nuage de points graphique permet de comparer des projets en fonction de la taille relative du code.
Tableau de bord de productivité
Ce tableau de bord contient les rapports suivants :
- Project Cycle : ce rapport montre comment la longueur d'un projet varie en fonction de la taille du projet. Il permet de faire une estimation de la durée de futurs projets et de comprendre l'impact de l'accroissement de l'efficacité dans le travail ou des améliorations au niveau des processus.
- Average SPI & SV : l'index de performances planifié (SPI) permet de mesurer l'utilisation du temps dans une itération ou un projet. Il permet d'identifier les tendances de progression dans une planification. L'écart de planification (SV) indique si un projet est en avance ou en retard par rapport à la planification.
- Project Length : ce rapport présente la longueur de chaque projet (en mois).
Il permet d'identifier les projets pour lesquels une attention peut être requise car la durée d'exécution est plus ou moins longue que celle des autres projets.
- Iteration Velocity : ce rapport présente le nombre de tâches terminées dans chaque itération. Il permet d'identifier la quantité de travail pouvant être effectuée dans chaque cycle d'itérations. Généralement, la courbe doit être relativement constante. Une baisse ou une augmentation importante peut révéler des pressions externes sur le projet. Toutefois, le graphique suppose que la même quantité de travail est requise pour toutes les tâches. L'attribution d'une quantité plus ou moins élevée à des tâches peut avoir des conséquences sur le nombre de tâches réalisées dans une période définie.
- Build Health : ce rapport suit la santé d'une génération de produit au fil du temps.
Il compare le nombre d'intervalles de temps qui sépare un génération ayant échouée d'une génération sans faute.
Tableaux de bord des exigences
Ce tableau de bord contient les rapports suivants :
- Average Enhancement Request Backlog : ce rapport surveille le nombre moyen de demandes d'amélioration reçues et fermées ainsi que le nombre de demandes d'amélioration en attente. Il permet d'accéder au rapport de commandes en attente pour les demandes d'amélioration pour chaque projet.
- Average Requirement Churn : ce rapport indique les tendances pour les modifications apportées à la définition des exigences du système. Il décrit également la stabilité de la définition du système pour un produit.
- Average Defect Repair Latency : ce rapport indique la durée moyenne nécessaire à la résolution des incidents lors du développement et le nombre d'incidents après la livraison. Il présente l'écart moyen entre la reconnaissance et la résolution des incidents.
Tableau de bord de qualité
Ce tableau de bord contient les rapports suivants :
- Average defect by severity : ce rapport indique la qualité du code atteinte lors du développement dans un projet et chaque élément livrable, en fonction du nombre relatif d'incidents et de la taille du code. Ces données contribuent à la densité des incidents par gravité pour chaque projet.
- Average defect backlog : ce rapport indique le nombre d'incidents lors du développement, en fonction du statut des incidents. Vous pouvez voir le nombre d'incidents restants dans le système. Ces données contribuent aux commandes en attente pour les incidents pour chaque projet.
- Average enhancement request backlog : ce rapport surveille le nombre moyen de demandes d'amélioration reçues et fermées ainsi que le nombre de demandes d'amélioration en attente sur une période donnée. Ces données contribuent aux commandes en attente pour les demandes d'amélioration pour chaque projet.
- Average repair latency : ce rapport indique la durée moyenne nécessaire à la résolution des incidents lors du développement et le nombre d'incidents après la livraison.
Il présente l'écart moyen entre la reconnaissance et la résolution des incidents.
Tableau de bord des incidents
Ce tableau de bord contient les rapports suivants :
- Average defect density by severity : ce rapport indique la qualité du code atteinte lors du développement dans un projet et chaque élément livrable, en fonction du nombre relatif d'incidents et de la taille du code. Ces données contribuent à la densité des incidents par gravité pour chaque projet.
- Average defect distribution : ce rapport présente le nombre total d'incidents pour un projet donné. Le nombre total d'incidents indique les projets pouvant inclure des incidents.
- Average defect backlog : ce rapport indique le nombre d'incidents lors du développement, en fonction du statut des incidents. Vous pouvez voir le nombre d'incidents restants dans le système. Ces données contribuent aux commandes en attente pour les incidents pour chaque projet.
- Average fixes failing verification : ce rapport indique le pourcentage d'incidents avec des rapports de correctifs pour lesquels les tests de vérification n'aboutissent pas.
- Average defect repair latency : ce rapport indique la durée moyenne nécessaire à la résolution des incidents lors du développement et le nombre d'incidents après la livraison. Il présente l'écart moyen entre la reconnaissance et la résolution des incidents.
- Build health : ce rapport suit la santé d'une génération de produit au fil du temps.
Il compare le nombre d'intervalles de temps qui sépare un génération ayant échouée d'une génération sans faute.
Tableau de bord au niveau projet
Les tableaux de bord au niveau projet affiche des informations relatives à un projet particulier. Les tableaux de bord sont dans IBM Cognos Connection, sous
Public Folders >
Dashboards by Category >
Project level dashboards. Les tableaux de bord suivants sont des tableaux de bord exemple au niveau projet :
- Productivité
- Exigence
- Exigence des parties prenantes
- Qualité
- Incident
- Détection des incidents
- Prévention des incidents
Tableau de bord de productivité
Ce tableau de bord contient les rapports suivants :
- SPI &SV : l'index de performances planifié (SPI) permet de mesurer l'utilisation du temps dans une itération ou un projet. Il permet d'identifier les tendances de progression dans une planification. L'écart de planification (SV) indique si un projet est en avance ou en retard par rapport à la planification.
- Build health : ce rapport suit la santé d'une génération de produit au fil du temps.
Il compare le nombre d'intervalles de temps qui sépare un génération ayant échouée d'une génération sans faute.
- Project cycle : ce rapport montre comment la longueur d'un projet varie en fonction de la taille du projet. Il permet
d'estimer la durée nécessaire à l'exécution des projets futurs, il permet également de comprendre l'impact de l'augmentation de l'efficacité du travail ou des améliorations du traitement.
- Iteration velocity : ce rapport présente le nombre de tâches terminées dans chaque itération. Il permet d'identifier la quantité de travail pouvant être effectuée dans chaque cycle d'itérations. Généralement, la courbe doit être relativement constante. Une baisse ou une augmentation importante peut révéler des pressions externes sur le projet. Toutefois, le graphique suppose que la même quantité de travail est requise pour toutes les tâches. L'attribution d'une quantité de travail plus ou moins élevée à des tâches peut avoir des conséquences sur le nombre de tâches effectuées dans une période définie.
- Project length : ce rapport présente la longueur de chaque projet (en mois).
Il permet d'identifier les projets pour lesquels une attention peut être requise car la durée d'exécution est plus ou moins longue que celle des autres projets.
Tableaux de bord des exigences
Ce tableau de bord contient les rapports suivants :
- Enhancement request backlog : ce rapport surveille le nombre moyen de demandes d'amélioration reçues et closes ainsi que le nombre de demandes d'amélioration en attente. Ces données contribuent aux commandes en attente pour les demandes d'amélioration pour chaque projet.
- Requirement churn : ce rapport indique les tendances pour les modifications apportées à la définition des exigences du système. Il décrit également la stabilité de la définition du système pour un produit.
- Requirement distribution by status : ce rapport présente la progression des exigences par statut ainsi que le niveau de maturité de la définition du système.
Il indique également la stabilité et le respect complet des exigences du système, avec des impacts potentiels sur la conception et la production.
Tableau de bord des exigences des parties prenantes
Ce tableau de bord contient les rapports suivants :
- Enhancement request backlog : ce rapport surveille le nombre moyen de demandes d'amélioration reçues et closes ainsi que le nombre de demandes d'amélioration en attente. Ces données contribuent aux commandes en attente pour les demandes d'amélioration pour chaque projet.
- Requirement churn : ce rapport indique les tendances pour les modifications apportées à la définition des exigences du système. Il décrit également la stabilité de la définition du système pour un produit.
- Requirement distribution by status : ce rapport présente la progression des exigences par statut ainsi que le niveau de maturité de la définition du système.
Il indique également la stabilité et le respect complet des exigences du système, avec des impacts potentiels sur la conception et la production.
- Test coverage of requirements : ce rapport s'assure que toutes les exigences sont validées et que le produit fonctionne normalement.
- Defects per requirement : ce rapport indique la qualité du code pour chaque type d'exigence.
Tableau de bord de qualité
Ce tableau de bord contient les rapports suivants :
- Defect density by severity : ce rapport indique la qualité du code atteinte lors du développement dans un projet et chaque élément livrable, en fonction du nombre relatif d'incidents et de la taille du code. Ces données contribuent à la densité des incidents par gravité pour chaque projet.
- Defect distribution by severity : ce rapport présente le nombre total d'incidents pour un projet donné. Le nombre total d'incidents indique les composants pouvant inclure des incidents.
- Defect backlog : ce rapport indique le nombre d'incidents lors du développement, en fonction du statut des incidents. Vous pouvez voir le nombre d'incidents restants dans le système.
Ces données contribuent aux commandes en attente pour les incidents pour chaque projet.
- Enhancement request backlog : ce rapport surveille le nombre moyen de demandes d'amélioration reçues et closes ainsi que le nombre de demandes d'amélioration en attente. Ces données contribuent aux commandes en attente pour les demandes d'amélioration pour chaque projet.
- Test execution status : ce rapport indique si les tests planifiés sont terminés ou en attente. Le taux de réussite des tests indique si le système fonctionne correctement.
Tableau de bord des incidents
Ce tableau de bord contient les rapports suivants :
- Defect backlog : Ce rapport indique le nombre d'incidents lors du développement, en fonction du statut des incidents. Vous pouvez voir le nombre d'incidents restants dans le système.
Ces données contribuent aux commandes en attente pour les incidents pour chaque projet.
- Defect density by severity : ce rapport indique la qualité du code atteinte lors du développement dans un projet et chaque élément livrable, en fonction du nombre relatif d'incidents et de la taille du code. Ces données contribuent à la densité des incidents par gravité pour chaque projet.
- Project burndown : ce graphique présente la progression de l'équipe. Il affiche également une vue des tendances des tâches attribuées et exécutées dans une période donnée.
- Test coverage of requirements : ce rapport s'assure que toutes les exigences sont validées et que le produit fonctionne normalement.
- Test execution status : ce rapport indique si les tests planifiés sont terminés ou en attente. Le taux de réussite des tests indique si le système fonctionne correctement.
Tableau de bord de détection des incidents
Ce tableau de bord contient les rapports suivants :
- Defect backlog : ce rapport indique le nombre d'incidents lors du développement, en fonction du statut des incidents. Vous pouvez voir le nombre d'incidents restants dans le système.
Ces données contribuent aux commandes en attente pour les incidents pour chaque projet.
- Defect distribution by severity : ce rapport présente le nombre total d'incidents pour un projet donné. Le nombre total d'incidents indique les composants pouvant inclure des incidents.
- Defect density by severity : ce rapport indique la qualité du code atteinte lors du développement dans un projet et chaque élément livrable, en fonction du nombre relatif d'incidents et de la taille du code. Ces données contribuent à la densité des incidents par gravité pour chaque projet.
- Test coverage of requirements : ce rapport s'assure que toutes les exigences sont validées et que le produit fonctionne normalement.
- Test execution status : ce rapport indique si les tests planifiés sont terminés ou en attente. Le taux de réussite des tests indique si le système fonctionne correctement.
- Code churn : Ce rapport présente le nombre de modifications effectuées dans un projet au fil du temps. Une progression est normale au début et au milieu d'un projet.
Vers la fin de ce dernier, cette tendance doit s'inverser. Dans le cas contraire, le projet ne se stabilise pas.
- Build health : ce rapport suit la santé d'une génération de produit au fil du temps.
Il compare le nombre d'intervalles de temps qui sépare un génération ayant échouée d'une génération sans faute.
Tableau de bord de prévention des incidents
Ce tableau de bord contient les rapports suivants :
- Defect backlog : ce rapport indique le nombre d'incidents lors du développement, en fonction du statut des incidents. Vous pouvez voir le nombre d'incidents restants dans le système.
Ces données contribuent aux commandes en attente pour les incidents pour chaque projet.
- Defect distribution by severity : ce rapport présente le nombre total d'incidents pour un projet donné. Le nombre total d'incidents indique les composants pouvant inclure des incidents.
- Defect density by severity : ce rapport indique la qualité du code atteinte lors du développement dans un projet et chaque élément livrable, en fonction du nombre relatif d'incidents et de la taille du code. Ces données contribuent à la densité des incidents par gravité pour chaque projet.
- Build health : ce rapport suit la santé d'une génération de produit au fil du temps.
Il compare le nombre d'intervalles de temps qui sépare un génération ayant échouée d'une génération sans faute.
- Fixes failing verification : ce rapport indique le pourcentage d'incidents avec des rapports de correctifs pour lesquels les tests de vérification n'aboutissent pas.