Tâche: Développer une vision
Cette tâche explique comment développer la vision globale du système, y compris les incidents à résoudre, les parties prenantes clé, la portée/les limites du système, ses principales caractéristiques et les contraintes éventuelles.
Objet

L'objectif de cette tâche est de :

  • Obtenir un consensus sur le problème à résoudre.
  • Identifier les parties prenantes du système.
  • Définir les limites du système.
  • Décrire les principales caractéristiques du système.
Relations
RôlesPrincipal: Complémentaire: Auxiliaire:
EntréesObligatoire: Facultatif: Externe:
  • Aucun
Sorties
Description principale

Lorsque vous développez la Vision, gardez à l'esprit que :

Etapes
Obtenir un consensus sur le problème à résoudre

Une façon simple d'obtenir un consensus sur la définition du problème consiste à le mettre par écrit pour voir si tout le monde est d'accord.

Demandez au groupe : Quel est le problème ?

  • Très souvent, on s'attelle immédiatement à la recherche d'une solution, sans avoir d'abord pris le temps de bien comprendre le problème. Mettez le problème par écrit et voyez si tout le monde est d'accord avec votre définition.

Ensuite, redemandez au groupe : Quel est le problème réel ?

  • Recherchez les causes, ou le problème à l'origine du problème. Le vrai problème se cache souvent derrière un problème de façade.

N'acceptez pas la première formulation du problème. Continuez à demander "pourquoi ?". Examinez la nature du problème.

Parfois, le groupe est tellement convaincu de la solution à mettre en place qu'il est difficile de mettre en évidence le problème sous-jacent. Dans ce cas, il peut être intéressant de répertorier les avantages de la solution envisagée, puis de chercher à identifier les problèmes résolus par ces avantages. Vous pourrez alors déterminer si ces problèmes sont de réels problèmes auxquels l'organisation est confrontée. Parmi les techniques couramment utilisées pour identifier le problème derrière le problème, nous citerons le brainstorming, les diagrammes causes-effets et les diagrammes de Pareto.

Identifier les parties prenantes

Selon le niveau de compétence de l'équipe de développement, l'identification des parties prenantes peut être une étape simple ou complexe. Souvent, il suffit d'interroger les décisionnaires, les utilisateurs potentiels et autres parties concernées. Les questions suivantes vous seront utiles :

  • Qui sont les utilisateurs du système ?
  • Qui est l'acheteur du système ?
  • Qui d'autre sera affecté par les résultats obtenus via le système ?
  • Qui sera chargé d'évaluer et de valider le système lorsqu'il sera livré et déployé ?
  • Existe-t-il d'autres utilisateurs internes et externes dont les besoins doivent être pris en compte ?
  • Qui va gérer le nouveau système ?
  • Avons-nous oublié quelqu'un ?
  • OK, avons-nous oublié quelqu'un d'autre ?

Commencez à définir les profils des utilisateurs potentiels (ou réels) du système.  Les premières informations sur les principaux utilisateurs et leur environnement doivent être incluses dans le document Vision.

Définir les limites du système

Les limites du système définissent la frontière entre la solution et le monde réel autour de cette solution. En d'autres termes, les limites du système définissent une enveloppe dans laquelle se trouve la solution. Sous forme d'entrées et de sorties, des informations sont échangées entre le système et les utilisateurs qui se trouvent en dehors du système. Toutes les interactions avec le système ont lieu via des interfaces entre le système et le monde extérieur.

Souvent, les limites du système sont évidentes. Par exemple, les limites d'un gestionnaire de contacts shrink-wrap mono-utilisateur qui s'exécute sous Microsoft Windows sont relativement claires. Il n'y a qu'un seul utilisateur et une seule plate-forme. Les interfaces entre l'utilisateur et l'application se résument aux boîtes de dialogue via lesquelles l'utilisateur peut entrer des informations dans le système, et aux rapports de sortie et chemins de communication utilisés par le système pour documenter et transmettre ses réponses.

Identifier les contraintes à imposer au système

Il existe un certain nombre de contraintes à prendre en compte. Vous trouverez ci-dessous une liste des sources de contraintes potentielles et des questions à poser :

  • Politique : Existe-t-il des problèmes politiques internes ou externes susceptibles d'affecter les solutions potentielles ? Entre départements ?
  • Economie : Quelles sont les contraintes financières ou budgétaires applicables ? Existe-t-il des considérations relatives au coût des marchandises vendues ou à la tarification des produits ? Certains problèmes de licence doivent-ils être pris en compte ?
  • Environnement : Existe-t-il des contraintes environnementales ou réglementaires ? Légales ? D'autres standards qui nous limitent ?
  • Technique : Sommes-nous limités dans nos choix technologiques ? Sommes-nous contraints de travailler avec les plates-formes et technologies existantes ? Existe-t-il des technologies nouvelles qu'il nous est impossible d'envisager ?
  • Faisabilité : Le planning est-il défini ? Sommes-nous limités aux ressources existantes ? Pouvons-nous utiliser de la main d'oeuvre extérieure ? Pouvons-nous accroître les ressources ? Temporairement ? De façon définitive ?
  • Système : La solution doit-elle être mise en oeuvre sur nos systèmes existants ? Devons-nous assurer la compatibilité avec les solutions existantes ? Quels sont les systèmes d'exploitation et environnements à prendre en charge ?
Formuler le problème

Avec l'ensemble du groupe, travaillez sur un chevalet et décrivez chaque problème identifié à l'aide du canevas suivant :

Le problème de <décrire le problème>
affecte <parties prenantes affectées par le problème>.
Les conséquences de ce problème sont : <répercussions du problème>.
Une solution adaptée permettrait de <répertorier les principales caractéristiques d'une solution adaptée>.

Ce canevas a pour but de vous aider à distinguer les solutions/réponses des problèmes/questions.

Exemple :

Le problème de : résolution insatisfaisante et tardive des problèmes de service après-vente
affecte : nos clients, notre personnel du service après-vente et nos techniciens de maintenance.
Les conséquences de ce problème sont : clients mécontents, niveau de qualité insuffisant, employés insatisfaits et perte de chiffre d'affaires.
Une solution adaptée permettrait de :
fournir un accès en temps réel à une base de données de dépannage pour le personnel de support et de faciliter l'affectation immédiate de techniciens de maintenance sur les sites nécessitant réellement leur intervention.

Définir les caractéristiques du système

A partir de la liste d'avantages établie, définissez une liste des caractéristiques souhaitées pour le système. Décrivez-les brièvement et affectez-leur des attributs afin de définir leur état général et leur niveau de priorité au sein du projet.

Evaluer vos résultats

Vous devez évaluer votre vision à ce stade afin de vous assurer que votre travail semble correct, mais il est inutile de faire un contrôle détaillé. Consultez la liste de contrôle du document Vision (Liste de contrôle : Vision).



Propriétés
Plusieurs occurrences
Commandé par les événements
En cours
Facultatif
Planifié
Réitérable
Plus d'informations