PLAN D`ASSURANCE QUALITÉ LOGICIEL

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
4 Documentation
D-2
5 Standards, pratiques, conventions et métriques
D-2
6 Revues et Audits
D-4
3.1
3.2
3.3
4.1
4.2
4.3
5.1
5.2
6.1
6.2
Organisation ...........................................................................................................D-1
Tâches ...................................................................................................................D-1
Responsabilités .......................................................................................................D-1
But ........................................................................................................................D-2
Documentation minimale exigée ...............................................................................D-2
Autres ....................................................................................................................D-2
But ........................................................................................................................D-2
Contenu .................................................................................................................D-2
But ........................................................................................................................D-4
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
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 :
GC :
SGC :
V&V :
Assurance Qualité
Gestion de la configuration
Système de gestion de la configuration
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-1
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-2
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-3
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
6.2.1
Exigences minimales
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-4
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-5
•
•
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-6
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-7
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 :
1
•
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.
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-8
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-9
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.
D-10