Vous êtes sur la page 1sur 70

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