MÉTHODE DE TEST DES APPLICATIONS. Version : M21.4

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

Download "MÉTHODE DE TEST DES APPLICATIONS. Version : M21.4"

Transcription

1 MÉTHODE DE TEST DES APPLICATIONS Version : M21.4

2 [PAGE INTENTIONNELLEMENT BLANCHE]

3 Introduction MÉTHODE DE TEST DES APPLICATIONS 3

4 Avertissement Ce document est un support de cours dont le seul objectif est d aider les participants en leur évitant de prendre trop de notes, et en leur permettant d être plus actifs. Ce n est qu un élément d un ensemble de matériaux pédagogiques. Il est complémentaire des exposés et développements faits par l animateur, et ne contient pas la totalité des spécificités et des discussions propres à un site ou une session. Il ne représente donc qu une partie de la formation, et ne peut être utilisé avec profit que comme document d accompagnement d une séance de formation. 4 1-Introduction

5 Objectifs du cours Sensibiliser les participants à l importance de la qualité dans le développement du logiciel Définir une méthodologie de tests des modules et des applications Permettre de construire des jeux d essai Définir les éléments d organisation liés aux tests Définir une approche de la maintenance des programmes Donner les éléments de choix des outils de test Privilégier les aspects pratiques 1-Introduction 5

6 [PAGE INTENTIONNELLEMENT BLANCHE] 6 1-Introduction

7 La qualité MÉTHODE DE TEST DES APPLICATIONS 7

8 Les objectifs du chapitre Définir le concept de Qualité Assimiler la démarche Qualité Se convaincre de son absolue nécessité Relier qualité et tests 8 2-La qualité

9 La qualité : concepts 1. Le contrôle qualité : Est un concept des années 1960 Il applique le principe du contrôle «a posteriori» ou en final Il qualifie le résultat (bon ou mauvais) Conséquences : Tout est à recommencer si le résultat est mauvais (augmentation importante des coûts) Cela renforce l idée reçue (mais fausse) : «La qualité, cela se paie» 2-La qualité 9

10 La qualité : concepts (suite) 2. L assurance qualité : Est un concept des années 1970 Il applique le principe du contrôle «tout au long du processus de développement» Il introduit la notion de «qualité du produit» et de son «processus de fabrication» Il permet la détection des anomalies le «plus tôt possible» et engendre une réduction des coûts Définition : Mise en œuvre d un ensemble de dispositions préétablies destinées à l obtention régulière de la Qualité requise Remarque : L assurance qualité introduit les notions : de responsabilisation à chaque étape d objectifs qualité 10 2-La qualité

11 La qualité : concepts (suite) 3. La gestion totale de la qualité : Est un concept des années 1980 Il s appuie sur la notion de «Totalité» : la qualité est gérée dans l entreprise toute entière elle concerne toutes les fonctions et tous les aspects (matériel, logiciel, humain) chaque intervenant est impliqué et s efforce d améliorer la qualité àson propre niveau tous les besoins des clients sont pris en compte (coûts, délais, performances,...) la qualité est présente tout au long du cycle de vie des projets 2-La qualité 11

12 Qualité : définitions La définition des systèmes qualité est régie par les normes internationales ISO 9000 reproduites par la norme européenne EN et la norme française AFNOR NF X Qualité : Aptitude d un produit ou d un service à satisfaire les besoins d un utilisateur Assurance qualité : Mise en œuvre d un ensemble approprié de dispositions préétablies et systématiques destinées à donner confiance en l obtention de la qualité requise Manuel qualité : Document décrivant les dispositions générales prises par l entreprise pour obtenir la qualité de ses produits ou des ses services Plan qualité : Document décrivant les dispositions spécifiques prises par une entreprise pour obtenir la qualité du produit ou du service considéré 12 2-La qualité

13 Qualité et informatique Le Manuel qualité transcrit, au niveau de l entreprise, l ensemble des méthodes, règles et procédures mises en œuvre pour développer un produit logiciel de qualité C est une base documentaire Qui s enrichit au cours du temps Le Plan qualité détermine le processus de développement propre à un projet, avec ses particularités et spécificités La Qualité est une démarche continue tout au long du développement du produit logiciel La Qualité se définit, se mesure et se concrétise 2-La qualité 13

14 Qualité et informatique (suite) Remarques : La démarche qualité ne se suffit pas à elle-même Elle demande une volonté de l encadrement (mise en place d une politique Qualité) Elle nécessite l adhésion complète de l ensemble des intervenants Elle demande la mise en place de moyens et de structures nécessaires à sa concrétisation 14 2-La qualité

15 Le manuel qualité Contenu : Les objectifs (explication de la politique de qualité) L organisation mise en place (qui contrôle quoi, où et quand?) Quels produits et services sont concernés par le manuel qualité Présentation et justification de la qualité : privilégier le professionnalisme éviter l aspect policier Le plan de développement du produit logiciel : les phases du cycle de vie les moyens nécessaires (méthodes, techniques, outils, rapports, notes,...) le plan de formation la planification et le suivi de l avancement Les documents à fournir 2-La qualité 15

16 Le manuel qualité (suite) Le contrôle de qualité : les critères de qualité les points de contrôle qualité les moyens mis en œuvre La gestion de l évolution du produit La mise à jour du manuel de qualité La qualité est présente tout au long du déroulement du projet et concerne tous les intervenants 16 2-La qualité

17 La qualité du logiciel Ce qu on demande Validité : aptitude d un produit logiciel à réaliser exactement les tâches définies par sa spécification Exploitabilité : aptitude à être utilisé par les différentes parties prenantes (opérateurs, utilisateurs, maintenance...) Efficacité : mesure de la bonne utilisation des ressources Fiabilité : aptitude d un logiciel à fonctionner sans incident Intégrité : aptitude d un composant à protéger ses différentes composantes contre des accès ou des modifications non autorisées Extensibilité (Maintenabilité) : facilité d adaptation d un logiciel aux changements de spécifications Exactitude : aptitude d un logiciel à produire des résultats corrects Robustesse : aptitude d un logiciel à fonctionner dans des conditions anormales 2-La qualité 17

18 La qualité du logiciel Ce qu on doit obtenir Portabilité : facilité avec laquelle un constituant logiciel peut être adapté àdifférents environnements matériels et logiciels Réutilisabilité : aptitude d un logiciel à être réutilisé pour de nouvelles applications Lisibilité : faculté avec laquelle un composant est lu et donc compris Vérifiabilité : facilité de préparation des procédures de test pour le constituant considéré Compréhensibilité : aptitude pour un module d être compris isolément par un lecteur humain ; au pire le lecteur ne doit avoir à consulter que quelques modules voisins. Compatibilité : aptitude des logiciels à pouvoir être combinés les uns avec les autres 18 2-La qualité

19 La qualité du logiciel Ce qu on doit obtenir (suite) Décomposabilité : aptitude à décomposer un nouveau problème en plusieurs sous-problèmes dont la solution peut être recherchée séparément Composabilité : aptitude à favoriser la production d éléments de logiciel qui peuvent être combinés librement les uns avec les autres pour produire de nouveaux systèmes, éventuellement dans un environnement très différent de celui pour lequel ils ont été éventuellement développés Continuité : une petite modification de la spécification du problème n amène à modifier qu un seul module, ou peu de modules Protection : aptitude pour une architecture de ne pas propager l effet d une condition anormale se produisant à l exécution d un module, ou tout au moins de ne propager cet effet qu à quelques modules voisins 2-La qualité 19

20 Théorie et pratique La qualité est difficile à obtenir dans les applications informatiques Les objectifs de qualité sont peu souvent définis Le seul moyen de s en assurer est souvent limité aux tests Les tests sont peu productifs Beaucoup d erreurs sont découvertes en exploitation Les tests coûtent cher La non-qualité des applications coûte encore plus cher Pourra-t-on se le permettre encore longtemps? (car de plus en plus d activités humaines dépendent directement de la qualité des applications informatiques) 20 2-La qualité

21 Le coût de la non qualité Exemple 1 Le 22 juillet 1962, une fusée Atlas-Agena lançant un satellite Mariner I fut détruite par erreur Cause : Erreur minime dans le logiciel de guidage, amenant l ordinateur à croire que la fusée se comportait mal, ce qui n était pas le cas Coût : 18,5 millions de dollars Source : Les avatars du logiciel, Addison-Wesley 2-La qualité 21

22 Le coût de la non qualité Exemple 2 En juillet 1991, des séries de coupures affectèrent les abonnés du téléphone de Los-Angeles, Washington, etc. Cause : Le programme de commutation avait été modifié. Ce programme comporte plusieurs millions de lignes de code, et un cycle de tests représente 13 semaines. La modification ne touchant que trois lignes de code, on avait estimé inutile de refaire des tests complets! 22 2-La qualité

23 Le coût de la non qualité Exemple 3 Le 25 février 1991, un missile Scud irakien tua 28 soldats américains et en blessa 98 autres. Cause : Une bogue dans le logiciel de conduite des anti-missiles Patriot n avait pas permis l interception. Une erreur de calcul dans le logiciel de poursuite entraînait un écart d un dix millionième de seconde toutes les dix secondes, qui se cumulait au fil du temps. Le système ayant fonctionné 5 jours d affilée, l erreur atteignait 36 centièmes de secondes. L erreur avait été repérée, corrigée, mais le logiciel rectifié n avait pas encore été livré. 2-La qualité 23

24 Le coût de la non qualité Exemple 4 Le 20 novembre 1985, une bogue coûta 5 millions de dollars à la Bank of New-York. Cause : Réécriture d informations par dessus des informations déjà enregistrées. La détection de l erreur dura 90 minutes, et la banque devait alors déjà 32 millions de dollars à la banque fédérale. Les efforts de tous ramenèrent la dette à 23,6 millions de dollars, ce qui coûta 5 millions de dollars en intérêts La qualité

25 Tests et cycle de vie Exemple de cycle de vie ÉTUDE DES BESOINS CONCEPTION PROGRAMMATION INTEGRATION / TESTS PRODUCTION / MAINTENANCE Les tests constituent une phase isolée, indépendante, semblant située après les autres phases. Est-ce la meilleure solution? N est-ce pas une des causes de la mauvaise qualité du logiciel? 2-La qualité 25

26 Autre exemple : SDM / S DS DEMANDE DE SERVICE EO ÉTUDE D OPPORTUNITÉ DBS DÉFINITION DES BESOINS CAS CHOIX D ARCHITECTURE SES SPÉCIFICATIONS EXTERNES SIS SPÉCIFICATIONS INTERNES PRG PROGRAMMATION TST TESTS CONV CONVERSION INST INSTALLATION BILAN BILAN Phase de tests semblant isolée 26 2-La qualité

27 Autre exemple : MCP CONCEPTION FR0 EXPRESSION DES BESOINS +-> INSCRIPTION AU D AUTOMATISATION SCHEMA DIRECTEUR FR1 ÉTUDE D OPPORTUNITÉ +-> INSCRIPTION AU PLAN INFORMATIQUE FR2 ÉTUDE DU SYSTEME D INFORMATION FR3 ÉLABORATION DU +-> DÉCISION DE CAHIER DES CHARGES RÉALISATION RÉALISATION FR4 ÉTUDE DU SYSTEME INFORMATIQUE FR5 PROGRAMMATION ET ESSAIS MISE EN OEUVRE FR6 RÉCEPTION PROVISOIRE FR7 LANCEMENT SOUS CONTROLE EXPLOITATION FR8 ÉVALUATION DE L APPLICATION+-> DÉCISION DE MAINTENANCE FR9 ÉVALUATION DU PROJET +-> DÉCISION DE MODIFICATION La qualité 27

28 Les tests dans le cycle de vie Les tests devraient être «horizontaux» 28 2-La qualité

29 Place des tests Les tests sont longs et entraînent une charge importante DISTRIBUTION PAR PHASE TAILLE EN KISL CHARGE Plan/spécifications 6% 6% 6% 6% Conception 16% 16% 16% 16% Programmation 68% 65% 62% 59% dont conception détaillée 26% 25% 24% 23% codage et tests 42% 40% 38% 36% Intégration-tests 16% 19% 22% 25% TAILLE EN KISL DÉLAI Plan/spécifications 10% 11% 12% 13% Conception 19% 19% 19% 19% Programmation 63% 59% 55% 51% Intégration-tests 18% 22% 26% 30% Source : modèle COCOMO (Barry Boehm) 2-La qualité 29

30 Comment faire Mieux connaître les tests Mieux intégrer les tests dans le cycle de développement du logiciel Mieux tester Mieux écrire Mieux concevoir 30 2-La qualité

31 Les tests et leurs problèmes MÉTHODE DE TEST DES APPLICATIONS 31

32 Les objectifs du chapitre Définir les notions d erreur et de défaut Connaîtres les difficultés inhérentes aux tests Justifier la nécessité des tests Comparer les tests aux autres méthodes de recherche d erreurs 32 3-Les tests et leurs problèmes

33 Définitions Anomalie : manifestation observée d un comportement différent du comportement attendu ou spécifié (la norme) Défaut : manque, insuffisance : l anomalie est constatée parce qu il y a un défaut Erreur : faute commise en se trompant, méprise : l erreur provoque un défaut se manifestant par une anomalie C est parce qu on peut commettre des erreurs en développant des logiciels que les tests sont nécessaires 3-Les tests et leurs problèmes 33

34 Les tests Constats : Tout programme est faux, à moins qu on ait prouvé le contraire Les tests servent à montrer la présence d erreurs, jamais à prouver leur absence (Dijkstra 1969) Le programmeur est la personne la moins bien placée pour tester son programme Faible rendement Durée importante Tâche difficile Remarques : Un programme n est jamais faux Mais il ne fait pas ce que l on attend de lui! Les tests sont estimés à 33% du coût d un projet! 34 3-Les tests et leurs problèmes

35 Test et complexité Schéma : n n A A v A A A v A >+-+ +->-+ +->-+ ++-> >-+ +->-+ ++> v v A v v A n +² 5-1 NOMBRE DE CHEMINS A TESTER : T = 5 * SI N = 4 ---> T = SI MODULE DÉCOUPÉ ---> T = SI N = > T = 9,3 * 10 SI UNE MACHINE TESTE UN MILLION DE CHEMINS A LA SECONDE ANS DE TEST!!! Remarque : Plus un programme est compliqué, plus il est difficile à tester 3-Les tests et leurs problèmes 35

36 Difficultés des tests Théoriques : Problème de combinatoire (voir ci-dessus) Possibilité des tests? Peu d intérêt théorique pour la discipline (ou intérêt très récent) Il ne peut exister aucun algorithme général (donc aucun outil) capable de démontrer l exactitude totale de n importe quel programme! 36 3-Les tests et leurs problèmes

37 Difficultés des tests Techniques : Mauvaise synchronisation entre écriture et tests Problèmes de disponibilités de ressources (modules, systèmes, fichiers non disponibles) Nécessité de création d outils spécifiques (génération de cas, interprétation des résultats) Besoin d environnement(s) particulier(s) Problèmes liés à la stabilité des environnements (quelle version de système, de SGBD, etc.) 3-Les tests et leurs problèmes 37

38 Difficultés des tests Humaines : Tâche fastidieuse Les tests débutent souvent quand on est en retard (tendance à cumuler les retards sur les tests) Blocages psychologiques (erreurs ressenties comme des fautes par le programmeur qui les a commises) C est la première fois que l on montre quelque chose : remise en cause des spécifications conflits Manque de formation à la technique des tests construction des tests analyse des résultats bibliographie? Manque d objectifs précis Manque de rigueur Obstacle culturel (on apprend à gagner, l erreur est rejetée de la formation) 38 3-Les tests et leurs problèmes

39 Les causes d erreur Il existe (malheureusement) de nombreuses causes ou possibilités d erreurs lors du développement d applications informatiques Pendant les phases de conception mauvaise expression des besoins mauvaises solutions techniques etc. Pendant la conception de la logique détaillée : mauvaise interprétation des spécifications logique incomplète cas particulier omis cas d erreurs négligés etc. 3-Les tests et leurs problèmes 39

40 Les causes d erreur Pendant le codage : erreurs de syntaxe erreurs d initialisation erreurs de paramètres erreurs de compteur de boucle prise en compte incorrecte des résultats d une décision définition multiple ou non-définition de variables déclarations de type ou de dimension incorrects erreur d écriture du nom d une variable etc Les tests et leurs problèmes

41 Les causes d erreur Pendant la translation (link) : erreur de compilation restante mauvaise résolution des références externes confusion des noms de membres ou de bibliothèques Voir la classification des erreurs en annexe 3-Les tests et leurs problèmes 41

42 Échelle de gravité des erreurs 1. légère : présentation ou orthographe 2. modérée : sorties redondantes avec peu d impact sur le système 3. ennuyeuse : fonctionnement perturbé (zones tronquées) 4. perturbante : refus de traiter des transactions 5. sérieuse : perte de transactions 6. très sérieuse : exécution de la mauvaise transaction 7. extrême : les problèmes précédents arrivent fréquemment et arbitrairement 8. intolérable : corruption de bases de données 9. catastrophique : le système tombe en panne 10. infectieuse : le système corrompt d autres systèmes, ou tue 42 3-Les tests et leurs problèmes

43 Comparaison des méthodes d essai Les tests ne sont ni la seule, ni la meilleure méthode pour assurer la qualité d une application Les tests ont un faible rendement : en effort dépensé par instruction en pourcentage d erreurs corrigées EFFORT EN INSTRUCTIONS % DE CORRECTION PAR HEURE MÉTHODE INSPECTION MOYENNE : 40 59% DU CODE EXTREMES : 10 à à 89% TEST MOYENNE : 17 51% UNITAIRE EXTREMES : 5 à à 89% Les tests et leurs problèmes 43

44 Comparaison des méthodes d essai Pourcentage de défauts détectés MÉTHODE Taux le Taux Taux le + faible médian + fort Vérification individuelle 15% 30% 70% de la conception Revue formelle en groupe 30% 40% 60% de la conception Inspections formelles 35% 55% 75% de la conception Inspections formelles 30% 60% 70% du code Modélisation/prototypage 35% 65% 80% Vérification individuelle 20% 40% 60% du code Tests unitaires (module) 10% 25% 50% Tests de programme 20% 35% 55% Tests d enchaînement 25% 45% 60% Tests de recette 35% 50% 65% Effet cumulatif 93% 99% 99% Les tests et leurs problèmes

45 Comment améliorer les tests? Meilleure connaissance du programme Meilleure connaissance de l énoncé Méthodologie de tests Objectifs de tests Formation à la technique des tests Outils de tests 3-Les tests et leurs problèmes 45

46 [PAGE INTENTIONNELLEMENT BLANCHE] 46 3-Les tests et leurs problèmes

47 Définitions et axiomes MÉTHODE DE TEST DES APPLICATIONS 47

48 Les objectifs du chapitre Définir les tests Définir le vocabulaire utilisé Donner les axiomes relatifs aux tests 48 4-Définitions et axiomes

49 Définitions des tests Quelques définitions historiques Établir qu un programme fait ce qu il est supposé faire (Hetzel 1973) Action consistant à exécuter un programme ou un système avec l intention de trouver des erreurs (Myers 1979) Détection d erreurs de spécifications ou de d écarts par rapport aux spécifications Toute activité tendant à évaluer un attribut ou une capacité d un programme ou d un système Mesure de la qualité du logiciel (Hetzel 1983) Processus d évaluation d un programme ou d un système Vérifier qu un système satisfait ses spécifications ou identifier les différences entre les résultats attendus et les résultats fournis Confirmer qu un programme effectue correctement ses fonctions 4-Définitions et axiomes 49

50 Définitions des tests Définitions officielles IEEE/ANSI 1990 (Standard ) Processus consistant à exécuter un système ou un composant dans des conditions spécifiées, en observant ou en enregistrant les résultats, et à faire une évaluation de certains des aspects du système ou du composant IEEE/ANSI 1983 (Standard 823) Processus consistant à analyser un élément logiciel pour détecter les différences entre les conditions requises et celles existantes, et permettant d évaluer les caractéristiques de l élément logiciel Notre définition préférée Test : action qui consiste à exécuter un programme (une partie de programme ou un système) avec l intention de trouver des erreurs 50 4-Définitions et axiomes

51 Autres définitions Vérification : processus d évaluation d un système ou d un composant pour déterminer si le produit satisfait, à sa phase de développement, les conditions imposées au début de la phase On vérifie qu on a bien fait un logiciel Validation : processus d évaluation d un système ou d un composant durant ou à la fin de son développement pour déterminer s il satisfait ses spécifications On valide qu on a fait le bon logiciel Test = vérification + validation 4-Définitions et axiomes 51

52 Autres définitions Débogage (debugging, déverminage) : diagnostic de la nature exacte d une erreur connue et correction de l erreur (c est une activité de réparation et non de test) Jeu d essai : ensemble (structuré) de cas à tester 52 4-Définitions et axiomes

53 Les axiomes du test Un bon jeu d essai doit avoir comme objectif de trouver des erreurs non connues, et pas de montrer que le programme fonctionne correctement Un des problèmes les plus difficiles est de savoir quand s arrêter Il est impossible de tester son propre programme Tout jeu d essai doit être accompagné de la description des sorties attendues Les tests doivent être reproductibles On doit tester, en entrée, la validité des données et les cas invalides Il faut examiner soigneusement les résultats des tests Quand le nombre d erreurs détectées dans un élément de logiciel croît, la probabilité d existence d erreurs non détectées croît également On doit affecter les meilleurs programmeurs aux tests (tests techniques et non pas fonctionnels) On doit s assurer en écrivant un programme, qu il est possible de le tester 4-Définitions et axiomes 53

54 Les axiomes du test (suite) Chaque test doit avoir un objectif (performances, exploitabilité, utilisateurs...) On doit tester les cas valides et les cas invalides Le plan de test ne doit pas être construit avec l intention tacite de ne pas trouver d erreurs Les tests peuvent être une tâche extrêmement créative 54 4-Définitions et axiomes

55 Techniques de test Boîte noire On ne connaît que les spécifications (l aspect externe) On valide le programme par rapport à ses spécifications Test fonctionnel Boîte blanche On connaît à la fois les spécifications et l implémentation (pseudo-code ou code) On valide la réalisation du programme Test structurel Boîte grise Combinaison des deux techniques Non régression Un test de non régression consiste vise à s assurer qu une évolution n a pas introduit de nouveaux défauts 4-Définitions et axiomes 55

56 [PAGE INTENTIONNELLEMENT BLANCHE] 56 4-Définitions et axiomes

57 Le plan de tests MÉTHODE DE TEST DES APPLICATIONS 57

58 Les objectifs du chapitre Définir ce qu est un plan de tests Donner une trame du contenu d un plan de test Définir les différents types de test Relier les tests à la démarche de construction du logiciel 58 5-Le plan de tests

59 Plan de tests Le plan de test décrit toutes les procédures permettant de conduite les tests jusqu à leur terme Un plan de tests doit, au minimum : établir les objectifs de chaque phase de tests, définir les responsabilités et le planning pour chacune des activités des tests, s assurer de la disponibilité des outils de tests et données de tests (bibliothèques de cas de tests?), établir les normes de conduite des tests, définir les critères de fin et d acceptabilité de chaque test. 5-Le plan de tests 59

60 Trame d un plan de tests Composants à tester faire une liste exhaustive des composants à tester préciser pour chaque composant : les objectifs des activités de test les types de test et les étapes les méthodes de test choisies pour chaque type et chaque étape les outils de test utilisés les règles à suivre pour : définir chaque type de test rédiger les procédures de test exécuter les tests définir et décider les critères d arrêt des tests enregistrer les résultats de test et rédiger les comptes-rendus exploiter les résultats des tests 60 5-Le plan de tests

61 Trame d un plan de tests Objectif de chaque test Le plan devra détailler pour chaque test l objectif à atteindre validité des fonctionnalités contrôle de l enchaînement des écrans ergonomie du produit performances etc. 5-Le plan de tests 61

62 Trame d un plan de tests Types de test Le plan devra distinguer les différents types de tests test unitaire (module) test de programme ou de transaction test d analyse test d intégration (d enchaînement) test de recette utilisateur recette exploitation tests système test inter-applications etc Le plan de tests

63 Trame d un plan de tests Procédures de tests Pour chaque type de test, on doit indiquer les moyens utilisés test boîte blanche test boîte noire test de non régression contrôle des chemins contrôle de couverture couverture de branches couverture de conditions conditions multiples etc. graphe de contrôle scénario d intégration etc. 5-Le plan de tests 63

64 Trame d un plan de tests Critères d arrêt Pour chaque type de test, on doit préciser le critère d arrêt du test : taux de couverture atteint taux ou type d erreurs détectés dépassement du temps imparti intervalle de variables performances atteintes volumes atteints etc Le plan de tests

65 Trame d un plan de tests Mise en œuvre Le plan de test doit préciser : les moyens de tests utilisés à chaque étape la configuration utilisée les responsabilités (qui définit, qui réalise, qui contrôle) les délais (planning de chaque essai) les procédures nécessaires à la réalisation des tests, à l exploitation et à l enregistrement des résultats les actions à prendre (quand passe-t-on à l étape suivante, quand refait-on un test, etc.) la forme des comptes-rendus de tests 5-Le plan de tests 65

66 Trame d un plan de tests Compte-rendu de tests date nom de la phase de test identification de composant logiciel testé version du composant type de test effectué liste détaillée des cas testés liste détaillée des erreurs constatées liste des corrections envisagées liste des répercussions sur la configuration noms des participants charge de travail procédure d acceptation éventuelle 66 5-Le plan de tests

67 Plan de tests Liste de contrôle Tous les niveaux de tests sont-ils définis? L objectif de chaque test est-il défini? Les ressources nécessaires (matériel, logiciel, personnel) nécessaires à la période de test sont-elles identifiées? Les responsabilités de chaque niveau de test sont-elles identifiées? Sont-elles clairement définies? Les testeurs sont-ils indépendants des développeurs? Des revues ou inspections sont-elles planifiées? Les responsabilités de leur conduite sont-elles clairement identifiées? Concernent-elles : la conception, la définition des plans de tests, les procédures de test, les résultats de tests? Des normes existent-elles pour ces revues? Les procédures de correction post-revues sont-elles définies? Le planning des différentes épreuves (revues, tests, etc.) est-il établi et vérifié? La documentation nécessaire est-elle définie? Un auditeur qualité est-il nécessaire? Est-il défini? 5-Le plan de tests 67

68 Les différents tests Liste minimale des différents types de tests 1. Vérification avant, pendant et après l écriture 2. Test unitaire (module) 3. Test de programme ou de transaction 4. Test d analyse (de fonctions) 5. Test d enchaînement (d intégration) 6. Test de recette 7. Recette exploitation 8. Tests système 9. Test inter-applications 68 5-Le plan de tests

69 1 Réalisation et vérification Vérification avant, pendant et après l écriture : Objectif : trouver les erreurs le plus tôt possible éviter des tests Moyens : boîte blanche «test» manuel individuel : passer par tous les chemins possibles revues, inspections 5-Le plan de tests 69

70 Revue de programme La conception est-elle claire? Le programme réalise-t-il sa fonction? Le code est-il clair? Est-il aisément compréhensible? Les commentaires aident-ils à comprendre le programme? Pourrait-on modifier facilement le programme? Serait-on fier d avoir écrit ce programme? Le code suit-il les normes de programmation? Les tests suivent-ils les normes de test établies? Les données de test sont-elles bien choisies (variété des valeurs, valeurs mini, maxi, probables)? Le test des données erronées est-il prévu? Toutes les conditions d erreur sont-elle vérifiées? Les tests montrent-ils que le programme réalise bien ce qu on attend de lui? Les tests montrent-ils que le code satisfait toutes les exigences? Les données en entrées produisent-elles les sorties attendues? 70 5-Le plan de tests

71 2 Test unitaire (module) Objectif : contrôle technique de fonctionnement Moyens : boîte blanche jeux d essai programmeur (construit logiquement) simulateur d appel, liste de contrôle, inspection 5-Le plan de tests 71

72 3 Test de programme ou de transaction Objectifs : contrôle de l enchaînement des modules, intégration des éléments, solidité, fiabilité Moyens : images de fichiers (cas normaux), jeux d essai (cas aux limites), inspection 72 5-Le plan de tests

73 4 Test d analyse Objectifs : validité par rapport à l énoncé critère de fin de programmation Moyens : boîte noire cas vraisemblables (ordre décroissant) inspection 5-Le plan de tests 73

74 5 Test d intégration (d enchaînement) Objectifs : fonctionnement correct d un ensemble par rapport à une analyse temps réel : enchaînement cohérent des éléments d une même fonction (transactions, modules) temps différé : enchaînement des programmes et validation de la procédure (JCL) Moyens : jeu d essai ou extraits de fichiers système de test 74 5-Le plan de tests

75 6 Test de recette utilisateur Objectifs : contrôle par rapport aux spécifications validation dans l environnement réel contrôle du manuel utilisateur Moyens : jeu d essai de recette travail en double 5-Le plan de tests 75

76 7 Recette exploitation Objectif : satisfaction aux normes d exploitation validation du manuel opérateur sécurités, reprises, Moyens : contrôle visuel (documents) fonctionnement à blanc manipulations spécifiques (pannes) 76 5-Le plan de tests

77 8 Test système Objectifs : charge maximum admissible volume maximum admissible performances installation (ou ré-installation) fiabilité, disponibilité réparation qualification d une ou de configurations Moyens : simulateur (moniteur) jeu d essai essai en charge 5-Le plan de tests 77

78 9 Test inter-applications Objectifs : fonctionnement des applications entre elles détection des incompatibilités Moyens : comparateur de fichiers (ou interfaces) jeu d essai spécifique 78 5-Le plan de tests

79 Tests et assemblage La stratégie d intégration des éléments du logiciel a un impact important sur les tests L intégration peut être massive («big bang») progressive («au fil de l eau») descendante («top down») ascendante («bottom up») mixte (combinaison par incréments ou agrégats, guidée éventuellement par le risque) 5-Le plan de tests 79

80 Tests et assemblage A B C D E F G H TESTS TOP-DOWN : - MODULE A ( B, C, D, E, F, G ET H VIDES) - MODULES B ET C (D, E, F, G ET H VIDES) - MODULES D, E, F, G ET H TESTS BOTTOM-UP : - MODULES D, E, F, G ET H (B ET C VIDES) - MODULES B ET C (A VIDE) - MODULE A 80 5-Le plan de tests

81 Tests top-down Caractéristiques Le moniteur est testé en premier (logique d appel) Les modules sont intégrés un à un Avantages : L intégration des programmes commence très tôt Les modules appelants sont codés avant les modules appelés : les confusions au niveau des interfaces peuvent être réduites Le besoin de fabriquer un ou plusieurs moniteurs de test est réduit dans la mesure où chaque module peut-être appelé à travers le code existant Un programme en fonctionnement est toujours disponible 5-Le plan de tests 81

82 Tests top-down Inconvénients : L utilisation de modules communs pose des problèmes Il est nécessaire d avoir des modules vides pour tester Les tests sont plus longs car ils sont dépendants des modules supérieurs La complexité des modules n est pas prise en compte 82 5-Le plan de tests

83 Tests bottom-up Caractéristiques Test individuel et indépendant de chaque module Les modules sont intégrés un à un Avantages : Meilleur parallélisme dans la réalisation du codage et des tests L intégration commence plus tôt, mais l assemblage ne se fait que très tard Un module, une fois testé, est considéré comme une simple instruction Les tests peuvent être plus complets, car les modules sont testés indépendamment des modules de niveau supérieur Pas besoin de modules vides pour tester 5-Le plan de tests 83

84 Tests bottom-up Inconvénients : Codification non harmonisée des données et des interfaces Apparition des problèmes uniquement en phase d intégration Suivi difficile de l avancement des travaux Nécessité d écriture de moniteurs de tests 84 5-Le plan de tests

85 Codage et tests Par quoi commencer : Par les modules de plus bas niveau pour bâtir par blocs successifs Par le codage du squelette à tous les niveaux, pour mieux contrôler les interfaces et la complexité Par les modules communs (utilitaires) quel que soit leur niveau Par les modules les plus compliqués (ceux qui prennent le plus de temps à réaliser) Par les modules que les programmeurs se sentent le plus à même de concevoir et de réaliser 5-Le plan de tests 85

86 Tests et construction de logiciel Intégrer les tests le plus tôt possible dans la construction du logiciel Au niveau des spécifications : Détermination de fonctions testables, caractérisées par des entrées et des sorties spécifiques Traçé de diagramme de vérification du système sous forme de couples «stimulus/réponse» Ordonnancement des fonctions à tester : Par unités de réalisation Traduction des spécifications en termes de fabrication et vérification Codage et recette : Par fonction de niveau de détail croissant 86 5-Le plan de tests

87 Tests et construction de logiciel Bénéfices : Vérification des spécifications Noyau rapidement disponible Mesure de l avancement du projet 5-Le plan de tests 87

88 [PAGE INTENTIONNELLEMENT BLANCHE] 88 5-Le plan de tests

89 Construction de jeux d essai MÉTHODE DE TEST DES APPLICATIONS 89

90 Les objectifs du chapitre Définir comment construire un jeu d essai Décrire les méthodes disponibles et leur domaine d application Donner une application concrète de ces méthodes Traiter les cas particuliers 90 6-Construction de jeux d essai

91 Les premières idées Construction logique : au moins deux fois par répétitive (boucle et fin) au moins deux fois par alternative (vrai et faux) Un seul jeu d essai n est souvent pas suffisant fichiers vides? Tester progressivement : cas général puis cas particuliers dans leur ordre décroissant d apparition Contrôler particulièrement : valeurs aux limites initialisations S inspirer des autres disciplines : on ne met pas un avion en vrille à son premier essai on s assure d abord qu il peut décoller, voler et atterrir 6-Construction de jeux d essai 91

92 Les méthodes de construction Boîte blanche couverture structurelle tests mutationnels Boîte noire analyse partitionnelle (classes d équivalence) analyse aux limites tests aléatoires anticipation des erreurs graphes causes-effet 92 6-Construction de jeux d essai

93 Couverture structurelle Couverture d instruction (SC) : chaque instruction du programme a été exécutée au moins une fois Couverture de décision (DC) : chaque point d entrée et de sortie du programme a été mise en œuvre au moins une fois, toutes les branches résultant d une décision ont été mises en œuvre au moins une fois Couverture de condition/décision (C/DC) : ajoute à DC le fait que chaque condition dans une décision a pris toutes les valeurs au moins une fois Couverture de condition/décision modifiée (MC/DC) : ajoute à C/DC le fait que chaque condition dans une décision affecte de manière indépendante (sauf conditions liées) le résultat d une décision Couverture de condition multiple (M-CC) : ajoute à C/DC le fait que toutes les combinaisons des valeurs de conditions dans chaque décision doivent avoir été prises au moins une fois Logiciel critique : couverture MC/DC dans ce cas, si n conditions booléennes indépendantes, il faut n+1 combinaisons de conditions 6-Construction de jeux d essai 93

94 Couverture structurelle Exemple instructions-1; IF (A OR B) THEN instructions-2; ELSE instructions-3; END-IF; instructions-4; Organigramme 94 6-Construction de jeux d essai

95 Couverture structurelle Table de vérité CAS A B I2 I F F X F V X V F X V V X Exemples de combinaisons à tester selon la couverture souhaitée : SC : cas 1 et 2 (ou 1 et 3, ou 1 et 4) DC : idem C/DC : cas 1 et 4 MC-DC : cas 1, 2 et 3 (ou 1, 2 et 4, ou 1, 3 et 4) M-CC : cas 1, 2, 3 et 4 6-Construction de jeux d essai 95

96 Équivalence partitionnelle Principe Processus systématique permettant de définir des classes de conditions en entrée à tester, chaque classe couvrant un ensemble important de cas de test (Myers) Deux étapes identification des classes d équivalence identification des cas de test 96 6-Construction de jeux d essai

97 Identification des classes 1. Si une entrée spécifie une tranche de valeurs admissibles, définir une classe valide dans la tranche, et deux classes invalides (une pour chaque borne) Exemple : Tranche de 1 à 999 => une classe pour une valeur entre 1 et 999, une pour < 1, une pour > Si une entrée spécifie un nombre de valeurs valides, définir une classe valide pour une valeur, et deux classes invalides (rien, et supérieur au nombre) Exemple : lister de 1 à 6 clients => une classe pour une liste entre 1 et 6, une pour une liste vide, une pour une liste > 6 3. Si une entrée spécifie un ensemble de valeurs valides, définir une classe valide pour une valeur dans l ensemble, et une classe invalide (en dehors de l ensemble) 4. S il y a une raison de penser que le programme traite chaque valeur en entrée différemment, définir une classe par entrée 6-Construction de jeux d essai 97

98 Identification des classes 5. Si l entrée spécifie une condition obligatoire, définir une classe valide et une invalide Exemple : le premier caractère doit être numérique => une classe pour une valeur initiale numérique, une classe pour une valeur initiale non numérique 6. Si on pense que les éléments d une classe ne sont pas tous traités de la même manière, subdiviser la classe en sous-classes 98 6-Construction de jeux d essai

99 Identification des cas de test 1. Donner un numéro à chaque classe 2. Tant que toutes les classes valides n ont pas été couvertes, écrire un nouveau jeu d essai couvrant autant de classes valides non couvertes que possible 3. Tant que toutes les classes non valides n ont pas été couvertes, écrire un nouveau jeu d essai couvrant une et seulement une classe non valide non couverte 4. Si de multiples conditions invalides sont testées dans le même jeu d essai, certaines peuvent être masquées par le traitement des erreurs 6-Construction de jeux d essai 99

100 Analyse aux limites Variante de la méthode des classes d équivalence sous deux aspects : 1. Au lieu de prendre n importe quel élément dans une classe, on se focalise sur les limites de la classe (elles sont souvent à l origine de défauts) 2. Au lieu de ne se centrer que sur les entrées, on explore aussi les sorties, et on génère des classes forçant les sorties désirées Construction de jeux d essai

101 Analyse aux limites Application Si une entrée spécifie une tranche de valeurs, écrire un cas de test pour chaque valeur limite, et un pour chaque valeur juste en deçà et au delà des limites Exemple : nombre de -1.0 à +1.0 => tester -1.0 et 1.0, et Si une entrée spécifie un nombre de valeurs, écrire un cas de test pour chaque valeur limite, et un pour chaque valeur juste en deçà et au delà des limites Exemple : tableau contenant de 1 à 255 éléments => tester 1, 255, 0, 25 Utiliser la même approche pour les sorties : générer les cas de test produisant, pour les sorties, les valeurs limites et les valeurs au delà et en deçà des limites Si l entrée ou la sortie comportent un tri, examiner le premier et le dernier élément Faire preuve d imagination! 6-Construction de jeux d essai 101

102 Tests aléatoires Génération probabiliste, sur les domaines de définition, des données en entrée du programme Avantages facilement automatisable objectivité Inconvénients cas particuliers, exceptions prise en compte de la sémantique Résultats à peine moins bons que des techniques plus élaborées Construction de jeux d essai

103 Anticipation des erreurs Construction de tests à partir des situations ayant provoqué des erreurs par le passé, ou provoquant le plus d erreurs (ou le plus fréquemment) Basé sur le principe que ce qui a provoqué des erreurs dans le passé risque de la faire dans le futur Importance de l expérience et de l intuition Importance d un recensement des erreurs et d un maintien de leur historique Importance d une liste de contrôle actualisée 6-Construction de jeux d essai 103

104 Conseils pratiques Valeurs numériques en entrée Dans les cas d un petit nombre de valeurs différentes en entrée, tester toutes les valeurs Dans les cas d un grand nombre de valeurs de données en entrée, tester les valeurs extrêmes et une sélection de valeurs intermédiaires Toutes les classes de données admissibles doivent être testées (blanc, zéro, valeurs négatives, etc.) Toutes les conditions invalides en entrée doivent être testées (alpha dans du numérique, négatif dans un champ positif, décimal dans un champ entier, etc.) Si deux variables (ou plus) sont liées, tester les valeurs possibles et impossibles Construction de jeux d essai

105 Conseils pratiques Valeurs numériques en sortie Dans les cas d un petit nombre de valeurs différentes en sortie, tester les combinaisons en entrée qui produisent toutes les valeurs Dans les cas d un grand nombre de valeurs différentes en sortie, tester les combinaisons en entrée qui produisent les valeurs extrêmes et une sélection de valeurs intermédiaires Essayer de tester les cas de données en entrée produisant des données en sortie invalides Si des valeurs en sortie sont liées, tester les cas extrêmes, les cas probables, les valeurs illégales 6-Construction de jeux d essai 105

106 Conseils pratiques Tableaux Le contenu de chaque donnée du poste doit être testé Les bornes du tableau doivent être testées, ainsi que leur dépassement Construction de jeux d essai

107 Conseils pratiques Et encore : Tester des valeurs erronées Tester des combinaisons erronées Tester les valeurs extrêmes Tester au delà des extrêmes Ne pas oublier les cas normaux Ne pas générer de cas superflus Tenir compte de la structure Ne pas faire qu un seul test 6-Construction de jeux d essai 107

108 Tests complémentaires : temps réel Réutilisation en série? Réentrance Blocages et interblocages Prise de points de contrôle et redémarrage Performances (moyenne, maxi, limites) etc Construction de jeux d essai

109 Tests complémentaires : interface graphique Tester les valeurs possibles et impossibles de chaque zone Tester les sauts de curseur, les listes Tester avec la souris et avec le clavier Tester les messages d erreur contextuels et les aides Tester les déplacements de fenêtre, les redimensionnements (réductions et agrandissements) Tester le menu contextuel Tester toutes les variantes possibles (les touches de fonction, les touches alt ou ctrl, les barres de menu, les boutons, les icônes) Tester les modifications d environnement (carte graphique, définition et type d écran, couleurs, polices) Tester, le cas échéant, les échanges avec l environnement (couper, coller, OLE, DDE) Tester les dépendances de fenêtres (père-file) Tester l ergonomie fonctionnelle etc. 6-Construction de jeux d essai 109

110 Tests complémentaires : réseau Caractères de contrôle Séquences de messages Messages de longueur nulle Messages trop longs Messages de structure invalide Messages à blanc ou à zéro Nature de l information transmise (binaire, packée) Traduction de code Sécurité, reprises Incidents de trafic (coupure de ligne) etc Construction de jeux d essai

111 Tests complémentaires : client/serveur Protocole(s) de communication et «middleware» Cohérence des versions (entre client et serveur) Mise à jour des programmes Accès au(x) serveurs(s) Accès aux données (disponibilité, indisponibilité, volume) Accès aux procédures stockées, aux triggers Blocages, redémarrages Identification des configurations cibles et des environnements cibles (qualification) Capacité, temps de réponse de bout en bout etc. 6-Construction de jeux d essai 111

112 Tests complémentaires : objet Héritage Surcharge de méthodes Résolution dynamique Stabilité (que se passe-t-il si la bibliothèque de classes évolue?) Réutilisabilité des objets Test d impact Allocation et libération de mémoire Persistance etc Construction de jeux d essai

113 Autres cas particuliers Achat d un progiciel Adaptation d un logiciel étranger Changement de système d exploitation, de SGBD Intégration des outils au poste de travail etc. 6-Construction de jeux d essai 113

114 Une séance de tests Une séance de test doit être structurée : 1. Test devant le terminal : 2 heures 2. Travail au bureau : 2 heures 1/2 partagées par moitiés : exploitation des résultats : mise à jour journal archivage des listes explication des cas étranges interprétation des erreurs selon la nomenclature préparation de la séance suivante : étude et réalisation des modifications test manuel mise à jour du jeu d essai Penser à la comptabilité (amélioration des prévisions futures) Penser à la gestion de la configuration Construction de jeux d essai

115 Outils de tests MÉTHODE DE TEST DES APPLICATIONS 115

116 Les objectifs du chapitre Définir les outils de test En donner une nomenclature Préparer leur sélection Outils de tests

117 Le testware Acôté du hardware et du software, on voit apparaître une catégorie particulière d outils destinés à aider le processus de tests Notion de «testware» Domaine en évolution rapide (voir annexe) Classification des outils préparation des tests exécution des tests traitement des résultats observation et mesure Ne dispensent pas d une gestion de configuration 7-Outils de tests 117

118 Outils de préparation des tests Générateur de cas de tests : limité àl aspect technique Banque de données de cas de tests Extracteurs à partir de fichiers réels Éditeurs de fichiers Analyseurs statiques (graphe de contrôle) Outils de tests

119 Outils d exécution des tests Capture d interactions et rejeu Mode test en temps réel Simulateurs : exemple : BTS sous IMS Test interactif : exemple : mode test sous TSO Lanceurs de procédures de tests Bouchons (ou muets) 7-Outils de tests 119

120 Outils de traitement des résultats Comparateurs de fichiers Gestionnaires et outils d archivage de résultats Outils de tests

121 Outils d observation et de mesure Compilateurs : trace, debugging mode «Instrumentation» du programme : prévoir les tests au moment de l écriture Calculs de compexité, de métriques Aide à la détermination et au suivi de la couverture 7-Outils de tests 121

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

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

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

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

PLAN CONDUITE DE PROJET

PLAN CONDUITE DE PROJET PLAN CONDUITE DE PROJET Ce guide complète le cours, il donne une marche à suivre qui peut être adaptée si vous choisissez une méthode particulière ETUDE PREALABLE ANALYSE FONCTIONNELLE ANALYSE DETAILLEE

Plus en détail

Analyse et conception des Systèmes d Information. La démarche Merise : La Production Logicielle

Analyse et conception des Systèmes d Information. La démarche Merise : La Production Logicielle Analyse et conception des Systèmes d Information La démarche Merise : La Production Logicielle La production du logiciel Place, objectifs et principes directeurs Christophe.Nicolle@u-bourgogne.fr Introduction

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

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

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

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

Manuel d utilisation 26 juin 2011. 1 Tâche à effectuer : écrire un algorithme 2

Manuel d utilisation 26 juin 2011. 1 Tâche à effectuer : écrire un algorithme 2 éducalgo Manuel d utilisation 26 juin 2011 Table des matières 1 Tâche à effectuer : écrire un algorithme 2 2 Comment écrire un algorithme? 3 2.1 Avec quoi écrit-on? Avec les boutons d écriture........

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

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

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

ITIL V2 Processus : La Gestion des Configurations

ITIL V2 Processus : La Gestion des Configurations ITIL V2 Processus : La Gestion des Configurations Auteur: Fabian PIAU, Master 2 MIAGE, Nantes La Gestion des Configurations est un processus issu d ITIL version 2 qui aide au soutien du service («Service

Plus en détail

4. Créer des compteurs, des curseurs ou des bandes déroulantes : a) Création des objets. b) Affectation à une cellule et réglage du pas.

4. Créer des compteurs, des curseurs ou des bandes déroulantes : a) Création des objets. b) Affectation à une cellule et réglage du pas. Logiciel Excel version Office 2007. Voici une liste non exhaustive de fonctions de ce logiciel en relation avec le stage. Au sommaire : 1. Créer des boutons de raccourci dans une barre d outils: a) Sélection

Plus en détail

LA QUALITE DU LOGICIEL

LA QUALITE DU LOGICIEL LA QUALITE DU LOGICIEL I INTRODUCTION L'information est aujourd'hui une ressource stratégique pour la plupart des entreprises, dans lesquelles de très nombreuses activités reposent sur l'exploitation d'applications

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

Quatrième partie IV. La documentation

Quatrième partie IV. La documentation Quatrième partie IV Les différents types de Constat Il n y a pas de logiciel de qualité sans une documentation de qualité est un outil de communication Les paroles s envolent, les écrits restent Exemple

Plus en détail

Brevet de technicien supérieur Conception et Réalisation en Chaudronnerie Industrielle

Brevet de technicien supérieur Conception et Réalisation en Chaudronnerie Industrielle Brevet de technicien supérieur Conception et Réalisation en Chaudronnerie Industrielle ACTIVITÉS ET TÂCHES PROFESSIONNELLES Les activités professionnelles décrites ci-après, déclinées à partir des fonctions

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

Fonctionnalités d un logiciel de GMAO

Fonctionnalités d un logiciel de GMAO I.1. Introduction : Le caractère stratégique de la panne, préoccupe de plus en plus les responsables de la production ayant à faire face aux équipements complexes qui ne cessent de prendre de l ampleur

Plus en détail

Le projet technique industriel en BTS Électrotechnique

Le projet technique industriel en BTS Électrotechnique Le projet technique industriel en BTS Électrotechnique Le projet technique industriel fait partie intégrante de la formation et de l examen du BTS Electrotechnique par apprentissage. Il consiste, en 192

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

EDUGRAF. L éditeur nouvelle génération. de GRAFCET. Version : 1.0. Edition Août 2012 EduLabo

EDUGRAF. L éditeur nouvelle génération. de GRAFCET. Version : 1.0. Edition Août 2012 EduLabo EDUGRAF L éditeur nouvelle génération de GRAFCET Version : 1.0 Compatible : Win XP, Vista, 7 Mise à jour automatique Grafcet avec : o Divergence convergence OU, o Divergence convergence ET, o Temporisateurs,

Plus en détail

Visual TOM 5.0 Fonctionnalités

Visual TOM 5.0 Fonctionnalités The job scheduling Company Visual TOM 5.0 Fonctionnalités 0 Interfaces existantes Xvision Mode multi-fenêtre Vision spécifique par écran Vision technique / hiérarchique Difficulté à faire évoluer 1 Interfaces

Plus en détail

L application doit être validée et l infrastructure informatique doit être qualifiée.

L application doit être validée et l infrastructure informatique doit être qualifiée. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 Annexe 11: Systèmes informatisés

Plus en détail

C1 S informer. C1.1 Rechercher, Exploiter des documents

C1 S informer. C1.1 Rechercher, Exploiter des documents C1 S informer C1.1 Rechercher, Exploiter des documents Une commande Un besoin exprimé Expliciter le besoin*. Le service rendu, les utilisateurs, les conditions d'utilisation sont listés. Les performances

Plus en détail

Conduite de projets informatiques. Rappel. Plan de la dernière partie. Principes généraux et techniques. Eric Bourreau

Conduite de projets informatiques. Rappel. Plan de la dernière partie. Principes généraux et techniques. Eric Bourreau Conduite de projets informatiques Principes généraux et techniques Eric Bourreau 1 Rappel Définition et terminologie Le découpage d un projet L estimation des charges Les techniques de planification L

Plus en détail

LES TESTS. Les tests. Organisation d un projet de recette Les types de tests Les outils

LES TESTS. Les tests. Organisation d un projet de recette Les types de tests Les outils Les tests Organisation d un projet de recette Les types de tests Les outils Organiser le déroulement des tests Spécifier Exécuter les Cahiers de tests les Cahiers de tests Analyser les résultats Correction

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

I.2: Le test fonctionnel I.2.2 : Le test fonctionnel de logiciel

I.2: Le test fonctionnel I.2.2 : Le test fonctionnel de logiciel I.2: Le test fonctionnel I.2.2 : Le test fonctionnel de logiciel Introduction Notre contexte : pas possible d exprimer toutes les combinaisons de DT. Le test fonctionnel est basé sur la spécification/interface

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

Qualité logicielle, tests, débogage

Qualité logicielle, tests, débogage Qualité logicielle, tests, débogage A. Accro aux tests? Une introduction au test logiciel................ 4 Pourquoi le test logiciel? Des tests, pour gagner du temps! Pour aller plus loin Les objectifs

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

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

Conseils pour l évaluation et l attribution de la note

Conseils pour l évaluation et l attribution de la note Entreprise formatrice Candidat/-e Téléphone: Téléphone: Ce document ne doit en aucun cas être montré au candidat après l attribution des points. Conseils pour l évaluation et l attribution de la note Documentation

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

Génie Logiciel. Hassan El Mansouri

Génie Logiciel. Hassan El Mansouri Hassan El Mansouri 1 Plan du cours Problématique et naissance du génie logiciel Cycle de développement, cycle de vie, cahier des charges Patrons de conception Programmation par composants, réutilisation

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

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

Management qualité Réflexions et Prescriptions essentielles (Extraits VAE Alain THEBAULT 2013)

Management qualité Réflexions et Prescriptions essentielles (Extraits VAE Alain THEBAULT 2013) Management qualité Réflexions et Prescriptions essentielles (Extraits VAE Alain THEBAULT 2013) 1 Le Système qualité La cartographie des processus, qui se situe entre le manuel qualité et les procédures

Plus en détail

Brique BDL Gestion de Projet Logiciel

Brique BDL Gestion de Projet Logiciel Brique BDL Gestion de Projet Logiciel Processus de développement pratiqué à l'enst Sylvie.Vignes@enst.fr url:http://www.infres.enst.fr/~vignes/bdl Poly: Computer elective project F.Gasperoni Brique BDL

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

SOCLE COMMUN - La Compétence 3 Les principaux éléments de mathématiques et la culture scientifique et technologique

SOCLE COMMUN - La Compétence 3 Les principaux éléments de mathématiques et la culture scientifique et technologique SOCLE COMMUN - La Compétence 3 Les principaux éléments de mathématiques et la culture scientifique et technologique DOMAINE P3.C3.D1. Pratiquer une démarche scientifique et technologique, résoudre des

Plus en détail

Génie Logiciel. Hassan El Mansouri. Plan du cours. Problématique du Génie Logiciel

Génie Logiciel. Hassan El Mansouri. Plan du cours. Problématique du Génie Logiciel Hassan El Mansouri 1 Plan du cours Cycle de développement, cycle de vie, cahier des charges Patrons de conception Programmation par composants, réutilisation de composants Gestion des exceptions Stratégies

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

Claude Delannoy. Exercices C++ en langage. 3 e édition. Groupe Eyrolles, 1997, 1999, 2007, ISBN : 978-2-212-12201-5

Claude Delannoy. Exercices C++ en langage. 3 e édition. Groupe Eyrolles, 1997, 1999, 2007, ISBN : 978-2-212-12201-5 Claude Delannoy Exercices en langage C++ 3 e édition Groupe Eyrolles, 1997, 1999, 2007, ISBN : 978-2-212-12201-5 Chapitre 3 Les fonctions Rappels Généralités Une fonction est un bloc d instructions éventuellement

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

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

Analyse,, Conception des Systèmes Informatiques

Analyse,, Conception des Systèmes Informatiques Analyse,, Conception des Systèmes Informatiques Méthode Analyse Conception Introduction à UML Génie logiciel Définition «Ensemble de méthodes, techniques et outils pour la production et la maintenance

Plus en détail

Première STMG1 2014-2015 progression. - 1. Séquence : Proportion d une sous population dans une population.

Première STMG1 2014-2015 progression. - 1. Séquence : Proportion d une sous population dans une population. Première STMG1 2014-2015 progression. - 1 Table des matières Fil rouge. 3 Axes du programme. 3 Séquence : Proportion d une sous population dans une population. 3 Information chiffrée : connaître et exploiter

Plus en détail

Evaluation et tests d une interface graphique

Evaluation et tests d une interface graphique Evaluation et tests d une interface graphique Tâcheconsidérée considérée Utilisateurs Poste de travail Domaine d activité Analyse de la tâche Contexte de travail Stéréotype d utilisateur Critères d utilité

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

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

LES OUTILS D ALIMENTATION DU REFERENTIEL DE DB-MAIN

LES OUTILS D ALIMENTATION DU REFERENTIEL DE DB-MAIN LES OUTILS D ALIMENTATION DU REFERENTIEL DE DB-MAIN Les contenues de ce document sont la propriété exclusive de la société REVER. Ils ne sont transmis qu à titre d information et ne peuvent en aucun cas

Plus en détail

ATELIER ALGORITHME PREMIERS PAS Journée d information sur les nouveaux programmes de Première S-ES 2010-2011

ATELIER ALGORITHME PREMIERS PAS Journée d information sur les nouveaux programmes de Première S-ES 2010-2011 Pour me contacter : irene.rougier@ac-clermont.fr 1. Introduction ATELIER ALGORITHME PREMIERS PAS Journée d information sur les nouveaux programmes de Première S-ES 2010-2011 De nombreux documents et informations

Plus en détail

Installer Joomla. 2013 Pearson France Joomla! Le guide officiel Jennifer Marriott, Elin Waring

Installer Joomla. 2013 Pearson France Joomla! Le guide officiel Jennifer Marriott, Elin Waring 3 Installer Joomla Dans ce chapitre, nous procéderons au téléchargement et à l installation manuelle de Joomla, et nous expliquerons la configuration de base. Les captures d écran et les instructions font

Plus en détail

L informatique en BCPST

L informatique en BCPST L informatique en BCPST Présentation générale Sylvain Pelletier Septembre 2014 Sylvain Pelletier L informatique en BCPST Septembre 2014 1 / 20 Informatique, algorithmique, programmation Utiliser la rapidité

Plus en détail

Circuit du médicament informatisé

Circuit du médicament informatisé Circuit du médicament informatisé Points de vigilance axe technique SOMMAIRE... 1 FICHE N 1- DISPONIBILITE ET PERFORMANCE... 2 FICHE N 2- ENVIRONNEMENT DE TEST... 4 FICHE N 3- VERSIONNING... 5 FICHE N

Plus en détail

Découverte de l ordinateur. Explorer l ordinateur et gérer ses fichiers

Découverte de l ordinateur. Explorer l ordinateur et gérer ses fichiers Découverte de l ordinateur Explorer l ordinateur et gérer ses fichiers SOMMAIRE I L ORDINATEUR ET L EXPLORATEUR... 3 1.1 : PRESENTATION ET GENERALITES... 3 1.2 : CONNAÎTRE LES PROPRIETES D UN ELEMENT...

Plus en détail

IFT785 Approches Orientées Objets

IFT785 Approches Orientées Objets IFT785 Approches Orientées Objets FINAL Été 2002 Début : Lundi 19 août 2002 à 9h00 am Remise : Jeudi 22 août 2002 à 9h00 am Professeur : Sylvain GIROUX Note : /100 points Remarques : L examen est secret.

Plus en détail

ISO 9001:2000. CHAPITRE par CHAPITRE

ISO 9001:2000. CHAPITRE par CHAPITRE ISO 9001:2000 PARTIE 2-3 CHAPITRE par CHAPITRE 9001:2000, domaine Satisfaction du client par la prévention des N.C. (ISO 9001:1994) Appliquer efficacement le système pour répondre aux besoins du client

Plus en détail

Qualité du logiciel: Méthodes de test

Qualité du logiciel: Méthodes de test Qualité du logiciel: Méthodes de test Matthieu Amiguet 2004 2005 Analyse statique de code Analyse statique de code Étudier le programme source sans exécution Généralement réalisée avant les tests d exécution

Plus en détail

Chargement de processus Allocation contigüe Allocation fragmentée Gestion de pages. Gestion mémoire. Julien Forget

Chargement de processus Allocation contigüe Allocation fragmentée Gestion de pages. Gestion mémoire. Julien Forget Julien Forget Université Lille 1 École Polytechnique Universitaire de Lille Cité Scientifique 59655 Villeneuve d Ascq GIS 3 2011-2012 1 / 46 Rôle du gestionnaire de mémoire Le gestionnaire de mémoire a

Plus en détail

Concours EXTERNE d ingénieur des systèmes d information et de communication. «Session 2009»

Concours EXTERNE d ingénieur des systèmes d information et de communication. «Session 2009» Concours EXTERNE d ingénieur des systèmes d information et de communication «Session 2009» Meilleure copie "Rapport Technique" Thème : conception et développement logiciel Note : 15,75/20 Rapport technique

Plus en détail

FILIÈRE METHODOLOGIE & PROJET

FILIÈRE METHODOLOGIE & PROJET FILIÈRE METHODOLOGIE & PROJET 109 Gestion de projet METHODOLOGIE ET PROJET Durée 3 jours Conduite de projet COND-PRO s Intégrer les conditions de réussite d une démarche de management par projet. Impliquer

Plus en détail

INTRODUCTION AUX METHODES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES

INTRODUCTION AUX METHODES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES INTRODUCTION AUX METHODES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES Les contenus de ce document sont la propriété exclusive de la société REVER. Ils ne sont transmis qu à titre d information et

Plus en détail

Informatique TP1 : Découverte de Python CPP 1A

Informatique TP1 : Découverte de Python CPP 1A Informatique TP1 : Découverte de Python CPP 1A Romain Casati, Wafa Johal, Frederic Devernay, Matthieu Moy Avril - juin 2014 1 Découverte de l IDE : IDLE IDLE est un environnement de développement (Integrated

Plus en détail

Spécifications des exigences d'un logiciel (Adapté de la norme IEEE 830-1993)

Spécifications des exigences d'un logiciel (Adapté de la norme IEEE 830-1993) Spécifications des exigences d'un logiciel (Adapté de la norme IEEE 830-1993) Ce document suggère un ensemble d éléments à préciser pour les exigences d'un système logiciel. Il débute par une Page de titre,

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

ET 24 : Modèle de comportement d un système Boucles de programmation avec Labview.

ET 24 : Modèle de comportement d un système Boucles de programmation avec Labview. ET 24 : Modèle de comportement d un système Boucles de programmation avec Labview. Sciences et Technologies de l Industrie et du Développement Durable Formation des enseignants parcours : ET24 Modèle de

Plus en détail

Mise en œuvre des Assistants d Optymo

Mise en œuvre des Assistants d Optymo d Optymo Notes de lecture : dans ce document, les textes soulignés font référence aux libellés des fenêtres ou aux libellés associés à des boutons d Optymo. Les textes en caractères gras à des informations

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

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

TechTool Protogo 4. 1- Manuel TechTool Protogo 4

TechTool Protogo 4. 1- Manuel TechTool Protogo 4 TechTool Protogo 4 1- Manuel TechTool Protogo 4 Notes légales 2008-2013 Micromat Incorporated. Tous droits réservés. 2008-2013 TRI-EDRE. Tous droits réservés pour la traduction française du logiciel et

Plus en détail

«Appropriation de la norme EN9100 par les entreprises et pistes d amélioration»

«Appropriation de la norme EN9100 par les entreprises et pistes d amélioration» Conférence sur la certification EN 9100 «Appropriation de la norme EN9100 par les entreprises et pistes d amélioration» 16/12/2014 Christelle REBILLET Chef de Produit - AFNOR Certification Programme Contexte

Plus en détail

Formation Gestion concours Version 2011.1.2 du 3 février 2011

Formation Gestion concours Version 2011.1.2 du 3 février 2011 Formation Gestion concours Version 2011.1.2 du 3 février 2011 PROGRAMME - Présentation du logiciel - Installation du logiciel, identification des éléments du logiciel - Récupération des licenciés de la

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

Évaluation et implémentation des langages

Évaluation et implémentation des langages Évaluation et implémentation des langages Les langages de programmation et le processus de programmation Critères de conception et d évaluation des langages de programmation Les fondations de l implémentation

Plus en détail

Guide d installation UNIVERSALIS 2016

Guide d installation UNIVERSALIS 2016 Guide d installation UNIVERSALIS 2016 (Windows) Nous vous recommandons de lire ce document avant de commencer l installation d UNIVERSALIS 2016 sur Windows. Vous y trouverez la description de la procédure

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

TP C# Prise en main : interface graphique, animation

TP C# Prise en main : interface graphique, animation TP C# Prise en main : interface graphique, animation 1. Hello World! Description : Vous allez construire une application graphique dotée d un unique bouton qui affiche le message «Hello World!» lorsque

Plus en détail

Intelligence Artificielle et Systèmes Multi-Agents. Badr Benmammar bbm@badr-benmammar.com

Intelligence Artificielle et Systèmes Multi-Agents. Badr Benmammar bbm@badr-benmammar.com Intelligence Artificielle et Systèmes Multi-Agents Badr Benmammar bbm@badr-benmammar.com Plan La première partie : L intelligence artificielle (IA) Définition de l intelligence artificielle (IA) Domaines

Plus en détail

ACCOMPAGNEMENT A LA CERTIFICATION ISO 9001 DE L AGENCE POUR LA RECHERCHE ET L INNOVATION EN CHAMPAGNE-ARDENNE - CARINNA

ACCOMPAGNEMENT A LA CERTIFICATION ISO 9001 DE L AGENCE POUR LA RECHERCHE ET L INNOVATION EN CHAMPAGNE-ARDENNE - CARINNA 1 APPEL D OFFRES ACCOMPAGNEMENT A LA CERTIFICATION ISO 9001 DE L AGENCE POUR LA RECHERCHE ET L INNOVATION EN CHAMPAGNE-ARDENNE - CARINNA JUILLET 2013 2 1. OBJET DE L APPEL D OFFRE Réalisation d un accompagnement

Plus en détail

Sélection du contrôleur

Sélection du contrôleur Démo CoDeSys - 1 - 1. Configuration de l environnement de travail : Lancer le logiciel CoDeSys Fichier Nouveau Lors de la première utilisation, une boîte de dialogue apparaît permettant la sélection du

Plus en détail

BACCALAURÉAT PROFESSIONNEL ÉPREUVE DE MATHEMATIQUES. EXEMPLE DE SUJET n 1

BACCALAURÉAT PROFESSIONNEL ÉPREUVE DE MATHEMATIQUES. EXEMPLE DE SUJET n 1 Exemple de sujet n 1 Page 1/7 BACCALAURÉAT PROFESSIONNEL ÉPREUVE DE MATHEMATIQUES EXEMPLE DE SUJET n 1 Ce document comprend : Pour l examinateur : - une fiche descriptive du sujet page 2/7 - une fiche

Plus en détail

BIBLIOTHÈQUE ET ARCHIVES CANADA PLAN D ÉVALUATION 2008-2009

BIBLIOTHÈQUE ET ARCHIVES CANADA PLAN D ÉVALUATION 2008-2009 BIBLIOTHÈQUE ET ARCHIVES CANADA PLAN D ÉVALUATION 2008-2009 Division du rendement et de l information institutionnels Direction générale de la gestion intégrée Présenté au : Comité d évaluation de Bibliothèque

Plus en détail

Référence Etnic Architecture des applications

Référence Etnic Architecture des applications Référence Etnic Architecture des applications Table des matières 1. Introduction... 2 2. Architecture... 2 2.1 Démarche générale... 2 2.2 Modèle d architecture... 3 2.3 Découpe d une architecture applicative...

Plus en détail

Le mot «algorithme» vient du nom de l auteur persan Al-Khuwarizmi (né vers 780 - mort vers 850) Une définition: «un algorithme est une suite finie de

Le mot «algorithme» vient du nom de l auteur persan Al-Khuwarizmi (né vers 780 - mort vers 850) Une définition: «un algorithme est une suite finie de Le mot «algorithme» vient du nom de l auteur persan Al-Khuwarizmi (né vers 780 - mort vers 850) Une définition: «un algorithme est une suite finie de règles à appliquer dans un ordre déterminé à un nombre

Plus en détail

Calculatrice virtuelle HP Prime

Calculatrice virtuelle HP Prime Calculatrice virtuelle HP Prime Microsoft est une marque commerciale du groupe de sociétés Microsoft. Les informations contenues dans ce document peuvent être modifiées sans préavis. Les garanties relatives

Plus en détail

Introduction à l informatique en BCPST

Introduction à l informatique en BCPST Introduction à l informatique en BCPST Alexandre Benoit BCPST L informatique en BCPST «L enseignement de l informatique en classes préparatoires de la filière BCPST a pour objectif d introduire puis de

Plus en détail

Introduction : Le logiciel gère une pile des éléments textes du presse-papier de Windows.

Introduction : Le logiciel gère une pile des éléments textes du presse-papier de Windows. B. MALETTE : Fichier d'aide du logiciel «Presse papier» p. 1 Création mai 2013 dernière révision V 1.5._._ en mai 2015 Généralités : Le présent logiciel est libre de droit, il ne peut être vendu et reste

Plus en détail

PROJET DE CONCEPTION (6GIN333)

PROJET DE CONCEPTION (6GIN333) PROJET DE CONCEPTION (6GIN333) Cours #7 Hiver 2012 Ordre du jour Gestion des risques Introduction Concepts & définitions Processus d analyse Outils & méthodes Résultats Pause de 15 minutes Suivit des coûts

Plus en détail

P s a sep e o p r o t S e S r e vi v ce c s Fabrice Dubost

P s a sep e o p r o t S e S r e vi v ce c s Fabrice Dubost Passeport Services Fabrice Dubost 2.6 Gestion des Mises en Production ITIL, Soutien des services Entreprise, Clients et Utilisateurs Outil de Supervision Dysfonctionnements Questions / Renseignements Incidents

Plus en détail

Composant GANTT. Compétences à mettre en œuvre

Composant GANTT. Compétences à mettre en œuvre Composant GANTT C# Compétences à mettre en œuvre C4.1.6.1 Mettre en place et exploiter un environnement de développement C4.1.6.2 Mettre en place et exploiter un environnement de test C4.1.7.1 Développer

Plus en détail

Systèmes et réseaux d information et de communication

Systèmes et réseaux d information et de communication 233 DIRECTEUR DES SYSTÈMES ET RÉSEAUX D INFORMATION ET DE COMMUNICATION Code : SIC01A Responsable des systèmes et réseaux d information FPESIC01 Il conduit la mise en œuvre des orientations stratégiques

Plus en détail

I/ PRESENTATION GENERALE DE LA QUALITE : LES CONCEPTS QUALITE EN DIAGNOSTIC

I/ PRESENTATION GENERALE DE LA QUALITE : LES CONCEPTS QUALITE EN DIAGNOSTIC Généralités 3 I/ PRESENTATION GENERALE DE LA QUALITE : LES CONCEPTS QUALITE EN DIAGNOSTIC La multiplicité des acceptations de la notion de Qualité est source de bien de malentendus et de réticences associé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

Guide d utilisation du logiciel Regard

Guide d utilisation du logiciel Regard Guide d utilisation du logiciel Regard version complète LE MODULE DE CIRCULATION 0 Conception : Chantal Vézina, bibliothécaire Réalisation : Bibliothécaires, Commission scolaire de Laval Équipe du CRP,

Plus en détail