SAOUDI.L Qualité logicielle 2007/2008
VII. Qualité logicielle
1. DEFINITION
Selon l'IEEE La qualité logicielle est:
(1) Le degré avec lequel un système, un composant ou un processus satisfait à ses exigences spécifiées.
(2) Le degré avec lequel un système, un composant ou un processus satisfait aux besoins ou attentes de ses clients/usagers.
La notion de qualité recouvre deux aspects:
- conformité avec la définition, cette notion est contrôlable en cours de fabrication, - réponse à l'attente de l'utilisateur , cette notion est contrôlable à la livraison du produit.
La qualité est définie de manière générale par « l’aptitude d’un produit ou d’un service à satisfaire les besoins des utilisateurs en termes de fonctionnalités, délais, coûts. »
2. QUALITE: APPROCHE DE MAC CALL
Mac Call définit une approche de la qualité, à partir de la définition de caractéristiques externes (facteurs de qualité), internes (critères de qualité), mesurables (métriques).
1. Les facteurs qualité : expression des exigences (point de vue externe, client) 2. Les critères qualité : caractéristiques du produit (point de vue interne, technique) 3. Les métriques : ce qui permet de mesurer un critère
Pour mesurer la qualité du logiciel, des métriques sont associés aux critères eux même rattachés aux facteurs.
2.1. Facteurs de qualité
Les facteurs de qualité peuvent être classés en 3 catégories.
Les caractéristiques opérationnelles (product operation) conformité aux besoins: le produit fait-il ce que je souhaite?
fiabilité: le fait - il correctement dans tous les cas?
efficacité: utilise-t-il au mieux le matériel?
intégrité: est-il protégé contre les intrusions? a-t-il un niveau de sécurité suffisant?
facilité d’emploi : au niveau de l’apprentissage, de la mise en œuvre, de la préparation des données.
La capacité d’évolution (product revision)
maintenabilité: facilité avec laquelle on peut localiser et corriger les erreurs,
souplesse : facilité de modification et d’évolution (adaptation à de nouveaux besoins), testabilité : effort requis pour le tester.
L’adaptabilité (product transition)
portabilité: peut-on utiliser le logiciel sur une autre machine?
réutilisabilité: peut-on réutiliser des parties du logiciel dans d’autres applications, interopérabilité: facilité d’interfaçage avec un autre système (“ouverture”).
Les facteurs de qualité peuvent avoir une influence les uns sur les autres.
Par exemple les facteurs suivants diminuent l’efficacité:
SAOUDI.L Qualité logicielle 2007/2008
intégrité (nécessité d’introduire des vérifications), facilité d’emploi, portabilité . Les facteurs suivants diminuent l’intégrité: souplesse, réutilisabilité, interopérabilité.
2.2 Les critères de qualité
Attribut du logiciel par l'intermédiaire duquel un facteur peut être évalué.
– Il est orienté réalisateur
– peut affecter plusieurs facteurs.
Mac Call définit 23 critères perceptibles par l’informaticien et permettant d’évaluer dans quelle mesure les facteurs de qualité sont atteints. Chaque facteur défini précédemment est mesuré en fonction d’un certain nombre de critères. Chaque critère est évalué par une métrique.
facilité d’emploi :Opérabilité, Apprentissage, Communicabilité , Volume d'E/S ; Taux d'E/S . Intégrité : contrôle d'accès ,mise en œuvre.
efficacité : efficacité mémoire ,efficacité d'exécution.
Conformité : traçabilité, complétude, cohérence.
Fiabilité : tolérance aux fautes, cohérence, simplicité, précision.
Maintenabilité : cohérence, simplicité, modularité, concision.
Testabilité : simplicité, modularité, auto-description, instrumentation.
Souplesse : modularité, auto-description, généralité, évolutivité.
Portabilité : modularité, auto-description, indépendance machine, indépendance système.
Réutilisabilité : modularité, généralité, indépendance machine, indépendance système.
Interopérabilité : modularité, données banalisées , communications banalisées.
2.3 métriques : les métriques peuvent caractériser les qualités :
*du produit, *du processus de développement, *du service rendu
Ils peuvent se faire par des mesures objectives (comptages) ou par des enquêtes d’opinion (« pensez- vous que les résultats soient présentés clairement ? - de 0 à 5 »).
Mesure directe et objective :
- comptage de nombre de ligne de code source produit - comptage de nombre d’homme-jours processus - comptage du nombre d’abort système service Métriques obtenues par réponse oui/non (liste de contrôle)
- cohérence de la présentation des écrans produit - respect de la procédure de signalisation des incidents processus - capacité de raccordement satisfaisante service Métriques obtenues par enquête (note de 0 à 5)
- clarté de la présentation des résultats produit - apport de l'assurance qualité processus - disponibilité du système aux heures de pointe service 3. Assurance de qualité Logiciel
Selon l'IEEE L'assurance qualité logicielle est:
1. Un modèle planifié et systématique de toutes les actions nécessaires pour fournir une confiance adéquate qu'un article ou un produit est conforme à ses exigences techniques établies.
2. Un ensemble d'activités conçu pour évaluer le processus par lequel les produits sont développés ou fabriqués.
3.1 Contrôle
L'assurance qualité passe par des contrôles réguliers et inclut
- la validation (du latin "VALIDARE", déclarer valide) permet de répondre à la question
"sommes nous en train de faire le bon produit? "
- la vérification (du latin "VERITAS ", la vérité): répond à la question "est ce que nous faisons le produit correctement"
La validation et la vérification sont en partie garanties par la mise en place des inspections, revues, relectures pour tous les produits intermédiaires du développement (prototypes/ maquettes, documents
SAOUDI.L Qualité logicielle 2007/2008
3.2 Communication
Même si l'assurance qualité ne doit pas être confondue avec une production intensive et bureaucratique de documentation, elle insiste sur la nécessité de communiquer à différents niveaux:
- entre développeurs et environnement, (clients avant le développement, support pendant la phase de maintenance) : cahier des charges, dossier d'analyse, manuel d'installation, dossier de conception, plan projet, plan qualité
- entre les développeurs. (dossier d'analyse, dossier de conception, plan qualité, commentaires du code, résultats de tests…)
Certains documents sont plus spécifiquement dédiés à la gestion de la qualité, il s'agit du manuel qualité de l'entreprise et du plan qualité du projet.
3.2.1 Manuel qualité
Le manuel qualité décrit les procédures définies par une entreprise ou une organisation pour atteindre ses objectifs de qualité.
Il répertorie les méthodes et procédures à utiliser pour:
- Gestion de projets
- Réalisation, Vérification, Validation, - Evaluation de la Qualité (Mesures).
en s'appuyant sur:
- Rédaction de standards, normes (ISO, DOD..) , conventions, guides, - Expérience acquise des projets, pour améliorer le processus.
3.2.2 Plan qualité
Le plan qualité logiciel définit, pour un projet donné, en accord avec le manuel qualité de l'entreprise, les méthodes techniques et outils permettant d'atteindre les objectifs de qualité pour un coût donné. Le plan qualité fait partie des éléments contractuels liant un client et son fournisseur de logiciels. Il est établi lors de la phase de planification.
3.3 NORMES QUALITE
Les procédures qualité s'appuient sur la rédaction de normes et de standards, on citera particulièrement :
− la norme DOD 2167 A pour les applications militaires ,
− la norme ISO 9001 (ISO 9000-3 ) pour les applications civiles adoptée par 60 pays (USA, Europe, Japon...).
La grille CMM n’est pas une norme, elle peut toutefois servir de référence pour une exigence de qualité.
4. MOYENS DE L’ASSURANCE QUALITE:
Il existe deux grandes familles de méthodes pour s'assurer de la qualité d'un produit logiciel: les méthodes dynamiques et les méthodes statiques.
Les méthodes reposant sur l'exécution du programme avec des jeux de données préétablis sont aussi vieilles que le développement de logiciel; elles regroupent les différents tests dynamiques réalisés essentiellement pendant les phases de vérification (tests unitaires et tests d'intégration) et de qualification.
En phase de vérification on vérifie la conformité aux spécifications fonctionnelles.
En phase de qualification, le programme est validé sous différents points de vue:
-validation du programme par rapport aux performances requises -validation par rapport aux besoins
-Béta tests (chez l'utilisateur final)
L'examen critique de document est réalisé à travers une lecture statique du document (texte ou code) de manière individuelle ou collective. Son efficacité a été démontrée dès le milieu des années70
SAOUDI.L Qualité logicielle 2007/2008
4.1 EXAMEN CRITIQUE DE DOCUMENTS
L’examen critique porte sur tout document livrable en interne ou au client, prévu dans le cycle de vie et le plan qualité. Il vise à fournir un point de vue indépendant de l'auteur du document. Il permet de réduire le coût du produit et fournit des mesures précises pour la gestion de projet. L'examen critique de documents peut se faire selon diverses méthodes
4.1.1 QUELQUES METHODES DE RELECTURE OU INSPECTION
Différentes organisations sont possibles de la simple relecture personnelle de code à la revue très organisée et formalisée.
A.Auto-correction (Desk-checking)
Il s’agit d’une simple relecture personnelle de son travail (code, document..) à l’aide d’une liste de défauts typiques.
La contribution de cette méthode à l’assurance qualité est pratiquement nulle en ce qui concerne les documents amont, elle est assez faible pour la relecture de code.
B.Lectures croisées (Author-reader cycle)
Même méthode que précédemment mais la relecture se fait par un collègue qui recherche les ambiguïtés, imprécisions, oublis.
La contribution de cette méthode à l’assurance qualité reste assez faible en ce qui concerne les documents amont, elle est plus adaptée à la relecture de code.
C.Revues (Walkthroughs)
Il existe différents types de revues qui diffèrent essentiellement par la formalisation plus ou moins forte du processus. Dans tous les cas l’évaluation se fait par un groupe (10 personnes maximum), la présentation orale est précédée par une lecture préalable du document.
Dans une revue informelle, l’examen est conduit par un lecteur qui résume paragraphe par paragraphe le contenu du document. Il n’y a pas de conduite du débat mais plutôt une discussion informelle. Les problèmes sont évoqués et des solutions envisagées. La contribution de cette méthode à l’assurance qualité est moyenne.
Une revue structurée utilise un cadre plus formel:
Constitution d’une liste de défauts séparée du document, Utilisation d’une liste de défauts typiques (check list), Direction des débats par un secrétaire.
La contribution à l’assurance qualité s’en trouve améliorée. (bonne) D.Inspections
Même principe d’examen collectif mais dans un cadre tout à fait formel .L’inspection d’un document se fait en trois étapes:
Préparation: recherche des défauts, Cycle de réunions,
Suivi: vérification des corrections ou nouvelle inspection Les moyens sont précisés :
Documents de référence,
SAOUDI.L Qualité logicielle 2007/2008
Liste de défauts typiques,
Formulaires d’inspection (formulaire de description de défaut
