MANAGEMENT DES SYSTÈMES D’INFORMATION

DÉCEMBRE 2023

MASTER 1 - MIAGE
MIA 417

(P A R D R . J U S T I N MOSKOLAI)
Q U A L I F I É CNU 27 E S E S S I O N
SOMMAIRE

Chapitre III : Qualité du Sl

et métriques
• Norme logicielle
• Processus d’évaluation
• Méthode SCOPE
• Applications

SA IN T JÉ R ÔSJP
M E PO LY T E C H N IQ U E

2
RAISONS DE LA FAIBLE QUALITÉ DES LOGICIELS

q Tâche complexe
o Taille et complexité des logiciels
o Taille des équipes de conception/développement

q Manque de méthodes et de rigueur

o Manque de méthodes de conception
o Négligence et manque de méthodes et d'outils des phases de
validation/vérification

q Mauvaise compréhension des besoins

o Négligence de la phase d'analyse des besoins du client
o Manque d'implication du client dans le processus

3
IMPORTANCE DE LA QUALITÉ DES LOGICIELS

q Fiabilité, sûreté et sécurité des logiciels

o Transports automobile, ferroviaire, aéronautique
o Contrôle de processus industriels, nucléaire, armement
o Médical : imagerie, appareillage, télé-surveillance
o e-commerce, carte bancaire sans contact, passeport
électronique

q Raisons économiques : coût d'un bug

o Coût de la correction, du rappel des appareils défectueux
o Coût de l'impact sur l'image, de l'arrivée tardive sur le marché
o Coût en vies, coût de l'impact écologique

4
NORME DE QUALITÉ LOGICIELLE

q ISO/IEC 9126 propose 6 caractéristiques de qualité du produit

logiciel
o Capacité fonctionnelle (functionality)
o Fiabilité (reliability)
o Facilité d'utilisation (usability)
o Rendement (efficiency)
o Maintenabilité (maintainability)
o Portabilité (portability)

q (D’autres existent !)

AN A LY S E DES SYSTÈM ES (PAR DR J. MOSKOLAI)

5
CAPACITÉ FONCTIONNELLE

q Définition
o Ensemble d'attributs portant sur l'existence de fonctions et leurs
propriétés ; les fonctions sont celles qui satisfont aux besoins exprimés
ou implicites

q Sous-caractéristiques
o Aptitude : présence et adéquation d’une série de fonctions pour les
tâches données
o Exactitude : résultats ou effets justes ou convenus
o Interopérabilité : interactions avec d’autres systèmes
o Sécurité : accès non autorisé (accidentel ou délibéré) aux programmes
et données

6
FIABILITÉ

q Définition
o Ensemble d'attributs portant sur l'aptitude du logiciel à maintenir son
niveau de service dans des conditions précises et pendant une période
déterminée

q Sous-caractéristiques
o Maturité : fréquence des défaillances dues à des défauts
o Tolérance aux fautes : aptitude à maintenir un niveau de service donné
en cas de défaut ou d’attaque
o Possibilité de récupération : capacité à rétablir son niveau de service et
de restaurer les données directement affectées en cas de défaillance ;
temps et effort nécessaire pour le faire

7
FACILITÉ D’UTILISATION

q Définition
o Ensemble d'attributs portant sur l'effort nécessaire pour l’utilisation et
l'évaluation individuelle de cette utilisation par un ensemble défini ou
implicite d’utilisateurs

q Sous-caractéristiques
o Facilité de compréhension : effort de l’utilisateur pour comprendre la
logique et la mise en œuvre
o Facilité d’apprentissage : effort de l’utilisateur pour apprendre son
utilisation
o Facilité d’exploitation : effort que doit faire l’utilisateur pour exploiter et
contrôler l’exploitation du logiciel

8
RENDEMENT

q Définition
o Ensemble d'attributs portant sur le rapport existant entre le niveau de
service d’un logiciel et la quantité de ressources utilisées, dans des
conditions déterminées

q Sous-caractéristiques
o Temps : temps de réponses et de traitement ; débits lors de l’exécution
de sa fonction
o Ressources : quantité de ressources utilisées ; durée de leur utilisation
par fonction

9
MAINTENABILITÉ

q Définition
o Ensemble d'attributs portant sur l'effort nécessaire pour faire des
modifications données

q Sous-caractéristiques
o Facilité d’analyse : effort nécessaire pour diagnostiquer les déficiences
et leurs causes ou pour identifier les parties à modifier
o Facilité de modification : effort nécessaire pour modifier, remédier aux
défauts ou adapter à l’environnement
o Stabilité : risque des effets inattendus des modifications
o Facilité de test : effort pour valider le logiciel modifié

10
PORTABILITÉ

q Définition
o Ensemble d'attributs portant sur l'aptitude du logiciel à être transféré d’un
environnement à un autre

q Sous-caractéristiques
o Facilité d’adaptation : possibilité d’adaptation à différents environnements
donnés sans que l’on ait recours à d’autres actions, ou moyens que ceux
prévus à cet effet par le logiciel
o Facilité d’installation : effort nécessaire pour installer le logiciel dans un
environnement donné
o Conformité aux règles de portabilité : conformité aux normes et aux
conventions ayant trait à la portabilité
o Interchangeabilité : possibilité et effort d’utilisation du logiciel à la place d’un
autre logiciel donné dans le même environnement

11
EN RÉSUMÉ

q Concrètement, la qualité n’est pas une notion unidimensionnelle

q Il est donc nécessaire

o De définir quelles caractéristiques évaluer (quoi)
o De décider quelles techniques utiliser pour évaluer chacune des
caractéristiques (comment)

12
ASPECTS MESURABLES

q Les processus
o Activités reliées au développement du logiciel
q Les produits
o Objets produits, livrables ou documents qui résultent d'une activité d’un
processus
q Les ressources
o Entités exigées par une activité d’un processus

q Chaque entité des trois classes produits, processus et ressources

possède
o Des attributs internes : attributs mesurables sur l’entité indépendamment de
son environnement
o Des attributs externes : attributs mesurables par rapport aux liens avec son
environnement

13
EXEMPLES

q Attributs internes de processus : effort ou durée du processus ou

d’une activité, …

q Attributs externes de produit : l’efficacité, la portabilité, la facilité de

compréhension, …

q Attributs internes de produit : taille, complexité, couplage, cohésion,

…

q Attributs internes de ressource : personnel, matériels, méthodes, …

14
COMMENT MESURER LA QUALITÉ DU LOGICIEL?

q ISO/IEC 9126 propose des grandes lignes pour un processus

d’évaluation de la qualité

q ISO/IEC 14598 propose un cadre plus précis pour l’évaluation du

produit logiciel

q Le projet SCOPE (Software CertificatiOn Programme in Europe)

définit un cadre complet pour l’évaluation logicielle

q La méthode GQM (Goal – Question – Metrics) permet de choisir les

indicateurs adéquats et QIP (Quality Improvement Paradigm) de les
améliorer

15
COMMENT MESURER LA QUALITÉ DU LOGICIEL?

16
 PROCESSUS D'ÉVALUATION (9126)

Processus d'évaluation en trois étapes

q La définition des exigences de qualité : l'objectif est de spécifier les
exigences en termes de caractéristiques de qualité.
q La préparation de l'évaluation : l'objectif est d'initier l'évaluation et de
mettre au point ses bases. Ceci est fait en trois sous étapes :
o sélection des indicateurs de qualité, définition des taux de satisfaction et
définition des critères d'appréciation
q La procédure d'évaluation
o Mesure. Les indicateurs sélectionnés sont appliqués au produit, donnant ainsi
des valeurs
o Notation. Pour chaque valeur mesurée, une note (de satisfaction) est attribuée
o Appréciation. En utilisant les critères d'appréciation, un résultat global de
l'évaluation du produit est obtenu. Ce résultat est confronté aux aspects de
gestion (temps et coûts) pour la prise de décision

17
DIRECTIVES COMPLÉMENTAIRES (14598)

q Cette norme donne entre autres :

o Des informations générales sur des indicateurs de qualité des
logiciels
o Des critères de sélection de ces indicateurs
o Des directions pour l'évaluation des résultats des mesures
(données)
o Des directions pour l'amélioration du processus de mesure
o Des exemples de types de graphes d'indicateurs
o Des exemples d'indicateurs qui peuvent être utilisés pour les
caractéristiques de qualité de ISO/IEC 9126

18
UN CADRE D’ÉVALUATION, SCOPE

q SCOPE est un projet européen ESPRIT (1989-93) (Software

CertificatiOn Programme in Europe)

q Objectifs
o Définir des procédures d'attribution d'un label de qualité à un
logiciel quand celui-ci satisfait un certain ensemble d'attributs de
qualité
o Développer des technologies nouvelles et efficaces d'évaluation,
à des coûts raisonnables, permettant l'attribution de ce label
o Promouvoir l'utilisation des technologies modernes de l'ingénierie
des logiciels. Celles-ci, utilisées durant le développement,
contribuent à l'attribution du label

19
UN CADRE D’ÉVALUATION, SCOPE

q Résultat :
définition d'un
cadre d'évaluation
comprenant
o Un processus
o Une méthode
o Des techniques

20
PROCESSUS SCOPE

q Documents produits

o Les critères d'évaluation

o La spécification de l'évaluation

o Le plan de l'évaluation

o Le rapport d'évaluation

21
MÉTHODE SCOPE

q La méthode d'évaluation s'appuie sur trois types d'analyse

techniques
o L'analyse statique qui consiste à examiner le code pour évaluer
les caractéristiques de qualité

o L'analyse dynamique qui consiste entre autres à simuler le

déroulement du programme pour effectuer des mesures

o L'inspection qui concerne particulièrement les interfaces

personnes–machines

22
MÉTHODE SCOPE

q L'évaluation peut se faire selon le niveau de détail souhaité

23
 TECHNIQUES SCOPE

Choix des techniques pour chaque niveau

24
PROBLÈME : LE CHOIX D’UNE MESURE

q On ne mesure pas pour le plaisir de mesurer

q Comment choisir la bonne mesure quand vient le temps de

mesurer?

q Le choix de la mesure dépend de l’objectif des mesures

q L’une des approches les plus utilisées pour le choix des

mesures est GQM (Goal – Question – Metrics)

25
COMMENT MESURER LA QUALITÉ DU LOGICIEL?

q ISO/IEC 9126 propose des grandes lignes pour un processus

d’évaluation de la qualité

q ISO/IEC 14598 propose un cadre plus précis pour l’évaluation du

produit logiciel

q Le projet SCOPE (Software CertificatiOn Programme in Europe)

définit un cadre complet pour l’évaluation logicielle

q La méthode GQM (Goal – Question – Metrics) permet de choisir les

indicateurs adéquats et QIP (Quality Improvement Paradigm) de les
améliorer, AQL (Acceptable Quality Level)

26
ACCEPTABLE QUALITY LEVEL - AQL

q La notion de niveau de qualité́ acceptable (NQA ou Acceptable Quality

Level -AQL- en anglais) est une technique d’échantillonnage basée sur
statistiques et probabilités.

q On définira, pour une taille de lot et selon que le fournisseur est plus ou
moins fiable, une taille d’échantillon représentatif, et des niveaux de
défaut.

q Si le niveau de défaut constaté est supérieur au niveau autorisé le lot

entier est rejeté.

q L’approche doit être d’autant plus rigoureuse que les contraintes qui
s’appliquent au produit sont sévères.

27
LEAN MANAGEMENT

q Le Lean Management est une méthode de gestion et d’organisation du

travail qui vise à améliorer les performances d’une entreprise.

q Le Lean Management permet d’optimiser les processus en réduisant les

temps sans valeur ajoutée (opération ou transport inutile, attente,
surproduction, etc.), les causes de non qualité et la complexité.

q Le Lean Management s’appuie sur quatre principes fondamentaux :

o La compréhension des besoins clients
o La réduction du temps de production
o L’analyse, la compréhension et la résolution des problématiques
o La fédération et la sensibilisation des collaborateurs

28
APPORT DU LEAN MANAGEMENT À LA QUALITÉ LOGICIELLE

q Voici quelques-uns des outils de développement Lean les plus

populaires pour renforcer la qualité dans le développement d’un
logiciel:
o Programmation en binôme : évitez les problèmes de qualité en
combinant les compétences et l'expérience de deux développeurs au
lieu d'un
o Développement piloté par les tests: rédaction de critères pour le code
avant d'écrire le code pour s'assurer qu'il répond aux exigences de
l'entreprise
o Développement incrémental et rétroaction constante
o Minimiser les états d'attente: réduire le changement de contexte, les
lacunes dans les connaissances et le manque de concentration
o Automatisation : automatisez tout processus manuel fastidieux ou sujet
à des erreurs humaines

29
REVUE DU CODE

q La revue de code (de l'anglais code review) est un examen systématique

du code source d'un logiciel.

q Il peut être comparé au processus ayant lieu dans un comité de lecture,

l'objectif étant de trouver des bugs ou des vulnérabilités potentielles ou
de corriger des erreurs de conception afin d'améliorer la qualité, la
maintenabilité et la sécurité du logiciel

q Objectifs:
o Améliorer la qualité du code
o Favoriser la collaboration, le travail en équipe (appropriation du code par
l’équipe)
o Appliquer un standard
o Détecter et corriger les défauts (bugs mais aussi lisibilité) au plus tôt dans le
cycle de vie du code pour économiser les coûts
o Formation des développeurs

30
REVUE DU CODE EN PRATIQUE

q Dans la pratique, la revue du code peut se faire suivant :

o Inspection formelle

o Analyse par-dessus l'épaule (over the shoulder review)

o Programmation en binôme

o Utilisation d'un outil dédié:

• Review Board : logiciel libre à interface web créé par Vmware
• Agile Review : plugin libre pour Eclipse
• Crew : logiciel libre de revue de code pour les projets Git
• Rietveld : développé pour Google par Guido van Rossum
• CodeStriker.
• JCR : Java Code Reviewer.

31
LA ROUE DE DEMING

32
LA ROUE DE DEMING

33
MÉTHODE COCOMO

q La méthode COCOMO (COnstructive COst MOdel) est un modèle

permettant de définir une estimation de l’effort à fournir dans un
développement logiciel et la durée que ce dernier prendra en
fonction des ressources allouées.

q Son but était d’estimer le coût d’un projet logiciel, en nombre de

mois-homme et le temps du développement du produit logiciel.

q L’objectif principal de la méthode COCOMO est de définir le coût

d’un projet de développement d’un logiciel. Il est question d’évaluer
les critères de projet ci-après :
o L’effort
o La durée
o L’effectif
o La productivité

34
MÉTHODE COCOMO

q 3 modèles :
o modèle de base : projet < 50 kls (≈ 1000 pages de 50 lignes). Petit
projet.
o modèle intermédiaire : projet de taille moyenne
o modèle détaillé : grand projet

q Pour chaque modèle, on a 3 modes de développement :

o Mode organique (S) : petite équipe expérimentée et environnement
familier (traitement classique).
o Mode semi-détaché (P) : équipe assez expérimentée, environnement
connu.
o Mode imbriqué (E) : projet à contraintes serrées, dues à l'environnement
ou une certaine nouveauté de l'application (temps réel, ...)

35
MÉTROLOGIE – POURQUOI?

q Logiciel(s) critique(s)

q Avoir des mesures fiables, objectives

q Composants réutilisables

q Maintenance du logiciel (coût),

q Equipes de développement différentes

q Certification logiciel ?

q Différents fournisseurs pour un même

q projet ...

36
MÉTROLOGIE – POURQUOI?

37