Mesures de la qualité des logiciels

Les mesures logicielles peuvent être classées en trois catégories -

  • Product metrics - Décrit les caractéristiques du produit telles que la taille, la complexité, les caractéristiques de conception, les performances et le niveau de qualité.

  • Process metrics - Ces caractéristiques peuvent être utilisées pour améliorer les activités de développement et de maintenance du logiciel.

  • Project metrics- Ces métriques décrivent les caractéristiques et l'exécution du projet. Les exemples incluent le nombre de développeurs de logiciels, le modèle de dotation en personnel tout au long du cycle de vie du logiciel, le coût, le calendrier et la productivité.

Certaines métriques appartiennent à plusieurs catégories. Par exemple, les mesures de qualité en cours d'un projet sont à la fois des mesures de processus et des mesures de projet.

Software quality metricssont un sous-ensemble de mesures logicielles qui se concentrent sur les aspects qualité du produit, du processus et du projet. Celles-ci sont plus étroitement associées aux métriques de processus et de produit qu'aux métriques de projet.

Les mesures de la qualité des logiciels peuvent être divisées en trois catégories:

  • Mesures de qualité des produits
  • Mesures de qualité en cours de processus
  • Mesures de qualité de la maintenance

Mesures de qualité des produits

Ces métriques incluent les éléments suivants -

  • Temps moyen jusqu'à l'échec
  • Densité de défaut
  • Problèmes des clients
  • Satisfaction du client

Temps moyen jusqu'à l'échec

C'est le temps entre les échecs. Cette métrique est principalement utilisée avec les systèmes critiques pour la sécurité tels que les systèmes de contrôle du trafic aérien, l'avionique et les armes.

Densité de défaut

Il mesure les défauts par rapport à la taille du logiciel exprimés en lignes de code ou en point de fonction, etc. c'est-à-dire qu'il mesure la qualité du code par unité. Cette métrique est utilisée dans de nombreux systèmes logiciels commerciaux.

Problèmes des clients

Il mesure les problèmes rencontrés par les clients lors de l'utilisation du produit. Il contient le point de vue du client sur l'espace des problèmes du logiciel, qui comprend les problèmes orientés sans défaut ainsi que les problèmes de défaut.

La métrique des problèmes est généralement exprimée en termes de Problems per User-Month (PUM).

PUM = Total Problems that customers reported (true defect and non-defect oriented 
problems) for a time period + Total number of license months of the software during 
the period

Où,

Number of license-month of the software = Number of install license of the software × 
Number of months in the calculation period

Le PUM est généralement calculé pour chaque mois après la mise sur le marché du logiciel, ainsi que pour des moyennes mensuelles par année.

Satisfaction du client

La satisfaction du client est souvent mesurée par les données d'enquête client sur l'échelle de cinq points -

  • Très satisfait
  • Satisfied
  • Neutral
  • Dissatisfied
  • Très insatisfait

La satisfaction quant à la qualité globale du produit et à ses dimensions spécifiques est généralement obtenue grâce à diverses méthodes d'enquêtes clients. Sur la base des données d'échelle à cinq points, plusieurs mesures avec de légères variations peuvent être construites et utilisées, en fonction de l'objectif de l'analyse. Par exemple -

  • Pourcentage de clients entièrement satisfaits
  • Pourcentage de clients satisfaits
  • Pourcentage de clients insatisfaits
  • Pourcentage de clients non satisfaits

Habituellement, ce pourcentage de satisfaction est utilisé.

Mesures de qualité en cours

Les mesures de qualité en cours de traitement concernent le suivi de l'arrivée des défauts lors des tests de machine formels pour certaines organisations. Cette métrique comprend -

  • Densité des défauts lors des tests de la machine
  • Motif d'arrivée des défauts lors des tests de la machine
  • Modèle d'élimination des défauts par phase
  • Efficacité d'élimination des défauts

Densité des défauts lors des tests de la machine

Le taux de défauts pendant les tests formels de la machine (test après l'intégration du code dans la bibliothèque système) est corrélé avec le taux de défauts sur le terrain. Des taux de défauts plus élevés trouvés lors des tests indiquent que le logiciel a subi une injection d'erreur plus élevée au cours de son processus de développement, à moins que le taux de défauts de test plus élevé ne soit dû à un effort de test extraordinaire.

Cette simple métrique de défauts par KLOC ou point de fonction est un bon indicateur de qualité, alors que le logiciel est encore en cours de test. Il est particulièrement utile de surveiller les versions ultérieures d'un produit dans la même organisation de développement.

Motif d'arrivée des défauts lors des tests de la machine

La densité globale des défauts pendant les tests ne fournira que le résumé des défauts. Le schéma des arrivées de défauts donne plus d'informations sur les différents niveaux de qualité sur le terrain. Il comprend les éléments suivants -

  • Les arrivées de défauts ou les défauts signalés pendant la phase de test par intervalle de temps (par exemple, semaine). Ici, tous ne seront pas des défauts valables.

  • Le modèle des arrivées de défauts valides lorsque la détermination du problème est effectuée sur les problèmes signalés. C'est le vrai motif de défaut.

  • Le modèle de retard dans l'arriéré de défauts. Cette métrique est nécessaire car les organisations de développement ne peuvent pas rechercher et résoudre immédiatement tous les problèmes signalés. Ceci est une déclaration de charge de travail ainsi qu'une déclaration de qualité. Si le backlog de défauts est important à la fin du cycle de développement et que de nombreux correctifs doivent encore être intégrés dans le système, la stabilité du système (d'où sa qualité) sera affectée. Un nouveau test (test de régression) est nécessaire pour garantir que les niveaux de qualité des produits ciblés sont atteints.

Modèle d'élimination des défauts par phase

Il s'agit d'une extension de la métrique de densité de défaut pendant les tests. En plus des tests, il suit les défauts à toutes les phases du cycle de développement, y compris les revues de conception, les inspections de code et les vérifications formelles avant les tests.

Étant donné qu'un pourcentage élevé de défauts de programmation est lié à des problèmes de conception, la réalisation d'examens formels ou de vérifications fonctionnelles pour améliorer la capacité de suppression des défauts du processus en amont réduit les erreurs dans le logiciel. Le modèle d'élimination des défauts par phase reflète la capacité globale d'élimination des défauts du processus de développement.

En ce qui concerne les paramètres pour les phases de conception et de codage, en plus des taux de défauts, de nombreuses organisations de développement utilisent des paramètres tels que la couverture d'inspection et l'effort d'inspection pour la gestion de la qualité en cours de processus.

Efficacité d'élimination des défauts

Il peut être défini comme suit -

$$ DRE = \ frac {Défaut \: supprimé \: pendant \: a \: développement \: phase} {Défauts \: latent \: in \: the \: product} \ times 100 \% $$

Cette métrique peut être calculée pour l'ensemble du processus de développement, pour le front-end avant l'intégration du code et pour chaque phase. On l'appelleearly defect removal lorsqu'il est utilisé pour le front-end et phase effectivenesspour des phases spécifiques. Plus la valeur de la métrique est élevée, plus le processus de développement est efficace et moins il y a de défauts passés à la phase suivante ou sur le terrain. Cette métrique est un concept clé du modèle de suppression des défauts pour le développement logiciel.

Mesures de qualité de la maintenance

Bien que beaucoup ne puisse pas être fait pour altérer la qualité du produit au cours de cette phase, voici les correctifs qui peuvent être effectués pour éliminer les défauts le plus rapidement possible avec une excellente qualité de réparation.

  • Correction de l'index de gestion du backlog et du backlog
  • Correction du temps de réponse et correction de la réactivité
  • Pourcentage de corrections en souffrance
  • Correction de la qualité

Correction de l'index de gestion du backlog et du backlog

L'arriéré de correctifs est lié au taux d'arrivée des défauts et au taux auquel les correctifs pour les problèmes signalés deviennent disponibles. Il s'agit d'un simple décompte des problèmes signalés qui subsistent à la fin de chaque mois ou de chaque semaine. En l'utilisant sous la forme d'un graphique de tendance, cette métrique peut fournir des informations utiles pour la gestion du processus de maintenance.

L'indice de gestion du backlog (IMC) est utilisé pour gérer l'arriéré de problèmes ouverts et non résolus.

$$ IMC = \ frac {Nombre \: de \: problèmes \: fermé \: pendant \: le \: mois} {Nombre \: de \: problèmes \: arrivé \: pendant \: le \: mois} \ fois 100 \% $$

Si l'IMC est supérieur à 100, cela signifie que l'arriéré est réduit. Si l'IMC est inférieur à 100, l'arriéré a augmenté.

Correction du temps de réponse et correction de la réactivité

La métrique du temps de réponse du correctif est généralement calculée comme le temps moyen de tous les problèmes entre l'ouverture et la fermeture. Le temps de réponse court des correctifs conduit à la satisfaction du client.

Les éléments importants de la réactivité des correctifs sont les attentes du client, le temps de réparation convenu et la capacité à respecter son engagement envers le client.

Pourcentage de corrections en souffrance

Il est calculé comme suit -

$ Pourcentage \: Delinquent \: Fixes = $

$ \ frac {Nombre \: de \: corrections \: que \: a dépassé \: la \: réponse \: heure \: critères \: par \: ceverity \: level} {Nombre \: de \: corrections \: livré \: dans \: a \: spécifié \: heure} \ fois 100 \% $

Corriger la qualité

La qualité des correctifs ou le nombre de correctifs défectueux est une autre mesure de qualité importante pour la phase de maintenance. Un correctif est défectueux s'il n'a pas résolu le problème signalé ou s'il a résolu le problème d'origine mais a injecté un nouveau défaut. Pour les logiciels critiques, les correctifs défectueux nuisent à la satisfaction du client. La métrique du pourcentage de correctifs défectueux correspond au pourcentage de tous les correctifs dans un intervalle de temps défectueux.

Un correctif défectueux peut être enregistré de deux manières: enregistrez-le le mois où il a été découvert ou enregistrez-le le mois où le correctif a été livré. Le premier est une mesure client; la seconde est une mesure de processus. La différence entre les deux dates est la période latente du correctif défectueux.

Habituellement, plus la latence est longue, plus les clients seront affectés. Si le nombre de défauts est grand, la petite valeur de la métrique de pourcentage affichera une image optimiste. L'objectif de qualité pour le processus de maintenance, bien sûr, est de zéro correctif défectueux sans délinquance.