cours:ipm:anls-taches

Analyse des tâches

L'analyse des tâches (Diaper et Stanton 2004) est un vaste champ de connais-sance qui s'intéresse à plusieurs questions telles que :

  • identifier quelles sont les tâches qu'une personne ou un ensemble de personnes accomplissent dans leur contexte de travail ou d'autre acti-vité
  • comprendre et décrire ces tâches et les modéliser formellement
  • spécifier une manière de réaliser une tâche
  • calculer la charge cognitive et psycho motrice demandée à l'utilisateur pour réaliser une tâche

Bien qu'il n'existe pas de terminologie tout à fait standard dans le domaine, on s'accorde en général sur la terminologie suivante:

fonction : ensemble d'activités, processus, ou actions exécutés par une per-sonne ou une machine tâche : une fonction qui a un sens pour l'utilisateur et que l'utilisateur croit nécessaire ou désirable d'entreprendre

action : 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.)

objectif : é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 peut y avoir différents moyens (mé-thodes, outils, etc.) pour atteindre l'objectif et c'est la sélection du moyen qui détermine la tâche à entreprendre.

Dans le domaine de la conception des interfaces homme-machine, l'analyse des tâches s'intéresse tout d'abord à la situation présente : comment les gens font-ils actuellement pour atteindre leurs objectifs ou comment souhaite-raient-ils faire ? Une fois que l'on aura compris et modélisé les tâches menant à la réalisation de ces objectifs, on pourra se demander comment réaliser ces tâches avec un système interactif. Cette analyse déterminera donc le contenu de l'interaction : ce qu'un utilisateur doit pouvoir faire avec le système. La modélisation des tâches fournira également les éléments de départ pour la conception détaillée de l'interaction, et donc de l'interface, et enfin elle fourni-ra le canevas de base pour les tests d'utilisabilité de l'interface.

Il ne faut cependant pas oublier que la création d'une interface ou d'un sys-tème n'a pas forcément pour but de répliquer le travail les manière de travail-ler existantes. On peut vouloir

Nous proposons ici d'appréhender l'analyse des tâches en trois étapes répon-dant à des questions de plus en plus spécifiques. Lors de la première étape on s'intéressera à comprendre le travail des utilisateurs et en quoi le système pourra les aider. On développera pour cela des scénarios de tâches. Lors de la deuxième étape on décrira plus formellement chaque tâche, en particulier sa décomposition en sous-tâches ainsi que les contraintes temporelles entre sous-tâches (séquence, parallélisme, etc.). On utilisera pour cela un langage de modélisation de tâches. Enfin, on se posera la question de ce que l'on veut ou doit réellement faire avec le système informatique, et donc avec son interface. Les diagrammes de cas du langage de modélisation UML offrent un moyen ef-ficace de représenter qui fera quoi avec le système et d'établir une sorte de contrat avec les futurs utilisateurs on pourra également utiliser la technique des scénarios pour créer ou imaginer ce qui va se passer avec le système à dé-velopper.

Greenberg (Greenberg 2004) propose une technique basée sur des scénarios pour identifier les tâches. Pour apprendre ce que sont les tâches des utilisa-teurs, il faut développer des exemples concrets et détaillés de tâches qu'il réa-lisent ou veulent réaliser. Ce développement doit être issu d'interview, en-quêtes ou observations auprès des utilisateurs potentiels du système. En par-ticulier, on construira des scénarios pour chacun des personnages identifiés lors de l'analyse des utilisateurs et du contexte.

(Greenberg 2004) Chez Cheap Shop, les gens consultent le catalogue est pas-sent ensuite leur commande auprès d'un vendeur. On identifie les trois tâches ci-dessous :

Tâche 1.

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édiate-ment.

Tâche 2.

Une vieille dame arthritique compare les prix d'un mobi-lier de chambre d'enfants composé d'un bureau en bois, d'une chaise, d'un lit simple, d'un matelas, d'un couvre lit et d'un oreiller. Elle emporte avec elle la description et le prix total pour comparer avec d'autre magasins. Deux heures plus tard elle revient et décide d'acheter le tout sauf la chaise.

Tâche 3.

Un employé de Cheap Shop, qui est le seul vendeur dans le magasin, reçoit une liste de 10 articles d'un client qui ne veut pas utiliser l'ordinateur. Les articles sont : 4 chaises en pin, une table en pin, 6 set de table bleus, 6 fourchettes « lor », 6 cuillères « lor », 6 cuillères à thé « lor », 6 couteaux « lor », un tricycle « tot », 1 ballon rouge, 1 jeu de croquet « silva »

Après avoir vu le montant total le client décide de tout prendre sauf l'argenterie et ajoute un ballon bleu à la liste

Puis le client change d'avis à propos du payement par carte et décide de payer cash. Il veut que les articles lui soient livrés à la maison le surlendemain. Pendant que ceci se passe 6 autres clients attendent que le vendeur s'occupe d'eux.

Selon Greenberg une bonne description de tâche dit ce que l'utilisateur veut faire mais pas comment il le fait, dans une phase d'analyse on ne fait pas d'hy-pothèse sur l'interface. La description doit être très spécifique. On ne parle pas en termes génériques, du genre « emprunter un livre », mais d'objets spécifiques : « emprunter le livre Traité du Zen et de l'entretien des motocyclettes ».

De même, il faut dire qui sont les utilisateurs, soit explicitement, comme dans les exemples ci-dessus, soit en faisant référence aux personnages créés dans l'analyse des utilisateurs. Enfin, le scénario décrit une transaction complète impliquant plusieurs ac-tions. Ceci obligera le concepteur de l'interface à considérer l'articulation entre différentes parties de l'interface. La création des scénarios permet de vérifier que l'on est bien dans la bonne direction par rapport aux attentes et besoins des utilisateurs, que l'on est bien connecté à la réalité. Ceci n'est évidemment vrai que si les scénarios ont été validés par de futurs utilisateurs ou des personnes connaissant bien le do-maine.

En plus de leur rôle en phase d'analyse, les scénarios serviront lors du design de l'interface. Ils sont en effet à la base d'un type d'évaluation du design appe-lé évaluation par passage en revue (cognitive walkthrough).

Dans ce type d'évaluation on suit pas à pas les actions de l'utilisateur et à chaque pas on se pose 4 questions :

  1. Est-ce que l'utilisateur va essayer d'obtenir le bon effet ?
  2. L'utilisateur verra-t-il que l'action correcte est disponible ?
  3. Associera-t-il cette action avec l'effet souhaité ?
  4. Si l'action correcte est exécutée, verra-t-il qu'un pas a été réalisé en di-rection de la résolution de la tâche

Dans le cas d'activités complexes, par exemple le contrôle aérien, il est très difficile, voire impossible d'identifier dès le départ les tâches principales et leurs sous-tâches. On peut alors recourir à une analyse de bas en haut. Le principe est d'observer les utilisateurs et de noter leurs actions les plus simples, puis de reconstruire des tâches de plus haut niveau par regroupe-ment, jusqu'au tâches les plus globales. Si le degré de technicité du domaine est très élevé, il n'est pas possible de no-ter directement la séquence des actions observées. Dans ce cas on peut filmer l'activité, puis regarder le film en compagnie d'un spécialiste qui commente les actions (on prend soin de filmer le commentaire et la vidéo originale). À partir de ces commentaires on peut constituer une liste d'actions dont chaque entrée comprendra un identifiant, un temps de début de l'action, la descrip-tion de l'action, la description de son effet sur les objets du domaine

Le but est ensuite de produire des diagrammes montrant l'enchaînement ob-servé des actions : montrer ce qui s'est passé en séquence ou en parallèle, quels sont les choix qui ont été faits. Finalement, l'observation de ces dia-grammes permettra d'extraire une structure de tâches par généralisation, en repérant les motifs qui se répètent exactement ou avec des variantes.

Au cours des dernières décennies 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 (Hierar-chical 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 ma-tiè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écu-ter Payer cash ou Payer par carte ». Un plan peut être fournit pour chaque ni-veau de décomposition, il spécifie des contraintes sur l'exécution des sous-tâches. On peut également caractériser les tâches par des attributs tels que:

pré-requis l'utilisateur a-t-il besoin de connaissances particulières pour ac-complir la tâche?

fréquence la tâche est elle accomplie souvent, de temps en temps, rarement ?

objets quels sont les objets physiques dont il faut disposer pour exécuter la tâche ?

reproduction peut-on reproduire l'environnement physique (les objets) re-quis dans un système informatique?

importance la tâche est-elle critique pour le fonctionnement du système?

complexité faut-il des capacités humaines particulières (motrices, cérébrales, cognitives, verbales, …) pour réaliser la tâche?

Par exemple, la tâche Consulter catalogue de la Figure 2 n'a pas de pré-requis (si ce n'est savoir lire et écrire); elle est très fréquente; il faut disposer d'objets physiques : catalogue, bloc-notes, crayon; on peut la reproduire informati-quement sur un écran; elle est critique pour le fonctionnement du magasin et ne requière pas de capacités particulières.

Des notations plus sophistiquées, telles que 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 essen-tielles. C'est au moment de la conception (design) de l'interface que l'on com-plè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, Indi-quer-ville-arrivée, Choisir-classe mais n'indiquera pas dans quel ordre les ef-fectuer 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.

La notation ConcurTaskTree (CTT) (Mori et al. 2002) (Paterno et al. 1997) se caractérise par une décomposition hiérarchique des têches, une catégorisation des tâches en fonction des acteurs, l'expression des relations temporelles entre tâches à l'aide d'opérateurs (opérateurs LOTOS) et une représentation des échanges de données entre tâches.

CTT a été conçue avant tout pour simplifier le design d'applications interactive, contrairement à d'autres notations orientées vers l'analyse des systèmes de travail. Une description de tâche CTT est composée d'un nom, d'un type, d'une liste ordonnée de sous-tâches (décomposition hiérarchique), de relations tempo-relles entre les sous-tâches et d'objets d'entrée et de sortie (nom, type). On distingue quatre types de tâches :

Utilisateur: tâche entièrement réalisée par l'utilisateur, par exemple, choisir un hôtel dans une liste

Application: tâche entièrement réalisée par l'application, par exemple: calcu-ler la route la plus courte de A à B

Interactive: tâche réalisée par une interaction entre utilisateur et système et initiée par l'utilisateur trouver la définition d'un mot dans un diction-naire

Abstraite: tâches nécessitant une interaction complexe. Elle sera décomposée en sous-tâches de différents types Les sous-tâches d'une tâche T doivent être du même type que T, sauf si T est de type abstraite. Dans ce dernier cas ses sous-tâches doivent être soit toutes abstraites, soit d'au moins deux types différents. Relations temporelles

Opérateur Signification
T1 ||| T2 imbrication: actions en parallèle
T1 |[]| T2 synchronisation: échange d'information
T1 » T2 activation: fin de T1 déclenche T2
T1 |=| T2 ordre quelconque: T1 » T2 ou T2 » T1
T1 []» T2 activation avec passage d'information
T1 [] T2 choix: soit T1 soit T2
T1 [> T2 désactivation: dès qu'une action de T2 se pro-duit, T1 est désactivée
T1 |> T2 interruption: T2 peut interrompre T1, T1 peut reprendre à la fin de T2
T* répétition 0, 1 ou plusieurs fois
T(n) répétition n fois
[T1] option: T1 n'est pas obligatoirement effectuée

On représente la décomposition en sous-tâches par un arbre où les descen-dants d'un noeud sont liés entre eux par l'une des relations temporelles.

Exemples

1. Quand on réserve un billet on peut fixer la ville de départ et d'arrivée dans n'importe quel ordre, même en parallèle.

2. Utilisation (simplifiée) d'un application qui permet de modifier des données. Chaque modification doit être confirmée avant son exécution par la machine.

La modélisation CTT peut s'appuyer sur différents outils tels que

  • un éditeur de diagrammes
  • un simulateur interactif (présente les tâches possibles à chaque ins-tant et l'utilisateur sélectionne celle qu'il veut exécuter)
  • un analyseur de chemins (vérifie s'il existe une séquence d'actions commençant par une action A1 et finissant par A2
  • un générateur automatique d'interfaces (après avoir complété la des-cription des tâches avec les types de données traitées et les choix d'ob-jets d'interface)

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 de-hors 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'ana-lyse 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'utilisateurs 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

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. Les liens entre acteurs sont montrés sur le diagramme de cas d'utilisation suivent :

Lorsque les cas d'utilisation sont complexes ou qu'ils se recouvrent partielle-ment, 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 em-prunter, avec des actions en plus).

Diaper, D., & Stanton, N. (Eds.) (2004). Task analysis for human-computer in-teraction. .. Chichester, UK : : Ellis Horwood.

Greenberg, S. (2004). Human Computer Interaction I: Principles and Design. http://pages.cpsc.ucalgary.ca/~saul/481/. Accédé le 27 février 2011.

Mori, G., Paterno, F., & Santoro, C. (2002). Ctte : Support for developing and analyzing task models for interactive system design. IEEE Transactions on Software Engineering , 28 (9), 797–813.

Paterno, F., Mancini, C., & Meniconi, S. (1997). Concurtasktrees : A diagrammatic notation for specifying task models. In Proceedings Interact”97 , (pp. 362–369). Chapman & Hall.

  • cours/ipm/anls-taches.txt
  • Last modified: 2012/05/20 09:50
  • by gilles