Post on 17-Mar-2022
2J. Akoka / I. Wattiau
Sommaire
1. Introduction2. Définitions, concepts et outils3. Qualité des systèmes d’information4. Qualité et normalisation5. Qualité du logiciel6. Qualité du processus logiciel7. Conclusion
4J. Akoka / I. Wattiau
Introduction
La qualité est un concept « à la mode » dans le domaine des Systèmes d’InformationSigne de maturité du domaine
Première période : recherche d’efficacitéLe SI doit répondre aux besoins fonctionnels
Deuxième période : recherche de qualitéLe SI doit répondre aussi aux besoins non fonctionnelsQualité de service
5J. Akoka / I. Wattiau
Les enjeux
Un SI de qualité est un actif valorisableUn SI de qualité peut améliorer la satisfaction du clientUn SI de qualité peut procurer un avantage compétitif
6J. Akoka / I. Wattiau
Un exemple de problématique de qualité : le système d’information hospitalier
� Objectif qualité : mesurer la qualité du service rendu �de la traçabilité de l’information à la complétude dans les dossiers médicaux des patients
� Approches qualité traditionnelles�Tirage au sort de 80 dossiers �Évaluation manuelle
� Points faibles :�Lourd à mettre en œuvre�Etude rétrospective =>Pas de possibilité de correction
� Les enjeux :�Sécurité�Image�Coûts
7J. Akoka / I. Wattiau
Un exemple de problématique de qualité : la consommation d’électricité
� Objectif qualité : Analyser les prévisions de consommation de l’électricité pour diverses catégories de consommateurs �nécessite une complétude et une cohérence de l’information
� Questions clés :�est ce que les données couvrent toutes les populations souhaitées ?
�est ce que les données sont cohérentes ?
� Exemples d’approches :�Mesure du taux de données manquantes
�Contraintes d’intégrité
8J. Akoka / I. Wattiau
Les conséquences de la non-qualité
Coûts : des implications simplesQualité du logiciel -> coût de la maintenanceNon-qualité des données : 600 milliards de dollars par an aux USA (source : Data Warehousing Institute, 2002)Dépendance vitale : l’explosion de la navette Challenger était due à des problèmes de qualité« Bug » de l’an 2000 : 300 à 600 milliards de dollarsEtc.
10J. Akoka / I. Wattiau
Définitions de la qualité
1. Toutes les actions que l’on peut entreprendre:En amont, en cours de réalisation d’un projet pour améliorer le produit ou le serviceEt en aval pour suivre le produit ou le service livré.
2. ISO8402:1994L’ensemble des propriétés et caractéristiques d’un produit ou d’un service qui lui confère l’aptitude àsatisfaire des besoins exprimés ou implicitesC’est donc une notion relative, fondée sur le besoinOn doit rechercher une qualité optimale et pas nécessairement une qualité maximale
11J. Akoka / I. Wattiau
Typologie de la qualité
Qualité attendue : celle que le client souhaiteQualité voulue : que le fournisseur a prévu de faireQualité réalisée : traduit ce qui a été obtenuQualité perçue : ce que le client constate
12J. Akoka / I. Wattiau
Les acteurs de la qualité
Directeur qualitéÉtablit les procédures (plan d’assurance qualité, manuels, etc.) au niveau de l’entreprise
Ingénieur qualitéReprésente le directeur qualité au sein d’une entitéGarant de la bonne application des procédures
AuditeurDéfinit les méthodologies pour l’amélioration de la qualité et du système de management de la qualité
Contrôleur qualitéÉvalue la qualité du produit ou du service et supervise les actions qualité
13J. Akoka / I. Wattiau
Les approches qualité
Contrôlequalité
Améliorationde la qualité
Managementde la qualité
Qualitétotale
14J. Akoka / I. Wattiau
Gestion de la qualité totale
TQM (Total Quality Management)Améliorer constamment tous les processus, internes et externes, qui contribuent au produitUtiliser une approche systémique
15J. Akoka / I. Wattiau
14 principes de la qualité totale [Deming]
Garder en vue l’objectif d’améliorer constamment les produits et les servicesAdopter la nouvelle philosophieMettre fin à la dépendance à l’égard des inspections et contrôles
En intégrant la qualité au produit ou au serviceMettre un terme à la pratique des achats au plus bas prix
Réduire plutôt le coût total en traitant avec un fournisseur unique sur la base d’une relation long terme loyale et confiante
Améliorer constamment le système de productionEtablir un système de formationAdopter et instituer le leadership et dynamiser l’encadrementFaire disparaître la peur pour que chacun travaille plus efficacementEliminer les barrières entre les servicesEliminer les slogans et objectifs de rendement
Les problèmes de qualité résident dans le système lui-même, au-delà du pouvoir du personnel
Eliminer les quotas de productionSupprimer les obstacles à la fierté du travailEncourager l’éducation et l’amélioration de chacun Agir pour accomplir la transformation
16J. Akoka / I. Wattiau
Quelques outils de la qualitéDémarches et cadres de qualité
Roue de Deming, Méthode 6 Sigma, Cercle de qualité, démarche 8D, GQM
Outils de « défrichage »Diagramme KJ, brainstorming, feuille de relevé
Recherche des causes de problèmes de qualité et des impactsIshikawa, Pareto, Histogramme, QQOQCCP
Analyse des données et des mesuresGraphique de contrôle, diagramme de dispersion, stratification
Analyse du fonctionnement d’un processus/produitLogigramme, modélisation de processus, graphe PERT
Choix d’une solution parmi plusieursMatrice de compatibilité, arbre de décision, vote pondéré simple/multiple
Optimisation et sécurisation d’un processusAMDEC, Gantt, Kanban, 5S, Kaizen, Lean
18J. Akoka / I. Wattiau
Plan, Do, Check, Act – roue de Deming
Méthode séquentielle de conduite de projet permettant d’exécuter un travail de manière efficace et rationnelleComprend 4 étapes P, D, C, AS’applique à tous les processus :
Définir un plan d’améliorationChoisir les méthodes et outilsMesurer les résultatsAjuster les actions d’amélioration
19J. Akoka / I. Wattiau
La méthode 6 Sigma (σ)Origine : MotorolaPrincipe : faire en sorte que tous éléments du processus étudié, soient compris dans un intervalle s'éloignant au maximum de 6 fois l’écart type par rapport à la moyenne générale Travailler sur le processus afin que seuls des produits conformes aux exigences soient livrésActeurs : pyramide de fonctions d’expertise croissante
Le Green Belt (« ceinture verte »), consacre 25% de son temps à la conduite de projets d'améliorationLe Black Belt (« ceinture noire »), chef d'équipe, se consacre à plein temps àl'amélioration Le Master Black Belt, mentor et formateur de Blacks BeltsLe Deployment Leader ou Champion, chargé d'élaborer la stratégie, le contenu de la formation, les budgets, etc.
Démarches associées DMAIC (Define, Measure, Analyze, Improve, Control), DMADV (Define, Measure, Analyze, Design, Verify), etc.
20J. Akoka / I. Wattiau
Démarche 8D (ou 8 Do)
D1 : Préparer le process 8D D2 : Décrire le problème D3 : Identifier et mettre en place des actions immédiates D4 : Identifier les vraies causes D5 : Valider des actions correctives permanentes D6 : Mettre en œuvre les actions correctives permanentes D7 : Prévenir toute récidive D8 : Féliciter l'équipe
21J. Akoka / I. Wattiau
Cercle de qualité
Outil de communicationPour partager l’informationAu niveau d’une unité ou transversal, temporaire ou permanent, soutien hiérarchiqueFavoriser la compréhension des objectifs de qualitéPermettre la reconnaissance mutuelle3 facteurs clés de succèsVolonté d’améliorationClimat de confiance et de transparence« Légaliser » la critique
22J. Akoka / I. Wattiau
Approche par les buts(Goal-Question-Metric GQM)
Quel est le but de qualité ? Améliorer la satisfaction du client
Quelle dimension de qualité faut-il viser ?Obtenir des informations fiables sur le client
En quels facteurs se décline-t-elle ?ComplétudeFraîcheur
Avec quelles métriques peut-on mesurer ces facteurs ?Quelles sont les valeurs actuelles de qualité ?Comment peut-on améliorer la qualité ?
24J. Akoka / I. Wattiau
Diagramme d’affinités (ou KJ)
De son inventeur : Kawakita Jiro
Définir ensemble le problèmeChacun écrit ses 3 ou 5 idées ou explicationsMise en commun sur un tableauStructuration HiérarchisationSélection des catégories à ciblerRépartition des tâches
25J. Akoka / I. Wattiau
Le « brainstorming »
Travail de groupe exprimant le maximum d’idées notées sur un tableau visible de tous3 phases :Recherche : expression des idées sans restrictionRegroupement et combinaison d’idéesConclusion : analyse des causes suspectées
26J. Akoka / I. Wattiau
Feuille de relevé
Feuille de relevéréponse structurée, préparée sous forme de collecte et d'analyse des données. outil générique qui peut être adapté pour une large variété de fins.
Principe :Définir l’événement ou le problème à observerDécider du moment où les données seront collectées et pour combien de temps. Concevoir le formulaire Mettre en place
Exemple : communications téléphoniques
28J. Akoka / I. Wattiau
Diagramme d’Ishikawa
Diagramme causes-effets (en arête de poisson)Sert à comprendre les causes d’un défaut de qualitéAnalyse le rapport existant entre un problème et ses causesFondé sur un travail de groupeTrouver toutes les causes possibles au défaut de qualité et les classer en 5 familles (5M):Matières, Milieu, Méthodes, Matériels, Main d’oeuvre
29J. Akoka / I. Wattiau
Exemple de diagramme d’Ishikawa
La bière que je vends n’est pas bonne
Personnel non qualifié
Responsabilité mal définie
30J. Akoka / I. Wattiau
Graphe de Pareto
Permet de classer les phénomènes par ordre d’importanceHistogramme décroissant avec une ligne de cumul
0,0%
20,0%
40,0%
60,0%
80,0%
100,0%
a b c d e f g h autres
% d'impayés
servicesHistogramme : colonne 2 du tableau
Courbe des % cumulés : colonne 4 du tableau
31J. Akoka / I. Wattiau
Histogramme
Permet d’étudier une distribution de donnéesEt de la comparer à une distribution standardIl existe une typologie d’histogramme (normal, bimodal, plateau, etc.)
32J. Akoka / I. Wattiau
Le QQOQCCP
Why, what, where, when, who, how, how much ?Technique de recherche d’informations sur un problème et ses causes en se posant les questions: quoi, qui, où, quand, comment, pourquoiPour chaque question se demander combien ?
34J. Akoka / I. Wattiau
Graphique de contrôleUtilisé pour étudier un processus dans le tempsLes données sont tracées par ordre chronologique. ligne centrale = moyenne ligne supérieure et ligne inférieure déterminées à partir des données historiques.
35J. Akoka / I. Wattiau
Diagramme de dispersion
Moyen simple de vérifier une relation entre deux variablesPlus le nuage de points se rapproche d’une droite, plus la relation est forteCorrélation n’est pas causalité
36J. Akoka / I. Wattiau
La stratification
Permet de distinguer les données provenant de différentes sources pour analyser des « patterns »Aussi appelé « flowchart » ou « runchart »
40J. Akoka / I. Wattiau
Outil PERT (Project Evaluation and Review Technique)
Représentation des étapes d’un processus et des contraintes entre étapesExemple : La construction d'un entrepôt est découpée en dix tâches dont les caractéristiques sont données dans le tableau ci-contre
Graphe PERT
tâches nature
prédécesseurs
durée en jours
A acceptation des plans par le propriétaire 4
B préparation du terrain 2
C commande des matériaux A 1
D creusage des fondations A, B 1
E commande des portes et fenêtres A 2
F livraison des matériaux C 2
G coulage des fondations D, F 2
H livraison des portes et fenêtres E 10
I pose des murs, de la charpente et du toit G 4
J mise en place des portes et fenêtres H, I 1
42J. Akoka / I. Wattiau
La matrice de compatibilité
Outil d’aide à la décisionPermet de faire un choix parmi plusieurs propositionsCroisement des critères de choix (coûts, délais, efficacité,…) et des sujets (problèmes à sélectionner ou solutions à retenir)Les sujets sont comparés entre eux en fonction de leurs scoresLes problèmes ou solutions ne répondant pas à un ou plusieurs critères sont éliminésCeux répondant à la plupart ou à tous sont retenusExemple organisation d’un déplacement professionnel
43J. Akoka / I. Wattiau
Le vote pondéré
Outil de choix lorsque les données sont qualitativesSélection finale du problème que le groupe souhaite résoudre en premier à partir d’un résultat d’un vote simpleVote pondéré multicritèreVote pondéré simple
48J. Akoka / I. Wattiau
L’AMDEC
Analyse des Modes de Défaillances, de leurs Effets et de leur CriticitéAMDEC produit, AMDEC processus, AMDEC moyenRecenser toutes les causes potentielles d’une défaillance et évaluer la criticité selon trois notes : G (gravité), O (occurrence), D (détection)G : gravité ou sévérité de l’impact du défautO : fréquence d’apparition de la causeD : probabilité de non détection de la causeIndice de criticité : G * O * DMettre en place des actions en jouant sur un ou plusieurs des paramètres
50J. Akoka / I. Wattiau
Méthode Kanban
Méthode de suivi de production utilisée dans le juste-à-tempsSe fonde sur un système d’étiquettes permettant le juste-à-temps
51J. Akoka / I. Wattiau
5S
Mot Japonais Traduction Interprétation
Seiri Débarras Trier
Seiton Ranger Classer
Seiso Nettoyage Nettoyer
Seiketsu Ordre Conserver en ordre et propre
Shitsuke Rigueur Formaliser et impliquer
Outil d’amélioration continue, qui optimise l’organisation d’un poste de travail, d’un service ou d’une entreprise
52J. Akoka / I. Wattiau
Kaizen : changer pour faire mieux1 Abandonner les idées fixes, refuser l’état actuel des choses.2 Au lieu d’expliquer ce que l’on ne peut pas faire, réfléchir comment faire.3 Réaliser aussitôt les bonnes propositions d’amélioration.4 Ne pas chercher la perfection, gagner 60% maintenant.5 Corriger l’erreur immédiatement sur place.6 Trouver des idées dans la difficulté.7 Chercher la cause réelle, respecter les « 5 pourquoi ? » et chercher ensuite la solution.8 Prendre en compte les idées de 10 personnes au lieu d’attendre l’idée géniale d’une seule.9 Essayer et ensuite valider.10 L’amélioration est infinie.
53J. Akoka / I. Wattiau
LeanMéthode Toyota14 principes :
Penser sur le long termeFluiditéFlux tirésProduction constante et lisséeAutomatisation avec une touche humaineTâches standardiséesContrôles visuelsTechnologies et méthodes fiablesCultiver les leadersFaire monter en compétences les personnes de qualitéRespecter et motiver ses partenairesAller toujours sur le terrainPrendre les décisions en consensusAmélioration continue
Application en systèmes d’information : méthodes agiles
54J. Akoka / I. Wattiau
Les noms de la qualité
Deming : roue PDCA, qualité totale, insiste sur la cohérence de l’approche «assurer la qualité, c’est donner aux clients des garanties sur sa capacité à fournir un produit ou un service conformément à ses attentes et dans la durée »Juran : a diffusé le principe de Pareto ou loi des 80/20, a initialisé des formations, la qualité est « la meilleure adéquation au besoin »Crosby : la qualité, « conformité à des exigences », conduit à la chute des coûts et à l’accroissement de la productivitéTaguchi : propose des plans d’expérience et des tables pour évaluer et améliorer la qualité des produits
56J. Akoka / I. Wattiau
Qualité des systèmes d’information
Source : Stylianou, Kumar, CACM 2000
6 dimensions
57J. Akoka / I. Wattiau
Dimensions de qualité (1/2)
Qualité de l’infrastructureMatérielLogiciel de baseRéseauSystème d’exploitation, etc.
Qualité du logicielQualité des applications construites et/ou maintenues
Qualité des donnéesQualité des données entrant dans les différents systèmes d’information
58J. Akoka / I. Wattiau
Dimensions de qualité (2/2)
Qualité de l’informationQualité des données sortant des systèmes d’information
Qualité administrativeQualité de la fonction système d’information Inclut la qualité des processus de :• Élaboration du budget• Élaboration du planning
Qualité de serviceQualité du service rendu vu par le « client »
59J. Akoka / I. Wattiau
Interactions entre les dimensions
Qualité de l’infrastructure -> qualité des données et qualité de serviceQualité de l’information sortant d’un SI -> qualitédes données entrant dans un SIEtc.
61J. Akoka / I. Wattiau
Pourquoi des normes ?
Formalisent le fonctionnement et les responsabilités des intervenants et par là :Renforcent l’implication du managementGèrent l’après-certificationMotivent les acteursSatisfont le clientDonnent la priorité à l’efficacité et non à la conformitédes procéduresRépondent à la certification
62J. Akoka / I. Wattiau
Les normes ISO 9000
Créées en 19872 révisions en 1994 et 2000« outils de progrès »4 normes principales
ISO 9000:2000 • principes essentiels et vocabulaire
ISO9001:2000 : QUI et QUOI• exigences • utilisée pour faire des certifications
ISO9004:2000 : COMMENT• Lignes directrices pour l’amélioration des performances
ISO19011• Lignes directrices pour les audits de systèmes de management qualité
ISO9001 :Qualité externeÀ usage contractuelPour la certification des procédés auprès des clientsRéalisée par un tiers indépendant rattaché à un organisme de certification
63J. Akoka / I. Wattiau
Les 8 principes de management de ISO 9000:2000
Ecoute clientLeadershipImplication du personnelApproche processusManagement par approche systèmeAmélioration continueApproche factuelle pour la prise de décisionRelations mutuellement bénéfiques avec les fournisseurs
64J. Akoka / I. Wattiau
Ecoute client
Comprendre les besoins présents et futursSatisfaire les exigencesS’efforcer d’aller au devant des attentes
65J. Akoka / I. Wattiau
Leadership
Les dirigeants doivent:Établir la finalité et les orientations de l’organismeCréer les conditions d’implication des personnes dans la réalisation des objectifs de l’organisme
66J. Akoka / I. Wattiau
Implication du personnel
Motiver le personnelLes membres sont responsables de leur performanceLe personnel participe et contribue à l’amélioration continueLe personnel utilise ses aptitudes au profit de l’organisme
67J. Akoka / I. Wattiau
Approche processus
Les ressources et les activités sont gérées comme un processusAvec une focalisation sur les opportunités d’améliorationIdentifier et gérer les processus, leurs combinaisons et leurs interactionsPoints clés :
La direction est responsable du management de la qualitéLes ressources : humaines, temps, finances, infrastructures, information, environnement de travailProcessus de satisfaction du clientMesures, analyses et amélioration
68J. Akoka / I. Wattiau
Management par approche système
Identifier, comprendre et gérer des processus comme un systèmeIntégration et alignement des processus
69J. Akoka / I. Wattiau
Amélioration continue
L’amélioration continue de la performance globale d’un organisme est un objectif permanentAlignement des activités d’amélioration à tous les niveauxSouplesse et rapidité de réaction face aux opportunités
70J. Akoka / I. Wattiau
Approche factuelle pour la prise de décision
Les décisions efficaces sont fondées sur l’analyse des données et des informationsLes décisions bien informées si les données sont exactes et fiablesLa prise de décision est fondée sur des données factuelles.
71J. Akoka / I. Wattiau
Relations mutuellement bénéfiques avec les fournisseurs
Interdépendance de l’organisme et de ses fournisseursCapacité pour les deux organismes à créer de la valeurMise en commun des acquis et des ressources avec les partenaires
72J. Akoka / I. Wattiau
Standards développés ou en cours
ISO/TS 8000-100:2009 Data quality -- Part 100: Master data: OverviewISO/TS 8000-110:2009 Data quality -- Part 110: Master data: Exchange of characteristic data: Syntax, semantic encoding, and conformance to data specification.ISO/TS 8000-120:2009 Data quality -- Part 120: Master data: Exchange of characteristic data: ProvenanceISO/PAS 26183-2006 SASIG Product data quality guidelines for the global automotive industryISO/TR 21707-2008 Intelligent transport systems - Integrated transport information, management and control - Data quality in ITS systemsISO/IEC 25012:2008 Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Data quality modelBS 7986-2005 Data quality metrics for industrial measurement and control systems –SpecificationISO 19113:2002 Geographic information — Quality principlesISO 19114:2003 Geographic information — Quality evaluation proceduresISO TS 19138-2006 Geographic information — Data quality measuresISO/NP 19157 Geographic information -- Data qualityISO/NP TS 19158 Geographic information - Quality assurance of data supplyInternational Monetary Fund, IMF: Data Quality Assessment Framework, DQAF
74J. Akoka / I. Wattiau
Norme ISO/IEC 9126
Process quality: qualité des processus du cycle de vie du logiciel
Internal quality: qualité des produits intermédiaires, incluant les modèles statiques et dynamiques, la documentation et le code source
External quality: qualité du système final tel que vérifiable à son comportement externe
Quality in use: effet du système lors de son utilisation – satisfaction des attentes des utilisateurs
75J. Akoka / I. Wattiau
Le modèle de qualité logicielle ISO/IEC 9126
6 caractéristiques / 24 sous-caractéristiques / 113 métriques
76J. Akoka / I. Wattiau
Les 6 caractéristiques de la qualitélogicielle ISO/IEC 9126
Capacitéfonctionnelle
Fiabilité
Facilitéd’utilisation
ISO/IEC9126
Portabilité
Rendement
Maintenabilité
Est-ce que le logiciel répond aux besoins fonctionnels exprimés ?
Est-ce que le logiciel maintient son niveau de service dans des conditionsprécises et pendant
une période déterminée ?
Est-ce que le logiciel requiert peu d’effort à l’utilisation ?
Est-ce que le logicielrequiert un
dimensionnement rentable et proportionnée
de la plate-forme d’hébergement en regard des
autres exigences ?
Est-ce que le logiciel requiert peu d’effort pour son évolution par rapport aux
nouveaux besoins ?
Est-ce que le logicielpeut être transféréd’une plate-forme
ou d’un environnement à un autre ?
78J. Akoka / I. Wattiau
Bilan sur les normes
Points positifsImplication de tout le personnelValorisation du professionnalisme des personnes
Points négatifsDocumentation excessivePas d’innovationEchec si :• peu d’implication du management• Rédaction des procédures sans les acteurs• Communication insuffisante• Précipitation dans le lancement
80J. Akoka / I. Wattiau
Introduction
Spécificités du produit-logicielle logiciel est un produit complexe• beaucoup de modules• beaucoup d’opérations différentes possibles
le logiciel est un produit obscur• défauts non visibles à l’œil nu• leur détection nécessite des tests
81J. Akoka / I. Wattiau
La qualité du logiciel
Spécificités de l’environnement de productioncontrat coût-délai-fonctionnalitéscoopération étroite avec le clienttravail d’équipe nécessitant une coopération et une coordination interne et externeinterfaces avec d’autres logicielstaux important de rotation des équipesnécessité de maintenance du logiciel pendant plusieurs années
82J. Akoka / I. Wattiau
Exemple : logiciel de paie
Logicielde paie
Machine àbadger
Système d’in-formationbancaire
Ordres de transferts bancairesvers les comptes des salariés
Rapport mensuel incluantles heures supplémentaires
83J. Akoka / I. Wattiau
Logiciel
Définition IEEE : Programmes informatiques, procédures, documentation associée et données nécessaires au lancement du systèmeUne erreur dans le programmepeut déclencher un fonctionnement incorrectqui peut entraîner un échec du système
84J. Akoka / I. Wattiau
Causes des erreurs
Définition incorrecte des besoinsMauvaise communication entre le demandeur et le développeurModification délibérée du programmeErreurs de logiqueErreurs de codageTests insuffisantsErreurs dans les procédures
85J. Akoka / I. Wattiau
Qualité du logiciel
Définition IEEE :degré auquel un système, un composant ou un processus satisfait les besoins spécifiésdegré auquel un système, un composant ou un processus satisfait les attentes du client ou les besoins des utilisateurs
86J. Akoka / I. Wattiau
Qualité du logiciel
Autre définition (Pressman, 2000) :conformité :• aux besoins fonctionnels établis de façon explicite • aux performances• aux standards de développement demandés,• aux caractéristiques implicites attendues de tous les logiciels développés de façon professionnelle
87J. Akoka / I. Wattiau
Des erreurs logicielles lourdes de conséquences ou non
La sonde Mariner devait passer à 5000 km de Vénus : elle s’est perdue à5000000 de km à cause d’une erreur de programmation : un point remplacé par une virguleUn appareil d’irradiation thérapeutique a provoqué la mort de 2 personnes et l’irradiation de 4 autres à cause d’un « bug »Un navire de guerre anglais a été coulépar un Exocet français pendant la guerre des Malouines : plusieurs centaines de morts. La cause : le vaisseau anglais n’a pas activé ses défenses, parce que l’Exocet n’était pas répertorié dans les missiles ennemisInondation de la vallée du Colorado en 1983 à cause d’une erreur de modélisation dans le logiciel qui calcule le temps d’ouverture du barrage
En 1996, lors du 1er lancement d’Ariane V, elle explose en vol. La cause : réutilisation d’un logiciel d’Ariane IV qui vérifiait l’inclinaison de la fusée, mais le moteur étant plus puissant, il a jugél’inclinaison non conforme à son plan de tir et a provoqué l’ordre d’autodestruction : ½ milliard de dollars
Saisie pour une dette impayée de 1 centime de franc : arrondi mal maîtriséUne centenaire (106 ans) convoquée àl’école : bug de l’an 2000Une amende de 91500 $ pour une cassette vidéo non restituée au bout de cent ans : bug de l’an 2000
88J. Akoka / I. Wattiau
Facteurs de qualité du logiciel
Permettent d’exprimer les exigences de qualité3 classesfacteurs liés au fonctionnement du logicielfacteurs liés à l’évolution du logicielfacteurs liés à l’adaptabilité du logiciel
89J. Akoka / I. Wattiau
Modèle de McCall
Facteurs de fonctionnementexactitude, fiabilité, efficience, intégrité, utilisabilité
Facteurs d ’évolutionmaintenabilité, flexibilité, testabilité
Facteurs d ’adaptabilitéportabilité, réutilisabilité, interopérabilité
90J. Akoka / I. Wattiau
Autres facteurs
Modèle d’Evans et Marciniakvérifiabilité et extensibilité
Modèle de Deutsch et Willissécurité, manageabilité, survivabilité
91J. Akoka / I. Wattiau
Facteurs de qualité interne* selon Boehm
Portabilité Facilité à être porté sur de nouveaux environnements (matériels et/ou logiciels)
Traçabilité Capacité à suivre un élément du cahier des charges jusqu’au composant logiciel
Vérifiabilité Facilité de préparation des recettes
Intégrité Aptitude d’un logiciel à protéger contre des modifications non autorisées
Fiabilité Capacité à fonctionner sans tomber en panne
Documentation Respect de standards
Testabilité Facilité à localiser les défauts
Modularité Degré d’organisation en modules
Interopérabilité Aptitude à échanger avec d’autres systèmes
Compréhensibilité Facilité à comprendre, notamment la documentation
Modifiabilité Facilité à modifier
Clarté Lisibilité et respect des conventions de réalisation
* Qualité vue du développeur
92J. Akoka / I. Wattiau
Facteurs de qualité externe* selon Boehm
Validité/conformité Aptitude à réaliser les tâches définies dans les spécifications
Robustesse Aptitude à fonctionner même dans des conditions anormales
Extensibilité/flexibilité Facilité d’adaptation à un changement de spécification
Réutilisabilité Aptitude d’un logiciel à être réutilisé en tout ou partie
Compatibilité Aptitude du logiciel à pouvoir être combiné avec d’autres
Efficacité Aptitude du logiciel à bien utiliser les ressources matérielles (temps CPU, mémoire, etc.)
Maintenabilité Aptitude d’un logiciel à être facilement modifié
Facilité d’utilisation Facilité d’apprentissage ou de préparation des données, de rattrapage en cas d’erreur d’utilisation, etc.
Économie Adaptation par rapport aux moyens mis en oeuvre
Justesse Aptitude du logiciel à fournir des résultats corrects
Elasticité Capacité à minimiser l’effort en cas d’évolution
Généralité Satisfaction du logiciel dans des environnements multiples
* Vue du client (utilisateur)
94J. Akoka / I. Wattiau
Métrique de qualité logicielle
Définitions IEEE : Mesure quantitative du degré auquel un élément tend vers un facteur de qualitéUne fonction dont les entrées sont les données du logiciel et dont la sortie est une valeur numérique qui peut être interprétée comme le degré auquel un élément tend vers un facteur de qualité
95J. Akoka / I. Wattiau
Qu’est ce qu’une bonne métrique ?
PertinenteValideFiableComplète Mutuellement exclusive (une métrique = un facteur)SimpleNe nécessite pas la collecte de données supplémentairesNon sujette aux interventions des parties concernées
96J. Akoka / I. Wattiau
Classification des métriques de qualité
Par phase du cycle de vieMétrique de processus Métrique de produit
Par sujetQualitéDélaiEfficacité (des corrections, de la maintenance, des services)Productivité
97J. Akoka / I. Wattiau
Mesures de la taille du logiciel
KLOC — milliers de lignes de code. Nb de points de fonction (NFP) — mesures de la “quantité” de développement sur la base des fonctionnalités du logiciel
98J. Akoka / I. Wattiau
Métrique de qualité du processusMétrique de densité d’erreurMétrique de sévérité d’erreur
Métrique de délai du processus
Métrique d’efficacité de la suppression d’erreur
Métrique de productivité du processus
Les catégories de métriques de processus
99J. Akoka / I. Wattiau
Code Nom Formule de calcul
CED Densité d’erreur de codage NCECED = -----------
KLOC
DED Densité d’erreur de développement NDEDED = -----------
KLOC
WCED Densité d’erreur de codage pondérée WCEWCDE = ---------
KLOC
WDED Densité d’erreur de développement pondérée
WDEWDED = ---------
KLOC
WCEF Erreurs de codage par point de fonction WCEWCEF = ----------
NFP
WDEF Erreurs de développement par point de fonction
WDEWDEF = ----------
NFP
NCE = Nb d’erreurs de codage détectées pendant l’inspection du code ou pendant les testsNDE = Nb total d’erreurs détectées (codage et logique) pendant le développementWCED = Nb d’erreurs de codage détectées pendant l’inspection du code ou pendant les tests et pondérées par degré de sévéritéWDED = Nb total d’erreurs détectées pendant le développement et pondérées par sévérité
Métriques de densité d’erreur
100J. Akoka / I. Wattiau
Code Nom Formule de calcul
ASCE Sévérité moyenne deserreurs de codage
WCEASCE = -----------
NCE
ASDE Sévérité moyenne deserreurs de développement
WDEASDE = -----------
NDE
Métriques de sévérité d’erreur
NCE = Nb d’erreurs de codage détectées pendant l’inspection du code ou pendant les testsNDE = Nb total d’erreurs détectées (codage et logique) pendant le développementWCE = Nb d’erreurs de codage détectées pendant l’inspection du code ou pendant les tests et pondérées par degré de sévéritéWDE = Nb total d’erreurs détectées pendant le développement et pondérées par sévérité
104J. Akoka / I. Wattiau
Assurance qualité du logiciel
Définition IEEE :schéma planifié et systématique de toutes les actions àconduire pour obtenir la confiance dans le fait qu’un produit est conforme aux exigences techniques établiesensemble d’activités d’évaluation du processus par lequel les produits sont fabriqués
105J. Akoka / I. Wattiau
Assurance qualité du logiciel
Autre définition (~ ISO 9000) :ensemble systématique et planifié d ’actions nécessaires pour fournir une confiance adéquate dans le fait que le processus de développement ou de maintenance du logiciel est conforme aux besoins fonctionnels et managériaux, respectant le planning et les contraintes budgétaires
106J. Akoka / I. Wattiau
Objectifs de l’assurance qualité du développement de logiciel
Assurer un niveau acceptable de confiance dans la conformité du logiciel aux spécifications fonctionnellesAssurer un niveau acceptable de confiance dans la conformité du logiciel au planning et au budgetAssurer les activités d’amélioration du développement et d’assurance qualité
107J. Akoka / I. Wattiau
Objectifs de l’assurance qualité de la maintenance logicielle
Assurer un niveau acceptable de confiance dans la conformité de la maintenance aux spécifications fonctionnellesAssurer un niveau acceptable de confiance dans la conformité de la maintenance au planning et au budgetAssurer les activités d’amélioration de la maintenance et d’assurance qualité
108J. Akoka / I. Wattiau
L’assurance qualité pendant le projet
Revues Opinions d’expertTest logicielMaintenance corrective, adaptative et évolutive
Revue du contrat de maintenancePlan de maintenance
Assurance qualité dans l’implication de personnes extérieures (contrat)
109J. Akoka / I. Wattiau
Infrastructure de prévention et d’amélioration
Procédures et « checklists »Formation et certification des équipesActions préventives et correctivesGestion de configurationContrôle de la documentation
110J. Akoka / I. Wattiau
L’assurance qualité dans la gestion de projet
Contrôle de l’avancement du projetMétriques de qualité du logicielSuivi des coûts
livrables
L1 L2 L3 L4 L5Processus logiciel
Processus qualité
Standards etprocédures
Plan qualité Rapports de revue qualité
111J. Akoka / I. Wattiau
Les standards de l’assurance qualité
Permettent :de se référer à la connaissance professionnelle internationaleL’amélioration de la coordination avec les systèmes qualité des autres organisationsL’évaluation et la mesure objectives des réalisations de l’organisation
112J. Akoka / I. Wattiau
Les éléments humains de l’assurance qualité
Importance du managementCellule qualitéComités qualitéForums qualité
114J. Akoka / I. Wattiau
Les différents types de contrat
Réponse à un appel d’offresCommande d’un clientDemande interneEtc.
116J. Akoka / I. Wattiau
Revue de la demande
S’assurer que :Les demandes du client sont claires et documentéesLes approches alternatives ont été examinéesLes aspects formels de la relation client-fournisseur sont spécifiésLes risques liés au développement sont identifiésLes ressources et le délai nécessaires sont estimés de façon adéquateLa capacité du client à respecter ses engagements est examinéeLes conditions de participation d’autres partenaires ou sous-traitants sont définies
117J. Akoka / I. Wattiau
Revue de la réponse
Pas de problème non clarifié dans la propositionToutes les interprétations possibles de la demande sont considéréesIl n’y a pas eu de changement depuis la rédaction de la demande (adéquation demande-réponse)
118J. Akoka / I. Wattiau
Problème Conséquence pour le “client” Conséquence pour le développeur
Définition insuffisante des
besoins
Ecart entre l’attendu et le livré
Insatisfaction du client
Changement constant des demandes du client
Pas d’estimation des ressources
Attentes irréalistes par rapport
à la faisabilité du projet
Dérive des coûtsFrictions dues aux demandes de “rallonges”
Planning inexistant ou succinct
Pas d’échéancier pour la livraison du produit
Pas de contrainte de délaiDérapage dans les délais et la qualité
Méconnais-sance des risques
Client non préparé aux risques liés au projet et à
leurs conséquences
Prise en compte tardive des problèmes
Cas particulier des projets « internes »
120J. Akoka / I. Wattiau
Objectifs du plan qualité
Planifier la qualité permet de préparer les bases d’un projet réussiInclut :
PlanningEstimation des ressources et du budgetRecrutement des équipesIdentification des risquesMise en place des activités de l’assurance qualitéFourniture au management des données nécessaires au contrôle du projet
121J. Akoka / I. Wattiau
Les éléments d’un plan projet
Les livrablesLes interfacesLa méthodologie et les outils de développement Les standards et les procéduresLes jalonsL’organisation du projet et la coordination avec les participants externesLes risques liés et les actions de gestion des risquesLes moyens et méthodes de contrôleLes estimations de coûts
122J. Akoka / I. Wattiau
Les éléments d’un plan qualité
Les objectifs de la qualitéLes activités de revueLes tests Les recettesLa gestion de configuration : outils, procédures, données, gestion des versions, etc.
123J. Akoka / I. Wattiau
Risques liés au développement
Dérapage du planningFonctionnalités du systèmeSous traitancePrise en compte des besoinsUtilisation des ressources et performanceGestion des ressources humaines
124J. Akoka / I. Wattiau
10 risques de Boehm et Ross
Développer des fonctionnalités non correctesDélais et budgets irréalistesInterfaces utilisateurs non adaptées«Plaqué or »Arrivée incessante de changements dans les demandesDéfauts dans les composants externesDéfauts dans les développements externesDéfaillance du personnel (« turnover »)Performances système insuffisantesLimites des possibilités techniques
125J. Akoka / I. Wattiau
Avant--projet
Identification et priseen compte des risques
Planification des activités de gestion des risques
Nouveau projet
Mise à jour de la gestiondes risques
Mise en place des actions degestion des risques
Surveillance des activitésde gestion des risques
Identification et évaluation des nouveaux
risques
Projetsen cours
Evaluerles résultats
Objectifs atteints Résultats insatisfaisants
Le processus de gestion de risques
127J. Akoka / I. Wattiau
Méthodologies de gestion de projet
Cycle de vie du produit logicielPrototypageModèle en spirale
128J. Akoka / I. Wattiau
Définition desbesoins
Conceptiondu logiciel
Développementdu prototype
Développement du syst ème
Validation duprototype
Mise en exploitationet maintenance
Demandes d ’ajoutset de modifications
Les besoins sont-ils satisfaits ?
Tests d ’acceptation
NON
OUI
Prototypage
131J. Akoka / I. Wattiau
Facteurs influant sur le processus qualité
Facteurs liés au projetTaille du projetComplexité technique du projetAjout de composants logicielsGravité des conséquences en cas d’échec du projet
Facteurs liés à l’équipeQualification des membresProximité avec le projet et expérience dans le domaineDisponibilité des équipes métiersAncienneté des individus et des équipes
132J. Akoka / I. Wattiau
Vérification, validation et qualification
Vérification : processus d’évaluation d’un système ou d’un composant pour déterminer si les livrables d’une phase du développement satisfont les conditions imposées au début de cette phase« building the product right »
Validation : processus d’évaluation d’un système ou d’un composant pendant ou à la fin du processus de développement pour déterminer s’il satisfait les spécifications« building the right product »
Qualification : processus utilisé pour déterminer si un système ou un composant est opérationnel
IEEE Std 610.12-1990 (IEEE 1990)
133J. Akoka / I. Wattiau
Modèle d’estimation des coûts liés aux défaut
Résultats quantitatifs :Efficacité du plan qualité dans l’élimination des défauts des logicielsCoûts totaux d’élimination des défauts
134J. Akoka / I. Wattiau
Phase du projet Pourcentage moyen de défautsgénérés
Coût moyenrelatif d’élimination
du défaut
Spécification des besoins 15% 1
Conception 35% 2.5
Codage unitaire 30% 6.5
Intégration 10% 16
Documentation 10% 16
Test du système ----- 40
Exploitation ----- 110
Origine des défauts vs coûts de leur élimination
135J. Akoka / I. Wattiau
Activité d’assurance qualité Efficacité de la détection des
erreurs avec plan standard
Efficacité de la détection des erreurs avec plan
détaillé
Revue de la spécification des besoins
50% 60%
Inspection de la conception ----- 70%
Revue de la conception 50% 60%
Inspection du code ----- 70%
Test du code 50% 40%
Tests d’intégration 50% 60%
Revue de la documentation 50% 60%
Test du système 50% 60%
Détection pendant l’exploitation 100% 100%
Efficacité de la détection des erreurs avec plan qualité
136J. Akoka / I. Wattiau
Phase d’élimination des défauts Efficacité del’élimina-tion
Coût relatif moyen de suppression d’un défaut
Phase d’origine du défaut
Besoins Conception
Coda-ge
Intégration
Doc.
Spécification des besoins 50% 1 --- --- --- ---
Conception 50% 2.5 1 --- --- ---
Codage unitaire 50% 6.5 2.6 1 --- ---
Intégration Documentation système
50%50%
1616
6.46.4
2.52.5
11
Test système / Test d’acceptation 50% 40 16 6.2 2.5 1
Effectué par le client (après livraison)
100% 110 44 17 6.9 2.5
Efficacité de la suppression des erreurs avec plan qualité
137J. Akoka / I. Wattiau
Maintenance logicielle
Maintenance corrective
Maintenance
adaptative
Maintenanceévolutive
Maintenance
perfective
Maintenancepréventive
Maintenance logicielle
138J. Akoka / I. Wattiau
Facteur de qualité Maintenancecorrective
Maintenanceadaptative
Maintenanceévolutive
Exactitude des sorties +++
Exactitude de la documentation +++ +++ +++
Exactitude de la qualification +++ +++ +++
Fiabilité +++
Maintenabilité +++ +++ +++
Flexibilité +++
Testabilité +++
Portabilité +++
Interopérabilité +++
Facteurs qualité ayant un impact fort sur la maintenance logicielle
139J. Akoka / I. Wattiau
Clarification des besoins du “client”
Analyse des alternatives de réalisation de la maintenance
Revue de l’estimation des moyens requis
Revue des services de maintenance fournis par la sous-traitance ou par le client
Revue de l’estimation des coûts
Composants de l’assurance qualité : la revue de maintenance
140J. Akoka / I. Wattiau
Comprend :Une liste des services de maintenance faisant l’objet d’un contrat (clients internes ou externes)
Une description de l’organisation de l’équipe de maintenance
Une liste des outils de maintenance
Une liste des risques liés à la maintenance
Une liste des procédures de maintenance
Le budget
Composants de l’assurance qualité : le plan de maintenance
142J. Akoka / I. Wattiau
Causes des erreurs Degré de contribution
1. Mauvaise définition des besoins Presque aucun
2. Mauvaise communication Presque aucun
3. Déviations délibérées par rapport aux spécifications
++
4. Erreurs de logique ++
5. Erreurs de codage +++
6. Décalage entre le codage et la documentation +++
7. Insuffisances des tests ++
8. Interface utilisateur et erreurs dans les procédures
+
9. Erreurs de documentation ++
Degré de contribution des outils CASE àla qualité
143J. Akoka / I. Wattiau
Contribution des outils CASEà la qualité de la maintenance
� La documentation générée et mise à jour par l’outil facilite l’identification des erreurs
� Les contrôles de cohérence du CASE facilitent l’anticipation des erreurs
� La correction dans les outils “lower CASE” ou CASE intégrés fournit une documentation automatique des corrections
144J. Akoka / I. Wattiau
Code Nom Formule de calcul
TTO Respect du planning MSOTTTO = -----------
MS
ADMC Retard moyen par jalon TCDAMADMC = -----------
MS
MSOT = Jalons terminés à tempsMS = Nb total de jalons.TCDAM = Total des retards (jours, semaines, etc.) pour tous les jalons
Métriques de délai
145J. Akoka / I. Wattiau
Code Nom Formule de calcul
DERE Efficacité de la suppression des erreurs
NDEDERE = ----------------
NDE + NYF
DWERE Efficacité pondérée WDEDWERE = ------------------
WDE+WYF
NCE = Nb d’erreurs de codage détectées pendant l’inspection du code ou pendant les testsNDE = Nb total d’erreurs détectées (codage et logique) pendant le développementWCE = Nb d’erreurs de codage détectées pendant l’inspection du code ou pendant les tests et pondérées par degré de sévéritéWDE = Nb total d’erreurs détectées pendant le développement et pondérées par sévéritéNYF = Nb d’échecs du logiciel détectés pendant un an de maintenanceWYF = Nb d’échecs du logiciel détectés pendant un an de maintenance pondérés par sévérité
Métriques d’efficacité de la correction d’erreur
146J. Akoka / I. Wattiau
Code Nom Formule de calcul
DevP Productivité du développement KLOCDevP = ----------
DevH
FDevP Productivité du développement par PF
NFPFDevP = ----------
DevH
CRe Réutilisation de code ReKLOCCre = --------------
KLOC
DocRe Réutilisation de documentation ReDocDocRe = -----------
NDoc
DevH = Nb d’heures total de développement.ReKLOC = NB de milliers de lignes de code réutilisées.ReDoc = Nb de pages de documentation réutilisées.NDoc = Nb de pages de documentation.
Métriques de productivité du processus
147J. Akoka / I. Wattiau
Métrique de qualité du helpdesk (HD)
Métrique de densité d’appelMétrique de sévérité d’appelMétrique de succès du HD
Métrique de productivité du HD
Métrique d’efficacité du HD
Métrique de qualité de la maintenance corrective
Les catégories de métriques de produits
148J. Akoka / I. Wattiau
Code Nom Formule de calcul
HDD Densité des appels HD NHYCHDD = --------------
KLMC
WHDD Densité pondérée des appels HD WHYCWHYC = ------------
KLMC
WHDF Densité pondérée par point de fonction
WHYCWHDF = ------------
NMFP
NHYC = nb d’appels HD pendant une année.KLMC = milliers de ligne de code à gérer.WHYC = nb d’appels HD pendant une année pondérés par sévérité.NMFP = nb de points de fonction à gérer
Métriques de densité d’appels HD
149J. Akoka / I. Wattiau
Code Nom Formule de calcul
ASHC Sévérité moyenne des appels HD WHYCASHC = --------------
NHYC
NHYC = Nb d’appels HD pendant un an
WHYC = Nb d’appels HD pendant un an pondérés par sévérité
Métriques de sévérité d’appels HD
150J. Akoka / I. Wattiau
Code Nom Formule de calcul
HDS Succès du service de HD NHYOTHDS = --------------
NHYC
NHYOT = Nb d’appels HD traités dans les délais pendant un an. NHYC = Nb d’appels HD reçus pendant un an.
Métriques de succès du HD
151J. Akoka / I. Wattiau
Code Nom Formule de calcul
HDP Productivité du HD KLNCHDP= --------------
HDYH
FHDP Productivité du HD par point de fonction
NMFPFHDP = ----------
HDYH
HDE Efficacité du HD NHYCHDE = --------------
HDYH
HDYH = Nb d’heures total de HD.KLNC = Nb de KLOC géréesNMFP = Nb de points de fonction gérés.NHYC = Nb d’appels HD pendant un an.
Métriques de productivitéet d’efficacité du HD
152J. Akoka / I. Wattiau
Code Nom Formule de calcul
SSFD Densité d’échec du logiciel NYF SSFD = --------------
KLMC
WSSFD Densité d’échec du logiciel pondérée
WYFWFFFD = ---------
KLMC
WSSFF Densité d’échec par point de fonction
WYFWSSFF = ----------
NMFP
NYF = nb d’échecs logiciels détectés pendant un anWYF = nb d’échecs logiciels détectés pondérés pendant un anNMFP = nb de points de fonctionKLMC = nb de milliers de lignes de code.
Métriques de densité d’échec du logiciel
153J. Akoka / I. Wattiau
Code Nom Formule de calcul
ASSSF Sévérité moyenne des échecs du logiciel
WYFASSSF = --------------
NYF
NYF = nb d’échecs pendant un an.WYF = nb d’échecs pondérés par sévérité pendant un an.
Métriques de sévérité d’échecdu logiciel
154J. Akoka / I. Wattiau
Code Nom Formule de calcul
MRepF Métrique d’appels d’échecs répétés
RepYFMRepF = --------------
NYF
NYF = nb d’échecs pendant un anRepYF = nb d’échecs répétés pendant un an
Métriques d’échec du service de maintenance
155J. Akoka / I. Wattiau
Code Nom Formule de calcul
FA Disponibilité pleine NYSerH - NYFHFA = -----------------------
NYSerH
VitA Disponibilité vitale NYSerH - NYVitFHVitA = -----------------------------
NYSerH
TUA Indisponibilité totale NYTFHTUA = ------------
NYSerH
NYSerH = Nb d’heures de fonctionnement du logiciel par an NYFH = Nb d’heures où au moins une fonction n’est pas disponibleNYVitFH = Nb d’heures où au moins une fonction vitale n’est pas disponibleNYTFH = Nb d’heures d’arrêt total dû à un échecNYFH ≥ NYVitFH ≥ NYTFH.1 – TUA ≥ VitA ≥FA
Métriques de disponibilité du logiciel
156J. Akoka / I. Wattiau
Code Nom Formule de calcul
CMaiP Productivité de la maintenance corrective
KLMCCMaiP = ---------------
CMaiYH
FCMP Productivité de la maintenance corrective par point de fonction
NMFPFCMP = --------------
CMaiYH
CMaiE Efficacité de la maintenance corrective
NYFCMaiE = ------------
CMaiYH
CMaiYH = Nb d’heures de maintenance corrective par anNYF = Nb d’échecs du logiciel par anNMFP = Nb de points de fonctionKLMC = Milliers de lignes de code
Métriques de productivité et d’efficacitéde la maintenance corrective
157J. Akoka / I. Wattiau
- Contraintes budgétaires
- Facteurs humains : réticence à l’auto-évaluation
- Validité : incertitude sur les données
- Difficultés liées aux paramètres (voir suite)
Limitations des métriques
158J. Akoka / I. Wattiau
a. Style de programmation (KLOC).b. Volume des commentaires (KLOC).c. Complexité du logiciel (KLOC, NCE).d. Pourcentage de code réutilisé (NDE, NCE).e. Professionnalisme dans la détection d’erreurs (NCE).f. Styles de rapports de développement (NDE, NCE).
Facteurs affectant les paramètres des métriques utilisées pour le processus de
développement
159J. Akoka / I. Wattiau
a. Qualité du logiciel et de sa documentation (NYF, NHYC).
b. Style de programmation et volume des commentaires (KLMC).
c. Complexité du logiciel (NYF).d. Pourcentage de code réutilisé (NYF).e. Nb d’installations, nb d’utilisateurs, niveau d’utilisation
(NHYC, NYF).
Facteurs affectant les paramètres des métriques utilisées pour le processus de
maintenance
161J. Akoka / I. Wattiau
Conclusion
Domaine en pleine expansionLié à d’autres phénomènes :CertificationMaster data management
Pléthore d’outils :Lesquels utiliser ? Comment choisir ? Comment les mettre entre les mains des non informaticiens ?
Des domaines spécifiquesQualité des données géographiquesQualité des informations sur InternetQualité dans le domaine médical