Chapitre 4: Qualité logicielle

1
 Modèle de qualité orienté processus

 Modèle de qualité orienté produit

2
Modèle de qualité orienté processus

3
Introduction

 CMMI : Capability Maturity Model Integration,

 CMMI est un modèle d’évaluation et d’amélioration des

processus de développement et de maintenance
appliquées aux produits et aux services.

4
CMMI

•CMMi a été développé par le Software Engineering Institute (SEI) de l'université Carnegie
Mellon,

•Le SEI est un centre de recherche crée et financé par le Département de la Défense
US DoD.

•Initialement pour évaluer la qualité des services rendus par les fournisseurs de logiciels
du Département de la Défense US (DoD).

•Ce modèle est largement employé par les entreprises d'ingénierie logicielle.

5
CMMI
 Une approche centrée sur le processus.

 Processus: ensemble d'activités corrélées ou interactives

qui transforme des éléments d'entrée en éléments de
sortie [ISO 9000].

 Processus: Permet d’atteindre les objectifs stratégiques.

 La qualité d’un système ou d’un produit est fortement

influencée par la qualité du processus.

6
CMMI
 Une démarche d’amélioration évolutive

 Pour monter d’un niveau, il faut que toute l’organisation

maîtrise, et donc institutionnalise, l’ensemble des
domaines de processus associés au niveau supérieur.

7
 Niveaux de maturité CMMI (représentation étagée)

High Maturity

Low Maturity
8
L’évolution du CMMI

9
Source d’information : site internet SEI
10
11
12
Telnet: niveau de maturité 5
Standard CMMI Appraisal Method for
Process Improvement (SCAMPI)
TELNET a entrepris les
démarches de certification
CMMI depuis Octobre 2004 en
partenariat avec des organismes
indiens.
Telnet a été la première
entreprise en Afrique et Moyen-
Orient certifiée CMMi niveau 5.
Cette certification a offert à
Telnet un nouveau
positionnement à l'échelle
régionale et
internationale.[www.groupe-
telnet.com]
15
CMMI

16
17
18
 CMMI

 CMMI classifie les tâches (processus) que l’on doit accomplir pour réaliser un
projet, en 22 « domaines de processus » (Process Area).

19
Domaines de processus

Gestion •
•
Innovation et déploiement organisationnels (OID)
Définition du processus organisationnel (OPD)
de •
•
Focalisation sur le processus organisationnel (OPF)
Performance du processus organisationnel (OPP)
processus • Formation organisationnelle (OT)

• Gestion de configuration (CM)

• Assurance-qualité processus et produit (PPQA)
Support •
•
Mesure et analyse (MA)
Analyse causale et résolution (CAR)
• Analyse et prise de décision (DAR)
22 domaines de
• Planification de projet (PP)
processus
Gestion
• Surveillance et contrôle de projet (PMC) groupés dans 4
• Gestion des accords avec les fournisseurs (SAM)

de projet • Gestion de projet intégrée (IPM) catégories

• Gestion des risques (RSKM)
• Gestion de projet quantitative (QPM)

• Gestion des exigences (REQM)

• Développement des exigences (RD)

Ingénierie •
•
Solution technique (TS)
Intégration de produit (PI)
• Vérification (VER)
20 • Validation (VAL)
 CMMI

 Un domaine de processus (PA ou « Process Area ») constitue un ensemble de

pratiques liées dans un domaine qui, une fois mises en application collectivement,
satisfont à un ensemble d’objectifs considérés comme importants pour
l’amélioration de ce domaine.

21
CMMI

 La certification CMMi pour une organisation est le résultat

d'un audit conduit par un chef évaluateur, Lead Appraiser,
certifié par le SEI, qui déroulera sur des projets
sélectionnés pour leur représentativité au sein de
l’établissement la méthode officielle d'évaluation SCAMPI,
décrite sur le site du SEI.

 Certification du chef évaluateur: Pour obtenir cette

certification, vous devez être parrainé par une organisation
partenaire du CMMI Institute.

22
Comment se déroule une démarche
d'amélioration basée sur le modèle CMMI ?

 Pour réaliser cette évaluation de chacun des processus,

une équipe d’évaluation SCAMPI est formée.

 Cette équipe est composée :

 De membres de l'organisation qui sera évaluée
 De membres de société externe

 L’organisation doit choisir la société externe, certifiée par

le SEI, qui conduira l'évaluation.

23
L’évaluation et l’amélioration se déroulent en plusieurs phases :

- Evaluation initiale dans laquelle le niveau de maturité de l'organisation est

défini, qui débouche sur l'établissement d'un plan d'actions.
- Organisation de workshops constitués de membres d'équipe projets de
l'organisation afin d'implémenter les pratiques déclinées pour les projets (en
tenant compte du contexte et de l'existant).
-Accompagnement : Les pratiques définies dans les workshops sont déployées
dans les projets au travers de sessions de formation et de « coaching ».

- Evaluation « à blanc » : Ce sont des évaluations non officielles (exemple : mini-

check, GO/NOGO) qui permettent de donner un état des lieux des pratiques.
Elles donnent lieu à l'établissement d'un plan d'action, et donnent une idée de la
date d'évaluation officielle.
- Evaluation officielle : Collecte de preuves par l'équipe d'évaluation au sein des
projets de l'organisation (artefacts directs et indirects).
- Analyse des preuves collectées afin de déterminer les points forts et les points
faibles de l'organisation.
- Evaluation sur site : il s'agit essentiellement d'interviews.
- Cotation
24
et présentation des résultats, qui sont ensuite envoyés au SEI.
CMMI
 Cette évaluation finale est l'aboutissement du travail
d'amélioration: nous effectuons les prestations
d'évaluation initiale (savoir son niveau de départ) et
l'accompagnement du projet d'amélioration.

 Le résultat de l'évaluation initiale est une liste de forces

et de faiblesses destinée à entamer une démarche
d'amélioration.

 L’équipe d’évaluation donne un niveau de maturité à

l’organisation évaluée.

25
 Il existe 3 méthodes d'évaluation SCAMPI (Standard CMMI
Appraisal Method for Process Improvement) définies par le SEI :
méthodes A, B et C. La méthode A est la plus rigoureuse, et c'est la
seule qui autorise une cotation de niveau.

 Le modèle CMMI est longtemps demeuré l'apanage des entreprises

du domaine industriel (armement, aviation, transport,
télécommunication,…). Aujourd'hui, il s'étend largement au
domaine bancaire, à celui des assurances, et plus généralement aux
systèmes d'information.

 La limite de validité d'un niveau est passée aujourd'hui à 3 ans;

auparavant, il n'y avait pas de limite.

26
 CMMI

•CMMI est un cadre générique de processus qui se décline en 3 modèles :

•CMMI-DEV pour le développement de systèmes (logiciel ou autre,

modèle publié en août 2006)

•CMMI-ACQ pour la maîtrise des activités d'achat (modèle publié en

novembre 2007 )

•CMMI-SVC pour la fourniture de services (modèle publié en février 2009)

27
Pourquoi CMMI?

La démarche CMMI (Capability Maturity Model Integration ) est

un référentiel d'évaluation qui illustre:

- Capacité à gérer et terminer un projet correctement.

- Capable de répondre aux appels d’offre internationaux

- Capacité à respecter les cahiers des charges

28
CMMI: Un modèle, deux représentations

Étagée
Continue

29
 CMMI – Les représentations
• CMMI propose 1 modèle mais 2 représentations :
5

 Continue (env. 20%) 4

 La démarche de ce type de présentation 3

conduira à l’évaluation de chaque Capability
2 Level
processus indépendamment des autres
 On parlera de niveau d’aptitude 1

0
Process Process Process Process
area 1 area 2 area 3 area n

Optimizing

 Etagée (env.80%) Quantitativel

y defined
 Evaluation de façon globale de la maturité Managed
de l’entreprise en 5 niveaux
Defined
 On parlera de niveau de maturité
Initial
Niveaux de maturité

• NB : Dans la suite de la présentation, on ne parlera que de la représentation étagée sauf si spécifié

 CMMI - Structure

 La structure de chaque niveau de

maturité est simple et identique. On Niveau
distingue les composants suivants :
 Les niveaux au nombre de 5 Domaines
de processus
 Les domaines de processus
 Les objectifs généraux que l’on
retrouve dans tous les processus Objectifs Objectifs
 Les objectifs spécifiques propres génériques spécifiques Requis
à chaque processus
Pratiques Pratiques
 Les pratiques comportent une Attendues
génériques spécifiques
définition, des commentaires et
éventuellement des informations
Sous- Sous-
complémentaires (sous-pratiques) Pratiques Pratiques Informatifs
Exemple

Niveau 2
Niveau • PA : Gestion des exigences du client (REQM)
 SG : Les exigences sont gérées et les
Domaines incohérences avec les plans projet et les
de processus livrables prévus sont identifiées
 SP : Obtenir une compréhension
commune sur le sens des exigences
Objectifs Objectifs avec les fournisseurs de ces exigences
génériques spécifiques  Sub P : Établir des critères
objectifs pour l’acceptation des
Pratiques Pratiques
exigences
génériques spécifiques  Produit : Résultat de l’analyse des
exigences par rapport aux critères
 GG : Le processus (de gestion des
Sous- Sous-
Pratiques Pratiques
exigences) est géré
 GP : Une stratégie de mise en œuvre
est définie et permet de planifier et
d’exécuter le processus
33
Exemple: Domaine de Processus Analyse causale et résolution (CAR)

 SG: Specific Goal; SP: Specific Practice;

34
 Représentation Étagée

 Evaluation de façon globale de la maturité de l’entreprise en 5 niveaux. On

parlera de niveau de maturité.

 Chaque niveau est associé à la maîtrise de certains domaines de processus

 Incrémental: N avant N+1

 Permet de faire une comparaison entre organisations

35
 Représentation étagée

Pour un niveau ciblé, une organisation doit démontrer par une évaluation qu’elle couvre
entièrement les pratiques de ce palier et de tous les paliers inférieurs.
36
 Les niveaux de maturité: Niveau 1 - Initial
• Ce qui caractérise ce niveau : IN
OUT

 Pas de processus défini: Pas de formalisation du processus et pas de partage à

l’échelle du projet,

 La réussite du projet est tributaire de la compétence des acteurs du projet,

 Pas de planification,

 Pas de contrôle,

 Réactif et non prédictif,

 Pas d'enseignement tiré des difficultés ou des erreurs,

 Incapacité à reproduire les succès passés.

=> Processus non maîtrisé et imprévisible

37
 Les niveaux de maturité: Niveau 2 – Géré ou discipliné
IN
OUT

•Des pratiques de gestion de projet,

•Pour chaque projet:

Planification de phases


 Gestion des exigences

 Traçabilité des exigences:
 maîtriser les changements
 Les produits sont vérifiés par rapport aux exigences initiales

 Assurance qualité logiciel

 Processus documenté.
38
Les niveaux de maturité: Niveau 2 – Géré ou discipliné

• Ce qui caractérise ce niveau :

 Discipline dans les projets, bien que des variations subsistent entre projets
 Processus documenté
 Planification des travaux
 Prévisions, suivi et actions correctives
 Pas de compromis sur la qualité

• Conclusion
 La structure fonctionne au niveau projet
 Des pratiques de gestion de projet sont mises en œuvre
 Mais ce ne sont pas les mêmes dans les ≠ projets
 Bilan d’une évaluation SCAMPI
Exemple de résultat d’évaluation du Niveau 2
Chaque domaine de processus (PA) doit avoir la moyenne pour valider le niveau.
 Les niveaux de maturité: Niveau 3 – Défini
IN OUT

Standardisation des processus à l’échelle organisationnelle,

Un processus projet est une instanciation d’un processus organisationnel,

Mise en place d’un référentiel: un cadre commun pour toute l’organisation des
méthodes, outils et documents,

 Culture et compréhension communes

 Capitalisation systématique
 Enseignements tirés
 Réutilisation savoir-faire, code…

 Le chef de projet puise dans le référentiel en début de projet plutôt que de réinventer la
roue.

41
CMMI Niveau 3
 Le Référentiel organisationnel

42
Le niveau 3 présente une différence capitale avec le niveau 2:
 Les processus y sont décrits plus rigoureusement qu’au
niveau 2. Une description de processus ajusté énonce
clairement l’intention, les entrées, les activités, les rôles, les
mesures, les étapes de vérification.

43
 Niveau 4 Maîtrisé ou Géré quantitativement

IN OUT

 le processus est géré quantitativement: Le processus est mesuré,

 Objectifs quantitatifs,

 Le processus se comporte de façon prédictible

 Agir en cas de déviation par rapport aux objectifs

 Passage du Niveau 3 au Niveau 4 : de 18 à 24 Mois
44
 Niveau 4 Maîtrisé
IN OUT

ou Géré quantitativement
 Correction systématique en cas de dépassement des objectifs

• On va travailler sur la notion de productivité, de performance

des projets et non de l’organisation
• On va donc :
 Récupérer et comparer les statistiques de chaque projet. Pour cela, il faut
que les méthodes de calcul des statistiques soient les mêmes.
 Distinguer les causes normales et les causes spéciales de variation sachant
que le but est de corriger les causes spéciales.

 Un processus géré quantitativement est un processus niveau 3 contrôlé au

moyen de statistiques et d’autres techniques quantitatives (écart-type,
moyenne).
 Des objectifs quantitatifs de qualité et de réalisation de processus sont
fixés et employés comme critères dans la gestion du processus.
 IN OUT

Niveau 4
• Ce qui caractérise ce niveau :
 Métriques / Indicateurs mis en place et exploités
 Retours d’expérience possibles car processus cohérents
(les comparaisons ont un sens)
 Programme qualité
 Evaluation des impacts liés aux évolutions de processus

 Conclusion
 Le référentiel statistique sert à construire et piloter les projets
 Les niveaux de maturité: Niveau 5 Optimisé
IN OUT

 Amélioration continue du processus,

 Amélioration mesurable,
 Innovation organisationnelle
 Veille technologique
 Analyse des causes des problèmes
 On s’efforce de remonter du constat à la cause afin d’agir.

47
•La mise en place de ce niveau implique en plus de ce qui
est effectif au niveau inférieur :

 Prévention au lieu de correction des erreurs

 Processus toujours en amélioration

48
CMMI: deux représentations

Représentation continue Représentation étagée

 Réalisation des améliorations sur  Réalisation des améliorations

les différents processus à différents basées sur un étage prédéfini et
niveaux prouvé
 6 niveaux de capacité  5 niveaux de maturité
 Flexibilité  Benchmarking

 Les représentations différentes mais contenus similaires

 80% des organisations utilisent la représentation étagée
49
Quelles entreprises CMMI?
 Quelques chiffres
• IBM Australia : livraison des projets dans le budget initial passe de 90% à 100% en passant
du niveau 2 au niveau 5

• JP Morgan Chase (finance) : 70% de réduction du décalage moyen des dates de livraison
projet en atteignant le niveau 2, a doublé le nombre de livraisons par an en implémentant
le CMMI-3

• Siemens Information Systems : réduction de 45% des coûts de qualité pendant le passage
au CMMI-5, réduction de 20% du nombre de bugs avant tests

• DB Systems GmbH (IT) : coûts de développement réduits de 52% en passant au niveau 3

du CMMI

• Boeing Company : décalage de planning réduit de 63%, 3% d’augmentation de la

réutilisation de code et de matériel lors du passage du SW-CMM 4 au CMMI-5
Conclusion

•C’est un modèle qui a ses défenseurs et ses détracteurs. Il a

cependant le mérite d’inciter à :

 la capitalisation dans l’entreprise,

 la formalisation des processus.

•La réussite repose sur la compétence de l’entreprise toute

entière.
 Modèle de qualité de produit: Modèle
McCall

53
 Modèle de qualité de McCall

• Modèle d’évaluation de la qualité logicielle.

• Résultat d’une étude pour l’US air force en 1977.

• Modèle orienté produit.

• MacCall définit une approche de la qualité, à partir de la

définition de caractéristiques externes (facteurs de qualité),
internes (critères de qualité), mesurables (métriques).

54
Modèle de qualité de McCall

55
Modèle de qualité de McCall

• Facteur de qualité: décrit des caractéristiques externes,

• Critère de qualité: est un attribut qui affecte la satisfaction

d'un ou plusieurs facteurs. Il décrit des caractéristiques
internes,

• Métrique de qualité: décrit des caractéristiques

mesurables qui permettent de mesurer un critère.

56
Modèle de qualité de McCall

57
Modèle de qualité de McCall
Le modèle de qualité de McCall définit 11 facteurs:

 Correctness  Conformité
 Reliability  Fiabilité
 Efficiency  Efficacité
 Usability  Utilisabilité
 Integrity  Sécurité
 Maintenability  Maintenabilité
 Flexibility  Flexibilité
 Testability  Testabilité
 Portability  Portabilité
 Reusability  Réutilisabilité
 Interoperability  Inter-opérabilité
58
Modèle de qualité McCall

• Les caractéristiques opérationnelles

(product operation)

• La capacité d’évolution (product revision)

• La capacité d’adaptation (product

transition)
 Modèle Mc Call: Facteurs de qualité

Facteurs de qualité opérationnels

60
 Facteur de qualité: Conformité (correctness)

 Aptitude du logiciel à répondre aux besoins de l'utilisateur.

Besoin réel

Besoin perçu Besoin modélisé

61
Facteur de qualité: Conformité (correctness)

Critères de qualité:

Traçabilité

Consistance

Complétude

62
 Critères de qualité liés au facteur « Conformité »:

 Critère de qualité:Traçabilité

La capacité de décrire et de suivre la vie d'une exigence, dans les deux directions amont et avale
d’un projet.

Objectifs:

 Valider que les fonctionnalités du système répondent aux exigences,

 Analyser l’impact suite à un changement d’une exigence du client,
 Remonter aux causes de l’échec des tests fonctionnels. Réduire les risques de non-
atteinte des exigences

 Outils spécialisés: RequisitePro; TracMaker; SLATE; Marconi RTM; RTS;

Rtrace; …

63
Critère de qualité: Traçabilité

64
Exemple: Critère de qualité: Traçabilité

65
Critère de qualité: Traçabilité

66
Critères de qualité liés au facteur « Conformité »

 Critère de qualité: Consistance ou cohérence

Degré d’uniformité et Absence de contradictions dans

 la spécification: Un cahier des charges n'est pas consistant si deux spécifications

sont contradictoires. Le problème devient sensible à partir d'une certaine taille
du cahier des charges.

 la conception: cohérence syntaxique et sémantique entre les modèles

 e.g. inconsistance entre le diagramme de classe et le diagramme de séquence

 la documentation: Inadéquation de la documentation avec les phases qu’elle a la

charge de décrire.

67
Critères de qualité liés au facteur « Conformité »:

• Critère de qualité: Complétude

• La complétude est la qualité d'un logiciel de répondre entièrement aux besoins

des utilisateurs.
•NB. Parmi les objectifs des approches agiles

Besoin réel

Besoin perçu Besoin modélisé

68
• Facteur de qualité: fiabilité (Reliability)

 Accomplit sans défaillance l'ensemble des fonctionnalités

spécifiées, dans un environnement opérationnel de référence.

 Aptitudeà conserver un comportement conforme aux

besoins même dans des situations imprévues.

69
Critères de qualité liés au facteur « Fiabilité »

 Critère de qualité:Tolérance aux pannes ou Robustesse

 la capacité d'un logiciel de fonctionner même en étant handicapé
par la panne d'un composant (logiciel ou matériel).

Erreur provoquée par

le réalisateur - concepteur

Défaut

Panne
Fiabilité
du
logiciel

Erreur provoquée par

l'utilisateur Erreur d'utilisation

70
Critère de qualité: Tolérance aux pannes

 Erreur :
 Erreur commise par le développeur conduit à un défaut
 Erreur d’utilisation
 Défaut :
 imperfection dans le logiciel
 conduit ou non à une panne
 Panne :
 comportement anormal d'un programme
 Terme courant : bogue (bug)

71
 Critère de qualité: Tolérance aux pannes

 Dans le contexte des langages de programmation, un système de

gestion d'exceptions ou SGE permet de gérer les conditions
exceptionnelles pendant l'exécution du programme.

 Lorsqu'une exception se produit, l'exécution normale du programme

est interrompue et l'exception est traitée.

 Auparavant, une erreur de programmation pouvait facilement aboutir

à un plantage du programme voire de l'ordinateur.

 Les erreurs/exceptions les plus courantes sont probablement l'accès

non autorisé à une zone mémoire (erreur de manipulation de
pointeur) et la division par zéro (on ne prévoit pas le cas où le
diviseur
72
est nul).
 Critères de qualité liés au facteur « Fiabilité »

 Critère de qualité Consistance

 Le comportement du système et de son interface doivent être
cohérents et homogènes tout au long de l’utilisation du
système.

 Critère de qualité Précision: Les résultats sont proposés

conformément à la précision requise.

 Critère de qualité Simplicité: facilité de compréhension du

fonctionnement du système (simplicité du code et de la
conception) .
 Simplicité: afin de faciliter la détection et le correction des erreurs

73
 Facteur de qualité: Efficacité

 Minimisation de la consommation des ressources.

 Efficacité mémoire: consommation minimale de l ’espace mémoire.

 Efficacité en temps d’exécution: consommation minimale en temps
machine.

74
 Facteur de qualité: Utilisabilité

 L’utilisabilité est définie par [Nielsen, 1993], comme étant:

• Facilité de compréhension de l’usage du système: L’usage des commandes et

des fonctions doit être facile à comprendre.

• Facilité d’apprentissage (Mémorabilité): Les fonctions et les commandes du

système devraient être facile à se mémoriser (donc l’utilisateur n’aura
pas à les réapprendre quand il y retourne après un intervalle de temps)

• Facilité d’achèvement des buts d’usage (avec le moindre effort).

• Peu d’erreurs: Les utilisateurs devraient faire peu d’erreur lors de

l’utilisation du système et devraient être capable de rattraper ces erreurs
facilement.
75
 L'ergonomie est « l'étude scientifique de la relation entre
l'homme et ses moyens, méthodes et milieux de travail » et
l'application de ces connaissances à la conception de
systèmes « qui puissent être utilisés avec le maximum de
confort, de sécurité et d'efficacité par le plus grand nombre. »
SELF (Société d‘Ergonomie de Langue Française)

76
 Facteur Intégrité – Sécurité

• Capacité du logiciel à résister à des utilisations anormales comme

des altérations de code ou de données, ou leur accès par des
éléments extérieurs (personnes, programmes, etc ...).

• Critère: Contrôle d’accès

• Propriété d'un logiciel qui comporte des mécanismes permettant le contrôle
des accès.

• Aptitude du logiciel à surveiller, recenser, protéger les accès au code et aux

données ou fichiers.

77
 Les caractéristiques opérationnelles (product
operation)

 La capacité d’évolution (product revision)

 La capacité d’adaptation (product transition)

78
La capacité d’évolution (product revision)

• Maintenabilité
• Ensemble d'attributs portant sur l'effort nécessaire pour
comprendre et faire des modifications données :correctives ou
évolutives.
• Testability: Testabilité
• Effort requis pour le tester.
• Flexibilité: facilité à introduire des changements, une fois la
nature de ces changements a été déterminée.

79
 Les caractéristiques opérationnelles (product
operation)

 La capacité d’évolution (product revision)

 La capacité d’adaptation (product transition)

80
 Les facteurs du Modèle de McCall

• La capacité d’adaptation (product transition)

• Portability: Portabilité
• Effort requis pour utiliser le logiciel dans un autre environnement
logiciel et/ou matériel.

• Reusability: Réutilisabilité
• peut-on réutiliser des parties du logiciel dans d’autres
applications.

• Interoperabilty: Interopérabilité
• Capacité d’un logiciel à interagir avec d’autres systèmes.

81
 Facteurs-critères de qualité

 Facteur Maintenabilité:

 Consistance
 Simplicité: facilité de compréhension liée à l ’absence
d ’éléments superflus.
 Concision
 Modularité: décomposition d ’un logiciel en éléments de
taille réduite
 Auto-descriptivité (documentation interne)

82
 Facteurs-critères de qualité

 Facteur Flexibilité – Adaptabilité - Souplesse:

 Modularité
 Généralité: C’est l’aptitude de la solution à résoudre des
problèmes de portée plus large que le contexte particulier du
projet.
 Evolutivité
 Auto-descriptivité : documentation interne

83
 Facteurs-critères de qualité

 Facteur Testabilité:
 Les critères qui décrivent ce facteur sont:

 Instrumentation
 Auto-description
 Modularité
 Simplicité

84
Facteurs-critères de qualité

• Facteur Portabilité:
• Les critères qui décrivent ce facteur sont:

• Modularité
• Auto-description
• Indépendance matérielle
• Indépendance logicielle

85
Facteurs-critères de qualité

• Facteur Réutilisabilité:
• Les critères qui décrivent ce facteur sont:
• Généralité
• Modularité
• Auto-description
• Indépendance matérielle
• Indépendance logicielle

86
Facteurs-critères de qualité

• Facteur Interopérabilité:
• Les critères qui décrivent ce facteur sont:
• Modularité
• Données banalisées: basées sur les standards
• Communication banalisées

87
 Influence des facteurs de qualités les
uns sur les autres

 Exemple de facteurs qui diminuent l’efficacité:

 L’intégrité: nécessité d’introduire des vérifications.

 Maintenabilité: sacrifice de l’efficacité pour la lisibilité.

88
Mesures de qualité

89
Quelques métriques
Métriques de qualité du logiciel
 Définition selon le standard IEEE:

Mesure quantitative du degré avec lequel un système,

composant, ou processus possède un attribut donné.

91
 Mesures du produit logiciel

 Mesures de la taille (volume) du logiciel

 KLOC (Kilo Line Of Code, Soit 1000 lignes de code): mesure

classique de la taille du logiciel.
 Problèmes
 dépendant du langage
 dépendant du style de programmation
 difficile à prédire avant que le code ne soit produit

92
 Mesures de la complexité d’un logiciel
 La complexité d’un algorithme est le nombre d’opérations élémentaires (affectations,
comparaisons, opérations arithmétiques. . .) effectuées par un algorithme. Ce nombre
s’exprime en fonction de la taille n des données.

 Ce qui importe est l’ordre de grandeur de la complexité.

 constant, log n, linéaire, n*log n, n2, ...

• O(1): complexité constante (indépendante de la taille de la

donnée)
• O(log(n)): complexité logarithmique (exemple recherche
dichotomique)
• O(n): complexité linéaire
• O(np): complexité polynomiale
• O(nlog(n)) : complexité quasi-polynomiale
• O(2n): complexité exponentielle
• O(n!): complexité factorielle
93
Exemple de complexité

94
95
Mesures de l’utilisabilité d’un logiciel

Le calcul stochastique est l’étude des phénomènes aléatoires dépendant du temps.

96
Mesures logicielles
Mesures logicielles
Mesures logicielles

MTTF: Temps moyen de fonctionnement entre deux pannes.

MTTR: Temps moyen de réparation.
 Le standard ISO 9126 est inspiré du modèle MC CALL.

100
ISO 9126: Caractéristiques et Sous-
caractéristiques

101
ISO 9126: Caractéristiques et Sous-
caractéristiques

102