Interaction Homme Machine(IHM)



Documents pareils
LES INTERFACES HOMME-MACHINE

2. Activités et Modèles de développement en Génie Logiciel

Processus d Informatisation

Le génie logiciel. maintenance de logiciels.

Cours Gestion de projet

GESTION DE PROJET SÉANCE 2 : LES CYCLE DE VIE D'UN PROJET

LOG2420 Analyse et conception d interfaces utilisateur

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

LA QUALITE DU LOGICIEL

Analyse,, Conception des Systèmes Informatiques

2.DIFFERENTS MODELES DE CYCLE DE VIE

Gestion Projet. Cours 3. Le cycle de vie

Conduite de projets informatiques Développement, analyse et pilotage (2ième édition)

BOOK REFERENCES ERGONOMIQUES Gfi Informatique

Brique BDL Gestion de Projet Logiciel

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

GL Processus de développement Cycles de vie

Outil de gestion et de suivi des projets

Cours de Java. Sciences-U Lyon. Java - Introduction Java - Fondamentaux Java Avancé.

Qu'est-ce que le BPM?

Nom-Projet MODELE PLAN DE MANAGEMENT DE PROJET

Architecture d'entreprise : Guide Pratique de l'architecture Logique

Macroscope et l'analyse d'affaires. Dave Couture Architecte principal Solutions Macroscope

Génie logiciel (Un aperçu)

Enquête 2014 de rémunération globale sur les emplois en TIC

PEPI GPI (Gestion de Projet Informatique) - Note de Cadrage décembre

Plan de notre intervention 1. Pourquoi le test de charge? 2. Les différents types de tests de charge 1.1. Le test de performance 1.2.

Prestations d audit et de conseil 2015

Forum AMOA ADN Ouest. Présentation du BABOK. 31 Mars 2013 Nadia Nadah

- Le Diagramme de Gantt. - Le Diagramme de Pert - La Méthode QQCQCCP - La Méthode MOSI - Cahier des charges fonctionnel

Introduction au génie logiciel

Chapitre I : le langage UML et le processus unifié

M1if22 - Logiciels éducatifs Conception & rôle de l enseignant

LEXIQUE. Extraits du document AFNOR (Association Française de Normalisation) NF EN ISO 9000 octobre 2005

LA GESTION DE PROJET INFORMATIQUE

ISO/CEI Technologies de l information Gestion des actifs logiciels. Partie 1: Procédés et évaluation progressive de la conformité

Programme «Analyste Programmeur» Diplôme d état : «Développeur Informatique» Homologué au niveau III (Bac+2) (JO N 176 du 1 août 2003) (34 semaines)

Anticiper pour avoir une innovation d'avance : le leitmotiv de Pierre Jouniaux, entrepreneur du big data!

Processus de Développement Logiciel

Annexe sur la maîtrise de la qualité

Types de REA produites dans le cadre de la séquence pédagogique

PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN

modélisation solide et dessin technique

Bertrand Cornanguer Sogeti

LE PLAN D'AMÉLIORATION DE LA FONCTION MARKETING

StorageTek Tape Analytics

c o n c e p t i o n Un savoir-faire et des experts pour concevoir des sites efficaces et durables

Ingénierie et qualité du logiciel et des systèmes

Spécifications de l'offre Surveillance d'infrastructure à distance

LA GESTION DE PROJET INFORMATIQUE

Gestion de Projet. Génie Logiciel. Renaud Marlet. LaBRI / INRIA. (d'après A.-M. Hugues) màj 19/04/2007

Processus de Développement Logiciel

UCL. Université catholique de Louvain. Métro Web : logiciel de support à l'évaluation de la qualité ergonomique des sites web.

Introduction. Les articles de la presse spécialisée tendent à nous laisser penser que c est en effet le cas :

Méthodologie de mise en place de

Développement d'un projet informatique

Plan d action SMB d une Approche Agile de la BITM Pour les PME

Administrateur de Parc PC

Logiciel Libre Cours 3 Fondements: Génie Logiciel

Le management des risques de l entreprise Cadre de Référence. Synthèse

ANGULAR JS AVEC GDE GOOGLE

Méthodes de développement. Analyse des exigences (spécification)

Génie logiciel pour le commerce électronique Hiver 2003 Prof.: Julie Vachon

basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB Olivier Augereau Formation UML

ITIL v3. La clé d une gestion réussie des services informatiques

Méthodologies de développement de logiciels de gestion

1. Considérations sur le développement rapide d'application et les méthodes agiles

Gé nié Logiciél Livré Blanc

MODALITES DE SUIVI DU PROJET ANNUEL DU MASTER 2 SOLUTIONS INFORMATIQUES LIBRES

Technologie Web. Conception de sites Web. Alexandre Pauchet. INSA Rouen - Département ASI. INSA - ASI TechnoWeb : Rappels UML 1/21

IFT2255 : Génie logiciel

OMGL6 Dossier de Spécifications

Génie Logiciel LA QUALITE 1/5 LA QUALITE 3/5 LA QUALITE 2/5 LA QUALITE 4/5 LA QUALITE 5/5

Scrum Une méthode agile pour vos projets

Concepteur Développeur Informatique

SEMINAIRES INTERNATIONAUX

Analyse et Conception objet du logiciel Analyse et conception objet du logiciel : Méthode de conception objet et notation UML.

Simulation de systèmes. Logiciel de simulation

Baccalauréat technologique

Fiche méthodologique Rédiger un cahier des charges

Service de réplication des données HP pour la gamme de disques Continuous Access P9000 XP

M Études et développement informatique

Master Informatique Aix-Marseille Université

Identification du module

Céramique. Apprentissage. CFA Céramique Bourgogne. CFA Céramique Limousin. Institut Céramique Française

Gestion de projet. Définition. Caractérisation

Méthodes Agiles et gestion de projets

Jean-Louis FELIPE (Né le 20/11/1960) Consultant sénior ITSM

Développement itératif, évolutif et agile

Contrôle interne et organisation comptable de l'entreprise

Gestion de projets logiciels. Xavier Dubuc

La plate-forme DIMA. Master 1 IMA COLI23 - Université de La Rochelle

ALDEA ET SYSTEMES D INFORMATION

Maximisons les performances de votre stratégie digitale

Méthode d'organisation de la veille juridique

Méthodes de développement

Annexe : La Programmation Informatique

Le Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer

Enjeux du déploiement d'un Progiciel de Gestion Intégré (PGI) en PME / PMI

LA PROCEDURE D'EVALUATION A.NA.PSY.p.e. EST LE RESULTAT D'UNE RECHERCHE

Transcription:

Interaction Homme Machine(IHM) Cours 1 Introduction générale Conception 1

Introduction Organisation du cours : 4 grandes parties : 1. Systèmes interactifs : Intérêt, Conception centrée utilisateur Point de vue du génie logiciel : modèles, architectures logicielles, évaluation 2. Modèles utilisateurs : Point de vue des sciences cognitives : MPH + lois 3. Mise en œuvre de ces interfaces : GUI et NUI : chartes graphiques, accessibilité, handicap 4. Multimodalité Interfaces du futur, combinaison de modes, interaction gestuelle 2

Cours 1 Conception des IHM 3

Enquêtes Industrie du logiciel : même constat, 20 ans après 1979 : enquête de l US Government Accounting Office 2% des dépenses en logiciel pour des softs livrés et utilisés 25% des softs jamais livrés 50% des softs livrés mais jamais utilisés 1995 : enquête de Software Engineering Institute Plus de 1/3 des projets d envergure de développement de logiciels sont annulés En moyenne, un projet dure deux fois plus longtemps que prévu Plus de ¾ des applications informatiques d envergure présentent des défaillances opérationnelles et ne fonctionnent pas tel que prévu initialement Stéphane Conversy, Conception Participative 4

Industrie du logiciel Mitchell Kapor rapporte Solution proposée déjà en 1979 : le Génie Logiciel Problème : le génie logiciel a créé l illusion que la clé de la conception réside dans l application d un processus rigoureux permettant de transformer les besoins en un système Constat : manque de place accordée à l utilisateur dans les schémas de développement de ces logiciels Stéphane Conversy, Conception Participative 5

Importance de l utilisateur Déjà en 1962, Douglas Engelbart révélait cette importance dans Augmenting Human Intellect : A Conceptual Framework "By augmenting man's intellect we mean increasing the capability of a man to approach a complex problem situation, gain comprehension to suit his particular needs, and to derive solutions to problems" Stéphane Conversy, Conception Participative 6

C est quoi un système interactif? Wegner,1997, en donne une première définition Un système interactif est un système dont le fonctionnement dépend d'informations fournies par un environnement externe qu'il ne contrôle pas Les systèmes interactifs sont également appelés ouverts, par opposition aux systèmes fermés - ou autonomes - dont le fonctionnement peut être entièrement décrit par des algorithmes Stéphane Conversy, Conception Participative 7

Interface vs Système Interactif d après S. Conversy L'interface est l'ensemble des dispositifs matériels et logiciels qui permettent à un utilisateur de commander, contrôler, superviser un système interactif Stéphane Conversy, Conception Participative 8

Pourquoi interaction et pas interface? Ce n est pas seulement l interface qui compte, mais l interaction : la séquence d actions nécessaires pour accomplir une tâche l adéquation entre le système et le contexte dans lequel il est utilisé Stéphane Conversy, Conception Participative 9

L'Interaction Homme- Machine S. Conversy la définit ainsi : L'Interaction Homme-Machine est une discipline consacrée à la conception, à la mise en oeuvre et à l'évaluation de systèmes informatiques interactifs destinés à des utilisateurs humains ainsi qu'à l'étude des principaux phénomènes qui les entourent Stéphane Conversy, Conception Participative 10

Pourquoi s'intéresser à l'ihm? (d'après Bill Buxton) Environ 70% des coûts d un logiciel interactif sont consacrés à la conception de l interface utilisateur Bill Buxton (1991) Stéphane Conversy, Conception Participative 11

Pourquoi s'intéresser à l'ihm? (d'après Bill Buxton) 1. Le matériel progresse sans cesse (Moore) 2. Les fonctionnalités promises aussi (Buxton) 3. L homme, lui, ne change pas, ou presque Limites des capacités de perception et d'action : le temps de la frustration! Stéphane Conversy, Conception Participative 12

Le Design du S.I. M. Kapor désigne le métier Pour créer un S.I. il ne faut pas d informaticien mais un designer Problème Le métier de designer n existe pas! Qu est-ce que le design? Mitchell Kapor : It s where you stand with a foot in two worlds: the world of technology and the world of people and human purposes and you try to bring the two together Les disciplines liées au design ont pour but de créer des artefacts destinés à être utilisés pas les êtres humains Stéphane Conversy, Conception Participative 13

Le Design du S.I. Apport du design : Mitchell Kapor Firmness (Solidité, Fiabilité): A program should not have any bugs that inhibit its function Commodity (Servitude): A program should be suitable for the purposes for which it was intended Delight (Plaisir): The experience of using the program should be a pleasurable one Stéphane Conversy, Conception Participative 14

Le design n est qu un élément de la construction du S.I. : une approche pluridisciplinaire 15

L interaction 16

Interaction Forme classique de l interaction : relation directe Stéphane Conversy, Conception Participative 17

18 Interaction Maintenant : on parle d interaction située On tient compte du contexte On signale des artefacts qu on corrige Stéphane Conversy, Conception Participative

Exemples de situations Poste fixe Mobilité Nomadisme Interagir à travers le réseau, vidéo conf Environnement urbanisé Chercher son chemin : demander aux gens, lire les panneaux C. Faure 19

L interaction peut se faire avec plusieurs acteurs Une machine Un monde réel augmenté Une personne Des personnes (réseau) Un monde virtuel C. Faure 20

L interaction se donne pour objectif de réaliser un système interactif qui sera utilisé parce que : il répond à des besoins ou à des envies d'usage Les réponses sont satisfaisantes pour les utilisateurs parce qu il prend en compte les utilisateurs On parle dans ce cas de conception centrée sur les utilisateurs avec une équipe un modèle de conception la participation des utilisateurs (potentiels) C. Faure 21

L équipe : doit être pluridisciplinaire C. Faure En effet, réaliser un système interactif nécessite des compétences dans plusieurs domaines Informatique Domaine d'application Ergonomie Psychologie Sociologie, Droit Infrastructure de communication, logiciels (traitements de données, interfaces graphiques, assistance...) Spécifications des besoins, des contraintes... Modèle des tâches - Profil des utilisateurs - Évaluation Interaction, dialogue - Perception - Raisonnement Transformation des modes de travail, de vie - Droits, libertés, devoirs, étique 22

La conception centrée utilisateur (CCU) Deux principes fondateurs On passe de l étude de la fonction (programme) à celle de l usage À quoi sert ce système? Comment s en sert-on? L utilisateur est l évaluateur Définit la métrique permettant de mesurer la valeur d un système L ingénieur et la direction ne sont plus les seuls concepteurs Stéphane Conversy, Conception Participative 23

CCU veut dire concevoir pour les utilisateurs, c est-à-dire : Comprendre le travail des utilisateurs Que font-ils? Comment le savoir? Demander aux utilisateurs Interviews, questionnaires, etc. Observer les utilisateurs Études d'utilisabilité, observation en environnement réel, etc. Générer des idées avec les utilisateurs 24

CCU veut dire que la conception va suivre ce cycle où l on va passer de l observation 25

CCU veut dire que la conception sera participative, c est-à-dire : L utilisateur intervient dans toutes les phases Analyse, conception, évaluation Le processus est itératif (i.e. progressif) Cette forme de conception permet de redéfinir le problème et la résolution du problème comprendre l interaction dans un contexte réel intégrer le contexte dans le système 26

Y a-t-il une démarche pour la conception d une C.C.U.? Présence de norme? Lorsqu on démarre la conception d'un produit, quel qu'il soit, il est important de suivre les lois régissant ce produit Ici Il est question d'une norme permettant d'encadrer la conception d'un système interactif (interface Web, un logiciel, etc.) afin que ce dernier soit conçu avec une vision centrée utilisateur Il s'agit de la norme ISO 13407-1999 http://www.agentsolo.com/ca/fr/membre/shumac/capsules/102596.jsp 27

Cadrage donné par la norme ISO 13407 La norme ISO 13407 Donne des conseils (directives) en vue de concevoir des dispositifs bénéficiant d'une bonne utilisabilité...c.à.d. (le) degré selon lequel un produit peut être utilisé, par des utilisateurs identifiés, pour atteindre des buts définis avec efficacité, efficience et satisfaction, dans un contexte d'utilisation spécifié... [ISO 9241-11 :1998] 28

Cadrage donné par la norme ISO 13407 Étapes proposées par la norme pour aboutir à une telle conception 1. Identifier la nécessité d'une conception centrée sur l'opérateur humain 2. Comprendre et spécifier le contexte d'utilisation 3. Spécifier les exigences liées à l'utilisateur et à l'organisation 4. Proposer des solutions de conception 5. Évaluer les conceptions par rapport aux exigences 6. Le système répond aux exigences de l'utilisateur et de l'organisation La norme ISO 13407 est un cycle itératif et les étapes 2 à 5 sont effectuées en boucle. Lorsque le système répond aux besoins, l'étape 6, le cycle est terminé 29

Cadrage donné par la norme ISO 13407 Techniques Afin de mener à terme la conception d'un système interactif selon cette norme, plusieurs techniques sont utilisées. Par exemple, L'analyse de la tâche permet de mieux comprendre et cibler le contexte d'utilisation ainsi que les exigences liées à l'utilisateur et à l'organisation Les maquettes et les prototypes sont conçus en suivant des normes et lignes directrices établies L'évaluation heuristique (ou évaluation experte) consiste en une inspection systématique des éléments constituant l'interface d'un dispositif interactif au moyen d'une grille d'évaluation Le test d'utilisabilité consiste en l'exécution de scénarios prédéterminés par des utilisateurs représentatifs de ceux visés. L'analyste observe et recueille des données lors des tests. Ceci permet donc d'évaluer les solutions par rapport aux exigences. La norme ISO 13407 permet la participation active des utilisateurs et une compréhension claire des exigences liées à l'utilisateur et à la tâche 30

Cadrage donné par la norme ISO 13407 Raisons d'utiliser cette norme dans le développement de ces interfaces Facilité de compréhension et d'utilisation de l'interface Satisfaction de l'utilisateur Productivité et efficience opérationnelle Qualité, esthétique et impact du produit, et avantages concurrentiels 31

La norme ISO 13407 Que dit réellement la norme? Les utilisateurs finaux sont les mieux placés pour évaluer et influencer le développement d'un produit Si le produit final correspond à leurs besoins, envies et caractéristiques, il aura toutes les chances d'être adopté, et c'est bien le but ultime de tout produit La conception centrée utilisateur impose que le développement du produit doit être guidé par les besoins des utilisateurs plutôt que par les possibilités technologiques 32

La norme ISO 13407 Étapes du processus de CCU Un processus de CCU typique comprend trois phases principales mises en oeuvre de façon itérative : ANALYSE DES BESOINS CONCEPTION EVALUATION De façon plus précise, l'iso 13407 définit les étapes du cycle de conception centrée utilisateur comme suit : 33

Le processus de CCU DEBUT Planifier le processus de conception centrée utilisateur FIN Les exigences sont atteintes Évaluer les solutions au regard des exigences prédéfinies Comprendre et spécifier le contexte d utilisation Les exigences ne sont pas atteintes Comprendre et spécifier les exigences utilisateurs et organisationnelles Produire des solutions de conception 34

Ce que l'on doit retenir des étapes de construction d un S.I. en CCU Étape 1 : analyse des besoins : Modèle utilisateur L utilisateur type Définition des besoins Cahier des charges Étape 2 : conception : Modèle de conception Définition de l architecture globale Définition des tâches utilisateur Réalisation du prototype Étape 3 : évaluation de l interface Tests avec différents utilisateurs Modifications apportées 35

Le modèle utilisateur 36

Étape 1 : catégorisation des types d'utilisateurs 1. Identifiés Améliorer l'interface d'un logiciel déjà utilisé 2. Ciblés Proposer de nouveaux moyens adaptés à un secteur d'activités 3. Potentiels (?) Quels services et applications pour exploiter une technologie existante? C. Faure 37

Étape 2 : meilleure connaissance des utilisateurs Par les besoins Quels besoins et envies d'usage? Par des questionnements Propositions de prototypes Entretiens, interviews dirigées Enquêtes Observations des activités Scénarios... C. Faure 38

Étape 3 : classification des utilisateurs / interfaces L'utilisateur naïf Exigent vis-à-vis de sa machine N'en connaît pas (vraiment) le fonctionnement Son but : utiliser l'application sans trop s'appesantir sur l'apprentissage du logiciel L'interface pour ce genre d'utilisateur doit être : Auto-descriptive et le guidage très développé i.e. chaque étape doit être clairement présentée pour le diriger immédiatement vers la fonction ou la requête qu'il désire accomplir (ex. Minitel) 39

Étape 3 : classification des utilisateurs / interfaces L'utilisateur expert Expert soit dans la tâche à accomplir soit dans l'utilisation de l'interface L'interface pour ce genre d'utilisateur : ne doit évidemment pas avoir les mêmes caractéristiques que dans le cas de l'utilisateur naïf son temps est précieux, par csq, l'interface doit être optimisée au maximum 40

Étape 3 : classification des utilisateurs / interfaces L interface : l utilisateur moyen Plus expérimenté que l'utilisateur naïf mais ne possède pas encore les compétences de l'utilisateur professionnel Il utilise un nombre restreint de fonctions qui sont très souvent les mêmes L'interface pour ce genre d'utilisateur : lui fournir des raccourcis qui contribuent à le rendre de + en + productif et une aide en ligne lui permettant d'accroître sa compétence dans l'application 41

Les modèles de conception 42

Pourquoi un modèle? pour structurer et gérer un SI : un processus complexe faisant intervenir plusieurs compétences pour réaliser un produit répondant à des besoins qui soit satisfaisant pour les utilisateurs C. Faure 43

Que dit le modèle? ce qu'il faut faire (i.e. les blocs d'activité) Cahiers des charges Choix techniques Découpage en modules Codage Validation des modules Intégration Évaluations suivant quelle organisation Plusieurs modèles : extraits du Génie logiciel C. Faure 44

Le modèle en cascade Hérité de l'industrie du Bâtiment Il repose sur les hypothèses suivantes : On ne peut pas construire la toiture avant les fondations Les conséquences d'une modification en amont du cycle ont un impact majeur sur les coûts en aval Les phases de développement sont effectuées simplement les unes après les autres, avec un retour sur les précédentes, voire au tout début du cycle Analyse des besoins Cahier des charges Choix de conception du système et du logiciel Utilisateurs Codage et tests des modules Intégration et test du système C. Faure 45

Le modèle en cascade exécute des phases qui ont pour caractéristiques de : produire des livrables définis au préalable ; se terminer à une date précise ; ne se terminer que lorsque les livrables sont jugés satisfaisants lors d'une étape de validation-vérification Avantages Simple, "facile" à mettre en œuvre; processus rapide Inconvénients Dangereux, évaluation tardive risque de rejet ou d'ajustements bricolés C. Faure 46

Variante 1 : Modèle en cascade avec itérations Étape suivante uniquement quand une étape est satisfaisante conception orientée vers l implantation évaluation en dernier! Modèle créé pour les grands projets importance des documents (cahier des charges, spécifications) signés par les clients Analyse des besoins Cahier des charges Choix de conception du système et du logiciel Codage et tests des modules Intégration et test du système C. Faure

Variante 2 : Le modèle de conception en "V" L évaluation se fait seulement après le codage Il met en évidence la nécessité d'anticiper et de préparer dans les étapes descendantes les " attendus " des futures étapes montantes : Ainsi les attendus des tests de validation sont définis lors des spécifications, les attendus des tests unitaires sont définis lors de la conception, etc. SJD -LIRIS -UCBL : IHM -L3 info

Le modèle en V Caractéristiques Ce modèle est adapté aux projets de taille et de complexité moyenne C'est une amélioration du modèle en cascade traditionnel Il permet d'identifier et d'anticiper très tôt les éventuelles évolutions des besoins C'est aussi un moyen de vérifier la maturité des utilisateurs, car s'il en était autrement, ils se trouveraient dans l'incapacité de fournir des tests de recettes dès la phase de spécification C'est un modèle avantageux pour une maîtrise d'œuvre, rassurant pour une maîtrise d'ouvrage qui doit cependant s'engager significativement 49

Le modèle en Spirale http://www.intuilab.com/presentation/302b-methodedefi.html Constat Le modèle en V est bien adapté quand les spécifications sont complètement définies A montré ses limites dans le cas des IHM, en particulier pour les systèmes complexes En effet, il est difficile à la fois de définir précisément les exigences et de les formaliser avant que ne démarre la conception Cela faisait peser sur les projets des risques importants d'acceptation par les utilisateurs, et de remise en cause des développements 50

Le modèle en Spirale Propose des prototypes successifs Pour chaque cycle le modèle explicite : Les objectifs, alternative retenue et contraintes L analyse et la résolution des problèmes Le développement, validation et vérification de la phase La planification de la phase suivante SJD -LIRIS -UCBL : IHM -L3 info 51

Le modèle en Spirale Modèle par incréments On développe tout d abord le noyau On ajoute petit à petit des fonctions Risques rencontrer un problème pour l ajout d un élément remettre en question les éléments précédents voire même le noyau SJD -LIRIS -UCBL : IHM -L3 info 52

Les modèles de conception en Génie logiciel Bilan Les fonctionnalités du système sont mises en avant au détriment des utilisateurs Principe d indépendance entre le noyau fonctionnel et l interface utilisateur interface et interaction ne sont définies qu après mais dans les logiciels interactifs cette séparation n est pas si nette il est indispensable de prévoir l usage en même temps que les fonctionnalités SJD -LIRIS -UCBL : IHM -L3 info 53

Première solution Le modèle du "cycle de vie en étoile" (Star life cycle) Un processus centré sur l'utilisateur : Hix et Hartson1993 Prototypage Utilisateur (intervient partout) Codage Évaluation Modélisation conceptuelle et formelle Analyse de la tâche, des fonctions Spécialisation des besoins + - Garantie de répondre aux besoins Évaluations intermédiaires sur des maquettes, proto... Processus lent Maintenir l'équipe de conception tout au long du processus Manque de guidage : quel ordre? Quelle méthode? Hartson et Hix 54

Bibliographie Ouvrages de référence A. DROUIN et L.FAVEAUX Les critères de qualité et méthodologie de conception d'une Interface Paris-convention UNIX, 1992 H. HAMMOUCHE : De la modélisation des tâches à la spécification des interfaces Utilisateur Rapport Inria, Rocquencourt France, Mai 1993 HITCH et GARDINER Principles from the psychology of langage, Applying cognitive psychology to User Interface Design M. GARDINER et B. CHRISTIE, J Wiley & sons 1987 pp119-134 T I et pages 135-163 T II D.A. NORMAN, Cognitive engeneering, User centered System Design:New Perspectives on Human Computer Interaction, Associates,Publishers 1986 AFNOR Ergonomie et conception du dialogue homme-ordinateur, Z67-110 Afnor PARIS, Janvier 1988 AFNOR Définition des critères ergonomiques de conception et d'évaluation des produits logiciels Z67-133-1 Afnor PARIS, Décembre 1991 55