Cours ISI - Analyse des tâches
From Isiwiki
| ← | Cours ISI - Analyse Tâches | → |
| A. Utilisateurs |
L'analyse des tâches est un vaste champ de connaissance qui s'intéresse à plusieurs questions telles que :
- comprendre comment une personne ou un ensemble de personnes accomplissent certaines tâches faisant partie de leur travail
- mettre en évidence les tâches qu'un utilisateur devra pouvoir accomplir avec un système (informatique ou autre)
- spécifier la manière dont les tâches seront effectuées avec le système : quelles actions faire et dans quel ordre ? qui a l'initiative ? qui de l'humain ou de la machine effectue quelle action ? etc.
- calculer à l'avance la charge cognitive et psycho motrice demandée à l'utilisteur pour réaliser une tâche
- etc.
Cette analyse est essentielle pour la conception de l'interface d'un sytème. En effet, elle déterminere le contenu de l'interaction (ce qu'un utilisateur doit pouvoir faire), elle fournit également les éléments de départ pour la conception détaillée de l'interaction (et donc de l'interface), et enfin et elle fournit le canvas de base pour les tests d'utilisabilité de l'interface.
Au cours de cette analyse on va déterminer les différentes tâches que le système doit permettre d'accomplir. On va également décrire ces tâches de manière informelle (texte) ou à l'aide d'un formalisme spécifique. En principe la description doit rester à un niveau général, ce n'est qu'au moment de la conception de l'interface que l'on fixera la manière précise d'accomplir les tâches avec le système. Au niveau de l'analyse on déterminera surtout ce qui doit absolument être fait pour réaliser une tâche et les éventuelles contraintes temporelles qui peuvent exister (p.ex. on ne peut faire B avant A).
--> lire l'article sur l'Analyse systémique des tâches
Contents |
[edit] Quelques définitions
Une fonction est un ensemble d'activités, processus, ou actions exécutés par une personne ou une machine
Une tâche se distingue d'une fonction par le fait que :
- elle a un sens pour l'utilisateur
- l'utilisateur croit qu'il est nécessaire ou désirable d'entreprendre cette tâche
Une action est une tâche élémentaire qui ne demande aucune réflexion ou décision de la part de l'utilisateur (presser la touche "OK", taper un nom, cliquer une icône, etc.)
Un objectif est un état d'un système qu'un agent (humain) souhaite atteindre (p.ex. avoir une place réservée dans un train, avoir un diplôme). Un objectif reste stable dans le temps (il ne change pas toujours). Il peut y avoir différents moyens (méthodes, outils, etc.) pour atteindre l'objectif et c'est la sélection du moyen détermine la tâche à entreprendre.
[edit] Scénarios de tâches (Greenberg)
Greenberg (Greenberg 2007) propose une technique basée sur des scénarios pour identifier les tâches. Dans un premier temps, il s'agit de
- prendre contact avec des personnes réelles qui seront les utilisateurs potentiels du système (si vous n'en trouvez pas c'est qu'il y a déjà un problème)
- passer du temps avec ces personnes à discuter comment le système pourrait convenir à leurs besoins. À ce point il est intéressant de noter
- qui sera d'accord d'en parler avec vous ?
- ces gens sont-ils intéressés ? Sinon pourquoi ?
- pour apprendre ce que sont les tâches des utilisateurs, développer des exemples concrets et détaillés de tâches qu'il réalisent ou veulent réaliser et que le système pourrait aider à réaliser
Exemples concrets (Greenberg, [1])
At Cheap Shop, people browse a catalog and then order goods from a clerk.
Chez Cheap Shop, les gens consultent le catalogue est passent ensuite leur commande auprès d'un vendeur.
Task example 1
A man carrying a demanding toddler buys an umbrella stroller (red is preferred, but blue is acceptable), pays for it in cash, and uses it immediately. Un homme avec un enfant de deux ans achète un pousse-pousse muni d'une ombrelle (rouge de préférence, mais bleu est acceptable), il paie cash et l'utilise immédiatement.
Task example 2
An elderly arthritic woman is price-comparing the costs of a child's bedroom set, consisting of a wooden desk, a chair, a single bed, a mattress, a bedspread, and a pillow. She takes the description and total cost away with her, to check against other stores. Two hours later, she returns and decides to buy everything but the chair.
Task example 3
A "Cheap Shop" clerk, who is the sole salesperson in the store, is given a list of 10 items by a customer who does not want to use the computer. The items are: - 4 pine chairs, 1 pine table, 6 blue place mats, 6 "lor" forks, 6 "lor" table spoons, 6 "lor" teaspoons, 6 "lor" knives, 1 "tot" tricycle, 1 red ball, 1 "silva" croquet set After seeing the total, the customer decides to take all but the silverware, and then adds 1 blue ball to the list. The customer then changes his mind about paying by credit card, and decides to pay cash. The customer wants the items delivered to his home the day after tomorrow. While this is occurring, 6 other customers are waiting for the salesperson.
Greenberg propose plusieurs critères pour définir un bon exemple de tâches
- Dit ce que l'utilisateur veut faire mais pas comment il le fait (pas d'hypothèse sur l'interface)
- Très spécifique
- Décrit une transaction complète (oblige à considérer l'articulation entre différentes parties de l'interface)
- Dit qui sont les utilisateurs
- A été évalué par des vraies personnes
[edit] Remarque
On peut dire que les scénarios de Greenberg se situent au niveau des instances de tâches et non pas des tâches génériques. Un scénario ne devra pas dire
Emprunter un livre
mais
Phèdre Piersig, étudiante en 2e année, veut emprunter le livre Traité du Zen et de l'entretien des motocyclettes.
[edit] Utilisation
Les scénarios décrits précisément vont servir de base à une évaluation du design de l'interface par passage en revue (cognitive walkthrough). Dans ce type d'évaluation on suit pas par pas les actions de l'utilisateur et à chaque pas on se pose 4 questions :
- Est-ce que l'utilisateur va essayer d'obtenir le bon effet ?
- l'utilisateur verra-t-il que l'action correcte est disponible ?
- Associera-t-il cette action avec l'effet souhaité ?
- Si l'action correcte est exécutée, verra-t-il qu'un pas a été réalisé en direction de la résolution de la tâche
[edit] Les cas d'utilisation UML
Dans la notation UML les diagrammes de cas d'utilisation servent à définir les services que le système va rendre aux différents types d'utilisateurs. La notion de cas d'utilisation (use case) correspond à la notion de tâche. En effet, un cas d'utilisation décrit une interaction entre le système et un acteur qui est en dehors du système. Cette interaction doit avoir un début et une fin bien identifiés et elle doit produire un résultat concret pour l'utilisateur.
Chaque cas d'utilisation possède un scénario qui spécifie l'interaction entre l'utilisateur et le système. Les scénarios dans UML ne font pas partie de l'analyse des tâches (comme les scénarios de Greenberg) mais sont le résultat de la conception de l'interaction. Nous les présentons par conséquent dans l'article sur la conception de l'interaction
Dans UML on parle d'acteur pour définir une catégorie d'utilisateur qui vont faire le même usage du système. Par exemple, dans un système de gestion d'une bibliothèque universitaire on aura des acteurs tels que : bibliothécaire, chercheur, étudiant, utilisateur externe, administrateur du département, etc. Chacun de ces acteurs pourra effecteur certaines tâches (cas), en général pas toutes, avec le système.
Exemple: bibliothèque
Dans un système de gestion est d'accès à une bibliothèque on a identifié trois acteurs (types d'utilisateurs) : Bibliothécaire, Chercheur, Utilisateur externe et cinq cas d'utilisation : Payer la cotisation, Consulter le catalogue, Emprunter un lien, Réserver un livre, Enregistrer un nouvel utilisateur.
Lorsque les cas d'utilisation sont complexes ou qu'ils se recouvrent partiellement, on peut définir des cas qui seront utilisés par un ou plusieurs autres. Par exemple, le cas Sélectionner un livre pourrait être utilisé par Emprunter, Réserver et Sortir de l'inventaire. De même, il est possible de définir un cas par extension d'un autre. Par exemple, le cas Emprunter un ouvrage rare pourrait être une extension de Emprunter (on doit faire la même chose que pour emprunter, avec des actions en plus).
[edit] Analyse hiérarchique des tâches
Au cours des dernière décenies de nombreux modèles ont été proposés pour formaliser l'analyse des tâches. Les modèles les plus élémentaires s'intéressent essentiellement à la décomposition des tâches en sous-tâches (Hierarchical Task Analysis). Par exemple, pour effectuer la tâche suivre un cours il faudra réaliser les sous-tâches trouver les informations relatives au cours, s'inscrire, suivre les séances, effectuer les travaux demandés, assimiler la matière, passer l'examen. Le résultat d'une analyse selon ce modèle est en général représenté graphiquement sous forme d'un arbre.
On notera que l'arbre peut présenter des alternatives. Par exemple, seule l'une des sous-tâches "Payer cash" et "Payer par carte" doit être exécutée. Ce type d'interdépendance entre tâches peut être spécifié par un plan d'exécution. Dans le cas présent, le plan pourra indiquer "Suivant le choix du client exécuter 'Payer cash' ou 'Payer par carte' ". Un plan peut être fournit pour chaque niveau de décomposition, il spécifie des contraintes sur l'exécution des sous-tâches
[edit] Modèles hiérarchiques à contraintes temporelles formelles
Des notations plus sophistiquées, ConcurTaskTree, permettent de spécifier formellement les dépendances temporelles entre tâche (séquence, alternatives, parallèlisme, déclenchement, interruption, etc.).
Cependant, comme nous l'avons indiqué plus haut, la phase d'analyse des tâches proprement dite concerne le quoi et non pas le comment. On évitera donc de se laisser entrainer à trop préciser l'interaction humain-machine. Il s'agit surtout d'identifier les tâches et d'en présenter les composantes essentielles. C'est au moment de la conception (design) de l'interface que l'on complètera l'arbre en y ajoutant les détails du comment. Fixer trop de choix au moment de l'analyse risque de restreindre inutilment les choix de conception possibles.
Par exemple, pour un système de réservation de billets de train, l'analyse dira que la tâche Réserver comprend les sous-tâches Indiquer-ville-départ, Indiquer-ville-arrivée, Choisir-classe mais n'indiquera pas dans quel ordre les effectuer car n'importe quel ordre pourrait convenir. Lors de la conception de l'interface on pourra décider de la contrainte temporelle Indiquer-ville-départ puis Indiquer-ville-arrivée et enfin Choisir-classe.
--> Lire l'article sur ConcurTaskTree
[edit] Modèles multidimensionnels
Dans certaines notations on peut également introduire les notions d'acteur, d'information, d'objectif, de responsabilité, etc. (Diaper, 200X, chap. XX) présente une synhèse de ces modèles.
[edit] Références
D. Diaper (Ed.) The Handbook of Task Analysis
J. Preece et al. Human-Computer Interaction, Addison-Wesley, 1994.
F. Paterno. ConcurTaskTree [compléter]
S. Greenberg. Task-Centered System Design. U. of Calgary. Course slides.
X. Zhang. Interface Design. Rutgers U. Course slides
