VALIDATION VÉRIFICATION & TESTS

1. VALIDATION VÉRIFICATION & TESTS Place de la VVT dans le cycle système

2. Le cycle système et le cycle de développement

3. Nombre de RA/AC Mesure de la qualité de service (QOS) Durée Exploitation Cycle système - cycle de développement Développement et MCO Retrait Faisabilité Définition Prototype Expérimentation Réalisation de maquettes Réalisation de prototypes Version N°1 Version N°2 Exploitation A l’issue de ces deux phases, l’architecture/urbanisation du système d’information doit être stabilisée Le modèle de croissance est explicite Cycles de développement Version N°n Exploitation Durée d’un cycle : > 15-20 ans, mais > 30 pour les grands systèmes technologiques

4. Détail du cycle de développement (1/3) RETOUR D’EXPÉRIENCE Axe d’évolution Expression de besoin /Exigences Processus de DEVELOPPEMENT Axe d’évolution CdCF-3 Réalisation incrément N°3 CdCF-2 CdCF-1 Réalisation incrément N°2 Réalisation incrément N°1 Qualification Conception Axe d’évolution Qualification • Documents contractuels : • Spécifications techniques de besoin et exigences (fonctionnel et non fonctionnel, en particulier contrat de service pour les usagers en terme d’exigences) Développement Intégration • Fournitures contractuelles : • Kit d’installation, paramétrage et règle de calibrage, doc pour le support, doc utilisateur, etc. • Garantie Assurance Qualité et contrat de service Déploiement, support et MCO

5. Détail du cycle de développement (2/3) Processus de développement Processus de spécification Expression de besoin et exigences Mesure de la maturité de l’EB/EC EB/EC (Spécification fonctionnelles) • Défauts détectés • Défauts propagés • Défauts ajoutés Conception générale CG Conception détaillée Implémentation CD Programmation et tests unitaires • Mesure du taux d’erreurs résiduelles Processus de conception P/TU Intégration (VV&T) Mesure de la maturité (i.e. contrat de service) en exploitation Assurance qualité et activités transverses AQ Nombre de RA/AC VVT Exploitation et support QOS Mesure de la qualité de service Durée

6. CCD, DCD CCG, DCG CQFD global du projet CG CPTU, DPTU CAQ/CG CD CVVT, DVVT CAQ/CD P/TU CAQ/PTU VVT CAQ/VVT AQ globale centralisée CAQ = CAQ/GC + CAQ/CG + CAQ/CD + CAQ/PTU + CAQ/VVT Détail du cycle de développement (3/3)Système qualité - Assurance qualité Nombre de RA/AC Courbe de maturité Déléguer Contrôler Mesurer Agir Effort La recherche systématique des défauts se fait préventivement dans toutes les phases du cycle de développement

7. Cycle de vie VVT (Validation, Vérification, Test) • L’activité de VVT débute dès la phase EB/EC Besoin Conception • Plan et objectifs de tests • Système • Recette TESTS ET VÉRIFICATIONS POUR LA NON RÉGRESSION Développement • Plan de tests • Modules • Intégration • Conception des tests • Modules • Intégration • Système • Recette Intégration • Scénarios de tests • Modules • Intégration • Système • Cas à tester • Modules • Intégration • Système • Recette Recette Installation Résultats des phases concernant l’activité V&V des phases suivantes • Scénario de tests • Recette Construction de la courbe de maturité Pour toutes les phases : collecte des Rapports d’Anomalies (RA) et des Actions Correctrices (AC) ; traçabilité Cf. ANSI/IEEE Std 1012 Software verification and validation plans ; Std 1059 Guide VVT

8. Les erreurs humaines et les sources des défauts logiciel

9. Origine des erreurs humaines • Incompréhension du besoin et des exigences de l’organisation cible • En particulier les caractéristiques non fonctionnelles • Incompréhension de l’environnement de développement et d’exécution • Complexité des plates-formes • Erreurs inhérentes à l’activité psychocognitive • Capacité intrinsèque des personnels • Expérience et savoir faire Cf. mon livre, Puissance et limites des systèmes informatisés, Chapitre 3, chez Hermès

10. Erreurs humaines - Psychologie de la programmation

11. Taux moyen de défauts • Modèle de données, en particulier interfaces entre les modules, • Modèle d’enchaînement/contrôle des fonctions Conception détaillée • Code source fabriqué par les programmeurs, compilé sans erreur Programmation • Réduction du nombre de défauts au minimum acceptable selon le contrat de service VVT Tests de couverture et de contrôle Tests fonctionnel à partir des données • 80 à 100 défauts par KLS Tests de performance Tests de robustesse Tests de pré-intégration • 5 à 10 défauts par KLS INTÉGRATION Si la stratégie de VVT est correctement conduite • 1 à 2 défauts par KLS Installation

12. La chaîne de l’erreur (1/2) Erreurs humaines Introduction des défauts dans les différentes phases du cycle BESOIN CONCEPTION PROGRAMMATION INSTALLATIONMAINTENACE EXPLOITATION Défaillance +/- graves Manifestation d’une défaillance Éventualité d’une panne  grave Défaut dans le logiciel Erreur humaine

13. La chaîne de l’erreur (2/2) Période de très grand danger pour l’intégrité du système Période d'introduction de défauts d'installation (Actions erronées de l'administrateur) Période d'observation de la défaillance Période d'introduction de défauts d'exploitation (Actions erronées de l'usager) Temps de latence TFin nominal T0 TDébut T1 T2 Fault (exécution du défaut) • Failure • (constatation de la défaillance) • Arrêt du logiciel Démarrage du logiciel (début de session) Installation du logiciel Durée d’indisponibilité et réparation du logiciel  MTTR Durée moyenne de bon fonctionnement du logiciel  MTTF

14. Espace méthodologique et maturité de l’activité VVT

15. Espace méthodologique VV&T Axe caractéristiques qualité produit (Cf. ISO/CEI 9126) • 6 caractéristiques principales • FURPSE • Caractéristiques de l’environnement système • Sécurité, sûreté de fonctionnement, interopérabilité, etc. Axe méthodes VVT Axe méthodologies Cycle système et cycle de développement (Cf. ISO/CEI 12207)  Chaque phase a des besoins et des exigences qui lui sont propres Espace de de choix possibles très grand donc risque d’inconsistance et d’incomplétude si la maturité de l’équipe est faible (cf. CMM)

16. Rappel CMM : les 5 niveaux Optimiser • Régulation du processus sur les objectifs stratégiques de l’entreprise : • Prévention des défauts • Intégration des NTI ( architecture ouverte et testable) dans la stratégie • Optimisation CQFD Piloter • Pratique systématique de la mesure pour évaluer la performance : • Processus de développement • Produit logiciel réalisé Définir • Définition des processus • Vision systémique « gagnant-gagnant » des acteurs ( formation) • Satisfaction du client final • Revues de projet, évaluation des risques Reproduire • Gestion du besoin et des exigences • Assurance qualité (i.e. VV&T) • Gestion de projet ; contrats de sous-traitance • Gestion des configurations Initial « laissez faire »

17. Les acteurs de la VV&T • Le chef de projet • Planification des tâches et assurance qualité (système qualité) • L’architecte du projet • Architecture testable • Les programmeurs • Composants logiciel {Données+Algorithmes +Contrôles} intégrables (i.e. documentés et testés) • Le responsable de l’intégration et son équipe • Le responsable de la qualification indépendante et son équipe (Assurance Qualité ; Recette) • Le support et/ou la maintenance de 1er niveau

18. Place des méthodes de validation • Détection des défauts au moyen de : • Relecturesinformelles sur la base de standards • Inspections et revues (cf. système qualité) • Relecturesformelles • Preuves par simulation sur la base de modèles explicites • Simulation partielles • Simulations exhaustives • Preuves « mathématiques » par raisonnements explicites • Par construction (via des langages ad hoc) • Par induction (démonstrations  automatiques • Compilation des langages EB/EC CG CD Codage TU Détection des défauts Par les techniques de tests traditionnelles IVVT Modules IVVT Système Exploitation du logiciel Recette Fichier des incidents Enregistrement systématique de tous les incidents au moyen de fiches RA/AC précises + Traces facilitant le diagnostic Ce flux permet la mesure du taux d’erreurs résiduelles

19. F U R P S E Du besoin client au système installé Cycle de développement système Chaîne de valeur Assurance qualité système selon FURPSE appliquée à la chaîne de valeur Les 3 NIVEAUX de modélisation Expression de besoin - Exigences comportementales • Processus, Fonctions et Flux au sens métier • Ordonnancement et règles de gestion • Qualité de service (QOS) du point de vue « client » N1 Spécifications fonctionnelles • Processus, Fonctions et Flux au sens informatique ; cartographie • Ordonnancement des travaux (workflow) • Contraintes d’exploitation (capacity planning ; system management) N2 Conception système (Générale + Détaillée) Assurance qualité • Composants logiciel, transactions, COTS, « legacy » applications, etc. • Ordonnancement (client-serveur ; middleware ; OLTP ; etc.) • Maintenabilité ; diagnostics ; reprises incidents ; surveillance • Encapsulation des technologies et évolutivité N3 Programmation Bilan qualité et intégration Intégration • Bilan VVT du développement; Tests de charge ; Robustesse ; Disponibilité ; etc. • QOS estimée au vue des résultats des tests d’intégration Installation - Déploiement • VVT des paramétrages et des scripts d’installations ; MCO • QOS constatée sur les sites d’exploitation ; tableau de bord

20. Nombre de RA/AC Mesure de la qualité de service (QOS) Durée Nécessité d’une méthode transverse cohérente Structure d’un cycle d’acquisition de l’interopérabilité du SI global MOE(s) Besoin Développement SI-1 Conception Développement SI-2 Construction systématique multiprojet avec une garantie qualité Intégration Développement SI-n Référentiel (Modèles) Recette Installation Prochain cycle Valider l’interopérabilité Mettre en cohérence Vérifier la cohérence Méthodologie d’interopérabilité des SI selon MIND™

21. Pilote Pilote EB/EC Intégration/Recette Pilote Pilote MOE Développement MOE Développement Mise en œuvre de la méthode Nécessité de mise en cohérence des systèmes qualité MOA ET MOE Pilote stratégique MOA Pilote Suivi fournisseurSystème qualité MOA Interactions Contrat Contrat Système qualité MOE Plus les référentiels sont rigoureux et explicites, meilleures sont les chances de détecter les erreurs et de corriger les défauts

22. Stratégie de test

23. Stratégie de test : les objectifs (1/2) • Un double objectif : • Augmenter le MTTF  Réduire au maximum le taux d’erreurs résiduelles  Reconfigurer dynamiquement le système sur des états cohérents malgré le non-déterminisme (c’est une compensation des effets de certaines défaillances connues) • Diminuer le MTTR  Se donner les moyens d’observation des états déterministe du système (élimination systématique des erreurs reproductibles)  Réserver des ressources en quantité suffisante pour les tests « en ligne »  En respectant les contraintes de Coût-Délai du projet

24. Stratégie de test : les moyens (2/2) • Architecture testable • Créer les conditions d’observation des états du système que l’on saura interpréter et reproduire • Évaluation des caractéristiques non fonctionnelles des COTS (i.e. réduire le facteur d’incertitude) • Valider l’ergonomie avec les usagers REELS • Équilibrer : • Techniques AQ : revues, inspections, audits, • tests Boîte Noire et tests Boîte Blanche • Tests de robustesse et tests d’innocuité/sûreté

25. La vision qualité : répartition de l’effort Objectifs de test Équilibrage de l’effort de test Programmeur individuel Tests unitaires Test boîte blanche 1 Axe de progression de l’intégration en minimisant les retours arrière Équipe projet Intégration projet 3 Zone grise 2 Équipe système Intégration système Test boîte noire i est un coefficient d’amplification

26. Productivité de l’effort VVT Nombre de défauts détectés Techniques de TEST (Détection des défauts coûteuse) Techniques REVUES + INSPECTIONS (Détection des défauts peu coûteuse) PERTE Temps/Effort

27. Profils de maturité qualité produit Nbre de RA-AC Profil N°3 Profil N°1 Défauts résiduels Profil N°2 Effort VVT En relatif, ces profils sont indiscernables, mais les taux d ’erreurs résiduelles sont très différents

28. Principes de la VVT

29. Quelques principes VV&T (1/3) • Principe N°1 • Tester exhaustivement un logiciel est généralement impossible • Phénomènes combinatoires et coûts exponentiels • Principe N°2 • Tester correctement un logiciel est une tâche difficile qui requiert intelligence et créativité • Choix de stratégies, critères d’arrêt + Connaissance indispensable du contexte d’emploi réel • Pièges : • croire que c’est simple et facile par rapport à la programmation jugée plus « noble » • croire que cela n’exige ni expérience, ni savoir-faire, ni méthodes et qu’il est inutile de planifier cette activité

30. Quelques principes VV&T (2/3) • Principe N°3 • L’essence de l’activité de test est la prévention • Elle s’applique à toutes les phases du cycle • Il est futile de concevoir ce que l’on ne saura pas tester • Concept de testabilité à tous les niveaux • Principe N°4 • Le volume et la nature des tests à effectuer (i.e. l’effort VVT en terme de CQFD) doit s’apprécier en terme de risques que l’emploi du logiciel fait courir à l’organisation cible

31. Quelques principes VV&T (3/3) • Principe N°5 • La planification sérieuse de la VVT est indispensable à la maîtrise du projet • Chaque tâche du projet a sa propre VVT afin d’éviter l’effet d’avalanche lors de l’intégration • Piège : considérer que l’effort de test est une marge de manœuvre • Principe N°6 • L’évaluationhonnête de la qualité exige la présence d’un tiers de confiance (AQ logiciel) indépendant du développement • Piège : croire que le développement est seul juge

32. VV&T et QUALITÉ • Qualité • Conformité aux exigences du contrat de service défini par l’organisation cible • La qualité est une notion relative (Appréciation du risque  Notion de qualité de service QOS) • VVT • Le but des tests est de rendre la qualité « visible » • Le ratio de l’effort de VVT est un indicateur de la qualité du logiciel

33. Influence de la VVT sur la productivité et le rendement de l’organisation de développement

34. Données économiques Métriques qualité Coût des corrections Courbes de maturité Facteurs d’amplification des coûts Coûts pour l’usager

35. INDICATEURS CARACTÉRISTIQUES  Age moyen des RA, Dispersion des RA Disponibilité (i.e. MTTF, MTTR) Temps de non régression Développement Maintenance Besoin Durée du cycle Conception Flux de modifications en cours de développement Programmation Intégration Date fin d'exploitation Date début d'exploitation Relivraisons Rodage • Deux modes d'exploitation : • 1 à qq. sites(i.e. clé en mains) • Nombreux sites (progiciels)—> Doublons Période d'exploitation d'une version du système Courbe de maturité Flux continu de défaillances découvertes en exploitation • Coûts chez l'exploitant : • Émission d'un Rapport d'Anomalie. • Coûts d'arrêts de l'exploitation. • Pertes d'équipements, humaines,… • Coûts chez le fournisseur: • Constitution d'un dossier d'Erreur (Action Correctrice). • Coûts de réparation et de relivraison de tout ou partie du système. Filtrage Taux d’échecs Bien distinguer dans le MTTR la part due à la qualité du diagnostic Management qualité fondée sur la métrologie des flux d’anomalies

36. Coût moyen des corrections Conception Programmation Intégration VVT Taux d’erreurs acceptable ??? Coût moyen par phase selon vade-mecum 40% 20% 40% Ce qui est refait selon vade-mecum 30% 50% 70% Coût moyen des corrections = 50% 12% 10% 28%  Domaine de la prévention (amélioration de la productivité)

37. Courbes de maturité - Transfert de coût Palier de maturité acceptable (dépend du taux d’erreurs non reproductibles) 1 à 5 Err/KLS selon exigence Pente résiduelle La différence est supportée par l’éditeur du logiciel La différence est supportée par l’usager du logiciel 1ère mise en service Temps Exploitation Développement

38. Amplification du coût de correction (1/5) • Le coût de traitement d’une erreur dépend fortement du temps de latence (Introduction/Découverte) : Erreur humaine/défaut  Défaillance reproductible • Plus le temps de latence est long, plus le coût de la correction est élevé • Toute erreur non détectée peut occasionner d’autres erreurs (amplification)  Avec l’augmentation de complexité, seule une stratégie préventive est gagnante

39. Amplification du coût de correction (2/5) • Modèle d'amplification par phase du cycle de développement ERREURS COMMISES DÉTECTION ERREURS PROPAGÉES EFFICACITÉ DE LA DÉTECTION DANS LA PHASE DÉFAUTS PROVENANT DES PHASES PRÉCÉDENTES Yi ERREURS AMPLIFIÉES DÉFAUTS TRANSMIS À LA PHASE SUIVANTE Yj ERREURS NOUVELLES xj • COËFFICIENT D'AMPLIFICATION : #ERR  •  dépend fortement de l'architecture (interfaces, modularité) • l'efficacité de la détection dépend de la documentation, des standards, de l'organisation qualité et de l’expérience de l’équipe de revue (cf. facteurs AEXP et ACAP de COCOMO)

40. Amplification du coût de correction (3/5) • Application du modèle VEST Pilote de la tâche E S T Tâche projet à effectuer Tâche(s) aval Tâche(s) amont Flux nominal et anomalies imputables à T Flux nominal et demandes de modifications V Validation, vérification, test Tâches d ’assurance qualité permettant de détecter préventivement les défauts et d’éviter leur propagation

41. Amplification du coût de correction (4/5) Période de détection/correction des défauts au moyen de tests Période d’introduction des erreurs x1 x2 x3 x4 EB/EC CG CD Codage TU IVVT Modules IVVT Système Recette Y1 Y2 Y3 Y4 Construction du référentiel de VVT Scénarios de tests • Statistique de répartition des défauts (selon B.Beizer, Software testing techniques) • EB/EC : 9% • CG : 26% • CD : 52% (dont 24% sur les données) • Codage : 10% • Tests : 3% • Potentiel de détection des scénarios de tests fonction du volume de scénarios (fonctionne comme un filtre) • Défaillances les + probables • Absence de doublon

42. Amplification du coût de correction (5/5) >  300  150 à 300  50 à 150  10 à 50  4 à 8  2 à 4 EB/EC Réalisation incrément N°1 CdCF-1 Conception Développement Documents contractuels Intégration Déploiement, support et MCO ORIGINE = 1 Fournitures contractuelles

43. Coût pour l’usager (1/2) • Coûts de gestion • Emission de RA, installation des corrections, relivraisons, tests de régression, etc. • Coûts des interruptions de service • Systèmes « clé en main » • Possibilité d’impact « catastrophique » selon la criticité du système • Exemples : Infrastructures techniques (contrôle aérien, énergie, communications, réseaux bancaires, défense, etc.) • Progiciels • Existence de contournement selon le niveau de maturité • Systèmes d’exploitation, progiciels système (SGBD, Réseaux, etc.), progiciels applicatifs, etc.

44. Coût pour l’usager (2/2) • Impact des défaillances en terme de coût • Le coût induit par une erreur est fonction : • FRÉQUENCE DE LA DÈFAILLANCE : liée au taux d'erreurs résiduelles, effet de parc (variété/nombre des configurations installées) • COÛT DE LA RÉPARATION : dépend de l’architecture du système (par exemple : avec ou sans dispositif de journalisation, avec ou sans dictionnaire de données/gestion de configuration, etc.) • COÛT DE LA CORRECTION : très dépendant de l’automatisation des tests (cf. caractéristique de maintenabilité du logiciel) • COÛT DE L’INSTALLATION : dépend de l’architecture du système (par exemple : avec ou sans édition de liens dynamique, avec ou sans moniteur de machines virtuelles, etc.) + effet de parc • COÛT DE L’INTERRUPTION DE SERVICE : la non disponibilité du système peut induire des pertes qui doivent être comptabilisées (dommages et intérêts)