Comment doit-on mesurer la Densité de Défauts?

Est-il un moyen standard de mesure de Densité de Défauts? La plupart des sites en ligne de l'état qu'il doit être mesurée:

number of defects discovered /the code size

Mes questions sont:

  • Si des défauts "fixe" au cours de la période de soustraire les défauts découverts?
  • Que doit-on faire avec les défauts de l'un décide de fixer à la suite de la parution, en raison du manque de temps? Si ces carnet de défauts sera ajouté dans la prochaine version de la densité?
  • KLOC dans le dénominateur est probablement pas une bonne mesure si il a été prouvé que le code est inutilement gonflé jusqu'en raison d'une forte duplication. Comment un seul facteur qui?
  • Peut-on corréler le taux de Désabonnement dans une période donnée de temps, et l'arriéré existant de défauts pour un module en particulier, le nombre de défauts créés/découverte à la suite de la le taux de Désabonnement

Notre but ultime est de pouvoir (a) comparer la densité de défauts à l'encontre des normes de l'industrie (b) pour identifier les modules qui sont fragiles et plus buggé et méritent plus d'attention (c) de façon cohérente métrique afin de tracer une ligne de tendance en démontrant de l'amélioration de la qualité d'un module au fil du temps

Le vote pour la fermer comme trop large. Coverity utilise également ce terme comme kloc ratio.

OriginalL'auteur Nishith | 2011-05-20

  1. 1

    Je devine que Defect Density est utilisé pour détecter la vitesse à laquelle votre programmeurs sont de générer des défauts, alors que la soustraction fixe défauts est à voir avec le nombre de plaintes déposées par vos clients/utilisateurs finaux.

    De vos objectifs, (un) semble malsain, (b) est très incisif et versera des dividendes et (c) peuvent induire des faux optimisme.

    Vous devrait vraiment viser pour Zero Defects et vous devriez, pour les métriques fins, ignorer les bugs trouvés et corrigés avant la sortie.

    OriginalL'auteur quamrana

  2. 6

    Densité de défauts est le nombre de cas confirmés de défauts détectés dans le logiciel/module cours d'une période de développement/exploitation divisé par la taille du logiciel/module.
    (défauts de fabrication(confirmée et acceptée (et pas seulement signalé))).

    Densité De Défauts:
    Densité de défauts = Défaut/taille de l'unité

    Question peut se poser ici est: quelle est la taille de l'unité en fait destiné à.
    La taille de l'unité=Taille est généralement comptés ni dans les Lignes de Code ou de Points de Fonction. Un bon programmeur, vous devriez être suffisamment en confiance pour qu'il n'y a pas de chevauchement dans votre codage, ce qui pourrait gonflé de votre taille de code.

    Ex: Supposons que 10 bugs sont trouvés dans 1 KLOC
    Donc DD est de 10/KLOC

    Je suis un peu accroché sur comment faire pour associer un bug avec une particulier de milliers de lignes de code. Par exemple, un communiqué de presse peuvent contenir x lignes de code supplémentaires. Pour mesurer la densité de défauts, est-il nécessaire d'associer bugs confirmés, avec une version particulière? Il semblerait densité de défauts de suivi devient compliqué comme des bugs de versions différentes qui peuvent être signalés lors de futures versions.

    OriginalL'auteur Nishant Singh

  3. 2

    Densité de défauts est utilisé pour la mesure de la qualité du code/module/exigence/produit. Oui, le standard pour mesurer la même chose est
    Densité de défauts = Nombre de Défauts/Taille

    mais ici, si nous utilisons la taille que KLOC (Milliers de lignes de code) ou FP (Points de Fonction), puis il peut être difficile de calculer la même chose et parfois pour le client (ou de certains de prendre titulaires) qu'il n'a pas de sens. Donc, on doit considérer les points suivants aussi bien que le calcul de Densité de Défauts.

    1. Nombre de Défauts doit être calculé en additionnant tous les défauts concernant le code (ces devrait inclure un Examen des Défauts, des insectes Internes et Client/UAT bugs aussi) parce que tous les bugs sont liés à code et donc devrait être une partie de la densité de Défauts.
    2. Égalisé les Défauts de comptage en fonction de leur Gravité, avant de les ajouter, ce qui donne un résultat plus précis et c'est un standard aussi. On peut le considérer comme Bug Critique = 5, Élevée = 3, Moyenne = 1, Bas = 0.5. Ce qui est parfois appelé comme Pondérée en Densité de Défauts, mais il est plus précis dans les résultats.
    3. Taille ne devrait pas être limitée aux seules Lignes de Code ou de Points de Fonction. Il peut être pas. des exigences trop. La plus simple et efficace est de prendre la taille que le temps passé dans le codage (ce qui ne devrait pas inclure l'Examen du Code, Codage Retravailler effort). Ainsi, la Densité de Défauts peuvent être considérées comme des Défauts par 100 Jours de l'effort dépensé dans le codage, et si vous avez un projet objectif spécifié, vous pouvez voir si cela répond à votre objectif ou pas.

    C'est un moyen efficace et facile méthode de calcul de la Densité de Défauts, avec la période de temps, vous pouvez voir si vous êtes l'amélioration ou pas.

    OriginalL'auteur Dhiman

  4. 0

    Défaut est, en principe,lorsque le produit est expédié au client après que toutes les fonctionnalités ne fonctionne pas ou vous pouvez dire la déviation à partir des exigences de l'utilisateur, vous ne pouvez pas mesurer défaut, mais vous pouvez prendre certaines mesures pour éviter de se faire défaut,il peut être fait par différentes à l'essai des façons,certains de importante est, vous trouverez ci-dessous :

    • Test De Détection De Fumée
    • La Santé Mentale Des Tests
    • Boîte noire Test
    • Blanc Test
    • Charge de travail et Stress Tests

    Vous devez avoir une connaissance complète de ce que votre client est à demander auprès de vous,il vous aidera à vous empêcher de défaut.

    Cela ne semble pas répondre aux questions posées - le demandeur n'est pas à la recherche de moyens de prévention des défauts, mais à la recherche d'informations relatives à la mesure/comparaison des métriques

    OriginalL'auteur Syed Aamir Fatimi

  5. 0
    total number detected defects in your developed software divided by size of your software in line of code . it is calculated in KLOC ,it means it is multiply by 1000 
for example
defects found are 12
size is 2000
defect density= defects/size
answer=.006
it is calculated in kloc so .006*1000=6 so defect density is 6

    OriginalL'auteur rao kaleemuallah