VALIDATION VÉRIFICATION & TESTS

Slides:



Advertisements
Présentations similaires
Mustapha EL FEDDI Tests Mustapha EL FEDDI
Advertisements

Tests et Validation du logiciel
Eléments de Génie Logiciel
Le Développement Le développement.
Les Evolutions et la Maintenance
CORP VG G G 1 P&WC PROPRIETARY DATA 1 Charles Litalien PWC - Bureau de la Technologie Charles Litalien Août 2002 Conception & Développement dune.
Test de Systèmes Intégrés Digitaux et Mixtes
Tolérance aux défaillances de logiciel
Chapitre 7 : démarche de conception, conduite de projet SI
Les démarches de développement
Test de logiciel GLG101 AP.TELLE & S.MILOVANOVIC MAI 2007.
Tests et Validation du logiciel
FIABILITE MAINTENABILITE DISPONIBILITE
Les Ateliers de Génie Logiciel
Intellectual Property Rights are governed by PROTEUS Contract and PROTEUS consortium agreements. Before using, reproducing, modifying or disclosing the.
Qualites du Logiciel: Dependabilite LFI2 Automne 2008 Chapitre 11.
Analyse des Modes de Défaillance, de leurs Effets et de leur Criticité
Initiation à la conception des systèmes d'informations
To be or not to be ? That is the question !!! PHYLOGENESE HUMAINE.
le profil UML en temps réel MARTE
Processus de maîtrise du logiciel libre pour les systèmes embarqués
Cours #8 Flot de conception d’un circuit numérique
Besoins des sociétés minières
Modèle, Méthode et Conception
Modélisation causale multiphysique
CONCEPTION DES LOGICIELS : Chapitre 1
Techniques de test Boulanger Jean-Louis.
OIL & UPML DREVET - HUMBERT Introduction OIL : un langage de description dontologies UPML : un langage de description de systèmes à base.
SemanticMediaWiki Audit de projet Antoine Gavoille Anwar Rhemimet
SemanticMediaWiki Audit de projet Antoine Gavoille Anwar Rhemimet
SemanticMediaWiki Audit de projet Antoine Gavoille Anwar Rhemimet
IGL301 - Spécification et vérification des exgiences 1 Chapitre 1 Introduction (ref : Bray chapitre 1)
© Petko ValtchevUniversité de Montréal Janvier IFT 2251 Génie Logiciel Notions de Base Hiver 2002 Petko Valtchev.
1 SEEDS/M&M - MACS 23 janvier 2007 Groupement de Recherche SEEDS Systèmes d'Énergie Électrique dans leurs Dimensions Sociétales.
Élaboration des objectifs
Les étapes du cycle de développement du génie logiciel
Introduction Un test sur les tests Ce que n’est pas le test
MANAGEMENT DE LA QUALITÉ DANS LES PROJETS INFORMATIQUES
Test logiciel Xavier Baril.
Objectifs de vérification logiciels GEF492A 2014 Référence: [HvV §14.1] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie.
Qualites du Logiciel: Dependabilite IF4 Automne 2008 Chapitre 11.
Indicateurs Qualité Projets Logiciels
Supports de formation au SQ Unifié
INF8505: processeurs embarqués configurables Département de génie informatique et génie logiciel Langages de description architecturale.
©2001 Reproduction interdite J.Printz / CNAM - CMSL / VV&T dans le cycle système / Vers. 2.0 Page N° 1 VALIDATION VÉRIFICATION & TESTS Place de la VVT.
Institut Supérieur des Sciences Appliquées et de Technologie Sousse
GENIE LOGICIEL
1 Emeric ROLLIN 1 Génie Logiciel GENIE LOGICIEL
Gilles Dussault Politiques et gestion des ressources humaines en santé Gilles Dussault Note: I am attaching slides on the conceptual framework for the.
Introduction au Génie Logiciel
Test et Testabilité des Circuits Intégrés Digitaux
©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 1 : Définitions et concepts de base / Vers. 4.4Page 1 VALIDATION VÉRIFICATION & TESTS.
Initiation à la conception des systèmes d'informations
1 Emeric ROLLIN 1 Génie Logiciel GENIE LOGICIEL
©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2A : Élaboration d ’une stratégie de test / Vers. 2.0Page 1 VALIDATION VÉRIFICATION.
Présentation AICHA REVEL INGENIEUR D’ÉTUDE STERIA DEPARTEMENT TRD
Année 2006 – 2007 ENSEA © Emeric Rollin
INSTITUT NATIONAL DE FORMATION EN INFORMATIQUE
OPTIMISATION DE LA PLANIFICATION
G.L modèle en CASCADE Plan Réalisé par : Selmane mohamed lamine
Sensibilisation aux projets logiciels
© Petko ValtchevUniversité de Montréal Janvier IFT 2251 Génie Logiciel Le Processus Hiver 2002 Petko Valtchev.
Retour aux fondamentaux
Document de spécification d’exigences Normes IEEE et 29148:2011
Analyse des Modes de Défaillance, de leurs Effets et de leur Criticité
IFT 703 Informatique cognitive ACT-R Modèle symbolique et perceptuel
PRÉSENTATION AGL LES TESTS LOGICIELS LES TEST LOGICIELS 1 Mickael BETTINELLI Brandon OZIOL Gaétan PHILIPPE Simon LUAIRE.
19 avril Spécification d’un cadre d’ingénierie pour les réseaux d’organisations Laboratoire de recherche : OMSI à l’EMSE.
YOUR CENTRAL SOURCE FOR DATA EXCHANGE TranscenData Proprietary Confidential Support AP242 Solution d’Interopérabilité ITI TranscenData 26 Mars 2014 Vincent.
WHAT IS THIS ? Serveur d’intégration Environnement JAVA Open Source Ou logiciel d’intégration continue.
Transcription de la présentation:

VALIDATION VÉRIFICATION & TESTS Le problème fondamental du génie logiciel : le problème de l'erreur

Le problème de l'erreur COMMENT CONSTRUIRE DES LOGICIELS QUI SOIENT : ERGONOMIQUES FIABLES EVOLUTIFS ECONOMIQUES SATISFAISANT AUX CRITERES Coût/Qualité/Fonctionnalités/Délais de réalisation (CQFD) GARANTISSANT LE CONTRAT DE SERVICE REQUIS PAR LES USAGERS

Le constat et les causes PRESENCE DE NOMBREUX DÉFAUTS DANS LES LOGICIELS CAS DE LA NAVETTE SPACIALE : logiciel embarqué : 0.11 par KLS (500) logiciel sol : 0.40 par KLS (1400) Logiciels grand public : plutôt 5-10 voire plus par KLS EVOLUTIVITE DES LOGICIELS PROBLEMATIQUE (Régression en qualité) CAS DES GRANDS SYSTEMES

Présence et retrait des défauts logiciels 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 VVT Tests de couverture Tests fonctionnel à partir des données Réduction du nombre de défauts au minimum acceptable selon le contrat de service Tests de performance 80 à 100 défauts par KLS Tests de robustesse Tests de pré-intégration 5 à 10 défauts par KLS Intégration 1 à 2 défauts par KLS Installation

Fiabilité de la communication humaine L'ERREUR HUMAINE EST FREQUENTE DANS : L'ACTIVITE LOGICO-MATHEMATIQUE LA GENERALISATION ET LA CONSTRUCTION DES ABSTRACTIONS LA MODELISATION ET LA DYNAMIQUE DES SYSTEMES LA COMMUNICATION (COMPRENDRE ET ETRE COMPRIS AU SEIN D’UN GROUPE : LA SÉMANTIQUE) LA TRADUCTION (CHANGEMENT DE CODE) CES ACTIVITÉS SONT AU COEUR DE LA PROBLEMATIQUE INFORMATIQUE

Terminologie QUELQUES DEFINITIONS (IEEE STD 982 et 1044) ERROR (Erreur) : Human action that results in software containing a fault. E.g. omission or misinterpretation of user requirements in a software specification, and incorrect translation or omission of a requirement in the design specification. DEFECT (Défaut) : A product anomaly; e.g. (1) omissions and imperfections found during early life cycle phases and (2) faults contained in software sufficiently mature for test or operation. FAULT (Défaillance) : (1) An accidental condition that causes a functionnal unit to fail to perform its required function. (2) A manifestation of an error in software. A fault if encountered may cause a failure. FAILURE (Panne) : The termination of the ability of a functionnal unit to perform its required function. A failure may be produced when a fault is encountered.

La chaîne de l'erreur Erreur Défaut Défaillance Panne ACTION HUMAINE ERROR DEFECT FAULT FAILURE Est à l'origine qui peut conduire qui peut provoquer ACTION HUMAINE DANS LE LOGICIEL DANS LE PRODUIT DE LA FONCTION Métrique: Densité d'erreurs Temps moyen de diagnostique MTTR Peut être masqué par des dispositifs de type tolérance aux pannes Métrique: MTTF MTBF

Caractéristiques qualité Reliability (Fiabilité) Probabilité p de fonctionnement sans panne, pour une certaine durée, sous certaines conditions environnementale p dépend de la qualité des entrées et du taux de défauts résiduels du logiciel Safety/Dependability (sûreté de fonctionnement) Capacité à éviter les dangers et/ou les risques qu’une panne logicielle peut faire courir à l’environnement système (pertes d’équipements, pertes humaines, dégradations, etc.) Dépend de la capacité du système englobant (modèles de pannes) à rétablir une situation sans risque (survie, reconfiguration, etc.)