À propos de la normalisation des méthodes d’analyse de tâche

Toujours en raison de son but de permettre un changement de méthode à n’importe quel point d’une analyse de tâche, @Esperanto se doit d’utiliser au mieux les données entrées par les analystes sans égard à la méthode courante au moment de la saisie. Pour cela, la base commune à toutes les méthodes supportées devrait être la plus grande possible.

Dès le départ, on réalise que toutes les méthodes d’analyse de tâches ont un point en commun : elles servent à décrire des tâches! C’est un bon début, mais en y regardant de plus près, on réalise vite qu’au-delà d’un noyau commun d’information à propos desdites tâches, chaque méthode diffère non seulement dans les caractéristiques documentées, mais aussi dans la manière de documenter certaines caractéristiques essentiellement identiques (les directives d’exécution, notamment).

On réalise aussi que les méthodes que doit supporter @Esperanto peuvent être rangées dans l’une des deux grandes classes de méthodes d’analyse de tâche suivantes. D’une part, il y a celles

a _{Les règles de sélection pourraient être vues comme étant des branchements conditionnels, mais leur}

but est d’indiquer, parmi les méthodes disponibles pour réaliser une tâche, celle qui est la plus appropriée. Il ne s’agit donc pas d’une réelle modification au chemin d’exécution en fonction du contexte, puisque la prochaine tâche à effectuer n’est pas affectée par une règle de sélection.

b _{En AHT, il est très facile d’indiquer si des tâches doivent être réalisées en parallèle ou en simultané,}

mais certaines mises en œuvre (celle de TaskArchitect©_{, par exemple) ne font pas de distinction}

entre ces deux concepts.

c _{Aucune opération n’est facultative en ce sens qu’il faut impérativement exécuter toutes les}

opérations sur le chemin d’exécution résultant de l’évaluation des diverses conditions de l’OTHI.

d _{Les chemins d’exécution facultatifs sont facilement gérables lorsqu’on est seulement concerné par}

l’ordre dans lequel il faut accomplir les différentes opérations. Lorsque le temps d’exécution est important, il est vraisemblable que chaque chemin d’exécution va différer des autres sur cet aspect. Bien que ce ne soit pas ingérable, ce n’est certes pas évident.

e _{Les règles de sélection permettent de rendre optionnelles des séquences d’opérateurs, mais, comme}

avec KLM-GOMS, dans chaque séquence il ne peut y avoir d’opérations facultatives.

f _{Il serait certainement possible d’indiquer (en langage naturel) qu’une tâche est interruptible, mais}

une telle description ne saurait être comparée à la description formelle rendue possible par MAD.

g _{Il faut valider les relations entre les attributs suivants : état initial, précondition, état final,}

capables de gérer la complexité d’une tâche et des diverses situations dans lesquelles on peut devoir la réaliser (AHT, MAD et OTHI), de l’autre, celles portant sur les menus détails d’exécution dans des circonstances bien déterminées (analyse temporelle et KLM-GOMS). On verra plus loin que CMN-GOMS est un cas particulier qui peut être facilement traité par @Esperanto.29

La première chose à faire est donc d’établir une liste des caractéristiques d’intérêt pour chaque méthode d’analyse de tâches, puis d’augmenter le langage de chacune de manière à leur permettre d’exprimer un maximum des concepts des autres méthodes. Il est important de noter que cela n’est pas fait pour changer l’esprit de quelque méthode que ce soit, mais simplement pour permettre à chacune de bien représenter un maximum des concepts exprimables par une autre méthode. Cette opération d’élargissement de la base commune à toutes les méthodes supportées est la première étape obligée qui permettra de normaliser le langage de toutes les méthodes.

À nouveau, il est important de clarifier que la normalisation proposée ne vise pas à rendre toutes les méthodes semblables en les privant de leurs spécificités. En particulier, il serait exagéré de modifier les méthodes d’analyse de tâche au point que les deux grandes classes partagent le même langage. Il s’agit seulement d’augmenter le vocabulaire propre à chacune pour leur permettre de formuler autant de concepts que raisonnable30 _{à propos des tâches. Cette extension}

du vocabulaire des méthodes sera donc faite en respectant les spécificités de chacune.

Considérons, par exemple, d’un côté AHT et MAD qui sont des méthodes mettant l’accent sur la structure des tâches nécessaires à la réalisation d’un but, et de l’autre l’analyse temporelle qui est plutôt concernée par l’ordre et le temps d’exécution des opérations d’un processus. Bien qu’il serait fort possible d’ajouter aux tâches des premières méthodes assez de propriétés (attributs) pour aussi noter les informations relatives à l’ordre d’exécution et au temps d’exécution de

29 _{Pour l’instant, il n’est pas important d’assigner CMN-GOMS à une classe en particulier.}

chacune, aucune tentative en ce sens n’a été effectuée. On rappelle encore une fois qu’il ne s’agit pas de dénaturer les méthodes existantes non plus que de créer une super méthode.31

C’est donc pour ne pas dénaturer les méthodes d’analyse supportées que les additions ou modifications proposées pour chacune se limiteront aux seuls éléments du tableau 2-1 qui comportent un « N ». Le but de la normalisation étant d’uniformiser les possibilités des méthodes à l’intérieur de leur classe.

Les caractéristiques marquées par des «  » étant indissociablement liées à l’identité même des méthodes d’analyse de tâche se doivent d’être intégralement préservées.