VALIDATION VÉRIFICATION & TESTS

Présentation au sujet: "VALIDATION VÉRIFICATION & TESTS"— Transcription de la présentation:

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 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 : > ans, mais > 30 pour les grands systèmes technologiques

4 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

5 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

6 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

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 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

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 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

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 INSTALLATION MAINTENACE 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 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

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 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

18 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

19 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

20 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™

21 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

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’é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

32 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

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 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é

36 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é)

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

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 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

41 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

42 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

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)