Ateliers et Outils de Génie Logiciel

Chapitre 1 Introduction

Safa Ben Salem

sb.salem@yahoo.fr
 Logiciel : définitions
Ensemble d'entités nécessaires au fonctionnement d'un processus de
traitement automatique de l'information
●
Programmes, données, documentation...

Ensemble de programmes qui permet à un système informatique

d’assurer une tâche ou une fonction en particulier

Logiciel = programme + utilisation

S.BenSalem - Génie logiciel 2

 Logiciel : caractéristiques
Environnement
●
utilisateurs : grand public (traitement de texte),
spécialistes (calcul scientifique, finances),
développeurs (compilateur)
●
autres logiciels : librairie, composant
●
matériel : capteurs (système d'alarme),
réseau physique (protocole),
machine ou composant matériel contrôlé (ABS)

Spécification : ce que doit faire le logiciel, ensemble de critères que

doivent satisfaire son fonctionnement interne et ses interactions avec
son environnement

S.BenSalem - Génie logiciel 3

 Spécification
Spécification fonctionnelle
●
Fonctionnalités du logiciel, réponse besoins des utilisateurs
aux
Spécification non fonctionnelle
●
Facilité d'utilisation : prise en main et robustesse
●
Performance : temps de réponse, débit, fluidité...
●
Fiabilité : tolérance aux pannes
●
Sécurité : intégrité des données et protection des
● accès
Maintenabilité : facilité à corriger et à faire évoluer le logiciel
●
Portabilité : adaptabilité à d'autres environnements matériels ou
logiciels

S.BenSalem - Génie logiciel 4

 Crise du logiciel
Constat du développement logiciel fin années 60 :
●
délais de livraison non respectés
●
budgets non respectés
●
ne répond pas aux besoins de l'utilisateur ou du client
●
difficile à utiliser, maintenir, et faire évoluer

S.BenSalem - Génie logiciel 5

 Étude du DoD 1995
Étude du Department of Defense des États-Unis sur les logiciels
produits dans le cadre de 9 gros projets militaires

3% 2%

19% 29%

 Utilisés directement
 Utilisés après quelques modifications
 Utilisés après de fortes modifications
 Jamais utilisés
 Payés et pas livrés

47% Jarzombek, Stanley J., The 5th annual JAWS S3 proceedings,

1999

S.BenSalem - Génie logiciel 6

 Étude du Standish group
Enquête sur des milliers de projets, de toutes tailles et de tous secteurs
100%

80%

60%

40%

20%

0%

1994 1996 1998 2000 2002 2004 2008 2010 2012

2006
Standish group, Chaos Manifesto 2013 - Think Big, Act Small, 2013
 Projets réussis : achevés dans les délais et pour le budget impartis, avec
toutes les fonctionnalités demandées
 Projets mitigés : achevés et opérationnels, mais livrés hors délais, hors
budget ou sans toutes les fonctionnalités demandées
 Projets ratés : abandonnés avant la fin ou livrés mais jamais utilisés

S.BenSalem - Génie logiciel 7

 Petits vs grands projets

4% 10%
20%

38%  Projets réussis

 Projets mitigés
 Projets ratés

52%
76%

Petits projets Grands projets

budget ≤ $1 budget ≥ $10 millions
million
Standish group, Chaos Manifesto 2013 - Think Big, Act Small,
2013

S.BenSalem - Génie logiciel 8

 Utilisation des fonctionnalités implantées
Toujours, 7%

Souvent, 13%

Jamais, 45%

Parfois, 16%

Rarement, 19%

Standish group, Chaos Manifesto 2002,

2002

S.BenSalem - Génie logiciel 9

 Bugs célèbres
Sonde Mariner 1, 1962
●
Détruite 5 minutes après son lancement; coût : $18,5 millions
●
Défaillance des commandes de guidage due à une erreur de spécification
●
Erreur de transcription manuelle d'un symbole mathématique dans la
spécification
Therac-25, 1985-87
●
Au moins 5 morts par dose massive de radiations
Electron mode X-ray mode Problem
●
Problème d'accès concurrents dans le contrôleur
Processeur Pentium, 1994
●
Bug dans la table de valeurs utilisée par l'algorithme de division
Ariane V vol 501, 1996
●
Explosion après 40 secondes de vol; coût : $370 millions
●
Panne du système de navigation due à un dépassement
de capacité (arithmetic overflow)
●
Réutilisation d'un composant d'Ariane IV non re-testé

S.BenSalem - Génie logiciel 10

 Plus récemment
PlayStation Network, avril 2011
●
Des millions de données personnelles et bancaires piratées
●
Pertes financières de plusieurs milliards de dollars
● Vulnérabilité du réseau connue mais conséquences mal évaluées ?

Outil de chiffrement OpenSSL, mars 2014

●
500 000 serveurs web concernés par la faille
●
Vulnérabilité permettant de lire une portion de la mémoire d'un serveur distant

De manière générale, fiabilité, sûreté et sécurité des logiciels

●
Transports automobile, ferroviaire, aéronautique
●
Contrôle de processus industriels, nucléaire, armement
●
Médical : imagerie, appareillage, télé-surveillance
●
e-commerce, carte bancaire sans contact, passeport électronique

S.BenSalem - Génie logiciel 11

 Pourquoi ?
Raisons principales des bugs :
●
Erreurs humaines
●
Taille et complexité des logiciels
●
Taille des équipes de conception/développement
●
Manque de méthodes de conception
●
Négligence de la phase d'analyse des besoins du
● client
Négligence et manque de méthodes et d'outils des phases de
validation/vérification

S.BenSalem - Génie logiciel 12

 Mythes du logiciel
●
Idée grossière du logiciel suffisante pour commencer à programmer
Faux : échecs dus principalement à une idée imprécise du logiciel
●
Travail terminé quand programme écrit et fonctionnel
Faux : maintenance du logiciel = plus du 50% du coût total
●
Facile de gérer l es spécifications changeantes
Faux : changements de spécifications souvent coûteux
●
En cas de retard, solution : ajouter des programmeurs
Faux : période de familiarisation et communication plus difficile
impliquent perte de productivité
« Ajouter des programmeurs à un projet en retard ne fait que
le
retarder davantage »

S.BenSalem - Génie logiciel 13

 Génie logiciel
Idée : appliquer les méthodes classiques d'ingénierie au domaine
du
logiciel

Ingénierie (ou génie) : Ensemble des fonctions allant de la conception

et des études à la responsabilité de la construction et au contrôle des
équipements d'une installation technique ou industrielle

Génie civil, naval, aéronautique, mécanique, chimique...

S.BenSalem - Génie logiciel 14

 Génie logiciel
Définition : Ensemble des méthodes, des techniques et des outils
dédiés à la conception, au développement et à la maintenance des
systèmes informatiques

Objectif : Avoir des procédures systématiques pour des logiciels

de afin que
grande taille
●
la spécification corresponde aux besoins réels du client
●
le logiciel respecte sa spécification
●
les délais et les coûts alloués à la réalisation soient respectés

S.BenSalem - Génie logiciel 15

 Génie logiciel
Particularités du logiciel :
produit invisible et immatériel
●

●
diicile de mesurer la qualité
●
conséquences critiques causées par modifications infinies
●
mises à jour et maintenance dues à l'évolution rapide de la
technologie
●
difficile de raisonner sur des programmes
●
défaillances logicielles principalementhumaines

S.BenSalem - Génie logiciel 16

 Principes d'ingénierie pour le logiciel
Sept principes fondamentaux
●
Rigueur : principale source d'erreurs humaine, s'assurer par tous les
moyens que ce qu'on écrit est bien ce qu'on veut dire et que ça
correspond à ce qu'on a promis (outils, revue de code...)
●
Abstraction : extraire des concepts généraux sur lesquels raisonner,
puis instancier les solutions sur les cas particuliers
●
Décomposition en sous-problèmes : traiter chaque aspect
séparément, chaque sous-problème plus simple que l e problème global
●
Modularité : partition du logiciel en modules interagissant,
remplissant une fonction et ayant une interface cachant
l'implantation aux autres modules

S.BenSalem - Génie logiciel 17

 Principes d'ingénierie pour le logiciel
●
Construction incrémentale : construction pas à pas, intégration
progressive
●
Généricité : proposer des solutions plus générales que le
problème
pour pouvoir les réutiliser et les adapter à d'autres cas
●
Anticipation des évolutions : liée à la généricité et à la modularité,
prévoir les ajouts/modifications possibles de fonctionnalités

De façon transversale
●
Documentation : essentielle pour le suivi de projet et
la communication au sein de l'équipe de projet
●
Standardisation/normalisation : aide à la communication pour le
développement, la maintenance et la réutilisation

S.BenSalem - Génie logiciel 18

 Processus de développement logiciel
Ensemble d'activités successives, organisées en vue de la production
d'un logiciel

En pratique :
Pas de processus idéal
●

●
Choix du processus en fonction des contraintes (taille des
équipes, temps, qualité...)
●
Adaptation de « processus types » aux besoins réels

S.BenSalem - Génie logiciel 19

 Processus de développement logiciel
Activités du développement logiciel
Analyse des besoins
●

●
Spécification
●
Conception
●
Programmation
●
Validation et vérification
● Livraison
● Maintenance

Pour chaque activité : Utilisation et production de documents

S.BenSalem - Génie logiciel 20

 Analyse des besoins
Objectif : Comprendre les besoins du client
Objectifs généraux, environnement du futur système,
●

ressources disponibles, contraintes de performance...

Analyse
des besoins

Besoins du client Cahier des charges

(+ manuel
d'utilisation
préliminaire)

S.BenSalem - Génie logiciel 21

 Spécification
Objectifs :
Établir une description claire de ce que doit faire le logiciel
●

(fonctionnalités détaillées, exigences de qualité, interface...)

●
Clarifier le cahier des charges (ambiguïtés, contradictions)

Spécification

Cahier des charges Cahier des charges

fonctionnel

S.BenSalem - Génie logiciel 22

 Conception
Objectif : Élaborer une solution concrète
réalisant
● la spécification
Description architecturale en composants (avec interface et
fonctionnalités)
●
Réalisation des fonctionnalités par les composants
(algorithmes, organisation des données)
●
Réalisation des exigences non-fonctionnelles (performance,
sécurité...)

Conception

Cahier des charges Dossier de conception

fonctionnel

S.BenSalem - Génie logiciel 23

 Programmation
Objectif : Implantation de la solution conçue
●
Choix de l'environnement de développement, du/des
langage(s) de programmation, de normes de
développement...

Programmation

Dossier de conception Code documenté

+ manuel d'utilisation

S.BenSalem - Génie logiciel 24

 Validation et vérification
Objectifs :
Validation : assurer que les besoins du client sont satisfaits (au
●

niveau de la spécification, du produit fini...)

Concevoir le bon logiciel
Vérification : assurer que le logiciel satisfait
●
sa spécification
Concevoir le logiciel correctement

Validation

Cahier des
Besoins charges Logiciel
du client
fonctionnel

Vérification
S.BenSalem - Génie logiciel 25
 Méthodes de validation et vérification
Méthodes de validation :
●
Revue de spécification, de code
●
Prototypage rapide
●
Développement de tests (extreme programming)
exécutables
Méthodes de vérification :
●
Test (à partir de la spécification)
●
Preuve de programmes
●
Model-checking (vérification de modèles)

S.BenSalem - Génie logiciel 26

 Démarche de test
Plan de test
Description des exigences de test (couverture des
●

exigences
fonctionnelles et non fonctionnelles)
●

Choix d'une stratégie de test et planification des tests

Cahier de tests
Description des cas de test (couverture des exigences de test)
●

Élaboration des procédures de test

●

Dossier de tests
Implémentation et exécution des tests
●

Évaluation de l'exécution des tests et analyse des résultats

●

Rapport de test
●

S.BenSalem - Génie logiciel 27

 Maintenance
Type de maintenance :
s Correction : identifier et corriger des erreurs trouvées après la
●
livraison
Adaptation : adapter le logiciel aux changements
●

dans
l'environnement (format des données, environnement
d'exécution...)
Perfection
●
: améliorer la performance, ajouter des
fonctionnalités, améliorer la maintenabilité du logicie
l

S.BenSalem - Génie logiciel 28

 Répartition de l'effort

7%
6%

8% Spécification
Conception
Programmation
Intégration/Test
19% 60% Maintenance

S.BenSalem - Génie logiciel 29

 Rapport effort/erreur/coût
100

80

Intégration/Test

60

Programmation 40

Conception
20

Spécification

Effort Origine Coût de la

des maintenance
erreurs
S.BenSalem - Génie logiciel 30
 Processus en cascade
Chaque étape doit être terminée avant que ne commence la suivante
À chaque étape, production d'un document base de l'étape suivante

Spécification Cahier des charges

fonctionnel

Conception Dossier de
conception
détaillée
Programmation
Code documenté +
et test unitaire
Rapport de tests
unitaires
Intégration
et test système Rapport de validation

Livraison
et maintenance
S.BenSalem - Génie logiciel 31
 Processus en cascade
Caractéristiques :
Hérité des méthodes classiques d'ingénierie
●

Découverte d'une erreur entraîne retour à la phase à

●
de
l'origine
l'erreur et nouvelle cascade, avec de nouveaux documents...
●

Coût de modification d'une erreur important, donc choix en

amont cruciaux (typique d'une production industrielle)
Pas toujours adapté à une production logicielle, en si
particulier
besoins du client changeants ou difficiles à spécifier

S.BenSalem - Génie logiciel 32

 Processus en V
Caractéristiques :
Variante du modèle en cascade
●

Mise en évidence de la complémentarité des phases menant à la

●

réalisation et des phases de test permettant de les valider

Inconvénients : les mêmes que le cycle en cascade

●
Processus lourd, difficile de revenir en arrière
●
Nécessite des spécifications précises et stables
●
Beaucoup de documentation

S.BenSalem - Génie logiciel 33

 Niveaux de test
Test unitaire : test de chaque unité de programme (méthode,
classe,
composant), indépendamment du reste du système
Test d'intégration : test des interactions entre composants (interfaces
et composants compatibles)

Test d'acceptation et système : test du système complet par rapport à

son cahier des charges

Recette : faite par le client, validation par rapport aux besoins initiaux
(tests, validation des documents, conformité aux normes...)

S.BenSalem - Génie logiciel 35

 Processus en V

Analyse Écriture
Recette
des besoins Validation

Tests d'acceptation
Spécification et système

Conception Intégration et
architecturale tests d'intégration

Conception
Tests unitaires
détaillée

Programmation

S.BenSalem - Génie logiciel 34

 Développement par prototypage
Principe :
●
Développement rapide d'un prototype avec le client pour valider
ses besoins
●
Écriture de la spécification à partir du prototype, puis processus
de développement linéaire

Cahier
Besoins des
Prototype Logiciel
du client
charges
fonctionn
el

Avantage : Validation concrète des besoins, moins de risques d'erreur

de spécification

S.BenSalem - Génie logiciel 36

 Développement incrémental
Principe :
Hiérarchiser les besoins du client
●

Concevoir et livrer au client un produit implantant un sous-

●

ensemble de fonctionnalités par ordre de priorité

Spécification Spéc. Spéc. Spéc. Spéc.

Conception Conc. Conc. Conc. Conc.
Programmation Prog. Prog. Prog. Prog.
Validation et vérification V&V V&V V&V V&V
Livraiso Li
Livr. Livr. Livr. Livr.
n
Développement cascade Développement incrémental
en

Avantage : Minimiser le risque d'inadéquation aux besoins

Difficulté : Intégration fonctionnalités secondaires non pensées en amont
S.BenSalem - Génie logiciel 37
 Méthodes agiles et extreme programming
Principes :
Implication constante du client
●

Programmation en binôme (revue de code permanente)

●

Développement dirigé par les tests

●

Cycles de développement rapides pour réagir aux

●

changements
Avantages : développement rapide en adéquation avec les
besoins
Inconvénients : pas de spécification, documentation = tests,
maintenance ?

Fonctionne pour petites équipes de développement (< 20) car

la communication est cruciale

S.BenSalem - Génie logiciel 38

 Documentation
Objectif : Traçabilité du projet

Pour l'équipe :
Regrouper et structurer les décisions prises
●

Faire référence pour les décisions futures

●

Garantir la cohérence entre les modèles et le produit

●

Pour le client :
Donner une vision claire de l'état d'avancement du projet
●

Base commune de référence :

Personne quittant le projet : pas de perte d'informations
●

Personne rejoignant le projet : intégration rapide

●

S.BenSalem - Génie logiciel 39

 Documents de spécification et conception
Rédaction : le plus souvent en langage naturel (français)

Problèmes :
Ambiguïtés : plusieurs sens d'un même mot selon les personnes
●

ou les contextes
●
Contradictions, oublis, redondances difficiles à détecter
●
Difficultés à trouver une information
●
Mélange entre les niveaux d'abstraction (spécification vs.
conception)

S.BenSalem - Génie logiciel 40

 Documents de spécification et conception
Alternatives au langage naturel
Langages informels :
Langage naturel structuré : modèles de document et règles de
●

rédaction précis et documentés

Pseudo-code : description algorithmique de l'exécution d'une
●

tâche, donnant une vision opérationnelle du système

Langages semi-formels :
Notation graphique : diagrammes accompagnés de texte
●

structuré, donnant une vue statique ou dynamique du

système
Langages formels :
●
Formalisme mathématique : propriétés logiques ou modèle du
comportement du système dans un langage mathématique

S.BenSalem - Génie logiciel 41

 Documents de spécification et conception
Langages informels ou semi-formels :
✔ Avantages : intuitifs, fondés sur l'expérience, facile à apprendre
et à utiliser, répandus
✗Inconvénients : ambigus, pas d'analyse systématique

Langages formels :
✔ Avantages : précis, analysables automatiquement, utilisables
pour automatiser la vérification et le test du logiciel
✗Inconvénients : apprentissage et maîtrise difficiles

En pratique : utilisation de langages formels principalement pour

logiciels critiques, ou restreinte aux parties critiques du
système
S.BenSalem - Génie logiciel 42
 Modélisation
Modèle : Simplification de la réalité, abstraction, vue subjective
modèle météorologique, économique, démographique...
●

Modéliser un concept ou un objet pour :

Mieux le comprendre (modélisation en physique)
●

Mieux le construire (modélisation en ingénierie)

●

En génie logiciel :
●
Modélisation = spécification + conception
●
Aider la réalisation d'un logiciel à partir des du client
besoins

S.BenSalem - Génie logiciel 43

 Modélisation graphique
Principe : « Un beau dessin vaut mieux qu'un long discours »
Seulement s'il est compris par tous de la même manière

S.BenSalem - Génie logiciel 44

UML : Unified Modeling Language
Langage :
Syntaxe et règles d'écriture
●

Notations graphiques
●

normalisées :
…de modélisation
Abstraction du fonctionnement et de la structure du système
●

Spécification et conception
●

…unifié :
Fusion de plusieurs notations antérieures : Booch, OMT, OOSE
●

●
Standard défini par l'OMG (Object Management Group)
●
Dernière version : UML 2.4.1 (août 2011)

En résumé : Langage graphique pour visualiser, spécifier, construire et

documenter un logiciel
S. BenSalem - Génie logiciel 45
 Pourquoi UML ?
Besoin de modéliser pour construire un logiciel
Modélisation des aspects statiques et dynamiques
●

Modélisation à différents niveaux d'abstraction

●
et selon
plusieurs vues
Indépendant du processus de développement
●

Besoin de langages normalisés pour la modélisation

Langage graphique, semi-
●

formel
●

Standard très utilisé

Conception orientée objet
●
Façon efficace de penser le logiciel
●
Indépendance du langage de programmation (langages non objet)
S.BenSalem - Génie logiciel 46
 Conception orientée objet avec UML

UML n'est pas une méthode de conception

UML est un outil indépendant de la méthode

S.BenSalem - Génie logiciel 47

 Diagrammes UML
Représentation du logiciel à différents points de vue :
●
Vue des cas d'utilisation : vue des acteurs (besoins attendus)
●
Vue logique : vue de l’intérieur (satisfaction des besoins)
●
Vue d'implantation : dépendances entre les modules
●
Vue des processus : dynamique du système
●
Vue de déploiement : organisation environnementale du logiciel

Vue Vue
d'implant logiq
ation ue
Vue des cas
d'utilisation

Vue de Vue des

déploieme processu
nt s
S.BenSalem - Génie logiciel 48
 Diagrammes UML
14 diagrammes hiérarchiquement dépendants
Modélisation à tous les niveaux le long du processus de développement

Diagrammes structurels : Diagrammes comportementaux :

Diagramme de classes
● ●
Diagramme de cas
Diagramme d'objets
● d'utilisation
Diagramme de
●
●
Diagramme états-transitions
composants ●
Diagramme d'activité
Diagrammes d'interaction :
Diagramme de
●

déploiement
●
Diagramme de séquence
Diagramme de
●
●
Diagramme de communication
paquetages ●
Diagramme global d'interaction
Diagramme de structure
● ●
Diagramme de temps
composite
S.BenSalem - Génie logiciel 49
●
Diagramme de profils
 Exemple d'utilisation des diagrammes
●
Diagrammes de cas d'utilisation : besoins des utilisateurs
●
Diagrammes de séquence : scénarios d'interactions entre les
Spécification

utilisateurs et le logiciel, vu de l'extérieur

●
Diagrammes d'activité ou états-transitions : enchaînement
d'actions représentant un comportement du logiciel

●
Diagrammes de classes : structure interne du logiciel
●
Diagrammes d'objet : état interne du logiciel à un instant donné
Conception

●
Diagrammes états-transitions : évolution de l'état d'un objet
●
Diagrammes de séquence : scénarios d'interactions avec
utilisateurs oulesau sein du logiciel
●
Diagrammes de composants : composants physiques du logiciel
●
Diagrammes de déploiement : organisation matérielle du logiciel
S.BenSalem - Génie logiciel 50
Ateliers et Outils de Génie Logiciel
Chapitre 2: Cahier de charge

Safa Ben Salem

sb.salem@yahoo.fr
 Définition Cahier de charge

• 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 système devra
accomplir pour lui.
• Le CDC permet en outre :
 de provoquer chez le concepteur / réalisateur (prestataire) la
conception et la réalisation du produit le plus efficient,
 de faciliter la compréhension des propositions des
prestataires,
 de favoriser le dialogue entre les partenaires.

53
 Définition 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 définis des critères
d'appréciation et leurs niveaux. Chacun de ces niveaux doit être
assorti d'une flexibilité.
 Produire un CDC: Méthodologie (1)

• Le CDC doit être rédigé indépendamment 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 différents utilisateurs selon
les phases de l'état vivant du produit.

• Le CDC exprime les besoins exactes des utilisateurs. Pour

ce faire, des entretiens sont menés et un groupe de travail
est constitué.

55
 Produire un CDC: Méthodologie (2)
• Le Cahier des Charges Fonctionnel est la conclusion des
travaux d'analyse de la valeur et d'analyse fonctionnelle
qui symbolisent la démarche d'expression du besoin :
• Orienter l'étude : Du général au spécifique.
• Premiers points de la démarche :
• regarder le projet d'un œil extérieur

• Prendre du recul

• Se poser les bonnes questions :

 Rechercher l'information
 Traduire le besoin en fonctions
 Formaliser les travaux
 Contrôler le CDC Besoin
 Valider le CDC Besoin
56
 Recherche de l’information

• La recherche de l'information doit être canalisée et

formalisée.
• C'est un processus constant tout au long du projet qui doit
être mené rigoureusement dès le début du projet afin
d'appréhender plus précisément les caractéristiques
essentielles du besoin.
• Un excellent moyen de chercher l'information la plus
pertinente et de la vérifier en même temps est de constituer
un groupe de travail.

57
 Traduire le besoin en fonctions

• Le passage du besoin en fonction s'effectue au travers de l'analyse

fonctionnelle qui recense, caractérise, ordonne, hiérarchise et
valorise les fonctions.

58
 Formaliser les travaux

• Cette formalisation consiste à développer le Cahier des Charges.

• Il reprendra les conclusions de l'analyse fonctionnelle.

59
 Contrôler le CDC besoin

• Le contrôle du document est très important. En effet, on remarque que

cette étape n'est généralement pas effectuée de façon optimale alors
qu'elle est un frein aux dysfonctionnements qui peuvent apparaître
beaucoup plus tard dans le projet.

60
 Valider le CDC besoin

• Il s'agit de s'assurer que le passage du besoin exprimé au besoin

fonctionnel est conforme aux objectifs visés. C'est un travail qui peut
s'avérer fastidieux et risqué si le volume d'information est important.
L'objectif est donc ici de rendre efficace la validation en réduisant
son domaine d'action et tout en conservant sa représentativité.

61
 Exemple de CDC selon
IEEE std 830 (1)
I. Introduction
II.Contexte de la réalisation
1. Objectifs
2. Hypothèses
3. Bases méthodologiques
III.Description générale
1. Environnement du projet
2. Fonctions générales du système
3. Caractéristiques des utilisateurs
4. Configuration du système
5. Contraintes générales du développement, d’exploitation et
de maintenance Contraintes de développement

 Contraintes d’exploitation

 Maintenance et évolution du système 62
 Exemple de CDC selon
IEEE std 830 (2)
IV. Description des interfaces externes du logiciel
1. Interface matériel / logiciel
2. Interface homme / machine
3. Interface logiciel / logiciel
V. Description des objets
1. Définition des objets
 Identification de l’objet i
 Contraintes sur l’objet i
VI.Description des fonctions
1. Définitions des fonctions
 Identification de la fonction i
 Description de la fonction i
 Contraintes opérationnelles sur la fonction i
63
 Exemple de CDC selon
IEEE std 830 (3)
2. Conditions particulières de fonctionnement

1. Performances
2. Capacités
3. Modes de fonctionnement
4. Contrôlabilité
5. Sûreté
6. Intégrité
7. Conformité aux standards
8. Facteurs de qualité
VII- Justification des choix effectués
VIII- Glossaires
IX. Références
1. Annexes
2. Index 64
 Exemple de CDC: Gestion
d’une bibliothèque (1)
Fonctionnalités

• Il s'agit d'un outil d'aide à la gestion de bibliothèque.

• Une bibliothèque prête des livres et des magazines à des emprunteurs.
• Les livres et les magazines sont répertoriés dans le système.
• Les emprunteurs sont répertoriés dans le système.
• Une bibliothèque s'occupe de l'achat de nouveaux titres.
• Les titres populaires sont achetés en plusieurs exemplaires.
• Les vieux livres ou magazines sont retirés lorsqu'ils sont trop anciens.
• Les vieux livres ou magazines sont retirés lorsqu'ils sont en mauvais
état.
• Le bibliothécaire est un employé de la bibliothèque.

65
 Exemple de CDC: Gestion
d’une bibliothèque (2)
 Le bibliothécaire communique avec les emprunteurs.
 L'outil assiste le bibliothécaire dans sa tâche.
 Un emprunteur peut réserver un livre ou un magazine qui
n'est pas disponible (déjà prêté ou non encore répertorié).
 Lorsqu'un livre ou un magazine devient disponible (rendu ou
acheté), l'emprunteur qui l'a réservé est averti.
 La réservation est annulée lorsque le livre ou le magazine est
prêté.
 Une réservation peut être annulée à tout moment.
 Les création, mise à jour et destruction d'informations
relatives aux titres, emprunteurs, prêts et réservations
doivent être aisées.

66
 Exemple de CDC: Gestion
d’une bibliothèque (3)
 Contraintes non fonctionnelles
 L'application doit tourner dans tout environnement Unix ou Windows.
 L'application doit avoir une IHM agréable.
 L'application doit pouvoir être étendue à d'autres fonctionnalités.

 Limitations

 L'application ne gère pas l'envoi du message d'avertissement aux

emprunteurs lorsque le livre ou le magazine qu'ils ont réservé devient
disponible.

 L'application ne gère pas les retards à la restitution.

67
 Exercice: Gestion d’une projet
• Une société de développement logiciel décide d’implémenter son
propre outil de gestion de projet. Elle a dégagé les entités suivantes :
• Un projet est caractérisé par son identifiant, son nom, une description,
une date de début, une date de fin.
• Un projet passe par plusieurs phases. Chaque phase est caractérisée
d’un identifiant, un nom, une description, une date de début, une date
de fin et réalisée par une équipe de personnes dont l’un est responsable
(il existe un seul responsable pour une phase). Une phase doit générer
un rapport.
• Chaque document est caractérisé par son identifiant, son nom,
une description, sa date de validation, son état (valide, non
valide, en attente).
• Une personne est caractérisée par son identifiant, son nom, son
prénom, son âge. A un instant il participe à une seule phase.

68
 Exercice: Gestion d’une projet

 Donner la description textuelle de ce logiciel en se basant sur le

modèle suivant :

69
70