© Your Copyright
Ce cours est en construction. En attendant référez vous à l’ancien document de cours (page 93): coursMDD.pdf
Le cycle en “V” est un grand classique du cycle de développement d’un produit. Il va de l’expression du beoin à la livrason d’un produit. Le réalisation d’un cahier des charges est la première étape de ce cycle.
Maître d’ouvrage
Maître d’oeuvre
La réussite d’un projet passe impérativement par la défiition écrite, détaillée, précise, exhaustive et évaluable du besoin et des contraintes. Les phases d’expression et d’analyse du besoin permettent de décrire les fonctionnalités du logiciel et les contraintes sous lesquelles celui-ci doit être réalisé.
Expression du besoin
Les besoins sont exprimés par le maître d’ouvrage dans le cahier des charges et rédigés en langage naturel. L’expression du besoin est souvent associée à la description d’un contexte et de contraintes.
Analyse du besoin
L’analyse du besoin est réalisée par le maitre d’oeuvre en collaboration avec le maître d’ouvrage. Il s’agit d’identifier les fonctionnalites du produit à réaliser, sa faisabilité et sont co^ut. Pour être réellement utilisable, l’analyse doit également fournir des critères de validation et de qualité.
Le besoin est à diférencier de la fonction d’un produit. La fonction doit répondre à un besoin.
Besoin
Fonctions
Le point de vue utilisateur: Il ne faut surtout pas décrire COMMENT le logiciel remplira ses fonctions.
En IPI, le cahier des charges comportera l’expression et l’analyse du besoin. Dans une relation client / prestataire, le cahier des charges est un document contractuel. C’est en s’appuyant sur le cahier des charges qu’on pourra déterminer si les objectifs ont étés remplis.
Il faut s’adapter au sujet traité.
Le cahier des charges constitue les fondations du projet. Tout repose sur ce document! Vous devrez vous mettre dans la peau d’un client qui précise de manière univoque, cohérente et exhaustive ce qu’il attend comme produit.
Par exemple, vous pouvez imaginer qu’un autre binôme utilise votre cahier des charges pour produire le jeu auquel vous pensez. Dans ce cas, ce qui n’est pas décrit dans le cahier des charges ne sera probablement pas réalisé. Ce qui sera équivoque sera toujours interprété de la manière qui provoque le moins de développement.
Le Cahier des charges vous engage. Il permet d’évaluer la quantité de travail à réaliser. Veillez donc à être exhaustif : Si la description détaillée de votre projet vous paraît déjà insurmontable, imaginez le codage! C’est en allant au bout de cette description qu’on est capable de détecter un projet trop ambitieux. Si vous avez des doutes, afin de limiter le risque de ne pas achever le projet, certaines fonctionnalités peuvent être optionnelles. Les objectifs du projet pourront alors être considérés comme atteint même si ces dernières n’ont pas étés réalisées.
Page de garde
Mettre un titre, le logo de l’ENIB et une illustration. Utiliser un cartouche normalisé pour tous les documents du projet : type du document, nom du projet, commentaire, auteur, version, date.
Description générale: 1 à 2 phrases maximum disant ce qu’est le document et le projet. Contexte : précise le but et le contexte du projet. Cela apporte un éclairage qui permet de mieux comprendre le besoin qui sera exprime
Règles du jeu: Règles complètes, précises et exhaustives
L’interface utilisateur: Proposition de vues et description des moyens d’action.
Manuel utilisateur: Première version du manuel
Contraintes techniques: Au moins celles énoncées pour IPI
Fonctionnalite: c’est le plus important! Critere de validite et de qualite: essentiel dans la relation client/prestataire
Livrables Echeancier: Calendrier indiquant quand seront livres les livrables. Documents: Breve description de chaque documents. Prototypes: Description des prototypes et des fonctionnalites qu’ils devront posseder