le triangle de la qualité des logiciels: le personnel, le

1

Le triangle de la qualité des logiciels: le personnel, le processus et le produit

Claude Y LaporteProfesseur

Département de génie électrique

2

Le développement des logiciels - les défis

2

3

Le triangle de la qualité

Personnes

Processus Produit

4

SWEBOK*

w Initiative de IEEE Computer Society

w Objectifsw Identifier le contenu du corpus des connaissances en

génie logiciel

w Fournir la base pour le développementw Programmes universitaires w Matériel de certification des individus

w Gestionnaires

* SWEBOK: Software Engineering Body of Knowledge

3

5

Commanditaires

6

Domaines de connaissance

w Analyse des exigences du logicielw Analyse de la qualité du logicielw Conception du logicielw Construction du logicielw Évolution et maintenance du logicielw Gestion de configuration du logiciel w Infrastructure du génie logiciel w Management du génie logiciel w Processus du génie logicielw Test du logiciel

4

7

Exemples de certification

w American Society for Quality– Certified Software Quality

Engineer

w Quality Assurance Institute– Certified Software Test Engineer – Certified Quality Analyst

w IEEE Computer Society– Certified Software Engineering

Professional

8


Personnes

Processus Produit

5

9

Le modèle d’évolution des capacitéslogiciel (CMM)

w Version 1.0 publiée en 1990

w Contient un ensemble minimal de pratiques éprouvées et recommandéesw Il définit les attentes (le « quoi »)

w Sans trop contraindre l’implantation (le « comment »)

w Le CMM propose aussi un cheminement pour la

mise en oeuvre des pratiques (‘Roadmap’)

10

Modèle de maturité - CMM

Carnegie Mellon University

Software Engineering Institute

Niveau Emphase5.D’optimisation

Qualité du produit et des processus

Gestion de projet

Secteurs clés

Héros

Gestion de configuration logiciel Assurance-qualité logiciel Gestion de la sous-traitance logiciel Suivi et supervision de projet logicielPlanification de projet logicielGestion des exigences

Revues par les pairs Coordination intergroupesIngénierie de produits logiciel Gestion logiciel intégréeProgramme de formationDéfinition du processus de l ’organisationFocalisation organisationnelle sur les processus

RisquesRisques

Gestion de la qualité logiciel Gestion quantitative de processus

Gestion des changements du processus Gestion des changements technologiquesPrévention des défauts

Processus en amélioration continue

Processus d’ingénierie

Productivitéet qualité

Productivitéet qualité

Résultats

1.Initial

2.Reproductible

3.Défini

4.Maîtrisé

6

11



Pays où des évaluations ont été effectuées et les données ont été transmises au SEI

12

Types d’organisations qui ont évalué leur niveau de maturité



7

13

Évolution de la maturité



Évaluations effectuées entre 1987 et 2001:

- 1799 évaluations- 1380 organisations- 7393 projets

1 2 3 4 5

14

0

5

10

15

20

25

30

35

40

45

Niveau de maturité

1 2 34

19881990

1992

41%

18%

11%

6%

% du budget du projet

19961994

5%

Coût pour refaire le travailDébut de l’amélioration

du processus logiciel

SEI (1995)

8

15

Réduction des défauts

1 23 41988

19901992

1994

0

5

10

15

20

25

30

1 23 4

Niveau de maturité

16

Estimés

.

0 %

140%

-140%

....

.

..

..

.

..

.

. .

. . . .

.

. . .

. .

.

.

. . . .. .. . . . . .... . . .. ..

. .. ..

.

.

.

. .. .. ...... . .. . ... . .. . .. .

.

Absence de donnée historique Avec données historiques

Écart de + 20% à - 145% Écart de - 20% à + 20%

(Effort = heure-personne)

Principalement niveaux 1 & 2 Niveau 3

Pourcentagesur- sous estimation

.

.. . .

.

.

. .

..

.

. .

..

..

. .

..

.. .. . .. . . . . .. . . . . .. .

... . .. . .

. . . .. . . .. . . . .

. . . . .. . . . .. . . . . .

. . . . .. . . . . .

. . . . . .. . . . . . . .

. . .. . . . .

. . . . .. . . .

. . . . . .

. . . . . .

. . . . . .

Données de 120 projets chez Boeing Information Systems

9

17

100%

98%

96%

94%

90%

88%

86%

84%

80%

88%

94%

97%

99%99%

95%

Version 1 Version 2 Version 3 Version 4 Version 5 Version 6

Temps

Données de 120 projets chez Boeing Information Systems

Gestion des défauts

Pourcentage du nombre de défauts détectés avant une livraison

18

Niveau CMM Qualité Cycle Dév ProductivitéDéfauts/MAELOC Relatif Relative

1 n/d 1.0 n/d2 890 3.2 1.03 411 2.7 0.84 205 5.0 2.35 126 7.8 2.8

Diaz, M., “How Software Process Improvement Helped Motorola”, IEEE Software Oct 1997.

10

19

L’agence de transport de New Yorkw Contrat de plusieurs centaines de millions $

– Octroyé à Bombardier Transport en mai 1999w Le Client exige l’atteinte du niveau de maturité 2

pour le maître-d’œuvre ainsi que pour une douzaine de fournisseurs– Le niveau 2 doit être atteint 24 mois après le début du

contrat– Le client a imposé 2 évaluations

• Une première en début de projet• Une seconde 24 mois plus tard pour confirmer l’atteinte du

niveau 2

– Un plan d’amélioration doit être développé, approuvé par le Client et mis-à-jour mensuellement

• Un spécialiste AQ vérifie les progrès sur une base régulière

Basque (2000)

20

Industrie des télécommunicationsw Société canadienne

w Actifs de 1,25 million de points de fonction (~ 12 millions de lignes de code)

w Utilisation du CMM - logiciel– Imposition au fournisseur d’un niveau X à

l’intérieur d’un temps donné

w Utilisation du modèle ‘Software-Acquisition CMM’ (SA-CMM)

– Amélioration des capacités de gestion du donneur d’ordre

11

21

Ministère des ressources naturelles du Québec

w Évaluation formelle du processus logiciel par

le Centre de génie logiciel appliqué (CGLA) en

mai 2000– Atteinte du niveau 2– ‘Ce projet est un des gestes les plusstructurants et significatifs que nous avons mis en chantier au cours desdernières années.’

Jacques Blouin, Directeur DSI

w Objectif: niveau 4

Allen (2000)

22

Caractéristiques d’un processus logiciel mature

w Documentéw Utilisé w Stabiliséw Instrumenté de points de mesures

– Un processus stabilisé produit des données fiablesw Géré à l’aide des mesures: qualité, délai et coûtw Instrumenté pour la détection et la correction des

défauts à chaque étape du processus – e.g. revue par les pairs

w Doté de pratiques de préventions de défautsw En amélioration constante

12

23


Personnes

Processus Produit

24

Exemple d’évaluation d’un produitw Société de télécommunications w Évaluation requise pour un achat logiciel

majeurw Pour être crédible, la démarche d’évaluation

doit être:– Répétable, reproductible, impartiale et objective

w Trois étapes de la démarche d’évaluation– Définir de façon formelle les besoins techniques et les

qualités attendus du produit logiciel.– Déterminer le niveau de criticité du logiciel

• 4 niveaux de criticité définis

– Bâtir le diagnostique sur des faits constatés et incontestables.

April (2001)

13

25

FIABILITFIABILITÉÉ

Rapport existant entre le

niveau de service d’un logiciel et la quantité de

ressources utilisées, dans des conditions déterminées.

PORTABILITPORTABILITÉÉAptitude du logiciel à être transféré d’un

environnement àl’autre.

Effort nécessaire pour diagnostiquer les

déficiences ou les causes de défaillance ou pour identifier les parties à

modifier.

MAINTENABILITMAINTENABILITÉÉ

Existence d’un ensemble de fonctions

et leurs propriétés données. Les fonctions sont celles qui satisfont

aux besoins exprimés et implicites pour des

tâches données.

CAPACAPACCITITÉÉ dedeFONCTFONCTIONNEMENTIONNEMENT

FACILFACILITITÉÉDD’’UTILUTILISATIONISATION

Effort nécessaire pour

l’utilisation et sur l’évaluation individuelle de cette utilisation par un

ensemble défini ou implicite d’utilisateurs.

Norme ISO/CEI 9126 –Qualité des produits

Aptitude du logiciel àmaintenir son niveau

de service dans des conditions précises et pendant une période

déterminée.RENDEMENTRENDEMENT

26

OBJECTIFS ATTEINTSOBJECTIFS VISÉS

MauvaisMoyenBonExcellent

CONFORMESUR QUALITÉ

Facilité d’analyseFacilité d’analyseFacilitéFacilité de modificationde modification

StabilitéStabilitéFacilitéFacilité de testde test

Facilité d’adaptationFacilité d’adaptationFacilitéFacilité de de l’installationl’installation

ConfConf. . règlesrègles de portagede portageInterchangeabilitéInterchangeabilité

ComporComportt. / Temps. / Temps

MaturitéMaturitéToléranceTolérance aux fautesaux fautes

PossibilitésPossibilités de de récupérationrécupération

AptitudeAptitudeExactitudeExactitude

IntéropérabilitéIntéropérabilitéConformité règlementaireConformité règlementaire

SécuritéSécurité

ComporComportt. / . / RessourcesRessources

FacilitéFacilité de de compréhensioncompréhensionFacilité d’apprentissageFacilité d’apprentissage

Facilité d’exploitationFacilité d’exploitation

Mauvais Moyen Bon Excellent

RISQUÉNON ACCEPTABLE

Évaluation d’un produit

April (2001)

14

27

Méthode d’évaluation de la qualité d’un logiciel

w Repose sur une définition de la qualité– ‘Minimization of the life-cycle risks of a

system’w Méthode indépendante de l’architecture,

d’un language ou d’un systèmew Évaluations effectuées à ce jour

– 100 systèmes– 51 millions lignes de code

Martin (1996)

28

Portabilité

Extensibilité

Maintainabilité

Descriptivité

Cohérence

Indé penda nceModularité

Documentation

Gestion d’anomaliesSimplicité de la conception

Auto-description

Éléments du modèle de qualité

Martin (1996)

Secteurs de qualité (4)

Facteurs de qualité (7)

Attributs de la qualité (76)

15

29

0102030405060708090

100

1 3 5 70

102030405060708090

100

1 3 5 70

102030405060708090

100

1 3 5 70

102030405060708090

100

1 3 5 7

Maintainabilité Extensibilité Portabilité Descriptivité

Profils de risque des secteurs de

qualité

Profils de risque

des facteurs de qualité 0

102030405060708090

100

1 3 5 70

102030405060708090

100

1 3 5 7

0102030405060708090

100

1 3 5 7

0102030405060708090

100

1 3 5 7

0102030405060708090

100

1 3 5 7

0102030405060708090

100

1 3 5 7

0102030405060708090

100

1 3 5 7

Cohérence Indépendance Modularité

Documentation Auto-description Gestion d’anomalies Simplicité de conception

Exemple de résultats d’évaluations de fournisseurs

Martin (1996)

30


Personnes

Processus Produits

16

31

Cheminement - une propositionw Atteindre un niveau 2 de maturité

– Rencontrer les échéanciers, budget et fonctionalités

w Planifier l’atteinte du niveau 3– Ajouter la réduction des défauts– ‘Accompagner’ ses fournisseurs (e.g. DoD)– Débuter la définition et la mesure des facteurs

de qualité• e.g. fiabilité, maintainabilité, portabilité, etc.

w Planifier le niveau 4– Rencontrer systématiquement les objectifs de

qualité, d’échéancier et de coût

32

Référencesw American Society for Quality-Canada

– http://www.asq.mb.ca/index.htm

w Quality Assurance Institute– http://www.qaiusa.com

w Modèle de maturité (CMM)– http://www.crim.ca/index.epl?selec=4131&href=/cgla/services/

processus/cmm.htm

w Données du profil de maturité– http://www.sei.cmu.edu/sema/profile.html

w Données de Raytheon– http://www.sei.cmu.edu/publications/documents/95.reports/95.t

r.017.html

w Données de Boeing– Vu, J., ‘Software Process Improvement Journey’, Actes: 8th

Software Engineering Process Group Conference, San Jose, Californie, mars 1997.

17

33

Références

w Basque, R., ‘Quand un secteur industriel se prend en main: y-a-t-il du logiciel dans le train ?’, Présentation au SPIN de Montréal, mars 2000.

w Corpus des connaissances en génie logiciel (SWEBOK)– http://www.swebok.org

w Allen et al, ‘Rapport d’analyse de risque et d’évaluation de processus’, Ministère des Ressouces Naturelles, Direction des services informatiques, mai 2000.

w April, A., ‘Batelco : Bilan technique qualité logiciel’, présentation à l’ETS, avril 2001.

w Martin, R., ‘Providing a Framework for Effective SoftwareQuality Assessment’, Actes: 6 th Annual Symposium of INCOSE, Juillet 1996.

34

Questions ???

Mes coordonnées:Téléphone: (514) 396-8956Courriel: [email protected]

le triangle de la qualité des logiciels: le personnel, le

Documents