Vous êtes sur la page 1sur 26

IN S T I TUT SUPERIEUR INFORMATIQUE

ISI Cours Ateliers de Gnie Logiciel -AGL-

Cahier des Charges


(2)

Anne Universitaire 2010/2011

Dfinition
Le Cahier des Charges (CDC) d'un projet est un document par lequel on exprime son besoin pour le projet.

Ce besoin doit tre formul en termes de fonctions que le futur utilisateur aura accomplir, ou que le systme devra accomplir pour lui.

Dfinition (2)

Le CDC permet en outre : de provoquer chez le concepteur /ralisateur (prestataire) la conception et la ralisation du produit le plus efficient, de faciliter le dpouillement des propositions des prestataires, de favoriser le dialogue entre les partenaires.
3

Dfinition AFNOR

Document par lequel le demandeur exprime son besoin (ou celui qu'il est charg de traduire) en terme de fonctions de services et de contraintes. Pour chacune d'elles sont dfinis des critres d'apprciation et leurs niveaux. Chacun de ces niveaux doit tre assorti d'une flexibilit.

Produire un CDC : Mthodologie


Le CDC doit tre rdig indpendamment des concepts de solutions envisageables afin de laisser le plus grand ventail de concepts de solutions possibles.

Le CDC doit permettre au maximum l'expression du besoin dans les termes des diffrents utilisateurs selon les phases de l'tat vivant du produit.

Le cahier des charges relate les besoins exactes des utilisateurs. Pour ce faire, des entretiens sont mens et un groupe de

Produire un CDC : Mthodologie


Le Cahier des Charges Fonctionnel est la conclusion des travaux d'analyse de la valeur et d'analyse fonctionnelle qui symbolisent la dmarche d'expression du besoin : Orienter l'tude : Du gnral au spcifique. Le

premier point de la dmarche va donc consister regarder le projet d'un il extrieur, prendre du recul, se poser les bonnes questions :
Rechercher l'information Traduire le besoin en fonctions Formaliser les travaux Contrler le CDC Besoin Valider le CDC Besoin
6

Rechercher linformation
La recherche de l'information doit tre canalise et formalise. C'est un processus constant tout au long du projet qui doit tre men rigoureusement ds le dbut du projet afin d'apprhender plus prcisment les caractristiques essentielles du besoin. Un excellent moyen de chercher l'information la plus pertinente et de la vrifier en

Traduire le besoin en fonctions


Le passage du besoin en fonction s'effectue au travers de l'analyse fonctionnelle qui recense, caractrise, ordonne, hirarchise et valorise les fonctions.

Formaliser les travaux

Cette formalisation consiste dvelopper le Cahier des Charges. Il reprendra les conclusions de l'analyse fonctionnelle.

Contrler le CDC besoin


Le contrle du document est trs important. En effet, on remarque que cette tape n'est gnralement pas effectue de faon optimale alors qu'elle est un frein aux dysfonctionnements qui peuvent apparatre beaucoup plus tard dans le projet.

10

Valider le CDC besoin


Il s'agit de s'assurer que le passage du besoin exprim au besoin fonctionnel est conforme aux objectifs viss. C'est un travail qui peut s'avrer fastidieux et risqu si le volume d'information est important. L'objectif est donc ici de rendre efficace la validation en rduisant son domaine d'action et tout en conservant sa reprsentativit.

11

Exemple de CDC selon IEEE std 830


I- Introduction II- Contexte de la ralisation

III- Description gnrale

1. Objectifs 2. Hypothses 3. Bases mthodologiques 1. Environnement du projet 2. Fonctions gnrales du systme 3. Caractristiques des utilisateurs 4. Configuration du systme 5. Contraintes gnrales du dveloppement, dexploitation et de maintenance
Contraintes de dveloppement Contraintes dexploitation Maintenance et volution du systme

6.

12

Exemple de CDC selon IEEE std 830

IV- Description des interfaces externes du logiciel


1.Interface matriel / logiciel 2.Interface homme / machine 3.Interface logiciel / logiciel 1.Dfinition des objets

V- Description des objets

VI- Description des fonctions

Identification de lobjet i Contraintes sur lobjet i

1.Dfinitions des fonctions


Identification de la fonction i Description de la fonction i Contraintes oprationnelles sur la fonction i

13

Exemple de CDC selon IEEE std 830


2.Conditions particulires de fonctionnement

VII- Justification des choix effectus VIII- Glossaires IX- Rfrences

2.1. 2.2. 2.3. 2.4. 2.5. 2.6. 2.7. 2.8.

Performances Capacits Modes de fonctionnement Contrlabilit Sret Intgrit Conformit aux standards Facteurs de qualit

1.Annexes 2.Index

14

Exemple simple:
dune bibliothque

Gestion

Fonctionnalits

Il s'agit d'un outil d'aide la gestion de bibliothque. Une bibliothque prte des livres et des magazines des emprunteurs. Les livres et les magazines sont rpertoris dans le systme. Les emprunteurs sont rpertoris dans le systme. Une bibliothque s'occupe de l'achat de nouveaux titres. Les titres populaires sont achets en plusieurs exemplaires. Les vieux livres ou magazines sont retirs lorsqu'ils sont trop anciens. Les vieux livres ou magazines sont retirs lorsqu'ils sont en mauvais tat. Le bibliothcaire est un employ de la bibliothque.
15

Exemplesimple : Gestion d une Exemple simple: Gestion


bibliothque dune bibliothque

Fonctionnalits
Le bibliothcaire communique avec les emprunteurs. L'outil assiste le bibliothcaire dans sa tche. Un emprunteur peut rserver un livre ou un magazine qui n'est pas disponible (dj prt ou non encore rpertori). Lorsqu'un livre ou un magazine devient disponible (rendu ou achet), l'emprunteur qui l'a rserv est averti. La rservation est annule lorsque le livre ou le magazine est prt. Une rservation peut tre annule tout moment. Les cration, mise jour et destruction 16

Exemple simple: E x e m p le sim p le :


dune bibliothque d u n e b ib lio th q u e

Gestion G e stio n

Contraintes non fonctionnelles


L'application doit tourner dans tout environnement Unix ou Windows. L'application doit avoir une IHM agrable. L'application doit pouvoir tre tendue d'autres fonctionnalits.

Limitations
L'application ne gre pas l'envoi du message d'avertissement aux emprunteurs lorsque le livre ou le magazine qu'ils ont rserv devient disponible. L'application ne gre pas les retards la restitution.
17

Exercice : Gestion de projets


Une socit de dveloppement logiciel dcide dimplmenter son propre outil de gestion de projet. Elle a dgag les entits suivantes: Un projet est caractris par son identifiant, son nom, une description, une date de dbut, une date de fin. Un projet passe par plusieurs phases. Chaque phase est caractrise dun identifiant, un nom, une description, une date de dbut, une date de fin et ralise par une quipe de personnes dont lun est responsable (il existe un seul responsable pour une phase). Une phase doit gnrer un rapport. Chaque document est caractris par son identifiant, son nom, une description, sa date de validation, son tat (valide, non valide, en attente). Une personne est caractrise par son identifiant, son nom, son prnom, son ge. A un instant il participe une seule phase.

18

Exercice : Gestion de projets (2)


Donner la description textuelle de ce logiciel en se basant sur le modle suivant :

19

Exercice : Gestion de projets (3)

20

Exercice : Gestion de projets (Correction)

1- Fiche descriptive a.Rsum


Titre: Logiciel de gestion de projet But: Automatisation de la gestion de projet Rsum: Le logiciel va permettre une gestion complte, efficace et rapide dun projet Date: 15-02-2010 Version: 1.0 Responsable: le chef de projet Mr X Acteurs: 1 ingnieur conception, 3 ingnieurs dveloppement, 2 ingnieurs intgration et 2 ingnieurs validation 21

Exercice : Gestion de projets (Correction)


b. Pr conditions Il faut avoir 10 machines en bon tat avec un OS linux et tout les logiciels de conception, dveloppement, intgration et validation Une phase ne doit avoir quun seul responsable. Un acteur ne peut intervenir qua une seule phase la fois. c. Enchanement

Evnement de dclenchement: larrive dun nouveau projet Squences nominales: le logiciel doit grer toutes les phases dun cycle de vie dun logiciel: conception, dveloppement, intgration, tests et validation, documentation et la maintenance Squences exceptionnelles: Si un projet ne ncessite pas une des phases ou le client 22

Exercice : Gestion de projets (Correction)

d. e.

Chaque phase doit gnrer un document

Post conditions

Ce logiciel doit avoir une interface facile grer f. Contraintes non fonctionnelles: ce logiciel doit tre portable, fiable .

Besoin dIHM

23

Synthse

24

Synthse (2)

25

Merci pour votre attention