Inspection de Fagan

L'inspection de Fagan de se rapporte à un processus structuré de l'essai de trouver les défauts dans des documents de développement tels que le code, les caractéristiques, les conceptions et autres de programmation pendant de diverses phases du processus de développement de logiciel de . Elle est baptisée du nom du Michael Fagan qui est crédité d'être l'inventeur des inspections formelles de logiciel de

Définition

L'inspection de Fagan est une méthode de revue de groupe employée pour évaluer le rendement d'un processus donné.

L'inspection de Fagan définit un processus comme certaine activité avec des critères d'une entrée préspécifiée et de sortie. Dans chaque activité ou opération pour lesquelles des critères d'entrée et de sortie sont spécifiés des inspections de Fagan peuvent être employées pour valider si le rendement du processus est conforme aux critères de sortie spécifiques pour le processus. Les exemples des activités pour lesquelles l'inspection de Fagan peut être employée sont :
Spécifications de condition de

Architecture de système de logiciel/information (par exemple DYA )
Programmation (par exemple pour dans des itérations dans XP ou DSDM )
Essai de logiciel (par exemple quand la création de l'essai scripts)

Utilisation

Le processus de développement de logiciel de est une application typique d'inspection de Fagan ; Le processus de développement de logiciel de est une série d'opérations qui livreront un certain produit final et se composent des opérations comme la définition de conditions, conception, codant jusqu'à l'essai et à l'entretien. Comme coûts pour remédier à d'un défaut être jusqu'à 10-100 fois moins dans les opérations tôt comparées à fixer un défaut dans la phase d'entretien qu'il est essentiel de trouver des défauts aussi étroitement au point d'insertion comme possible. Ceci est fait en inspectant le rendement de chaque opération et en comparant cela aux conditions de rendement, ou des Sortie-critères du de cette opération.

Critères

Les critères d'entrée sont les critères ou les besoins qui doivent être répondus pour écrire un processus spécifique 1986. Par exemple pour des inspections de Fagan les documents high-- et de bas niveau doivent être conformes aux entrée-critères spécifiques avant qu'ils puissent être employés pour un procédé formel d'inspection.

Les critères de sortie sont les critères ou les besoins qui doivent être répondus pour compléter un processus spécifique. Par exemple pour des inspections de Fagan le document de bas niveau doit être conforme aux sortie-critères spécifiques (comme spécifique dans le document à niveau élevé) avant que le processus de développement puisse être pris à la phase suivante.

Les sortie-critères sont spécifiés dans un document à niveau élevé , qui est alors employé comme norme pour comparer le résultat d'opération (document de bas niveau ) à pendant les inspections. Des déviations du document de bas niveau des conditions définies dans le document à niveau élevé s'appellent les défauts et peuvent être classées par catégorie dans des défauts importants et des défauts mineurs.

Défauts

Le « un défaut est un exemple dans lequel une condition n'est pas satisfaisante. » 1986

En cours d'inspection de logiciel les défauts qui sont trouvés sont classés par catégorie dans deux catégories : défauts importants et mineurs (souvent beaucoup plus de catégories sont employées). Les défauts qui sont fonctionnalité ou caractéristiques incorrecte ou même absente peuvent être classifiés en tant que défauts importants : le logiciel ne fonctionnera pas correctement quand ces défauts ne sont pas résolus.

Avec des défauts importants, les défauts mineurs ne menacent pas le fonctionnement correct du logiciel, mais contrastent la plupart du temps de petites erreurs comme des erreurs d'épellation dans les documents ou issues optiques comme le positionnement incorrect des commandes dans une interface de programme.

Opérations typiques

Dans une inspection typique de Fagan le procédé d'inspection comprend les opérations suivantes 1986 ; Eickelmann, 2003 :
Planification de

Préparation des matériaux
Arrangement des participants
Arrangement de l'endroit de réunion
Vue d'ensemble
Éducation de groupe des participants au à être matériaux inspectés
Attribution des rôles
Préparation
Les participants préparent leurs rôles
Réunion d'inspection
Conclusion réelle du défaut
Reprise
La reprise est l'étape dans l'inspection de logiciel dans laquelle les défauts trouvés au cours de la réunion d'inspection sont résolus par l'auteur, le concepteur ou le programmeur. Sur la base de la liste de défauts le document de bas niveau est corrigé jusqu'à ce que les besoins dans le document à niveau élevé soient répondus.
Suivi
Dans la phase de suivi des inspections de logiciel tout le défaut trouvé lors de la réunion d'inspection devrait être corrigé (car ils ont été fixés dans la phase de reprise). Le modérateur est responsable de vérifier que c'est en effet le cas. Il devrait vérifier si tous les défauts sont fixes et aucun nouveau défaut n'est inséré tout en essayant de fixer les défauts d'initiale. Il est insignifiant que tous les défauts soient corrigés car les coûts de les fixer dans une phase postérieure du projet seront 10 à 100 fois plus fortement comparées aux coûts courants.

Un écoulement plus complet est disponible aux médias de : Inspection flow.

Un modèle de méta-données est disponible aux médias de : Méta-données Model.png d'inspection de Fagan.

Suivi

Dans la phase de suivi de l'inspection de Fagan de tous les défauts fixes (par l'auteur) dans la phase de reprise devraient être vérifiés. Le modérateur, habituellement, est responsable de la vérifier. Parfois, le travail fixe peut être accepté sans vérifier (quand le défaut était insignifiant), ou le plein processus de reinspection est effectué par l'équipe d'inspection (non seulement le président) quand le défaut était compliqué ou critique.

Si la vérification échoue, retourner pour retoucher le processus ; l'auteur essaye de fixer le défaut encore.

Rôles

Les participants du procédé d'inspection sont normalement juste des membres de l'équipe qui exécute le projet. Les participants remplissent différents rôles dans le procédé 1976 d'inspection :
Auteur/concepteur/codeur de

: la personne qui a écrit le document de bas niveau
Lecteur : paraphrase le document
Appareil de contrôle : examine le document d'un point de vue d'essai
Modérateur : responsable de la session d'inspection, fonctions comme autocar

Avantages et résultats

En employant des inspections la quantité d'erreurs dans les produits finis peut de manière significative diminuer, créant un produit plus de haute qualité. À l'avenir l'équipe pourra même éviter des erreurs car les sessions d'inspection leur donnent la perspicacité dans plus souvent les erreurs faites dans la conception et le codage fournissant l'action d'éviter de l'erreur à la racine de leur occurrence. En améliorant sans interruption l'inspection traiter ces perspicacités peut encore plus loin être employé 1986.

En même temps que les avantages qualitatifs mentionnés au-dessus des « améliorations de coût » importantes peut être atteint comme action d'éviter et une détection plus tôt des erreurs réduira la quantité de ressources requises pour corriger dans des phases postérieures du projet.

Dans la pratique des résultats très positifs ont été rapportés par de grandes sociétés comme IBM indiquant que 80-90% de défauts peut être trouvé et l'épargne dans les ressources jusqu'à 25% peut être atteinte 1986…

Améliorations

Bien que la méthode d'inspection de Fagan se soit avérée très efficace, des améliorations ont été proposées par les chercheurs multiples. Genuchten par exemple avait recherché l'utilisation d'un système (SME) de téléconférence de pour améliorer la productivité des réunions avec les résultats positifs 1997.

D'autres chercheurs proposent l'utilisation du logiciel qui garde une base de données des erreurs détectées et balaye automatiquement le code de programme pour ces erreurs communes. Ceci encore devrait avoir comme conséquence la productivité améliorée.

Exemple

Dans le diagramme un exemple très simple est donné d'un procédé d'inspection dans lequel une deux-ligne morceau de code est inspectée sur la base sur un document à niveau élevé avec une condition simple.

Comme peuvent être vues dans le document à niveau élevé pour ce projet est qui en tout intègrent dans le logiciel des variables produites spécifiques devraient être fortes avoué de `dactylographiées'. Sur la base de cette condition le document de bas niveau est examiné pour déceler les défauts. Malheureusement un défaut est trouvé sur la ligne 1, car une variable n'est pas forte avoué de `dactylographiée'. Le défaut trouvé est alors rapporté dans la liste de défauts fonde et a classé par catégorie selon les catégorisations spécifiques dans le document de bas niveau.

Random links: