Gestion et conduite de projets : le document « Vision Document »

 

Le V de vision

 

 

le v du document vision doc

le-v-du-document-vision-doc.JPG

 

Quoi mettre dans le vision Doc ?

Le futur système d’information ne sera efficace que s’il répond aux besoins de ses utilisateurs/clients . Il est donc nécessaire, tout en amont du projet, de partager une vision commune entre les parties prenantes de la solution à développer.

Pour cela on consigne dans le Vision Document, succinctement et à un niveau macroscopique, les principaux besoins, fonctionnalités voulues et contraintes du commanditaire.

Ce travail donne une vue d’ensemble de la solution et délimite le périmètre du projet. Il permet de communiquer et de rassembler l’équipe sur le « quoi » et le « pourquoi » du projet et fixe le cadre des décisions ultérieures en matière de besoin.

Le Vision document procurera un contexte pour une étude en profondeur ultérieure.

Dans une approche UP, il précède et prépare d’autres livrables (spécifications détaillées)

Vision doc : UC Model, Glosary, UC detail, Supporting requirements

 

document vision doc

document-vision-doc.JPG

 

Synthèse du Vision Doc

 

Le Vision Document rassemble les informations suivantes:

 

Objet, Objectifs et Enjeux du projet

 

Processus ou fonction couvert par le projet, Objectifs visés (accroître les ventes, réduire les coûts, …) et gains attendus (quantifiés).

 

Décideurs et Utilisateurs

 

Description succincte des différents profils d’utilisateurs du System under design (S.u.d.) et des décideurs du projet (financeur, responsable du dpt impacté,…)

 

Liens entre applications

Informations échangées entre le S.u.d. et les applications avec lesquelles il sera interfacé.

 

Liens entre applications

 

Liens-entre-applications.JPG

 

Une question? Posez-la ici

 

Fonctionnalités du produit

 

Fonctionnalités de haut niveau, nécessaires pour assurer la satisfaction des décideurs/utilisateurs, décrites très succinctement. Dans un contexte UP cette liste débouchera sur le UC model.

 

Exigences supplémentaires et Contraintes

 

Différents types de contraintes:

Économiques (budget),

Délai et ressources,

Techniques (compatibilité avec des systèmes existants, choix d’OS, de langages,..)

Fiabilité, performance

Critères d’évaluation

 

Pour que les solutions envisagées puissent être comparées objectivement, il faut annoncer à l’avance les critères sur lesquels elles seront jugées (coûts, évolutivité, ergonomie, …)

Positionnement

 

Objet du projet

 

Indiquer le processus ou la fonction couvert par le projet.

Indiquer comment l’application cible s’insère dans ce processus.

Préciser la nature du besoin (Nouvelle procédure, Nouveau système, Modification d’un système existant).

 

Objectifs et enjeux

Exprimer l'objectif principal et les objectifs complémentaires éventuels :

Accroître les ventes

Accroître les marges

Améliorer la qualité

Améliorer la réactivité

Réduire les frais généraux

...

Evaluer les gains attendus à court terme (1 an) et à moyen terme.

Positionnement

Présenter de façon ultra synthétique (« elevator statement ») :

le problème résolu par le projet

 

le positionnement commercial du produit

 

Décideurs et utilisateurs

 

Utilisateurs

 

Description succincte des différents profils d’utilisateurs : département ou groupe représenté,

rôle, utilisation du système, …

 

Décideurs

 

acheteurs du système

responsables du département impacté

financeurs du projet

évaluateurs du produit

(+ les utilisateurs eux-mêmes)

Description succincte : responsabilités sur le projet (ex : s’assurer qu’il y a un marché pour le

produit, approuver le financement, monitorer l’avancement, …), mode d’implication dans le

projet, critères de succès.

 

Besoins fondamentaux des Décideurs/Utilisateurs

 

Présenter ici le point de vue exprimé par les décideurs/utilisateurs quant à leurs besoins et aux solutions qu’ils envisagent.

 

Environnement des Utilisateurs

Pour chaque profil :

nombre de personnes concernées / nombre d’accès simultanés

contraintes de navigation entre fonctions/applications

accès par Web ou en client-serveur

langue

localisation géographique

 

Liens entre applications

 

              

Liens avec les applications qui seront interfacées avec le système à développer. On présentera sous forme de messages les informations échangées.

On peut utiliser un diagramme de collaboration UML dans lequel chaque application est un objet appartenant à la classe « application »

 

Fonctionnalités du produit

              

Fonctionnalités de haut niveau, nécessaires pour assurer la satisfaction des décideurs/utilisateurs, décrites très succinctement.

Dans un contexte UP cette liste débouchera sur le UC model.

 

Une question? Posez-la ici

 

 

Exigences supplémentaires et contraintes

              

Ces informations sont décrites ici à haut niveau.

Dans un contexte UP la plupart seront détaillées dans le livrable « Supporting

Requirements »

 

Exigences « FURPS »

Par exemple, besoin d’IHM. Contraintes niveau performances, etc. Exemple : mon application devra être disponible 24h sur 24.

Contraintes « + »

Exigences de documentation

 

Autres Contraintes

(non détaillées dans le document « supporting requirements »)

 

Economiques

Enveloppe budgétaire disponible pour le projet en investissement et fonctionnement

En fonction du gain attendu évaluer le prix de revient maximum acceptable.

Estimer le temps de retour sur investissement souhaité

Délai/Ressources

Préciser et justifier les contraintes de délai du projet

Les ressources sont-elles restreintes, peut on recruter, faire appel à des prestataires, modifier les ressources en cours de projet, … ?

Politiques : des problèmes politiques peuvent-ils affecter le projet ?

Légales

Systèmes : doit-on maintenir la compatibilité avec des systèmes existants ? Quels OS, hardware et environnements doivent être supportés ?

 

Une question? Posez-la ici

 

Référentiel d’exigences

               Tout ces exigences et contraintes pourront être suivies : nécessité de les prioriser, tracer, et de suivre leur réalisation effective.

               On établira pour ça un référentiel des exigences.

  1. Tracer la prise en charge des exigences dans le projet
  2. Ex : tel composant est le fruit de tel UC, lui même issu de tel besoin, le tout testé dans tel cas de test ==> on trace la vie d’une exigence aussi bien en amont qu’en aval de sa spécification

               Pour prioriser les exigences on peut définir pour chacune le bénéfice associé, la stabilité de

               l’exigence, l’effort nécessaire, le risque de ne pas l’implémenter, etc…

 

Une question? Posez-la ici

 

Critères d’évaluation

              

               Pour que les solutions envisagées puissent être comparées objectivement, il faut annoncer à l’avance les critères sur lesquels elles seront jugées :

Coût et gains (amortissement)

Délai d’obtention

Impact sur l’activité

Evolutivité

Facilité d’accès

Ergonomie

Facilité de maintenance

...

Le Vision document : exigeant et précis, mais pas restrictif

 

Il ne faut pas préjuger de ce que sera la future solution et donc ne pas orienter le vision document vers une solution en particulier (spécification trop restrictive).

A l’inverse il faut être suffisament exigeant pour ne pas laisser la porte ouverte à toutes les solutions.

 

 

 Une question? Posez-la ici

 

Des questions?