Revue de logiciel
Cet article est une ébauche concernant l’informatique.
Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.
La revue de logiciel est « un processus ou une réunion au cours de laquelle un produit logiciel est examiné par l'équipe de projet, les managers, les utilisateurs, clients, utilisateurs référents ou d'autres parties intéressées, pour observations ou d'approbation[1] ».
Revues par les pairs[modifier | modifier le code]
Les revues par les pairs impliquent généralement que les réviseurs aient des connaissances techniques sur le contenu du matériel à vérifier. Il existe différents types de revues par les pairs[2]. Certaines sont encadrées par des normes, comme les inspections[1]. L'efficacité d'une inspection est généralement déterminée par le nombre d'anomalies détectées / le nombre total d'anomalies. Par exemple, on considère que les inspections ont un taux d'efficacité de 80 %, contre 30 % d'efficacité pour les tests (tiré d'une étude d'IBM, 1981).
Voici quelques exemples de types de revues par les pairs:
- Revues Ad hoc : cela peut même être : "tiens, peux-tu relire ce document de 100 pages, quand tu auras 5 minutes"
- Revues desktop review, où un auteur demande à un collègue expérimenté, de relire attentivement un document, dans le but précis d'en relever les anomalies. Il peut utiliser une liste d'inspection ou d'autres méthodes.
- Revues techniques : il s'agit de tenir une réunion d'experts, où l'auteur présente son produit et où les intervenants discutent des anomalies et proposent des pistes de solution.
- Inspection de produit logiciel : il s'agit d'un ensemble d'activités précises, dont le but est d'identifier les anomalies d'un produit. Cette technique inclut obligatoirement un responsable d'inspection/modérateur, un lecteur, un scribe, qui ne doivent pas faire partie des auteurs du produit. Le produit est présenté à l'équipe, ainsi que les outils de vérification (liste de vérification ou autre). Chaque auteur, dans les jours qui suivent, fait une lecture attentive du produit, en notant les anomalies. Par la suite, une réunion permet de mettre en commun les anomalies détectées. Aucune discussion sur les solutions n'est tolérée. Un rapport d'inspection est produit et un suivi des corrections des anomalies est fait. Aucun administrateur ne doit utiliser les résultats de l'inspection pour évaluer l'auteur du produit.
Revues administratives[modifier | modifier le code]
Les revues administratives sont davantage axées sur le suivi administratif, comme la gestion de projet, l'évaluation, etc.
Les revues administratives sont parfois le préalable à la délivrance d'autorisation d'exercice d'une activité. Par exemple, les sites internet de jeux en ligne français doivent être revus par l'ARJEL
Audits[modifier | modifier le code]
Les audits sont effectués par des auditeurs externes à l'organisation.
Difficultés des revues[modifier | modifier le code]
L'une des grandes difficultés des revues est de former les réviseurs. Il ne s'agit pas d'une activité naturelle. Une simple lecture ne suffit pas. Une liste d'inspection aide le réviseur à se concentrer sur quelques aspects à la fois. Cela peut aider. Par exemple, pour vérifier un texte, on commence par vérifier le sens du texte (lecture rapide). On vérifie ensuite la syntaxe. On relit ensuite le texte pour vérifier l'accord des verbes. On relit de nouveau pour l'accord des pluriels, etc. Ces changements de focus constituent justement la bonne technique pour inspecter du code, de la conception, etc.
Document de référence[modifier | modifier le code]
La norme IEEE 1028-2008 Standard for Software Reviews fait référence dans le domaine.
Notes et références[modifier | modifier le code]
- 1028-2008 - IEEE Standard for Software Reviews and Audits
- « Software Reviews » [XpressReviews],
