Qualité en informatique Pr. Rémy Courdier Email : Remy.Courdier@univ-reuni.fr 1 Plan du cours Chapitre 1 : Sensibilisati au Green IT Chapitre 2 : Qualité informatique Introducti à la Qualité Informatique 2
1. Introducti à la Qualité Informatique Ctexte de l informatique Les projets informatiques présentent bien souvent une part d incnu et dc de risques. Mécnaissance des besoins par le client Incompréhensi des besoins par le fournisseur Instabilité des besoins Changement des choix technologies Mouvements de persnels... 3 1. Introducti à la Qualité Informatique 1.1 Difficultés induites 1. Difficulté de maîtrise des coûts 2. Difficulté de réalisati de plannings 3. Difficulté de maîtrise des délais de réalisati 4. Difficulté d améliorati de la productivité et de la qualité des logiciels 5. Difficulté de gesti de projets logiciels de grande ampleur (Programming in the Large) 6. Nombreux échecs : résultats fournis par les logiciels insatisfaisants pour les clients finaux. Tout ceci dans un ctexte de compétiti internatiale sévère 4
1. Introducti à la qualité logicielle Quelques idées sur les coûts... i 1. Répartiti : (Ref. Boehm) 1. Analyse/Ccepti 1. 33-34 % : Système d exploitati, Aérospatiale 2. 44-46 % : Ctrôle et Régul. indus., Calcul scientifique, Gesti 2. Codage 1. 17-20 % : Système d expl., Ctrôle et Régul. indus., Aérospatiale 2. 26-28 % : Calcul scientifique, Gesti 3. Test/Intégrati 1. 28-34 % : Ctrôle et Régul. indus., Calcul scientifique, Gesti 2. 46-50 % : Système d exploitati, Aérospatiale 4. Maintenance 1. Plus de 100% du coût des phases précédentes! 5 1. Introducti à la Qualité Informatique Nombreux échecs i Logiciels insatisfaisants & Difficulté de maintenabilité 6
1. Introducti à la Qualité Informatique Que faire pour s améliorer 1. Premier «brainstorming» 1. Embaucher des supers chef de projets? 2. N embaucher que des experts? 3. Faire des heures sup et travailler le week-end? 4. Faire des opératis coups de poing? 5. Faire des plans d actis? Ceci est déjà fait depuis bien lgtemps, alors.. 1. Trouver des pistes 7 Les inctournables pour tout informaticien... «Les Boites noires» 1. Introducti à la Qualité Informatique La qualité du travail d un informaticien commence par quelques repères simples Découpage du logiciel en modules indépendants présentant des caractéristiques d abstracti, d encapsulati, et de faible couplage 1. abstracti : chaque module doit correspdre à une abstracti préexistante et doit pouvoir être défini de faç abstraite, indépendamment de tout traitement susceptible d utiliser le module. 2. encapsulati : masquage de la mise en œuvre effective du module, du comment c est fait. Seules les éléments accessibles de l extérieurs st visibles et spécifiés précisément. 3. faible couplage : limitati des cnexis entre modules (dépendances de générati,...). Il est indispensable que les liens entres modules soient bien définis (couches logicielles) et le moins nombreux possible pour qu il y ait effectivement modularité. 8
Les inctournables pour tout informaticien... Vocabulaire 1. Facteurs externes (visibles par le client) 1. Exactitude : le logiciel fournit les bs résultats 2. Robustesse : le logiciel réagit correctement à des dnées fausses 3. Stabilité : possibilité d intégrer des modif. de spécificati légères 4. Fiabilité : exactitude + robustesse 5. Efficacité : performances d exécuti, encombrement mémoire, 6. Ergomique : ccepti bien adaptée à l utilisateur 9 Les inctournables pour tout informaticien... Vocabulaire 1. Facteurs de qualité internes 1. Maintenabilité (support du temps..., testabilité, traçabilité) 2. Portabilité 3. Compatibilité 4. Extensibilité 5. Réulilisatibilité 6. Cohési : forte cohési dans les modules 7. Faible couplage entre les modules 10
Les inctournables pour tout informaticien... Vocabulaire 1. Facteurs de qualité liés aux Dnées informatiques 11 1. Introducti à la Qualité Informatique OK comment va t plus loin La médiocrité vient sans qu' l'appelle ; la qualité, il faut la vouloir violemment. F. Mayer 1. Qualificati du persnel par la formati 2. Procédures de gesti de la qualité logiciel 3. Outils dédiés au GL (CASE, Logiscopes) 4. Langages et envirnements de programmati 5. Prototypage 6. Réutilisabilité 12
OK comment va t plus loin (2) Faire comme d autres métiers Mettre en place une démarche méthodique, pour obtenir le meilleur résultat possible MÉTHODOLOGIE 13 Plan du cours 1. Chapitre 1 : Sensibilisati au Green IT 2. Chapitre 2 : Qualité informatique 1. Introducti à la Qualité Informatique s Informatiques 14
Commençs Ctexte de PME en informatique Méthodologies simples de mise en œuvre Peu couteuse en organisati Peu couteuse en temps «agile» : référence à la capacité d'adaptati aux changements de ctexte et aux modificatis de spécificatis intervenant pendant le processus de développement. Objectif Réduire le cycle de vie du logiciel en développant une versi minimale, puis en intégrant les fctinalités par un processus itératif basé sur une écoute client et des tests tout au lg du cycle de développement. Les 4 valeurs portées par les méthodes AGILE 1. individus et interactis plutôt que processus et outils 2. développement logiciel plutôt que documentati exhaustive 3. collaborati avec le client plutôt que négociati ctractuelle 4. ouverture au changement plutôt que suivi d'un plan rigide Méthode AGILE (Agile Modeling) XP - extreme Programming RAD - Rapid Applicati Development FDD - Feature Driven Development DSDM - Dynamic Software Dev. Method SCRUM -(qui signifie mêlée au rugby 15 Les 12 principes des méthodes AGILE 1. Accorder une haute priorité à la satisfacti du client 2. Accepter le changement de besoins même tardivement 3. Livrer fréquemment un logiciel qui marche à échéances régulières 4. Faire travailler ensemble quotidiennement les utilisateurs et les développeurs 5. Cstruire les projets autour de persnes motivées, leur dner du support et leur faire cfiance 6. Privilégier la communicati face à face 7. Csidérer les versis opératinelles du logiciel comme étant les mesures principales de progrès 8. Spsors, développeurs et utilisateurs doivent pouvoir tenir un rythme cstant 9. Apporter une attenti ctinue à l excellence technique et à la bne ccepti 10. Privilégier la simplicité, maximisé le travail à ne pas faire 11. Les choix émergent d équipes auto-organisées 12. Réfléchir à intervalle régulier à la faç de devenir plus efficace individuellement et collectivement 16
XP - extrem Programming (1) 2.1 Méthodes Agile Biblio 1999, Kent Beck Cohési équipe 1. Respsabilité collective du code 2. Travail en binôme 3. Règles de codage 4. Intégrati Ctinue! Développeur travaillant sur différentes parties du code! Renouvellement régulier des binômes! Définies par l équipe elle même! Des développements quotidiennement intégrés 17 2.1 Méthodes Agile extrem Pragramming (2) 18
OK comment va t plus loin (2) i Adopt Model of best practices of high performance organizatis CERTIFICATIONS INTERNATIONALES 19 2.2 Certificatis Internatiales Les Certificatis Internatiales i Entreprise d informatique placée sur les marchés internatiaux Obenti de la recnaissance d un certain niveau de maturité sur le marché informatique, Mise en cfiance des clients Normes Document établi par un csensus et approuvé par un organisme recnu, qui fournit, pour des usages communs et repérés, des règles, des lignes directrices ou des caractéristiques, pour des activités ou leurs résultats, garantissant un niveau d'ordre optimal dans un ctexte dné. Standards Ensemble de recommandatis développées et précisées par un groupe représentatif d utilisateurs. Certificati Internatiale CMMI ISO COBIT ITIL 20
Normes et standards Nuances à saisir Une norme est publié par un organisme de normalisati officiellement agréé par un État (comme Afnor) ou issu d'un traité internatial (comme ISO). Un standard est généralement déterminé soit par un industriel pinier ou en positi dominante sur un marché, soit par une associati professinelle ou un csortium d'acteurs industriels (Comme PostScript d Adobe) Attenti «norme» se dit «standard» en anglais, parle pour les normes de standards de jure et pour les simples standards de standards de facto. 21 Cartographie des référentiels nomalisés dans le domaine informatique 2.2 Certificatis Internatiales 22
Critères de choix de référentiel normalisé 2.2 Certificatis Internatiales i 23 Modèle d évoluti des capacités logiciel Capability Maturity Model 2.2 Certificatis Internatiales i «Demstrate Your Organizati's Capability Moving your capability from practice to process makes your organizati resilient, sustainable, and scalable. This shift is the reas that CMMI adopti has been a differentiator for organizatis around the world, and it can provide a competitive edge for you, too.» 24
Organisatis logiciels immatures et matures Organisati immature 2.2 Certificatis Internatiales Processus logiciel improvisés Si processus existe, il n est pas appliqué de faç rigoureuse Les respsables se ctentent de résoudre les crises Les délais et les budgets st dépassés Lorsque les échéances st impératives, la fctinalité et la qualité du produit st compromises 25 Organisatis logiciels immatures et matures (2) Organisati mature 2.2 Certificatis Internatiales Capacité généralisé de gesti du processus logiciel et de maintenance logiciel Le processus est communiqué de faç exacte Les travaux effectués st exécutés sel le processus planifié Les processus st opératinels et cformes au déroulement réel des travaux Les processus st mis à jour au besoin Les amélioratis st développés à l aide d essais ctrôlés et/ou d analyses coûts-bénéfices Les respsabilités st réparties de faç n équivoque 26
CMM & Qualité logiciel CMM (Capability Maturity Model) Outil de mesure de qualité des sociétés de développement informatique. Origine : 1987 - SEI Software Ingineering Institute de la Carnegie Mell University Les niveaux du CMM Niveau 1 : Initial Niveau 2 : Répétable - Méthodes élémentaires de gesti Niveau 3 : Défini - Définiti du processus de développement Niveau 4 : Maîtrisé : Gesti du processus de développement Niveau 5 : Optimisé : Ctrôle et optimisati Le Niveau 2 est de plus en plus souvent requise par les grands groupes industriel 27 CMM : Niveau 1 2.1 CMM Niveau 1 : Initial Peu de formalisati, Aband de toute méthode en cas de crise Le processus de développement est «ad hoc», et parfois même chaotique. Peu de procédures st définies et le succès repose sur des efforts individuels. Sur 782 évaluatis sept. 2005 28
2.1 CMM CMM : Niveau 2 Niveau 2 : Répétable Méthodes élémentaires de gesti Processus stabilisés, résultats statistiquement répétables Une procédure de gesti minimale est définie pour suivre les coûts, les délais et les fctis. Les procédures nécessaires st en places pour répéter les succès antérieurs à des projets similaires. Gesti de cfigurati logiciel Assurance-Qualité logiciel Gesti de la sous-traitance logiciel Suivi de la supervisi du projet Planificati de projet logiciel Gesti des exigences 29 CMM : Niveau 3 Niveau 3 : Défini - Définiti du processus de développement 2.1 CMM Les processus de gesti et! Gesti de cfigurati technique st documentés, rigoureuse, respects des standardisés à un processus normes et standards, standard de l organisati. inspectis et tests Tous les projets utilisent une versi approuvée et adaptée formels, existence d un des processus standards pour service de GL ou Qualité développer et maintenir le logiciel. logiciel. Revues par des pairs Coordinati intergroupes Ingénierie de produits logiciel Gesti logiciel intégré Programme de formati Définiti du processus de l organisati Focalisati organisatinelle sur les processus 30
2.1 CMM CMM : Niveau 4 Niveau 4 : Maîtrisé Gesti du processus de développement! Des mesures détaillées du développement et de qualité st collectées.! Les processus et le produit st quantitativement compris et ctrôlés. Gesti quantitative de processus : ctrôle de la performance des processus Compréhensi de la qualité des produits logiciels 31 CMM : Niveau 5 Optimisé : Ctrôle et optimisati Les processus st ctinûment améliorés par les analyses des mesures. Gesti des changements technologiques Préventi des défauts 32
Synthèse des niveaux CMM Niveau 1 : Initial Peu de formalisati, Aband de toute méthode en cas de crise Le processus de développement est «ad hoc», et parfois même chaotique. Peu de procédures st définies et le succès repose sur des efforts individuels. Niveau 2 : Répétable - Méthodes élémentaires de gesti Processus stabilisés, résultats statistiquement répétables Une procédure de gesti minimale est définie pour suivre les coûts, les délais et les fctis. Les procédures nécessaires st en places pour répéter les succès antérieurs à des projets similaires. Niveau 3 : Défini - Définiti du processus de développement Les processus de gesti et technique st documentés, standardisés à un processus standard de l organisati. Tous les projets utilisent une versi approuvée et adaptée des processus standards pour développer et maintenir le logiciel. Gesti de cfigurati rigoureuse, respects des normes et standards, inspectis et tests formels, existence d un service de GL ou Qualité logiciel. Niveau 4 : Maîtrisé : Gesti du processus de développement Des mesures détaillées du développement et de qualité st collectées. Les processus et le produit st quantitativement compris et ctrôlés. Niveau 5 : Optimisé : Ctrôle et optimisati Les processus st ctinûment améliorés par les analyses des mesures. 33 2.1 CMM Synthèse des organisatis évaluées (3) Sur 782 évaluatis 34
2.1 CMM Synthèse des organisatis évaluées (2) USA/ N USA 35 2.1 CMM Synthèse des organisatis évaluées (3) Prise en compte de l activité de Défense 36
2.1 CMM Synthèse des organisatis évaluées (4) Prise en compte de la taille des entreprises 37 2.1 CMM Zes géographiques des entreprises évaluées CMM Quelles zes du mde s intéresse à CMM? 38
Quels pays s intéressent à CMM? Gesti de Projet CMM 39 Quelles organisatis s intéressent à CMM Dans les année 2000? Une Liste des évaluatis réalisées est dispible sur l Internet 2.1 CMM http://seir.sei.cmu.edu/pars/pars_list_iframe.asp 40
Quelles organisatis s intéressent à CMMI? Dans le mde - CMMI Level 5-2012-2014 2.1 CMM 41 Quelles organisatis s intéressent à CMMI? En France - CMMI Level 5-2012-2014 Anybody here? No Pourtant la France est particulièrement recnue dans le secteur du logiciel! 42
43 2.2 ISO Normes de l ISO ISO 9126 Ensemble de normes qui définit le modèle de qualité pour un produit logiciel Ccepti Fabricati - Utilisati II ISO 14 598 Ensemble de normes publié par l AFNOR sous le titre «Ingénierie du logiciel Évaluati de produit logiciel» Définit les démarches méthodologiques pour l évaluati de la qualité logiciel III ISO 25 000 Square : Software QUAlity Requirements and Evaluati Poser le cadre et les références pour définir et évaluer les exigences qualité Retenu par le SEI pour améliorer les performances du CMMI A terme : devrait remplacer les normes ISO 9126 et ISO 14598 44
2.2 ISO NORME ISO 9126 i ISO 9126 partie 1 (1992) Caractéristiques de qualité Directives d utilisati Statut de norme Définit le modèle de qualité pour un produit logiciel ISO 9126 partie 2 (2003) Métrologie interne Rapport technique ISO 9126 partie 3 (2003) Métrologie externe Rapport technique ISO 9126 partie 4 (2003) Métrologie d usage Rapport technique 45 2.2 ISO ISO 14598 i Définit des démarches méthodologiques pour l évaluati de la qualité logiciel 46
2.2 ISO ISO 25000 i A terme : devrait remplacer les normes ISO 9126 et ISO 14598 47 OK comment va t plus loin (3) i Trouver des pistes Améliorer les pratiques de travail au quotidien OUTILS DE GESTION DE QUALITÉ 48 48
Plan du cours Chapitre 1 : Sensibilisati au Green IT Chapitre 2 : Qualité informatique Introducti à la Qualité Informatique Méthodologies Informatiques Outils de la Qualité 49 49 Un mot sur les logiscopes Outil permettant de vérifier et d'évaluer le code source d'un logiciel en calculant les métriques Métrique : Nombre qui mesure la grandeur/la complexité du code d'un logiciel Exemples de métriques Nombre de lignes de codes Evaluati du nombre d'opérateurs et d'opérandes Mesure le nombre cyclomatique : nombre de chemins indépendants dans le graphe 50 50
Exemple de Logiscope 51 51 Un mot sur la gesti de versis logiciel Caractère spécifique du développement logiciel Nombreux documents principalement de format texte Problème de cohérence, Problème de dépendance Travail en parallèle Fichier modifié simultanément Problèmes de coordinati Retour en arrière Evoluti simultanée de variantes de versis Problème d historisati et d archivage Nécessité de comparer les versis Perte de fichier Fiabilité des supports de stockage de dnées Problème d un développeur qui crash Logiciel de gesti de versis 52 52
Type de solutis Soluti centralisée Soluti distribuée Soluti distribuée avancée 53 53 Solutis centrilisée Exemple d outils de gesti de versis logiciel Current Versi System, en abrégé CVS Le plus ancien (1990), encore très répandu Projets : Open BSD Apache Subversi, en abrégé SVN Cçu pour remplacer CVS, meilleur implémentati Le plus utilisé, simple d utilisati Projets: Apache, Redmine, Struts Solutis distribuées Mercurial Plus récent et plus puissant Projets : Mozilla, Pyth, Openoffice.org Puissant et récent (2005 par Linus Torvalds) Spécialement optimisé pour le noyau Linux Projets :Kernel de Linux, Debian, VLC, Android 54 54
Le top CV Qualité informatique 55 55 Fin du Chapitre 2 Qualité Informatique Références : François Dufay, CMMI par l exemple, Editi Eyrolles, ISBN : 987-2-212-12687-7, 287 pages, 2010. Analysis of ISO/IEC 9126 and 25010, Jean-Marc Desharnais, http://www2.cmpe.boun.edu.tr/courses 56 56
Références François Dufay, CMMI par l exemple, Editi Eyrolles, ISBN : 987-2-212-12687-7, 287 pages, 2010. 57 57 Le cycle en spirale (Boehm) A chaque spire, il y a itérati complète sur les phases : Analyse (Quoi?) Ccepti (Comment?) Codage Test A chaque itérati, le logiciel doit être dans un état quasi commercialisable Grand intérêt en prototypage incrémental Très utilisé sur les projets informatiques. «Design a little, code a little» La première spire doit comprendre les éléments les plus abstraits et Le cœur fctinel minimum du système 58 58