Le triangle de la qualité des logiciels: le personnel, le ...
Transcript of 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
Le triangle de la qualité
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
Carnegie Mellon University
Software Engineering Institute
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é
Carnegie Mellon University
Software Engineering Institute
7
13
Évolution de la maturité
Carnegie Mellon University
Software Engineering Institute
É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
Le triangle de la qualité
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
Le triangle de la qualité
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]