Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Qualité logiciel - Generalités

2,505 views

Published on

Formation généraliste rédigée en Juin 2009

Qualité logiciel
Plan Qualité
Gestion Processus de développement
Gestion des exigences
Gestion de configuration
Gestion des tests
Gestion des anomalies
Gestion de la documentation

Published in: Business
  • Be the first to comment

Qualité logiciel - Generalités

  1. 1. Qualité Logiciel 1 Généralités @crochefolle Juin 2009
  2. 2. @crochefolle 2 Présentation  Qui suis-je ?  Qualité logiciel  Plan Qualité  Gestion Processus de développement  Gestion des exigences  Gestion de configuration  Gestion des tests  Gestion des anomalies  Gestion de la documentation
  3. 3. @crochefolle 3 Qui suis-je ? Porteur d’organisations, méthodes et outils pour améliorer la qualité des projets et produits, du recueil des besoin à la mise en production, le tout avec passion & plaisir depuis 10 ans ! 10 ans 5 entreprises < 100 personnes #editeurLogiciel #startup #testLogiciel #qualité #offshore
  4. 4. @crochefolle 4 Qualité Logiciel : définitions  Qualité : « l’ensemble des caractéristiques d'une entité qui lui contèrent l'aptitude à satisfaire des besoins exprimés et implicites » (source : norme NF EN ISO 9000:2000)  Entité : tout ce « qui peut être décrit et considérée individuellement » : produit, processus, organisme ou combinaison des 3 (source : norme NF EN ISO 9000:2000)  Qualité du logiciel : « ensemble des traits et caractéristiques d’un produit logiciel portant sur son aptitude à satisfaire des besoins exprimés et implicites » (source : norme ISO/CEI 9126:1991)
  5. 5. @crochefolle Postulats préalables à toute démarche qualité 1. Définir les exigences qualité : Les attentes du client/utilisateur en matière de qualité sont clairement définis. Au-delà des spécifications fonctionnelles, le cahier des exigences doit prendre en compte les besoins en termes de caractéristiques de la qualité. 2. Mesurer la qualité : Les caractéristiques qualité doivent être mesurables pour permettre de vérifier le niveau de la qualité. 3. Maîtriser les processus : La qualité du produit peut être maîtriser par la maîtrise du processus qui le crée, de la conception à la livraison. 5
  6. 6. @crochefolle Normes Norme Titre Description NF EN ISO 9000 Management de la qualité et assurance qualité - Vocabulaire Norme généraliste de base de tout processus qualité NF ISO/CEI 12207 Processus du cycle de vie du logiciel Cadre pour un démarche projet Z 67-130 Système de traitement de l’information – Recommandation de plan qualité logiciel Rédaction des plansAFCIQ-PDL Recommandation de plan de développement logiciel AFCIQ-PAQL Recommandation de plan d’assurance qualité logiciel NF ISO/CEI 9126-1 Technologies de l’information – Qualité des produits logiciels Définition caractéristiques qualité 6
  7. 7. @crochefolle Norme ISO/CEI 9126-1  La norme ISO 9126, "Technologies de l’Information : Qualités des produits logiciels", définit et décrit une série de caractéristiques qualité d’un produit logiciel (caractéristiques internes et externes, caractéristiques à l’utilisation) qui peuvent être utilisées pour spécifier les exigences fonctionnelles et non fonctionnelles des clients et des utilisateurs. Chaque caractéristique est détaillée en sous-caractéristique, et pour chacune d’elle, la norme propose une série de mesures à mettre en place pour évaluer la conformité du produit développé par rapport aux exigences formulées.  Caractéristiques  CAPACITE FONCTIONNELLE Ensemble d'attributs portant sur l'existence d'un ensemble de fonctions et leurs propriétés données. Les fonctions sont celles qui satisfont aux besoins exprimés ou implicites.  FIABILITE 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.  FACILITE D UTILISATION Ensemble d'attributs portant sur l'effort nécessaire pour l'utilisation et sur l'évaluation individuelle de cette utilisation par un ensemble défini ou implicite d'utilisateurs.  RENDEMENT 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.  MAINTENABILITE Ensemble d'attributs portant sur l'effort nécessaire pour faire des modifications données.  PORTABILITE Ensemble d'attributs portant sur l'aptitude de logiciel à être transféré d'un environnement à l'autre. 7
  8. 8. @crochefolle Norme ISO/CEI 9126-1 8
  9. 9. @crochefolle Norme NF ISO/CEI 12207 Processus du cycle de vie du logiciel 5. Processus de base 6. Processus de support 5.1 Acquisition 6.1 Documentation 5.2 Fourniture 6.2 Gestion de la configuration 5.3 Développement 5.4 Exploitation 6.3 Assurance de la qualité 6.4 Vérification 6.5 Validation 5.5 Maintenance 6.6 Revue Conjointe 6.7 Audit 6.8 Résolution de problème 7. Processus organisationnels 7.1 Management 7.2 Infrastructure 7.3 Amélioration de processus 7.4 Formation 9
  10. 10. @crochefolle Norme NF ISO/CEI 12207 Processus de support  Processus de documentation : 1. Mise en œuvre du processus de gestions des informations produites 2. Conception et développement 3. Production 4. Maintenance  Processus de gestion de configuration 1. Mise en œuvre du processus 2. Identification de la configuration 3. Maîtrise de la configuration 4. Rapport d’état de la configuration 5. Evaluation de la configuration 6. Gestion de la livraison et de distribution  Processus d’assurance qualité 1. Mise en œuvre du processus 2. Assurance du produit 3. Assurance du processus 4. Assurance des systèmes qualité  Processus de vérification 1. Mise en œuvre du processus 2. Vérification  Processus de validation 1. Mise en œuvre du processus 2. Validation  Processus de revue conjointe 1. Mise en œuvre du processus 2. Revues de gestion de projets 3. Revues techniques  Processus d’audit 1. Mise en œuvre du processus 2. Audit  Processus de résolution de problème 1. Mise en œuvre du processus 2. Résolution de problème 10
  11. 11. @crochefolle Missions  Gestion Qualité logiciel  Gestion du processus de développement  Gestion des exigences  Gestion de configuration  Gestion des tests  Gestion des anomalies  Gestion de la documentation 11
  12. 12. @crochefolle Documents de référence de la démarche qualité  Gestion Qualité du logiciel  Plan qualité logiciel  Gestion du processus de développement  Plan développement logiciel  Planning  Budget  Dossier de conception  Spécification Fonctionnelle  Spécification Technique  Gestion des exigences  Cahier des charges/exigences  Gestion de configuration  Plan de gestion de configuration  Gestion des tests  Plan de test  Gestion des anomalies  Plan de gestion des anomalies  Gestion de la documentation  Plan de gestion de la documentation 12
  13. 13. @crochefolle PLAN QUALITÉ LOGICIEL 13
  14. 14. @crochefolle Définition &Objectifs Plan Qualité « Document énonçant les modes opératoires, les ressources et la séquence des activités liées à la qualité, se rapportant à un produit, un service ou un projet particulier.» Source : Z 67-801-1:1995 Plan qualité logiciel « Document décrivant les dispositions spécifiques prises par une entreprise pour obtenir la qualité du produit ou du service considéré.» Source : Z 67-130:1987  Objectifs :  Lister les plans et procédures nécessaires aux différentes missions de l’équipe qualité : c’est le point d’entrée de la démarche qualité  Recenser l’ensembles des ressources nécessaires : humaines, matériels et logiciels  Définir les rôles et responsabilité 14
  15. 15. @crochefolle Sommaire type 1. Introduction 1. But, domaine d’application du plan qualité et responsabilité 2. Documents applicables et documents de référence 3. Terminologie 2. Description du projet 1. Présentation générale du projet, 2. Organigramme fonctionnel et technique 3. Champ d’intervention 3. Démarche de développement 1. Cycle de développement 2. Processus de développement 4. Moyens et ressources 1. Rôles et responsabilité 2. Matériel 3. Logiciel 5. Planification du projet 1. Techniques d’estimation des charges 2. Charges prévisionnelles 3. Planning prévisionnel 4. Suivi de projet 6. Description des activités 1. Gestion de documentation 2. Gestion de configuration 3. Gestion des tests 4. Gestion des anomalies 7. Suivi de projet 1. Suivi des adaptations du projet 2. Audit 3. Bilan de projet 4. Proposition d’amélioration 15 Référence : Norme Z 67-130
  16. 16. @crochefolle PROCESSUS DE DÉVELOPPEMENT 16
  17. 17. @crochefolle Introduction  Cycle de vie logiciel  Référentiel de bonnes pratiques  Méthodes de développement 17
  18. 18. @crochefolle Cycle de vie logiciel Un logiciel est un ensemble complexe et son développement nécessite une diversité d’activités. La modélisation de l’enchainement de ses activités constitue le cycle de vie du logiciel. Les différents cycles de vie répertoriés sont les suivant:  En cascade  En V  Par prototypage  Itératif  En spirale 18
  19. 19. @crochefolle Modèle en cascade Spécification du logiciel Conception préliminaire Conception détaillée Codage Tests Unitaires Intégration Validation Exploitation 19 • Dossier Spécifications • Plan Qualité Logiciel • Dossier Conception préliminaire • Dossier Conception détaillée • Programme de référence • Produit logiciel (programme et documentation) Caractéristiques principales: • chaque phase se termine par une vérification pour éliminer le plus possible d’anomalies • les retours en arrière sur les phases se limitent à un retour sur les phase immédiatement antérieure Inconvénient : • Si chaque phase n’est pas maitrisée, des erreurs en avalanche peuvent apparaître. Revue Revue Revue Audit fonctionnel et technique Recette
  20. 20. @crochefolle Modèle en V Analyse du besoin Spécification fonctionnelle Spécification Technique Codage Tests Unitaires Test d’intégration Test fonctionnel Recette Exploitation 20 Le modèle du cycle en V a été imaginé pour pallier le problème de réactivité du modèle en cascade. Ce modèle est une amélioration du modèle en cascade qui permet en cas d'anomalie, de limiter un retour aux étapes précédentes. Les phases de la partie montante, doivent renvoyer de l'information sur les phases en vis-à-vis lorsque des défauts sont détectés afin d'améliorer le logiciel. De plus le cycle en V met en évidence la nécessité d'anticiper et de préparer dans les étapes descendantes les « attendus » des futures étapes montantes : ainsi les attendus des tests de validation sont définis lors des spécifications, les attendus des tests unitaires sont définis lors de la conception, etc. Le cycle en V est devenu un standard de l'industrie du développement de logiciel et de la gestion de projet depuis les années 1980.
  21. 21. @crochefolle Modèle par prototypage 21 Concevoir prototype Implément. Installation Maintenance prototype prototype Construire TesterConcevoir prototype Concevoir prototype prototype Concevoir prototype prototype Concevoir prototype Tester prototype Concevoir prototype prototype Tester prototype Concevoir prototype prototype Tester prototype Concevoir prototype prototype Tester prototype Concevoir prototype prototype Tester prototype Concevoir prototype TesterConcevoir prototypeBesoins prototype Concevoir prototype Construire prototype Tester Conception Spécif. besoins Spécif. besoins Avantages: - Éliminer les mésententes avec les utilisateurs en montrant tôt la fonctionnalité du système. - Permet d’identifier les besoins manquants. - Permet d’identifier les problèmes reliés aux interfaces. - Permet de vérifier la faisabilité et l’utilité du système. Inconvénients: - Coût du prototype peut être non apprécié par les utilisateurs. - Le prototype peut mettre l’accent sur les interfaces et négliger la fonctionnalité du système. - Exige beaucoup l’implication de l’utilisateur.
  22. 22. @crochefolle Modèle itératif  Les avantages de cette approche itérative du développement sont :  Réduction des risques: Permet d’avoir une visibilité de ce qui est achevé à un moment précis du projet.  Augmentation de la valeur : livrer rapidement à des avantages, être en mesure de livrer le produit quand il est considéré comme assez bon, plutôt que de devoir attendre tous les éléments destinés à être livrés,  Plus de souplesse / agilité: on peut choisir de changer de direction ou d'adapter les prochaines itérations sur la base ce qui a été développé et sur l’utilisation du logiciel.  Une meilleure gestion des coûts: si, comme tous les trop nombreux projets de développement de logiciels, vous courez après le budget, une certaine économie peut-être apportée par la méthode Agile.  Pour cette approche et pour être pratique, chaque fonction/caractéristique doit être pleinement développé, dans la mesure où elle est doit être livré, avant de passer à la suite. 22
  23. 23. @crochefolle Modèle en spirale 23 Le modèle en spirale (spiral model) est un modèle de cycle de développement logiciel qui reprend les différentes étapes du cycle en V. Par l'implémentation de versions successives, le cycle recommence en proposant un produit de plus en plus complet et dur. Le cycle en spirale met cependant plus l'accent sur la gestion des risques que le cycle en V. On distingue quatre phases dans le déroulement du cycle en spirale : 1. détermination des objectifs, des alternatives et des contraintes ; 2. analyse des risques, évaluation des alternatives ; 3. développement et vérification de la solution retenue ; 4. revue des résultats et vérification du cycle suivant.
  24. 24. @crochefolle Référentiel de bonnes pratiques 1/3 A quoi sert un référentiel de bonnes pratiques en informatique  A priori, un système d'information en bonne santé peut fort bien se passer de la mise en place d'un référentiel de bonnes pratiques. Toutefois, il doit faire face à de nombreux impératifs :  satisfaire les utilisateurs,  faire la preuve de son optimisation financière,  rassurer la direction générale sur sa fiabilité et sa pérennité,  rassurer les investisseurs sur la sécurité de leurs investissements,  savoir s'organiser pour évoluer et s'adapter en permanence.  Faire appel aux bonnes pratiques est à la fois un guide méthodologique efficace et également une sorte de label que le décideur informatique pourra mettre en avant pour démontrer qu'il a pris les meilleures dispositions possibles. Protéger l'informatique s'impose désormais à la direction générale : La direction générale a désormais la responsabilité impérieuse de protéger son informatique sur 2 niveaux :  patrimonial : l'informatique est un enjeu économique fondamental, aussi bien directement (budget informatique), qu'indirectement (risque d'arrêt de la production en cas d'incident). Ces différents aspects patrimoniaux sont désormais surveillés par les investisseurs.  légal : conscient de la nécessité d'obliger l'entreprise à protéger la valeur du capital investi et à garantir la sincérité des rapports annuels, de nombreuses législations imposent désormais aux entreprises de prendre des dispositions de protection du système d'information (Sarbanes- Oxley, LSF, NRE, IAS/IFRS, Bâle II...) 24
  25. 25. @crochefolle Référentiel de bonnes pratiques 2/3 Même si chaque système a plus ou moins été étendu aux différentes facettes de l'activité informatique, chaque référentiel trouve son efficacité dans un domaine particulier. Il n'est pas donc pas trop difficile de se tourner vers celui qui sera pertinent. 25 Pour l'informatique, trois référentiels de bonnes pratiques sont actuellement à la mode :  COBIT (Control Objectives for Business & Related Technology),  ITIL (Information Technology Infrastructure Library),  CMMi (Capability Maturity Model intégration). Très complémentaires, ils ont chacun un domaine de prédilection. Outre ces trois référentiels, il en existe d'autres, plus ou moins spécifiques ou plus moins en vogue :  PMI (Project Management Institute),  Prince2 (PRojects INControlled Environments),  Spice (ISO 15504),  ISO 17799,  ISO 9000.
  26. 26. @crochefolle Référentiel de bonnes pratiques 3/3  COBIT Le COBIT (Control Objectives for Business & Related Technology), est utilisé pour la gouvernance et l'audit des systèmes d'information. Il analyse le système informatique suivant 4 domaines :  planning et organisation,  acquisition et mise en place,  fourniture du service et support,  surveillance.  ITIL ITIL (Information Technology Infrastructure Library), s'intéresse à la production, qu'il s'agisse de fourniture de services informatiques ou d'exploitation interne. C'est donc une voie pour s'assurer de la satisfaction des utilisateurs ou clients de services.  CMMi CMMi (Capability Maturity Model intégration) est le référentiel dédié au développement de systèmes et logiciels. CMMi permet d'évaluer la maturité de l'entreprise sur 5 niveaux :  initial,  reproductible,  défini,  maîtrisé,  optimisé.  Prince, Prince2 Prince (PRojects INControlled Environments) est un guide des meilleures pratiques en direction de projet, utilisé par l'administration britannique. Chaque processus est défini avec ses entrées et sorties caractéristiques ainsi qu'avec les objectifs spécifiques à remplir et les tâches à accomplir. La méthode Prince est dans le domaine public.  PMI Le PMI (Project Management Institute) a développé le standard PMBOK (Project Management Body of Knowledge, élaboré sur la base des meilleures pratiques du management de projet. Il est organisé suivant 9 domaines :  intégration du projet,  contenu du projet,  délais du projet,  communication du projet,  risques du projet  approvisionnements du projet.  Spice, ISO 15504 Spice est une norme créée par l’ISO (International Organization for Standardization) pour standardiser l'évaluation des processus logiciels (Norme ISO/CEI 15504). Spice est moins une méthodologie de travail qu’un outil d'évaluation du niveau de maîtrise du processus de conduite du projet.  ISO 9000 Les certifications de la famille ISO 9000 constituent désormais un ensemble de références de qualité incontestées sur le plan mondial. Très généralistes, ces spécifications ne sont pas forcément les plus productives pour l'informatique.  ISO 17799 Catalogue de bonnes pratiques assurant un client que ses informations sont gérées de manière sécurisée par son fournisseur. Elle est présentée dans cette liste comme complément de réponse aux obligations de sécurité des systèmes d'information. 26
  27. 27. @crochefolle CMM (CAPABILITY MATURITY MODEL), CMMI (CAPABILITY MATURITY MODEL INTEGRATION) La famille CMM est un ensemble de normes américaines du SEI (Software Engineering Institute) définissant le niveau de qualité des pratiques de développement logiciel. Le modèle CMMI définit une échelle de mesure de la maturité à 5 niveaux, ainsi que les indicateurs nécessaires pour évaluer les activités menées par une équipe par rapport à cette échelle - l'équipe peut être un groupe de travail, un ou plusieurs projets, une société voire une institution d'Etat. Le modèle CMMI est majoritairement utilisé dans des sociétés d'informatique, toutefois les principes de CMMI s'appliquent à n'importe quelle activité d'ingénierie : architecture, mécanique, électronique,... La notion introduite est celle de maturité.  D'après la définition donnée dans le CMMI, la maturité d'une organisation est le degré auquel celle-ci a déployé explicitement et de façon cohérente des processus qui sont documentés, gérés, mesurés, contrôlés et continuellement améliorés.  Un niveau de maturité (Maturity Level) correspond à l'atteinte d'un niveau de capabilité uniforme pour un groupe de processus. Un niveau de capabilité (Capability Level) mesure l'atteinte des objectifs d'un processus pour le niveau donné. 27
  28. 28. @crochefolle CMMi – les niveaux Les bonnes pratiques préconisées par le modèle (version 1.2) sont rassemblées en 22 domaines de processus eux- mêmes regroupés en 5 niveaux de maturité. Les domaines de processus rattachés à un niveau de maturité M ne peuvent être stabilisés et efficaces que si les domaines de processus des niveaux inférieurs ( < M ) sont déjà stabilisés et efficaces (principe d'empilement). Les 5 niveaux sont :  Initial (niveau de maturité 1) : Il n'y a pas de grand pilier directionnel, aucune façon de faire ou standard ne sont établis (ou bien ils sont documentés mais ne sont pas utilisés), tout doit être fait. Il n'y a pas de surveillance (monitoring), aucune évaluation de performance et la communication est absente. Les faiblesses ne sont pas identifiées et les employés ne sont pas au courant de leurs responsabilités de façon définie et absolue. Les réactions aux incidents se font en mode urgence, sans identification claire des priorités. À ce niveau les solutions ainsi que les projets sont décidés, développés et instaurés par un individu. Les compétences et les ressources propres de cet individu sont la raison du succès ou de l'échec du projet (par dérision, ce niveau est aussi nommé héroïque ou chaotique). Il n'y a pas de description du niveau de maturité 1 dans le modèle.  « managed », soit discipliné en français (niveau de maturité 2) : Une discipline est établie pour chaque projet et se matérialise essentiellement par des plans de projet (plan de développement, d'assurance qualité, de gestion de configuration ...). Le chef de projet a une forte responsabilité dans le niveau 2 : il doit définir, documenter, appliquer et maintenir à jour ses plans. D'un projet à l'autre, il capitalise et améliore ses pratiques de gestion de projet et d'ingénierie.  « Defined », soit ajusté en français (niveau de maturité 3) : Ce niveau est caractérisé par une standardisation adéquate des pratiques, une capitalisation centralisée (en particulier sur les mesures réalisées dans les projets) et une maîtrise du référentiel interne (ou Système Qualité). Il existe des lignes directrices, un plan stratégique et une planification de l'amélioration de processus pour le futur, en ligne avec les objectifs d'affaire de l'organisation. Les employés sont formés et conscients de leurs responsabilités ainsi que de leurs devoirs.  « Quantitatively managed », soit géré quantitativement en français (niveau de maturité 4) : Les projets sont pilotés sur la base d'objectifs quantitatifs de qualité produit et processus. La capacité des activités (ou sous-processus) critiques est déterminée par l'organisation, ainsi que les modèles de performance et de prévision associés. L'expression de la qualité demandée par le client est prise en compte pour quantifier les objectifs du projet et établir des plans selon la capacité des processus de l'organisation.  « Optimizing », soit en optimisation en français (niveau de maturité 5) en français : Les processus qui sont gérés quantitativement pour le pilotage de projet (niveau de maturité 4) sont en optimisation constante afin d'anticiper les évolutions prévues (besoins clients, nouvelles technologies...). 28
  29. 29. @crochefolle CMMi – Niveau 2  Pour le niveau 2, les activités et produits (techniques et de gestion, intermédiaires et finaux) sont maîtrisés par le projet. Les processus projet sont disciplinés, ce qui se caractérise par :  les activités sont planifiées et exécutées conformément à une politique (ou directive) d'organisation,  les rôles, responsabilités et acteurs sont définis et connus,  les acteurs disposent des compétences et des ressources adéquates pour réaliser les produits,  les produits sont contrôlés,  la mise en œuvre du processus fait l'objet d'un suivi, de vérifications et d'ajustement si nécessaire.  Le niveau 2 se compose de sept domaines de processus traitant de :  la gestion des exigences,  la planification de projet,  le suivi de projet,  la gestion des fournisseurs,  l'utilisation des métriques,  l'assurance qualité  et la gestion de configuration.  Chacun de ces sept domaines de processus contribue à donner à l'organisation une bonne visibilité sur ses développements : visibilité sur le contenu, les coûts, les délais, la qualité des produits développés et des processus utilisés. Typiquement, les membres d'une équipe de développement, comme le management, connaissent l'état d'avancement de leur projet et des évolutions en cours, ainsi que ce qu'il reste à faire. 29
  30. 30. @crochefolle SPICE (Software Process Improvement and Capability dEtermination) SPICE est une norme créée par l’ISO (International Organization for Standardization) pour standardiser l'évaluation des processus logiciels (Norme ISO/CEI 15504). SPICE est cohérent avec CMMi, mais aussi ISO 9000 et ISO 12207. C’est moins une méthodologie de travail qu’un outil d'évaluation de la maîtrise de conduite du projet. C'est un référentiel des pratiques clés destiné à tout projet de développement ou de maintenance du logiciel. Il établit deux grands axes d’étude :  le processus évalué sur 5 thèmes : 1. relations client-fournisseur relations avec le client, 2. ingénierie développement du logiciel, 3. support interface avec les autres processus, 4. gestion administration du développement, 5. organisation environnement d'exploitation.  la maturité, évaluée en cinq niveaux : 0. incomplet, le processus n'est pas réalisé, ou bien il n'atteint son objectif que partiellement ou bien le résultat n’est pas facilement identifiable. Répétabilité des processus, 1. effectué, les objectifs du processus sont atteints, les pratiques de base sont employées, les produits en fournissent la preuve. Le processus est géré au niveau de l'individu. Pertinence par rapport aux objectifs de l'entreprise. 2. géré, les produits sont vérifiés et conformes aux standards. La planification s'effectue au niveau projet et est respectée, aussi bien au niveau du processus lui-même que des produits issus du processus, 3. établi, les activités s'effectuent suivant un processus standard défini au niveau de l'organisation. Le processus est basé sur des pratiques documentées standards adaptées aux besoins de chacun. Comparaison face à un référentiel., 4 prévisible, le déroulement du processus et de la qualité des produits sont quantifiés et les performances sont prévisibles. Obtention d’un niveau de qualité prédéfini, 5 optimisé, l'organisation est capable d'améliorer de façon continue ses processus pour les adapter suivant les objectifs. Soutien de l’amélioration de la productivité.  Il se décrit en neuf documents : 1. les concepts fondamentaux, 2. l'ingénierie des processus, 3. l'évaluation du niveau d'aptitude, 4. la conduite de l'évaluation, 5. les outils, le guide des indicateurs d’évaluation, 6. la qualification des évaluateurs, 7. l'amélioration des processus, 8. les aptitudes des fournisseurs, 9. la terminologie (référentiel). 30
  31. 31. @crochefolle Les méthodes Agile 1/3 Valeurs Elles prônent 4 valeurs fondamentales (entre parenthèse, les citations du manifeste) :  L'équipe (« Personnes et interaction plutôt que processus et outils ») : Dans l'optique agile, l'équipe est bien plus importante que les moyens matériels ou les procédures. Il est préférable d'avoir une équipe soudée et qui communique composée de développeurs moyens plutôt qu'une équipe composée d'individualistes, même brillants. La communication est une notion fondamentale.  L'application (« Logiciel fonctionnel plutôt que documentation complète ») : Il est vital que l'application fonctionne. Le reste, et notamment la documentation technique, est secondaire, même si une documentation succincte et précise est utile comme moyen de communication. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n'est pas à jour. Il est préférable de commenter abondamment le code lui-même, et surtout de transférer les compétences au sein de l'équipe (on en revient à l'importance de la communication).  La collaboration (« Collaboration avec le client plutôt que négociation de contrat ») : Le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l'équipe et fournir un feed-back continu sur l'adaptation du logiciel à ses attentes.  L'acceptation du changement (« Réagir au changement plutôt que suivre un plan ») : La planification initiale et la structure du logiciel doivent être flexibles afin de permettre l'évolution de la demande du client tout au long du projet. Les premières releases du logiciel vont souvent provoquer des demandes d'évolution. Principes Ces 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes agiles :  « Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles ».  « Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client ».  « Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte ».  « Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet ».  « Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail ».  « La méthode la plus efficace pour transmettre l'information est une conversation en face à face ».  « Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet ».  « Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment ».  « Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité ».  « La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle ».  « Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent ».  « À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens ». 31 Les méthodes Agiles sont des procédures de conception de logiciel qui se veulent plus pragmatiques que les méthodes traditionnelles. En impliquant au maximum le demandeur (client), ces méthodes permettent une grande réactivité à ses demandes, visent la satisfaction réelle du besoin du client, et non des termes du contrat de développement. La notion de méthode agile a été officialisée en 2001 par un document Manifeste Agile (Agile Manifesto) signé par 17 personnalités impliquées dans l'évolution du génie logiciel et généralement auteurs de leur propre méthode.
  32. 32. @crochefolle Les méthodes Agile 2/3 Tronc des pratiques communes à l'ensemble des méthodes Agiles  Les pratiques communes liées aux ressources humaines  Participation de l’utilisateur final aux groupes de travail.  Groupes de travail disposant du pouvoir de décision.  Autonomie et organisation centralisée de l’équipe (motivation).  Spécification et validation permanente des Exigences.  Les pratiques communes liées au pilotage du projet  Niveau méthodologique variable en fonction des enjeux du projet.  Pilotage par les enjeux et les risques.  Planification stratégique globale basée sur des itérations rapides.  Réalisation en jalons par prototypage actif itératif et incrémental.  Recherche continue d’amélioration des pratiques.  Les pratiques communes liées à la qualité de la production  Recherche d’excellence technique de la conception.  Vision graphique d’une modélisation nécessaire et suffisante.  Vision de la documentation nécessaire et suffisante.  Normes et techniques raisonnables de qualité du code (métrique).  Architecture à base de composants.  Gestion des changements automatisée. Méthodes Agiles publiées  Rapid Application Development (RAD)  Dynamic systems development method (DSDM)  Extreme programming (XP)  Adaptive software development (ASD)  Feature Driven Development(FDD)  Scrum  Crystal clear  Processus Urbanisant les Méthodes Agiles (PUMA) 32
  33. 33. @crochefolle Les méthodes Agile 3/3 Seules quelques techniques complémentaires entre elles, ou mieux adaptées à des typologies et à des tailles de projets spécifiques, différencient les méthodes Agiles (y compris ASD ou Crystal Clear).  La méthode DSDM se particularise par la spécialisation des acteurs du projet dans une notion de « rôles ». Ainsi, l'on trouvera dans les réunions DSDM des sponsors exécutifs, des ambassadeurs, des utilisateurs visionnaires, des utilisateurs conseillers, sans oublier l'animateur-facilitateur et des rapporteurs.  La méthode Scrum affirme sa différence dans des pratiques de courtes réunions quotidiennes (Stand-Up meeting). Ces temps de travail commun ont pour objectifs d'améliorer la motivation des participants, de synchroniser les tâches, de débloquer les situations difficiles et d'accroître le partage de la connaissance.  Pour FDD, la particularité nommée Mission focused réside dans une forte orientation vers un but immédiat mesurable guidé par la notion de valeur métier. C'est en fait l'ambition globale d'une itération qui se trouve ainsi renforcée. Cet aspect se retrouve aussi dans la méthode RAD sous la forme des objectifs de Focus ou dans Scrum dans la notion de Sprint. FDD préconise aussi le Features Driven Development. Cette technique se caractérise par des notions de Feature et de Features set (fonctionnalités et groupes de fonctionnalités). La priorité est donnée aux fonctionnalités porteuses de valeur. Le RAD propose des techniques proches : livraison en fonctionnalité réduite ou livraison par thèmes.  XP (extreme programming) est très axé sur la partie Construction de l'application. Une de ses originalités réside dans l’approche de planification qui se matérialise sous la forme d’un jeu intitulé Planning game et qui implique simultanément les utilisateurs et les développeurs. On notera aussi des techniques particulières liées à la production du code comme la programmation en binôme (Pair programming), l'appropriation collective du code, la Refactorisation (refactoring) et l' Intégration continue. La méthode RAD préconise dans ce sens des revues de code personnelles, puis collectives et l'intégration avant chaque Focus (ou Show). Par contre, le RAD limite la programmation en binôme aux parties les plus stratégiques.  2TUP (2 track unified process, prononcez "toutiyoupi") préconise un cycle de vie en Y qui dissocie la résolution des questions fonctionnelles et techniques. Le cycle de vie de 2TUP s'apparente à un cycle de développement en cascade mais introduit une forme itérative interne à certaines tâches. Il n'est pas certain que ce cycle s'apparente réellement à une approche Agile. Par contre, 2TUP préconise des formes de recherche de qualité et de performance intéressantes telles que les services réutilisables et la conception générique (Framework et Patron de conception Design pattern) proches des mécanismes architecturaux de RUP.  UP se caractérise par une approche globale nommée « Vue 4+1 ». Les 5 composants de cette vue sont : la vue des Cas d'utilisation, la vue Logique, la vue d'Implémentation, la vue du Processus, la vue du Déploiement. RUP offre aussi, à l'identique du RAD 2, un Processus guide formel et adaptable comme guide d'activité. Dans le cas de RUP, il est malheureusement propriétaire et orienté outil. 33
  34. 34. @crochefolle Et alors?  Des cycles de vies,  Des référentiels de bonnes pratiques,  Des méthodes de développement 34 Règles d’or :  Ne pas appliquer une norme, un modèle pour lui-même ou pour une certification, mais se poser la question à chaque étape : « Qu’est-ce que cela va m’apporter ? »  Mieux vaux un modèle imparfait appliqué par tous et qu’on améliore progressivement qu’un modèle parfait jamais appliqué.
  35. 35. @crochefolle GESTION DES EXIGENCES 35
  36. 36. @crochefolle Définitions  La gestion des exigences consiste à gérer les exigences hiérarchisées d'un projet, à détecter les incohérences entre elles et à assurer leur traçabilité.  Dans l'ingénierie logiciel, une exigence peut être la description de ce qu'un logiciel doit faire. Ce type d'exigence spécifie quelque chose que le logiciel livré doit être capable de faire. Un autre type d'exigence spécifie quelque chose sur le logiciel lui-même, et de quelle manière il exécute ses fonctions. De telles exigences s'appellent souvent «exigences non fonctionnelles», «exigences de performance» ou «qualité des exigences de service». Exemples de ce type d'exigences : la disponibilité, la testabilité, la facilité de maintenance et la facilité d'utilisation.  Un ensemble d'exigences définit les caractéristiques ou propriétés du logiciel désiré (exigé). Une «bonne» liste d'exigences évite de spécifier la manière pour le logiciel de mettre en œuvre ces exigences, laissant ce genre de décision pour les activités de conception. Un élément parmi les exigences qui décrit comment mettre en œuvre le logiciel s'appelle un biais de mise en œuvre.  Le CMMi décrit les activités liées à la gestion des exigences dans la conception logicielle :  Comprendre et intégrer les exigences au projet  Valider les exigences  Gérer le changement d'exigences  Maintenir la traçabilité des exigences 36
  37. 37. @crochefolle Comprendre et intégrer les exigences au projet Les parties prenantes du projet expriment des besoins, qui sont formulés sous forme d'exigences. Les responsables du projet, après avoir compris les exigences et en avoir vérifié la cohérence, les intègrent au projet.  Cela peut impliquer :  De maintenir une liste des acteurs habilités à exprimer les exigences.  De maintenir des critères pour accepter ou non les exigences.  D'analyser des exigences vis à vis des critères.  De formaliser l'acceptation d'une exigence.  Gérer les incohérences entre le projet et les exigences. 37
  38. 38. @crochefolle Valider les exigences Pour garantir l'engagement des parties prenantes du projet, en ce qui concerne les impacts sur le projet d'une nouvelle exigence ou d'un changement, on évalue les conséquences sur le projet et on demande validation de l'exigence par les parties. Cette activité peut donner lieu à :  Une analyse d'impact d'une exigence ou d'un changement d'exigence  Un document formalisant l'engagement des parties sur les exigences et leurs impacts. 38
  39. 39. @crochefolle Gérer le changement Au cours d'un projet les exigences évoluent pour diverses raisons. Il est important de gérer efficacement les changements et les ajouts. Pour pouvoir évaluer correctement les impacts il est important que l'origine et la justification de tous les changements soient documentées. On peut en outre vouloir mesurer la volatilité des changements. Cela peut impliquer de produire :  Un état des exigences  Une base de données des exigences  Une base de données des décisions concernant les exigences. 39
  40. 40. @crochefolle Maintenir la traçabilité des exigences La traçabilité est la possibilité de lire facilement ce qu'il est advenu et ce qu'il est censé advenir de quelque chose. La traçabilité des exigences est le fait de pouvoir à tout instant connaitre facilement l'origine et les liens entre les exigences, ainsi qu'entre les exigences et le reste du projet ou le contexte (notamment les besoins utilisateur, réalisation et tests). Elle aide à répondre aux questions du type :  D'où vient une exigence ? (Quel besoin cette exigence couvre-t-elle ? Pourquoi a-t-on conçu la solution de cette manière et quelles étaient les autres possibilités ?)  Cette exigence est-elle nécessaire ?  Où met-on en œuvre cette exigence ?  Comment interpréter cette exigence ?  Quelle décision de conception affecte la mise en œuvre de l'exigence ?  Cet élément de conception est-il nécessaire ?  La solution réalisée est-elle conforme aux exigences ?  Comment testera-on cette exigence ?  Toutes les exigences sont-elles prises en compte ?  Est-ce que le projet est terminé ?  Quel est l'impact du changement d'une exigence ? 40
  41. 41. @crochefolle GESTION DE CONFIGURATION 41
  42. 42. @crochefolle Définitions  Les activités de gestion de configuration permettent de contrôler les évolutions durant le cycle de vie du logiciel, d’archiver chacun des états successifs et de vérifier que chacun de ces états est complet et cohérent.  On rassemble sous la dénomination « gestion de la configuration » l’ensemble des règles et des moyens destinés à gérer la cohérence des différents logiciels, sous-ensembles logiciels, modules, composants et documents.  D’après la norme NF Z 61-102, la gestion de configuration correspond à l’ensemble des activités (manuelles ou automatisées) qui permettent d’identifier et de définir les éléments de configuration et toutes leurs relations.  La gestion de configuration correspond à un problème de fond: connaître ,à tout moment, certaines informations liées à un système installé sur un site donné, par exemple:  Les matériels installés (y compris les périphériques et les cartes montées),  Les programmes d’application avec leur version  Les outils de conception et de développement utilisés,  Les logiciels de tests utilisés,  Les logiciels d’exploitation et les logiciels de base avec leur version,  Les interfaces,  Les logiciels associés,  La documentation technique et la documentation d’utilisation correspondantes,  L’état des dernières corrections,  L’état des dernières demandes d’évolution,  La liste des utilisateurs,  … 42
  43. 43. @crochefolle Plan de gestion de configuration 1. Introduction  Objectifs  Domaine couvert  Relations avec les matériels associés  Relations avec les documents associés 2. Organisation de la gestion de configuration (GC)  Relations entre la GC et les services concernés  Autorisations d’accès  Autorisations de modifications  Rappel des responsabilités des intervenants  Rôle des responsables de la GC  Principes  Méthodes  Procédures appliquées 3. Activités de la gestion de configuration  Définition et identification des éléments  Contrôle des éléments au fur et à mesure des évolutions  Suivi des demandes d’évolution  Mise sous GC aux points d’arrêts prévus  Contrôle des interfaces  Suivi des différentes versions du produit au cours de l’avancement 4. Vérifications de l’état du produit  Contrôle par rapport aux spécifications  Définition de la version de référence lors des livraisons successives 5. Planning de la gestion de configuration  Relation avec le plan de développement 6. Définition de la configuration  Définition du matériel utilisé  Définition du logiciel utilisé  Définition du personnel responsable des actions  Définition de la formation nécessaire  Définition des informations en entrée  Définition des informations en sortie  Définition de l’archivage 7. Maintenance de la gestion de configuration  Plan définissant les activités et responsables de la GC pendant toute la durée de vie 43
  44. 44. @crochefolle Composants  Les élément de configuration d’un logiciel vont comprendre:  Les documents de conception  Les documents de réalisation  Les documents d’utilisation  Les documents d’exploitation  Les programmes  Les données des tables et paramètres  Les procédures  L’environnement de développement (tous les produits matériels et logiciels utilisés pour la réalisation, la vérification et la modification du logiciel)  L’environnement de recette (tous les produits logiciels utilisés pour les tests)  Les jeux d’essais (données, procédure et scénarii de test)  Les éléments à gérer sont au minimum :  Le dossier de spécification du logiciel  Le dossier de conception préliminaire  Les programmes en langage source et les moyens permettant de reproduire ces mêmes programmes en langage machine  Les manuels d’utilisation  Les manuels d’exploitation 44
  45. 45. @crochefolle Gestion de version vs configuration  La différence essentielle entre un logiciel de gestion de version et un logiciel de gestion de configuration est que ce dernier propose des outils permettant :  de gérer les demandes de modification du système à faire évoluer  de mettre en correspondance les demandes de modifications avec les changements apportés au système.  PVCS parle de tâche, Perforce de jobs pour désigner ces demandes de modifications. Autant CVS, SVN, SourceSafe et consorts ne sont que des gestionnaires de versions (CVS signifie « Concurrent Versionning System » !) tandis que les premiers sont des gestionnaires de configuration.  Au début du projet, les tâches sont les spécifications du projet, puis on trouvera les demandes de corrections ou d’évolutions.  Grâce à cette association, l’entropie du système reste sous contrôle, la matrice de conformité est alors automatiquement renseignée, le reste-à-passer global est connu à chaque instant. 45
  46. 46. @crochefolle Etapes du processus de compilation et assemblage  Compilation  Génération des librairies, exécutables, application web Tests Unitaires  Documentation du code (Javadoc,...)  Mesure qualité (complexité cyclomatique, nb lignes de code)  Vérification des règles de codage  Génération documentation utilisateur  Tests fonctionnels/intégration  Déploiement en espace de tests, pré-production, production 46
  47. 47. @crochefolle Intégration continue Pour appliquer cette technique, il faut d'abord que :  le code source soit partagé ;  les développeurs intègrent (commit) quotidiennement (au moins) leurs modifications ;  des tests d'intégration soient développés pour valider l'application  un outil d'intégration continue  Les principaux avantages d'une telle technique sont :  les problèmes d'intégration sont détectés et réparés de façon continue, évitant les problèmes de dernière minute ;  prévient rapidement en cas de code incompatible ou manquant ;  test immédiat des unités modifiées ;  une version est toujours disponible pour test, démonstration ou distribution.  Les pratiques sont les suivantes :  maintenir un dépôt unique de code source versionné ;  automatiser les compilations ;  rendre les compilations auto-testantes ;  tout le monde committe tous les jours ;  tout commit doit compiler le tronc sur une machine d'intégration ;  maintenir une compilation courte ;  tester dans un environnement de production cloné ;  rendre disponible facilement le dernier exécutable ;  tout le monde doit voir ce qui se passe ;  automatiser le déploiement. 47 L'intégration continue est un ensemble de pratiques utilisées en génie logiciel. Elles consistent à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression de l'application en cours de développement. Bien que le concept existait auparavant, l'"intégration continue" se réfère généralement à la pratique XP : « Daily build, nightly test »
  48. 48. @crochefolle  Séparation des espaces  Développement  Build  Test  (Pré-production)  Production  Un système de GC unique pour un projet, voire pour l’entreprise  Un système de build commun au projet (voire à l’entreprise) intégrant les tests (au minimum les tests unitaires) 48 Règles d’or
  49. 49. @crochefolle GESTION DES TESTS 49
  50. 50. @crochefolle Définitions  Un test est un ensemble de cas à tester (état de l'objet à tester avant exécution du test, actions ou données en entrée, valeurs ou observations attendues, et état de l'objet après exécution), éventuellement accompagné d'une procédure d'exécution (séquence d'actions à exécuter). Il est lié à un objectif.  La définition d'un test revient donc à définir cet ensemble. Différents types de test permettent de détecter différents types de défaut.  Un test vise à mettre en évidence des défauts de l'objet testé. Cependant il n'a pas pour objectif :  de diagnostiquer la cause des erreurs,  de les corriger,  de prouver la correction de l'objet testé.  La définition d'un cas à tester précise les exigences s'appliquant à une spécification. Un objet ne peut être testé que si on peut déterminer précisément le comportement attendu en fonction des conditions auxquelles il est soumis. Si la spécification ne permet pas cette détermination, la propriété du logiciel qu'elle définit ne peut être testée.  Soumettre la spécification à cette contrainte de « testabilité » permet d'en améliorer la précision puisqu'elle oblige à expliciter les caractéristiques de l'objet. Ceci permet, en retour, de trouver plutôt les erreurs de spécification (incohérence, etc). Cette contrainte est renforcée par certaines méthodes de développement comme le Test-Driven Development.  L'activité de test d'un logiciel utilise différents types et techniques de test pour vérifier que le logiciel est conforme à son cahier des charges (vérification du produit) et aux attentes du client (validation du produit). Elle est un des processus du développement de logiciel.  Vérification: Est-ce que nous livrons un logiciel correct, c-à-d conforme aux spécifications.  Validation: Est-ce que nous livrons le logiciel attendue, c-à-d conforme aux attentes du client. 50
  51. 51. @crochefolle Définitions complémentaires  Campagne de Test Activité qui consiste à dérouler un ensemble de scénarios de test. Un dossier de test est produit à l'issue d'une campagne de tests.  Cas de test (exigence) " Point " particulier des spécifications du logiciel nécessitant un test (règle de traitement, de calcul, de gestion, …)  Dossier de Test Ensemble documentaire qui contient la description des scénarios, des jeux de test et leurs exécutions, des anomalies et leur suivi. Le dossier de test est le reflet d'une campagne de tests.  Jeux de Test Ensemble de cas de test permettant de vérifier un produit logiciel. L'enchaînement des jeux de test est relatif à une stratégie de test précisée dans le plan de test et les spécifications.  Plan de Test Document décrivant la démarche générale de test associée au développement d'un logiciel : la stratégie de test, le périmètre (la couverture), les critères d'arrêt, les moyens à mettre en œuvre, la planification. Sa rédaction intervient durant la phase de définition du projet, il est ensuite mis à jour au cours de l'évolution du projet et du développement du produit logiciel.  Rapport de Test Partie du Dossier de Test rapportant le résultat et l'analyse du passage de chaque jeu de test plan de test et les spécifications.  Scénarios de Test Ensemble des jeux de test cohérents permettant de vérifier un objectif particulier (fonctionnel, performance, etc.). 51
  52. 52. @crochefolle Typologie des tests  Test unitaire  Test fonctionnel  Test d'intégration  Test de performance  Test de charge  Test de vulnérabilité/sécurité  Test d'acceptation/Recette  Test de non-régression 52
  53. 53. @crochefolle Test unitaire  le test unitaire est un procédé permettant de s'assurer du fonctionnement correct d'une partie déterminée d'un logiciel ou d'une portion d'un programme (appelée « unité »).  Il s'agit pour le programmeur de tester un module, indépendamment du reste du programme, ceci afin de s'assurer qu'il répond aux spécifications fonctionnelles et qu'il fonctionne correctement en toutes circonstances. Cette vérification est considérée comme essentielle, en particulier dans les applications critiques. Elle s'accompagne couramment d'une vérification de la couverture de code, qui consiste à s'assurer que le test conduit à exécuter l'ensemble (ou une fraction déterminée) des instructions présentes dans le code à tester.  L'ensemble des tests unitaires doit être rejoué après une modification du code afin de vérifier qu'il n'y a pas de régressions (l'apparition de nouveaux dysfonctionnements).  Dans les applications non critiques, l'écriture des tests unitaires a longtemps été considérée comme une tâche secondaire. Cependant, la méthode Extreme programming (XP) a remis les tests unitaires, appelés « tests du programmeur », au centre de l'activité de programmation.  La méthode XP préconise d'écrire les tests en même temps, ou même avant la fonction à tester (Test Driven Development). Ceci permet de définir précisément l'interface du module à développer. En cas de découverte d'un bogue, on écrit la procédure de test qui reproduit le bogue. Après correction on relance le test, qui ne doit indiquer aucune erreur. 53
  54. 54. @crochefolle Test d’intégration Un test d'intégration est un test qui se déroule dans une phase d'un projet informatique suivant les tests unitaires. Il consiste, une fois que les développeurs ont chacun validé leurs développements ou leurs correctifs, à regrouper leurs modifications ensemble dans le cadre d'une livraison.  Pour  Valider le fait que toutes les parties développées indépendamment fonctionnent bien ensemble de façon cohérente.  Résultat  Mise en évidence des problèmes d’interfaces entre composants  Comment ?  Vérifier pour chaque intégration que les résultats sont conformes au document de conception détaillée  Tester tous les appels entre composants 54
  55. 55. @crochefolle Test fonctionnel  Le test fonctionnel est le processus qui vise à trouver des erreurs dans le comportement d'un logiciel ou d'un composant logiciel. On attend de ce type de test qu'il montre non seulement qu'un logiciel fait ce qu'on attend de lui, mais aussi qu'il ne fait pas ce qu'on en n'attend pas..  En soit, le test fonctionnel pourrait être simple: il suffirait de tester exhaustivement tous les comportements d'un programme et de vérifier que chaque comportement satisfait la spécification. Malheureusement, procéder à un test exhaustif est généralement hors de question: le nombre de cas est souvent trop grand, voire infini, pour qu'on puisse tous les tester dans un temps raisonnable. Le problème du test est donc un problème d'échantillonnage ou de couverture: il faut sélectionner parmi les comportements possibles ceux qui assurent une meilleure couverture du programme, c'est à dire qui sont représentatifs du comportement général du programme, sans oublier les cas particuliers (les tests aux bornes), susceptibles de révéler des erreurs. La qualité d'un ensemble de tests se mesure donc à la qualité de la couverture qu'il offre.  Pour  Vérifier la conformité de l'application développée avec les spécifications  Comment ?  En se fondant sur les spécifications fonctionnelles  Scénarios, décomposition fonctionnelle 55
  56. 56. @crochefolle Test de performance/ charge  Test de Charge : il s'agit d'un test au cours duquel on va simuler un nombre d'utilisateurs prédéfinis, afin de valider l'application pour une charge attendue d'utilisateurs. Ce type de test permet de mettre en évidence les points sensibles et critiques de l’architecture technique. Il permet en outre de mesurer le dimensionnement des serveurs, de la bande passante nécessaire sur le réseau, etc.  Test de Performance : proche du Test de Charge, il s'agit d'un test au cours duquel on va mesurer les performances de l'application soumise à une charge d'utilisateurs. Les informations recueillies concernent les temps de réponse utilisateurs, les temps de réponse réseau et les temps de traitement d’une requête sur le(s) serveur(s). La nuance avec le type précédent réside dans le fait qu'on ne cherche pas ici à valider les performances pour la charge attendue en production, mais plutôt vérifier les performances à différents niveaux de charge d'utilisateurs.  Test de stress : il s'agit d'un test au cours duquel on va simuler l'activité maximale attendue tous scénarios fonctionnels confondus en heures de pointe de l'application, pour voir comment le système réagit au maximum de l'activité attendue des utilisateurs. La durée du palier en pleine charge, en général de 2 heures, doit tenir compte du remplissage des différents caches applicatifs et clients, ainsi que de la stabilisation de la plateforme de test suite à l'éventuel effet de pic-rebond consécutif à la montée en charge. Dans le cadre de ces tests, il est possible de pousser le stress jusqu'à simuler des défaillances systèmes ou applicatives afin d'effectuer des tests de récupération sur incident (Fail-over) ou pour vérifier le niveau de service en cas de défaillance.  Test de Robustesse, d'endurance, de fiabilité: il s'agit de tests au cours duquel on va simuler une charge importante d'utilisateurs sur une durée relativement longue, pour voir si le système testé est capable de supporter une activité intense sur une longue période sans dégradations des performances et des ressources applicatives ou système. Le résultat est satisfaisant lorsque l'application a supporté une charge supérieure à la moitié de la capacité maximale du système, ou lorsque l'application a supporté l'activité d'une journée ou plusieurs jours/mois/années, pendant 8 à 10 heures, sans dégradation de performance (temps, erreurs), ni perte de ressources systèmes.  Test de capacité, Test de montée en charge : il s'agit d'un test au cours duquel on va simuler un nombre d'utilisateurs sans cesse croissant de manière à déterminer quelle charge limite le système est capable de supporter. Éventuellement, des paramétrages peuvent être effectués, dans la même logique que lors des tests de dégradation, l'objectif du test étant néanmoins ici de déterminer la capacité maximale de l'ensemble système- applicatif dans une optique prévisionnelle  Test aux limites : il s'agit d'un test au cours duquel on va simuler en général une activité bien supérieure à l'activité normale, pour voir comment le système réagit aux limites du modèle d'usage de l'application. Proche du test de capacité, il ne recouvre pas seulement l'augmentation d'un nombre d'utilisateurs simultanés qui se limite ici à un pourcentage en principe prédéfini, mais aussi les possibilités d'augmentation du nombre de processus métier réalisés dans une plage de temps ou en simultané, en jouant sur les cadences d'exécutions, les temps d'attente, mais aussi les configurations de la plateforme de test dans le cadre d'architectures redondées (Crash Tests). 56
  57. 57. @crochefolle Test de vulnérabilité/sécurité  Il s'agit avant tout d'effectuer un diagnostic des failles du système d'information. Pour cela, tous les éléments de l'architecture en place sont concernés, que ce soient les éléments réseau (routeurs, pare-feu), les services applicatifs (services Web, serveurs de messagerie) ou les applications elles-mêmes. Le spectre peut parfois être encore plus large et concerner par exemple les PABX installés dans l'entreprise.  Les tests de vulnérabilité se contentent de détecter les failles d'un système sans toutefois les exploiter. Un test d'intrusion consistera à identifier une faille et à s'y introduire, dans une démarche de démonstration de ladite faille, et de mesurer les conséquences qu'elle peut engendrer.  Les tests de vulnérabilité sont en principe effectués de manière automatique et périodique par une solution logicielle dont l'objectif est de scanner l'intégralité du système à la recherche de nouvelles failles. On peut programmer cette recherche aussi souvent que souhaité (une fois par jour, par semaine, par mois, par an...). Bien entendu, les analyses peuvent se faire manuellement, par des ingénieurs sécurité, mais ces derniers utiliseront de toutes les façons des solutions spécialisées - soit développées en interne, soit achetées. La différence se situe donc dans la présence ou non d'un être humain derrière le processus de recherche de failles. 57
  58. 58. @crochefolle Test d’acceptation / Recette  Servent à la réception du logiciel par le client  Basés sur :  Des tests fonctionnels : «business»  Des tests non-fonctionnels : robustesse, rapidité, etc.  Fondés sur les critères d’acceptation définis dans le cahier des charges 58
  59. 59. @crochefolle Test de non-regression  Test de régression : tests d’un programme préalablement testé, après une modification, pour s’assurer que des défauts n’ont pas été introduits ou découverts dans des parties non modifiées du logiciel, comme suites des modifications effectuées.  Ces tests sont effectués quand le logiciel ou son environnement est modifié.  L'intérêt principal de ces tests est de limiter les anomalies relevées lors de la recette de l'application. Ils viennent compléter les tests unitaires et les tests d'intégration en amont des tests de recette.  Pour  Vérifier que le logiciel n’a pas été dégradé lors d’une modification (correction d’une anomalie par exemple)  Comment ?  En rejouant les scénarios de tests déjà passés et dont les résultats étaient ceux attendus 59
  60. 60. @crochefolle Référentiel de test Un référentiel de tests doit pouvoir :  Gérer les exigences de tests :  Aide à la création  Multi-utilisateurs : Partage aisé entre tous les acteurs du projet  Modification aisé  Lien facile entre exigences > Fiches de tests > Anomalies  Génération d’une matrice de couverture exigences ==> campagne / scénarios  Analyse du taux de couverture  Impression facile des listes  Gestion des versions des exigences  Gérer les fiches et cas de tests :  Aide à la création  Modification aisé  Possibilité de joindre des documents  Multi-utilisateurs  Gestion des versions  Gérer les cahiers / dossiers / plan de tests :  Aide à la création des scénarios  Multi-utilisateurs  Gestion des versions  Aide au pilotage des tests :  Etat d’avancement de la conception des tests  Etat d’avancement de l’exécution des tests  Etat d’avancement global d’une campagne de test  Impression de rapport déjà renseigné et formaté  Multi-utilisateurs  Interfaçage et pilotage directs des :  Automates de tests fonctionnels  Automates de tests techniques (performance)  Anomalies 60
  61. 61. @crochefolle Plan de test Un projet de plan de test est un document qui décrit les objectifs, la portée, l’approche et est orienté sur l’effort nécessaire pour tester un programme. Le processus de préparation d’un plan de test est une méthode pratique pour définir les efforts qui seront nécessaire pour valider l’assurance qualité d’un produit. Le document complété peut aussi aider les personnes extérieures à l’équipe de test à comprendre « pourquoi » et « comment » le produit sera validé. Un plan de test défini quelles seront les fonctions qui seront testées et à quel niveau, dans quel ordre elles seront testés et quelle sera la stratégie de test de chaque fonction et l’environnement de test utilisé. L’objectif de chaque plan de test est de définir un schéma de vérification, et par les tests, s’assurer que le produit satisfera à toutes les normes de qualité en vigueur. Dans le cas de test de validation, il s’agit souvent de tester que les fonctionnalités se comportent comme prévu par le cahier des charges initial et produisent les résultats escomptés. 61 1. Carte d’identité du plan de test 2. Références 3. Introduction 4. Modules à tester 5. Risques 6. Fonctions à tester 7. Fonctions à ne pas tester 8. Approche 9. Critères de Réussite/Echec des tests 10. Critères de suspension et critères de reprise 11. Tests déjà effectués 12. Tests à encore effectuer 13. Besoins en matériel 14. Besoins en personnel et formations 15. Responsabilités 16. Planning 17. Risques de planning et facteurs extérieurs 18. Approbations 19. Glossaire
  62. 62. @crochefolle Test manuel vs Test automatisé 62 Test automatisé Test Manuel Avantages • Si vous devez exécuter les mêmes tests de manière répétitives avec des jeux de données différents • S’il s’agit d’un projet d’une durée réduite voire jetable • SI vous devez effectuer des tests de compatibilités : mutl- navigateur, multi-plateforme • Permet aux testeurs de faire des tests plus aléatoires • Permet d’effectuer des tests de non-regression de manière rapide • Permet aux testeurs de faire des tests plus proches de la réalité et donc de trouver des anomalies plus proche du monde utilisateur • Permet d’effectuer des tests de non-regression sur du code en changement fréquent • Coût à court terme réduit • Peux être effectuer en parallèle sur plusieurs machines pour diminuer le temps de test • Coût à long terme réduit Inconvénients • Il est très couteux d’automatiser, temps en mis en place qu’en maintenance • Les tests manuels peuvent consommer beaucoup de temps • Tout ne peut pas être automatiser, certaines fonctions ne peuvent être testées que manuellement • Pour chaque version/release, vous devez refair eles mêmes tests, ce qui devient très démotivant pour les équipes de test Autres facteurs • Performance des outils de test • Le niveau de connaissance de votre équipe de test • L’évolution du volume de fonctionnalité à tester • Nombre de régression à tester
  63. 63. @crochefolle Indicateurs et couverture de tests Bilan de test Document présentant le bilan quantitatif (nombre de tests rédigés, passés, en erreur, nombre et état des anomalies, ...) et qualitatif (points forts, points à améliorer) de la mission de test, ainsi que le résultat fournis par les indicateurs qualité mis en place. Il fournit enfin des préconisations afin de palier les points faibles sur les futurs projets. Indicateurs de suivi des tests :  Nombre de tests effectués / totaux  Nombre de tests passés avec succès/ échecs  Couverture de tests  Nombre d’anomalies ouvertes / fermées par campagne de test  Charge consommée / charge prévisionnelle Couverture de tests  Pour mesurer l’efficacité des tests, il est nécessaire de vérifier les différents cas d'utilisation possible. Pour résoudre ce problème, on utilisera des logiciels de couverture de code qui mettra en évidence les parties du code source exécutées lorsque la suite de test est passée.  Une bonne couverture de code par les tests est primordiale. Cependant, un taux de couverture élevé ne signifie pas pour autant que le logiciel est bien testé. La fragilité des tests est un élément très important. Par exemple : Ca n’est pas parce qu’un test couvre une partie de mon code que cette partie est testée. Imaginer un test sans assert. Ce test participe à la couverture des tests mais pas à leur qualité. En effet, s’il n’y a pas d’assert, le test a toutes les chances de toujours passer. Un test pour être efficace doit être plutôt fragile. C’est à dire qu’il doit casser à la moindre modification du fonctionnel. 01/09/2018 63
  64. 64. @crochefolle GESTION D’ANOMALIES 64
  65. 65. @crochefolle Définitions  Un bug/bogue/anomalie peut être :  soit un non-respect de la spécification du système (c’est-à-dire de la définition de ce que le système est censé faire),  soit un comportement inattendu non couvert par la spécification (par exemple, cas non prévu de deux actions contradictoires à traiter simultanément). 65
  66. 66. @crochefolle Processus de gestion d’anomalie Le cycle de vie d’une anomalie représente l'ensemble des états dans lequel les bugs doivent se trouver. Il est généralement modélisé sous la forme d'une machine d'état qui énonce également les conditions de passage d'un état à un autre. 66 •Avant de soumettre une nouvelle anomalie, il faut s'assurer de la confirmation de l'anomalie (non respect du cahier des charge, crash de l'application, pas de fausse manœuvre de l'opérateur, ...) et de sa reproductibilité (on sait assez facilement le reproduire ou non). •Parfois, l’anomalie n'est plus jamais reproduite par la suite sur base du même environnement (les causes ne sont donc pas connues ou ciblées). Dans ce cas, on préconise néanmoins de le rentrer en tant que "UNCONFIRMED". En agissant de cette façon, on en garde toujours une trace. •Une fois l’anomalie confirmée et reproductible, elle passe en "NEW" et commence son cycle de vie. Le chemin le plus classique est le suivant : l’anomalie est assignée à un développeur particulier (état "ASSIGNED"). •Cette assignation peut se faire automatiquement lors de l'insertion de l’anomalie (mais elle reste dans l'état "NEW"). Dans ce cas, le développeur peut l'accepter (passage en "ASSIGNED" ou l'assigner à une autre personne). •Une fois assigné à un développeur, la mission de celui-ci est de le corriger dans les délais requis. •Une fois corrigé, l’anomalie passe en "RESOLVED". •Ensuite, le contrôle qualité (les testeurs) vérifie que l’anomalie est effectivement corrigée comme prétendu par le développeur. Si c'est le cas, l’anomalie est passée en "VERIFIED". Si les différents cas de test démontrent que le problème persiste encore, elle est passée en "REOPEN" en n'oubliant d'y ajouter des commentaires supplémentaires décrivant les cas de test dans lesquels elle peut encore être reproduite. •Une anomalie réouverte est généralement assigné de nouveau au développeur (état "ASSIGNED") et suit une seconde fois le chemin présenté ci-dessus. •Lors de la release finale du produit, une campagne de test est mise en œuvre et on vérifie de nouveau que les anomalies corrigés en cours du développement ("VERIFIED") le sont toujours. Dès lors, elles sont fermées définitivement (passés en "CLOSED") et les cas de test rajoutés aux tests de non-régression.
  67. 67. @crochefolle Sévérité, criticité Matrice Sévérité Importance 1 - Critique 2 - Majeur 3 - Mineur 4 - Accessoire Occurrence 1 - Fonction principale très utilisée 1 1 2 3 2 - Fonction secondaire, peu utilisée 1 2 3 4 3 - Exceptionnellement, une seule fois 3 4 4 4 Définition Importance Niveau 1 - Critique : Crash Niveau 2 - Majeur : Fonction non réalisée sans contournement Niveau 3 - Mineur : Fonction non réalisée avec contournement NIveau 4 - Accessoire : Tout le reste Occurrence Niveau 1 : Fonction principale très utilisée ou anomalie sur l'ensemble des plateformes supportées Niveau 2 : Fonction secondaire, peu utilisée ou anomalie sur les principales plateformes supportées Niveau 3 : Anomalie constatée exceptionnellement ou une seule fois, ou anomalie sur une des plateformes supportées 67
  68. 68. @crochefolle Indicateurs  Nombre de tickets ouverts par semaine  Nombre de tickets fermés par semaine  Nombre de tickets actifs/en cours par semaine  Temps moyen de prise en compte d'une anomalie  Temps moyen de résolution d'une anomalie  Temps moyen de fermeture d'une anomalie 68
  69. 69. @crochefolle  Une anomalie qui n’est pas référencée dans le référentiel d’anomalies n’existe pas.  Une anomalie non-reproduite doit être référencée pour mémoire.  Le contenu d’une anomalie doit être définit pour chaque projet, système / sous-système afin d’être pertinente. 69 Règles d’or
  70. 70. @crochefolle GESTION DE DOCUMENTATION 70
  71. 71. @crochefolle Définitions  La maîtrise des documents, préoccupation permanente de la qualité se retrouve dans toutes les étapes du cycle de vie. Le rôle de la documentation est essentiel, car c’est elle qui :  Matérialise l’avancement des travaux,  Constitue le moyen de communication privilégié entre les différents intervenants,  Fait partie de la fourniture du produit  Est le support de base indispensable pour les étapes suivantes,  Constitue une partie de la mémoire de l’entreprise.  Il est indispensable de structurer la documentation pour pouvoir la faire vivre, la diffuser, l’exploiter et la sauvegarder efficacement.  La maîtrise des documents est la capacité à concevoir, rédiger, diffuser et retirer de la circulation si nécessaire, les documents adaptés à l’usage pour lequel ils sont prévus. Cette maîtrise doit couvrir toutes les étapes du cycle de vie du logiciel que nous avons étudié : la conception, le paramétrage, le développement, la recette, l’installation, l’exploitation et la maintenance, sans oublier tous les documents relatifs au système qualité.  De plus il faut ajouter :  Tous les documents d’organisation liés au projet, tels que contrat, planning, organisation du projet, plan de développement, plan d’intégration, plan de validation, procédures d’acceptation, … ;  Tous les documents de type d’exploitation, tels que les manuels d’installation, d’utilisation, de maintenance, … 71
  72. 72. @crochefolle Plan de gestion de documentation Il doit définir les éléments suivant : 1. L’identification des documents 2. Les normes de présentation 3. Les états d’un document 4. Les révision et les règles de gestion des versions 5. La circulation des documents  L’identification  La création  La validation  La diffusion  Les modifications  La suppression 6. La procédure d’approbation et de diffusion 7. La procédure de modifications des documents 8. La mise en place de l’organisation administrative 72
  73. 73. @crochefolle  Attribuer une référence (numéro) à un document afin de pouvoir l’identifier sans équivoque. En corollaire, à une référence donnée doit correspondre un document et un seul.  Gérer la documentation par sous-ensembles, les références d’un même sous ensemble étant répertoriées dans une nomenclature de gestion. La description des liens se fait par un schéma d’arborescence.  Identifier les documents en fonction de leur nature ou de leur utilisation. (Dossier de spécification, dossier de conception, dossier d’exploitation, etc…). 73 Règles d’or
  74. 74. @crochefolle 74 Merci

×