Inspection

REVUE ou INSPECTION, IEEE 729 :

Examen détaillé d’une spécification, d’une conception ou d’une implémentation par une personne ou un groupe de personnes, afin de déceler des fautes, des violations de normes de développement ou d'autres problèmes.

• "code walk-throughs";
  pas nécessairement le code; on peut faire l'inspection de n'importe quel document dans la documentation d'un système
• participants :
  • concepteur ou programmeur - responsable pour la production du document ou du programme
  • inspecteur - trouve des erreurs, des lacunes ou des inconsistances dans les documents et programmes
  • lecteur - présente le code ou le document pendant la réunion d'inspection
  • modérateur
  • secrétaire
  • "étranger" - quelqu'un qui n'est pas lié directement au document ou au code inspecté
• discutent comment détecter des erreurs, et non comment en corriger
simulent l’exécution du code
• il est important que les critères d'inspection soient définis au début
• une technique très efficace
• les connaissances du domaine et des techniques de programmation permettent aux inspecteurs de trouver des erreurs qui ont lieu souvent
• l'inspection peut vérifier la conformité avec une spécification mais pas avec les besoins réels du client
• l'inspection ne peut pas vérifier les caractéristiques non-fonctionnelles telles que performance, utilité, etc.

Inspection du code

Exemples des critères qui peuvent être utilisés :

• erreurs de données
  • chaque variable initialisée ?
  • est-ce que les indices dépassent les bornes ?
  • est-ce qu'on compare des valeurs réelles si elles sont égales ?
  • est-ce que le débordement est possible pour chaque buffer ?
• erreurs d'interface
  • est-ce qu'il y a des inconsistances entre les déclarations et les appels ?
• erreurs d'instructions de contrôle
  • un "break" nécessaire après chaque "case" ?
  • tous les cas inclus dans l'instruction "case" ?
  • est-ce que chaque boucle se termine ?
• erreurs de non-respect des standards de codage
  • est-ce que les constantes sont écrites correctement ?
  • est-ce que le rôle de chaque paramètre est défini ?

Classification des défauts

Exemples :

• Défaut grave qui pourrait causer un fonctionnement erroné ou imprévu du programme ou bien des erreurs de compilation.
• Défaut qui rend le programme difficile à comprendre aux lecteurs/inspecteurs.
• Défaut qui rend le code inconfortable pour le lecteur (difficile à lire).
• Défaut qui rend le code peu esthétique.
• Défaut occasionné par une violation des standards de codage.

Vitesse d'inspection

• 500 lignes de code/heure pendant la réunion
• 125 lignes de code/heure pendant la préparation individuelle
• l'inspection de 500 lignes de code coute ~ 40 personne/heure

Attention : l'inspection devrait se concentrer sur les tâches qui ne peuvent pas être automatisés !

Inspection de l'interface d'un module

(lire après le chapitre Méthode de traces)

• Est-ce que les noms des méthodes sont bien choisis ?
• Est-ce que le mode de passage est bien choisi pour chaque argument ?
• Est-ce qu'on trouve une description de l'entrée pour chaque "V" ?
• Est-ce qu'on trouve une description de la sortie pour chaque "O" ?
• Identifier quelques scénarios typiques d'usage de ce module.