INFORMATIQUE APPLIQUÉE: CSI 5202
ASSURANCE DE LA QUALITÉ LOGICIELLE
Dr Romaric Sagbo
Avant-propos
L’Université Virtuelle Africaine (UVA) est fière de participer à accès à l’éducation dans les pays africains en produisant du matériel d’apprentissage de qualité. Nous sommes également fiers de contribuer à la connaissance globale, pour nos ressources éducatives sont principalement accessibles de l’extérieur du continent africain.
Ce module a été développé dans le cadre d’un programme de diplôme et diplôme en
informatique appliquée, en collaboration avec 18 institutions partenaires dans 16 pays africains.
Un total de 156 modules ont été développés ou traduits pour assurer la disponibilité en anglais, français et portugais. Ces modules sont également disponibles en tant que ressources éducatives ouvertes (OER) à oer.avu.org.
Au nom de l’Université Virtuelle Africaine et notre patron, nos institutions partenaires, la Banque africaine de développement, je vous invite à utiliser ce module dans votre
établissement, pour leur propre éducation, partager aussi largement que possible et participer activement aux communautés AVU de pratique d’intérêt. Nous nous engageons à être à l’avant-garde du développement et de partage ouvert de ressources pédagogiques.
L’Université Virtuelle Africaine (UVA) est une organisation intergouvernementale
panafricaine mis en place par lettre recommandée avec un mandat d’augmenter l’accès à l’enseignement supérieur et de formation de qualité grâce à l’utilisation novatrice des technologies de communication de l’information. Une charte instituant la UVA Organisation intergouvernementale, signée à ce jour par dix-neuf (19) Les gouvernements africains - Kenya, Sénégal, Mauritanie, Mali, Côte d’Ivoire, Tanzanie, Mozambique, République démocratique du Congo, Bénin, Ghana, République de Guinée, le Burkina Faso, le Niger, le Soudan du Sud, le Soudan, la Gambie, la Guinée-Bissau, l’Ethiopie et le Cap-Vert.
Les institutions suivantes ont participé au programme informatique appliquée: (1) Université d’Abomey Calavi au Bénin; (2) University of Ougagadougou au Burkina Faso; (3) Université Lumière Bujumbura Burundi; (4) Université de Douala au Cameroun; (5) Université de
Nouakchott en Mauritanie; (6) Université Gaston Berger Sénégal; (7) Université des Sciences, Techniques et Technologies de Bamako au Mali (8) Institut de la gestion et de l’administration
publique du Ghana; (9) Université des sciences et de la technologie Kwame Nkrumah au Ghana; (10) Université Kenyatta au Kenya; (11) Université Egerton au Kenya; (12) Université d’Addis-Abeba en Ethiopie (13) Université du Rwanda; (14) University of Salaam en Tanzanie Dar; (15) Université Abdou Moumouni Niamey Niger; (16) Université Cheikh Anta Diop au Sénégal; (17) Université pédagogique au Mozambique; E (18) L’Université de la Gambie en Gambie.
Bakary Diallo le Recteur
Université Virtuelle Africaine
Crédits de Production
Auteur
Sagbo Romaric
Pair Réviseur
Pelagie Houngue
UVA – Coordination Académique
Dr. Marilena Cabral
Coordinateur global Sciences Informatiques Apliquées
Prof Tim Mwololo Waema
Coordinateur du module
Jules Degila
Concepteurs pédagogiques
Elizabeth Mbasu Benta Ochola Diana Tuel
Equipe Média
Sidney McGregor Michal Abigael Koyier
Barry Savala Mercy Tabi Ojwang
Edwin Kiprono Josiah Mutsogu
Kelvin Muriithi Kefa Murimi
Victor Oluoch Otieno Gerisson Mulongo
Droits d’auteur
Ce document est publié dans les conditions de la Creative Commons Http://fr.wikipedia.org/wiki/Creative_Commons
Attribution http://creativecommons.org/licenses/by/2.5/
Le gabarit est copyright African Virtual University sous licence Creative Commons Attribution- ShareAlike 4.0 International License. CC-BY, SA
Supporté par
Projet Multinational II de l’UVA financé par la Banque africaine de développement.
Table des matières
Avant-propos 2
Crédits de Production 3
Droits d’auteur 4
Supporté par 4
Aperçu du cours 12
Bienvenue au cours d’Assurance de la Qualité Logicielle 12
Prérequis 12
Matériaux 12
Objectifs du cours 13
Unités 13
Évaluation 14
Plan 15
Lectures et autres ressources 16
Unité 0. Évaluation diagnostique 18
Introduction à l’unité 18Objectifs de l’unité 18
Termes clés 18
Évaluation de l’unité 19
Système de notation 20 Évaluation 20 Réponses 20
Unité 1. Aperçu sur l’Assurance de la Qualité Logicielle 22
Introduction à l’unité 22Objectifs de l’unité 22
Termes clés 23
Activités d’apprentissage 24
Activité 1 1 Assurance de la qualité logicielle . . . . 24
Introduction 24
1.1.1 Définition et généralités 24
Détails de l’activité 24
Conclusion 25
Évaluation 25
Système de notation 25
Réponses 25
Activité 1 2 La qualité à partir de plusieurs points de vue 26
Présentation 26
1.2.1 La qualité du point de vue utilisateur/client 26 1.2.2 La qualité du point de vue architecte, analyste
, ingénieur logiciel 26
1.2.3 La qualité du point de vue de l’équipe assurance qualité 27
Détails de l’activité 28
Conclusion 29
Évaluation 29
Système de notation 29
Évaluation 29
Réponses 30
Activité 1 3 Le coût de la qualité 30
Introduction 30
Détails de l’activité 31
Conclusion 31
Évaluation 31
Système de notation 31
Réponses 32
Activité 1 4 Les modèles de qualité 32
Introduction 32
Détails de l’activité 32
Conclusion 33
Évaluation 33
Système de notation 33
Réponses : 33
Activité 1.5 La fiabilité du logiciel 33
Présentation 33 Détails de l’activité 34 Conclusion 34 Évaluation 34 Système de notation 35 Réponses : 35 Évaluation de l’unité 35
Système de notation 35 Résumé de l’unité 35
Évaluation 36 Réponses : 36 Lectures et autres ressources 37
Unité 2. Formulation des exigences et développement centré sur l’utilisateur 38
Introduction à l’unité 38Objectifs de l’unité 38
Termes clés 38
Activités d’apprentissage 39
Activité 2 1 – La formulation des exigences et développement centré sur l’utilisateur . . . 39
Introduction 39
Les détails de l’activité 39
Conclusion 40
Évaluation 40
Système de notation 40
Évaluation 40
Réponses : 41
Introduction 41
Détails de l’activité 42
Conclusion 42
Évaluation 43
Système de notation 43
Réponses : 43
Activité 2 3 – Approche d’analyse des exigences du logiciel : Analyse de
problème 44
Introduction 44 Détails de l’activité 45 Conclusion 45 Évaluation 45 Système de notation 45 Évaluation 45 Réponses : 46 Évaluation de l’unité 46
Directives 46 Système de notation 46 Évaluation 46 Résumé de l’unité 46
Réponses : 47 Système de notation 47 Lectures et autres ressources 47
Unité 3. Vérification et validation 48
Introduction à l’unité 48Objectifs de l’unité 48
Termes clés 48
Activités d’apprentissage 49
Activité 3.1 - Définition de la Mission de test . . . . 49
Introduction 49
Détails de l’activité 49
Conclusion 50
Évaluation 50
Système de notation 50
Évaluation 50
Réponses : 50
Activité 3 2 - Stratégies de test 51
Introduction 51
Détails de l’activité 51
Conclusion 51
Évaluation 51
Système de notation 51
Réponses : 52
Activité 3 3 - Valider les conceptions préliminaires au moyen d’un prototype 52
Introduction 52
Détails de l’activité 52
Conclusion 53
Évaluation 53
Système de notation 53
Réponses : 53
Activité 3 4 – Découverte d’outils de mesure de performance 54
Présentation 54
Détails de l’activité 54
Conclusion 54
Évaluation 54
Système de notation 54
Réponses : 55
Évaluation de l’unité 55
Système de notation 55
Résumé de l’unité 55
Réponses : 56 Lectures et autres ressources 56
Unité 4. Gestion de la qualité 57
Introduction à l’unité 57Objectifs de l’unité 57
Termes clés 57
Activités d’apprentissage 58
Activité 4 1 – La gestion de la qualité 58
Introduction 58 Détails de l’activité 58 Conclusion 58 Évaluation 58 Système de notation 59 Réponses : 59 Activité 4 2 - Assurance de la qualité et les normes 59
Introduction 59 Les détails de l’activité 59 Conclusion 60 Évaluation 60 Système de notation 60 Réponses : 60 Activité 4.3 - Planification de la qualité 61
Introduction 61 Les détails de l’activité 62 Conclusion 62 Évaluation 62 Système de notation 62 Réponses : 62 Activité 4 4 – Contrôle de la qualité 63
Introduction 63
Les détails de l’activité 63
Conclusion 63
Évaluation 64
Système de notation 64
Réponses : 64
Évaluation de l’unité 65
Directives 65
Système de notation 65
Evaluation 65
Réponses : 65
Résumé de l’unité 65 Unité Lectures et Autres ressources 66
Directives 66
Système de notation 66
Évaluation 67
Réponses : 68
Évaluation Finale 2 (Evaluation sommative) 70
Système de notation 70
Évaluation 70
Réponses : 71
Références du cours 74
Aperçu du cours
Bienvenue au cours d’Assurance de la Qualité Logicielle
Ce cours aborde l’assurance qualité que nous pouvons espérer d’un logiciel. En effet, La garantie et le contrôle de la qualité sont des activités essentielles pour toute entreprise de création, de conception d’un produit ou d’un service destinés à être utilisés par des tiers.
Dans notre cas ici, ce produit est le logiciel, et il va falloir qu’il remplisse des exigences de qualité. Pour ce qui concerne la conception de logiciels, certains acteurs de la chaîne de développement pensent que la qualité ne commence que lorsque le développement est fini.
La qualité doit être déjà un critère non négociable dès les premières heures de réflexion et c’est même souvent à cause de la qualité que vous pouvez prétendre convaincre un client de lui développer un logiciel. Donc la qualité, c’est avant, pendant et après le développement.
Pour garantir la qualité du logiciel, il existe aujourd’hui la discipline appelée Assurance de la Qualité Logicielle (en anglais, Software Quality Assurance (SQA)) qui permet de définir toutes les exigences de qualité en amont et suit leur réalisation à chaque étape du développement jusqu’à la livraison de la recette. La gestion de la qualité est une activité universelle permettant d’assurer la qualité du logiciel produit qui doit répondre aux besoins des clients. Pour cela, il existe des indicateurs de performance clés (KPI, pour Key Performance Indicator) qui doivent être vérifiés à chaque étape du processus de développement du logiciel. Les exigences qualité logicielle doivent également être appliquées pour les procédures d’acquisition de logiciels.
Dans ce cours, l’étudiant apprendra les aspects généraux de la garantie de qualité des logiciels, les exigences de qualité, les exigences pour le développeur, le développement centré sur l’analyse des besoins des utilisateurs et des parties prenantes, la vérification et la validation et la gestion de la qualité en elle-même par le biais de l’utilisation des normes SQA.
Prérequis
• Principe des systèmes de bases de données
• Les systèmes de bases de données avancées
• Principes de programmation
• Introduction aux structures de données
• Introduction à a programmation orientée objet
Matériaux
Les matériaux nécessaires pour compléter ce cours comprennent :
• Outils logiciels
• Vidéos en ligne
• Pages wiki
• Manuels
Aperçu du cours
Objectifs du cours
À la fin de ce cours, l’étudiant devrait être en mesure de faire preuve de compétence dans le domaine de l’assurance qualité des logiciels (SQA) grâce à la définition et la normalisation des processus d’élaboration des systèmes.
L’objectif principal de l’apprentissage est centré sur :
• Avoir un aperçu sur la gestion de la qualité, couvrant différents concepts connexes ;
• Comprendre les exigences de l’analyse des besoins et les techniques de développement centré sur l’utilisateur ;
• Comprendre le but principal de l’analyse des besoins ;
• Comprendre la nature des défauts logiciels et les différentes approches qui mènent au développement d’un logiciel de qualité ;
• Donner aux étudiants les connaissances et les compétences nécessaires pour produire des logiciels de qualité ;
• Connaître la mission, les stratégies et les techniques de tests ;
• Savoir comment mesurer la qualité des logiciels ;
• Comment utiliser les nomes pour certifier la qualité d’un logiciel.
Unités
• Unité 0 : Évaluation diagnostique
L’objectif de cette unité est de vérifier la compréhension des connaissances de base liées à cette discipline.
• Unité 1 : Aperçu sur l’Assurance de la Qualité Logicielle
Cette unité présente une vue d’ensemble des concepts liés à la qualité en général, à la qualité des logiciels et de l’assurance de la qualité.
• Unité 2 : Formulation des exigences et développement centré sur l’utilisateur
Cette unité va permettre à l’étudiant de savoir la façon dont il va communiquer avec le client dans la collecte des exigences, la conception et le développement centrés sur l’utilisateur et comment identifier, classifier les problèmes par le biais d’un tableau de problèmes.
• Unité 3: Vérification et Validation
Cette unité donne une description des différentes techniques de vérification et de validation pour montrer que le logiciel satisfait aux spécifications et aux besoins du client en utilisant des tests.
• Unité 4: Gestion de la qualité
Cette unité met en évidence l’entrelacement entre la qualité du processus de développement et la qualité des produits et préconise la création de normes de traitement, le suivi du
processus de développement et la communication sur le développement du logiciel comme mécanismes importants du processus de gestion de la qualité. L’unité traite en outre les fonctions importantes de gestion de la qualité, y compris la planification de la qualité, le contrôle de la qualité et de la mesure des indicateurs clés de performance pouvant certifier de la qualité.
Évaluation
Les évaluations formatives (vérification de progrès) sont incluses dans chaque unité.
Les évaluations sommatives (tests et travaux finaux) sont fournies à la fin de chaque module et traitent des connaissances et compétences du module.
Les évaluations sommatives sont gérées à la discrétion de l’établissement qui offre le cours. Le plan d’évaluation proposé est le suivant :
1 Evaluations
de l’activité
20%
2 Evaluations
de l’unité
30%
3 Examen final 50%
TOTAL 100%
Aperçu du cours
Plan
Unité Sujets et Activités Durée estimée
Unité 0 : Évaluation diagnostique
Cours et Evaluation 10 heures
Unité 1 : Aperçu sur l’Assurance de la Qualité Logicielle
Activité 1.1 – Assurance de la qualité logicielle
Activité 1.2 – La qualité à partir de plusieurs points de vue
Activité 1.3 – Le coût de la qualité Activité 1.4 – Les modèles de qualité Activité 1.5 – La fiabilité du logiciel
25 heures
Unité 2 : Formulation des exigences et développement centré sur l’utilisateur
Activité 2.1 – La formulation des exigences et développement centré sur l’utilisateur Activité 2.2 – La formulation, l’analyse et la négociation
Activité 2.3 – Approche d’analyse des exigences du logiciel : Analyse de problème
30 heures
Unité 3 : Vérification et Validation
Activité 3.1 - Définition de la Mission de test
Activité 3.2 - Stratégies de test Activité 3.3 - Valider les conceptions préliminaires au moyen d’un prototype Activité 3.4 – Découverte d’outils de mesure de performance
30 heures
Unité 4 : Gestion de la qualité
Activité 4.1 – La gestion de la qualité Activité 4.2 - Assurance de la qualité et les normes
Activité 4.3 - Planification de la qualité Activité 4.4 - Contrôle de la qualité
25 heures
Examens finaux Examens sommatives 5 heures
Lectures et autres ressources
Les lectures et autres ressources dans ce cours sont indiquées ci-dessous.
Unité 0
Lectures et autres ressources obligatoires:
• Gerard O’Regan, Introduction to Software Quality, Springer, 2014
• Jalote, P. (2012). An integrated approach to software engineering. Springer Science & Business Media.
• SAGBO, Kouessi Arafat Romaric et HOUNGUE, Pélagie. Quality architecture for resource allocation in cloud computing. In : Service-Oriented and Cloud Computing. Springer Berlin Heidelberg, 2012. p. 154-168.
Lectures et autres ressources optionnelles:
• Jeff Tian, Software Quality Engineering: Testing, Quality Assurance, and Quantifiable Improvement, IEEE Computer Society, 2005
• Derek Nazareth, “Assembling a Metrics Suite for Rule-Based Systems Development,” AMCIS 1999 Proceedings (1999): 23.
Unité 1
Lectures et autres ressources obligatoires:
• Gerard O’Regan, Introduction to Software Quality, Springer, 2014
• Jalote, P. (2012). An integrated approach to software engineering. Springer Science & Business Media.
• http://www.iso.org/iso/Laporte_Genie_Logiciel_Dec2009.pdf
Lectures et autres ressources optionnelles:
• eff Tian, Software Quality Engineering: Testing, Quality Assurance, and Quantifiable Improvement, IEEE Computer Society, 2005
• Darrel Ince, An Introduction to Software Quality Assurance and Its Implementation, McGraw-Hill, 1994
• Pankaj Jalote, A Concise Introduction to Software Engineering, ed. Springer, 2008.
Unité 2
Lectures et autres ressources obligatoires:
• Gerard O’Regan, Introduction to Software Quality, Springer, 2014
• Jalote, P. (2012). An integrated approach to software engineering. Springer Science & Business Media.
Aperçu du cours
Lectures et autres ressources optionnelles:
• Alistair Sutcliffe, User-Centred Requirements Engineering, Springer-Verlag London Limited 2002
• David J. Gilmore, Russel L. Winder and Francoise Detienne, User-Centred Requirements for Software Engineering Environments, Springer-Verlag Berlin Heidelberg GmbH, 1994
• Pankaj Jalote, A Concise Introduction to Software Engineering, ed. Springer, 2008.
Unité 3
Lectures et autres ressources obligatoires:
• Gerard O’Regan, Introduction to Software Quality, Springer, 2014
• Jalote, P. (2012). An integrated approach to software engineering. Springer Science & Business Media.
Lectures et autres ressources optionnelles:
• Paul Ammann and Jeff Offutt, INTRODUCTION TO SOFTWARE TESTING, CAMBRIDGE UNIVERSITY PRESS, 2008
• William E. Perry, Effective Methods for Software Testing, Third Edition, Wiley Publishing, Inc., Indianapolis, Indiana, 2006
Unité 4
Lectures et autres ressources obligatoires:
• Gerard O’Regan, Introduction to Software Quality, Springer, 2014
Lectures et autres ressources optionnelles:
• Jeff Tian, Software Quality Engineering: Testing, Quality Assurance, and Quantifiable Improvement, IEEE Computer Society, 2005
• Darrel Ince, An Introduction to Software Quality Assurance and Its Implementation, McGraw-Hill, 1994
• Pankaj Jalote, A Concise Introduction to Software Engineering, ed. Springer, 2008.
• SAGBO, Kouessi Arafat Romaric et HOUNGUE, Pélagie. Quality architecture for resource allocation in cloud computing. In : Service-Oriented and Cloud Computing. Springer Berlin Heidelberg, 2012. p. 154-168.
Unité 0. Évaluation diagnostique
Introduction à l’unité
Dans cette unité, vous allez vérifier vos connaissances avant de commencer le cours. Vous allez faire l’évaluation de l’unité avant de faire les activités d’apprentissage pour aider à rafraîchir vos connaissances.
Objectifs de l’unité
À la fin de cette unité, vous devriez être capable de :
• Comprendre les principes de base de l’ingénierie logicielle et son application.
• Connaître les méthodologies ou modèles de génie logiciel.
• Appliquer les concepts de modélisation de systèmes dans la résolution de problèmes pratiques.
• Connaître les indicateurs clés de performance.
Termes clés
Génie logiciel: C’est l’application d’une approche disciplinée et systématique quantifiable dans le développement, dans l’exploitation et la maintenance de logiciels.
Processus de développement: C’est un ensemble d’activités, partiellement triés, avec le but d’obtenir un produit logiciel.
Modélisation : technique par laquelle les besoins de l’utilisateur sont traduits sous forme de modèle facilement interprétable dans le processus de développement.
Modélisation objet : Ici la modélisation représente les réalités du monde réel sous forme d’objets ayant un nom, des attributs et remplissant une ou plusieurs fonctions.
Langage de Modélisation : C’est un ensemble de règles permettant de représenter généralement sous forme graphique les besoins et exigences suivant des notations, des représentations et mots clés, par exemple UML.
Unité 0. Évaluation diagnostique
Normes : Document qui définit des exigences, des spécifications, des lignes directrices ou des caractéristiques à utiliser systématiquement pour assurer l’aptitude à l’emploi des matériaux, produits, processus et services.
Standards : Référentiel publié par une entité privée autre qu’un organisme de normalisation national ou international ou non approuvé par un de ces organismes pour un usage national ou international.
On ne parle de standard qu’à partir du moment où le référentiel a une diffusion large.
Qualité : La qualité tend à désigner ce qui rend quelque chose supérieur à la moyenne.
KPI : Key Performance Indicator. C’est l’ensemble des métriques que l’on peut définir et mesurer pour évaluer la performance d’un système, service, processus ou logiciel.
Organisme de certification : c’est une entité indépendante reconnue/agréée qui met en place des procédures pour faire valider la conformité du système qualité d’une organisation à partir d’un référentiel de qualité officiel et reconnu. C’est un processus d’évaluation de la conformité qui aboutit à l’assurance écrite qu’un produit, une organisation répond à certaines exigences. Eg. ISO, …
SQA : Software Quality Assurance ou en français AQL : Assurance Qualité Logiciel
Évaluation de l’unité
Vérifiez votre compréhension!
Evaluation formative Directives
Le but de cette évaluation est de vérifier votre niveau de connaissance sur le e-business avant de démarrer ce module.
En utilisant toutes les ressources bibliographiques fournis, répondez clairement aux questions suivantes.
Système de notation
Cette évaluation est notée sur 20 points. Chaque question est notée sur 2 points.
Évaluation
1. 1Quelles sont les caractéristiques d’un logiciel ?
2. Expliquer la différence entre la vérification et la validation ?
3. Mentionner deux avantages et deux inconvénients des techniques suivantes
a. Interviews ;
b. Étude de la documentation.
4. Qu’entend-on par maintenance de logiciels ? Donnez les catégories de maintenance des systèmes ? Laquelle nécessite plus d’efforts et pourquoi
?
5. Qu’est-ce que UML ? Parlez un peu de la modélisation avec UML.
6. Expliquez comment CMMI encourage l’amélioration continue dans le processus de développement logiciels ?
7. Quelles différences faites-vous entre une norme et un standard ? 8. Pensez-vous qu’un standard peut devenir une norme ?
9. Donnez deux exemples de normes et deux exemples de standards.
10. Citez deux organismes de certification/standardisation.
Réponses
1. Fonctionnalité, fiabilité, ergonomie, efficacité, maintenabilité, portabilité 2. Ceux sont deux aspects de la notion de qualité.
La vérification fait la correction d’une phase du processus de développement ou de l’ensemble par rapport aux éventuelles erreurs sur les définitions ou spécifications définies lors des phases antérieures de développement.
La validation voit la conformité par rapport à la définition en contrôlant les défauts par rapport aux besoins que le produit doit satisfaire.
3. Interviews :
Avantages : collecte des exigences du client pour l’élaboration di dossier
d’analyse, la rencontre avec les acteurs clés pour avoir la description correcte des processus
Inconvénients : insuffisance d’informations si échantillon trop petit, recueil
Unité 0. Évaluation diagnostique
d’informations inutilisables si ce n’est pas validé par tous les acteurs, trop d’acteurs à rencontrer de façon disparate.
- Etude de la documentation :
Avantages : Une bonne description des procédures et processus dans un document peut aider à une bonne analyse, la documentation pourra aider à l’identification des acteurs clés à rencontrer lors de la collecte
Inconvénients : mauvaise description des processus si la documentation est vieille, un nombre trop importante de documents décrivant les mêmes processus
4. Quatre types de maintenance
• Maintenance corrective : modification d’un progiciel effectuée après livraison afin de corriger les défauts rencontrés.
• Maintenance adaptative : modification d’un progiciel effectuée après livraison pour qu’il reste utilisable dans un environnement qui change ou a changé.
• Maintenance perfective : modification d’un progiciel effectuée après livraison pour en améliorer l’efficacité ou la maintenabilité.
• Maintenance préventive : modification d’un progiciel effectuée après livraison pour en déceler et corriger les défauts latents avant qu’ils ne se manifestent.
La maintenance adaptative et la maintenance préventive répondent à une demande d’amélioration du logiciel, ce qui peut demander plus d’efforts, car les spécifications peuvent avoir beaucoup changées ou qu’il y a de nouvelles procédures à intégrer
5. Le langage de modélisation unifié, de l’anglais Unified Modeling Language (UML), est un langage de modélisation graphique à base de pictogrammes conçu. Lire sur wikipédia pour compléter : https://
fr.wikipedia.org/wiki/UML_(informatique) 6. CMMI : Capability Maturity Model Integration
L’amélioration continue dans le processus de développement est encouragé par l’organisation en niveaux (étages) de maturité progressive.
Lire https://fr.wikipedia.org/wiki/Capability_maturity_model_integration
7. La norme est mise en place par un organisme de normalisation national ou international tandis que le standard est publié par une entité privée.
8. Un standard peut évoluer pour devenir une norme si les restrictions d’accès sont levées.
9. 9- Normes : ISO 9001, ISO 10646 Standards : Unicode, PostScript 10. ISO, AFNOR, CEI, W3C, IETF
Unité 1. Aperçu sur l’Assurance de la Qualité Logicielle
Introduction à l’unité
Dans cette unité, vous allez découvrir que l’assurance de la qualité est un ensemble d’actions et de règles nécessaires et suffisantes pour assurer qu’un produit ou service respectera les exigences définies en matière de qualité, qui à leur tour devraient refléter les besoins et les attentes implicites et explicites du client. Les activités d’assurance de la qualité logicielle sont axées sur la prévention des défauts de conception et des problèmes qui peuvent surgir lors du développement, de l’exploitation et de l’utilisation du logiciel. La définition de normes, de méthodologies, de techniques et d’outils afin de soutenir le développement font partie de ce contexte (Rocha Balthazar, 1981).
Il faudrait que le produit qui est développé tienne compte en premier lieu des exigences du client ; ensuite des normes et bonnes pratiques d’analyse, de modélisation et de conception et de développement en faisant de bon choix technologique ; enfin, que le produit soit soumis à des tests pouvant permettre de s’assurer d’une certaine qualité (tests de robustesse, de montée en charge, d’attaques, …). Pour réussir un bon développement, il faut que le client soit au cœur des processus qui sont modélisés et qu’il soit présent tout le long du développement. A un moment donné, il faudra lui demander de faire les dernières validations pour que le développement soit conduit à terme avant qu’il ne revienne pour les tests. Pour que la qualité soit garantie à la fin du processus de développement, il est important de mettre en place une équipe qui s’occupe de la vérification et de la validation de tous les aspects qualitatifs du logiciel durant tout le processus de développement. Ainsi, l’assurance de la qualité consiste à des fonctions de gestion, de vérification et de rapport. Il faut suffisamment documenter le logiciel, de l’analyse jusqu’à l’exploitation, et surtout faire valider tous les documents par le client.
Objectifs de l’unité
À la fin de cette unité, vous devriez être capable de:
• Avoir des connaissances de base sur l’assurance de la qualité logicielle.
• Comprendre l’importance du développement axé sur l’utilisateur.
• Décrire les éléments de l’assurance de la qualité logicielle, ses tâches et ses Objectifs.
• Connaître les techniques de collecte des besoins du client.
• Comprendre les facteurs et les modèles de qualité comme base de mesure de la qualité logicielle.
• Avoir une idée des indicateurs de performance clés qu’on pourrait mesurer.
• Découvrir quelques logiciels de mesure de performance.
Unité 1. Aperçu sur l’Assurance de la Qualité Logicielle
Termes clés
La qualité des logiciels : il est un processus systématique qui porte sur toutes les étapes et les artéfacts produits avec l’objectif d’assurer la conformité des processus et des produits, la prévention et l’élimination des défauts
L’assurance de la qualité : fait partie de la gestion de la qualité visant à donner confiance que les exigences de qualité sont satisfaites
Assurance de la qualité des logiciels : c’est l’ensemble des activités permettant de donner l’assurance que les processus sont établis et sont continuellement améliorés afin de fournir des produits qui répondent aux spécifications et qui sont adaptés à l’usage prévu
Gestionnaire de projet : En charge de la gestion des activités des projets
Architecte logiciel : C’est celui qui est en charge de l’architecture du logiciel, du respect des normes d’architecture et orientera les choix technologiques Analyste fonctionnel : C’est celui qui est chargé de l’analyse, de la modélisation, d’analyser les besoins du client et des parties prenantes et les traduire en de différents diagrammes
Ingénieur Logiciel : C’est celui qui s’occupera du développement.
Equipe SQA : C’est l’équipe qui se chargera de définir et de vérifier les exigences de qualité non seulement du produit final qu’est le logiciel, mais aussi de l’analyse et de la conception.
SRE : Software Reliability Engineering – Cela regroupe toutes les activités pour assurer la fiabilité d’un logiciel.
Activités d’apprentissage
Activité 1.1 Assurance de la qualité logicielle Introduction
Cette activité vous permet d’avoir un aperçu sur l’assurance de la qualité logicielle et tout ce qu’elle engendre. Vous ne pouvez pas ajouter de la qualité à un logiciel à la fin du processus de développement. Il faudra définir les spécifications et choisir les métriques à évaluer dès le début du développement et les suivre tout le long du processus. L’Assurance Qualité Logiciel (AQL) doit être la préoccupation de tous les acteurs intervenant dans la chaîne de développement : chef projet, client, architecte, analyste, ingénieur logiciel, utilisateur, … L’assurance qualité est l’ensemble des activités permettant de s’assurer que les processus sont établis et peuvent être continuellement amélioré sans devoir tout reprendre, et qui conduisent à la conception d’un produit qui remplit les spécifications fonctionnelles du client et qui techniquement donne une certaine assurance dans l’exploitation. Toutes les exigences de qualité à vérifier doivent être inscrites dans un plan d’assurance qualité afin de permettre un suivi rigoureux. Ce plan inclut également de plan de test qui permet de mesurer d’autres indicateurs de performance qu’on ne pouvait pas mesurer lors des phases précédentes du développement. Avoir la qualité, a un coût et il peut être difficile parfois pour des projets de petites tailles d’aller en détail, d’être exigeant ou suivre toutes les étapes de l’assurance qualité. Mais pour les projets complexes et surtout sensibles, il faudrait que la qualité y soit.
1.1.1 Définition et généralités
Qualité : Le mot qualité selon le dictionnaire peut être discuté comme la propriété, l’attribut ou l’état de choses ou des personnes qui permet de les distinguer des autres et de déterminer leur nature. La qualité se rapporte à la mesure de la valeur de certains attributs clés identifiés dès le départ comme porteurs de la qualité. En génie logiciel, tous les attributs ne sont pas aussi mesurables que tels, car ayant parfois des valeurs logiques non quantifiables.
Le contrôle de la qualité : Par définition de l’ISO, le contrôle de la qualité est l’activité technique et opérationnelle qui est utilisé pour répondre aux exigences de qualité.
Détails de l’activité
Dans cette activité, vous avez sûrement lu pour avoir plus d’informations sur l’assurance de la qualité logicielle en plus de ce qui est présenté. Ici, vous devez choisir un logiciel que vous devez développer et définir les attributs du logiciel qui peuvent concourir à sa qualité ? Dites ceux qui sont quantifiables ou mesurables facilement ?
Si vous devez répondre à cette question : “Pensez-vous que le contrôle de qualité fait partie intégrante du processus de développement ?” Que diriez-vous ? Justifiez.
Selon vous, quels pourraient être les impacts si elle n’est pas prise en compte dès le départ ? Maintenant, mettez-vous à la place du client pour définir les caractéristiques qui permettront à votre logiciel de répondre à l’attente des utilisateurs. Sont-elles mesurables ?
Unité 1. Aperçu sur l’Assurance de la Qualité Logicielle
Comment pensez-vous garantir la qualité en tant que responsable de l’équipe de développement ?
Conclusion
Cette activité vous a permis de vous introduire dans l’univers de l’assurance de la qualité logicielle. Vous avez appris que la qualité doit être au cœur du processus de développement et qu’il y a des attributs qu’il faudra surveiller pour garantir la qualité.
Évaluation
Cette évaluation porte sur l’activité qui vient de se terminer et il est recommandé que vous le fassiez individuellement.
Système de notation
Cette évaluation est notée sur 3 points. Chaque question est notée sur 0.75 point.
1. Dites avez vos propres mots ce que c’est que la qualité ?
2. Donnez des exemples d’attributs que vous trouvez importants à surveiller pour avoir un logiciel de qualité ?
3. Dites si oui ou non, la phase de contrôle de qualité ne doit pas intervenir à la fin du développement ? Justifiez selon votre réponse.
4. Donnez un motif d’échec d’un logiciel de votre choix.
Réponses
1. La qualité est le fait qu’un produit répond aux spécifications initialement retenues lors de l’analyse des exigences. Elle peut se mesurer par la vérification de certains attributs clés.
2. La modularité, la robustesse, la réutilisabilité, la compatibilité, l’intégrité, … 3. Non, car les spécifications de qualité doivent être vérifiées au fur et
à mesure. L’omission d’une exigence de qualité constatée à la fin du développement peut avoir un impact négatif sur la livraison et rallonger les délais.
4. La non-prise en compte de tous les utilisateurs clés du logiciel dans la phase de collecte des exigences, la non-validation des exigences par le client avant le développement.
Activité 1.2 La qualité à partir de plusieurs points de vue
Dans cette activité vous allez découvrir ce que c’est que la qualité selon les différents acteurs d’un projet de développement.
Présentation
Donner de l’assurance à la qualité d’un logiciel, ne peut pas être une activité isolée comme nous l’avons dit. Elle est doit faire partir du processus de développement et intervenir à chaque étape. Pour mieux comprendre tous les contours et percevoir toutes les parties qui la composent, il faudra détailler les différents éléments qui entrent dans de le processus de l’assurance de la qualité du logiciel selon chaque acteur.
1.2.1 La qualité du point de vue utilisateur/client
La qualité du logiciel à ce niveau est évaluée en fonction de l’interaction avec des utilisateurs finaux avec le logiciel. Pour eux, la qualité d’un système se résume à l’obtention d’une réponse satisfaisante aux questions suivantes :
o Le logiciel est-il adapté à l’usage ? o Le logiciel est-il fiable ?
o Le logiciel est-il ergonomique ?
o Le logiciel est-il facile à utiliser et à apprendre ? o Le logiciel donne-t-il un rendement raisonnable ? o Le logiciel fait-il ce qu’il est censé faire ?
o Le logiciel est-il rapide ?
o Le logiciel répond t-il aux attentes du client ?
o Le logiciel a-t-il implémenté toutes les fonctionnalités demandées par le client correctement ?
o Etc …
Il existe assez de petites questions comme cela, qui paraissent anodines, mais qui prennent de l’importance lors de la livraison. Un produit peut être rejeté juste à cause de l’aspect extérieur, même si toutes les fonctionnalités marchent. Il est très important d’avoir la réponse à toutes ces questions pour s’assurer que du côté client et utilisateur, le logiciel répond à la qualité.
1.2.2 La qualité du point de vue architecte, analyste, ingénieur logiciel
A ce niveau, la qualité a un autre sens et ne se mesure pas de la même façon. Elle prend une tournure plus professionnelle et n’est pas mesurable par le client.
Unité 1. Aperçu sur l’Assurance de la Qualité Logicielle
La qualité du logiciel est généralement perçue ici comme le nombre de défauts, la facilité à faire évoluer le système, la facilité de faire des tests sur le système, la prise en compte des récentes évolutions technologiques à tout point de vue, la nature de la conception, la technique de modélisation, le choix architecture, le choix de la base de données, la conformité aux exigences, le langage de développement, la plateforme de déploiement.
Il faudrait tenir compte de la simplicité et de la modularité du système, la documentation produite durant tout le processus, la justification des choix opérés.
L’ingénieur logiciel/qualité doit bien choisir et écrire les processus, choisir les outils et
techniques de surveillance et de contrôle de la qualité du logiciel lors de la conception. S’il est difficile de contrôler tous les attributs de qualité du logiciel, il est important de s’assurer de la qualité des processus mis en place, car la réussite de ceux-ci contribuera forcément à l’atteinte des objectifs qualité, surtout côté utilisateur/client. Un processus optimisé et moins complexe contribuera à l’assurance qualité.
Les principales questions que tout ingénieur qualité devra se poser tournent autour de :
• Le logiciel répond t-il de manière adéquate aux facteurs de qualité définis ?
• Le développement du logiciel a-t-il été fait suivant les normes préétablies ?
• Les exigences de qualité ont-ils été respectées à chaque étape du processus de développement ?
• Chaque partie technique a-t-elle joué son rôle dans la chaîne ? Notez qu’une faille sur la ligne peut porter atteinte profondément à tout le dispositif de qualité.
Les éléments clés d’assurance qualité dont ils doivent tenir compte également sont : les normes, les examens et vérifications, les tests, la collecte et l’analyse des erreurs ou défaillance, la gestion des changements, la gestion des clients, la gestion de la sécurité, la sécurité et la gestion des risques.
1.2.3 La qualité du point de vue de l’équipe assurance qualité
Les membres de cette équipe disposent d’une liste d’attributs qui doit être vérifiée et validée pour s’assurer de la qualité de n’importe quel logiciel. Il existe des normes qui doivent être respectées. Mais, ceux-ci doivent participer à tout le processus de développement et doivent tenir compte de tous les points de vue pour tester la qualité. Ils doivent prendre en compte toutes les exigences et faire ressortir les attributs qu’ils ont pu identifier et qui peuvent contribuer à la qualité du logiciel. Ces attributs seront ajoutés à leur liste initiale pour être surveillés. Au fur et à mesure que le développement du logiciel avance, ils doivent veiller à l’atteinte des objectifs de qualité. Ils sont aussi comme un œil du client sur le projet en entreprise, car un échec entrainera tous les acteurs vers le bas. Dans l’application des normes, ils doivent très strictes.
Détails de l’activité
Dans cette activité, vous avez vu les différents aspects de l’assurance qualité à partir de plusieurs points de vue.
1. Listez cinq (5) autres questions de qualité auquel le logiciel doit répondre côté utilisateur et cinq (5) autres côté développement.
2. Reformulez les attentes de qualité côté développement présentées dans ce cours sous forme de question.
3. Identifiez des indicateurs de performance pour un logiciel et proposer une approche pour les mesurer.
4. Pensez-vous qu’il existe d’autres acteurs dont les exigences de qualités doivent être connues ? si oui, lister les et donner des exemples
d’exigences qualité.
5. Donnez selon vous, une approche qui peut conduire à l’assurance qualité dans un logiciel.
6. Donnez en fonction de votre niveau de connaissances, les caractéristiques de qualité d’un logiciel.
Pour l’équipe d’assurance de la qualité logicielle, les objectifs présentés dans ce tableau sont importants, mais certains ont été volontairement soustraits, veuillez les compléter.
Exigences de qualité
La qualité de la conception
La qualité du code
L’efficacité du contrôle de qualité Ambiguïté Intégrité
architecturale
Complexité Affectation des ressources Taux
d’achèvement
Volatilité Intelligibilité
Traçabilité Patterns
Remplissez ce tableau qui recense les éléments d’assurance qualité de l’équipe de développement en donnant les définitions de chaque élément :
Elément Définition
Normes
Examens et vérifications Tests
Unité 1. Aperçu sur l’Assurance de la Qualité Logicielle
Collecte et l’analyse des erreurs ou défaillance Gestion des
changements Gestion des clients Gestion de la sécurité Sécurité
Gestion des risques
Après avoir fait le point des attributs et des caractéristiques de qualité d’un logiciel, veuillez identifier les attributs fonctionnels et les attributs non fonctionnels.
Conclusion
Dans cette activité, vous avez vu que les questions de qualité ne sont pas les mêmes d’un acteur à l’autre.
Évaluation
Cette évaluation porte sur l’activité qui vient de se terminer et il est recommandé que vous le fassiez individuellement.
Système de notation
Cette évaluation est notée sur 2 points. Chaque question est notée sur 1 point.
Évaluation
1. Pensez à un petit projet de conception d’un logiciel que vous devez mener à terme et garantir la qualité. Après avoir donné les détails élémentaires, décrire selon vous les exigences en termes de qualité du point de vue de chaque acteur qui interviendra dans le processus.
2. Pensez-vous que la qualité serait garantie si le logiciel fonctionne correctement en fonction de ce que vous avez compris des exigences ? Justifiez.
Réponses
1. Un projet de gestion des étudiants. Exigences : authentification avant ajout/modification/suppression des étudiants et des notes, trace des modifications effectuées par les utilisateurs, ergonomie, position des boutons, utilisation du logo du client sur certaines pages, application web, base de données Oracle, …
2. Non, car si la compréhension que vous avez, n’a pas été validée par le client lors de l’établissement du dossier d’analyse, votre développement sera vain. Beaucoup de choses seront remis en cause. Il serait plus prudent de tout faire valider avec tous les acteurs impliqués avant de continuer avec la conception. Chaque inquiétude au niveau d’un processus doit être clarifiée par tous les acteurs avant d’évoluer vers une autre phase.
Activité 1.3 Le coût de la qualité
Dans cette activité, vous allez découvrir que la qualité dont nous parlions depuis le début a un coût, car cela implique d’autres aspects dont on n’est pas forcément au courant dès le début.
Introduction
Vous devez savoir que l’assurance de la qualité ajoute des contraintes supplémentaires dans le développement du logiciel. Cela demande une augmentation de l’équipe projet, car la qualité ne se fera pas sans l’apport de l’équipe qualité qui doit veiller à la perfection.
Le coût de la qualité comprend tous les frais financiers des activités liées à l’assurance de la qualité. Ces coûts se divisent en trois catégories à savoir : les coûts liés à la prévention, les coûts liés à l’évaluation et les coûts liés aux défaillances.
Les coûts de la prévention sont les suivants :
• Planification de la qualité ;
• Révisions techniques formelles ;
• Test du matériel d’essai ;
• Formation.
Les coûts liés à l’évaluation comprennent :
• Inspections des processus et les interactions entre eux ;
• Entretien du matériel ;
• Tests.
Les coûts liés aux défaillances qui peuvent être internes comme externes comprennent donc
Unité 1. Aperçu sur l’Assurance de la Qualité Logicielle
• Amélioration ;
• Réparer des bogues ;
• Retour/échange du produit ;
• Analyse des échecs ;
• Résolution des plaintes ;
• Support et aide en ligne ;
• Les travaux de sécurité.
Détails de l’activité
Dans cette activité, vous avez vu les types de coût qui entrent en jeu pour l’obtention de l’assurance de la qualité logicielle.
Parmi les coûts liés aux défaillances que vous avez lu dans l’activité, classifier ceux qui sont internes et ceux qui sont externes. Vous devez profiter pour expliquer ce qu’on entend par défaillances interne et externe.
Lister deux (2) autres coûts qui pourraient s’ajouter à la liste pour chaque catégorie de coût.
Pensez-vous que les coûts liés aux défaillances pourraient être nuls ? Justifiez.
Entre un coût lié à une défaillance interne et un coût lié à une défaillance externe, lequel il faudra craindre le plus ? Justifiez
Conclusion
Cette activité vous a permis de vous rendre compte des coûts liés à l’assurance qualité dans le processus de développement du logiciel. Vous devez être en mesure de mieux discuter avec le client par rapport aux implications qu’engendrent chacune de ses exigences.
Évaluation
Cette évaluation porte sur l’activité qui vient de se terminer et il est recommandé que vous le fassiez individuellement.
Système de notation
Cette évaluation est notée sur 4 points.
1. Qu’est-ce qu’une défaillance ? (0.75 point)
2. Qu’entendez-vous par bogue ? Est-il une défaillance externe ? Justifiez (0.75 point)
3. Quand pouvons-nous qualifier une défaillance d’externe ? Donnez en deux exemples différents de celles citées dans cette activité. (0.75 point) 4. Si vous devez négocier à la fin de ce cours un projet de développement
négocié avant de suivre ce cours ? Pourquoi ? (0.75 point)
5. Si le client n’est pas en mesure de payer la facture liée à la qualité, pensez- vous qu’il faudra développer le logiciel sans tenir compte des exigences de qualité ou bien qu’il faudra abandonner le projet ou qu’il faudra
essayer de le convaincre et trouver un terrain d’entente avant de démarrer
? Justifiez votre choix. (1 point)
Réponses
1. Une défaillance est un défaut ou problème constaté dans le fonctionnement d’un logiciel.
2. Un bogue est une erreur dans le codage du logiciel. C’est une défaillance interne car c’est une faille dans l’implémentation qui est gérée par l’équipe de développement en interne.
3. La défaillance externe fait allusion à un défaut ou une panne qui survient après la livraison chez le client. On peut citer par exemple une défaillance due l’insertion d’une valeur inappropriée ou une défaillance matérielle entraînant le plantage du logiciel.
4. Non, parce qu’il faudra y intégrer les coûts liés à la prise en compte de la qualité.
5. Il faudra essayer de le convaincre et trouver un compromis avec le client.
Autrement, il ne sera jamais satisfait du produit développé sans les exigences de qualité qu’il avait préalablement voulu.
Activité 1.4 Les modèles de qualité Introduction
Dans cette activité, vous êtes amenés à faire des recherches et à proposer un contenu pour cette partie.
Vous devez parler de la gestion de la qualité, revenir sur les activités de l’équipe d’assurance qualité pour pouvoir faire un point des facteurs de qualité fondamentaux et aborder les modèles de qualité qui peuvent être utilisés avec leurs caractéristiques (ex. ISO-9126).
Détails de l’activité
L’étudiant doit mener des activités de recherche et de lecture pour :
• Parler de la gestion de la qualité ;
• Donner les activités de l’équipe d’assurance qualité ;
• Donner les facteurs de qualité fondamentaux ;
• Présenter quelques modèles de qualité qui existent, comme par exemple le modèle ISO-9126.
Unité 1. Aperçu sur l’Assurance de la Qualité Logicielle
Conclusion
Dans cette activité, vous avez montré votre capacité à faire de la recherche sur un sujet donné.
Vous devez être en mesure de décrire maintenant quelques modèles de qualité. Les résultats vous seront utiles dans l’évaluation de cette activité.
Évaluation
Cette évaluation porte sur l’activité qui vient de se terminer et il est recommandé que vous le fassiez individuellement.
Système de notation
Cette évaluation est notée sur 3 points. Chaque question est notée sur 1.5 point.
• Présentez en détail quatre (4) caractéristiques du modèle de qualité ISO-9126.
• Présentez aussi un autre modèle de votre choix que vous avez découvert lors de vos recherches et trois (3) de ses caractéristiques en détail.
Réponses :
1. La norme ISO/CEI 9126 définit un langage commun pour modéliser les qualités d’un logiciel.
Caractéristiques : fiabilité, facilité d’utilisation, efficacité, maintenabilité, portabilité 2. La norme ISO 9001 – version 2015 définit une série d’exigences
concernant la mise en place d’un système de gestion de la qualité dans un organisme. Elle s’occupe des principes de management comme le leadership, l’approche processus, l’amélioration continue, l’implication du personnel.
Activité 1.5 La fiabilité du logiciel Présentation
La fiabilité d’un logiciel se définit comme la probabilité de fonctionnement sans défaillance d’un logiciel dans un environnement donné pour une période de temps spécifiée. Elle peut être directement mesurée et évaluée à l’aide des données historiques et du développement. Il ne faut pas oublier que tous les indicateurs ne sont pas mesurables.
La fiabilité se mesure comme le temps moyen entre deux défaillances : Temps moyen entre défaillances (MTBF) = MTTF + MTTR
MTTF = Durée moyenne de fonctionnement avant défaillance MTTR = Temps de réparation moyen
La fiabilité permet d’identifier les dangers potentiels qui peuvent causer la défaillance d’un système logiciel. L’identification précoce des risques permet aux développeurs de spécifier les caractéristiques de conception qui peuvent éliminer ou au moins de contrôler l’impact des dangers potentiels.
La fiabilité va de pair avec la sécurité qui examine la manière dont les défaillances peuvent entraîner dans des conditions données à un incident.
Détails de l’activité
Dans cette activité, vous avez pris connaissance de la fiabilité du logiciel qui est aussi importante et qui implique beaucoup d’activités.
A partir de vos lectures, donnez les types de défaillances qui existent avec deux exemples dans chaque cas.
Qu’entendez-vous par Software Reliability Engineering ? Citez en deux activités.
Le tableau qui suit donne la liste des activités que l’ingénieur logiciel et les autres acteurs de l’équipe projet doivent mener pour s’assurer de la fiabilité. Pour chaque phase du processus de développement, donnez au moins deux activités importantes qui doivent être faites.
Phases Activités
Exigences -
- Conception
Implémentation Tests
Post-Livraison Maintenance
Conclusion
Cette activité vous a permis de savoir que la fiabilité est un facteur de qualité et sa relation à la défaillance logicielle. Aussi l’activité mis en évidence comment les ingénieurs de logiciels peut améliorer la fiabilité en intégrant les activités de recherche de fiabilité dans le processus de développement de logiciel.
Évaluation
Cette évaluation porte sur l’activité qui vient de se terminer et il est recommandé que vous le fassiez individuellement.
Unité 1. Aperçu sur l’Assurance de la Qualité Logicielle
Système de notation
Cette évaluation est notée sur 2 points. Chaque question est notée sur 1 point.
1. La fiabilité est-il un facteur critique de qualité? Discuter.
2. Examiner les compétences clés et d’outils qui pourraient être nécessaires pour exécuter les activités de contrôle de fiabilité.
Réponses :
1. La fiabilité est un facteur critique de qualité car elle permet d’identifier les dangers potentiels qui peuvent causer la défaillance d’un logiciel. Elle permet d’avoir un produit qui répond aux exigences de qualité définies.
2. Les compétences clés sont liées aux compétences des différents acteurs qui interviennent au cours des phases de développement du logiciel dans la recherche de la qualité. Il faut qu’ils soient au courant des normes de qualité et qu’ils y veillent lors de l’élaboration des processus. Que ce soient les développeurs, les testeurs, les experts d’assurance qualité, ils doivent disposer des compétences pour faire face aux exigences lors des activités de définition des exigences, de conception, d’implémentation, de tests, de livraison et de maintenance.
Résumé de l’unité
Cette unité vous a permis d’avoir un aperçu sur l’assurance de la qualité logicielle, de découvrir les exigences de qualité en fonction des acteurs et des équipes, de savoir que la qualité à un coût, d’avoir une vue sur les modèles de qualité et de savoir que la fiabilité conduit à l’atteinte de la qualité également avec ses implications. Dans l’unité qui suit, vous allez découvrir l’étape de formulation des exigences et comment le développement centré sur l’utilisateur.
Évaluation de l’unité
Vérifiez votre compréhension!
Evaluation Formative Directives
Faire subir l’évaluation aux apprenants et en tenir compte pour apprécier leur progression.
Système de notation
Cette évaluation est notée sur 6 points. Chaque question est notée sur 1 point.
Évaluation
1. Selon votre expérience, pensez-vous que les propositions de qualité des différents acteurs peuvent conduire à la qualité ? Donner deux exemples en fonction de deux acteurs différents.
2. Pour un système de détection de métaux à l’aéroport, pensez-vous que l’assurance qualité doit être moyenne ou élevée ? Expliquer et donnez quelques indicateurs de performance de ce logiciel
3. Citez les quatre objectifs de l’équipe d’assurance de la qualité logicielle.
4. Discuter de l’implication de la qualité pour les produits en général 5. Décrire les techniques/méthodes/outils qui pourraient être utilisés par
les ingénieurs logiciels afin d’aider à répondre aux questions d’assurance qualité suivantes :
a. Est-ce que le logiciel répond de manière adéquate à ses facteurs de qualité?
b. Le développement du logiciel a-t-il été mené selon les normes préétablies?
c. Est-ce que l’équipe AQL a accompli son rôle technique correctement?
6. Donner un exemple de logiciel et son domaine d’application lorsque la fiabilité est :
a. Très importante b. Pas très importante
Réponses :
1. Oui, mais toutes les propositions peuvent ne pas être réalisables à cause d’un choix technologique dépassé ou très récent dont l’équipe de développement n’a pas la maîtrise.
Le client :
• Demande d’une application accessible de partout et disponible 24h/24
• Demande d’une application accessible sur smartphone
Le développeur :
• Choix de PHP pour développer l’application
• Choix de UML pour la modélisation
• Choix de tester chaque module avec l’équipe d’assurance qualité avant d’évoluer
Unité 1. Aperçu sur l’Assurance de la Qualité Logicielle
2. L’assurance qualité doit être élevée car un tel système doit être très sensible à tout soupçon de métal dans un bagage ou sur une personne.
Comme indicateur de performance, nous avons la fiabilité qui doit être maximale, la robustesse et la réutilisabilité.
3. Les objectifs concernent la vérification des exigences de qualité, la qualité de la conception, la qualité du code et l’efficacité du contrôle de qualité.
Cela peut être aussi la vérification de l’intégrité, la complexité, le taux d’achèvement, la maintenabilité, la volatilité, la traçabilité, la réutilisabilité, la documentation.
4. La qualité participe à l’adoption d’un produit au dépend d’un autre. Elle aide à pouvoir atteindre des objectifs bien définis dès le début. Elle permet de vérifier si les choix technologiques sont appropriés.
5.
• La mesure des indicateurs de performance (fiabilité, robustesse, temps de réponse, …) par des tests, l’utilisation des logiciels d’évaluation de performance tel que LoadUI, la qualité du code, le respect des normes telles que définies par l’équipe d’assurance qualité (ISO 9126)
• La vérification de la conformité par rapport aux normes choisies par des tests, des mesures de métriques de qualité.
• La disponibilité des rapports des vérifications effectuées par l’équipe et les recommandations engendrées.
6.
• Logiciel de contrôle d’identité par lecture de l’iris. Un tel logiciel peut contrôler l’accès à des ressources sensibles tels un datacenter, une réserve d’armes nucléaires.
• Logiciel de contrôle de trafics. Un tel logiciel permet d’avoir une estimation du nombre de véhicules qui empruntent un axe routier, un péage, …
Lectures et autres ressources
Les lectures et autres ressources de cette unité se trouvent au niveau des lectures et autres ressources du cours.
Unité 2. Formulation des exigences et développement centré sur
l’utilisateur
Introduction à l’unité
Dans cette unité, vous allez étudier comment collecter les exigences du client et procéder à un développement centré sur l’utilisateur.
La formulation des exigences/besoins comprend les tâches d’analyse pour déterminer les besoins ou les conditions à satisfaire par un nouveau produit/logiciel ou un produit/logiciel modifié pour prendre en compte les exigences des différentes parties prenantes du projet avec parfois des besoins conflictuels. Les tâches tournent autour de l’analyse, la documentation, la validation et la gestion des exigences du logiciel ou système. L’analyse des besoins contribue à la réussite d’un projet logiciel, mais quand elle est mal faite, cela peut conduire le projet vers un échec. Les exigences devraient être documentées, faisables, mesurables, testables, traçables, liées aux besoins métiers du client qui ont été définis ou des opportunités à exploiter.
Elle définit un niveau de détail suffisant pour la conception du système.
Objectifs de l’unité
Dès l’achèvement de cette unité, vous devriez être en mesure :
• De comprendre les étapes clés de la formulation des exigences.
• De comprendre comment se passe la collecte des besoins.
• De comprendre l’analyse des besoins.
• De voir le rôle de chaque acteur dans le processus.
• De négocier les exigences
• D’appliquer une approche d’analyse des exigences
Termes clés
Diagramme de Cas d’Utilisation : En modélisation UML, cela permet de capturer le comportement d’un système, d’un sous-système vu de l’extérieur. Il scinde la fonctionnalité du système en unités cohérentes appelées cas d’utilisation qui a un sens pour les acteurs. Les cas d’utilisation permettent d’exprimer le besoin des utilisateurs d’un système, donc ils se construisent autour des acteurs du système.
Unité 2. Formulation des exigences et développement centré sur l’utilisateur
Activités d’apprentissage
Activité 2.1 – La formulation des exigences et développement centré sur l’utilisateur
Introduction
Dans cette activité, vous allez découvrir que la formulation englobe toutes les activités menant à la découverte des exigences d’un système. Les développeurs des systèmes et les ingénieurs travaillent en relation étroite avec le client et les utilisateurs finaux pour en savoir plus sur le problème à résoudre, pour décrire les fonctionnalités du système, les performances du système, des contraintes matérielles et ainsi de suite.
La formulation n’est pas un simple processus de collecte d’exigences, mais un processus hautement complexe en raison de ce qui suit :
• Le client a rarement une image claire de ses besoins
• Différentes personnes ont des exigences conflictuelles
• L’environnement d’entreprise dans lequel le processus de formulation est fait en constante mutation. Cela peut entraîner le changement dans certaines exigences et l’expression de nouveaux besoins provenant de nouveaux intervenants.
• De nombreux processus de formulation existent et il faudra choisir à travers.
• Quel que soit le travail qui sera réalisé dans un projet de développement, il faudra s’appuyer sur les utilisateurs pour avoir une bonne définition des processus et procédés.
Les détails de l’activité
A ce niveau, vous allez faire quelques lectures pour répondre à des questions.
Donner les activités importantes de la formulation des exigences. Il en a 4.
Donner les étapes de la formulation des données.
Citer trois activités qui composent l’analyse des besoins ?
Quels sont les acteurs clés qu’il ne faut pas laisser tomber lors de la collecte des besoins ? A quoi servira la collecte des besoins ? Est-ce une étape nécessaire ?
A quoi vous fait penser le schéma de la Figure 1 ci-dessous ? Pensez-vous qu’une étape a été oubliée ? Donnez-lui un titre.
Pensez-vous que les parties prenantes d’un projet peuvent le faire échouer ? Justifier.
Figure 1 : [Proposer un titre à la figure]
Conclusion
Dans cette activité, vous avez compris les activités et les implications de la formulation des exigences qui fait partie intégrante du processus de développement du logiciel. Nous avons vu qu’il faudra faire aussi avec les réponses conflictuelles qui peuvent provenir de la collecte des besoins et dont il faudra tenir compte et les élucider avant d’aller à la conception. Dans l’unité suivante, vous allez voir qu’après la formulation des exigences, il y a l’analyse qui est une étape importante qui peut impliquer aussi des négociations entre les acteurs.
Évaluation
Cette évaluation porte sur l’activité qui vient de se terminer et il est recommandé que vous le fassiez individuellement.
Système de notation
Cette évaluation est notée sur 4 points.
Évaluation
1. A quoi sert l’analyse des besoins ? (0.5 point)
2. Quels sont les acteurs dont il faut tenir compte lors de la collecte des besoins ? (0.5 point)
3. Faut-il prendre en compte tous les acteurs lors de la collecte ? Expliquez (0.5 point)
4. Une validation des processus issus de l’analyse des besoins est-elle nécessaire de la part du client ? (0.5 point)
5. Prenez une situation de développement de logiciel de votre choix et exprimer les besoins et proposer les implications si la qualité est requise.