PLAN D’ASSURANCE QUALITÉ LOGICIEL

TRAVAIL PRÉSENTÉ À MME SOUMAYA CHERKAOUI

DANS LE CADRE DU COURS GEI450, PROJET DE CONCEPTION DE LOGICIELS

PAR L'ÉQUIPE SOKRATE : SIMON BÉLANGER

YANNICK BROSSEAU NICOLAS HATIER

CATHERINE PROULX FRANÇOIS TREMBLAY

LE 25 JUILLET 2001

Université de Sherbrooke

PLAN D’ASSURANCE QUALITÉ LOGICIEL Table des matières

1 But D-1

2 Documents de référence D-1

3 Gestion D-1 3.1 Organisation ...........................................................................................................D-1 3.2 Tâches ...................................................................................................................D-1 3.3 Responsabilités .......................................................................................................D-1

4 Documentation D-2 4.1 But ........................................................................................................................D-2 4.2 Documentation minimale exigée...............................................................................D-2 4.3 Autres ....................................................................................................................D-2

5 Standards, pratiques, conventions et métriques D-2 5.1 But ........................................................................................................................D-2 5.2 Contenu .................................................................................................................D-2

6 Revues et Audits D-4 6.1 But ........................................................................................................................D-4 6.2 Exigences minimales ...............................................................................................D-4 6.2.1 Revue des exigences logicielles...............................................................................................D-4 6.2.2 Revue de design préliminaire ..................................................................................................D-4 6.2.3 Revue de design critique ........................................................................................................D-4 6.2.4 Revue de PVVL ......................................................................................................................D-4 6.2.5 Audit fonctionnel....................................................................................................................D-4 6.2.6 Audit physique.......................................................................................................................D-4 6.2.7 Audit en préparation ..............................................................................................................D-4 6.2.8 Revue de gestion ...................................................................................................................D-5 6.2.9 Revue PGCL...........................................................................................................................D-5 6.2.10 Revue finale ..........................................................................................................................D-5 6.3 Inspections.............................................................................................................D-5

7 Test D-5

8 Notification des problèmes et corrections D-5

9 Outils, techniques et méthodologies D-6

10 Contrôle du code D-6

11 Contrôle des médias D-6

12 Contrôle des fournisseurs D-6

13 Collecte, maintenance et conservation des archives D-6

14 Formation D-6

15 Gestion du risque D-6

D-1

1 But Ce document décrit le plan par lequel le projet Sokrate concoit un produit de qualité, ceci inclus la maintenance de Sokrate. Le PAQL applique la norme IEEE 730-1989. Acronymes : AQ : Assurance Qualité GC : Gestion de la configuration SGC : Système de gestion de la configuration V&V : Validation et vérification

2 Documents de référence [BRAUDE] A.J. Braude, Software Engineering, An Object-Oriented Perspective. Wiley, 2001. Autres documents à la section 4.2

3 Gestion

3.1 Organisation Chacun des membres de l’équipe est responsable de la qualité de son travail. De plus, chaque membre se verra attribué un vérificateur qui aura la tâche de réviser et analyser le produit développé par le membre. Voir la section 2.2 du PGPL.

3.2 Tâches Les tâches de l’AQ incluent :

Documentation Rencontre pour revues Vérification et inspections Validation et tests Activités d’amélioration du processus d’AQ

Ces tâches sont définies dans ce document.

3.3 Responsabilités Il est de la responsabilité du responsable d’AQ de veiller à ce que les tâches décrites à la section 3.2 soient effectuées. Le chef de projet est responsable de s’assurer qu’une gestion de qualité sera effectuée. Le responsable des spécifications est responsable de produire des exigences claires, précises et qui répondent au fonctionnement du produit. Le responsable du design a la responsabilité de s’assurer que le produit est conçu de manière à permettre une conception qui respecte les standards du projet tout en permettant de faire facilement la maintenance du produit.

D-2

Le responsable de la GC a la responsabilité de veiller à ce que le projet compile en tout temps et que les fichiers le constituant répondent aux standards du groupe.

4 Documentation

4.1 But Le but de cette section est de définir la documentation utilisée afin d’assurer la qualité du produit.

4.2 Documentation minimale exigée Les documents suivant seront produits :

• PAQL : Le plan d’assurance qualité logiciel • PGCL : Le plan de gestion de la configuration logicielle • PGPL : Le plan de gestion de projet logiciel • PVVL : Le plan de validation et vérification logiciel • SELC : Spécification externe du logiciel orienté client • SELD : Spécification externe du logiciel orienté développeur • SILA : Spécification interne du logiciel, l’architecture • SILD : Spécification interne du logiciel, conception détaillée • DDL : Le document de design logiciel • DTL : Le document de tests logiciels • Manuel de l’utilisateur • Plan de maintenance

4.3 Autres Cette section est non-applicable.

5 Standards, pratiques, conventions et métriques

5.1 But Cette section décrit les standards, pratiques, conventions et métriques utilisés pour le projet Sokrate. Ceux-ci ont pour but d’assurer la qualité du logiciel tout en fournissant des donnés quantitatives sur le processus d’AQ.

5.2 Contenu Standards :

Le standard utilisé pour le code source sera celui décrit dans le document « Normes de code de l’équipe Sokrate » mis en annexe 1 de ce document. Aussi, la rédaction des documents doit être faite selon le standard décrit dans le document « Normes de documentation de l’équipe Sokrate » mis en annexe 2 de ce document.

D-3

Pratiques : • Afin de permettre d’intégrer un maximum de fonctionnalités pendant le projet, il est recommandé

d’adopter les préceptes de qualité immédiatement au lieu de revenir effectuer les changements puisque ceux-ci forceront des délais.

• Tous les documents seront inspectés et seront tous mis à la disponibilité des membres de l’équipe dès qu’ils sont développés. Ceci est effectué en mettant les documents sous l’égide de la GC.

• Chaque projet ou sous-projet devra être ajouté dans le logiciel de gestion du projet pour permettre son évolution et connaître le responsable de l’activité.

• Chaque développeur est responsable de faire réviser, sur une base hebdomadaire, son code par le vérificateur qui lui est assigné. Les changements à apporter devront être effectués par le développeur.

• Les erreurs dans une section développée seront comptabilisées pour le développeur responsable à partir du moment où le fichier sera déposé dans le SGC. Ces valeurs seront utilisées pour calculer le ratio d’erreur contre le ratio tolérable.

• La version finale (après révision et approbation) de chaque document est produite en format DOC et PDF, et devront être déposés dans le SGC.

Conventions :

Les lignes de code comptabilisées sont toutes les lignes effectives, c’est-à-dire toutes les lignes qui peuvent être tracés au cours d’une exécution. Par exemple, les « if », « else », « while », toutes les lignes se terminant par un point virgule compte comme une ligne effective. Afin d’inciter les développeurs à produire du code de qualité, les assertions (assert) sont comptabilisés parmi les lignes effectives.

Métriques : Au moins trois métriques sont conservés pour chacun des projets, sous-projets, tâches et sous-tâches dans le logiciel de gestion de projet.

• Le temps consacré à une tâche par un membre de l’équipe. • Nombre de défauts par lignes de code après dépôt. • Les résultats obtenus sur les livrables.

Les objectifs de qualité pour Sokrate à la livraison sont décrites comme suit : Obtenir une évaluation supérieure ou égale à 90 % de la note maximale pour l’évaluation. Détectées à partir du lancement jusqu’à la livraison : Exigences : une erreur mineure par 40 exigences. Design : Pas plus d’une erreur par dix diagrammes. Code : Pas plus d’une erreur de haute priorité par 200 lignes de code

Pas plus de deux erreurs de moyenne priorité par 200 lignes de code. Pas plus de huit erreurs de faible priorité par 200 lignes de code.

Détectées après la livraison : Code : Pas plus de deux erreurs par 500 lignes de code (toutes priorités confondues) Les niveau de priorités sont définis à la section 8. Les données métriques de ce projet sont rapportés dans les journaux de bord de chaque membre.

D-4

6 Revues et Audits

6.1 But Le but de cette section sur les revues et les audits est de fournir un moyen de centrer l’attention des développeurs sur la qualité de leur application en cours de développement.

6.2 Exigences minimales

6.2.1 Revue des exigences logicielles C’est une révision complète du document des exigences en présence de toute l’équipe. La revue sera dirigée par le chef de projet et sa planification sera sous sa responsabilité. Il est présumé que les exigences auront été préalablement révisées à la présentation du brouillon ainsi qu’à la présentation de la version intermédiaire.

6.2.2 Revue de design préliminaire C’est une revue des architectures alternatives du projet en présence de toute l’équipe. Cette rencontre sera dirigée par le chef de projet. Il est attendu que les membres fourniront des suggestions de design dont les résultats se reflèteront dans le design final. Le chef du design aura la responsabilité de voir à ce que cette revue soit faite.

6.2.3 Revue de design critique Cette étape est une inspection de l’architecture proposée en présence de toute l’équipe. Le chef du design a la responsabilité de voir à ce que ces inspections soient effectuées. Une inspection de base de l’architecture doit être faite avant cette revue. Le chef de design choisira, selon l’importance de l’architecture, le ou les membres pour faire l’inspection. Chaque élément d’architecture devrait être décomposé en sous éléments d’architecture pour faciliter et assurer la qualité de la revue.

6.2.4 Revue de PVVL La revue de V&V doit être faite en présence de tous les membres de l’équipe. Cette rencontre est la responsabilité du responsable de l’AQ. Une attention particulière devrait être portée par les évaluateurs pour valider et vérifier les cas particuliers.

6.2.5 Audit fonctionnel Avant la livraison du produit, le chef de projet est responsable de s’assurer que le produit développé correspond aux exigences dans le document des spécifications.

6.2.6 Audit physique Avant chaque livrable, le responsable de l’AQ a la responsabilité de s’assurer que le logiciel ainsi que la documentation appropriée soit bel et bien livrés.

6.2.7 Audit en préparation Puisque Sokrate est un petit groupe avec des projets à courtes échéances, il n’y aura pas d’audits en préparation

D-5

6.2.8 Revue de gestion À chaque deux semaines le chef de projet doit faire une revue avec tous les membres de l’équipe pour vérifier le bon fonctionnement de la gestion du projet.

6.2.9 Revue PGCL La revue du document PGCL se fera telle que décrite à la section 3.4 du PGCL.

6.2.10 Revue finale Afin de fournir des renseignements utiles pour des projets ultérieurs et de fournir une revue du processus d’AQ lui même, la revue finale doit être effectuée après la livraison. Le chef de l’AQ devra produire un document d’amélioration des phases d’AQ.

6.3 Inspections Tous les documents produits par le groupe Sokrate seront inspectés par au moins une personne de l’équipe selon le processus décrit à la section 2.2 du PGPL. Ces inspections incluent la revue de code ainsi que celle des documents.

7 Test Au cours du processus de mise en oeuvre, chaque développeur doit procéder à des tests préliminaires sur la section développée avant de soumettre celle-ci (tests sommaires). À chaque label, le responsable de l’AQ doit s’assurer que les tests complémentaires appropriés sont effectués (Se référer à Braude Chapitre 8 et 9 pour de plus amples renseignements sur ces types de tests). Les tests détaillés du projet sont disponible dans le DTL.

8 Notification des problèmes et corrections La notification des problèmes, à toute étape du processus de développement, se fait dans le logiciel de gestion du projet sous le projet « Rapports de Problèmes », et ce par chacun des membres de l’équipe. Pour rapporter une défectuosité, le développeur doit ajouter une tâche dans le projet « Rapports de Problèmes » contenant les éléments suivants :

• Le numéro du problème • Le nom du découvreur du problème • Le fichier en cause • Les parties du code affectées • Le niveau de priorité (H, M, F) • La description du problème • Les suggestions de résolution (s’il y a lieu) • Le nom du responsable de sa résolution (TBA si cette personne est non-identifiable)

Le pourcentage de résolution doit être mis à jour selon l’évolution de la résolution du problème. Un gabarit de rapport de problème est mis à la disposition des développeurs dans le logiciel de gestion du projet. Les différents niveaux de priorité sont H : Haute, M : Moyenne et F : Faible. Elles sont définies comme suit :

• Haute : Faille critique qui interrompt le fonctionnement normal du logiciel

D-6

• Moyenne : Les spécifications ne sont pas satisfaites • Faible : Problème n’étant pas de Haute ou de Moyenne priorité

L’AQ recommande d’enregistrer tous les problèmes dès que ceux-ci ne seront pas réglés par le développeur, et ceci, indépendamment du niveau de priorité du problème. Le responsable de l’AQ a la tâche de veiller à ce que les problèmes soient rapportés, réparés et mis à jour dans le logiciel de gestion du projet. Il doit également s’assurer que l’équipe de développeurs vérifient fréquemment la liste de problèmes. Le chef de projet doit veiller à ce que les tâches soient équitablement distribués afin que la résolution des problèmes correspondent à la planification du projet décrite dans le PGPL.

9 Outils, techniques et méthodologies L’AQ utilisera des listes de vérifications pour vérifier la qualité de tout document (incluant le code source). Les listes de vérifications utilisés sont celles contenues dans Braude et référés en tant que « On way to… ». Au besoin, l’AQ pourra ajouter des listes de vérifications.

10 Contrôle du code Les méthodes utilisées pour maintenir, entreposer, sauvegarder et documenter les différentes versions du code lors de chacune des phases de la conception sont décrites dans le PGCL. Le responsable de la GC doit vérifier que les procédures décrites dans le PGCL sont respectés par tous les développeurs.

11 Contrôle des médias Le responsable de l’AQ doit s’assurer que les médias utilisés sont construits et configurés conformément au PGCL. Aussi, l’AQ doit s’assurer que les copies de sauvegarde sont régulièrement effectuées conformément au PGCL.

12 Contrôle des fournisseurs Cette section est non-applicable.

13 Collecte, maintenance et conservation des archives Le responsable de l’AQ doit conserver tout document qui servira au maintient des règles d’AQ tels que mémos, rapports de tests, etc. De ces documents, ceux disponibles en version électronique devront être inclus dans le SGC.

14 Formation Si des compétences requises pour le projet ne sont pas maîtrisées par suffisamment de membres dans l’équipe, les membres verront à acquérir ces compétences requises par le biais de lectures ou de formations entre les membres.

15 Gestion du risque La procédure de gestion du risque est décrite à la section 3.3 du PGPL.

D-7

ANNEXE 1 NORMES DE CODE DE L’ÉQUIPE SOKRATE

Règles :

1. Chaque pointeur non alloué doit être initialisé à la valeur NULL

2. Seules les functions C++ peuvent être utilisées new et delete au lieu de malloc et free cout au lieu de printf …

3. On doit utiliser // pour les commentaires de façon à pouvoir commenter de larges sections de

code avec /* … */

4. Chaque classe doit être dans deux fichiers distincts: un .cpp pour l’implémentation et un .h pour la déclaration.

5. Les commentaires, noms de variables et fonctions, etc… doivent tous être dans la langue

anglaise.

6. Les noms de variables, fonctions et structures doivent avoir la structure suivante : nom en minuscule, avec le début de chaque mot en majuscule, sans espace entre les mots

Ex : void DoSomething(), long SomeValue

7. Les constantes doivent être en majuscules en séparant les mots par des soulignés.

8. Les variables membres d’une classe doivent être préfixées par m_ , les variables globales par g_.

9. Les pointeurs doivent être préfixés par la lettre p, les noms de classes sont préfixés par la lettre Ck et les noms de structures par la lettre Sk.

10. Les variables, fonctions, etc., doivent avoir le nom le plus descriptif possible. Autant que possible,

les mots doivent être écrits au long plutôt qu’avec des abréviations, sauf dans le cas de certains mots clés très courants (Nbr, Max et Min…)

Ex : Utiliser Counter au lieu de i, PositionX au lieu de x, et surtout pas de variables Temp, Toto, FooBar…

11. On ne doit jamais utiliser de valeur numérique directement dans le code. Il faut déclarer une

constante ayant un nom descriptif et utiliser la constante.

12. Les accolades doivent être placés au début du bloc. Ex : if (SomeCondition){

DoSomething();}

13. Les indentations doivent avoir exactement 3 caractères de large et être faites par des espaces, et non des caractères de tabulation.

14. Les lignes doivent avoir une largeur maximale de 80 caractères de façon à faciliter la lecture et

l’impression du code.

D-8

15. Les primitives if, else, while, for et do doivent obligatoirement être suivies d’un bloc entre

accolades, même s’ils ne contienent qu’une instruction ou qu’ils sont vides.

16. On doit utiliser les fonctions d’assertion1 (assert.h) aussi souvent que nécessaire, c’est à dire dès qu’une condition doit obligatoirement être respectée, de façon à simplifier le débogage du code.

17. On doit utiliser la méthode de la permission minimale. Évitez les variables globales, les données

membres publiques, etc. Les variables globales doivent être utilisées le moins possible et, le cas échéant, doivent être encapsulées dans un seul objet global.

18. Le mot clé int ne devra pas être utilisé pour des raisons de portabilité. À la place les mots clés

short ou long seront utilisés.

19. Les fichiers et les fonctions devront inclure des entêtes telles que décrites à la fin de cet annexe.

20. Tout code temporaire devra être identifié tel que suit : //TBM_XX (To Be Modified) //TBA_XX (To Be Added) //TBR_XX (To Be Removed) //TBEND (Fin d’une section To Be)

21. Les fichiers d’entête (header files *.h) auront utiliseront des commandes de pré-processeurs suivantes :

#ifndef SOKRATE_KNAMEOFTHEFILE_H#define SOKRATE_KNAMEOFTHEFILE_H...[Contenu de l’entête]... #endif

Recommandations générales : • Ne faites pas une première version mal codée de votre code en vous disant que vous le rendrez

plus élégant par la suite : on finit toujours par le laisser comme ça.

• Gardez à l’esprit que d’autres personnes, dont des programmeurs débutants, devront comprendre et retravailler votre code. En cas de doute, abusez des commentaires : ça ne coûte pas cher et ça sauve beaucoup de travail inutile.

• Faites un effort pour faire du code propre et élégant. Ce n’est pas grave si ça prend deux lignes

de plus pour rendre le code plus facile à comprendre, une fois en assembleur ça ne change rien.

• Ne vous compliquez pas la vie pour rien. S’il y a une manière simple de faire quelque chose, n’allez pas couper les cheveux en quatre.

• Quand vous changez quelque chose, gardez toujours l’ancienne version en commentaires tant

que la nouvelle n’est pas fonctionnelle et testée. N’oubliez pas d’enlever le code de l’ancienne version avant de faire un dépôt.

1 Les fonctions d’assertion permettent de vérifier une condition, et d’afficher un message d’erreur si la condition n’est pas respectée. Comme ces fonctions ne sont appelées qu’en version debug, elles permettent seulement de confirmer une condition qui devrait normalement être respectée.

D-9

ENTÊTE DE FONCTIONS : //-----------------------------------------------------------------------------//NameOfTheFunction////Parameters : short ParameterA, char ParameterB, char* ParameterC////Return type : void////Action : Receive a short (A), add it to a character (B) and write the result// at the location showned by the pointer (C).////Creator : Simon Bélanger 22-may-2001////-----------------------------------------------------------------------------

ENTÊTE DE FICHIERS : //-----------------------------------------------------------------------------//Sokrate////NameOfTheFile.cpp////-----------------------------------------------------------------------------//Module : This file regroup the components of the graphic interface for// Windows////Functions :// NameOfTheFirstFunction// NameOfTheSecondFunction// NameOfTheThirdFunction////-----------------------------------------------------------------------------

D-10

ANNEXE 2 NORMES DE DOCUMENTATION DE L’ÉQUIPE SOKRATE

1. Tous les documents, excluant les fichiers de code, doivent utiliser la police de base, soit le

Tahoma. Dans tous les documents, la police utilisée pour les lignes de code est Courrier. 2. Les titres de section de premier niveau (ex : 5.) sont en caractères gras de taille 14 points. 3. Les titres de sous-section de deuxième niveau (ex : 6.1) sont en caractères gras de taille

11 points. 4. Les titres de sous-section de troisième niveau (ex : 7.2.3) sont en caractères gras de taille

10 points. 5. Les titres de sous-section quatrième niveau et plus (ex : 2.4.1.3), sont en caractères de taille

10 points. 6. Le corps du texte normal est en normal de taille 10 points. 7. La numérotation des pages se fera en bas à droite et en caractères de taille 10 points. 8. Toutes les marges sont de 2,54 cm. 9. Une ligne vide doit être insérée entre chacun des paragraphes. 10. L’ensemble des documents doit être interligne simple. 11. Chaque paragraphe débute à la marge. Il n'y a donc aucune tabulation au début de paragraphe. 12. Tous les titres et les sous titres sont alignés à la marge, il n'y a aucune indentation de ces

éléments. 13. La disposition du corps du texte doit être en justifié. 14. Une attention devrait être portée afin que les sections principales débutent une page le plus

souvent possible. Toutefois, un souci d’esthétisme du document prédomine sur cette consigne. 15. Les documents, excluant les fichiers de code, devront avoir une page de présentation du même

modèle que celle du PGPL. Ils devraient également posséder une table des matière dynamique comme deuxième page. S’il y a lieu, une table des figures devra être placée à la suite de la table des matières.