• Aucun résultat trouvé

Assurance de la qualité logicielle

N/A
N/A
Protected

Academic year: 2022

Partager "Assurance de la qualité logicielle"

Copied!
76
0
0

Texte intégral

(1)

INFORMATIQUE APPLIQUÉE: CSI 5202

ASSURANCE DE LA QUALITÉ LOGICIELLE

Dr Romaric Sagbo

(2)

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

(3)

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

(4)

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.

(5)

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é 18

Objectifs 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é 22

Objectifs de l’unité 22

Termes clés 23

Activités d’apprentissage 24

Activité 1 1 Assurance de la qualité logicielle . . . . 24

Introduction 24

(6)

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

(7)

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é 38

Objectifs 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

(8)

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é 48

Objectifs 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

(9)

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

(10)

Résumé de l’unité 55

Réponses : 56 Lectures et autres ressources 56

Unité 4. Gestion de la qualité 57

Introduction à l’unité 57

Objectifs 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

(11)

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

(12)

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

(13)

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.

(14)

• 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%

(15)

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

(16)

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.

(17)

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.

(18)

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.

(19)

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.

(20)

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

(21)

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

(22)

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.

(23)

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.

(24)

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 ?

(25)

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.

(26)

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.

(27)

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.

(28)

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

(29)

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.

(30)

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

(31)

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

(32)

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.

(33)

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

(34)

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.

(35)

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.

(36)

É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

(37)

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.

(38)

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.

(39)

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.

(40)

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.

Références

Documents relatifs

Rapport entre les médicaments fabriqués à façon et les médicaments destinés à être remis à la clientèle de l’établissement : Fabrication exclusivement destinée à la

Pour chaque rencontre, le coordinateur du projet communique avec le point de contact de chaque partenaire pour rappeler la date de l’évènement, l’échange a lieu

Ministère, qu'elle effectue à son usine ainsi qu'en chantier un contrôle de la qualité rencontrant les exigences décrites dans la norme BNQ 9911-200 (83-12-05) "Gestion de

Narimane Hadj-Hamou, is the Founder and CEO of the enter of Learning Innovations and Customized Knowledge Solutions (CLICKS); prior to that she was the Assistant

le logo « AB » est délivré à partir d’un cahier des charges avec exigences. Le produit et le producteur subissent ensuite des contrôles après certification.

Membre du collectif IT’s on us (numérique responsable) Formateur officiel Opquast en assurance qualité web Formateur en accessibilité numérique.. Plus d’infos

Avec ce système de qualité obligatoire pour tous les membres actives ou actifs, le bso veut promouvoir le professionnalisme des conseillères et conseillers bso et contribuer

Mémoire Master MEDAS – INTD CNAM – Amal DHANNOO 25 Ce tableau présente quelques problèmes que l’on peut rencontrer dans le traitement d’une donnée.. Par conséquent, ce