Symphony augmentée pour la conception des systèmes de réalité mixte

Auteur(s)

Caractéristiques

La méthode Symphony augmentée possède les caractéristiques suivantes :

• la méthode est dirigée par les processus métier, c'est-à-dire que ce sont les processus métier qui définissent le découpage fonctionnel de l'application,
• la méthode est centrée sur l'utilisateur, c'est-à-dire que l'on cherche à adapter le système aux pratiques des utilisateurs (à l'inverse des approches dirigées par les fonctions, qui privilégient le regroupement logique de fonctionnalités),
• La méthode est itérative et incrémentale, c'est-à-dire que le système est construit progressivement, bloc par bloc (ou, plus précisément, processus métier par processus métier). Il est également possible de reprendre les activités de développement du système, par exemple afin de raffiner certains aspects, voire de refléter dans le système de nouvelles compréhensions des problématiques du métier.

D'autre part, la méthode Symphony est soumise à deux types de cycle de développement:

• Le macro-cycle, correspondant au temps nécessaire pour développer et implémenter l'ensemble d'un processus métier
• Le micro-cycle, correspondant au temps nécessaire pour développer et implémenter un sous-ensemble de fonctions d'un processus métier.

Le temps affecté à chaque type de cycle sera fonction d'une part des risques associés au développement du projet, d'autre part des ressources humaines affectées au développement. Les principes suivants doivent être suivis, afin de garantir un déroulement optimal du projet :

1. Un macro-cycle contient un certain nombre de micro-cycles. Le dernier micro-cycle d'un macro-cycle déclenche l'intégration des différents éléments logiciels développés. Il est donc nécessaire de prévoir un temps d'intégration à la fin du macro-cycle,
2. Le nombre de micro-cycles doit être déterminé avant le lancement d'un macro-cycle de développement. En revanche, il est préférable de ne pas modifier la durée des micro-cycles durant le projet.

La fin de chaque cycle est marquée par une présentation devant l'ensemble de l'équipe (ou d'un sous-ensemble de l'équipe) des éléments logiciels (fonctionnels). L'organisation pourra être conviée à cette présentation, selon que le bloc fonctionnel présenté implémente un processus métier (délivrable externe) ou un processus métier composant (délivrable interne).

Les réunions de présentation sont également l'occasion de mettre à plat, pour l'ensemble de l'équipe de développement, les problèmes rencontrés lors du développement, pour chaque sous-ensemble développé. Des mesures doivent être prises pour traiter les problèmes en cours avant d'envisager les prochains sous-ensembles à développer. Toutefois, l'aphorisme "le mieux est l'ennemi du bien" doit prévaloir au cours de ces réunions. Celles-ci ne doivent pas durer plus de deux heures : les points traités doivent être généraux et/ou liés aux autres groupes de développement ; il n'est donc pas nécessaire de traiter les problèmes particuliers de développement lors des réunions de présentation.

Il est à noter qu'en fonction de la taille de l'équipe de développement, plusieurs micro-cycles peuvent être entrepris en parallèle, voire plusieurs macro-cycles. Dans ce dernier cas, il reste préférable de synchroniser les fins de cycles afin d'aménager des temps d'intégration.

Patron racine

Liste des patrons

• Phase d'étude préalable
• Phase de spécification conceptuelle des besoins
• Identifier le type d'interaction
• Phase de spécification organisationnelle et interactionnelle des besoins
• Spécification externe de l'interaction
• Découpage fonctionnel du métier
• Description conceptuelle du processus métier
• Identifier les acteurs des processus métier
• Décomposition du processus métier
• Identifier les processus métier composant
• Description de la cartographie des Objets Métier
• Description de la cartographie des Objets Interactionnels
• Connexion des espaces métier et interactionnel
• Décomposition organisationnelle des PMC
• Élaboration des scenarii projetés abstraits de l'interaction
• Description des modèles de tâches
• Organisation des processus métier composant
• Élaboration des scenarii projetés concrets de l'interaction
• Choix des classes de support pour l’interaction

Participants

• Spécialiste GL:
  

  Le spécialiste GL possède des compétences en conception de systèmes logiciels. Ces compétences couvrent l'ensemble des domaines techniques liés à la conception et à l'implémentation d'applications (hors compétences IHM), telles que :

  • la conception de bases de données,
  • la description de l'architecture système,
  • la conception de l'architecture réseau d'un système distribué,
  • etc.
• Spécialiste IHM:
  

  Le spécialiste IHM est un informaticien spécialisé dans la conception d'interfaces homme-machine, du point de vue logiciel. Il possède des notions en ergonomie logicielle (utilisabilité).

• Ergonome:
  

  L'ergonome dispose de compétences en psychologie sociale, anthropologie ou sociologie. Il ne fait pas appel à des connaissances "fondamentales" en informatique, mais axe sa pratique sur l'évaluation et le conseil en interaction homme-machine.

• Expert métier:
  

  L'expert métier est un référent de l'équipe de développement pour tout ce qui concerne le métier à informatiser. À ce titre, il peut appartenir à l'organisation qui commande le logiciel, bien que son rôle ne soit pas celui de "client" (qu'il est préférable de distinguer).