Gestion et conduite de projets : le document « Vision Document »
Le V de vision
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.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.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.
- Tracer la prise en charge des exigences dans le projet
- 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.
Des questions?