Rapports de contrôle des changements

Cette catégorie contient des rapports qui vous aident à contrôler et à gérer des changements qui se produisent en cours de projet. Les rapports permettent d'évaluer la santé du projet et d'entreprendre des actions correctives de façon proactive grâce à la surveillance de paramètres, comme le nombre de ligne de code, le nombre d'incidents et la façon dont ces nombres varient durant les étapes du projet.

Les rapports exemple suivants sont disponibles :

Renouvellement de code

Ce rapport montre l'évolution du volume de code selon des tendances du 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.

Contributions de code

Ce rapport affiche le volume de code produit par chaque développeur. Il est important de connaître les contributions apportées par des personnes à un projet. Généralement, les tâches doivent être réparties de manière équitable au sein de l'équipe. Si une personne effectue plus ou moins de tâches que les autres et ce de façon significative, il peut être nécessaire de revoir la planification du projet. Notez que ce rapport ne tient pas compte de facteurs comme d'autres responsabilités, la difficulté relative du travail et les congés.

Fréquence d'arrivée des incidents

Ce rapport indique la fréquence de soumissions de nouveaux incidents au fil du temps, classés par gravité. Généralement, le nombre d'incidents doit progresser au début du projet, puis doit diminuer à mesure que le projet se rapproche de sa réalisation. Les lignes d'incident doivent au moins montrer cette tendance, si ce n'est pas le cas, le projet ne se stabilise pas.

Distribution des incidents

Ce rapport présente le nombre d'incidents par composant dans un projet. Une courbe en progression peut signaler une zone d'incident à examiner ou peut être due à des tests plus poussés. De la même manière, une valeur faible peut indiquer une bonne qualité ou des tests insuffisants. Les courbes doivent généralement baisser à mesure que le projet progresse.

Taux d'échec de vérification des incidents

Un "échec de vérification" est un incident qui a été résolu mais qui a dû être ouvert à nouveau car il n'a pas été résolu complètement. Un nombre croissant ou élevé peut indiquer un problème de communication au sein de l'équipe.

SLOC par composant

Ce rapport présente le nombre de lignes de code source (SLOC) pour chaque composant. Il vous aide à vérifier que la taille du code est raisonnable et proche de la valeur attendue pour ce composant.