05/05/2014 1

Qualit du Logiciel
BELASLA El Mehdi

2
Question?
Vous ? (nom, prnom, diplmes..)
Dveloppeur informaticien?
Logiciel ?
Qualit logicielle?
Normes ? :CMMI ? ISO ? ITIL? PMBOK?
COBIT?
Outils : dveloppement? GBD? GP?...
3
Plan gnral du cours
Introduction la qualit du logiciel
Assurance qualit
Normes et dmarches qualit
Rfrentiels de qualit :
CMMI
ITIL
COBIT
Mtriques de la qualit du logiciel ( Qualimetrie )

4
Quelques ouvrages
Prcis de Gnie Logiciel, M.-C. Gaudel at al., Masson,
1996
Gnie Logiciel : principes, mthodes et techniques, A.
Strohmeier et al., Presses Polytechniques et
Universitaires Romandes, 1996
ISO 9001 and Software Quality Assurance, D. Ince,
McGrawHill, 1994
IS0 9000-3 A Tool for Software Product and Process
Improvement, R. Kehoe and A. Jarvis, Springer, 1995
05/05/2014 5
Partie 1: introduction la
qualit du logiciel
6
Objectifs
Qu'est-ce la qualit du logiciel?
Pourquoi la qualit du logiciel?
Facteurs de qualit du logiciel
Dfauts du logiciels par rapport au processus de
dveloppement
Dfinition de l'ingnierie de la qualit du logiciel
Total Quality Management
7
Quest ce quun logiciel
Selon l'IEEE

Un logiciel est:

Des programmes, procdures, ainsi que possiblement
de la documentation et des donnes lies
l'opration d'un systme informatique.
8
il est visible mais intangible
il vieillit mais ne s'use pas
il ne se dtriore pas sous l'effet des tests
il est encore et toujours fabriqu artisanalement
il est (trop ?) facilement reproductible
il est (trop ?) facile modifier
il est d'une grande complexit : cot trs (trop ?) lev
...
Le logiciel : proprits
9
La crise
du
Logiciel
Cot du Dveloppement Logiciel / Cot du matriel
50%
100%
60 70 80 90
Cot du logiciel vs cot du matriel
10
Rpartition des cots de
dveloppement
spcification : 6%
conception : 5%
codage : 7%
tests et validation : 15%
maintenance : 67%
Cots de correction des erreurs
provenant
exigences et spcification : 56%
conception : 24%
codage : 10%
autres : 10%

Quelques chiffres
11
Qualit du logiciel
Qualit en gnral:
perception de la valeur d'un produit par client
bas sur: prix, performance, fiabilit, satisfaction
Pour l'ingnierie de la Qualit, nous avons besoins:
dfinition plus prcise/oprationnelle
mesure du degr de qualit
monitoring de la qualit
amlioration du dveloppement pour mieux atteindre
objectifs de qualit
12
Qualit du logiciel
Conformit aux exigences

Bug/dfaut consquence d'une erreur humaine
Rsulte en non-conformit aux exigences

Sens le plus troit de qualit du logiciel
absence de bugs
bas ratio de dfauts (# de dfauts/unit de taille)
haute fiabilit (nombre de pannes par n heures
d'opration)
Temps Moyen entre Pannes (Mean Time To Failure - MTTF)
probabilit d'opration sans panne dans un temps spcifi
13
Qualit du logiciel
Deux niveaux de qualit
Small q: qualit intrinsque du produit
Limite au ratio de dfauts et la fiabilit
Big Q: niveau plus largi
qualit du produit
qualit du processus
satisfaction des clients
Besoins et demandes du client
Assurance de la satisfaction des clients
Exigences et spcifications
Produits conus, dvelopps et fabriqus conformment aux prescriptions
en continu ax sur l'amlioration des processus
Excellente qualit des produits,
bonne distribution, service processus
Boucle
de la
qualit
14
Qualit du logiciel
pourquoi ?
15
Importance Qualit du Logiciel
Logiciel est une composante majeure des systmes
informatiques (environ 80% du cot) utiliss pour
Communication (ex. syst. tlphone, syst. email)
Sant (monitoring),
Transport (ex. automobile, aronautique),
changes conomiques (ex. e-commerce),
Entertainment, etc.
Les dfauts du logiciel sont extrmement coteux en
terme de
Argent
Rputation
Perte de vie
16
Importance de la qualit du logiciel
Plusieurs dsastres historiques attribus au logiciel
1988 abattage d'un Airbus 320 par l'USS Vincennes
affichage cryptique et confusant du logiciel de
dtection
1991 chec de missile patriot - calcul imprcis de
temps d des erreurs arithmtiques
London Ambulance Service Computer Aided
Despatch System plusieurs dcs
Le 3 Juin 1980, North American Aerospace Defense
Command (NORAD) rapporta que les U.S. taient
sous attaque de missiles
17
Importance de la qualit du logiciel
Ariane 5 crash 4 Juin 1996
Vol inaugural du lanceur europen Ariane 5 crash environ 40
secondes aprs dcollage

Perte d'environ milliards de dollars

L'explosion tait le rsultat d'une erreur logiciel

Exception non capture due une erreur de floating-point:
conversion d'entier 64-bit entier 16-bit signed integer appliqu
un nombre plus large que suppos
Le module tait r-utilis sans avoir t test convenablement
d'Ariane 4
Erreur n'tait pas suppos survenir avec Ariane 4
Pas de gestionnaire d'exception
18
Importance de la qualit du logiciel
Virus et vers Internet
Ver Blaster ($US 525 millions)
Sobig.F ($US 500 millions 1milliard)
Exploitent des vulnrabilit bien connues du logiciel
Les dveloppeurs de logiciel ne consacrent pas assez d'effort
appliquer des leons apprises sur les causes des vulnrabilits.
Les mmes types de vulnrabilits continuent tre vus dans
les nouvelles versions des produits qui taient dans des versions
prcdentes.
Problmes d'utilisabilit
19
Importance de la qualit du logiciel
Impact montaire de logiciel de mauvaise qualit (Standish group
1995)
175,000 projets logiciels/an cot moyen par projet
Grosses compagnies - US 2,322,000
Compagnies Moyennes - US 1,331,000
Petites compagnies - US 434,000
31.1% des projets annuls avant leur compltion
cot $81 milliards
52.7% des projets dpassent leur budget cotent 189\% de l'original
cot $59 milliards
16.2% des projets complts temps selon le budget (9% pour
grosses compagnies)
Grosses compagnies systmes dlivrs ont approximativement
seulement 42% des fonctions originellement proposes
78.4% des projets de petites compagnies sont dploys avec au
moins 74.2% des fonctions originelles.
20
Il est indispensable de fixer a priori la qualit d'un systme
dans lequel un logiciel critique intervient
Pour cela, il faut :
tre sr de ses spcifications compltude ?
valider/vrifier toute tape cl dans un dveloppement
a-t-on les moyens de la V&V ?
Rutiliser mais pas n'importe COMMENT
quelles mthodes, quels outils ?
Leons
21
Sources derreurs
10 raisons principales pour le succs de projets (Standish group)
1. Participation des Clients
2. Appui de la Gestion Excutive
3. Description claire des Exigences
4. Planification Approprie
5. Esprances Ralistes
6. Milestones de projets plus petits
7. Personnel Comptent
8. Proprit
9. Vision & objectifs clairs
10. Personnel Assidu Et Focalis
22
Sources derreurs
10 raisons principales pour projets challengs
1. Manque d'Input du client
2. Exigences & Spcifications Incomplets
3. Exigences & Spcifications changeantes
4. Manque de support de l'excutif
5. Incomptence technologique
6. Manque de Ressources
7. Attentes irralistes
8. Objectifs non-claires
9. Temps de dveloppement irraliste
10. Nouvelle technologie
23
Sources derreurs
10 raisons principales pour projets annuls
Exigences Incompltes
Manque de participation des clients
Manque de Ressources
Attentes irralistes
Manque de support de l'excutif
Exigences & Spcifications changeantes
Manque de Planification
Plus besoin du logiciel
Manque de gestion IT
Analphabtisme Technologique
24
Et le client ?
Produit de bonne qualit est un qui le/la satisfait
Conforme aux spcifications
Fonctionne bien sur plate-forme(s)/configurations
Satisfait compltement aux exigences oprationnelles (mme
si non-spcifie!)
Compatible avec tout l'quipement des usagers terminaux
Backward transparent aux usagers finaux
N'a pas d'impact ngatif sur les usagers finaux au temps
d'introduction
25
Problmatique de la qualit logicielle
Le caractre unique du produit logiciel
Grande complexit
Invisibilit du produit
Opportunits limits de dtection de (bugs) seulement durant le
dveloppement

Les environnements de dveloppement du logiciel
Sous contrat
Sujet une relation client/fournisseur
Exige un travail d'quipe
Exige la coopration et coordination avec d'autres quipes de
dveloppement
Exige des interfaces avec d'autres systmes
Exige la poursuite du projet alors que l'quipe change
Exige la maintenance pendant plusieurs annes
26
Qualit
Utilisateurs
Dcideurs client
Dcideurs
fournisseur
Dveloppeurs
Logiciel
Offre
Bnfices
Produits
intermdiaires
Problmatique de la qualit
27
Facteurs de qualit logicielle
Modle de qualit logicielle de McCall's

28
Facteurs de qualit de logiciel
Correctude
exactitude, compltude de la sortie requise
disponibilit, caractre jour de l'information
Effort requis pour localiser et corriger une erreur
(lisibilit, traabilit, accessibilit, etc.)
Y contribue :
Qualit de la documentation
Rgle de prsentation et de nommage
Modularit
Traitement des erreurs
29
Facteurs de qualit de logiciel
Fiabilit
taux de panne maximum
Aptitude avec laquelle il fonctionne sans dfaillance
pour une dure donne (robuste, constant, etc.).

Y contribue :
Disponibilit
Robustesse
Scurit

30
Facteurs de qualit de logiciel
Efficacit
ressources ncessaires la fonction du logiciel
Aptitude avec laquelle il fonctionne avec un optimum de
ressources et de temps
Y contribue :
La bonne utilisation des ressources machines (CPU,
mmoire, ...)

31
Facteurs de la qualit de logiciel
Intgrit (scurit)
scurit du systme logiciel, droits d'accs
Aptitude avec laquelle il est protg contre les altrations
ou les accs non autoriss (protg, confidentiel, etc.).

Y contribue :
La disponibilit
Confidentialit

32
Facteur de la qualit du logiciel
Utilisabilit
habilit d'apprentissage, habilit d'usage pour la tche requise
Effort requis pour l'apprentissage et le dialogue homme/machine et la
documentation (comprhensible, maniable, document, etc.).

Y contribue :
Ergonomie
Facilit d'utilisation
Facilit d'apprentissage
33
Facteurs de qualit du logiciel
Maintenabilit
effort pour identifier et corriger les pannes
(documentation, lisibilit, traabilit, accessibilit,
etc.)

Y contribue :
Qualit de la documentation
Rgle de prsentation et de nommage
Modularit
Traitement des erreurs

34
Facteurs de la qualit du logiciel
Flexibilit
degr d'adaptabilit (a de nouveaux usagers, tches, etc)

Effort requis pour l'amlioration, spcifications inchanges ou pour le
modifier afin de rpondre de nouvelles versions du systme
d'exploitation.

Y contribue :
Perfectibilit
Flexibilit
Modularit
Niveau de paramtrage

35
Facteurs de la qualit du logiciel
Testabilit
support pour tests (ex: fichier logs, diagnostics automatiques,
etc)
Effort requis pour s'assurer de son bon fonctionnement (jeu d'essais et
vrification de rsultats)

Y contribue :
Modularit
Automatisation des tests
Facilit d'analyse des rsultats
36
Facteurs de qualit du logiciel
Portabilit
Adaptation d'autres environnements (matriel,
logiciel)
Effort requis pour le transfrer d'un environnement un
autre. La portabilit peut tre vue sous ses deux aspects :
intgrable sur d'autres systmes d'exploitation
intgrable sur d'autres machines.

Y contribue :
Modularit
Indpendance logiciel et matriel
37
Facteurs de qualit du logiciel
Reusabilit
Usage de composants du logiciel pour d'autres
projets.
Aptitude avec laquelle il peut tre utilis dans de multiples
applications (paramtrable, modulaire, indpendant,
etc.)

Y contribue :
Modularit
Indpendance logiciel et matriel
Niveau de paramtrage

38
Facteurs de qualit du logiciel
Interoprabilit
Habilit d'interfaage avec d'autres composants/systmes
Aptitude avec laquelle il peut communiquer ou interagir avec d'autres
systmes (interfaable, compatible)

Y contribue:
Compatibilit
Banalit des communications
Banalit des donnes
39
Qu'est ce l'assurance de qualit
logicielle ?
Selon l'IEEE

L'assurance qualit logicielle est:

Un modle planifi et systmatique de toutes les actions
ncessaires pour fournir une confiance adquate qu'un
article ou un produit est conforme ses exigences
techniques tablies.

Un ensemble d'activits conu pour valuer le processus
par lequel les produits sont dvelopps ou fabriqus. A
contraster avec: le contrle de qualit.
40
Qu'est ce l'assurance de qualit
logicielle ?
Selon D. Galin

L'assurance qualit logicielle est:

Un ensemble systmatique et prvu d'actions
ncessaires l'obtention d'une confiance adquate que
le procd de dveloppement de logiciel ou le processus
de maintenance d'un produit de systme logiciel est
conforme aux exigences techniques fonctionnels
tablies aussi bien qu'aux exigences concernant le
schedule et budget.
41
Objectifs de l'AQL dans le
dveloppement
Assurer un niveau de confiance acceptable que le
logiciel sera conforme aux exigences fonctionnelles
techniques.

Assurer un niveau de confiance acceptable que le
logiciel sera conforme aux exigences de gestion
concernant l'chancier et le budget.

Initiation et activits de gestion pour l'amlioration et la
plus grande efficience des activits de dveloppement et
d'assurance de qualit logicielle.
42
Trois principes gnraux de l'AQL
Savoir ce que vous faites
Savoir ce que vous devriez faire
Savoir mesurer la diffrence
43
Trois principes gnraux de l'AQL
Savoir ce que vous faites
comprendre ce qui est entrain d'tre construit,
comment il est construit et ce qu'il fait
suppose un processus de dveloppement logiciel
avec
une structure de gestion (milestones, schduling)
politique de rapport
processus de suivi
44
Trois principes gnraux de lAQL
Savoir ce que vous faites
comprendre ce qui est entrain d'tre construit,
comment il est construit et ce qu'il fait
suppose un processus de dveloppement logiciel
avec
une structure de gestion (milestones, schduling)
politique de rapport
processus de suivi
45
Trois principes gnraux de lAQL
Savoir ce que vous devriez faire
avoir des exigences et spcifications explicites
suppose un processus de dveloppement
logiciel avec
analyse des exigences,
tests d'acceptabilit,
feedback frquent des usagers
46
Trois principes gnraux de lAQL
Savoir mesurer la diffrence
avoir des mesures explicites comparant ce qui est entrain
d'tre fait de ce qui devrait tre fait
quatre mthodes complmentaires:
Mthodes formelles vrifier mathmatiquement des proprits
spcifies
Tests donnes explicites pour excuter le logicielle et vrifier si
les rsultats correspondent aux attentes
Inspections examen par humain des exigences, design, code,
... bass sur des check-lists
Mtriques mesures un ensemble connu de proprits lies la
qualit
47
Assurance Qualit du Logiciel
SQE comprend
Vrification
construisons nous le produit bien?
effectue la fin d'une phase pour
s'assurer que des besoins tablis
pendant la phase prcdente ont t
rpondus
Validation
construisons nous le bon produit?
effectue la fin du processus de
dveloppement pour assurer la
conformit aux exigences du produit
Exigences
Design
Architecture
Codage
Vrification
Vrification
Vrification
Vrification
Validation
48
Assurance Qualit du Logiciel
SQE comprend
Prvention de dfauts
Prviens la survenance de dfauts
Activits: formation, planification, simulation
Dtection de dfauts
Trouver des dfauts dans un artefact logiciel
Activits: inspections, test, mesure
Suppression de dfauts
isolation, correction, vrification de correction
Activits: isolation de fautes, analyse de fautes, test de
rgression
49
Assurance Qualit du Logiciel
Activits typiques de processus d'Assurance de la
Qualit Logicielle
Validation des exigences.
Vrification de Design.
Vrification statique de code (inspection/revues).
Test dynamique.
Ingnierie de processus et standards.
Mtriques et amlioration continue.
50
Dmarche dAssurance qualit (ISO)
51
Dmarche dassurance qualit
logiciel
LAQ est un ensemble de mesures et de techniques
structures spcifiques chaque type de Logiciel.

Il est indispensable de structurer ces pratiques dans une
dmarche logique afin datteindre lobjectif dun
processus dassurance qualit.
52
Dmarche assurance qualit (ISO)
Plan daction
tudes vis--vis des clients
tude de lentreprise
53
tude de lentreprise
Choix du rfrentiel
Choix du cycle de vie
Manuel et plan dassurance qualit
La gestion de projet
La gestion de configuration
54
Gestion de la configuration
Dfinir
Il sagit tablir et maintenir l'intgrit des produits de
projet logiciel pendant la dure du cycle de vie logiciel
du projet

principe :
identifier la configuration de logiciel un instant t
contrler les changements de configuration apports
assurer la traabilit tout au long du Cycle de vie
grer la livraison de la distribution du logiciel
55
tude vis--vis du client
Satisfaction du client
Trois caractristiques
Exigences
Besoins
Attentes

Faire une enqute


56
tude vis--vis du client
1. Satisfaction du client
Exigences
Besoins
Attentes
Faire une enqute
2. Respecter les dlais
3. Respecter les couts
57
Plan dactions
But :amliorer la qualit dans la conception de logiciel .
Comment: en agissant sur les diffrentes phases de
conception du logiciel

05/05/2014 58
Plan dassurance et de
contrle qualit
59
Manuel de qualit
activit principale la base d'une dmarche qualit
permet d'valuer rapidement le niveau de l'entreprise
rle interne : pour les employs
rle externe : auditeur, stagiaire...
doit permettre l'entreprise d'tablir une alliance entre
outils, les mthodes et l'assurance qualit.
60
Manuel de qualit
organis en 6 parties principales :
organisation de l'entreprise
activit de production et de contrle technique
activits de gestion
activits de contrle de qualit
plan type du plan qualit
lignes directrices pour le plan qualit
61
Manuel de qualit
exigences :
tre bien maintenu
Contrler son accs dt au "Know How" de l'entreprise
Servir toute l'entreprise
Formation l'assurance qualit
62
Plan dassurance et contrle qualit
Le plan d'assurance qualit est un
document nonant les pratiques, les
moyens et la squence des activits lies
la qualit spcifiques un produit, un
projet ou un contrat particulier
(ISO 8402:1994).
63
Plan dassurance et de contrle
qualit
Reprsente la mise en application du manuel de qualit
Rdig par les ralisateurs du projet logiciel
Permet d'obtenir des logiciels de qualit
Dcrit les moyens utiliss afin d'obtenir les logiciels de
qualit
64
PACQ : Plan type
but , domaine d'application et responsabilits
Documents applicables et documents de rfrence
Terminologie
Organisation
Dmarche de dveloppement
Documentation
Gestion de la configuration
Gestion des modifications
Mthodes, outils et rgles
Contrle des fournisseurs
65
PACQ
On s'appuie sur la dfinition, la stabilisation et la
documentation des activits de dveloppement des
produits, deux niveaux :

niveau rfrentiel : il s'agit des procdures, plans types et
guides mthodologiques communs la lorganisation .

niveau spcifique : il s'agit de l'application de ces procdures de
manire spcifique dans chaque projet ; ces dispositions font
l'objet d'un Plan d'Assurance et Contrle Qualit (PACQ) par
projet.
Le PACQ est un document rdig pour chaque projet. Il est spcifique au
projet considr. C'est un document contractuel entre le matre d'oeuvre et
la matrise d'ouvrage
66
PACQ : principe dlaboration
Le PACQ s'labore lors du dmarrage de la phase de
dveloppement du projet.

Rdig par :
Le correspondant qualit du projet
Le chef de projet
Responsable qualit.

doit rester un document synthtique renvoyant en tant
que :
de besoins aux procdures
guides mthodologiques du site de conduite de projet.
67
PACQ :principes dlaboration
valid par :
le chef de projet
le responsable qualit,

le PACQ peut tre diffus toutes les parties prenantes
Matrise d'ouvrage
Matrise d'uvre
quipes projets


Le PACQ peut tre remis jour chaque tape d'avancement du
projet. Dans ce cas, il sera soumis l'acceptation des interlocuteurs
les plus directement concerns.

Remarque : Citer un document applicable implique que le responsable qualit
contrlera son application pendant le projet.
68
PACQ: Objectifs du plan
Le plan d'assurance et contrle qualit vise
dcrire les dispositions prises pour obtenir la
qualit du logiciel dfinie en accord avec la
matrise d'ouvrage.

Ce PACQ dfinit :
Les mthodes,
L'organisation
Les activits d'assurance et de contrle de la qualit
spcifique au projet

69
PACQ: Objectifs du plan
L'utilisation du PACQ doit permettre:
Une rfrence commune tous les membres de
l'quipe projet. Il permettra d'assurer une bonne
cohrence et une homognit dans les mthodes de
travail.
Garantir la qualit du produit et des prestations. Cette
qualit s'exprime par des critres de qualit
respecter dans le cadre du projet.
dfinir les procdures suivre, les outils utiliser, les
normes respecter, la mthodologie de
dveloppement du produit et les contrles prvues
pour chaque activits.

70
PACQ: Domaine d'application
Identifie les systmes et logiciels concerns par le
PACQ. Il est spcifique chaque projet et son contenu
doit donc tre adapt en fonction du contexte.

En gnral :Les dispositions dcrites dans un PACQ
couvrent :
Les processus de dveloppement (depuis l'tablissement du
cahier des charges jusqu' la diffusion sur les sites utilisateurs)
Les fournitures (documentation interne au projet, documentation
utilisateur et application logicielle).


71
PACQ: Responsabilit de ralisation
et de suivi du plan
On y dfinie les responsabilits des diffrents acteurs
avec leurs rles (dfinition, rdaction, diffusion,
validation, mise en uvre et suivi du plan) et leurs
limites.

En gnral:
L'tablissement et les mises jour du plan ainsi que le
suivi de son application sont de la responsabilit du
responsable qualit projet. Il est assist dans cette tche
par la cellule qualit

La coordination des actions entreprendre pour la bonne
excution du plan relve de la responsabilit du chef de
projet
72
PACQ: Documents
Documents applicables :
documents dont l'application est impose et
vrifiable (ex : procdures, normes).
en fonction des projets
Documents de rfrence
Documents permettant d'effectuer le
dveloppement mais qui ne sont pas imposs
(ex : guides mthodologiques).
Adapt en fonction des projets.

73
Les mises jour du plan doivent tre justifies par
une amlioration des conditions de droulement du
projet ou de la qualit des fournitures.

La cellule qualit doit tre tenue au courant des
volutions.

Le responsable qualit du projet est charg des
mises jour du plan. Aprs validation par le chef de
projet, il sassure de sa diffusion auprs de lquipe
projet.

PACQ: Critres et procdure
d'volution
74
PACQ: autres composantes
Procdures de drogation (Exemple):
Les membres de l'quipe projet sont tenus de se conformer aux
dispositions dcrites dans le PACQ.

En cas de non-application de ces dispositions, une demande de
drogation doit tre faite auprs du chef de projet
Terminologie
Glossaire des termes
l'ensemble des termes communs au projet.
Abrviations


75
PACQ: autres composantes
Systme de qualit :
Objectifs et engagements qualit du projet
Mesure de la qualit (proprits et mtriques)
Documentation qualit du projet
Activits d'assurance et de contrle de la qualit
Documents relatifs la qualit du projet
Conduite de projet
Organisation du projet
Prsentation des activits couvertes par le projet
Planification et suivi du projet
Dmarche de dveloppement
Cycle de dveloppement
Description des tapes
76
PACQ: autres composantes
Gestion de la documentation
Identification de la documentation
Sauvegarde et archivage
gestion de la configuration
Responsabilits
Identification des lments
Cycle de vie et tats des lments
Sauvegarde et archivage
gestion des modifications
contrle des fournisseurs
Documents de liaison
Description des documents
05/05/2014 77
Qualit logiciel:
Rfrentiels et pratiques
BELASLA El Mehdi
78
valuation des processus projets:Contextes
Direction Qualit dans une SSII (certification ISO
9000)
Programme damlioration des dveloppements
logiciel dun grand groupe industriel (SW-CMM)
Programme damlioration des processus
logiciel chez un grand oprateur tlcom (ISO
15504-Spice)

79
Rfrentiels
ISO 9000
ISO 15504 (SPICE)
ISO 15408
ITIL
PMBOK
CMMI
80
Rfrentiels
ISO 9000 (International Organization for Standardization)
Modle dassurance qualit utilis pour la
certification des systmes de management de
la qualit.
Les normes de la famille ISO 9000 constituent
un ensemble de rfrences de qualit
incontest sur le plan mondial.
81
Rfrentiels
ISO 15504 (SPICE) Software Process Improvement Capability dEtermination
Norme pour lvaluation de processus logiciels, synthse
des dmarches d valuation et d amlioration de
processus logiciel : CMM, BootStrap, TRILLIUM, est
cohrente avec les normes existantes : ISO 9000, ISO
12207.

Applicable un large domaine d applications, daffaires,
de tailles dorganisation de projets.

Elle permet de comparer des entits semblables et elle
produit des profils de processus cots selon une chelle
six niveaux.
82
Rfrentiels
ISO 15408 remplace ITSEC (Information
Security Evaluation Criteria) dans le processus
dvaluation du niveau de scurit des logiciels
et systmes dinformation.

dfini les procdures et les mesures
techniques normalises prendre en compte
dans le cycle de vie dun produit logiciel.

83
Rfrentiels
ITIL (Information Technology Infrastructure Library)
recense, synthtise et dtaille les meilleures pratiques
(Best practices) pour la fourniture de services
informatiques.

ITIL donne des recommandations, des informations
dtailles sur les processus, des descriptions de postes,
des rgles de gestion.

ITIL couvre le domaine de la production informatique.

84
Rfrentiels
PMBOK (Project Management Body of Knowledge)

Rfrentiel des connaissances en gestion de projet
promu par le Project Management Institute (PMI).

Il dcrit des connaissances et des mthodes
applicables la majorit des projets, qu'ils soient
informatiques ou non, sur lesquelles il y a un
consensus gnral sur leur valeur et leur utilit.

Il donne un lexique commun et des mthodes de
communication.
05/05/2014 85
CMMI
Introduction et pratiques
86
Pourquoi CMMI ?
87
Les Origines du CMMI (1/3)
Audit du Departement Of Defense (DoD) command
par le Snat Amricain en 1980
Seulement 5% des projets se terminent dans les dlais et avec
la qualit demande.
Perte de matrise des projets pour les systmes (darmes) qui
dpendent du logiciel.

Cration en 1984 du SEI (Institut Software Engineering
Institute)
Watts Humphrey, ancien dIBM, sauveur du projet 360.
Dveloppement de logiciel bas sur des processus
matures.
Etude de plus de 1000 projets informatiques travers
le monde.

88
Les Origines du CMMI (2/3)
Sortie en 1991 de la 1
re
version du SW-CMM
(Capability Maturity Model for Software) (SEI-Mitre
Corporation).
Nouvelle version en 1993 (SW-CMM version 1.1).
Immense succs auprs des entreprises industriels.
Sortie de SE-CMM, SA-CMM, IPD-CMM, P-CMM etc.
SPICE(ISO) , SECAM(INCOSE) .
Besoin dintgration exprim par les professionnels.

Annonce de la sortie du CMM Integration (CMMI)
en 1998 (SEPG Chicago).
Raction ngative de la communaut.
Retard de 2 ans pris sur le projet.
Sortie du CMMI en 2000.

89
Les Origines du CMMI (3/3)
H
i
s
t
o
r
i
q
u
e

90
Cartographie des normes et mthodes de
qualit
91
2 demarches/ reprsentations
tage
5 niveaux de maturit
Par SW CMM
Continue
6 niveaux de capacit
Par EIA/IS 731 ISO 15504
92
2 dmarches

93
2 dmarches
94
Niveaux de maturit CMMI (reprsentation
tage)
Low Maturity
High Maturity
95
Niveaux de maturit CMMI

96
Niveaux de maturit CMMI

97
Niveaux de maturit CMMI

98
Niveaux de maturit CMMI

99
Niveaux de maturit CMMI

100
Domaines processus
Le domaine de processus constitue un ensemble de
pratiques connexes.

Les pratiques sont les actions accomplir pour atteindre
les objectifs d'un domaine traitement.

Ils sont les principaux lments de base dans
l'tablissement du processus de maturit d'une
organisation.

Chaque domaine de traitement rside dans un niveau de
maturit spcifiques
101
Niveau Incomplet : Les objectifs associs ce domaine
ne sont pas remplis.

Niveau Ralis : Les objectifs sont atteints, mais la
russite repose sur les individus.

Niveau Gr : Les objectifs sont remplis en suivant des
plans prtablis.

Le Niveau Dfini : politique de normalisation des
processus est mise en place au niveau de lorganisation.
La Reprsentation continue
102
La reprsentation continue
Le Niveau 4 dit Matris :
Des mesures sont effectues pour contrler les
processus et agir en cas de dviation par rapport aux
objectifs de lorganisation

Le Niveau 5 dit Optimis :
Les processus sont sans cesse remis en question afin
dtre toujours en adquation avec les objectifs de
lorganisation.
103
Comparatif
Reprsentations tage
Niveaux de maturit du CMM
Domaines processus sont affects aux
quatre parties suprieures de des cinq
niveaux de maturit (reproductible, Dfini ,
Encadr, Optimis)
Fournit une feuille de route pr-dfinie pour
l'amlioration organisationnelle
104
Comparatif
Reprsentation continue
Les niveaux de maturit sont remplacs par
des niveaux de capacit afin de mesurer
individuellement chaque domaine de
processus
Offre un maximum de souplesse pour que les
organisations qui choisissent d'insister sur les
processus d'amlioration.
105
Comparatif
Reprsentation Continue Reprsentation tage
Autorise une relle libert
dordonnancer les amliorations qui
correspondent le mieux aux
objectifs daffaire de lorganisation
et mitige les zones de risques.
Permet aux organisations davoir une
voie damlioration prdfinie et
prouve.
Permet une meilleure visibilit sur les
capacits acquises dans les
diffrents processus individuels.
Met laccent sur un groupe de
processus qui fournissent
lorganisation une capacit
spcifique caractrise par chaque
niveau de maturit.
Fournit une mesure des capacits
organisationnelles, utilise la
base dans un but damlioration, et
rarement communique lexterne.
Fournit une mesure de la maturit,
souvent utilise pour la gestion interne
de la communication, les
communications externes
lorganisation, et pendant les
contractualisations comme moyen
de qualifier les fournisseurs.
106
Comparatif (suite)
Permet de raliser des amliorations
sur les diffrents processus
diffrents niveaux.
Permet une synthse des processus
des rsultats damlioration
simples, une seule mesure de la
maturit.
Reflte une approche plus nouvelle
qui na pas encore dmontr ses
impacts sur le ROI.
Elabore un historique relativement
long
des pratiques, comprenant des tudes
des cas et des donnes qui ont
gnr un ROI.
Permet une migration plus aise de
SECM CMMI.
Permet une migration aise du logiciel
CMM au logiciel CMMI.
Permet une comparaison aise des
processus damlioration avec
ISO/IEC
15504, lorganisation des domaines de
processus dcoulant de 15504.
Permet une comparaison avec 15504,
cependant lorganisation des
domaines de processus ne
correspond pas celle
utilise pour ISO/IEC 15504.
Reprsentation Continue Reprsentation tage
107
Le CMMI rpond une organisation hirarchise
extrmement prcise afin de faciliter lvaluation de
lorganisation.

Ainsi on distingue par domaine de processus un
ensemble dobjectifs et de pratiques.



Organisation du modle
108
Organisation de la reprsentation tage
109
Organisation de la reprsentation continue
110
Les composantes du CMMI (25 domaines de
processus )
Sigles Process Areas Domaines de processus
CAR Causal Analysis and
Resolution
Analyse causale et rsolution
CM Configuration Management Gestion de configuration
DAR Decision Analysis and
Resolution
Analyse et prise de dcision
IPM for
IPPD
Integrated Project
Management
for IPPD
Gestion de projet intgre dans un
contexte IPPD
ISM Integrated Supplier
Management
Gestion de fournisseur intgre
IT Integrated Teaming Equipe intgre
MA Measurement and Analysis Mesure et analyse
OEI Organizational Environment
for Integration
Environnement organisationnel en
vue de l'intgration
111
Les composantes du CMMI (25 domaines de
processus )
Sigles Process Areas Domaines de processus
OID Organizational Innovation
and
Deployement
Innovation et dploiement
organisationnels
OPD Organizational Process
Definition
Dfinition du processus
organisationnel
OPF Organizational Process
Focus
Focalisation sur le processus
organisationnel
OPP Organizational Process
Performance
Performance du processus
organisationnel
OT Organizational Training Formation organisationnelle
PI Product Integration Intgration Produit
PMC Project Monitoring and
Control
Suivi et contrle de projet
112
Les composantes du CMMI (25 processus)
Sigles Process Areas Domaines de processus
PP Project Planning Planification de projet
PPQA Process and Product Quality
Assurance
Assurance qualit processus et
produit
QPM Quantitative Project
Management
Gestion de projet quantitative
RD Requirement Development Dveloppement des exigences
REQM Requirements Management Gestion des exigences
RSKM Risk Management Gestion du risque
SAM Supplier Agreement
Management
Gestion des ententes avec les
fournisseurs
TS Technical Solution Solution technique
VAL Validation Validation
VER Verification Vrification
113
Les Composants du CMMI
Les 25 domaines de processus du CMMI par catgorie
114
La porte
Au dbut de chaque chapitre dun domaine de
processus on trouve un petit paragraphe qui
explique brivement la porte et le but du domaine.

par exemple, dans le chapitre consacr au domaine
de gestion des exigences, les auteurs ont dbut
avec :
Lintention du domaine de processus Gestion des
exigences et de grer les exigences des produits et
composants de produits du projet et didentifier les
incohrences entre ces exigences et les plans et
produits de sortie du projet..
115
Exemple tir du CMMI de la porte du domaine de processus
PMC
116
Domaines lis
Le CMMI expose les rfrences qui
peuvent exister entre le domaine en
question et les autres domaines du
modle

Exemple : PMC fait rfrence deux autres domaines
de processus : Project Planning pour les
informations relatives au plan projet et Measurement
and Analysis pour les informations relatives au
processus de mesure et danalyse.
117
Domaines lis
118
Organisation dun niveau de maturit

119
Structure CMMI
Objectif (goal): Une atteinte de haut niveau des
rsultats atteindre par l'application efficace des
pratiques de groupe.

La notion d'objectifs dans le CMMI est la mme que
dans SW-CMM.

120
Les objectifs
On distingue deux types dobjectifs de domaine de
processus :
les objectifs spcifiques
les objectifs gnriques.

par exemple, dans le domaine suivi et contrle de
projet, les objectifs sont :
Suivre le projet au regard du plan.
Grer laction corrective jusqu terme.
Le processus de suivi et contrle de projet est
institutionnalis en tant que processus disciplin.
121
Exemple tir du CMMI des objectifs du domaine de processus PP
122
Les Pratiques
Pratiques - Une description dactions devrait tre
effectue en vue de raliser les objectifs d'un
processus.

Pratiques spcifiques - Ces processus diffrent selon
les domaines.

Pratiques gnriques- Ce sont des processus
communs dans tous les domaines

Pratiques gnrales soutenir l'objectif gnrique de
chaque domaine de services.
123
Les pratiques
Voici une exemple de la pratique GP2.1 (Generic
Practice 2.1) pour le domaine planification de projet :

PP-GP2.1 : tablir et maintenir une directive
organisationnelle traitant de la planification et de la
mise en uvre du processus de planification de
projet.
124
Les pratiques
125
Les produits de sortie typiques
Les produits de sortie constituent des documents
que lorganisation devra produire si elle souhaite
couvrir une pratique. La production de ces
documents matrialise la dmarche CMMI de
lorganisation.

Le contrle de lexistence des produits de sortie
constitue lune des premires tapes dune
valuation CMMI.


126
Exemple tir du CMMI des objectifs du domaine de processus PP
127
Autres composantes (les sous pratiques)
La grande majorit des pratiques du CMMI sont
dcomposes en sous pratiques.

Elles apportent des clefs supplmentaires dans la
comprhension et la juste interprtation des pratiques.

En effet, bien souvent le libell de la pratique nest
pas suffisamment explicite et son interprtation
peut tre diffrente selon les organisations. Les
sous pratiques vont ainsi diminuer le risque dune
interprtation errone.
128
Autres composantes (Les laborations)
Llaboration rente dans le cadre des pratiques
gnriques.

Elle a pour objectif de prciser les particularits de la
pratique gnrique lorsquelle est applique un
domaine de processus.

Les pratiques gnriques sont, par dfinition,
identiques dun domaine de processus un autre.
Cette gnricit nexclue le fait quil faille parfois
apporter certaines prcisions propres un domaine
129
Les points cls du CMMI par la pratique
Satisfaction des utilisateurs = Le respect des exigences
L'anticipation des problmes = Le pilotage par les
risques
La qualit des livrables = La stratgie de vrification

130
CMMI
Face aux autres modles
131
Liens troits entre
les modles du SEI
et ceux de ISO.

Des modles
souvent
complmentaires

Les modles la
mode : ITIL,
PMPBOK, COBIT
Dpendances entre le CMMI et les autres normes et modles
CMMI faces aux autres modles
132
CMMI et ISO 9001 version 2000
Dans le domaine du logiciel et des
systmes,lISO/IEC occupe une place prpondrante.

La publication de plusieurs rapport sur la
correspondance entre CMMI et ISO.
CMMI face aux autres modles
133
CMMI et ISO 9001 version 2000

CMMI face aux autres modles
134
SPICE / ISO IEC 15504
Le projet SPICE a t cre par lISO en 1993 dans le but initial de
dfinir une norme internationale d'valuation des processus logiciels.
Le projet ft par la suite redfini avec pour objectif de dfinir les
critres des mthodes dvaluation et des modles de pratiques.
Le SEI a mis disposition du projet SPICE plusieurs experts afin de
sassurer que le CMMI rponde lensemble des critres.
Le projet SPICE est aujourdhui arriv son terme et la norme
correspondante est la norme ISO IEC 15504 .
La norme dfinit deux grands axes dtude
le processus valu sur cinq thmes
la maturit value en cinq niveaux
CMMI face aux autres modles
135
La mthodologie Six Sigma a t dveloppe par Motorola en
1992.

Il sagit dune mthodologie et dune dmarche dinvestigation
structure, fonde sur lanalyse de donnes afin dliminer les
dfauts et les drives de tout processus.

L'objectif principal tant d'augmenter la rentabilit de
l'entreprise en rduisant le gaspillage.
Six Sigma
CMMI face aux autres modles
136
Le Six Sigma dfinit cinq phases appeles aussi DMAIC :
Define :Dfinir le primtre du projet, les attentes du client,le
fonctionnement dtaill du processus, la cible atteindre.
Measure : Mesurer suppose de dfinir les indicateurs de
performance (dlai, quantit de rebuts), les critres de mesure
mais aussi de dvelopper et tester la collecte des donnes de
mesure et tablir les valeurs de rfrence.
Analyse : Analyser les donnes de mesure pour isoler les causes
possibles de non qualit, tester les hypothses et au final identifier
les causes de non performance.
Improve : Choisir une solution alternative, la tester sur un primtre
restreint (pilote) et, si le rsultat est concluant, le mettre en uvre.
Control : Contrler la solution et documenter et suivre les
rsultats des mesures.
CMMI face aux autres modles
137
Correspondance entre les domaines de processus du CMMI et les phases du Six Sigma

CMMI face aux autres modles
138
ITIL
ITIL est ne dans les annes 80 au Royaume-Uni de la
volont de dfinir un ensemble de bonnes pratiques lies aux
technologies de linformation.
De grandes entreprises europennes ont expriment ITIL
durant les annes 90.
Il y a peu de temps les communauts CMMI et ITIL
signoraient totalement et trs peu dtudes sur la
complmentarit des deux modles ont t menes.
CMMI face aux autres modles
139
Exemple la socit Bouygues Tlcom qui mne cette
dmarche.
CMMI face aux autres modles
140
PMBOK
Le PMBOK, actuellement dans sa 3me version, est le
rfrentiel de bonnes pratiques en management de projet
dvelopp par le PMI depuis 2000.
Les similitudes entre le CMMI et le PMBOK sont
videntes.
Toutefois, on constate que la tendance actuelle est de
former les collaborateurs aux deux modles. Il nest donc
pas exclu qu lavenir les deux communauts tendent
se rapprocher davantage.
CMMI face aux autres modles
141
Le principal risque : La rsistance au changement
Soutien sans concession de la direction
Adhsion et participation dun maximum de collaborateurs
Une sensibilisation convaincante

Obligation de dfinir les besoins et les objectifs de
lorganisation
Dmarche damlioration itrative.
Dmarche adapte la stratgie, la culture et aux moyens

Le CMMI est un modle et non une mthodologie
Adapter le CMMI aux spcificits de lorganisation
Dfinir les mthodes et les outils mettre en uvre

Risques dune dmarche damlioration
142
La gestion des exigences
REQM
143
La gestion des exigences
Collecter TOUTES les exigences
Explicites
Implicites
Capitalisation via des check-list volutives
Valider la comprhension des exigences
Un rfrentiel partag

Tracer les exigences
Sur lensemble des livrables (spcifications, sources, cas de
tests, )
Niveau de couverture des livrables (individuellement)
Une analyse dimpact immdiate
144
Gestion des exigences
Cycle dun projet
No Dossier Libell Descriptif Origine Date Priorit Complexit
F-001
B0. IFI USA Mise disposition des formulaires IFI-USA
Description des f ormulaires IFI USA Runion de
spcif ication
Moyen 1-Trs simple
F-002
B1.Rpartition Standard Ajouter/modifier/supprimer des fors de rpartition
Description de la gestion des f ors de
rpartition et de leur initialisation, y compris
f or pour temps de sjour
Runion de
spcif ication
18.juin.04 Trs important 4-Complexe
F-003
B1.Rpartition Standard Localiser/qualifier des lments imposables
Ajouter des attributs permettant de qualif ier
les lments de la dclaration d'impt en vue
de leur intgration dans un calcul de
rpartition
Runion de
spcif ication
25.mai.04 Trs important 4-Complexe
F-004
B1.Rpartition Standard Traiter une rpartition indpendant
Description des crans et cinmatique de
traitement d'un rpartition indpendante
Runion de
spcif ication
03.juin.04 Important 3-Normale
F-005
B1.Rpartition Standard Traiter une rpartition pour activit dirigeante
Description des crans et cinmatique de
traitement d'un rpartition dirigeante
Runion de
spcif ication
02.juil.04 Important 3-Normale
F-006
B1.Rpartition Standard
Afficher l'impt communal par communes dans le calcul de
l'impt
Description de l'impact de la rpartition sur la
prvisualisation et l'impression du calcul de
l'impt
Runion de
spcif ication
29.juin.04 Important 3-Normale
F-007
B1.Rpartition Standard
Afficher les informations delatives la rpartition dans l'cran
de dtermination IFD
Description de l'impact de la rpartition dans
l'cran de synthse IFD
Runion de
spcif ication
29.juin.04 Important 3-Normale
Identification des exigences Nature des exigences
Dmarrage du projet :
Identification et catgorisation
des exigences -> dfinition et
priorisation des modules
danalyse.
No Dossier Statut Date Origine du statut Concept. Dtaille Version Maquette Front end Moteur Impressions Scnario de Test Version Xsd
F-001
B0. IFI USA
AC Validation de la maquette
X X X
F-002
B1.Rpartition Standard
AC 05.07.2004 Validation des specif ications TAOB_FONC_1_Rpa
rtition_Standard.doc
V1.0
X X X X
TAOB_FONC_TC_1_
Rpartition_Standard.
doc V1.0 X
F-003
B1.Rpartition Standard
AC 13.07.2004 Compte rendu de prsentation du
prototype
TAOB_FONC_1_Rpa
rtition_Standard.doc
V1.0
X X X
TAOB_FONC_TC_1_
Rpartition_Standard.
doc V1.0
F-004
B1.Rpartition Standard
AC 05.07.2004 Validation des specif ications TAOB_FONC_1_Rpa
rtition_Standard.doc
V1.0
X X X
TAOB_FONC_TC_1_
Rpartition_Standard.
doc V1.0
F-005
B1.Rpartition Standard
AC 05.07.2004 Validation des specif ications TAOB_FONC_1_Rpa
rtition_Standard.doc
V1.0
X X X X
TAOB_FONC_TC_1_
Rpartition_Standard.
doc V1.0
F-006
B1.Rpartition Standard
AC 05.07.2004 Validation des specif ications TAOB_FONC_1_Rpa
rtition_Standard.doc
V1.0
X X X X
TAOB_FONC_TC_1_
Rpartition_Standard.
doc V1.0 X
F-007
B1.Rpartition Standard
AC 05.07.2004 Validation des specif ications TAOB_FONC_1_Rpa
rtition_Standard.doc
V1.0
X X X X
TAOB_FONC_TC_1_
Rpartition_Standard.
doc V1.0 X
Identification des exigences Statut des exigences Client Livrables concerns
Demande de
changement :
Nouvelles exigences ou
modification dexigences
existantes suite aux sances
danalyses ou au tests
utilisateurs
Rfrentiel des exigences et matrice de
traabilit :
Rfrentiel de lensemble des exigences. Initialis
au dbut, il vit tout au long du cycle du projet.
Analyse de limpact
Utilisation des la matrice des exigences couple avec
la matrice de traabilit pour dterminer rapidement
limpact exact dun changement.
145
Gestion des exigences
Caractristiques des exigences dans le rfrentiel
Identification
Identifiant unique, catgorie, intitul
Priorit : pour faciliter les arbitrages lorsque cela est ncessaire
Complexit : qui donne une indication du risque de mise en uvre
Documentation
Description : texte descriptif de lexigence (Cahier des charges ou
reformulation)
Rponse : solution envisage pour rpondre lexigence
Validation : description de la mthode de vrification de lexigence
(exprimer les contraintes et/ou les conditions de test particulires)
tat ou statut
Analyse de lexigence : a t elle t ralise de manire plus
approfondie, est-elle stabilise ou valide ?
Indications sur lavancement des travaux danalyse (sur leur
aboutissement), et sur lanticipation possible des dveloppements
(si 80 % du rfrentiel est valid alors stable)
146
Gestion des exigences
Identification des exigences
Deux familles dexigences
Explicites
Elles sont lies au mtier de lutilisateur et souvent exprimes dans
les cahiers des charges.
Couvertes par la mise en uvre des mthodes danalyse Merise ou
Objet
Implicites
Pas exprimes directement car elles sortent du primtre mtier de
lutilisateur final
Elles ont trs souvent une forte incidence sur larchitecture du projet
Elles ne sont pas connues au dbut du projet, mais identifies
durant le travail de spcification
Pour faciliter lidentification, des outils sont proposs
comme support de lidentification
Une Check-list FURPS+ pour identifier les exigences implicites
Guide dentretien avec le client pour piloter les entretiens
danalyse
147
Gestion des exigences
Identification des exigences (FURPS+)
148
Gestion des exigences
Identification des exigences (FURPS+)
Check-list
Support des entretiens avec les utilisateurs
Pour chaque fonction, description de limpact et explication de la
contrainte
Exemple de questions poser et enregistrement de la rponse

Fonction / Contrainte Description de l'impact Question poser
P Performance (Performance)
P.1 Dlai d'indisponibilit Plus le dlai d'indisponibilit attendu est faible, plus
le systme de relance est sophistiqu et plus le
dlai de mise en oeuvre est important.
Quelles sont les attentes en terme d'indisponibilit
du systme suite une panne ?
P.2 Temps de rponse Plus les temps de rponses attendus sont faibles,
plus les dlais de mise en oeuvre sont importants.
Quelles sont les temps de rponses attendus pour
certains vnements, en particulier les interactions
avec les utilisateurs ?
S Facilit de support (Supportability)
S.1 Evolutivit Plus le systme est ouvert aux volutions, plus le
dlai de mise en oeuvre et les cots de
maintenance sont importants.
Y a-t-il des contraintes particulires sur l'volutivit
du systme ?
S.2 Compatibilit Plus le systme doit tre compatible, plus le dlai
de mise en oeuvre est important.
Le systme doit-il tre compatible avec ses
versions antrieures ou des systmes existants
offrant les mmes services ?
S.3 Paramtrage Plus le systme est configurable, plus le dlai de
mise en oeuvre et les cots de maintenance sont
importants.
Le produit sera-t-il configur aprs son dploiement
?
Comment le systme sera-t-il configur ?
S.4 Installation Plus l'installation du systme est simple, plus le
dlai de mise en oeuvre est important.
Y a-t-il des contraintes particulires pour
l'installation du systme ?
S.5 Maintenance Plus le systme doit tre maintenable, plus le dlai
de mise en uvre est important. C'est un
compromis entre le dlai de mise en uvre de la
premire version du systme et des versions
ultrieures.
Quelles sont les contraintes particulires en terme
de maintenance ?
149
Gestion des exigences
Traabilit
Garantir la couverture de la solution par rapport aux besoins
Matriser limpact des changements durant la vie du projet
Plusieurs axes dimpact couvrir
Traabilit transversale entre toutes les exigences
Exigences stratgiques vers les exigences fonctionnelles
Exigences fonctionnelles vers les exigences techniques

Traabilit bi-directionnelle vers les produits/livrables
Assurer que lexhaustivit des exigences est traite
Identifier dans un document lutilit de chaque paragraphe

Permet dvaluer rapidement limpact (dlai, primtre,
cot)
150
Gestion des exigences
Traabilit
Des spcifications jusquau code source.
No Dossier Statut Date Origine du statut Concept. Dtaille Version Maquette Front end Moteur Impressions Scnario de Test Version Xsd
F-001
B0. IFI USA
AC Validation de la maquette
X X X
F-002
B1.Rpartition Standard
AC 05.07.2004 Validation des specif ications TAOB_FONC_1_Rpa
rtition_Standard.doc
V1.0
X X X X
TAOB_FONC_TC_1_
Rpartition_Standard.
doc V1.0 X
F-003
B1.Rpartition Standard
AC 13.07.2004 Compte rendu de prsentation du
prototype
TAOB_FONC_1_Rpa
rtition_Standard.doc
V1.0
X X X
TAOB_FONC_TC_1_
Rpartition_Standard.
doc V1.0
F-004
B1.Rpartition Standard
AC 05.07.2004 Validation des specif ications TAOB_FONC_1_Rpa
rtition_Standard.doc
V1.0
X X X
TAOB_FONC_TC_1_
Rpartition_Standard.
doc V1.0
F-005
B1.Rpartition Standard
AC 05.07.2004 Validation des specif ications TAOB_FONC_1_Rpa
rtition_Standard.doc
V1.0
X X X X
TAOB_FONC_TC_1_
Rpartition_Standard.
doc V1.0
F-006
B1.Rpartition Standard
AC 05.07.2004 Validation des specif ications TAOB_FONC_1_Rpa
rtition_Standard.doc
V1.0
X X X X
TAOB_FONC_TC_1_
Rpartition_Standard.
doc V1.0 X
F-007
B1.Rpartition Standard
AC 05.07.2004 Validation des specif ications TAOB_FONC_1_Rpa
rtition_Standard.doc
V1.0
X X X X
TAOB_FONC_TC_1_
Rpartition_Standard.
doc V1.0 X
Identification des exigences Statut des exigences Client Livrables concerns
Matrice de traabilit
Spcification
Scnarii
de tests
Code
source
151
Gestion des exigences
Loutillage du rfrentiel Fichier Excel
Approche simple et rapide.
Mais basique et donc rserver aux petits projets.

Outils spcialiss (CaliberRM de Borland)
Hirarchisent les exigences
Exploitation plus facile les caractristiques des exigences
Pour lhistorisation,
Pour des tats statistiques
Mise disposition des graphiques danalyse dimpact
Peut devenir le rfrentiel documentaire du projet
Offre des fonctions supplmentaires :
Gestion des droits
Gestion dchange collaboratif (forum)

Adapt toute taille de projet, mais indispensable pour les
gros projets ou pour les projets multi-environnement
152
Gestion des exigences
Grer les changements
Les changements sont invitables dans le projet
volution de lorganisation, nouvelles contraintes (dlais, cot, )

Il est important den matriser lincidence sur le projet
Identifier les changements et les nouvelles exigences
Maintenir un historique des changements
Analyser leur impact sur le projet (dlai, cot,)
Dcider et accepter le changement
Sassurer de la prise en compte des changements valids

Mise en place dun processus avec des tapes claires
Support par un outils de gestion des changements
153
Gestion des exigences
Grer les changements
Outils de gestion des volutions et des anomalies
Enregistrement et qualification des demandes
Suivi des dcisions/rsolutions associes
154
Gestion des exigences
Synthse
Couvre tout le cycle du projet
Traduction des exigences en maquette
Traduction des exigences en cas de tests

Une matrise parfaite du besoin
Rfrentiel centralis dexigences
Maquettes
Scnario de tests

Pour une plus grande souplesse
Identification des changements au plus tt
Meilleure analyse de leur impact
Plus de rapidit dans la prise en compte de demande
155
Gestion des risques

156
Gestion des risques
157
Gestion des risques
(choisir les risques grer)

158
Gestion des risques

159
Stratgie de vrification

160
Stratgie de vrification

161
Retours dexpriences
162
Retours dexpriences

163
Retours dexpriences
(SEI)

164
Le site du SEI : http://www.sei.cmu.edu/cmmi/

Le site dinformation complmentaire du SEI :
http://seir.sei.cmu.edu/

Les documents virtuels du CMMI :
http://www.sei.cmu.edu/cmmi/models/models.html

Le livre de Richard Basque, en franais, sur le CMMI :
http://www.dunod.com/pages/ouvrages/ficheouvrage.asp?i
d=48308

Les groupes dutilisateurs SPIN du CMMI :
http://www.sei.cmu.edu/collaborating/spins/spins.html

Le groupe de discussion CMMI en franais :
http://groups.yahoo.com/group/cmmi_en_francais/

En Savoir plus sur le CMMI
165
CMMI : mise en pratique
166
CMMI : mettre en pratique
Les DSI/SSII grent dj les oprations
Cependant, lalignement sur CMMI de
lorganisation est un chantier de transformation
majeur
Lorientation bnfices mtiers est dvelopper
Ce chantier doit comporter un volet
daccompagnement au changement
Pour prenniser la mise en place des processus, il
faut sappuyer sur un outillage
167
Projet de mise en pratique : dmarche en 6 tapes

168
Mise en uvre 1/6
169
Mise en uvre 2/6
170
Mise en uvre 3/6

171
Mise en uvre 4/6

172
Mise en uvre 5/6

173
Mise en uvre 6/6

174
Quelques conseils
Identifier les faiblesses actuelles
Prendre de la comptence
Formation
Prestation externe
Communiquer
05/05/2014 175
Mtriques de la qualit
de logiciel
2008/2009
176
Facteurs de qualit (Rappel)

177
Mesure des facteurs de qualit
ci : coefficient de rgression
mi : mtrique affectant le facteur de qualit

178
Mtriques de qualit du logiciel
Mesure
indication quantitative de l'tendue, quantit, dimension, capacit ou
taille d'un attribut de produit ou processus
Mesurement
acte de dtermination d'une mesure

Mtrique (IEEE Std. 610.12)
mesure quantitative du degr avec lequel un systme, composant, ou
processus possde un attribut donn
peut lier des mesures individuelles
Indicateur
mtrique(s) donnant une indication sur le processus, projet, ou produit

179
Objectifs des mtriques de qualit du logiciel
1. Faciliter le contrle de la gestion, la planification et
l'intervention gestionnaire.
Bas sur:
Dviations de l'actuel de l'excution planifie.
Dviations du Schedule et de la performance relle de ce qui est
planifi.
2. Identifier les situations pour le dveloppement ou
l'amlioration du processus de maintenance (actions
prventives ou correctives).
Bas sur:
Accumulation de mtriques concernant la performance des quipes,
units, etc...
180
Types de Mtriques
Mtriques de Produit caractristiques de produit
complexit,
caractristique du design,

Mtriques de Processus pour amliorer le processus de
dveloppement
efficacit de suppression de dfauts,
temps de rponse de processus de correction

Mtriques de Projet caractristiques du projet et son
excution
pattern du personnel au cours du cycle de vie
productivit
181
Mesures de la taille (volume) du logiciel
KLOC mesure classique de la taille du logiciel en millier
de lignes de code.
problmes
dpendant du langage
dpendant du style de programmation
difficile prdire avant que le code ne soit produit

Nombre de points de fonctions (NFP) mesure des
ressources de dveloppement (ressources humaines)
requises pour dvelopper un logiciel, bas sur la
fonctionnalit requise du logiciel.

182
Mesures du nombre d'erreurs
Nombre d'erreurs du code (NCE) vs. nombre d'erreurs pondrs du
code (WCE).

183
Catgories des mtriques de qualit de
processus
Mtriques de qualit du processus logiciel
Mtriques de densit d'erreurs
Mtriques de svrit d'erreurs
Mtriques d'efficacit de suppression d'erreurs
Mtriques de cdule du processus logiciel
Mtriques d'efficacit de suppression d'erreurs du
processus logiciel
Mtriques du productivit du processus logiciel

184
Mtriques de densit d'erreurs
NCE = nombre total d'erreurs du code dtects par inspection de code et tests
NDE = nombre total d'erreurs de dveloppement (erreur de conception et code)
dtects pendant le processus de dveloppement.
WCE = nombre total d'erreurs pondrs du code dtects par inspection de code et
tests.
WDE = nombre total d'erreurs pondrs de dveloppement (erreur de conception et
code) dtects pendant le processus de dveloppement.
185
Mtriques de svrit d'erreurs
NCE = nombre total d'erreurs du code dtects par inspection de code et tests.
NDE = nombre total d'erreurs de dveloppement (erreur de conception et code)
dtects pendant le processus de dveloppement.
WCE = nombre total d'erreurs pondrs du code dtects par inspection de code et
tests.
WDE = nombre total d'erreurs pondrs de dveloppement (erreur de conception et
code) dtects pendant le processus de dveloppement.

186
Effectivit de la suppression d'erreurs
NDE = nombre total d'erreurs de dveloppement (erreur de conception et
code) dtects pendant le processus de dveloppement.
WDE = nombre total d'erreurs pondrs de dveloppement (erreur de
conception et code) dtects pendant le processus de dveloppement.
NYF = nombre de pannes dtectes pendant une anne de service de
maintenance.
WYF = nombre de pannes pondres dtectes pendant une anne de
service de maintenance.
187
Mtrique de cdule du logiciel
MSOT = Milestones complts temps.
MS = Nombre total de milestones.
TCDAM = Delais de completion total (jours, semaines, etc.) pour
tous les milestones.

188
Mtriques de productivit du
processus logiciel
DevH = Nombre total d'heures de travail investi dans le dveloppement du
logiciel.
ReKLOC = Nombre de millier de lignes de code rutiliss.
ReDoc = Nombre de pages de documentation rutiliss.
NDoc = Nombre de pages de documentation.

189
Mtriques de qualit de Produits
exemples
Rfrent la phase oprationnelle du logiciel (annes
d'usage oprationnelle par les clients) inclus
Service d'aide aux clients (HD)
Service de maintenance correctifs (Corrective maintenance
services)
Catgories de mtriques affectant la phase
oprationnelle du logiciel
Temps moyen entre pannes Mean time to failure (MTTF)
mesure du temps entre pannes
collection avec profiles usagers, scnarios, etc.
Densit de dfauts Defect density (defect rate)
nombre de dfauts relatifs la taille du logiciel
Problmes des Clients
Satisfaction des Clients

190
Catgories de mtriques de produits
Mtriques de qualit du HD:
mtriques de densit d'appels au HD mesurs par le nombre d'appels
mtriques de svrit des appels au HD la svrit des problmes
rapports au HD.
mtriques de succs du HD le niveau de succs dans la rponse des
appels au HD.
Mtriques de productivit du HD.
Mtriques de l'effectivit du HD.
Mtriques de maintenance corrective.
Mtriques de densit des pannes du systme logiciel
Mtriques de svrit des pannes du systme logiciel
Mtriques de panne des services de maintenance
Mtriques de disponibilit du systme logiciel
Mtriques de productivit et efficacit de la maintenance corrective.
191
Exemple:Problmes de Clients d'IBM
Rochester
Inclus
Dfauts valides
Problmes d'utilisabilit
Documentation non claire
Duplicata de dfauts valides
Erreurs d'usagers

PUM
Nombre total de problmes rapports par les clients sur une
priode donne/Nombre total de licences-mois du produit
pendant cette priode

192
Exemple: Satisfaction des Clients d'IBM
Rochester
Grce des sondages de clients ex de classification
Trs satisfait
Satisfait
Neutre
Insatisfait
Trs Insatisfait

Exemples de mtriques
Pourcentage de clients compltement satisfaits
Pourcentage de clients satisfaits (satisfaits et compltement satisfaits)
Pourcentage de clients insatisfaits (insatisfaits et compltement
insatisfaits)
Pourcentage de non satisfaits (neutres, insatisfaits et compltement
insatisfaits)
193
Mtriques de densit d'appels au HD
NHYC = nombre d'appels au HD pendant une anne de service.
KLMC = milliers de lignes de code maintenu.
WHYC = nombre pondr d'appels au HD pendant une anne de service.
NMFP = nombre de points de fonctions maintenir.

194

195

196

197

198

199

200

201

202
Mtriques de qualit du logiciel lies au
dveloppement
Mtriques utiliss pour valuer diffrentes
phases du dveloppement
mtriques de qualit de la spcification
mtriques de qualit du design
mtriques de qualit du code source

203
Mtriques de qualit de spcification
Pour valuer qualit de spcification des exigences et
modle d analyse

Exemple: mtriques de qualit de spcification de Davis
nf nombre d'exigences fonctionnelles
nnf nombre d'exigences non-fonctionnelles
nr nombre d'exigences = nf + nnf

Mtrique de spcificit d'exigences (lack of ambiguity)

Q1=nui /nr nui nombre d'exigences pour lesquelles tous les
reviewers ont la mme interprtation

Q2=nc /[nc+nnv ] nc nombre d'exigences valides
nnv nombre d'exigences non encore valides

204
Mtriques de modle du Design
Complexit structurelle et de donnes

Complexit structurelle (fanout)
S(m) = fout(m)

Complexit de donnes
D(m) = v(m)/[fout(m) + 1]
v(m) nombre de variables d'entres/sorties passes de/ m

Complexit du Systme
C(m) = S(m) + D(m)

indication sur complexit de l'architecture gnrale
utile pour valuation de l'effort d'intgration et de test

205
Mtriques de couplage de Dhama
Valeur de couplage gnrale d'un module
M=di+2ci+do+2co+gd+2gc+w+r

di nombre de paramtres donnes d'entre
ci nombre de paramtres de contrle d'entre
do nombre de paramtres donnes de sortie
co nombre de paramtres de contrle de sortie
gd nombre de variables globales utilises comme donnes
gc nombre de variables globales utilises pour contrle
w nombre de modules appels (fanout)
r nombre de modules appelantes (fanin)

206
Mtriques de Qualit OrientObjet
Rponse d'une Classe (RFC)
Nombre de mthodes locales + nombre de mthodes
appeles par celles ci
Nombre de mthodes pouvant tre invoqus directement
ou indirectement en rponse un message
Indique
complexit
effort de tests

207
Mtriques de Qualit Orient Objet
Profondeur de l'arbre d'hritage
Longueur max de classes la racine de l'arbre
d'hritage

208
Mtriques de Qualit Orient-Objet
Nombre de descendants
Nombre de sous-classes immdiates
Affecte la testabilit

209
Mtriques de Qualit Orient-Objet
Coupling Between Object Classes

CBO(C) nombre de classes distinctes utilisant
C + nombre de classes distinctes utilises par C