Ce chapitre s'adresse plus particulièrement aux personnes qui se situent à l'extérieur du processus de conception, tel que nous venons de le décrire au chapitre 5, mais qui peuvent intervenir sur celui-ci en particulier pour améliorer la communication homme-machine.
Il peut s'agir du correspondant informatique, d'un ergonome, d'un conseiller extérieur à l'entreprise ou d'un utilisateur.
Ce chapitre comprend trois parties . Dans la première partie, nous indiquons comment procèder aux tests d'un logiciel existant; dans la deuxième partie comment faire un cahier des charges permettant de spécifier les caractéristiques du logiciel amélioré et dans la troisième partie, nous exposons une étude de cas portant sur le diagnostic d'un logiciel existant.
Pour faire le diagnostic d'un logiciel existant, on dispose généralement de deux sources d'informations: d'une part les dossiers d'analyse et de programmation, d'autre part le logiciel lui-même tel qu'il a été réalisé.
Les dossiers d'analyse et de programmation correspondent respectivement à la Représentation Conceptuelle et à la Représentation Interne. Le logiciel réalisé correspond essentiellement à la Représentation Externe, même si on peut également y voir des éléments de la Représentation Conceptuelle traduits en Représentation Externe et un élément de la Représentation Interne, le temps de réponse.
Le dossier d'analyse peut fournir des indications intéressantes concernant le schéma de la base de données, la hiérarchie du menu, l'enchaînement des opérations et, éventuellement, les dessins d'écran; le dossier de programmation indiquera les types de contrôle d'erreurs effectués et le détail des entrées/sorties.
Mais le diagnostic ne peut en aucun cas être réalisé uniquement au vu des dossiers d'analyse et éventuellement de programmation.
En effet, ces dossiers sont rarement complets car de nombreux détails se règlent souvent au stade de l'écriture des programmes; de plus, ils peuvent être erronnés par le fait que des options prises au niveau de l'analyse n'ont pas été respectées au niveau de la réalisation.
Aussi, dans tous les cas, les éléments pertinents pour la communication homme/machine que nous relevons dans ces dossiers devront être testés sur le logiciel réalisé.
Le diagnostic est possible même si nous ne disposons que du logiciel réalisé car il est possible de recomposer les éléments des dossiers d'analyse et de programmation qui nous intéressent en examinant le logiciel réalisé même si cette procédure peut s'avérer plus longue.
L'essentiel de notre exposé porte sur l'examen du logiciel car, comme nous venons de le voir, c'est un passage obligé pour notre étude.
La méthode la plus efficace consiste à procèder en deux étapes:
- tout d'abord, on teste soi-même le logiciel sur les critères que nous décrivons dans la grille d'analyse ci-après; ces tests permettent de dégager une grille d'observation ,
- ensuite, on effectue des observations sur des utilisateurs du logiciel à partir de la grille d'observation élaborée précédemment.
Dans les deux cas, on doit procèder à des recopies d'écran systématiques en cours de tests pour pouvoir recomposer ultérieurement les séquences suivies et s'assurer que l'ensemble du logiciel a été testé; c'est pour cela que la confrontation avec le dossier d'analyse peut s'avérer fructueuse.
Cette grille d'analyse repose en grande partie sur les paramètres de l'interface vus par l'ergonome (voir chapitre trois) ; cette approche permet effectivement de tester les possibilités de communication avec un logiciel d'un point de vue extérieur à sa conception.
Pour chaque écran , on observe les paramètres suivants:
- vocabulaire
La première question qui se pose est de savoir si le vocabulaire utilisé, que ce soit pour nommer les commandes et les données ou pour les messages de services ou d'erreurs est ambigu pour l'utilisateur; ces ambiguïtés se traduisent, soit par des erreurs systématique des utilisateurs, soit par une sous-utilisation des possibilités du logiciel. Dans tous les cas, l'utilisateur a des difficultés à mémoriser ce vocabulaire.
La deuxième question concerne les abréviations qui, si elles existent, doivent être mnémoniques: l'utilisateur doit pouvoir trouver une règle simple lui permettant de passer du mot complet à son abréviation; là aussi, l'homogénéité de l'application de cette règle est essentielle.
- syntaxe
Le premier élément à tester est l'homogénéité: des actions identiques de la part de l'utilisateur (quand elles sont autorisées) ont des effets identiques sur le programme; inversement, une même action de l'ordinateur est toujours activée par la même commande; ceci doit être vérifié sur l'ensemble des écrans.
Le deuxième élément est la simplicité du point de vue de l'utilisateur.
Si ces deux éléments ne sont pas respectés, l'utilisateur ne pourra pas développer d'automatismes, ce qui se traduira au mieux par une lenteur d'exécution et au pire par des erreurs de manipulation.
- dispositifs d'entrée
Les observations d'erreur liées strictement au dispositif d'entrée sont assez rares maintenant, car les dispositifs d'entrée en informatique des organisations sont peu nombreux (clavier, souris,...) et assez standardisés.
Par exemple, toutes les marques d'ordinateur proposent aujourd'hui des claviers AZERTY alors que le clavier QWERTY est, en France, une source continuelle d'erreurs pour des utilisateurs familiarisés aux normes françaises.
Par contre, d'autres éléments du clavier (touches-fonctions...) et les "souris" ne sont pas normalisées, ce qui peut être une source d'erreurs aisément observable.
- dispositifs de sortie
Nous ne parlons pas ici des caractéristiques matérielles des écrans (bien qu'elles jouent un rôle essentiel dans la fatigue visuelle) car elles ne relèvent pas de l'ergonomie du logiciel et donc de notre marge de manoeuvre concernant le logiciel.
La première chose à observer est la lisibilité générale qui se traduit par un écran qui n'est pas surchargé d'informations, avec des zones distinctes pour des objets informationnels distincts, de manière que la structure de l'écran apparaisse clairement à la suite d'un parcours visuel rapide.
La deuxième chose à observer est l'homogénéité de la présentation entre les différents écrans de même type (écrans de menus, écrans de saisie, écrans d'explication,...). Par exemple, le nom de l'opération que l'on est en train d'exécuter doit toujours apparaître au même endroit de l'écran et avec le même graphisme.
Une présentation générale surchargée ou non homogène engendre lenteur de lecture et fatigue .
Puis, nous examinons plus en détail chaque zone de l'écran pour savoir si elles sont pertinentes ou non pour l'utilisateur; inversement, nous regardons si toutes les données pertinentes au niveau de cet écran y figurent.
La pertinence des zones peut être longue à tester et demande une connaissance approfondie du travail ou des observations.
- temps de réponse
L'observation des temps de réponse est simple et leur acceptabilité obéit à des règles simples développées au chapitre 3. Il faut vérifier que pour des temps de réponse supérieur à quatre secondes, un message d'information apparaît.
Dans le cas où le logiciel se déconnecte au bout d'un certain temps de non utilisation, il faut vérifier que ce laps de temps est compatible avec la nature de la tâche entreprise. Par exemple, une tâche de type décisionnel s'accompagne de délais de réponse plus long de la part de l'utilisateur.
- logique d'utilisation
Pour les écrans de menu, on peut vérifier si l'ensemble des commandes présenté sur un écran suit une logique d'utilisation c'est-à-dire si l'utilisateur y trouve un ensemble cohérent du point de vue de la réalisation de sa tâche.
Ce critère est repris à un niveau plus global avec l'enchaînement des écrans.
- traitement des erreurs
Le premier élément à tester est la capacité du logiciel à percevoir les erreurs de l'utilisateur. Pour cela, il faut dans un premier temps imaginer un ensemble d'erreurs possibles, puis complèter si nécessaire par des observations.
Le deuxième test porte sur l'intelligibilité du message d'erreur et sa pertinence par rapport à l'erreur commise.
Le troisième test porte sur les possibilités et les facilités offertes pour rectifier les erreurs.
L'ensemble des tests sur les erreurs constitue un travail important de la part de l'intervenant et des utilisateurs mais il est crucial pour la qualité du logiciel.
- aide
Il faut identifier les différents types d'aide offerts à l'utilisateur (explicitation de commandes, explicitation de procédures, inférences) et pour chaque type d'aide procèder aux vérifications suivantes.
La première vérification concerne la possibilité d'être guidé à tout moment de l'utilisation du logiciel.
La deuxième vérification porte sur la cohérence des explications avec les faits: il faut vérifier si les explications à caractère général sur les commandes correspondent bien à la réalité du comportement du logiciel dans tous les cas.
Pour les enchaînements d'écran, il faut tester les éléments suivants:
- l'arborescence du menu
Il faut vérifier que l'ensemble de l'arborescence du menu correspond bien à une logique d'utilisation, c'est-à-dire que les commandes regroupées à un certain niveau correspondent bien à un ensemble de commandes qui ont un rapport entre elles du point de vue du travail de l'utilisateur.
Si les enchaînements d'écran sont automatiques, il faut s'assurer que ce fait constitue une aide pour l'utilisateur et non pas une gêne; inversement, il faut essayer de détecter si certains enchaînements d'écran ne devraient pas devenir automatiques.
Si les interruptions d'opérations ne sont pas permises par le système, il faut vérifier que l'on peut naviguer aisément entre les opérations que l'on a besoin d'utiliser en parallèle comme, par exemple, "consulter" avant ou après "enregistrer".
Les tests sur ces éléments peuvent être simulés par l'intervenant, mais il est indispensable qu'ils soient réalisés avec des utilisateurs.
- les commandes standard d'enchaînement
Il faut vérifier que les commandes standard d'enchaînement entre écrans comme "sortie", "aide",etc..., sont disponibles à tout moment et produisent toujours les mêmes effets!
Si certaines commandes ne sont pas exécutables dans certaines parties du programme, elles doivent être signalées à l'utilisateur; inversement, on doit indiquer les commandes standard disponibles à chaque moment.
- l'homogénéité entre écrans
Nous devons vérifier que la syntaxe, les dispositifs d'entrée et la présentation de l'écran (dispositif de sortie) sont homogènes sur l'ensemble du logiciel et même sur l'ensemble des logiciels manipulés par les différents postes de travail.
Pour permettre un diagnostic plus aisé sur l'enchaînement des écrans, on peut représenter ces enchaînements sous la forme d'un automate d'états finis comme le propose la méthode Use (Was, 82) avec les conventions suivantes:
- les états (visualisées par des cercles) représentent les écrans ou les fenêtres ou les lignes selon le mode d'interaction minimum entre l'homme et la machine.
- les transitions (visualisées par des flèches) représentent les actions de l'utilisateur permettant de basculer d'un état à l'autre.
Nous présentons ci-après un exemple de ce formalisme:
Si l'on veut que ce type de schémas reste lisible, il est la plupart du temps impossible de faire figurer sur un même schéma l'ensemble des transitions possibles.
Aussi, en pratique, on réalise un premier schéma "descendant" où on visualise les enchaînements en partant du premier écran vers tous les autres; puis on fait un ou plusieurs autres schémas pour représenter toutes les autres transitions possibles (quitter, aide,...).
Des exemples de ces schémas sont donnés dans l'étude de cas RTR présenté dans la troisième partie de ce chapitre.
Dans le tableau de synthèse ci-dessous, nous rappelons l'ensemble des éléments à tester et pour chacun d'eux nous indiquons quels types de tests doivent être pratiqués avec les utilisateurs en plus d'une expérimentation directe par l'intervenant .
Dans cette étape, nous présentons un canevas de cahier des charges du logiciel à destination des informaticiens responsables de la réalisation du logiciel.
L'objectif de ce cahier des charges est de traduire les observations que l'on vient de faire sur le logiciel en spécifications opérationnelles pour les informaticiens.
On peut, à ce sujet, remarquer qu'il est possible de faire un cahier des charges pour un logiciel interactif uniquement à partir de la Représentation Externe, c'est-à-dire en partant du point de vue de l'utilisateur; les informaticiens se chargeant alors d'élaborer une Représentation Conceptuelle et une Représentation Interne compatibles avec cette Représentation Externe.
Ce cahier des charges se présente comme un cahier des charges classique de logiciel informatique auquel on rajoute un ensemble de spécifications propres à l'interaction homme-machine.
C'est ce dernier aspect que nous développons ci-dessous.
Nous rappelons qu'un cahier des charges classique comprend l'ensemble des spécifications concernant les données (rubriques, accès, volumes,...) et les traitements (algorithmes, sécurité, confidentialité,...).
Nous rajoutons à ces spécifications celles concernant les Représentations Externes (ou vues externes) des différents postes de travail concernés par le logiciel. Il est tout à fait inutile de donner des spécifications concernant la Représentation Interne car cela relève de la compétence et de la responsabilité de l'informaticien qui doit concevoir cette Représentation Interne de manière à ce qu'elle puisse satisfaire les spécifications de la Représentation Externe.
On ne donne pas non plus de spécifications directes concernant la Représentation Conceptuelle mais la Représentation Externe contient des paramètres provenant de la Représentation Conceptuelle comme les enchaînements d'écrans ou la répartition du pilotage entre l'homme et la machine.
Les spécifications concernant la Représentation Externe se subdivisent en deux sous-ensembles; le premier concerne les spécifications à caractère général, le deuxième les spécifications propres à l'application et à chaque poste de travail.
L'objectif de ces spécifications est de fournir un cadre général de réalisation du logiciel permettant de créer une homogénéité maximale à l'intérieur du logiciel et avec les logiciels existants s'il y a lieu.
Ces spécifications doivent porter sur les paramètres suivants:
- les commandes standard qui doivent être actives (sauf exceptions) sur l'ensemble du logiciel. Il s'agit des commandes d'aide à l'utilisation que nous avons présentées dans les chapitres 2 et 3; les commandes les plus usuelles concernent les possibilités de quitter, d'annuler, de revenir en arrière, d'interrompre. Il vaut mieux spécifier également le vocabulaire de désignation de ces commandes et les abréviations, surtout s'il existe déjà des logiciels les utilisant, afin que ce vocabulaire reste identique et n'entraîne pas d'ambiguïté sémantique chez les utilisateurs.
- la présentation générale des écrans qui doit être identique sur l'ensemble du logiciel et de préférence compatible avec les logiciels existants. Nous entendons par présentation générale des écrans les choix concernant l'emplacement des zones de menu, de saisie de données, de messages d'erreur ainsi que la forme visuelle de ces paramètres; dans la forme visuelle, nous décrivons le type de caractère (gras, italique, surbrillance, couleur,...), la forme des fenétres ou des zones, l'impression du fond des zones (motifs, couleurs,...), les conventions de représentations (touches-fonctions,...).
Le plus simple est de présenter une ou des images d'écran ou de fenêtres (selon que l'on a un logiciel de mono ou de multifenêtrage) avec une représentation des différentes formes visuelles.
- les dispositifs d'entrée qui doivent être également homogènes avec les autres matériels et logiciels existants; ces spécifications portent sur le type de clavier (AZERTY, accentué, mathématique...) et sur le mode de désignation des commandes (frappe au clavier, touche-fonction, souris,...).
- la syntaxe du langage de commande comme la validation des écrans ou l'indication de fin de saisie des données qui doivent aussi être homogènes.
Il faut bien se rendre compte que tout ce qui n'aura pas été spécifié ici a plus de chance d'être hétérogène qu'homogène surtout si la réalisation (ce qui est le cas le plus courant) est confiée à plusieurs informaticiens. Pour s'en convaincre, il suffit de se reporter à l'étude de cas RTR décrit dans le paragraphe suivant et qui ne constitue pas un cas d'exception.
Il faut d'abord définir les différents types de poste de travail concernés par l'application dans la mesure où ces types de postes correspondent à des vues externes différentes de la même application (par exemple les postes correspondant à différents niveaux de responsabilités).
Puis, pour chaque poste de travail, on définit la ou les Représentations Externes; on peut avoir plusieurs Représentations Externes pour un poste de travail (correspond aux différents types de procédures définiées au chapitre 2) si on a plusieurs types d'utilisateurs (expérimentés, novices) ou des utilisateurs ayant des procédures effectives différentes.
Pour chaque Représentation Externe, nous spécifions les paramètres suivants:
- la répartition du pilotage entre l'homme et la machine qui comporte trois aspects; la spécification des enchaînements entre écrans, les écrans et données obligatoires ou facultatives à saisir et les déclenchements d'écrans à l'initiative de l'utilisateur ou de l'ordinateur.
- l'ensemble des commandes et la hiérarchie de ces commandes en menu suivant une logique d'utilisation; les noms de commandes doivent être spécifiés soit quand ils correspondent à un vocabulaire spécialisé, soit pour être compatibles avec des commandes de logiciels existants.
- les erreurs indispensables à détecter et le contenu des messages d'erreur correspondants; on peut rajouter éventuellement les possibilités de correction d'erreurs (retour-arrière, défaire,...).
- la présentation des écrans de saisie qui doivent correspondre le plus possible à des présentations déjà existantes comme les formulaires ou les écrans.
- le vocabulaire des spécialistes afin qu'il soit utilisé dans la dénomination des données et éventuellement des commandes.
Le cas RTR (Réseau de Transport par Rail) est inspiré d'un cas réel utilisé dans le cadre de la télématique grand public.
Ce cas a pour but d'illustrer la méthode permettant de faire un diagnostic d'un logiciel interactif.
Il s'agit, en l'occurence, d'un logiciel télématique destiné au grand public, ce qui facilite le diagnostic en ce sens que nous n'avons pas besoin de faire des tests sur des types d'utilisateurs différents (expérimentés, novices,...) et que la notion de procédure effective n'est plus utile.
Pour ce type de logiciel, une première expérimentation, directement effectuée par l'analyste en fonction de la grille d'analyse définie précedemment, permet de faire un certain nombre de remarques utiles à la préparation de tests systématiques auprès d'un échantillon d'utilisateurs.
Nous présentons ci-dessous quelques-une des images d'écrans sur lequel nous pouvons a priori formuler un certain nombre de critiques, compte-tenu des éléments ergonomiques présentés précédemment. Ces constatations ne sont pas forcément exhaustives car elles n'ont pas été validées sur un nombre suffisant d'utilisateurs.
Nous présentons ensuite des remarques ayant trait aux enchaînements entre les écrans.
La figure 2.1 reproduit le premier écran du logiciel RTR sur lequel nous pouvons faire les remarques suivantes:
- la première remarque a trait au fait que la syntaxe n'est pas homogène; en effet, cet écran propose un choix entre quatre possibilités ; pour obtenir trois d'entre elles, on doit taper une abréviation puis appuyer sur la touche "ENVOI", alors que pour la quatrième, il faur appuyer sur la touche "SUITE". Comme nous le verrons, cette hétérogénéité se reproduit tout au long du logiciel; la conséquence en est que l'utilisateur ne peut pas acquérir d'automatismes concernant l'envoi d'un message à l'ordinateur; cela nécessite plus de concentration et occasionne des erreurs.
- la deuxième remarque est relative à l'ambiguïté des messages concernant le premier et le dernier choix: l'utilisateur n'a qu'une idée vague ou pas d'idée du tout sur ce que peut apporter la consultation de "Davantage d'horaires régionaux, c'est possible!!!" et "les principaux mots-clés". Par contre les deux autres possibilités sont explicites.
- la troisième remarque porte sur la non-pertinence d'une zone de l'écran; à la dernière ligne, nous avons le message "(C) RTR 1987" qui n'est d'aucune utilité pour l'utilisateur car il sait déjà par la première ligne qu'il est en train de consulter RTR, on peut penser qu'il sait en quelle année il est et la signification du (C) n'est pas nécessaire pour utiliser le logiciel. Cette zone inutile, du point de vue de l'utilisateur, se retrouve avec des variantes de présentation sur tous les écrans.
La figure 2.2 est obtenue en appuyant sur la touche "SUITE" à partir du premier écran; on peut l'obtenir aussi à d'autres moments en appuyant sur la touche "SOMMAIRE"; ceci est une autre forme de l'hétérogénéité de la syntaxe.
Nous avons choisi cet écran car il est très caractéristique des abréviations non mnémoniques en ce sens que ces abréviations ne sont pas constituées à partir d'une règle unique facilement mémorisable.
Les abréviation des commandes 2,3,4,7,9,11,12 reprennent des lettres contenues dans le vocabulaire de ces commandes et peuvent donc être plus facilement mémorisées (une étude plus fine s'imposerait); mais cette règle n'est pas appliquée pour les autres commandes.
La commande 1 a une abréviation correspondant à la ligne précédente qui est un libellé général.
La commande 5 a comme abréviation le nom d'une entreprise!
Les commandes 6 et 10 ont une abréviation mystérieuse pour un utilisateur ordinaire.
La commande 8 a une abréviation proche de celle de la commande 1 et éloignée de la commande qu'elle désigne.
Nous pouvons faire également deux remarques sur la présentation:
- la première concerne la ligne où sont présentées les commandes 9 et 10; cette ligne n'est pas homogène avec les autres puisqu'il y a deux commandes sur la même ligne ce qui la rend quasiment illisible.
- la seconde concerne l'écriture du chiffre zéro qui est présenté avec une barre, ce qui est usuel uniquement pour les informaticiens et inconnu pour tous les autres utilisateurs.
La figure 2.3 représente un des feuillets de l'aide à l'utilisation ; le premier feuillet de cette aide est obtenu en tapant 12 ou AI suivi de "ENVOI" à la suite de l'écran SOMMAIRE; pour obtenir le deuxième feuillet, il faut appuyer sur 1 suivi de la touche "ENVOI" alors que pour obtenir les autres feuillets, il faut appuyer sur "SUITE" (hétérogénéité de la syntaxe).
La première remarque que l'on peut faire sur cet écran concerne le vocabulaire; certains mots de ce vocabulaire ont une signification pour l'informaticien mais pas pour les autres utilisateurs. Il s'agit de "fonctions", "accès", "page adjacente" (la faute d'orthographe sur adjacente est d'origine!).
La deuxième remarque a trait à l'ambiguïté du message décrivant "Retour au feuillet précédent"; ce message exprime en fait deux idées différentes, la première a trait effectivement au retour à la page précédente, la seconde a trait à la "page rubrique précédente", ce qui n'est pas très explicite.
La troisième remarque n'est pas directement visible sur l'écran puisqu'elle concerne la vérification de la cohérence entre les explications contenues dans l'aide et le logiciel lui-même. Cela concerne les touches SUITE et RETOUR dont l'emploi au cours de l'utilisation du logiciel n'est pas toujours possible et dont les effets ne sont pas toujours ceux attendus.
La figure 2.4 représente le premier écran du service "horaires"que l'on obtient en tapant la commande "HORA" comme il est indiqué dans la première ligne.
La première remarque concerne le vocabulaire des messages de service:
- le mot "relation"qui désigne une liaison ferroviaire n'est pas en usage dans le vocabulaire courant;
La deuxième remarque concerne la logique d'utilisation au niveau de cet écran.
On trouve en effet, regroupés dans le service "horaires", deux autres services, "les réductions" et "les dernières nouvelles", qu'il n'est pas du tout évident de placer à cet endroit.
En ce qui concerne "les réductions", l'utilisateur doit pouvoir y accéder directement sans passer par une arborescence; c'est donc un service qui doit être présenté au niveau du sommaire général. Si l'accès direct n'est pas possible, il faut le regrouper dans un service du type "informations générales" où l'utilisateur peut s'attendre à trouver des informations variées à caractère général et non pas dans un service spécifique comme "horaires"
La figure 2.5 représente un écran de consultation d'horaires où l'utilisateur a essayé de revenir à la page précédente (liste des horaires) au moyen de la touche "RETOUR"; on voit alors que s'affiche sur la première ligne le message d'erreur "touche retour ineffective".
Ce message est en contradiction avec les explications contenues dans "l'aide à l'utilisation" où l'on indique que la touche "RETOUR" permet de revenir à la page précédente.
Si la règle énoncée ne peut, pour des raisons techniques, être respectée, il faut modifier le texte de l'aide et indiquer pour chaque écran les touches actives à ce niveau (notion de menu dynamique).
Mais avant de faire ces modifications, il y aurait lieu de vérifier s'il y a une véritable impossibilité technique à respecter cette règle qui a l'avantage de la simplicité et qui correspond à une touche fonction.
La figure 2.6 correspond à l'écran de réservation obtenu directement à partir de l'écran "Sommaire".
On peut faire des remarques de surface au sujet de la syntaxe des phrases suivantes:
- "Vous désirez des : ASSISES"; alors qu'il y a suffisamment d'espace pour rajouter le mot "PLACES".
- "Vous pouvez : - autre résevation ou horaire".
Ce type de syntaxe inutilement incomplète constitue pour les utilisateurs une gêne importante qui affecte leur compréhension.
Mais la remarque essentielle sur cet écran concerne le traitement des erreurs. Nous sommes dans un cas d'erreur non détectée avec message d'erreur erronné.
En effet, quand l'utilisateur partant de TOULOUSE tape PARIS comme destination, l'ordinateur lui demande de choisir parmi une des gares parisiennes; cette question est parfaitement inutile puiqu'il n'a pas le choix effectif de cette gare! Cette information devrait donc être déduite automatiquement.
Si l'utilisateur se trompe sur la gare d'arrivée (ici, en tapant PARIS- NORD), le logiciel ne lui signale pas l'erreur et, en conséquence, l'utilisateur continue à saisir les autres données; après validation, il obtient comme message qu'il n'y a pas de train à l'heure indiquée.
Le comportement du programme est par ailleurs non stable car au cours d'un autre essai de ce type nous n'avons pas obtenu de message d'erreur mais un message d'attente "votre demande est transmise veuillez patienter" suivi d'une interruption pour dépassement de temps sans utilisation!
Quelle que soit la réponse du logiciel, l'utilisateur ne peut pas savoir qu'il a fait une erreur sur la gare de destination.
La figure 2.7 est un écran de réservation obtenu à partir du service "horaires", ce qui a pour conséquence que les quatre premières lignes sont remplies automatiquement par le logiciel car elles correspondent au choix fait par l'utilisateur sur l'écran précédent.
Mais la zone indiquant le numéro du train n'est pas pertinente pour l'utilisateur alors que l'heure du train le serait et ne figure pas.
L'indication concernant la longueur du nom (limitée à 13 caractères) est une indication d'ordre technique qui est peu pertinente pour l'utilisateur; elle correspond à la logique de fonctionnement (indexation des fichiers) et non à la logique d'utilisation.
Les enchaînements d'écrans peuvent être testés uniquement à partir du logiciel, mais l'analyse sera plus rapide si l'on dispose du dossier d'analyse et que l'on procède ensuite à des vérifications systématiques sur le logiciel. Sinon la première partie du diagnostic consiste à reconstituer l'arborescence du menu qui figure dans le dossier d'analyse. C'est ce qui a été fait dans ce cas et nous présentons ci-dessous deux schémas, avec le formalisme des automates d'états finis, qui ont été remplis lors des tests sur le logiciel RTR:
- le premier représente une partie de l'arborescence générale dans le sens descendant, c'est-à-dire en partant du menu général et en allant vers les écrans suivants; pour faire le lien avec les images d'écrans présentées précédemment , nous avons indiqué dans les places du schéma (représentées par un cercle) le numéro des figures correspondantes.
- le deuxième schéma représente les tests systématiques des touches RETOUR et SOMMAIRE pour chacun des écrans représentés sur le premier schéma; on voit cependant la touche GUIDE apparaître une fois quand on est dans le cas où les touches RETOUR et SOMMAIRE sont toutes les deux interdites; mais pour des raisons de lisibilité, il n'était pas possible de représenter sur le même schéma les tests systématiques de la touche GUIDE.
A partir de ces schémas, nous pouvons constater les dysfonctionnements suivants:
1. l'arborescence du menu ne correspond pas globalement à une logique d'utilisation; on peut à titre d'exemple citer les faits suivants:
- on peut aller de l'écran "horaires" vers l'écran "réservation" (comme on peut le voir sur le schéma représentant un extrait de l'arborescence de RTR) mais l'inverse n'est pas vrai; ce fait constitue une gêne importante car il est usuel d'avoir besoin de consulter des horaires en cours de réservation soit pour s'assurer de l'horaire précis soit pour redresser une erreur.
- le sommaire général (figure 2.2) s'adresse à des types d'utilisateurs différents et à des niveaux différents; il y aurait lieu de distinguer au minimum les voyageurs (horaires et réservations) et les entreprises (transports par wagons complets et en conteneurs).
Les différents types d'information à caractère général peuvent être regroupés par type d'utilisateur (informations générales, actualité,...).
- certaines informations de niveau un ne sont pas acessibles directement; par exemple, les réductions ne sont accessibles qu'à partir des horaires, ce que l'utilisateur ne peut absolument pas deviner.
2. Les commandes standard d'enchaînement ne sont pas systématiquement activables par l'utilisateur, sans qu'aucune indication ne lui soit fournie à ce sujet. Il s'agit des commandes correspondants à des touches-fonctions comme SOMMAIRE, GUIDE, ANNULATION, CORRECTION, RETOUR, SUITE.
De plus, l'effet de ces commandes n'est pas toujours identique, ce qui rend le comportement du logiciel non prévisible pour l'utilisateur et lui interdit de développer un automatisme.
Nous pouvons voir sur le deuxième schéma que dans la branche "horaires", sur quatre écrans successifs, on a trois actions différentes pour la même touche RETOUR (interdiction, retour à l'écran précédent, retour à la ligne précédente du même écran). De même pour la touche SOMMAIRE qui fait parfois revenir à l'écran précédent, parfois deux écrans précédents,parfois au début de l'arborescence ou qui est interdite.
Comme nous l'avons indiqué au début de ce chapitre, le formalisme des automates d'états finis, qui a l'avantage d'être très facile à utiliser pour décrire les enchaînements d'écrans, présente une ambiguïté quand il s'agit d'exprimer le parallélisme et les synchronisations. Nous pouvons constater ce problème sur le deuxième schéma où, à partir de l'écran "Horaires/1", il y a deux sorties par la touche SOMMAIRE selon que l'on vient de "Horaires/0" ou de "Menu général". Pour lever cette ambiguïté due au formalisme, il faudrait dupliquer complètement la branche constituée des écrans "Horaires/1", "Horaires/2", "Horaires/3" et "Réservation"...; ceci alourdirait la présentation du schéma sans offrir d'avantages notables pour satisfaire l'objectif que l'on s'est fixé ici: le diagnostic du logiciel vu du point de vue de l'utilisateur.
