Introduction au test de logiciel. Cours INE21 Séances 1-5. Philippe Herrmann

Dimension: px
Commencer à balayer dès la page:

Download "Introduction au test de logiciel. Cours INE21 Séances 1-5. Philippe Herrmann philippe.herrmann@cea.fr"

Transcription

1 Introduction au test de logiciel Cours INE21 Séances 1-5 Philippe Herrmann session 2010

2 2

3 Table des matières 1 Introduction Vérification : Objectifs et Intérêt Vérification et Validation Quand vérifier? Comment vérifier? Bonnes pratiques dans le logiciel Bonnes pratiques Mesures de la qualité d un logiciel Qualité et CMMI Répartition des efforts dans le domaine logiciel Vérification et méthodes formelles Vérification Formelle : définition Vérification par sous-approximation : le test Vérification par sur-approximation : techniques d abstraction Vérification par la preuve assistée Vérification formelle dans l industrie Test de Logiciel Généralités sur le test Importance du test Test : définitions et propriétés Infrastructure de test Perspectives du test Processus de test Quelques définitions Oracle de test : un exemple Process simplifié du test Scripts de test i

4 TABLE DES MATIÈRES Environnement de test unitaire Mesure de la qualité d une suite de tests Caractérisations de l activité de test Typologie Test Fonctionnel, Test Structurel Phases du test Autres types de tests Pièges du test Par rapport au rôle du test Par rapport au processus de test Conclusion Sélection des Tests Génération boîte noire Analyse partitionnelle Test aux limites Test combinatoire : approche n-wise Génération aléatoire Autres techniques de génération Génération boîte blanche et critères de couverture Graphe de contrôle Couverture des blocs, couverture des arcs Couverture des décisions, conditions Couverture MC/DC Couverture de boucles, de chemins Couverture du flot de données Couverture des mutants Conclusion Génération Automatique de Tests Panorama des techniques de génération Génération automatique aléatoire Génération automatique en boîte noire Génération automatique en boîte blanche Techniques de génération automatique de tests structurels Prédicat de chemin Génération par exécution symbolique des chemins Exemple de génération par exécution symbolique ii

5 4.2.4 Génération de tests par exécution concolique Apport pour le traitement des alias Apport pour l utilisation de code externe Conclusion iii

6 iv

7 Chapitre 1 Introduction 1.1 Vérification : Objectifs et Intérêt Vérification et Validation Vérification et Validation ou V&V : ensemble d activités exécutées en parallèle du développement d un système logiciel afin de fournir l assurance qu il fonctionnera conformément à un ensemble d exigences / spécifications / besoins utilisateur. Le processus de V&V évalue le logiciel dans un contexte système par une approche structurée : le logiciel est testé en interaction avec les fonctionnalités du système, le contexte d utilisation (hardware, OS), les interfaces logicielles (bibliothèques par exemple) et l utilisateur. Il s inscrit naturellement dans le cycle en V classique de développement de systèmes logiciels. Exigences Système Recette du Produit final Exigences du Logiciel Spécifications Conception Générale Conception Détaillée revues diverses analyses statiques Tests Système Tests d'intégration analyses dynamiques (plate forme d'exécution) Codage Tests Unitaires déverminage Généralement on effectue la distinction suivante entre vérification et validation : 1

8 Introduction Vérification : il s agit de comparer certaines propriétés intrinsèques du logiciel à des standards, procédures, politiques, process, exigences, spécifications : «am I building the product right?» Validation : ici on compare le contenu informatif du produit à des propriétés extrinsèques : fait-il ce pour quoi il a été conçu? satisfait-il les besoins du client : «am I building the right product?» Ce cours traite principalement de la vérification du logiciel sous les angles suivants : test : techniques et environnement de test pour le logiciel (ce document) preuve (3 cours) : prouver qu un logiciel satisfait à ses spécifications par la preuve de programme model checking (3 cours) : modéliser le logiciel par des techniques à base d automate et vérifier automatiquement des propriétés exprimées en logique temporelle Objectifs de la vérification de logiciel La vérification a pour objectif principal de construire des systèmes ayant un minimum de défauts. Les défauts interviennent typiquement à différents niveau dans le cycle en V : défaut dans les spécifications (amont) : une fonctionnalité attendue a été oubliée ou mal spécifiée défaut dans la conception : la réalisation d une fonctionnalité ne satisfait pas à ce qui a été spécifié défaut de codage (aval) : l implantation de la fonctionnalité n a pas été faite en accord avec sa conception Plus le défaut est introduit en amont, plus son impact potentiel est grand et sa correction coûteuse. Il s avère donc indispensable d adopter une méthodologie de vérification qui permette de détecter les défauts au plus tôt après leur introduction, par exemple en vérifiant chaque étape du cycle en V avant de passer à l étape suivante. Un objectif annexe de la vérification est de permettre la détection précise des défauts. Un logiciel conséquent peut avoir de l ordre de 10 5 à 10 6 lignes de code. Il est donc essentiel de pouvoir tracer un défaut jusqu à sa source, notamment lors du développement du logiciel, mais potentiellement aussi lors des phases d intégration, voire lorsque le logiciel est en opération. Il est souvent indispensable de prévoir des fonctionnalités de diagnostic afin de pouvoir effectuer un retour vers le développeur en cas de détection de problèmes (par exemple lors de violations d assertions à l exécution) Quand vérifier? La vérification doit fait partie intégrante du développement du logiciel, notamment parce que vérifier a posteriori qu un logiciel répond à certaines exigences est infiniment plus coûteux que de procéder de manière structurée et incrémentale, et que la qualité d un logiciel vérifié en parallèle de son développement est bien supérieure. Lors de la descente du cycle en V (spécification, conception, développement), il s agit de vérifier que les différents modèles décrivant le système final et ses sous-systèmes satisfont bien aux exigences définies par le niveau de modélisation supérieur : 2

9 les spécifications doivent répondre aux exigences systèmes les modèles de conception doivent réaliser les fonctionnalités spécifiées le code doit fournir une implantation correcte des modèles de conception La vérification d un niveau se fait conformément aux exigences héritées du niveau supérieur, elles mêmes issues au final des exigences systèmes initiales. Lors de la phase remontante du cycle en V, les sous-systèmes sont intégrés de manière incrémentale pour aboutir au système final. A chaque étape, les sous-systèmes sont supposés remplir correctement des sous-fonctions, et l on cherche à vérifier que leur combinaison permet de réaliser les fonctionnalités de plus haut niveau Comment vérifier? La vérification se base sur des processus spécifiques tout au long du cycle de développement. Il existe des technologies outillées qui ont pour objectif d assurer formellement le développement et la vérification parallèle de la partie logicielle d un système (méthode B 1 ). Le projet Meteor (ligne 14 du métro de Paris) a été réalisé en utilisant la méthode B. Il est cependant fréquent que les différentes étapes du développement soient chacune associée à un ensemble de processus ad hoc pour vérifier leurs exigences : le test, la preuve de programme et le model checking en sont des exemples. Une difficulté est alors d assurer la cohérence entre les différents niveaux de description du système. D autre part, une grande part de la vérification est réalisée par l utilisation de méthodologies que l on peut qualifier de transversales. En vrac on peut citer : règles de codage (par exemple MISRA 2 pour le monde automobile) : généralement pour interdire des constructions jugées dangereuses pour des langages comme C ou C++ revue par les pairs : les autres concepteurs/développeurs effectuent des relectures critiques des modèles/codes, dans un processus qui peut être formalisé utilisation d outils de génie logiciel : gestionnaire de versions 3, bug tracking systems 4,... environnement d automatisation des tests : faciliter leur écriture, automatiser leur exécution (non-régression) Pourquoi vérifier? A un niveau plus macroscopique, la vérification a avant tout un intérêt économique crucial pour l industrie du logiciel. Des études ont chiffré les gains potentiels d une activité de test bien menée à plusieurs milliards de dollars pour l industrie du logiciel américaine. Il existe donc un intérêt économique évident à la vérification, qui permet de produire plus rapidement des logiciels de meilleure qualité. Ceci est à mettre en parallèle avec le fonctionnement d une industrie comme l automobile, où il y a intérêt à avoir la capacité de sortir de nouvelles voitures rapidement tout en gardant un haut niveau de qualité

10 Introduction Outre l aspect économique, certains domaines d activité industrielle ayant une composante logicielle non négligeable (aéronautique, ferroviaire, nucléaire civil et médical) voient leur processus de mise sur le marché de nouveaux produits soumis à des autorités de certification. Le logiciel de ces systèmes doit obligatoirement avoir été développé selon certaines normes et/ou satisfaire à une certaine mesure de qualité. Certifier le logiciel de ces systèmes sans processus de vérification adapté est généralement illusoire. A titre d exemple, on peut citer la norme DO178B applicable aux logiciels critiques dans l avionique. Les niveaux les plus exigeants de cette norme (A,B,C) exigent par exemple un certain niveau de couverture de code par les tests et la justification des écarts constatés (par exemple : pas de code non-exécutable ou code «mort»). Un logiciel produit dans un processus de développement classique a bien peu de chance de satisfaire à ce type de contraintes de couverture structurelle. 1.2 Bonnes pratiques dans le logiciel Bonnes pratiques Pour un développement classique de logiciel, certaines pratiques de développement et de vérification sont communément admises comme ayant fait leur preuve du point de vue du rapport entre leur coût et leur gain en terme de qualité. L état de l art prône principalement : la vérification en profondeur de l ensemble des exigences du logiciel la revue par des pairs («peer-review») des spécifications et des documents et modèles de conception la vérification en profondeur des implantations critiques, la revue pour le reste du code le test unitaire (fonction par fonction) systématique avec une bonne qualité de couverture, et en général la réalisation et l exécution d un plan de tests pertinent (pour les tests d intégration, les tests du système... ) De bonnes pratiques de génie logiciel (Makefile, gestionnaire de version, bug-tracking, qualité de la documentation, automatisation des tests de non-régression... ) contribuent également à la qualité du logiciel et facilitent sa vérification. La mise en œuvre de telles pratiques permettrait de générer les performances théoriques suivantes (en partant d une situation sans systématisation du test, sans revue par les pairs, et à ne pas prendre trop au sérieux) : 70-90% des défauts détectés avant la phase de test ratio 7-12x de retour sur investissement réduction du time-to-market de 10-15% par an productivité doublée en 5 ans Ces bonnes pratiques contribuent globalement à la qualité d un logiciel Mesures de la qualité d un logiciel La mesure de la qualité d un logiciel peut se faire selon plusieurs dimensions, qui ne relèvent pas toutes de la vérification. 4

11 En termes opérationnels, la qualité se mesure selon les axes suivants : correction, fiabilité, sûreté : le logiciel réalise-t-il les fonctions demandées et à quel niveau? intégrité, sécurité : résiste-t-il aux attaques intentionnelles ou aux maladresses de l utilisateur? efficacité, performance : quelles ressources le logiciel requiert-il (temps, mémoire)? facilité d utilisation La vérification se préoccupe principalement de la correction, fiabilité, sûreté voire sécurité du logiciel. Les aspects de performance peuvent également être vérifiés (par exemple politique d ordonnancement et analyse du pire temps d exécution pour les logiciels temps-réel). La qualité du logiciel se mesure également en terme de facilité de développement et d évolution, qui jouent un rôle important du point de vue de l aspect pratique de la vérification, et de la vérification des évolutions d un logiciel : maintenabilité : facilité à détecter et corriger des erreurs flexibilité : facilité à faire évoluer le logiciel ou l adapter testabilité : facilité à dérouler une campagne de test A titre informatif, la qualité d un logiciel peut également être évaluée sous l angle de l intégration : interopérabilité : capacité à interagir avec d autres systèmes réutilisabilité de tout ou partie portabilité vers d autres plateformes (OS, application, micro-contrôleurs... ) Qualité et CMMI Sans vouloir entrer dans le détail, un certain nombre de modèles d organisation de la politique de qualité (du logiciel ou plus généralement du système) ont émergé depuis ans. On peut citer le modèle CMMI (Capability Maturity Model + Integration) ou «modèle intégré du niveau de maturité» développé à l université de Carnegie Mellon pour le ministère de la défense des Etats-Unis. Il décrit cinq niveaux de maturité d une organisation, qui mesurent 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. A titre d exemple : niveau 1 : «l ère des héros» (tout repose sur le développeur) niveau 2 : plus classique, le chef de projet joue un rôle important, le management et les ingénieurs ont une idée de l avancement global du projet qui peut être mesuré quantitativement... niveau 3 : l entreprise dispose d un référentiel qui permet de capitaliser l expérience acquise lors des projets niveau 4 : gestion quantitative des processus (on fait des statistiques pour repérer les problèmes) niveau 5 : on optimise en permanence les processus sur la base des analyses statistiques 5

12 Introduction Répartition des efforts dans le domaine logiciel Le tableau qui suit décrit l évolution de la répartition des efforts (pour chaque étape du cycle en V) dans l industrie du logiciel au cours du temps. capture des exigences conception préliminaire conception détaillée codage test unitaire test d intégration années % 80% 10% années 80 20% 60% 20% années 90 40% 30% 30% test système Quelques remarques concernant cette évolution : il y a eu une prise de conscience par l industrie du logiciel du coût élevé de la vérification tardive : l effort global s est réparti plus amont cette prise de conscience a favorisé l émergence de modèles de conception et de langages de spécifications, qui en retour a favorisé l investissement dans l effort de conception les systèmes étant de plus en plus gros et intégrés, les phases de test d intégration et de test systèmes sont devenues plus coûteuses le test est maintenant vu comme une activité à part entière, au coût toujours conséquent (un tiers du coût total) la phase de capture des exigences nécessite un effort important et souvent incompressible, notamment du fait de la complexité des systèmes produits 1.3 Vérification et méthodes formelles Vérification Formelle : définition Par vérification formelle d un logiciel, on entend la vérification mathématique «exhaustive» de sa correction. On cherche à prouver au sens mathématique que l implantation (vue comme un modèle logique) satisfait à sa spécification (vue par exemple comme un ensemble de formules logiques). La vérification formelle est une activité complexe. Tout d abord, il y a la difficulté technique d extraction d un modèle depuis un programme ou de formules logiques depuis des spécifications (souvent semi-formelles). Cette extraction doit se faire de manière sûre bien entendu. Mais la difficulté principale est d arriver à faire la preuve que le modèle extrait satisfait bien aux formules qui correspondent à la spécification requise. Pour un programme autre qu un programme jouet, envisager une preuve manuelle complète est souvent tout à fait hors de question, la taille du modèle étant rédhibitoire. La preuve automatique à l aide d un ordinateur est quant à elle un problème tout à fait indécidable (il n y a pas de logiciel magique qui serait capable de prouver automatiquement la correction de tout logiciel). Le problème ne pouvant être résolu dans toute sa généralité, divers choix et techniques se présentent pour le simplifier. La vérification formelle consiste généralement en la combinaison de ces diverses techniques présentées ci-après. 6

13 1.3.2 Vérification par sous-approximation : le test L idée est de ne pas faire une vérification exhaustive du logiciel, mais d essayer de mettre le modèle en défaut par rapport à une propriété de la spécification. Le test peut s effectuer sur le logiciel final, ou des sous-parties du logiciel (modules, fonctions), ou sur des modèles du logiciel. La qualité première du test est de permettre de révéler des défauts avec une grande précision et à moindre coût, mais jamais de garantir qu il n y ait aucun défaut. La difficulté du test est de parvenir à un ensemble de tests (ou suite de tests) suffisamment pertinent pour se convaindre de la correction du logiciel. Il est impossible de prouver qu un programme est correct en n utilisant que des techniques de test, puisqu il s agit d une technique qui explore seulement une sous-approximation des comportements. Il est donc important de pouvoir mesurer la qualité d une suite de tests, ce qui se fait généralement en terme de couverture d un certain critère. Les critères les plus courants au niveau du test de code sont le taux de couverture des instructions ou des branches (décisions). De nombreux auteurs considèrent que le test n est pas une technique de vérification formelle à proprement dit, puisqu il ne permet pas à lui seul de conclure. Il reste qu il s agit de la technique de vérification la plus universellement adoptée, la moins coûteuse en terme de défauts trouvés par rapport à l effort investi, et la mieux outillée (environnement de tests comme JUnit, automatisation des tests) Vérification par sur-approximation : techniques d abstraction La complexité d un logiciel est liée à la complexité des comportements associés, généralement corrélés à sa taille, mais pas uniquement. La présence de boucles, l utilisation de structures de données ayant des invariants complexes, le recours à des types de données flottants contribuent parmi d autres à la complexité du logiciel. Cette complexité se reflète dans ce qui est appelé la sémantique opérationnelle du programme, qui définit un système de transitions généralement infini décrivant l ensemble des traces d exécution possibles (séquence des états mémoire). L idée générale est d abstraire ce système de transition par un système «essentiellement fini», qui en soit une sur-approximation (toutes les traces d exécutions sont représentées). Il est alors possible d essayer de prouver les propriétés requises sur cette vue abstraite, simplifiée par rapport à la vue concrète de la sémantique opérationnelle. Le point crucial est qu une propriété prouvée sur la vue abstraite sera correcte sur la vue concrète. En revanche, une propriété qu on n arrive pas à prouver sur l abstraction ne sera pas forcément incorrecte sur la vue concrète, puisque la sur-approximation a pu introduire des comportements illicites du point de vue de la propriété à prouver mais qui n existaient pas initialement. Il existe différentes techniques travaillant par sur-approximation. Interprétation abstraite : il s agit d un cadre général qui permet d associer une sémantique abstraite à un programme qui soit une généralisation de sa sémantique concrète, ceci en fixant un domaine abstrait de représentation des traces d exécutions. On peut par exemple choisir un domaine abstrait de représentation des variables (ex : intervalles), et choisir d abstraire un chemin d exécution par le point de contrôle qu il at- 7

14 Introduction teint. Il s agit d un cadre particulièrement adapté à la preuve automatique de l absence de «runtime-errors» : division par zéro, dépassement de capacité, accès hors bornes d un tableau, déréférencement d un pointeur invalide. Il permet en effet de traquer avec une grande précision les valeurs potentielles qu une variable peut prendre en chaque point du graphe de contrôle. Dans les faits, une grande expertise est requise pour obtenir au final une abstraction fidèle du programme initial, sans trop de faux positifs (valeurs du domaine abstrait posant problème et ne correspondant à aucune exécution concrète), et sans utiliser dès les départ des domaines trop précis dont le coût lors de l analyse devient prohibitif (en temps et mémoire). Exemples d outils industriels : Frama-C 5, Polyspace Verifier 6, Astrée 7. Model checking : il s agit cette fois de choisir un certain type de modèle (généralement à base d automates finis étendus avec des types de données simples) pour lequel il existe un algorithme permettant de vérifier la classe de propriétés visées (souvent exprimées en terme de logique temporelles, décrivant des enchaînements complexes d actions). Une première difficulté est de parvenir à abstraire le logiciel vers ce type de modèle, automatiquement dans l idéal. Les limitations fortes sur le pouvoir d expression des modèles obligent souvent à des abstractions relativement grossières. Une autre difficulté majeure est le problème du passage à l échelle en fonction de la taille du modèle et de la complexité de la propriété à vérifier, les algorithmes de vérification étant en général exponentiels. Les outils de model checking existant sont plutôt issus du monde académique (Spin 8, Uppaal 9 en est un exemple). De manière générale, toutes les techniques dites d analyse statique (analyse d un logiciel à partir de ses sources) travaillent par sur-approximation. Par exemple : algorithmes de calcul de dépendances de données et autres algorithmes dataflow utilisés dans les compilateurs Vérification par la preuve assistée La preuve assistée de programme a fait des progrès considérables ces dernières années, notamment grâce au développement d assistants de preuves ambitieux (comme Coq développé à Orsay 10 ) qui intègrent des procédures de décision efficaces (preuve automatique, généralement sur des logiques du premier ordre sans quantification ; voir par exemple le prouveur Z3 de Microsoft Research 11 ). L expertise de l utilisateur chargé de prouver le programme joue bien entendu un rôle primordial. Il ne s agit pas de travailler directement sur le programme à prouver au niveau de l assistant de preuve (problème de sa représentation dans la théorie choisie), mais sur des formules extraites du programme (obligations de preuves), de préférence de manière automatisée. Cette extraction peut se faire en utilisant des techniques de calcul de précondition «la plus faible» à la Hoare, qui permet de calculer (semi-)automatiquement à partir d un prédicat à prouver en un point du programme la précondition à vérifier

15 en entrée de la fonction englobante. La principale difficulté est le passage des boucles du programme, pour lesquelles l utilisateur doit fournir un invariant, qui permet d abstraire le comportement de la boucle. Les alias (plusieurs manières d identifier la même location mémoire, par exemple via des pointeurs) sont également source de difficulté (complexité du modèle mémoire sous-jacent), et leur traitement correct nécessite en général des analyses dédiées (de type interprétation abstraite ou autre). La méthode B fournit un environnement qui comporte en particulier un assistant de preuve dédié. Voir aussi Jessie et Why Vérification formelle dans l industrie Si certains industriels utilisent des techniques de développement/vérification formelles au cœur de leur métier (par exemple Siemens Transportation Systems et l atelier B, Airbus et l outil Caveat développé au CEA LIST... ), et que le model checking connaît un réel succès dans la vérification de matériel (au sens : description de circuits intégrés), il y a encore beaucoup de chemin à parcourir pour que la vérification formelle pénètre plus largement certains domaines de l industrie (secteur automobile par exemple). Une des difficultés vient du fait que l offre en terme d outils logiciels de support à la vérification reste faible ou impose un processus de développement relativement spécifique (méthode B, outil Scade 13 ). Il est en particulier difficile de trouver un ensemble de modèles suffisamment riches pour représenter un système complet et ceci à tous les niveaux de conception, tout en gardant une grande liberté sur le choix des technologies (architecture matérielle, bus de communication, langage de programmation, OS temps-réel) mais aussi organisation de l entreprise en terme de processus métiers (seule une petite partie des intervenants sont des ingénieurs logiciels). Si l offre est relativement faible, c est aussi que la preuve de logiciel automatisée était encore jusqu à récemment essentiellement confinée au domaine académique (preuve d algorithmes plutôt que d implantations), même si les récents progrès notamment sur les solveurs permettent d envisager un élargissement de l offre. Du point de vue du test (technique par sous-approximation), il s agit d une technologie largement répandue et réputée très efficace pour la recherche de défauts, notamment lorsque l activité de test est structurée, systématisée et automatisée. Les environnements de test unitaire (comme JUnit 14 pour Java) ont connu un réel essort, et des techniques complexes de génération de tests sur des critères structurels sont en train de se concrétiser dans des outils grand public (outil Pex 15 de Microsoft Research). En parallèle se développent des langages de spécification (JML 16, ACSL 17 ) qui permettent par exemple de spécifier des pré/post-conditions et des invariants en annotant le code source, servant à la fois à des techniques de vérification dynamique (vérification à l exécution des assertions) ou de passerelle vers des assistants de preuve

16 10

17 Chapitre 2 Test de Logiciel 2.1 Généralités sur le test Importance du test Le test est une activité cruciale dans le monde du logiciel, comme l attestent les données chiffrées suivantes : le poids de l activité du test dans l industrie du logiciel aux USA s élève à plusieurs dizaines de milliards de dollars par an en moyenne, le test représente 30 % du coût de développement d un logiciel standard pour un logiciel critique (avionique, nucléaire, médical, transport), cette part moyenne monte à 50 % Le test est l activité de V&V dominante, la phase remontante du cycle en V correspond principale à l exécution de tests. Même si un code a été prouvé formellement, le tester reste indispensable : notamment car on teste l implantation (ce qui va réellement s exécuter, dans l environnement réel d exécution) alors qu on ne prouve que des modèles. Cf. cette citation de Donald Knuth : «Beware of bugs in the above code ; I have only proved it correct, not tried it». Enfin, le test est la technique la moins coûteuse et la plus efficace pour capturer une grande partie des défauts d implantation (bugs) et on ne peut donc pas s en priver Test : définitions et propriétés Quelques définitions classiques : Le test est l exécution ou l évaluation d un système ou d un composant par des moyens automatiques ou manuels, pour vérifier qu il répond à ses spécifications ou identifier les différences entre les résultats attendus et les résultats obtenus 1. Tester, c est exécuter le programme dans l intention d y trouver des anomalies ou des défauts 2. 1 IEEE (Standard Glossary of Software Engineering Terminology) 2 G. Myers (The Art of Software Testing, 1979) 11

18 Test de Logiciel L important est de retenir que le test est une méthode de vérification partielle : le test exhaustif d un programme en injectant toutes les entrées possibles n est en général pas possible. On ne prouve pas qu un programme est correct par le test seul. Testing can only reveal the presence of errors but never their absence 3. Tester sert avant tout à améliorer la qualité du logiciel, ce qui permet de réduire les coûts de développement et de maintenance, mais également de potentiellement sauver des vies. Des tragédies comme le crash d un Airbus A320 ou des surexpositions mortelles à des radiations lors d examens médicaux sont directement liées à des défauts logiciels. Tester consiste à stimuler un maximum des comportements d un logiciel, en gardant à l esprit qu on cherche à minimiser le nombre de tests (et surtout leur redondance) et à maximiser leur pertinence (en exécutant des tests révélant des défauts réellement impactant). Le test est une méthode dynamique, dans la mesure où l on exécute réellement le programme, contrairement aux techniques par analyse statique, où seul le source est examiné pour déterminer la correction du programme Infrastructure de test L infrastructure de test est l ensemble des outils et processus permettant de mettre en œuvre une politique de test. La qualité d une infrastructure de test se mesure selon les critères suivants : temps de détection des défauts après leur introduction (le plus court étant le mieux). Des tests pertinents doivent être écrits et exécutés dans un délai très court après l introduction de nouveau code. précision sur la détermination de l origine d un défaut. L échec d un test doit fournir un retour suffisant pour que l origine du problème puisse être tracée précisément. capacité à caractériser l impact système d un défaut. Celà permet de classifier la correction des défauts par ordre de priorité. Le coût induit par des infrastructures de test inadéquates du point de vue de ces critères est estimé à plusieurs dizaines de milliards de dollars par an Perspectives du test Le test comme technique permettant de trouver des défauts (defect testing) a déjà beaucoup été évoqué. Idéalement, cette recherche de défauts se fait au plus tôt, en parallèle du développement. C est particulièrement aisé et conseillé à un niveau «test unitaire», le développeur écrivant les tests en parallèle de la fonction qu il code (quelquefois avant, cf. test driven development, souvent juste après), et s aidant de ces tests pour corriger les bugs rencontrés jusqu à satisfaction. Le test est donc vu comme un moyen de mettre le programme en défaut (test-to-fail) et l on aboutit naturellement à l obtention d une suite de tests de non-régression. Les suites de tests étant écrites par le développeur, on parle aussi de test «boîte blanche» car le développeur à non seulement connaissance de la spécification de la fonction mais 3 E. W. Dikjstra (Notes on Structured Programming,

19 également de son implantation. On peut jauger la qualité de cette suite par sa capacité à capturer des défauts lors des évolutions du code, lorsque l implantation évolue mais que les interfaces et spécifications restent les mêmes. Le test peut également être vu comme un processus d assurance qualité (validation testing) voire comme participant à la certification du logiciel. L idée est de contrôler la qualité d un logiciel, pour soi ou un tiers (autorité de certification), dans la phase ascendante du cycle en V, généralement en boîte noire (connaissance des spécifications mais pas de l implantation du logiciel), et par des équipes dédiées (la DO178B peut par exemple exiger que ces tests soient effectués par des équipes distinctes des développeurs). Cette utilisation du test est typique dans les industries développement des systèmes embarqués critiques. Le test est alors vu comme un moyen de confirmer le bon fonctionnement du logiciel (test-to-pass). 2.2 Processus de test Le processus de test est la façon dont le test est mis en œuvre Quelques définitions Un scénario de test correspond à un chemin fonctionnel (issu des spécifications) que l on cherche à exercer. Il s agit de définir une suite d actions (les entrées du test) ainsi que l ensemble des réponses censées être déclenchées en retour. Le domaine des entrées d un programme est l ensemble de ses entrées possibles : variables globales, paramètres de fonctions, actions venues de l extérieur... Chaque entrée est associée à un domaine de valeurs possibles (domaine de définition), qui est un sous-ensemble du domaine de valeurs que définit le type de l entrée. Les données de test associent à chaque entrée d un programme une valeur choisie dans son domaine de définition, ceci dans l optique d exercer un scénario de test. Un oracle est un mécanisme permettant de décider la réussite d un scénario de test, c est à dire de déterminer si les réponses obtenues à l exécution du test correspondent bien à ce que requiert le scénario. Un cas de test est l association d un scénario de test, des données de test le déclenchant et d un oracle décidant de sa réussite. Il s agit donc d une étape dans la concrétisation d un scénario de test. Un script de test est un mécanisme (en général un programme dédié ou un script shell) en charge d exécuter les cas de tests qui ont été définis pour le logiciel sous test, et de recueillir les résultats (on parle aussi de verdict de test, suivant que l oracle soit satisfait ou non pour chaque cas de test) Oracle de test : un exemple Supposons qu il faille implanter un oracle de test pour un tri rapide de type quicksort. Une première possibilité est d implanter un tri plus simple, comme un tri par insertion ou un tri-bulles. Le résultat du tri rapide doit correspondre exactement au résultat du tri simple sur tout tableau en entrée (la détermination de l ensemble des tableaux à 13

20 Test de Logiciel considérer comme données de test est un autre problème). La vérification de l oracle est donc simple, la difficulté principale étant de fournir une implantation du tri simple qui soit correcte. Pour pallier au problème d avoir à fournir une implantation alternative d un tri, il est également possible de faire appel à une fonction de tri de la bibliothèque standard, que l on peut a priori supposer correcte. Pour le langage C on dispose par exemple du tri rapide générique suivant : void qsort (void *array, size_t count, size_t size, comparison_fn_t compare) La difficulté est alors simplement de comprendre la façon dont cette fonction doit être appelée (ici, la taille du tableau, la taille de chaque élément et une fonction de comparaison entre éléments doivent être fournis). Enfin, on peut également remarquer qu implanter un oracle est souvent plus facile qu implanter la fonction à réaliser (vérifier qu une solution est correcte s avère souvent plus facile que de construire une solution). Ici, on peut par exemple vérifier que le tableau en sortie est trié dans l ordre qui convient (ce qui est facile), et qu il comporte exactement les mêmes éléments que le tableau en entrée, avec le même nombre d occurrences (plus difficile) Process simplifié du test Le processus de test suit les étapes suivantes : 1. identification des scénarios à tester 2. détermination des oracles de chaque scénario 3. génération (manuelle ou automatique) des données de test de chaque scénario : on dispose alors d une suite de cas de test couvrant tous les scénarios 4. création et exécution d un script de test évaluant le programme sur l ensemble des cas de tests 5. comparaison des résultats obtenus aux oracles 6. émission d un rapport de test décrivant les cas de tests ayant réussis et ceux ayant échoués L identification des scénarios à tester s effectue lors de l élaboration des plans de test, en parallèle des phases de conception et de codage correspondantes. 14

21 La détermination des sorties attendues se fait de manière conjointe, mais les oracles utilisés au final nécessitent généralement d être concrétisés de manière plus précise que cela n est possible en conception. Il faut en particulier être capable de traduire les entrées, sorties et observables tels que définis au niveau des spécifications en tant qu éléments concrets de l implantation finale. La génération des données de test, qu elle soit manuelle ou automatique, constitue une activité à part entière du test, et fera l objet d un chapitre spécifique. L activité d exécution des tests prend place lors de la phase remontante du cycle en V, au contraire des activités précédentes. Evidemment un constat d échec à ce niveau implique des corrections sur le code, la conception ou les spécifications du système suivant la phase de test où l on se trouve alors. La conception des tests eux-mêmes peut bien évidemment être en cause. La capacité à émettre des rapports de test informatifs est cruciale afin de pouvoir détecter le plus précisément possible l origine de la divergence constatée Scripts de test Un script de test peut schématiquement être décomposé de la manière suivante : Préambule : le programme est amené dans la configuration voulue pour un ou plusieurs cas de test, ceci en appelant un certain nombre de fonctions d initialisations et de constructeurs. Il peut par exemple s agir d allouer un certain nombre d objets ayant certaines dépendances, d initialiser les tables d une base de données avec certaines entrées, d émettre ou de recevoir un ensemble de messages dans le cadre d un protocole... Corps : le script exécute les fonctions sous test avec les données de test qui ont été générées. Identification (facultatif) : le script peut effectuer un certain nombre d opérations d observation qui vont permettre de faciler l évaluation de l oracle. Le scénario de test peut en effet nécessiter d observer des actions effectuées en cours d exécution du test, et non pas simplement le résultat final. Le script de test doit donc permettre de tracer les actions requises, ou de voir l évolution des valeurs de certaines variables globales. Cela n est possible que si le programme sous test rend ces données effectivement observables. Postambule : le script réinitialise le programme dans un état initial, par exemple l état obtenu juste après exécution du préambule, ceci afin de permettre d enchaîner avec les tests restant. Il peut par exemple s agir d effectuer un rollback des requêtes émises par le corps du test dans le cadre du test d une base de données Environnement de test unitaire Il s agit d un environnement (généralement une bibliothèque) qui permet de faciliter l écriture, la maintenance ou l exécution des tests unitaires, et éventuellement l évaluation de leur qualité (couverture de tests). Un tel environnement réalise tout ou partie du travail que l on peut attendre d un script de test, sans le caractère ad hoc que peut avoir un script fait maison. On peut citer à titre d exemples : JUnit pour Java (il existe l équivalent pour C#), et FORT pour Objective Caml (Framework for OCaml Regression Testing). 15

22 Test de Logiciel Les caractéristiques principales d un environnement de test unitaire sont : le code de test est développé dans des fichiers distincts du code de développement, qui n est donc en aucun cas modifié par l ajout de tests (requis pour les systèmes critiques) les préambules, corps et postambules sont des fonctions virtuelles à définir dans les classes implantant effectivement les cas de test (généricité) l oracle est implanté par l utilisateur en utilisant tout la puissance du langage de base, ainsi que des facilités offertes par l environnement de test l environnement de test peut proposer un environnement d exécution facilitant la mesure de la qualité des tests (sous forme de couverture atteinte). Voir le TP1 pour un exemple d environnement jouet de test unitaire Mesure de la qualité d une suite de tests Une infrastructure de test adéquate doit permettre de pouvoir aboutir à l obtention de suites de tests pertinentes. L objectif principal est d obtenir une suite de tests dont le taux de couverture est élevé, ce qui indique qu une bonne proportion des comportements du logiciel est testée. La couverture se mesure souvent sur la base de critères liés à la structure du programme (flot de contrôle et de données), comme par exemple le taux d instructions, de branches ou de paires définition-utilisation effectivement exécutées. On peut également baser la mesure de couverture sur le taux de détection de mutants du logiciel sous test. Un mutant est un quasi-clone du programme, dans lequel seul un petit nombre d instructions (souvent une seule) a été modifié. On peut par exemple choisir de remplacer un opérateur de comparaison < par ou un = par un. Les transformations effectuées pour obtenir les mutants se basent sur un modèle des fautes les plus probables commises par le programmeur, fautes qui devraient être à même d être capturées par les cas de tests. Outre la qualité de couverture obtenue, une deuxième caractéristique importante est de disposer d une suite de tests de taille raisonnable et comportant peu de tests redondants (c est à dire des paires de cas de test dont l apport en terme de couverture est équivalent). Réduire le nombre de tests permet de réduire le coût d écriture, d exécution et de maintenance des tests. Les critères de couverture principaux seront détaillés dans le chapitre suivant. 2.3 Caractérisations de l activité de test Typologie Afin de caractériser l activité de test, diverses dimensions sont à prendre en compte : A partir de quoi les tests sont-ils générés? Les cas de test peuvent être issus de la spécification seule : on parle alors d approche «boîte noire», car l implantation est vue comme une boîte noire dont seules les entrées et les sorties sont connues. Lorsque les cas de test sont déterminés en s aidant du code 16

23 source et la connaissance de la mécanique interne du logiciel, on parle au contraire d approche «boîte blanche». Un test issu des spécifications est aussi appelé un test fonctionnel : le but du cas de test est de mettre en avant de manière explicite une fonctionnalité du système apparaissant dans la spécification. Un test issu du code source est le plus souvent un test structurel, puisque la création du cas de test se fait sur la base des chemins d exécution associés au code (ou d autres éléments structurels, comme le fait de chercher à atteindre une instruction particulière dans un état-mémoire donné). On associe généralement le test boîte noire avec le test fonctionnel, et le test boîte blanche avec le test structurel. A quel niveau du cycle de développement se trouve-t-on? Les cas de tests sont élaborés (plans de test) lors de la partie descendante d un cycle en V typique, en parallèle des phases de spécification, conception, et de codage. L exécution des tests se fera dans chacune des phases de la partie remontante du cycle, sur la base des cas de tests élaborés dans la phase jumelle de la partie descendante. On parle alors de test unitaire, de test d intégration, de test système (ou de test de conformité). Quel est l objectif du test? Dans ce cours, l activité de test est principalement vue comme une façon d améliorer la correction fonctionnelle et la sûreté d un logiciel, en parallèle d activités de vérification formelle. Mais le test est également le principal moyen pour évaluer un système du point de vue de sa résistance aux attaques (sécurité), au stress ou à la charge, et du point de vue de sa performance (temps de réponse) et de son ergonomie. Certains types de test ont pour objectif de fournir une aide au développement. Le test de non-régression est un process facilitant l écriture et l exécution de tests unitaires à des fins de détection rapide de défauts logiciels introduits en cours de développement. Le test-driven development est une technique de développement agile qui utilise les tests unitaires comme guide du développement. Quelle est la technologie de génération des données de test? La réalisation concrète des cas de test nécessite de créer des données de test à même de solliciter les scénarios de test correspondants. Différentes techniques manuelles ou automatiques coexistent pour sélectionner les données de test, suivant la nature du logiciel à tester et le fait que la sélection des tests se fasse en boîte blanche (test mutationnel, 17

24 Test de Logiciel test «symbolique») ou noire (test combinatoire, test aux limites, test mutationnel). Ces technologies seront décrites plus en détail dans le chapitre suivant. Teste-t-on le code ou un modèle du code? La communauté du model-based testing focalise son attention sur le test de modèles de conception, généralement à base d automates finis, qui se prêtent bien aux techniques de génération automatique de tests structurels par des méthodes symboliques. Dans ce cours on se concentre davantage sur le test de code source, étant entendu que les techniques de génération de tests qui seront vues peuvent être adaptées à des modèles à base d automates. En outre, la vérification de modèles à base d automates finis a fait l objet d un travail considérable : cf. le cours de model checking Test Fonctionnel, Test Structurel La détermination des cas de test est une part essentielle du test. On parle également de génération, ou sélection, de cas de test. On peut classifier les différentes techniques permettant de déterminer les cas de test en deux grandes familles : le test fonctionnel et le test structurel. Test fonctionnel : On parle de test fonctionnel lorsque le cas de test est conçu à partir des spécifications du logiciel (par exemple les cas d utilisation définis par UML). Le concepteur du test n a pas accès au code source ou a choisi de ne pas regarder la façon dont le logiciel a été écrit : c est pour celà qu on parle également de test en boîte noire. Il s agit principalement d évaluer dans quelle mesure les fonctionnalités que les spécifications requièrent du système sont réalisées. Test structurel : le cas de test est conçu en partant du code source (on parle également de test en boîte blanche). Le testeur essaie de mettre en évidence la façon dont l implantation a réalisé la fonctionnalité requise en terme d éléments de programmation 18

25 (structures de contrôle notamment), et écrit les tests en fonction des chemins d exécution qu il veut voir sollicités. Il est évidemment nécessaire d avoir accès au code source et d être capable de le comprendre de manière détaillée. Le test fonctionnel ne se basant que sur les spécifications, normalement plus directement compréhensibles que le code, l écriture de cas de test s en trouve facilitée, et ils ont un sens fonctionnel généralement assez évident. De même, la détermination des oracles est en général simple car explicite dans la spécification. En revanche, les spécifications n étant pas toujours formelles ou très précises, il peut être difficile de concrétiser les données de test ou de réaliser effectivement l oracle sans passer par une analyse approfondie des documents de conception. En essence, on ne teste que les fonctionnalités attendues du programme, et il est peu probable de mettre à jour des fonctionnalités cachées ou des erreurs à l exécution non triviales sans les rechercher explicitement. Le test structurel étant déterminé à partir du code source, la réalisation du script de test s en trouve facilitée. En revanche la détermination de l oracle peut poser des difficultés : un test sollicite un chemin dont la sémantique en termes fonctionnels demande potentiellement beaucoup d investissement de la part du testeur. De plus, des fonctionnalités de haut niveau relativement claires au niveau des spécifications peuvent être difficiles à retrouver au niveau de l implantation. Il va de soit que le test fonctionnel et le test structurel sont complémentaires Phases du test Le test unitaire a pour objectif de tester les procédures, modules, ou autres composants (classes dans un contexte orienté object) en isolation. La plus grande partie des techniques de détermination des cas de tests seront décrites dans le cadre des tests unitaires. Les tests d intégration servent à tester le comportement obtenu lors de la composition de procédures et modules pour former des sous-systèmes, qui réalisent des fonctionnalités de plus haut niveau. Enfin les tests système / d acceptation / de conformité permettent de valider le comportement fonctionnel du code par rapport aux spécifications générales du système, ainsi que sa conformité aux exigences. Les modèles en spirale recommandent de développer l application finale par des incréments conduisant tous à des prototypes intermédiaires réalisant une partie toujours croissante des fonctionnalités demandées. Le processus de test évolue alors en fonction de l étape du développement. Les premières étapes se focalisent sur l écriture d un plan de test qui évoluera tout au long du développement en spirale, ainsi que sur l écriture de tests unitaires et d intégration qui seront raffinés dans les étapes ultérieures, tout comme le seront les exigences et les spécifications. Lorsque les exigences se stabilisent, les tests sytème et d acceptation sont introduits. Les processus de développement et de test agiles et plus précisément le développement orienté par les tests lient très fortement les activités de développement et de test. Les exigences sont spécifiées sous forme de tests, et le code de test est souvent écrit avant le code applicatif. 19

Processus d Informatisation

Processus d Informatisation Processus d Informatisation Cheminement de la naissance d un projet jusqu à son terme, deux grandes étapes : Recherche ou étude de faisabilité (en amont) L utilisateur a une idée (plus ou moins) floue

Plus en détail

Description et illustration du processus unifié

Description et illustration du processus unifié USDP Description et illustration du processus unifié Définit un enchaînement d activités Est réalisé par un ensemble de travailleurs Avec des rôles, des métiers Avec pour objectifs de passer des besoins

Plus en détail

Les méthodes formelles dans le cycle de vie. Virginie Wiels ONERA/DTIM Virginie.Wiels@onera.fr

Les méthodes formelles dans le cycle de vie. Virginie Wiels ONERA/DTIM Virginie.Wiels@onera.fr Les méthodes formelles dans le cycle de vie Virginie Wiels ONERA/DTIM Virginie.Wiels@onera.fr Plan Introduction Différentes utilisations possibles Différentes techniques pour différentes propriétés à différents

Plus en détail

Le génie logiciel. maintenance de logiciels.

Le génie logiciel. maintenance de logiciels. Le génie logiciel Définition de l IEEE (IEEE 1990): L application d une approche systématique, disciplinée et quantifiable pour le développement, l opération et la maintenance de logiciels. Introduction

Plus en détail

Projet Informatique. Philippe Collet. Licence 3 Informatique S5 2014-2015. http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415

Projet Informatique. Philippe Collet. Licence 3 Informatique S5 2014-2015. http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415 Projet Informatique Philippe Collet Licence 3 Informatique S5 2014-2015 http://deptinfo.unice.fr/twiki/bin/view/linfo/projetinfo201415 Réalisation d'un développement de taille conséquente? r Firefox? Ph.

Plus en détail

Méthodes de test. Mihaela Sighireanu

Méthodes de test. Mihaela Sighireanu UFR d Informatique Paris 7, LIAFA, 175 rue Chevaleret, Bureau 6A7 http://www.liafa.jussieu.fr/ sighirea/cours/methtest/ Partie I 1 Propriétés 2 Un peu de génie logiciel de test 3 Eléments Problèmes Point

Plus en détail

Développement itératif, évolutif et agile

Développement itératif, évolutif et agile Document Développement itératif, évolutif et agile Auteur Nicoleta SERGI Version 1.0 Date de sortie 23/11/2007 1. Processus Unifié Développement itératif, évolutif et agile Contrairement au cycle de vie

Plus en détail

Génie logiciel Test logiciel A.U. 2013/2014 (Support de cours) R. MAHMOUDI (mahmoudr@esiee.fr) 1 Plan du chapitre - Définition du test logiciel - Principe de base du test logiciel - Les différentes étapes

Plus en détail

Les Bonnes PRATIQUES DU TEST LOGICIEL

Les Bonnes PRATIQUES DU TEST LOGICIEL Les Bonnes PRATIQUES DU TEST LOGICIEL SOMMAIRE Qu est-ce que le test logiciel? Pourquoi le test est-il un maillon crucial de l ingénierie logicielle? Quels sont les différents types de tests? Qu est-ce

Plus en détail

FICHE JANVIER 2009 THÉMATIQUE. Direction de projets et programmes

FICHE JANVIER 2009 THÉMATIQUE. Direction de projets et programmes FICHE JANVIER 2009 THÉMATIQUE Direction de projets et programmes La représentation par les processus pour les projets Système d Information (SI) La modélisation de l'entreprise par les processus devient

Plus en détail

CONCEPTS ET MISE EN PRATIQUE POUR LA VALIDATION DE GRANDS SYSTÈMES

CONCEPTS ET MISE EN PRATIQUE POUR LA VALIDATION DE GRANDS SYSTÈMES MODEL-BASED TESTING (MBT) CONCEPTS ET MISE EN PRATIQUE POUR LA VALIDATION DE GRANDS SYSTÈMES Le Model-Based Testing est une pratique de test en plein développement dans l'industrie pour accroitre l'efficacité

Plus en détail

COMPLIANCE Consulting. Gardez la Maîtrise de vos Exigences. 18 mai 2011

COMPLIANCE Consulting. Gardez la Maîtrise de vos Exigences. 18 mai 2011 COMPLIANCE Consulting Gardez la Maîtrise de vos Exigences 18 mai 2011 Présentation Société Société Société de conseil spécialisée dans le transfert de technologies en matière de processus, de méthodes

Plus en détail

Bienvenue dans le monde de la construction logicielle

Bienvenue dans le monde de la construction logicielle Chapitre 1 Bienvenue dans le monde de la construction logicielle Sommaire : 1.1 La construction logicielle, qu est-ce que c est? : page 3 1.2 Pourquoi la construction logicielle est-elle importante? :

Plus en détail

Travaux soutenus par l ANR. Jean-François CAPURON (DGA) Bruno LEGEARD (Smartesting)

Travaux soutenus par l ANR. Jean-François CAPURON (DGA) Bruno LEGEARD (Smartesting) Travaux soutenus par l ANR Jean-François CAPURON (DGA) Bruno LEGEARD (Smartesting) 03 Avril 2012 1. Test de sécurité et génération de tests à partir de modèle 2. Le projet SecurTest à DGA Maîtrise de l

Plus en détail

Contexte et motivations Les techniques envisagées Evolution des processus Conclusion

Contexte et motivations Les techniques envisagées Evolution des processus Conclusion Vérification de logiciels par analyse statique Contexte et motivations Les techniques envisagées Evolution des processus Conclusion Contexte et motivations Specification Design architecture Revues and

Plus en détail

Modèle d implémentation

Modèle d implémentation Modèle d implémentation Les packages UML: Unified modeling Language Leçon 5/6-9-16/10/2008 Les packages - Modèle d implémentation - Méthodologie (RUP) Un package ou sous-système est un regroupement logique

Plus en détail

Modélisation des Systèmes d Information Jean-Yves Antoine

Modélisation des Systèmes d Information Jean-Yves Antoine Modélisation des Systèmes d Information Jean-Yves Antoine http://www.info.univ-tours.fr/~antoine Processus de développement logiciel Jean-Yves Antoine U. Bretagne Sud - UFR SSI - IUP Vannes année 2001-2002

Plus en détail

Machine de Turing. Informatique II Algorithmique 1

Machine de Turing. Informatique II Algorithmique 1 Machine de Turing Nous avons vu qu un programme peut être considéré comme la décomposition de la tâche à réaliser en une séquence d instructions élémentaires (manipulant des données élémentaires) compréhensibles

Plus en détail

Analyse abstraite de missions sous PILOT

Analyse abstraite de missions sous PILOT Analyse abstraite de missions sous PILOT Damien Massé EA 3883, Université de Bretagne Occidentale, Brest damien.masse@univ-brest.fr Résumé Nous étudions la possibilité de réaliser un analyseur par interprétation

Plus en détail

CTE Éditeur de classification arborescente pour spécifications du cas de test

CTE Éditeur de classification arborescente pour spécifications du cas de test Tessy Test d intégration et unitaire dynamique automatisé pour des applications embarquées CTE Éditeur de classification arborescente pour spécifications du cas de test Le meilleur outil de test unitaire

Plus en détail

6761 Validation de la conformité 21.03.2007

6761 Validation de la conformité 21.03.2007 6761 Validation de la conformité 21.03.2007 Peter DAEHNE 1 Tests de stress Les tests de stress permettent d étudier le comportement du logiciel lorsque celui-ci est mis dans des situations extrêmes, aux

Plus en détail

CCI Génie Logiciel UFR - IMA. Objectifs du cours d'aujourd'hui. Génie Logiciel Validation par le test. Qu est-ce que tester un programme?

CCI Génie Logiciel UFR - IMA. Objectifs du cours d'aujourd'hui. Génie Logiciel Validation par le test. Qu est-ce que tester un programme? Validation par le test Objectifs du cours d'aujourd'hui Donner des réponses aux questions suivantes : Lydie du Bousquet 2 Qu est-ce que tester un programme? Exercice 1 : Inscrivez sur une feuille ce que

Plus en détail

Agilitéet qualité logicielle: une mutation enmarche

Agilitéet qualité logicielle: une mutation enmarche Agilitéet qualité logicielle: une mutation enmarche Jean-Paul SUBRA Introduction : le manifeste Agile Manifeste pour le développement Agile de logiciels Nous découvrons comment mieux développer des logiciels

Plus en détail

Introduction aux Composants Logiciels

Introduction aux Composants Logiciels Introduction aux Composants Logiciels Christian Pérez LIP/INRIA Année 2010-11 Plan Introduction aux composants logiciels Pourquoi des composants logiciels Notions de composants logiciels Conclusion Survol

Plus en détail

GÉNIE LOGICIEL (SOFTWARE ENGINEERING)

GÉNIE LOGICIEL (SOFTWARE ENGINEERING) GÉNIE LOGICIEL (SOFTWARE ENGINEERING) 6ÈME PARTIE TEST DU LOGICIEL (SOFTWARE TESTING) Faculté des Sciences et Techniques http://perso.univ-st-etienne.fr/jacquene/gl/ Francois.Jacquenet@univ-st-etienne.fr

Plus en détail

Eléments pratiques de test des Hiérarchies et Frameworks

Eléments pratiques de test des Hiérarchies et Frameworks Eléments pratiques de test des Hiérarchies et Frameworks Notes de cours Christophe Dony Master Info Pro - Université Montpellier-II 1 Introduction 1.1 Définitions Génie Logiciel No 18, Mars 1990. EC2.

Plus en détail

ITIL, une approche qualité pour la gestion des services(*) informatiques. Pourquoi et comment introduire ITIL dans son organisation

ITIL, une approche qualité pour la gestion des services(*) informatiques. Pourquoi et comment introduire ITIL dans son organisation Livre blanc Le pragmatisme de votre système d information Rédacteur : Marc LORSCHEIDER / Expert ITIL Mise à jour : 05/06/2013 ITIL, une approche qualité pour la gestion des services(*) informatiques Pourquoi

Plus en détail

Cours de Génie Logiciel

Cours de Génie Logiciel Cours de Génie Logiciel Sciences-U Lyon Gestion de Projet Informatique http://www.rzo.free.fr Pierre PARREND 1 Mars 2005 Sommaire Gestion de projet informatique Cycle de vie du logiciel Modèles de Méthodes

Plus en détail

Génie logiciel. Concepts fondamentaux. Bruno MERMET, Université du Havre 1

Génie logiciel. Concepts fondamentaux. Bruno MERMET, Université du Havre 1 Génie logiciel Concepts fondamentaux Bruno MERMET, Université du Havre 1 Nécessité du Génie Logiciel Bruno MERMET, Université du Havre 2 Développement d un logiciel Caractéristiques souhaitées : Adéquation

Plus en détail

Ioannis Parissis UFR IMA Laboratoire LIG. Test logiciel

Ioannis Parissis UFR IMA Laboratoire LIG. Test logiciel Test logiciel Objectif et plan du du cours Présenter les concepts de base sur le test logiciel Introduire des techniques simples pour construire des tests A partir de la spécification informelle du programme

Plus en détail

DOCUMENTATION ASSOCIEE A UN PROJET LOGICIEL

DOCUMENTATION ASSOCIEE A UN PROJET LOGICIEL DOCUMENTATION ASSOCIEE A UN PROJET LOGICIEL 31 août 2004 Plate-Forme Opérationnelle de modélisation INRA ACTA ICTA http://www.modelia.org FICHE DU DOCUMENT 10 mai 04 N.Rousse - : Création : version de

Plus en détail

Le «data mining», une démarche pour améliorer le ciblage des contrôles

Le «data mining», une démarche pour améliorer le ciblage des contrôles MINISTERE DE L ECONOMIE ET DES FINANCES Le «data mining», une démarche pour améliorer le ciblage des contrôles La lutte contre la fraude aux finances publiques a été renforcée ces dernières années et a

Plus en détail

Les standards et la prise en compte des COTS : comment se concilient l utilisation des COTS et les normes actuelles?

Les standards et la prise en compte des COTS : comment se concilient l utilisation des COTS et les normes actuelles? Les standards et la prise en compte des COTS : comment se concilient l utilisation des COTS et les normes actuelles? L I S EDF Electricité de France technicatome THOMSON-CSF Marie-Hélène Durand Aerospatiable

Plus en détail

Des exigences aux tests Génération de tests à partir des processus et règles métier (Model-Based Testing)

Des exigences aux tests Génération de tests à partir des processus et règles métier (Model-Based Testing) Des exigences aux tests Génération de tests à partir des processus et règles métier (Model-Based Testing) Bruno LEGEARD JDEV 2013 4-6 septembre 2013 Sommaire Partie I Introduction au Model-Based Testing

Plus en détail

Systèmes temps réel Concepts de base. Richard Grisel Professeur des Universités Université de Rouen

Systèmes temps réel Concepts de base. Richard Grisel Professeur des Universités Université de Rouen Systèmes temps réel Concepts de base Richard Grisel Professeur des Universités Université de Rouen 1 Systèmes temps réel - Choix Gestion des ressources Ordonnancement ( Scheduling ), Tolérance aux fautes

Plus en détail

Méthode de Test. Pour WIKIROUTE. Rapport concernant les méthodes de tests à mettre en place pour assurer la fiabilité de notre projet annuel.

Méthode de Test. Pour WIKIROUTE. Rapport concernant les méthodes de tests à mettre en place pour assurer la fiabilité de notre projet annuel. Méthode de Test Pour WIKIROUTE Rapport concernant les méthodes de tests à mettre en place pour assurer la fiabilité de notre projet annuel. [Tapez le nom de l'auteur] 10/06/2009 Sommaire I. Introduction...

Plus en détail

Algorithmique et Analyse d Algorithmes

Algorithmique et Analyse d Algorithmes Algorithmique et Analyse d Algorithmes L3 Info Cours 5 : Structures de données linéaires Benjamin Wack 2015-2016 1 / 37 La dernière fois Logique de Hoare Dichotomie Aujourd hui Type Abstrait de Données

Plus en détail

Modélisation objet Le langage UML

Modélisation objet Le langage UML Modélisation objet Le langage UML Brahim HAMID La base de contrôle Robot Zone à explorer brahim.hamid@irit.fr brahim.hamid@univ-tlse2.fr http://mass-cara.univ-tlse2.fr/~brahimou/ens/uml 1 Les méthodes

Plus en détail

Le tableau de bord de la DSI : un outil pour mieux piloter son informatique.

Le tableau de bord de la DSI : un outil pour mieux piloter son informatique. Le tableau de bord de la DSI : un outil pour mieux piloter son informatique. Introduction Face à l évolution constante des besoins fonctionnels et des outils informatiques, il est devenu essentiel pour

Plus en détail

Correction de l examen final

Correction de l examen final IFT3902 : (Gestion de projet pour le) développement, (et la) maintenance des logiciels Correction de l examen final Yann-Gaël Guéhéneuc, cours et TPs guehene@iro.umontreal.ca Salah Bouktif, démonstrations

Plus en détail

Analyse de sûreté des systèmes informatisés : l approche de l IRSN

Analyse de sûreté des systèmes informatisés : l approche de l IRSN 02 Novembre 2009 Analyse de sûreté des systèmes informatisés : l approche de l IRSN 1 ROLE DES SYSTEMES INFORMATISES DANS LES CENTRALES NUCLEAIRES Les centrales nucléaires sont de plus en plus pilotées

Plus en détail

Logiciel libre et systèmes critiques hérésie ou réalité de demain? Philippe David European Space Agency

Logiciel libre et systèmes critiques hérésie ou réalité de demain? Philippe David European Space Agency Logiciel libre et systèmes critiques hérésie ou réalité de demain? Philippe David European Space Agency Premiers constats! Les fonctions nécessaires aux systèmes critiques sont implémentées par les LL:

Plus en détail

Projet : Plan Assurance Qualité

Projet : Plan Assurance Qualité Projet : Document : Plan Assurance Qualité 2UP_SPEC_DEV1 VERSION 1.00 Objet Ce document a pour objectif de définir la démarche d analyse et de conception objet ainsi les activités liées. Auteur Eric PAPET

Plus en détail

Méthode de tests MODE D EMPLOI POINTS IMPORTANTS

Méthode de tests MODE D EMPLOI POINTS IMPORTANTS Méthode de tests MODE D EMPLOI Cette première partie est destinée à ceux qui débutent en tests et permet une approche progressive et simple de la méthodologie des tests. L introduction vous aura permis

Plus en détail

CONSEIL STRATÉGIQUE. Services professionnels. En bref

CONSEIL STRATÉGIQUE. Services professionnels. En bref Services professionnels CONSEIL STRATÉGIQUE En bref La bonne information, au bon moment, au bon endroit par l arrimage des technologies appropriées et des meilleures pratiques. Des solutions modernes adaptées

Plus en détail

Les expériences d ERNI dans l univers du management, des processus et des technologies. Experience N 52. Mars 2012 Pas à pas vers de bonnes exigences

Les expériences d ERNI dans l univers du management, des processus et des technologies. Experience N 52. Mars 2012 Pas à pas vers de bonnes exigences Les expériences d ERNI dans l univers du management, des processus et des technologies Experience N 52 Mars 2012 OutsourcINg Pas à pas vers de bonnes exigences Outsourcing 10 11 Pas à pas vers de bonnes

Plus en détail

CRÉER UN COURS EN LIGNE

CRÉER UN COURS EN LIGNE Anne DELABY CRÉER UN COURS EN LIGNE Deuxième édition, 2006, 2008 ISBN : 978-2-212-54153-3 2 Que recouvre le concept d interactivité? Dans une perspective de cours en ligne, une activité interactive est

Plus en détail

Chapitre 2 : Cycles de vie logiciel et méthodes de développement G L & A G L 2 0 1 4 / 2 0 1 5

Chapitre 2 : Cycles de vie logiciel et méthodes de développement G L & A G L 2 0 1 4 / 2 0 1 5 Chapitre 2 : Cycles de vie logiciel et méthodes de développement G L & A G L 2 0 1 4 / 2 0 1 5 Plan Chapitre 2 Modèles de cycles de vie Méthodes de développement : Méthode lourde Méthode agile Exemple

Plus en détail

Transformation IT de l entreprise ANALYTIQUE: L ÈRE WATSON

Transformation IT de l entreprise ANALYTIQUE: L ÈRE WATSON Transformation IT de l entreprise ANALYTIQUE: L ÈRE WATSON L analytique joue un rôle désormais primordial dans la réussite d une entreprise. Les pouvoirs qu elle délivre sont incontestables, cependant

Plus en détail

Introduction au développement du logiciel

Introduction au développement du logiciel Introduction au développement du logiciel Vers le génie logiciel Université de Nantes Master Miage M1 Plan 1 Introduction 2 Génie logiciel 3 Projet informatique 4 Méthode de développement 5 Qualité Bibliographie

Plus en détail

LES OUTILS DE LA GESTION DE PROJET

LES OUTILS DE LA GESTION DE PROJET LES OUTILS DE LA GESTION DE PROJET PROJET : «ensemble des actions à entreprendre afin de répondre à un besoin défini dans des délais fixés». Délimité dans le temps avec un début et une fin, mobilisant

Plus en détail

Application industrielle de la Méthode formelle B

Application industrielle de la Méthode formelle B Application industrielle de la Méthode formelle B Guilhem Pouzancre Thierry Servat C novembre l e a r S 2005 y Contact@Clearsy.com EUROPARC de Pichaury Bâtiment C1 1330, av. Guillibert de la Lauzière 13

Plus en détail

LES SOLUTIONS MES HUMAINES METTENT EN AVANT LES INDIVIDUS

LES SOLUTIONS MES HUMAINES METTENT EN AVANT LES INDIVIDUS LIVRE BLANC LES SOLUTIONS MES HUMAINES METTENT EN AVANT LES INDIVIDUS Une collaboration entre homme et machine LIVRE BLANC LES SOLUTIONS MES HUMAINES METTENT EN AVANT LES INDIVIDUS 2 A PROPOS Les hommes

Plus en détail

PRINCIPES et METHODES de SPECIFICATION et de CONCEPTION GLOBALE des SYSTEMES INFORMATISES 10/20/02 1

PRINCIPES et METHODES de SPECIFICATION et de CONCEPTION GLOBALE des SYSTEMES INFORMATISES 10/20/02 1 PRINCIPES et METHODES de SPECIFICATION et de CONCEPTION GLOBALE des SYSTEMES INFORMATISES 10/20/02 1 CYCLE de VIE des SYSTEMES INFORMATISES Expression du besoin Développement du «système» Exploitation

Plus en détail

Les différents paradigmes de programmation

Les différents paradigmes de programmation Les différents paradigmes de programmation Un peu d histoire... Les problèmes posés par les s La programmation Un peu d histoire... Les difficultés du développement La programmation procédurale (ou impérative)

Plus en détail

IFT3903 Qualité du logiciel et métriques

IFT3903 Qualité du logiciel et métriques IFT3903 Qualité du logiciel et métriques Yann-Gaël Guéhéneuc Hiver 2006 Chapitre 2 Développement logiciel (Tiré du cours de Houari Sahraoui) GEODES Ptidej Team OO Programs Quality Evaluation and Enhancement

Plus en détail

Le génie Logiciel (suite)

Le génie Logiciel (suite) Le génie Logiciel (suite) Lors du cours précédent, on a étudié différents cycles de vie, dont la cascade, ou la spirale. Analyse des besoins L analyse des besoins est une étape menant à l élaboration de

Plus en détail

Gé nié Logiciél Livré Blanc

Gé nié Logiciél Livré Blanc Gé nié Logiciél Livré Blanc Version 0.2 26 Octobre 2011 Xavier Blanc Xavier.Blanc@labri.fr Partie I : Les Bases Sans donner des définitions trop rigoureuses, il faut bien commencer ce livre par énoncer

Plus en détail

Commission des Outils d évaluation pour les Humanités générales et technologiques. Présentation générale des outils

Commission des Outils d évaluation pour les Humanités générales et technologiques. Présentation générale des outils Commission des Outils d évaluation pour les Humanités générales et technologiques Présentation générale des outils 1. Généralités 1.1. Cadre institutionnel Le décret du 24 juillet 1997 sur les missions

Plus en détail

IFT3913 Qualité du logiciel et métriques. Chapitre 2 Modèles de processus du développement du logiciel. Plan du cours

IFT3913 Qualité du logiciel et métriques. Chapitre 2 Modèles de processus du développement du logiciel. Plan du cours IFT3913 Qualité du logiciel et métriques Chapitre 2 Modèles de processus du développement du logiciel Plan du cours Introduction Modèles de processus du développement du logiciel Qualité du logiciel Théorie

Plus en détail

Projet Industriel Identification des contraintes DO 178C en implémentant l approche «Model Based Testing» avec l aide de l outil MaTeLo

Projet Industriel Identification des contraintes DO 178C en implémentant l approche «Model Based Testing» avec l aide de l outil MaTeLo Projet Industriel Identification des contraintes DO 178C en implémentant l approche «Model Based Testing» avec l aide de l outil MaTeLo Encadrement : Mihaela BARREAU Anthony FAUCOGNEY René Christian TUYISHIME

Plus en détail

6. Des objets bien conçus

6. Des objets bien conçus Conception objet en Java avec BlueJ une approche interactive 6. Des objets bien conçus David J. Barnes, Michael Kölling version française: Patrice Moreaux Rédigé avec 1.0 Conception objet en Java avec

Plus en détail

L essentiel. Coopérative, flexible, très performante : la plateforme Engineering Base. web aucotec.com

L essentiel. Coopérative, flexible, très performante : la plateforme Engineering Base. web aucotec.com L essentiel Coopérative, flexible, très performante : la plateforme Engineering Base web aucotec.com Les défis La globalisation des structures d ingénierie avec le travail en réseau sur des sites dispersés

Plus en détail

Automatisation de la certification formelle de systèmes critiques par instrumentation d interpréteurs abstraits

Automatisation de la certification formelle de systèmes critiques par instrumentation d interpréteurs abstraits 1 d Automatisation de la certification formelle de systèmes critiques par instrumentation d sous la direction de Michaël Périn Soutenance de Thèse de Doctorat Université de Grenoble - Laboratoire Verimag

Plus en détail

2. Technique d analyse de la demande

2. Technique d analyse de la demande 1. Recevoir et analyser une requête du client 2. Sommaire 1.... Introduction 2.... Technique d analyse de la demande 2.1.... Classification 2.2.... Test 2.3.... Transmission 2.4.... Rapport 1. Introduction

Plus en détail

Management des processus opérationnels

Management des processus opérationnels Ecole Nationale Supérieure de Management Master Management des organisations Management des processus opérationnels Dr TOUMI Djamila Cours n 1: La vision processus dans le management des organisations

Plus en détail

Étapes du développement et de l utilisation d un modèle de simulation

Étapes du développement et de l utilisation d un modèle de simulation Étapes du développement et de l utilisation d un modèle de simulation Étapes du développement et de l utilisation d un modèle de simulation Formulation du problème Cueillette et analyse de données Conception

Plus en détail

Annexe 4 Programmes des classes préparatoires aux Grandes Ecoles

Annexe 4 Programmes des classes préparatoires aux Grandes Ecoles Annexe 4 Programmes des classes préparatoires aux Grandes Ecoles Filière : scientifique Voie : Technologie et biologie (TB) Discipline : Informatique Première et seconde années Programme d informatique

Plus en détail

COMMENT DÉFINIR L ORIENTÉ OBJET

COMMENT DÉFINIR L ORIENTÉ OBJET COMMENT DÉFINIR L ORIENTÉ OBJET De manière superficielle, le terme «orienté objet», signifie que l on organise le logiciel comme une collection d objets dissociés comprenant à la fois une structure de

Plus en détail

Gestion des Incidents (Incident Management)

Gestion des Incidents (Incident Management) 31/07/2004 Les concepts ITIL-Incidents 1 «Be prepared to overcome : - no visible management ou staff commitment, resulting in non-availability of resources - [ ]» «Soyez prêts a surmonter : - l absence

Plus en détail

Management des processus opérationnels

Management des processus opérationnels Ecole Nationale Supérieure de Management Master Management des organisations Management des processus opérationnels Dr TOUMI Djamila Cours n 4: l approche processus et le management du système d informations

Plus en détail

Rapprocher les méthodes formelles, l analyse statique et les tests. 29 mai 2013

Rapprocher les méthodes formelles, l analyse statique et les tests. 29 mai 2013 Rapprocher les méthodes formelles, l analyse statique et les tests 29 mai 2013 Présentation du projet Déroulement du projet Réalisations Démonstrations Perspectives Présentation du projet Déroulement du

Plus en détail

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009

GPA 789 : Analyse et Conception Orientées Objet. ETS Mickaël Gardoni Bureau A 3588 tel 84 11. Mise en Œuvre UML version du 24 avril 2009 GPA 789 : Analyse et Conception Orientées Objet ETS Mickaël Gardoni Bureau A 3588 tel 84 11 Mise en œuvre UML 1/ 25 Introduction Mise en œuvre d UML UML n est pas une méthode 2/ 25 1 UML n est qu un langage

Plus en détail

Formations Méthode et conduite de projet

Formations Méthode et conduite de projet Formations Méthode et conduite de projet Présentation des formations Qualité et Conduite de projets Mettre en place et gérer un projet SI nécessite diverses compétences comme connaître les acteurs, gérer

Plus en détail

Environnements de Développement

Environnements de Développement Institut Supérieur des Etudes Technologiques de Mahdia Unité d Enseignement: Environnements de Développement Mme BEN ABDELJELIL HASSINE Mouna m.bnaj@yahoo.fr Développement des systèmes d Information Syllabus

Plus en détail

B : Une méthode de développement de logiciels sûrs

B : Une méthode de développement de logiciels sûrs B : Une méthode de développement de logiciels sûrs Loïc PELHATE, Responsable de l Atelier des Logiciels de Sécurité de l Ingénierie du Transport Ferroviaire loic.pelhate@ratp.fr 9/11/01 1 1 Plan Contexte

Plus en détail

Développement spécifique d'un système d information

Développement spécifique d'un système d information Centre national de la recherche scientifique Direction des systèmes d'information REFERENTIEL QUALITE Procédure Qualité Développement spécifique d'un système d information Référence : CNRS/DSI/conduite-proj/developpement/proc-developpement-si

Plus en détail

L approche Bases de données

L approche Bases de données L approche Bases de données Cours: BD. Avancées Année: 2005/2006 Par: Dr B. Belattar (Univ. Batna Algérie) I- : Mise à niveau 1 Cours: BDD. Année: 2013/2014 Ens. S. MEDILEH (Univ. El-Oued) L approche Base

Plus en détail

Noureddine Kerzazi noureddine.kerzazi@polymtl.ca

Noureddine Kerzazi noureddine.kerzazi@polymtl.ca Domaine de la modélisation des processus pour le génie logiciel. Noureddine Kerzazi noureddine.kerzazi@polymtl.ca DSL4SPM Domain-Specific-Language for Software Process Modeling Il s agit d un nouveau cadre

Plus en détail

Recommandations organisationnelles. Outils et guides. Guide de gestion de projet chirurgie ambulatoire

Recommandations organisationnelles. Outils et guides. Guide de gestion de projet chirurgie ambulatoire Ensemble pour le développement de la chirurgie ambulatoire Recommandations organisationnelles Outils et guides Guide de gestion de projet chirurgie ambulatoire Mai 2013 Le document source est téléchargeable

Plus en détail

IFT3913 Qualité du logiciel et métriques. Chapitre 2

IFT3913 Qualité du logiciel et métriques. Chapitre 2 IFT3913 Qualité du logiciel et métriques Chapitre 2 Qualité du produit logiciel Plan du cours Introduction Qualité du logiciel Théorie de la mesure Mesure de la qualité du logiciel Études empiriques Mesure

Plus en détail

pratiques. Nous avons abondamment illustré l'application correcte et efficace des nombreuses pratiques en assurance qualité par des cas pratiques.

pratiques. Nous avons abondamment illustré l'application correcte et efficace des nombreuses pratiques en assurance qualité par des cas pratiques. Cet ouvrage s inscrit dans le cadre d une problématique globale portant sur l amélioration de la qualité du logiciel pour des organismes qui ont atteint un certain niveau de maturité. Il cherche à rapprocher

Plus en détail

LES ORIGINES D ITIL Origine gouvernementale britannique 20 ans d existence et d expérience Les organisations gérant le référentiel :

LES ORIGINES D ITIL Origine gouvernementale britannique 20 ans d existence et d expérience Les organisations gérant le référentiel : La méthode ITIL plan Introduction C est quoi ITIL? Utilisation d ITIL Objectifs Les principes d ITIL Domaines couverts par ITIL Les trois versions d ITIL Pourquoi ITIL a-t-il tant de succès Inconvénients

Plus en détail

Service d Audit des logiciels Qualité et Conformité Cobol/Cics/IMS

Service d Audit des logiciels Qualité et Conformité Cobol/Cics/IMS GT-8 Service d Audit des logiciels Qualité et Conformité Cobol/Cics/IMS IMS-DC DC/SQL/ /SQL/IMS (disponible aussi pour Java/J2EE) IMS-DLI 03/12/2007 1 Prestation de service : Audit Qualimétrique I. Description

Plus en détail

Table des matières. Première partie Situation du test fonctionnel. Préface... Avant-propos...

Table des matières. Première partie Situation du test fonctionnel. Préface... Avant-propos... Préface..................................................................... Avant-propos................................................................ III XIII Première partie Situation du test fonctionnel

Plus en détail

Module : Méthodes et Spécifications Formelles (Approche orientée modèle) Christian Attiogbé UFR Sciences Nantes Dpt. Informatique

Module : Méthodes et Spécifications Formelles (Approche orientée modèle) Christian Attiogbé UFR Sciences Nantes Dpt. Informatique Méthodes formelles 1 Module : Méthodes et Spécifications Formelles (Approche orientée modèle) Slide 1 Christian Attiogbé UFR Sciences Nantes Dpt. Informatique Christian.Attiogbe@univ-nantes.fr maj. janvier

Plus en détail

Conduite de projets et architecture logicielle

Conduite de projets et architecture logicielle s et architecture logicielle ABCHIR Mohammed-Amine Université Paris 8 15 février 2011 1/36 ABCHIR Mohammed-Amine (Université Paris 8) Conduite de projets et architecture logicielle 15 février 2011 1 /

Plus en détail

les outils de la gestion de projet

les outils de la gestion de projet les outils de la gestion de projet Sommaire Objectifs de la gestion de projet Les étapes du projet Les outils de gestion de projets Paramétrage de l outil PROJET : «ensemble des actions à entreprendre

Plus en détail

Notre modèle d engagement

Notre modèle d engagement Notre modèle d engagement 1. EVALUER L évaluation des compétences que vous souhaitez améliorer implique un vrai échange entre nos deux équipes, et une étude plus approfondie des écarts et des actions préalablement

Plus en détail

vendredi 8 février 2008 QUALITÉ DU LOGICIEL

vendredi 8 février 2008 QUALITÉ DU LOGICIEL QUALITÉ DU LOGICIEL La qualité du logiciel Qualité d'un logiciel? de manière informelle : respect des spécifications. Particularités des logiciels par rapport à des produits matériels : Un logiciel a de

Plus en détail

Logiciel Libre Cours 3 Fondements: Génie Logiciel

Logiciel Libre Cours 3 Fondements: Génie Logiciel Logiciel Libre Cours 3 Fondements: Génie Logiciel Stefano Zacchiroli zack@pps.univ-paris-diderot.fr Laboratoire PPS, Université Paris Diderot 2013 2014 URL http://upsilon.cc/zack/teaching/1314/freesoftware/

Plus en détail

Programmation orientée objet et technologies Web

Programmation orientée objet et technologies Web Programmation orientée objet et technologies Web LEA.3N, version 2012 Information : (514) 376-1620, poste 7388 Programme de formation Type de sanction Attestation d études collégiales permettant de cumuler

Plus en détail

Why Software Projects Escalate: The Importance of Project Management Constructs

Why Software Projects Escalate: The Importance of Project Management Constructs Why Software Projects Escalate: The Importance of Project Management Constructs Why Software Projects Escalate: The Importance of Project Management Constructs 1. Introduction 2. Concepts de la gestion

Plus en détail

Validation de systèmes intégrant des COTS : comment accommoder les inconnues sur la qualification des COTS dans le processus de validation?

Validation de systèmes intégrant des COTS : comment accommoder les inconnues sur la qualification des COTS dans le processus de validation? Validation de systèmes intégrant des COTS : comment accommoder les inconnues sur la qualification des COTS dans le processus de validation? L I S EDF Electricité de France technicatome THOMSON-CSF Philippe

Plus en détail

Licence en Informatique à Horraire Décalé. Cours Gestion de projet informatique Première partie

Licence en Informatique à Horraire Décalé. Cours Gestion de projet informatique Première partie Licence en Informatique à Horraire Décalé Cours Gestion de projet informatique Première partie 1 PLAN Introduction 1. Les concepts de base en management de projet : 3-33 2 Les processus du management de

Plus en détail

Joël Darius Eloge ZODJIHOUE

Joël Darius Eloge ZODJIHOUE La gestion axée sur la Performance et les Résultats appliquée à la gestion des Finances Publiques: Préparation et Mise en place du Budget axée sur la performance et les résultats Joël Darius Eloge ZODJIHOUE

Plus en détail

Avec vous, pour vos projets, à chaque instant. Utilisation des réseaux de Pétri avec GRIF

Avec vous, pour vos projets, à chaque instant. Utilisation des réseaux de Pétri avec GRIF Avec vous, pour vos projets, à chaque instant Utilisation des réseaux de Pétri avec GRIF 2010 Projets pour le grand accélérateur de particules GANIL CEA/CNRS Vérification des automatismes de gestion du

Plus en détail

Experience N 52. Les expériences d ERNI dans l univers du management, des processus et des technologies. Mars 2012

Experience N 52. Les expériences d ERNI dans l univers du management, des processus et des technologies. Mars 2012 Les expériences d ERNI dans l univers du management, des processus et des technologies Experience N 52 Mars 2012 MIGRATIONS Garder la maîtrise lors de migrations GARdER la maîtrise LORS de migrations Lors

Plus en détail

REseau qualité Enseignement supérieur et Recherche L APPROCHE PROCESSUS. Réunion du 00/00/2011 1

REseau qualité Enseignement supérieur et Recherche L APPROCHE PROCESSUS. Réunion du 00/00/2011 1 L APPROCHE PROCESSUS Réunion du 00/00/2011 1 MISSION QUALITE ET METHODE L APPROCHE PROCESSUS Xavier Darrieutort-Approche_PS-Janv_2012 L APPROCHE PROCESSUS 1. SOMMAIRE Définition d un PROCESSUS Caractérisation

Plus en détail

C.1. COMMUNIQUER-S INFORMER. Conditions de réalisation

C.1. COMMUNIQUER-S INFORMER. Conditions de réalisation C.1. COMMUNIQUER- INFORMER avoir faire C.1.1. : Communiquer avec le client Écouter le client Questionner le client sur le dysfonctionnement constaté et les conditions d utilisation du véhicule, du sous-ensemble

Plus en détail