Vous êtes ici : Accueil > La revue > Numéro 4 - "Des expé... > Illustration d’une d...

Illustration d’une démarche centrée utilisateur pour l’ingénierie informatique : conception de langage de modélisation

frPublié en ligne le 02 décembre 2016

Résumé

La création de systèmes d’information nécessite la mise en œuvre d’une phase de conception qui s’appuie généralement sur des modèles graphiques. L’apparition de systèmes de plus en plus complexes a accru la difficulté de leur conception, augmentant ainsi la nécessité d’utiliser de nouveaux modèles et donc de nouveaux langages de modélisation. Aujourd'hui, nous constatons que les utilisateurs finaux ne sont pas intégrés de manière systématique dans le processus de développement des langages de modélisation informatiques. Cette intégration devient encore plus nécessaire lorsqu'on propose un langage spécifique à un domaine. Dans cet article, nous proposons une démarche centrée utilisateur pour la construction de langages de modélisation. Nous nous appuyons sur nos expériences passées en matière d’évaluation de langages de modélisation par des utilisateurs. Nous illustrons cette démarche dans le domaine de la modélisation des processus métier inter-organisationnels.

Abstract

The creation of information systems requires the implementation of a design phase which is generally based on graphical models. The increasing complexity of systems has increased the difficulty of design, thus implying the need for new models and therefore new modelling languages. Today, end-users are not systematically integrated into the development process of computer modelling languages. This integration is even more necessary when proposing specific domain languages. In this paper, we propose a user-centred approach for building modelling languages. We describe our past experiences with evaluation of modelling languages by end-users. We illustrate this approach in the field of inter-organizational business processes modelling.

Sommaire

  1. 1.Introduction
  2. 2.Contexte de notre étude : les langages de modélisation
  3. 2.1.Cas d’étude : l’arrivée inattendue d’un avion à un aéroport
  4. 2.2.Exemple de modèle de chorégraphie
  5. 2.3.Langages de modélisation en informatique
  6. 3.Etat de l’art
  7. 3.1 Qualité des langages de modélisation
  8. 3.1.1.Evaluation globale de la qualité
  9. 3.1.2.Evaluation suivant les composants d’un langage
  10. 3.1.3.Rôles dans l’évaluation d’un langage
  11. 3.1.4.Méthodes d’évaluation
  12. 3.2.Démarches de développement d’un langage de modélisation
  13. 3.2.1.Construction des langages de modélisation spécifiques au domaine
  14. 3.2.2.Démarche centrée utilisateur (DCU)
  15. 3.2.3.Phases de la démarche centrée utilisateur
  16. 3.3.Synthèse
  17. 4.Vers une ingénierie de langages de modélisation de qualité
  18. 4.1.Principes pour l’élaboration de langages de modélisation
  19. 4.2.Vue générale du processus du développement d’un langage de modélisation intégrant la démarche centrée utilisateur
  20. 4.3.Les trois étapes du développement du langage de modélisation
  21. 4.4.Processus d’évaluation centré utilisateur
  22. 5.Illustration de la démarche via l’expérience d’études centrées utilisateur
  23. 5.1.Vue générale des études réalisées
  24. 5.2.Première étude : cadre des exigences pour les langages de chorégraphies
  25. 5.2.1.Positionnement de l’étude
  26. 5.2.2.Explication de l’étude
  27. 5.3.Deuxième étude : analyse du méta-modèle et de la notation
  28. 5.3.1.Positionnement de l’étude
  29. 5.3.2.Explication de l’étude
  30. 5.4.Troisième étude : questionnaire en ligne
  31. 5.4.1.Positionnement de l’étude
  32. 5.4.2.Explication de l’étude
  33. 5.6.Synthèse des études
  34. 6.Bilan et perspectives
  35. Bibliographie

1.Introduction

1Les systèmes d’information (SI) sont une brique essentielle dans une organisation. Ils permettent de gérer une information qui doit être accessible n’importe où, n’importe quand, tout en étant adaptée au contexte d’usage de l’utilisateur. Nous retiendrons des systèmes d’information actuels que leur complexité se retrouve au niveau de leur conception et que pour y faire face, de nouveaux modèles ont été envisagés. Les modèles utilisés dans ce cas sont souvent des modèles graphiques qui doivent permettre d’exprimer les concepts et les contraintes métier.

2Un des risques liés à l’utilisation de modèles est de produire des modèles inutiles ou incompréhensibles. Les modèles s’appuyant sur des langages, la question qui se pose est : qu'en est-il de l’adéquation des langages de modélisation aux besoins des concepteurs ?

3Offrir un langage de modélisation adapté aux compétences et connaissances des futurs utilisateurs de ce langage permet la construction de SI en totale adéquation avec l’organisation à laquelle ils sont dédiés. Cette approche est particulièrement pertinente dans le cadre d’organisations complexes et évolutives telles que les écosystèmes basés sur des processus innovants non maitrisés (par exemple l’écosystème du maintien des personnes fragiles à domicile (Cortes-Cornax et al. 2015). Au sein de telles organisations, tout projet d’innovation nécessite des innovations organisationnelles impliquant des refontes du SI. L’alignement entre l’innovation organisationnelle, les processus inter-organisationnels innovants (nouveaux acteurs, nouvelles interactions, nouveaux services, etc.) et le SI support passe par l’adoption des langages qui permettent de le représenter.

4Souvent, les langages de modélisation sont conçus par des experts en langage de modélisation sans prendre en compte les concepteurs, futurs utilisateurs des langages (Mandran et al., 2013). Même si certains travaux étudient la qualité d’un langage du point de vue des utilisateurs (Krogstie et al., 2006) ou en fournissent des évaluations (Siau et Tian, 2001; Aranda et al., 2007 ; Patig, 2008), peu de travaux proposent une prise en compte systématique de l’utilisateur dans la conception des langages de modélisation.

5Or le développement de langages spécifiques à un domaine (DSL) rend essentiel l'intégration de l'utilisateur (i.e., l'expert du domaine) dans le développement des langages de modélisation de leur domaine. Cet article s’inscrit donc dans une démarche d'ingénierie des langages de modélisation des SI en proposant un processus de développement garantissant la qualité du langage, en particulier son adéquation aux futurs utilisateurs du langage. Il montre l’intégration des pratiques expérimentales de la conception centrée utilisateur au sein du cycle de développement d’un langage permettant ainsi de construire des langages adaptés à leurs futurs utilisateurs, les concepteurs de modèles.

6Nous illustrons notre démarche par le développement d'un langage dédié au domaine des chorégraphies de services (Peltz, 2003). La notion de chorégraphie a émergé au cours des dernières années comme un concept fondamental pour la capture, la représentation et l’exécution des processus inter-organisationnels. Un processus inter-organisationnel intègre les processus internes de plusieurs organisations afin de réaliser un objectif commun. Ainsi, les modèles de chorégraphie servent à mieux comprendre, construire, analyser et maîtriser la complexité des processus inter-organisationnels supportés par les systèmes d’information. Dans cet article, nos études empiriques portent sur ce concept.

7Dans la section suivante (section 2), nous présentons le contexte de ce travail : la définition des langages de modélisation en nous appuyant sur l'exemple des langages de chorégraphie. Dans la section 3 nous présentons les travaux existants sur la qualité des langages ainsi que les différentes démarches de construction des langages. La section 4 présente notre cycle de construction de langage de modélisation de qualité intégrant la démarche centrée utilisateur. Les expérimentations menées au Laboratoire d’Informatique de Grenoble et qui nous permettent aujourd’hui d’aboutir à ce cycle de construction sont présentées dans la section 5. Enfin nous concluons par une synthèse et les perspectives de ce travail (section 6).

2.Contexte de notre étude : les langages de modélisation

8Dans cette section, nous introduisons le contexte dans lequel nous travaillons : les langages de modélisation. Afin d'introduire ce domaine d'une manière graduelle, nous présentons dans la section 2.1 un cas d'étude pour illustrer le besoin de langages de modélisation. Ensuite, la section 2.2 fournit un exemple de modèle basé sur le cas d'usage. Finalement, la section 2.3 présente les concepts de base d’un langage de modélisation.

2.1.Cas d’étude : l’arrivée inattendue d’un avion à un aéroport

9Le cas d’étude choisi pour illustrer notre approche concerne la gestion d’une arrivée inattendue de passagers dans un aéroport suite au déroutement d’un avion causé par des intempéries dans la ville de destination. La compagnie aérienne de l’avion dérouté doit trouver à loger les passagers de l’avion avant leur nouveau départ vers leur destination finale. Cet exemple sert à illustrer le concept de modèles en informatique ainsi que notre démarche centrée utilisateur pour la définition du langage sous-jacent. Ce scénario est inspiré du cas d’étude traité dans le projet CHOREOS.

Image 10000201000001F40000014EF613CE1B.png

Figure 1 : Illustration du cas d’utilisation – arrivée inattendue d’un avion à un aéroport

10Dans la définition de ce scénario, illustré par la Figure 1, nous distinguons trois concepts principaux : les rôles, les acteurs jouant ces rôles et les interactions. Un rôle définit le comportement d’un acteur dans la chorégraphie. Un rôle est une abstraction d’un service qui doit être fourni dans le cadre d’une chorégraphie. C’est donc une entité liée au modèle de chorégraphie. Pour la chorégraphie associée à cet exemple, nous avons besoin d’un rôle Déclencheur qui déclenche l’alarme dans une situation d’urgence. Un acteur est une entité qui joue un ou plusieurs rôles dans une chorégraphie. Eventuellement, un acteur pourrait jouer d’autres rôles dans d’autres chorégraphies. L’acteur est donc celui qui réalise le service à fournir. Dans notre scénario, le Pilote est l’acteur qui joue le rôle de Déclencheur. Un acteur peut donc être une personne (ex. Pilote), une partie d’une organisation (ex. Personnel au Sol de la compagnie) ou une organisation (ex., Agence de Voyages exploitant l’aéroport). Une interaction représente une communication entre deux rôles. Une interaction génère un échange de messages entre un rôle initiateur et un rôle récepteur.

11Dans ce scénario nous observons que parmi les acteurs impliqués (ex. Pilote, Personnel au Sol ou Aéroport), aucun n'a le pouvoir de décision nécessaire pour incarner un point central de contrôle. La solution à ce problème est naturellement fournie par le paradigme de chorégraphie qui est distribué par nature : il n’y a pas de responsable unique. La responsabilité est partagée par tous les acteurs jouant les différents rôles. Cet exemple illustre la potentielle complexité des processus inter-organisationnels et le besoin de les spécifier.

2.2.Exemple de modèle de chorégraphie

12La Figure 2 est un exemple de modèle de chorégraphie correspondant au scénario. Notez que nous simplifions le modèle afin qu'il soit plus lisible en nous focalisant sur le Déclencheur, le Contrôleur et le Coordinateur Alarme. Ce modèle décrit d'une part, la vue structurelle modélisant les acteurs jouant des rôles et leurs relations (partie gauche de la figure 2) et d’autre part, la vue comportementale représentant les interactions, leur ordre, les rôles initiateur et récepteur de chacune d’elles. Le bandeau blanc (resp. gris) indique le rôle initiateur (resp. récepteur) d’une interaction. Par exemple, la première interaction (Informer crise) est initialisée par le Déclencheur (Pilote) et reçue par le Contrôleur (Aéroport). Le branchement, dépend de l’avis du Coordinateur Alarme qui évalue si l’alarme a été traitée de manière satisfaisante (OK? = Oui) ou pas (OK? = Non). Les relations dans la vue structurelle impliquent des interactions dans la vue comportementale.

Image 10000201000001F4000000E074CBBBB7.png

Figure 2 – Modèle de chorégraphie correspondant au cas d’étude modélisé

13Nous proposons ces modèles pour capturer des chorégraphies s'appuyant sur la notation proposée par BPMN 2.0 (OMG, 2011), un langage très répandu dans le domaine de la modélisation de processus, qui sert de base pour notre proposition.

2.3.Langages de modélisation en informatique

14Selon la distinction faite par Kleppe (Kleppe, 2007), un langage de modélisation est constitué de trois parties (figure 3) : le méta-modèle, composé de concepts et associations entre ces concepts et désigné par « syntaxe abstraite », les notations associées au langage désignées par « syntaxe concrète » et la sémantique qui établit le lien entre le modèle et son domaine ou la connaissance des spécialistes du domaine. La description de la sémantique correspond aux moyens de communiquer une compréhension des éléments linguistiques du langage en direction d'une ou plusieurs autres entités (personnes ou machines). Elle fait partie d'un langage pour permettre à son concepteur de communiquer sa compréhension du langage.

15Les langages s’appuient sur des outils (éditeurs, animateurs, vérificateurs syntaxiques ou sémantiques, etc.). En particulier, le développement d’éditeurs de modèles basés sur les syntaxes abstraites et concrètes est devenu courant avec des outils tels que les outils de modélisation EMF1 et GMF2 d'Eclipse.

Image 10000201000001F4000002CC421E1162.png

Figure 3 : Les éléments d’un langage de modélisation et ses relations

16Le méta-modèle peut fournir une partie de la sémantique du langage. La notation graphique peut aussi aider à définir la sémantique du langage grâce, par exemple, à des icônes très expressives. Donc, les concepts du domaine, généralement groupés dans un dictionnaire de termes, peuvent être complétés par le méta-modèle et la notation graphique.

17Un modèle doit être conforme au méta-modèle, mais doit aussi respecter les contraintes données par la syntaxe concrète et la sémantique du langage. Grâce au langage, on peut exprimer des modèles qui représentent un système existant ou à construire.

18La Figure 4 illustre la relation de conformité entre plusieurs modèles et un méta-modèle. Les deux premiers modèles (aéroport et e-business) respectent toutes les contraintes du méta-modèle ainsi que la notation. Ils sont donc conformes au méta-modèle et à la notation. Par contre, le troisième modèle n’est pas en conformité avec le méta-modèle. La relation RevueRel n’admet qu’un seul rôle alors que le méta-modèle impose l’implication d’au moins deux rôles dans une relation (multiplicité 2..* de la relation Rôle dans le méta-modèle). Dans son état actuel, ce modèle n'est donc pas conforme au méta-modèle.

Image 10000201000001F4000000F0EF7C8750.png

Figure 4 : Illustration de la conformité de plusieurs modèles à un méta-modèle

19L'Ingénierie Dirigée par les Modèles (IDM) fournit les briques de base (syntaxe abstraite, concrète et outils) pour créer facilement de nouveaux langages adaptés aux besoins spécifiques d’un domaine, d’un niveau d’abstraction, etc.

3.Etat de l’art

20Dans ce travail, nous nous intéressons au développement des langages de modélisation. Notre objectif est de produire des langages de modélisation de qualité. Aussi commençons-nous par les travaux existants permettant de définir la qualité des langages de modélisation (section 3.1). Nous discutons la notion générale de qualité d’un langage (section 3.1.1), puis nous nous focalisons sur la qualité des composants du langage (section 3.1.2). Nous étudions également les différents rôles à prendre en compte pour évaluer la qualité (section 3.1.3), et enfin nous présentons les méthodes d’évaluation de la qualité (3.1.4).

21La section 3.2 présente l’approche centrée utilisateur que nous proposons d’intégrer dans le développement des langages. Nous étudions ici l’intérêt des langages spécifiques au domaine (section 3.2.1) et nous présentons les démarches centrées utilisateur (3.2.2).

22Enfin, nous concluons cet état de l’art avec une synthèse qui résume les points traités faisant partie de notre approche de développement de langages de modélisation de qualité (section 3.3).

3.1 Qualité des langages de modélisation

23L’organisation internationale de normalisation (ISO3) définit un modèle de qualité comme un moyen de raisonner de manière objective et systématique sur la qualité : “A quality model is a framework that provides a concrete mechanism for reasoning about quality in a systematic and objective manner” (ISO-IEC 9126-1 (ISO, 2001)). Cette norme nous sert comme cadre pour traiter le domaine de la qualité. Les sections qui suivent abordent la qualité de manière plus spécifique aux langages de modélisation.

3.1.1.Evaluation globale de la qualité

24La qualité des langages est généralement abordée par une approche expérimentale (Siau et Tian, 2001). De manière plus générique, (Aranda et al., 2007) et (Patig, 2008) proposent des protocoles expérimentaux applicables à n’importe quel langage pour évaluer leur facilité de compréhension. Néanmoins ils n’abordent que l’aspect de la qualité des langages. En adoptant une approche plus générale, Krogstie (Krogstie, 2003) propose un cadre d'évaluation générique pour étudier les langages dans leur globalité (syntaxe et sémantique). L'auteur identifie cinq caractéristiques pour un langage de modélisation :

25- la convenance au domaine : Krogstie explique que les concepts du langage doivent permettre d’exprimer toutes les connaissances d’un domaine, mais pas plus. Cette caractéristique est liée à la sémantique du langage. Par exemple, notre langage de chorégraphie se restreint effectivement au domaine des chorégraphies de services.

26- la convenance aux connaissances des concepteurs : le langage doit être adapté aux acteurs de la modélisation (i.e. les concepteurs de modèles). Ainsi il vaut mieux baser un langage sur l’expérience acquise par l'utilisation antérieure d’autres langages précédemment utilisés. Dans notre cas, nous proposons un langage basé sur BPMN 2.0, qui propose une notation pour les chorégraphies que nous améliorons. Il doit être adapté aux concepteurs de processus inter-organisationnels.

27- la convenance à externaliser les connaissances : toutes les assertions dans les connaissances explicites des participants doivent pouvoir être exprimées dans le langage. Cette caractéristique est aussi relative à la qualité de la sémantique. Notre langage permet de prendre en compte la connaissance métier de personnes faisant partie de la chorégraphie (par exemple, un rôle).

28- la convenance à comprendre pour les parties prenantes : le langage doit être accessible aux parties prenantes, il ne doit pas avoir de trop nombreux concepts, les concepts doivent être distinguables les uns des autres, etc. Dans notre proposition, nous essayons de minimiser le nombre de concepts et de les représenter via une notation graphique afin de les rendre plus compréhensible.

29- la convenance à l’interprétation par des acteurs techniques : la syntaxe et la sémantique du langage doivent être suffisamment formelles pour que les acteurs techniques, c’est-à-dire les outils de modélisation, puissent automatiser certains traitements sur les modèles. Dans notre langage, les concepts et leurs relations sont décrits avec une notation textuelle équivalente, compréhensible par les outils.

30Ce cadre a été régulièrement utilisé pour mesurer la qualité de nouveaux langages. Par exemple (Cortes-Cornax et al, 2011; Nysetvold et Krogstie, 2006; Wahl et Sindre, 2005) l’utilisent pour évaluer le langage BPMN (OMG, 2011).

3.1.2.Evaluation suivant les composants d’un langage

31Une autre approche est de s’appuyer sur la définition d’un langage. Le langage est évalué à partir de ses trois composants que sont sa syntaxe abstraite, sa syntaxe concrète et sa sémantique. L’évaluation de la syntaxe abstraite suppose l’étude du méta-modèle du langage. La partie haute de la Figure 5 capture une version simplifiée du méta-modèle de notre langage définie de la manière suivante : une chorégraphie d’un point de vue structurel est composée d’un ensemble de Rôles et de Relations entre Rôles. Un Rôle (entité abstraite comme par exemple le Déclencheur) est joué par un Acteur (entité concrète comme par exemple le Pilote). Dans une chorégraphie, un acteur peut jouer plusieurs rôles et un rôle peut être joué par plusieurs acteurs. D’un point de vue comportemental, une chorégraphie est un conteneur d’éléments de flux. Un Elément de Flux peut être soit une Séquence de Flux soit un Nœud. Ces derniers peuvent être de trois types différents : 1) des Evénements, comme par exemple l’événement de type StartEvent, 2) des Branchements, comme par exemple un branchement exclusif ou 3) des Interactions. Une interaction représente une communication entre deux ou plusieurs Rôles. Dans notre exemple, le Déclencheur pourrait alerter en même temps le Coordinateur de l’Alarme et le Contrôleur.

32Rossi et Brinkkemper (Rossi et Brinkkemper, 1996) font l’hypothèse qu’il existe une dépendance intrinsèque entre les méta-modèles et la facilité d’apprentissage du langage : "the more complex a metamodel, the harder the method is to learn". Ainsi ils s’intéressent à la complexité conceptuelle théorique d’un méta-modèle et cherchent à la calculer. Ce travail a permis de comparer plusieurs langages de modélisation orientés objet à partir de leur méta- modèle et conclut qu’ils deviennent plus complexes au fil du temps. (Mohagheghi et Aagedal, 2007) font une autre hypothèse sur les caractéristiques d’un méta-modèle : ils pensent que la complexité du méta-modèle influence le pouvoir d’expression du langage. Ainsi un méta- modèle complexe sera jugé comme ayant un fort pouvoir d’expression et pourra donc permettre de créer des modèles plus petits. Néanmoins, ces travaux ne permettent pas d’aborder toutes les caractéristiques de la qualité d’un méta-modèle. Aussi l’évaluation d’un méta-modèle ne peut actuellement être abordée que de manière expérimentale.

Image 10000201000001F4000000FD520B5622.png

Figure 5 : Relation entre les modèles de chorégraphie et leur méta-modèle

33La deuxième composante d’un langage est sa syntaxe concrète, c’est à dire sa notation. Dans ce cadre, nous pouvons noter la Théorie de la Physique des notations (Moody, 2009) qui donne neuf principes pour concevoir des notations visuelles cognitivement efficaces. Nous citerons à titre d’exemple la clarté sémiotique, qui aborde essentiellement la nécessaire correspondance 1 - 1 entre les éléments de la syntaxe abstraite et ceux de la syntaxe concrète. Par exemple, dans la Figure 5 nous observons une correspondance 1 - 1 entre les éléments graphiques et les concepts décrits dans le méta-modèle. Cette relation "un concept - un élément graphique" rend plus compréhensible une notation graphique. Notez que les classes abstraites comme Elément de Flux et Nœud ne sont pas représentées graphiquement car ce sont des concepts abstraits.

34Un autre exemple concerne la transparence sémantique (Moody, 2009) qui définit dans quelle mesure la signification d’un symbole peut être déduite de son apparence. Si ces principes sont intéressants et nous permettent de mieux caractériser les aspects à évaluer d’un langage, ils ne sont néanmoins pas suffisamment précis pour permettre une évaluation automatique ou la mise en place de protocoles expérimentaux génériques.

35Quant à la sémantique, sa qualité est généralement mesurée par la capacité à être interprétée par un ordinateur. Ainsi (Kleppe, 2007) identifie 4 façons (dénotationnelle, opérationnelle, translationnelle et pragmatique) pour définir formellement la sémantique d’un langage. Ce n’est pas cet aspect qui nous intéresse ici. Dans ce travail, nous nous intéressons à la signification du langage du point de vue de l’humain et non de la machine.

36Les travaux sur la qualité des langages de modélisation nous permettent de caractériser les propriétés que nous souhaitons évaluer. Mais ils doivent s’inscrire dans une approche plus large qui permet d’appréhender et d’évaluer la qualité d’un langage de manière globale.

3.1.3.Rôles dans l’évaluation d’un langage

37Les rôles nécessaires dans l’évaluation d’un langage sont les experts métier futurs utilisateurs du langage et également des utilisateurs d’une application construite à partir de ce langage. Ainsi, pour le développement d’un langage, trois rôles peuvent être identifiés : le concepteur du langage (CL) expert en modélisation, l’utilisateur du langage (UL), souvent expert métier, et l’utilisateur de l’application (UA) réalisée avec le langage. La Figure 6 illustre les trois rôles et indique la partie dans laquelle ils interviennent.

Image 10000201000001F4000001AE95DB141F.png

Figure 6 : Rôles pour l’évaluation d’un langage

3.1.4.Méthodes d’évaluation

38Les méthodes à utiliser lors du processus de développement d’un langage vont naturellement dépendre des objectifs de l’étude et des objets à étudier. Il faut cependant distinguer deux grandes familles de méthodes : les méthodes qualitatives et les méthodes quantitatives. La section 5 présentera des exemples de ces différentes méthodes.

39Les méthodes qualitatives ont pour objectif de comprendre en profondeur les utilisateurs et leur environnement. Ce sont des méthodes qui vont laisser libre cours au discours, au vécu, aux habitudes. Elles sont des outils performants pour identifier une diversité de situations, pour avoir différents points de vue, pour faire échanger des utilisateurs lors de travaux de groupe et pour recenser un maximum d’usages, de comportements, d’opinions. Elles sont utilisées quand l’utilisateur et son environnement sont mal connus, mais aussi lorsque l’objet d’étude ne peut fournir ni des mesures chiffrées, ni des traces d’activités. Pour la production des données qualitatives, les principales méthodes d’investigation sont les entretiens individuels, les focus-groups et l’observation in situ. Les entretiens individuels sont réalisés en face à face avec l’utilisateur, ils sont menés avec un guide d’entretien. Un focus-group correspond à des réunions dans lesquelles les participants vont réaliser différentes activités. Nous ne détaillerons pas plus les méthodes qualitatives, de nombreuses publications existent sur chacune d’elles, en particulier les travaux de Per Runeson et Martin Höst (Runeson et Höst, 2008).

40Les méthodes quantitatives ont pour objectif de quantifier et de mesurer un certain nombre de métriques prédéfinis. Pour les applications informatiques, ces mesures peuvent s’intéresser aux performances des outils ou aux opinions des utilisateurs sur l’outil. Les méthodes statistiques permettent de construire un dispositif de mesure et de contrôle des valeurs. Le plus souvent, ces dispositifs sont construits selon un plan expérimental, qui compare la nouvelle application à un outil de référence (Snedecor et Cochran, 1957). L’ensemble des données est ensuite testé avec des méthodes d’analyses statistiques (Snedecor et Cochran, 1957).

41Une approche complémentaire et plus générale est assurée par des cadres d'évaluation de la qualité tels que le cadre sémiotique proposé par Krogstie (Krogstie, 2003) présenté dans la Section 3.1.2. Ce cadre évalue un large éventail de caractéristiques d'un langage afin qu'il puisse être considéré comme un «guide» pour évaluer la qualité des langages.

3.2.Démarches de développement d’un langage de modélisation

3.2.1.Construction des langages de modélisation spécifiques au domaine

42Nous mettons l'accent sur la construction des langages spécifiques au domaine (DSL – Domain Specific Languages). Un des travaux les plus importants autour des DSL est celui de Mernik et al. (Mernik et al. 2005) qui donne un certain nombre de patrons pour la construction de langages, notamment ceux qui sont spécifiques à un domaine. Le processus de développement du DSL est divisé en cinq étapes : décision, analyse, conception, implémentation et déploiement. Le travail de Ceh et al. (Ceh et al., 2011) complète cette démarche en proposant les étapes de test et de maintenance. Dans ces travaux, les utilisateurs finaux du langage ne sont considérés que de manière ponctuelle. Cette démarche propose uniquement l'utilisation des méthodologies centrées utilisateur pouvant être appliquées pour une étape particulière. Par exemple, la méthode FODA (Kang et al., 1990) est considérée pour réaliser l'analyse du domaine. Cependant, nous observons que les utilisateurs finaux ne sont pas intégrés de manière systématique dans le processus de développement du langage. Or, cette intégration devient nécessaire dans le cadre des langages spécifiques au domaine (Villanueva et al., 2013). Villanueva et al. s'appuient sur la démarche proposée par Mernik et al. (Mernik et al. 2005) et intégrent les utilisateurs dans les décisions de conception du DSL, notamment sur les points moins techniques comme le développement de la syntaxe concrète du langage (Villanueva et al., 2013).

43Dupuy et al. (Dupuy-Chessa et al., 2014) montrent aussi l'intérêt d'une approche centrée sur l'humain pour le développement de langages de modélisation dédiés. Les auteurs proposent un cycle de développement intégrant la mise en place de la syntaxe concrète et abstraite de manière itérative. Cette dernière proposition manque de formalisation et ne propose pas une démarche qui prend en compte le cycle complet de développement.

44Au contraire, nous proposons dans cet article un cycle d'ingénierie couvrant l’intégralité du développement des langages (analyse, conception et opérationnalisation) et mettant les différents types d’utilisateurs de ce langage (concepteur du langage, utilisateur du langage et utilisateur de l’application) au centre du développement en intégrant dans chaque étape une démarche centrée utilisateur.

3.2.2.Démarche centrée utilisateur (DCU)

45La démarche centrée utilisateur (DCU) telle que décrite par la norme ISO134074, présente le développement des applications informatiques comme un cycle intégrant l’utilisateur dès le début de la conception. La DCU se préoccupe à la fois de la nature de la connaissance, du lien entre l’utilisateur et son contexte et de ses représentations fonctionnelles. De plus, les méthodes d’évaluation utilisées dans la DCU sont non seulement multiples et variées, mais aussi qualitatives et quantitatives. Les trois phases de la DCU sont l’analyse, la conception et l’évaluation. La norme ISO13407 vise le champ du cycle de conception d'applications informatiques et détermine les exigences auxquelles un projet doit répondre pour être considéré comme "centré sur l'humain". Elle concerne la méthodologie de conception. Suivant la norme AFNOR (AFNOR, 2003), elle doit prendre en compte :

46- une préoccupation amont des utilisateurs, de leurs tâches et de leur environnement, la participation active de ces utilisateurs, ainsi que la compréhension claire de leurs besoins et des exigences liées à leurs tâches,

47- une répartition appropriée des fonctions entre les utilisateurs et la technologie,

48- l'itération des solutions de conception : on peut imaginer le cycle comme une spirale, une démarche qui boucle et reboucle jusqu'à ce que le système satisfasse aux exigences définies au départ.

49- l'intervention d'une équipe de conception multidisciplinaire. La conception centrée utilisateur représente en effet plus que de simples considérations sur l'utilisabilité. Son caractère global vise une expérience utilisateur optimale. Cette notion d'expérience utilisateur est au carrefour de disciplines différentes (design, marketing, qualité, etc.).

3.2.3.Phases de la démarche centrée utilisateur

50Dans une démarche centrée utilisateur, la phase d’analyse doit permettre, relativement au sujet étudié, de recenser les pratiques des utilisateurs, de connaître leur environnement, leurs besoins et leurs attentes. Pour cela, les méthodes préconisées sont des entretiens semi-directifs individuels et des observations en situation. En effet, elles permettent de recueillir des informations précises et d’aller en profondeur dans le questionnement. Un travail de groupe est moins fructueux car le questionnement ne peut pas être individuel et les personnes sont influencées par le groupe (Paillé et Mucchielli, 2012).

51La phase de conception est celle qui donne les éléments pour construire une application, un outil, etc. Pour cela, une méthode souvent utilisée est le focus-group. L’objectif est de « créer un espace de délibération » autour d’un objet (Baribeau et Germain, 2010). Un ensemble de participants est réuni. Au travers de différentes activités, on leur demande de construire un outil ou d’utiliser une application, un débriefing est mené pour recueillir leurs avis et les pistes d’améliorations. Le déroulement du focus-group est cadré par une grille d’animation pour contrôler le temps de la séance. Ce travail de groupe permet la confrontation des idées. Des périodes de travail individuel sont souhaitables pour éviter l’influence du groupe.

52La phase d’évaluation permet de mesurer auprès des utilisateurs différents critères, par exemple, l’utilisabilité (Dumas et Fox, 2009), la satisfaction, la performance des outils. Les méthodes mises en œuvre sont des méthodes ergonomiques et/ou des méthodes statistiques.

3.3.Synthèse

53Pour la conception de langages spécifiques au domaine, nous avons pu constater par les expériences successives que nous avons menées (cf. section 5), que la démarche centrée utilisateur est une méthode utile, utilisable et qui peut être appliquée à chacune des étapes du processus de développement d'un langage. Par l’intégration de l’utilisateur, elle permet de limiter les erreurs de développement, ce qui aura des effets positifs sur les applications. Un autre aspect intéressant de la démarche centrée utilisateur est la possibilité d’utiliser des méthodes variées (qualitatives et quantitatives) pour conduire un développement méthodologiquement contrôlé avec des méthodes adaptées aux mesures à effectuer.

54Dans nos études, nous préférons utiliser le terme « explorer » plutôt que le terme « analyser ». Selon le TLFI5, la définition du verbe « explorer » correspond à « parcourir et/ou examiner de fond en comble pour découvrir quelque chose » et celle du verbe « analyser » correspond à « décomposer un tout en ses éléments de manière à le définir, le classer, le comprendre ». Pour la conception des langages spécifiques, les études sur le vocabulaire et les pratiques des utilisateurs vont explorer et parcourir un domaine inconnu pour fournir des éléments de compréhension.

55Pour le terme de « conception », nous préférons utiliser le terme de « co-construction » car dans cette phase, la dimension collaborative pluridisciplinaire est indispensable car les travaux collectifs se basent sur « le processus d'allocation des tâches selon les compétences, la synchronisation des actions, la gestion des conflits et les fonctions de communication » (Darses et Falzon, 1996). Cet aspect collaboratif n’est pas naturellement présent dans le terme de « conception ».

56Enfin, en ce qui concerne le terme d’« évaluation », nous préférons utiliser le terme de « validation » : en effet, une évaluation peut être conduite aussi bien dans la phase d’exploration que dans celle de co-construction. Cette démarche centrée utilisateur doit être intégrée dans une ingénierie de langages de qualité qui prend en compte les différents composants d'un langage.

4.Vers une ingénierie de langages de modélisation de qualité

57Dans cette section, nous présentons les points principaux de notre démarche dédiée à une ingénierie de langages de modélisation de qualité. Nous présentons ses principes dans la section 4.1 et proposons une vue générale de notre démarche dans la section 4.2. La section 4.3 détaille les trois étapes proposées pour le développement d'un langage et la section 4.4 se focalise sur l'intégration de la démarche centrée utilisateur dans le développement d'un langage.

4.1.Principes pour l’élaboration de langages de modélisation

58Notre proposition, issue des expériences réalisées depuis 2008 lors de l’élaboration de langages de modélisation dans un cadre académique, repose sur les trois principes cités ci-dessous que nous développons par la suite :

59- un langage de modélisation est un produit d’ingénierie qui en tant que tel doit être le résultat d’un processus de développement ;

60- l’évaluation d’un langage doit être réalisée tout au long du processus de développement du langage et porter sur l’ensemble des composants du langage ;

61- des expérimentations centrées utilisateur peuvent permettre la validation de tout ou partie du langage, mais sont également utiles en phases d’exploration construction et de co-construction.

62Dans les sections qui suivent, nous développons ces principes en proposant d'intégrer une démarche centrée utilisateur dans un processus de développement d'un langage.

4.2.Vue générale du processus du développement d’un langage de modélisation intégrant la démarche centrée utilisateur

63Qu’il s’agisse d’un « vrai » nouveau langage, d’une extension d’un langage existant voire même d’une évolution majeure d’un langage existant, le développement d’un langage doit suivre un processus de développement : analyse conceptionopérationnalisation, où chaque étape génère et valide des produits, en l’occurrence des composants du langage. La figure 7 illustre les trois étapes de développement d'un langage que nous proposons. La figure 7 montre aussi les produits créés ou modifiés durant ces étapes et surtout ceux qui doivent absolument faire l’objet d’une validation avant de passer à l’étape suivante. Il est par exemple inutile de développer un méta-modèle extrêmement formalisé tant que le dictionnaire de concepts n’est pas validé.

64De plus, nous proposons d'intégrer la Démarche Centrée Utilisateur (DCU) dans chacune de ces étapes du processus de développement d'un langage afin de délimiter les erreurs de développement. Les phases proposées sont exploration, co-construction et validation.

Image 10000201000001F4000000E784586A2F.png

Figure 7 : Cycle d’évaluation intégré au cycle de développement d’un langage

65Les trois étapes du développement du langage (i.e., analyse, conception et opérationnalisa-tion) ainsi que les trois phases d'évaluation concernant la DCU (i.e., exploration, co-construction et validation) sont détaillées par la suite.

4.3.Les trois étapes du développement du langage de modélisation

66Comme dans toute démarche d’ingénierie, l’analyse est destinée à formaliser le problème. Dans le cas de l’analyse des langages de modélisation, il s’agit à minima de produire la sémantique du langage sous la forme par exemple d’un dictionnaire de concepts du langage.

67Nous préconisons également de caractériser le langage en précisant à qui il s’adresse, pour quels domaines applicatifs et/ou technologiques, comment sera défini son méta-modèle, les outils envisagés, etc. Cette caractérisation constitue ce que l’on pourrait appeler la carte d’identité du langage. Une ébauche de syntaxe concrète peut être produite, en particulier pour pouvoir « manipuler » les concepts.

68La conception consiste à produire une solution compatible avec les connaissances scientifiques actuelles. Pour un langage de modélisation, il s’agit de formaliser son méta-modèle en adoptant des techniques de méta-modélisation ainsi que sa syntaxe concrète (graphique et/ou textuelle). Les référentiels de qualité présentés en Section 3.1.2 constituent à ce niveau des cadres structurants pour étudier des méta-modèles et des syntaxes concrètes de qualité. Des maquettes d’outils peuvent déjà être élaborées en particulier pour tester la syntaxe concrète dans un cadre informatisé.

69L’opérationnalisation consiste à produire les outils supports du langage : au minimum un éditeur graphique pour les langages de modélisation, des outils de transformation si une démarche de modélisation par abstraction ou composition est proposée, etc.

70L’analyse, la conception et l’opérationnalisation d’un langage de modélisation sont des étapes destinées à produire et valider les composants d’un langage. La caractérisation du langage et son dictionnaire sont validés à l’issue de l’analyse, le méta-modèle et la syntaxe concrète à l’issue de la conception et finalement les outils supports au langage à l’issue de l’opérationnalisation. Cependant les produits sont graduellement introduits. C’est ainsi que pour valider un dictionnaire de concepts, on a souvent besoin dès la phase d'analyse, de proposer une syntaxe concrète permettant de « manipuler » les concepts. Mais, s'il est fondamental en phase d'analyse de stabiliser les concepts et leurs définitions, il n’est pas encore nécessaire de stabiliser la représentation graphique de ces concepts.

71La Figure 7 précise entre crochets les états des différents composants d’un langage durant les trois étapes de développement. Un composant peut être dans l'état non abordé, abordé, en cours de validation ou validé. C’est ainsi que :

72- l'étape d’analyse d’un langage valide sa caractérisation, le dictionnaire de concepts et aborde la syntaxe concrète et les outils,

73- l'étape de conception valide le méta-modèle et la syntaxe concrète et peut produire des maquettes d’outils,

74- finalement l'étape d’opérationnalisation valide les outils. La syntaxe concrète est alors intégrée à l'outil et considérée comme un composant à étudier lors de l'évaluation de l'outil.

75Il n’est pas rare que la syntaxe concrète dans sa forme opérationnelle s’éloigne un peu de celle produite en conception, en particulier les icônes sont souvent différemment représentés dans un outil ou avec un crayon et un papier. Mais l’évaluation de la syntaxe concrète via des outils peut aussi remettre en jeu des choix validés en conception, tout simplement parce que les expérimentations peuvent être plus rapides et plus nombreuses par l’intermédiaire des outils logiciels.

76Chaque étape intègre un processus d’évaluation centré utilisateur destiné à explorer, co-construire et valider les produits créés ou modifiés durant l’étape.

4.4.Processus d’évaluation centré utilisateur

77Les étapes que nous avons décrites dans la section précédente s’inscrivent dans un processus complet de développement de langages où l’évaluation est centrale. Deux principes que nous défendons ici est que d’une part l’évaluation d’un langage doit être réalisée tout au long du processus de développement et que d’autre part l’évaluation doit être réalisée par des expérimentations centrées utilisateur. Il s’agit d’impliquer les futurs utilisateurs d’un langage dès l’étape d’analyse. Suivant les langages, les utilisateurs peuvent être des experts d’un domaine, des analystes, des concepteurs, ... Mais ils peuvent être aussi des non-experts des langages et des méthodes de modélisation. Des expérimentations impliquant les futurs utilisateurs du langage doivent être menées tout au long du processus de développement, certes pour valider le langage, mais également pour l’explorer et le co-construire. Nous proposons d’introduire un processus d’évaluation centré utilisateur dans chaque étape du développement (cf. Figure 7).

78Ce processus est constitué de trois phases : exploration, co-construction et validation. Ces trois phases ne doivent pas systématiquement être réalisées, mais il est nécessaire de se poser la question de leur nécessité, ce questionnement pouvant éviter de nombreuses erreurs. Par exemple, lors de la proposition de notre langage de chorégraphie, la phase de validation lors de l'analyse n'a pas donné lieu à des expérimentations utilisateurs : une revue bibliographique et une analyse experte ont été considérées suffisantes.

79L’exploration s’appuie bien entendu sur un état de l’art du domaine sociétal, organisationnel et/ou technique du langage, mais doit également prendre en compte les besoins des futurs utilisateurs potentiels. C’est ainsi que lors de l’étape d’analyse du langage, la phase d’exploration peut par exemple être réalisée par des entretiens ou des observations dont l’exploitation permettra une première ébauche des concepts du langage.

80La co-construction consiste à impliquer les utilisateurs dans l’élaboration de la proposition. Il s'agit ici de co-établir avec les utilisateurs, le dictionnaire des concepts, la syntaxe concrète ou encore les outils à élaborer, cette co-construction permettant évidemment que les propositions soient conformes aux besoins des utilisateurs.

81Enfin, la validation, plus classique, consiste à faire évaluer la proposition finale par les utilisateurs à l'aide d'entretiens ou de questionnaires supportés par la réalisation de tâches.

82Bien entendu, le processus est incrémental et peut nécessiter plusieurs itérations. La Figure 7 illustre la première itération (flèche pleine) ainsi que les itérations possibles (flèches pointillées bi-directionnelles) dues aux retours des évaluations.

83Dans la suite, nous proposons d'illustrer cette démarche de développement d'un langage avec le langage de chorégraphie présenté précédemment. Nous proposons également une discussion et un retour d'expérience sur différentes études empiriques réalisées.

5.Illustration de la démarche via l’expérience d’études centrées utilisateur

84Cette section présente trois études réalisées durant le processus de développement du langage de chorégraphie. La section 5.1 donne une vue générale des études en les positionnant par rapport à la démarche centrée utilisateur. Les études empiriques sont traitées dans les sections 5.2, 5.3 et 5.4. Finalement, la section 5.5 résume et synthétise les leçons apprises et nos recommandations concernant ces études empiriques.

5.1.Vue générale des études réalisées

85Le tableau 1 propose une vue générale des trois études présentées par la suite. Pour chacune d’elles, nous indiquons l'étape du processus de développement (i.e., analyse, conception ou opérationnalisation), la phase du processus d’évaluation (i.e., exploration, co-construction ou validation) et l'objectif de l’étude. Notons qu’une étude composée de plusieurs parties peut concerner plusieurs phases.

Image 10000201000001F4000000A1ACAA6F48.png

Tableau 1 : Vue générale des études empiriques

86L’ordre de présentation des études correspond à l'ordre des étapes du processus de développement (analyse, conception) et des phases d’évaluation (analyse/exploration, conception/co-construction, conception/validation). Cet ordre ne correspond pas à l'ordre chronologique dans lequel nous avons réalisé les études. Nous discutons cette particularité et ses effets négatifs lors de la deuxième étude.

5.2.Première étude : cadre des exigences pour les langages de chorégraphies

87Cette étude présente le cadre des exigences pour les langages de chorégraphie que nous avons proposé. Elle sert à évaluer les langages de chorégraphie mais également de guide pour nos propositions. Ce cadre raffine un cadre de qualité de langages générique en l'adaptant au domaine des chorégraphies.

5.2.1.Positionnement de l’étude

88Nous nous situons dans l'étape d'analyse du processus d’ingénierie des langages afin de caractériser le langage de chorégraphies. Plus concrètement, nous nous plaçons dans la phase d'exploration consistant à réaliser une analyse du domaine pour étudier en profondeur les attentes et pratiques des utilisateurs (dans notre cas, les concepteurs de langages de chorégraphies).

89La méthode mobilisée durant cette étude est l'analyse par des experts. La construction a été principalement guidée par l’étude bibliographique du domaine et l’analyse des différents langages. De plus, l’analyse expert a été complétée par des discussions avec des chercheurs reconnus dans le domaine des chorégraphies (Marlon Dumas, Alistair Barros, Oliver Kopp et Andreas Schönberger).

90Nous nous positionnons donc dans une approche cadre de qualité (tableau 2).

Tableau 2 : Positionnement de la première étude

Image 10000201000001F400000034DA5514EF.png

5.2.2.Explication de l’étude

91Nous raffinons le cadre générique pour la qualité de langages défini par Krogstie (Krogstie, 2003) que nous avons présenté dans la section 3.1.1 afin de prendre en compte les caractéristiques propres aux chorégraphies.

92Le tableau 3 montre un extrait du cadre utilisé. Ce tableau se focalise sur la convenance au domaine qui traite la sémantique du langage. Pour la définition des critères, nous nous appuyons notamment sur les travaux de Decker et al. (Decker, et al., 2007) et Barros et al. (A Barros et al., 2005; A. Barros et al., 2007). Nous identifions par exemple des critères comme une spécification adéquate des participants et du contexte ou la prise en compte des patrons d'interaction.

93Le cadre reprend l’évaluation du langage BPMN 2.0 et résume les améliorations que nous avons proposées. Deux flèches ascendantes indiquent que des améliorations importantes ont été proposées. Une seule flèche indique que les contributions sont significatives mais moins importantes. Si aucune flèche n’est présente, cela signifie que nous ne proposons pas d’amélioration.

Tableau 3 : Extrait du cadre d’évaluation utilisé

Image 10000201000001F4000000DF04412828.png

94Ce cadre d’évaluation a permis dans un premier temps de caractériser de manière structurée les langages de chorégraphie, puis dans un deuxième temps, d'évaluer d'autres langages de chorégraphie existants. Finalement, il a permis de guider la caractérisation d'un nouveau langage, pour lequel nous proposons par exemple de nouveaux concepts (e.g., acteur - rôle) ainsi que d'aborder des nouvelles caractéristiques du langage concernant le méta-modèle et la syntaxe concrète.

5.3.Deuxième étude : analyse du méta-modèle et de la notation

95Cette étude a été temporellement la première dans le cadre de nos travaux sur les langages de chorégraphie. Nous nous appuyons sur un méta-modèle et une notation préliminaire proposés au début de notre travail à partir du langage WS-CDL (Cortes-Cornax, 2011).

5.3.1.Positionnement de l’étude

96Cette étude est composée de deux parties (cf. tableau 4), la première partie concerne le méta- modèle, la deuxième la notation graphique. Comme nous le spécifions dans la section 3.1.2, nous évaluons des composants du langage. Les deux parties se positionnement sur l'étape d'analyse. La première partie concerne la phase de validation. La deuxième partie se focalise sur les phases de co-construction et validation.

97Cette étude a été réalisée avec huit chercheurs spécialisés dans le domaine des services et / ou des processus métier que nous avons recrutés au sein des équipes ADELE et SIGMA du Laboratoire d'Informatique de Grenoble (LIG). Elle s’est déroulée lors d’une séance de trois heures. Nous voulions intégrer l’opinion des spécialistes (analystes) sur le concept de chorégraphies ainsi que sur sa représentation graphique. La première partie se déroule comme une analyse expert : les sujets travaillent principalement de manière individuelle, puis ils discutent entre eux afin de mutualiser les idées. La deuxième partie s'appuie sur un travail en équipe et des groupes de discussion (en anglais, focus-group). Ces deux méthodes correspondent à une famille de méthodes qualitatives.

Tableau 4 : Positionnement de la deuxième étude

Image 10000201000001F40000007601A47466.png

5.3.2.Explication de l’étude

98Le but de cette étude était d’extraire des nouvelles idées concernant la syntaxe abstraite (méta-modèle de chorégraphie) et la syntaxe concrète (la notation graphique) pour le langage de chorégraphies. L’étude s’appuie sur deux hypothèses : 1) notre méta-modèle représente bien la sémantique de la chorégraphie et 2) notre notation est plus appropriée pour les chorégraphies que celle de BPMN 2.0. La première hypothèse est basée sur l'identification des concepts du méta-modèle dans un scénario textuel (où une chorégraphie pourrait être appliquée). Le scénario traite la commande et l’envoi d’un ordinateur personnalisé chez un fabricant. Le tableau 5 décrit les différents points clés (hypothèse, moyens d’évaluation et protocole d’évaluation) concernant la première partie de l’étude. L’hypothèse fait référence à l’énoncé à valider. Les moyens d’évaluation précisent les outils ou modèles fournis aux sujets. Finalement, le protocole décrit les pas à suivre pour réaliser l’étude.

Tableau 5 : Deuxième étude : protocole de la première partie

Image 10000201000001F4000000BB2C6799DA.png

99La seconde hypothèse repose sur l'identification des principes de la notation graphique et la comparaison entre notre notation et la représentation proposée dans BPMN 2.0. Le tableau 6 décrit les différents points clés concernant la deuxième partie de l’étude. Nous avons proposé deux modèles graphiques du scénario traité dans l’exercice précédent. Le premier modèle est construit avec notre propre notation. Le deuxième modèle utilise la notation BPMN 2.0. La confrontation de deux groupes défendant les deux notations, nous a permis d’analyser des avantages et les inconvénients de chacune d’entre elles.

Tableau 6 : Deuxième étude : protocole de la deuxième partie

Image 10000201000001F4000000C7B0F8DE1C.png

100Cette étude nous a aussi servi à valider le choix des concepts importants dans notre proposition, notamment, le choix des termes concernant le rôle, l'acteur et le concept d’interaction. Un autre point intéressant soulevé lors de cette étude est l’importance de bien clarifier les vues structurelle et comportementale. Les résultats de cette étude ont contribué à améliorer à la fois le méta-modèle de chorégraphie et la notation graphique.

5.4.Troisième étude : questionnaire en ligne

101Dans cette étude, nous avons proposé un questionnaire en ligne pour valider certains points concrets de la notation graphique (Cortes-Cornax et al., 2014). Nous avons voulu introduire une approche quantitative permettant d'avoir un retour objectif de nos propositions.

5.4.1.Positionnement de l’étude

102L’objectif de ce questionnaire était de valider des propositions issues de l’étape de conception. Cette étude se situe donc dans l'étape de conception en phase de validation. Un plus grand nombre de sujets est ciblé afin d'obtenir une évaluation quantitative des propositions. La méthode d’évaluation choisie est un questionnaire en ligne6. Ce questionnaire cherche à évaluer des points pour lesquels les sujets n'ont pas besoin d'une connaissance approfondie du domaine de la modélisation des chorégraphies. Il s’adresse d’une part à des futurs utilisateurs du langage, donc à des analystes compétents en modélisation mais n’utilisant pas les langages de modélisation de chorégraphies et d’autre part, à des utilisateurs d’applications et donc des acteurs potentiels des chorégraphies modélisées.

103Le tableau 7 résume le positionnement de cette étude.

Tableau 7 : Positionnement de la troisième étude

Image 10000201000001F400000035477C7A4B.png

5.4.2.Explication de l’étude

104Un effort important a été réalisé pour minimiser le temps de réponse au questionnaire afin de motiver les répondants (environ 15 min). Quarante personnes ont répondu au questionnaire. Les sujets étaient des personnes ayant des compétences différentes dans le domaine de la modélisation des processus métier et des applications logicielles. Nous décrivons brièvement deux questions sur les quatre que nous avons proposées. Notez que pour chaque question, nous avons laissé des questions ouvertes afin que les sujets puissent justifier et commenter leurs réponses.

105Dans la première question, les sujets sont invités à choisir la meilleure représentation d'un scénario simple : "Un participant A envoie plusieurs messages à un participant B." Les sujets peuvent choisir entre l'option BPMN 2.0 (image 2) et d’autres représentations similaires qui ont été proposées. La figure 8 donne les résultats de la question et montre les différentes images proposées aux sujets. Nous observons que la proposition de BPMN 2.0 (image 2) est loin d’être la meilleure selon les sujets. C’est plutôt l’image 4 (qui reprend la notation d’UML) qui remporte le meilleur score. Avec cette question, nous voulions montrer une limite de la notation BPMN 2.0 (manque de transparence sémantique (Moody, 2009)) et comment il était possible d’y remédier.

Figure 8 : Réponses à la question : Which representations do you think capture the best the scenario : « Participant A sends multiple messages to Participant B » ?

Image 10000201000001F4000000B619B6CD21.png

106La deuxième question est similaire à la première. Les sujets devaient choisir la meilleure représentation pour un scénario dont une interaction implique plusieurs participants de type B (rôle pour nous). La figure 9 donne les résultats de la question et montre les différentes images proposées aux sujets. Encore une fois, nous observons les limites de la notation BPMN 2.0. La plupart des sujets (36 sur 40) choisissent la notation que nous proposons. Il parait donc évident, en regardant ces deux premières questions, que l’utilisation de trois traits verticaux pour représenter les multiples messages ou participants est restreinte et non intuitive.

Figure 9 : Réponses à la question : Which graphical construct captures best the fact that an interaction may involve several participants of type B ?

Image 1000020100000168000000F7901D0E84.png

5.6.Synthèse des études

107Tout au long de notre travail, nous avons constaté qu'il est très important de combiner différentes méthodes d'évaluation : des méthodes qualitatives, des méthodes quantitatives et les cadres d'évaluation. Certaines approches peuvent effectivement être plus appropriées pour certaines phases. Par exemple, l'utilisation d'un cadre d'évaluation est plus appropriée pour la phase d'exploration et de validation. Les méthodes qualitatives, notamment les focus-groups s'adaptent mieux à la phase de co-construction. Les méthodes quantitatives sont surtout intéressantes lors d'une phase de validation.

108Les expérimentations nous ont permis de voir que les méthodes étaient davantage en lien avec les étapes du processus d’évaluation centré utilisateur (exploration, co-construction, validation) qu'avec les phases du processus de développement du langage (analyse, conception, opérationnalisation). Par exemple les méthodes mobilisées en co-construction sont les mêmes lors de l’analyse et de la conception du langage.

109Afin de donner des recommandations pour le choix des méthodes, nous résumons dans le tableau 8, pour les trois phases de la démarche d’évaluation centrée utilisateur, les principales méthodes à utiliser et auprès de quels utilisateurs. En gras, nous soulignons les méthodes qui ont été illustrées dans ce papier.

Tableau 8 : Phases de la démarche centrée utilisateur (DCU) et méthodes expérimentales

Image 10000201000001F40000011D9056A2B7.png

110Dans le cadre de la conception de langages spécifiques, la phase de validation est rarement conduite sur une application. Ce sont les différents éléments du langage (dictionnaire des concepts, syntaxe concrète, syntaxe abstraite) qu’il faut valider par des méthodes qualitatives.

111Les éléments du langage étant dépendants, il convient de mener des expérimentations successives depuis la caractérisation jusqu'à l’opérationnalisation. Comme préconisé dans les démarches centrées utilisateur, dès qu’un élément est finalisé par le concepteur, il doit être évalué par les utilisateurs finaux.

112Nous constatons que la mise en place d'une démarche centrée utilisateur est une tâche difficile qui requiert beaucoup d'investissement et de temps. De plus, il est très difficile de couvrir toutes les parties du langage (i.e. concepts, sémantique, notation, etc.). Cependant, l'application d'une ingénierie de langages de modélisation aide le concepteur du langage à bien cadrer les études empiriques et à marquer leurs objectifs.

6.Bilan et perspectives

113Notre proposition s’inscrit dans la perspective de proposer une véritable ingénierie des langages de modélisation ; elle repose sur l’adoption d’étapes d’ingénierie (analyse, conception, opérationnalisation), chacune d’elle se focalisant sur l’élaboration et l’évaluation des composants du langage (carte d’identité, dictionnaire de concepts, syntaxe abstraite, etc.). Nous proposons également d’intégrer un cycle d’évaluation dans chaque étape du processus de développement, évaluation reposant en grande partie sur des expérimentations utilisateurs.

114L’idée que nous défendons ici est qu’il ne faut pas limiter les études empiriques aux activités de validation, mais également explorer et co-construire avec les utilisateurs les différents composants d’un langage.

115L'utilisateur devient donc un point central du processus d'élaboration d'un langage de modélisation. L'étude de l'utilisateur via des expérimentations a besoin de s'alimenter de disciplines comme la sociologie ou la psychologie pour interpréter les observations et les résultats obtenus lors de ces études. Les sciences humaines et sociales (SHS) peuvent donc apporter une connaissance essentielle pour dynamiser et construire des expérimentations plus efficaces ainsi que pour réaliser une analyse détaillée des résultats. Une approche prometteuse pour favoriser l’implication des utilisateurs consiste à s’appuyer sur des techniques ludiques de créativité. De telles approches, qui ont d’ores et déjà fait l’objet de travaux dans le domaine de l’ingénierie des exigences des systèmes d’information (Maiden et al., 2010; Osterwalder, Pigneur, Smith, & Movement, 2010) et la modélisation collaborative des processus métier (Front et al., 2015) pourraient s'étendre à d'autres domaines. Une première série d’expériences nous permet de penser qu’elles pourraient s’appliquer aux phases d’exploration et de co-construction des langages de modélisation.

116La méthode globale (processus de développement et démarche d’évaluation intégrée) proposée dans cet article est spécifique au développement de nouveaux langages de modélisation car elle s’appuie sur l’élaboration des composants constitutifs des langages (syntaxe abstraite, concrète et sémantique). Cependant, nous pensons que cette démarche peut être applicable à d’autres discipline que celle de l’informatique, plus précisément à toute discipline utilisant des modèles dans le but de gérer la complexité des produits, services ou systèmes existants ou innovants.

117Cette démarche peut donc être utilisée dans d'autres domaines afin de créer et formaliser les langages permettant de construire ces modèles. Cette formalisation aidera par exemple à établir des conventions de communication et rendra plus facile la construction d’outils facilitant la manipulation des modèles. Pour concrétiser cet apport, nous devons étudier l’applicabilité de la démarche à d'autres domaines. Nous devons rendre cette démarche suffisamment flexible pour pouvoir incorporer les différentes techniques issues d'autres disciplines. Nous devons également observer sur le terrain les pratiques métiers d'autres disciplines afin d'étudier s’il est possible de les intégrer dans notre démarche. En effet, les propositions présentées dans cet article sont issues de travaux de recherche menés dans le monde académique et centrées informatique. Il serait intéressant de croiser nos propositions avec les techniques d’évaluation utilisées dans l’industrie ainsi que dans d’autres disciplines. Une solution serait d’engager une recherche action dans le cadre d’une thèse où le doctorant participerait à l’élaboration d’un langage industriel spécifique à un domaine.

118Finalement, si la démarche globale proposée est spécifique au développement de nouveaux langages de modélisation, le processus d’évaluation nous semble suffisamment générique pour pouvoir être adapté et intégré dans tout processus d’innovation de produit ou de service pour peu que celui-ci soit suffisamment décrit et formalisé sous la forme d’étapes et de produits intermédiaires.

Bibliographie

AFNOR, Ergonomie de l’informatique. Aspects logiciels, matériels et environnementaux, Recueil Normes Informatique, 2003, 185 p., ISBN 2-12-236211-1

Aranda J., Ernst N., Horkoff J., Easterbrook S. (2007) A framework for empirical evaluation of model comprehensibility. Proceedings of the International Workshop on Modeling in Software Engineering, MISE'07, IEEE Computer Society, Washington, DC, USA.

Baribeau, C., & Germain, M. (2010). L’entretien de groupe : considérations théoriques et méthodologiques. Entretiens de Groupe : Concepts, Usages et Ancrages, 29(1), 28–49.

Barros, A., & Decker, G. (2007). Multi-staged and multi-viewpoint service choreography modelling. Proceedings of the Workshop on Software Engineering Methods for Service Oriented Architecture (SEMSOA), 244.

Barros, A., Dumas, M., & Oaks, P. (2005). A critical overview of the web services choreography description language. BPTrends Newsletter 3, 1–24.

Ceh, I., Crepinsek, M., Kosar, T., & Mernik, M. (2011). Ontology driven development of domain-specific languages. Computer Science and Information Systems, 8(2), 317–342.

Cortes-Cornax, M. (2011). Service choreographies through a graphical notation based on abstraction Layers and viewpoints. In Fifth International Conference on Research Challenges in Information Science (RCIS) (pp. 1–12). Guadeloupe - French West Indies, France

Cortes-Cornax, M., Dupuy-Chessa, S., Rieu, D., & Dumas, M. (2011). Evaluating choreographies in BPMN 2.0 using an extended quality framework. In Business Process Model Notation Workshop. Lucerne, Switzerland.

Cortes-Cornax, M., Dupuy-Chessa, S., Rieu, D., & Mandran, N. (2014). Evaluating the appropriateness of the BPMN 2.0 standard for modeling service choreographies: using an extended quality framework. Software & Systems Modeling.

Cortes-Cornax M., Rieu D., Verdier C., Front A., Forest F., Mercier A., Benoit A-M., Faravelon A. (2015) A Method to Analyze, Diagnose and Propose Innovations for Complex Ecosystems: the InnoServ Project.–AHA 2015 – ER-Workshop on Conceptual Modeling for Ambient Assistance and Health Ageing.

Darses, F., & Falzon, P. (1996). La conception collective : une approche de l’ergonomie cognitive. In G. de Terssac & E. Friedberg (Eds). Coopération et Conception (pp. 1–12).

Decker, G., Kopp, O., Leymann, F., & Weske, M. (2007). BPEL4Chor: Extending BPEL for Modeling Choreographies. In IEEE International Conference on Web Services (ICWS 2007) (pp. 296–303). Salt Lake City, Utah, USA: IEEE Comput. Soc.

Dumas, J., & Fox, J. (2009). Usability Testing : current practices and future directions. In Human-Computer Interaction: Development Process (CRC Press., pp. 231–252).

Dupuy-chessa, S., Combemale, B., Nodenot, T., Pallec, X. Le, Wouters, L., Saclay, C. E. A., & Gif, N. (2014). Vers une approche centrée humain pour la définition de langages de modélisation graphiques, 1–17.

Front A., Rieu D., Santorum M., Movahedian F. (2015), A participative end-user method for multiperspective business process elicitation and improvement, (DOI : 10.1007/s10270-015-0489-6), Software and Systems Modeling, Springer.

International Organization for Standardization. (2001). IEC 9126-1: Software Engineering- Product Quality-Part 1: Quality Model. Geneva, Switzerland.

Kang, K. C., Cohen, S. G., Hess, J. a, Novak, W. E., & Peterson, a S. (1990). Feature- Oriented Domain Analysis (FODA) Feasibility Study. Distribution, 17(November), 161.

Kleppe, A. (2007). A language description is more than a metamodel. In Fourth International Workshop on Software Language Engineering (pp. 1–9). Nashville, USA : megaplanet.org.

Krogstie, J. (2003). Evaluating UML using a generic quality framework. In UML and the Unified Process (pp. 1–22). IGI Global.

Krogstie, J., Sindre, G., & Jørgensen, H. (2006). Process models representing knowledge for action: a revised quality framework. European Journal of Information Systems, 15(1), 91–102.

Maiden, N., Jones, S., Karlsen, K., Neill, R., Zachos, K., & Milne, A. (2010). Requirements engineering as creative problem solving: A research agenda for idea finding. In Proceedings of the 2010 18th IEEE International Requirements Engineering Conference, RE2010 (pp. 57–66).

Mandran, N., Dupuy-Chessa, S., Front, A., & Rieu, D. (2013). Démarche centrée utilisateur pour une ingénierie des langages de modélisation de qualité. Ingénierie des systèmes d’information, 18(3), 65–93.

Mernik, M., Heering, J., & Sloane, A. M. (2005). When and how to develop domain-specific languages. ACM Computing Surveys, 37(4), 316–344.

Mohagheghi, P., & Aagedal, J. (2007). Evaluating Quality in Model-Driven Engineering. In International Workshop on Modeling in Software Engineering (MISE’07: ICSE Workshop 2007) (pp. 6–6).

Moody, D. (2009). The “Physics” of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering. IEEE Transactions on Software Engineering, 35(6), 756–779.

Nysetvold, A. G., & Krogstie, J. (2006). Assessing business process modeling languages using a generic quality framework. Advanced Topics in Database.

OMG. (2011). Business Process Model and Notation v. 2.0 (BPMN 2.0).

Osterwalder, A., Pigneur, Y., Smith, A., & Movement, T. (2010). Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers. Journal of Business (Vol. 5). John Wiley & Sons, Inc.

Paillé, P., & Mucchielli, A. (2012). L’analyse qualitative en sciences humaines et sociales. (A. Colin, Ed.)Collection Sciences humaines et sociales.

Peltz, C. (2003). Web services orchestration and choreography. Computer, 36(10), 46–52. Rossi, M., & Brinkkemper, S. (1996). Complexity metrics for systems development methods and techniques. Information Systems, 21(2), 209–227.

Runeson, P., & Höst, M. (2008). Guidelines for conducting and reporting case study research in software engineering. Empirical Software Engineering, 14(2), 131–164.

Snedecor, G., & Cochran, W. (1957). Snedecor G., Cochran W. (1957), Statistical methods, 6ème édition (Vol. The Iowa S). Iowa, USA: The Iowa State University Press Ames.

Villanueva, M. J., Valverde, F., Pastor, O., Villanueva, M. J., Valverde, F., & Pastor, O. (2013). Involving end-users in the design of a domain-specific language for the genetic domain.

Wahl, T., & Sindre, G. (2005). An analytical evaluation of BPMN using a semiotic quality framework. In CEUR Workshop Proceedings (Vol. 363, pp. 147–158). Citeseer.

Notes

1 EMF = Eclipse Modeling Framework. http://www.eclipse.org/modeling/emf/

2 GMF = Graphical Modeling Framework. http://www.eclipse.org/modeling/gmp/

3 http://www.iso.org/iso/fr/

4 Norme révisée par la norme ISO 9241-210:2010 /

5 TLFI : Trésor de la langue française informatisée. http://atilf.atilf.fr/

6 http://goo.gl/AsvO7

Pour citer cet article

Mario Cortes-Cornax, Sophie Dupuy-Chessa , Nadine Mandran , Dominique Rieu , Agnès Front (2016). "Illustration d’une démarche centrée utilisateur pour l’ingénierie informatique : conception de langage de modélisation". - La revue | Numéro 4 - "Des expérimentations pour l'innovation aux innovations dans l'expérimentation".

[En ligne] Publié en ligne le 02 décembre 2016.

URL : http://innovacs-innovatio.upmf-grenoble.fr/index.php?id=332

Consulté le 20/09/2017.

A propos des auteurs

Mario Cortes-Cornax

Il a obtenu son doctorat informatique de l'Université de Grenoble en 2014. Il a un double diplôme d'ingénieur en informatique de l’« Universidad Politécnica de Madrid » (UPM) et l’ « École nationale supérieure d'informatique et de mathématiques appliquées de Grenoble » (ENSIMAG). Il a été professeur assistant à l'ENSIMAG (2013-2014) et à l’IUT2 (2011 - 2013). Ses intérêts de recherche portent sur la conception de systèmes d'information, la gestion des processus métier et l’ingénierie dirigée par les modèles.

Sophie Dupuy-Chessa

Professeur en informatique à l'Université Grenoble Alpes. Elle a obtenu sa thèse en 2000 dans le domaine du génie logiciel, plus précisément en modélisation logicielle. Ensuite, elle a réalisé deux post-doctorats: elle a été enseignant/chercheur à l'Université de Genève, puis ingénieur de recherche au Xerox Research Centre Europe. Actuellement, ses intérêts de recherche concernent l'ingénierie dirigée par les modèles pour l'interaction homme-machine et la conception de systèmes d'information. Elle a publié dans des conférences et des revues à la fois dans le domaine du génie logiciel, des systèmes d'information et de l’Interaction Homme Machine (IHM).

Nadine Mandran

Ingénieur en sciences humaines et sociales, en particulier dans les méthodes de production et d'analyse des données. Elle est membre du Laboratoire d'Informatique de Grenoble (LIG). Ses intérêts de recherche portent sur l'adaptation des méthodes développées pour les sciences humaines et sociales dans le domaine de l'informatique. Elle travaille principalement sur les aspects de l'ingénierie des systèmes d'information et la méthode d'ingénierie et dans les technologies de l'apprentissage amélioré. Elle est en charge de la mission de la qualité au LIG.

Dominique Rieu

Professeur titulaire à l'Université Grenoble Alpes (UGA). Elle est membre du Laboratoire d'Informatique de Grenoble (LIG), directrice adjointe de l’IUT2, co-directrice de la fédération de recherche INNOVACS (Innovation Connaissance, Société) et a été présidente de l’association INFORSID, l'association française des chercheurs et des industriels en système d'information. Actuellement ses recherches portent sur la modélisation des systèmes d’information par les experts métiers ou les utilisateurs finaux, la gestion des processus métier inter-organisationnels et l’ingénierie des méthodes de développement.

Agnès Front

Maître de conférences-HDR à l'Université Grenoble Alpes. Elle a obtenu un doctorat en informatique en 1997 et une Habilitation à Diriger des Recherches en 2011. Elle est membre du Laboratoire d’Informatique de Grenoble (LIG). Ses principales activités de recherche concernent l’ingénierie de méthodes, plus principalement la proposition de nouvelles techniques basées sur les approches participatives, la créativité et les serious game pour le développement de systèmes d’information ou de projets d’innovation.




Contacts

SFR INNOVACS

Université Grenoble Alpes

1221 avenue centrale - Domaine universitaire

38400 Saint-Martin d'Hères

sabrina.barbosa@univ-grenoble-alpes.fr

http://innovacs.univ-grenoble-alpes.fr/

Abonnez-vous

Recevez en temps réel les dernières mises à jour de notre site en vous abonnant à un ou à plusieurs de nos flux RSS :

Informations légales

ISSN électronique :

Dernière mise à jour : 23 février 2017

Edité avec Lodel.

Administration du site (accès réservé)