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

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

Cycle système - cycle de développement Faisabilité Définition Développement et MCO Retrait Prototype Exploitation Nombre de RA/AC Durée Mesure de la qualité de service (QOS) 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

Détail du cycle de développement (1/3) RETOUR D’EXPÉRIENCE Expression de besoin /Exigences Axe d’évolution 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 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 Qualification 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

Détail du cycle de développement (2/3) Processus de spécification Processus de développement 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 VVT Nombre de RA/AC Exploitation et support QOS Mesure de la qualité de service Durée

Détail du cycle de développement (3/3) Système qualité - Assurance qualité CCG, DCG CCD, DCD CPTU, DPTU CVVT, DVVT AQ globale centralisée CQFD global du projet CAQ = CAQ/GC + CAQ/CG + CAQ/CD + CAQ/PTU + CAQ/VVT CD P/TU VVT CG CAQ/CG CAQ/CD CAQ/PTU CAQ/VVT 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

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 Système Recette Intégration Scénarios de tests Modules Intégration Système Cas à tester Recette Résultats des phases concernant l’activité V&V des phases suivantes Recette Installation 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

Les erreurs humaines et les sources des défauts logiciel

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

Erreurs humaines - Psychologie de la programmation

Taux moyen de défauts VVT 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

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

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 Installation du logiciel Démarrage du logiciel (début de session) Durée moyenne de bon fonctionnement du logiciel  MTTF Durée d’indisponibilité et réparation du logiciel  MTTR

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

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)

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 »

Les acteurs de la VV&T Le chef de projet L’architecte du 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

Place des méthodes de validation Détection des défauts au moyen de : Relectures informelles sur la base de standards Inspections et revues (cf. système qualité) Relectures formelles 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 IVVT Modules Détection des défauts Par les techniques de tests traditionnelles IVVT Système Recette Exploitation du logiciel 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

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 F U R P S E 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

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 Construction systématique multiprojet avec une garantie qualité Développement SI-2 Nombre de RA/AC Durée Mesure de la qualité de service (QOS) Développement SI-n Intégration Référentiel (Modèles) Recette Installation Prochain cycle Mettre en cohérence Vérifier la cohérence Valider l’interopérabilité Méthodologie d’interopérabilité des SI selon MIND™

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 Intégration/Recette Pilote EB/EC Pilote Pilote Suivi fournisseur Système qualité MOA Interactions Contrat Contrat MOE Développement Pilote MOE Développement Pilote 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

Stratégie de test

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

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é

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

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

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

Principes de la VVT

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é

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

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’évaluation honnê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

VV&T et QUALITÉ Qualité VVT 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

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

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

Management qualité fondée sur la métrologie des flux d’anomalies INDICATEURS CARACTÉRISTIQUES   Age moyen des RA, Dispersion des RA  Disponibilité (i.e. MTTF, MTTR)  Temps de non régression Rodage Période d'exploitation d'une version du système Besoin Conception Programmation Intégration Développement Maintenance Date début d'exploitation Date fin 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. Relivraisons Deux modes d'exploitation : 1 à qq. sites (i.e. clé en mains) Nombreux sites (progiciels) —> Doublons Flux de modifications en cours de développement Filtrage  Durée du cycle  Bien distinguer dans le MTTR la part due à la qualité du diagnostic  Taux d’échecs  Courbe de maturité

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

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 Développement Exploitation

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

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)

Amplification du coût de correction (3/5) Application du modèle VEST Pilote de la tâche E T Tâche projet à effectuer S Tâche(s) amont Tâche(s) aval 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

Amplification du coût de correction (4/5) Période d’introduction des erreurs Période de détection/correction des défauts au moyen de tests 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

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

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.

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)