Approches d’intégration synergique des modèles

Les sections précédentes ont montré l’importance de l’utilisation outillée des modèles au cours de l’approche de développement d’un système interactif critique. Nous avons montré que les modèles du comportement du système et les modèles de tâches utilisateur permettaient de fournir un support pour la conception et le développement des systèmes interactifs critiques fiables et utilisables.

Les modèles de tâches utilisateurs et les modèles du comportement du système représentent, entre autres, deux points de vue du passage d’informations entre l’utilisateur et le système. Les deux vues

doivent être cohérentes pour que le système soit opérable et que les actions conjointes de l’utilisateur et du système n’altèrent pas l’intégrité de l’un de deux. S’assurer que ces deux types de modèles sont cohérents doit donc faire partie de l’approche de développement des systèmes interactifs critiques complexes et des outils logiciels doivent fournir un support à cette activité.

La première sous-section décrit les solutions proposées jusqu’à aujourd’hui pour intégrer des modèles de différents types lors de la conception et du développement de systèmes interactifs et la seconde sous-section détaille une approche de développement prenant en compte l’intégration synergique de ces deux types de modèles, seule du genre répertoriée à jour.

3.1.1 Solutions existantes pour l’intégration entre des modèles de différents types

Depuis un dizaine d’années, plusieurs propositions d’intégration des modèles de tâches avec les modèles du système ont été apportées dans la communauté scientifique.

3.1.1.1 Génération automatique de modèles

Mobi-D (Puerta & Eisenstein, 1999) et Trident (Bodart, Hennebert, Leheureux, & Vanderdonkt, 1994) sont des exemples d’outils logiciels utilisant les informations contenues dans les modèles pour fournir un support à la conception et au développement d’interfaces utilisateur. Alors qu’avec Mobi-D le concepteur peut choisir différentes stratégies d’utilisation de l’information contenue dans les modèles de tâches et de domaine pour générer l’interface utilisateur, Trident utilise les descriptions et recommandations à propos des interactions abstraites pour la génération automatique d’interface utilisateur indépendante de la plateforme.

D’autres travaux se concentrent sur la génération de modèles à partir d’autres modèles. Les travaux de (Lu, Paris, Vander Linde, & Colineau, 2003) proposent de générer les modèles du système à partir de modèles de tâches ; ces mêmes auteurs proposent aussi la génération de modèles de tâches à partir de modèles du système (Lu, Paris, & Vander Linde, 1998). Les approches dirigées par les modèles (sous- section 1.2.7) proposent d’utiliser plusieurs types de modèles en leur appliquant des règles de transformation. Les travaux de (Limbourg Q. , Vanderdonckt, Michotter, Bouillon, & Lopez-Jaquero, 2004) et (Reichart, Dittmar, Forbrig, & Wurdel, 2008) proposent de créer l’interface utilisateur du système à partir d’autres modèles comme les modèles de tâches, de contexte et d’interface utilisateur abstraite. Cependant, sans l’intervention des concepteurs et développeurs, les règles de transformation peuvent mener à des descriptions irréalistes de l’activité utilisateur (Winckler, Vanderdonckt, Trindade, Stan, & Stanciulescu, 2008).

3.1.1.2 Evaluation de la cohérence entre différents types de modèles

Alors que ces propositions se concentrent sur la production de modèles, d’autres travaux se concentrent sur l’évaluation de la compatibilité entre les tâches utilisateur et le système (Sawyer, Minsk, & Bisantz, 1996). Les travaux de (Palanque, Bastide, & Sengès, 1995) vérifient la compatibilité entre des modèles de tâches (conçus avec la notation UAN) transformés en réseaux de Petri et les modèles du système décrits eux aussi avec des réseaux de Petri. Les travaux de (Palanque, Bastide, & Paternò, 1997) présentent l’utilisation de la notation CTT pour modéliser les tâches utilisateur abstraites et l’utilisation des réseaux de Petri pour modéliser les tâches concrètes. Ces modèles de tâches concrets sont utilisés pour évaluer la complexité des tâches qui seront exécutées par l’utilisateur, au moyen des techniques d’évaluation de performances fournies par les apports théoriques des réseaux de Petri.

Afin de fournir une intégration synergique des modèles de tâche et des modèles du système, (Palanque & Bastide, 1997) proposent une méthode outillée pour exécuter des scénarios extraits de modèles de

tâches (modélisés avec la notation CTT) sur les modèles du système (modélisés avec la notation ICO). Cette approche permet de vérifier la correspondance et l’exhaustivité des tâches utilisateurs avec les possibilités d’interaction fournies par le système grâce à des scénarios concrets. La limitation de cette solution proposée est que des scénarios préenregistrés sont nécessaires pour effectuer cette correspondance et qu’elle ne peut se faire sur une exécution du modèle de tâche.

Plus récemment, (Basnyat, 2006) propose un cadre outillé de modélisation pour l’analyse, la conception et la validation de systèmes critiques interactifs tolérants aux erreurs, afin d’inclure les facteurs humains dans chaque phase de modélisation d’un système interactif critique, en particulier dans le cadre de systèmes critiques en termes de sûreté de fonctionnement. Les travaux de (Blumendorf, Lehman, Feuerstack, & Albayrak, 2008) argumentent qu’une approche dirigée par les modèles serait une solution permettant de fournir un support à la co-exécution des modèles de différents types. Cette co-exécution doit assurer la cohérence et l’exécution bi-directionnelle des modèles (un changement dans un modèle doit déclencher les changements nécessaires dans les modèles liés de l’environnement). Cependant, ces auteurs n’expliquent pas les liens et mises en correspondances nécessaires pour exécuter les modèles de tâches et les modèles du système de manière simultanée.

3.1.2 Approche synergique pour la conception de systèmes interactifs critiques:

méthode MEFISTO

La méthode MEFISTO, « Modelling, Evaluating and Formalising Interactive Systems using Tasks and interaction Objects », est une approche basée sur les modèles de tâches et du système proposée dans les travaux de (Palanque, Navarre, & Gaspard-Boulinc, 2000). Elle utilise :

- Le concept d’abstraction durant le processus de conception issu de la méthode

Muse*/MERISE (section 1.2.7).

- L’exploitation synergique des modèles de tâches et des modèles formels du système pour la

conception de systèmes interactifs vérifiant les propriétés d’utilisabilité et de fiabilité.

Figure 29. Processus de développement MEFISTO

La Figure 29 décrit les étapes principales du processus de développement MEFISTO.

La phase d’observation (ou analyse) correspond à la collecte d’informations sur le domaine, incluant la pratique déjà existante, les artefacts déjà existants, les contraintes commerciales ou organisationnelles déjà existantes.

La phase de conception structure et abstrait les informations collectées lors de la phase d’observation. Cette phase nécessite la construction de modèles pour représenter ces informations. L’analyse et le raisonnement autour de ces modèles permettent de découvrir les dysfonctionnements dans l’organisation, dans la pratique du travail, dans l’intuition des utilisateurs et dans les artefacts ou le système utilisés. La Figure 30 décrit cette étape de modélisation et son positionnement par rapport à l’effort d’abstraction effectué durant le processus.

Figure 30. Niveau d’abstraction des phases de développement de la méthode MEFISTO

La phase de prototypage se décompose en deux parties : la phase de prototypage basse-fidélité et celle de prototypage haute-fidélité:

- Le prototypage basse-fidélité a pour but de permettre la compréhension du problème pour produire les besoins précis pour le système à construire. Les techniques utilisées sont dans ce cas le prototypage à l’aide d’un stylo et de feuilles de papier, en demandant régulièrement la participation de l’utilisateur en vue de valider ou invalider la conception. Cela suppose, bien sûr, un processus très itératif qui propose de nombreux choix aux utilisateurs.

- Le prototypage haute-fidélité a pour but de produire un système interactif aussi proche que possible du système final. Ce prototype est construit en tenant compte des leçons tirées par le prototypage basse-fidélité et évolue en fonction de modifications nécessaires après les phases de validation à travers des tests utilisateurs. Le prototype ainsi produit reste tout de même de qualité faible, si bien qu’il ne peut être utilisé comme le système final. La phase de développement vise à produire un logiciel de haute qualité respectant les besoins exprimés tout au long du processus qui a permis de le construire.

Figure 31. Phase de conception du processus MEFISTO

A l’intérieur du cercle présenté en Figure 31, quatre cadrans représentent les quatre principales activités du processus de conception : la modélisation des tâches, la modélisation du système, le prototypage et les tests utilisateur. Les spirales au centre du diagramme montrent que le processus de conception peut commencer aussi bien avec la modélisation des tâches (spirale gris clair) qu’avec la mise en place d’un premier prototype (spirale noire). Le cercle extérieur, nommé Scénario, illustre l’utilisation des scénarios dans toutes les phases du processus. Ces scénarios peuvent être utilisés pour conduire les expérimentations utilisateur, comme point de départ pour la modélisation de l’activité ou comme un moyen de vérifier le modèle du système.

Un élément important de cette méthode est la possibilité d’utiliser les leçons tirées du prototypage haute-fidélité comme source d’information et de solutions de conception pour la phase de développement. De plus, les modèles formels développés au cours de la phase de conception peuvent être utilisés pour générer des tests qui pourront être appliqués sur le système final. Cela fournit une façon supplémentaire de vérifier que le système construit dans la phase de développement est conforme au prototype développé dans un cadre centré sur l’utilisateur, garantissant un certain niveau d’utilisabilité, là où les méthodes classiques de développement en cascade ne l’encouragent pas.

4

Conclusion

Les approches et techniques présentées dans ce chapitre nous ont permis de dégager les exigences et besoins importants portant sur l’approche de conception et développement de systèmes simultanément fiables, utilisables et opérables :

- L’approche doit prendre en compte l’analyse des besoins utilisateurs et les tests utilisateur mais aussi permettre les itérations dans certaines phases (support à l’utilisabilité).

- L’approche doit prendre en compte la traçabilité des choix de conception et des exigences tout au long du processus de développement (exigence courante dans les standards de développement d’un système critique).

- L’approche doit prendre en compte le développement d’un programme de formation associé

au système développé (support à l’opérabilité et à la fiabilité).

- L’approche doit utiliser des modèles formels de comportement du système pour fournir un support à sa vérification et à sa validation (support à l’opérabilité et à la fiabilité).

- L’approche doit utiliser des modèles de tâches utilisateur (support à l’analyse de gros volumes de tâches et au développement du programme de formation).

- L’approche doit fournir un support à la mise en correspondance synergique des modèles de tâches et des modèles du système (vérification de la cohérence entre les tâches utilisateur et le comportement du système).

Parmi les techniques de modélisation présentées dans ce chapitre, nous pouvons retenir une notation outillée de modélisation du comportement du système : ICO – PetShop. Elle répond aux besoins et exigences en termes de support à la conception et au développement d’un système interactif critique simultanément utilisable, fiable et opérable. Cette notation outillée est utilisée dans les chapitres 6 et 7. Concernant la notation outillée de modélisation des tâches utilisateur, aucune des notations outillées existantes n’ayant pu être retenues, une nouvelle notation outillée est proposée dans le chapitre 4. Parmi les approches de développement existantes présentées dans ce chapitre, aucune d’entre elles ne peut être retenue comme fournissant un support à la conception et au développement d’un système simultanément utilisable, fiable et opérable. Ainsi, le Chapitre 1 tente de répondre aux exigences décrites précédemment en proposant une nouvelle approche de développement. Afin de comprendre et d’investiguer comment intégrer le développement du programme de formation à cette nouvelle approche, nous présentons les approches de développement existantes des programmes de formation pour les systèmes interactifs critiques.