Fichier de rejeu Close

Indication Close

A propos de... Close

Commentaire Close

Téléchargements

Aide

Expression et analyse du besoin

Objectif :

  • Imaginer un jeu adéquat pour le projet de IPI
  • Etre capable de rédiger le cahier des charges de votre projet
  • Savoir exprimer et analyser le besoin

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.

Concepts

Les acteurs du projet

Définition :

Maître d’ouvrage

  • Définition : client qui demande la réalisation
  • Synonyme : client, product owner

Définition :

Maître d’oeuvre

  • Definition : fournisseur qui réalise le projet
  • Synonyme: Développeur, fournisseur, prestataire, concepteur

Le besoin

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é.

Définition :

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.

Définition :

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é.

Différence entre le besoin et la fonction

Le besoin est à diférencier de la fonction d’un produit. La fonction doit répondre à un besoin.

Définition :

Besoin

  • Définiton : Situation de manque ou prise de conscience d’un manque.
  • Format : langage naturel, dessin, schéma...

Définition :

Fonctions

  • Définition : Eléments de rendu de service de l’application qui permettent de répondre au besoin exprimé.
  • Synonyme : fonctionnalités
  • Format : phrases à l’infinitif, sujet=système, compléments=acteurs en interaction avec le système.

Le point de vue utilisateur: Il ne faut surtout pas décrire COMMENT le logiciel remplira ses fonctions.

Exemple :

  • Crayon - Fonction : deposer de l’encre sur un papier - Besoin : communiquer
  • Tondeuse - Besoin : entretenir le jardin - Fonction : diminuer la hauteur de l’herbe
  • Projet de IPI - Besoin : Vous avez le concept d’un nouveau jeu et vous voulez permettre au prof et à vos amis d’y jouer. - Fonction : permettre à l’utilisateur de jouer à ce jeu.

Cahier de charges

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.

Normes:
  • Cahier des Charges Fonctionnel : AFNOR
  • Use Cases : UML
  • Récits d’utilisation : méthodes agiles
  • ...

Il faut s’adapter au sujet traité.

Le cahier des charges de IPI

Exemple :

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.

Plan imposé en 4 parties:

  • Objectifs
  • Expression du besoin
  • Analyse du besoin
  • Livrables

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.

Objectifs

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

Expression du besoin

  • 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

  • Scenario d’utilisation:
    • schéma (non formalisé); éventuellement plusieurs.
    • enchaînement d’actions.
    • phrases à l’infinitif, le sujet est l’utilisateur (sauf exception explicitée)

Analyse du besoin

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