Le modèle de maturité CMM

Le modèle de maturité
CMM
Mise en œ uvre et risques
Cet article est la traduction d’un texte rédigé en anglais par Tracey Briscoe. Téléchargeable sur Internet, il
a été reproduit dans Forum Logiciel.net - supplément Hiver 1999 – revue diffusée de nos amis M@rtinig &
Associés – rue des Marronniers 25, CH-1800 Vevey - Suisse. Qu’ils se partagent nos remerciements pour
cette initiative !
Résumé
Aujourd’hui, de nombreux organismes s’efforcent d’améliorer leurs processus de développement de
logiciel et d’en mesurer les progrès.
L’un des standards de mesure de cette amélioration est le CMM (Capabilitiy Maturity Model)1 modèle de maturité applicable à tout organisme impliqué dans le développement de logiciel.
Rappelons que CMM a été défini par le Software Engineering Institute (SEI) de l’Université Carnegie
Mellon [1].
La documentation standard de CMM étant relativement complexe, cet article explique, de façon
informelle, la structure de ce modèle et signale quelques pièges à éviter lors de sa mise en œuvre.
Cet article est centré autour des niveaux 2 et 3, qui sont les deux premiers niveaux de maturité des
processus que de nombreux organismes cherchent à atteindre.
Un aperçu de CMM
CMM décrit 5 niveaux de maturité des processus.
• Le niveau 1 est le niveau le plus bas (aucune amélioration n’a encore commencé).
• Le niveau 5 est le plus élevé.
• Chaque niveau, supérieur au premier, porte son effort sur l’amélioration de quelques thèmes
majeurs.
• La majorité des organismes est actuellement au niveau 1.
• L’amélioration de la maturité d’un organisme se caractérise par :
• la réduction des délais de développement ;
• la réduction des coûts ;
• l’utilisation plus efficace des ressources.
Mise en évidence des apports de CMM
Les promesses de réduction des délais et des coûts de développement, d’utilisation plus efficace des
ressources, trouvent des échos très positifs chez les responsables. Pour cette raison, de nombreux
directeurs, ingénieurs et chefs de projet souhaiteraient emprunter le train du CMM.
1 Voir « La Lettre n° 22 » de janvier 1996 – Les 5 niveaux de CMM
Extrait de la Lettre d’ADELI N°38 – Janvier 2000
1
On affirme qu’une progression du niveau 1 au niveau 3 réduit les travaux de réfection de 60 % [2]. Les
organismes ayant atteint le niveau 3 de CMM afficheraient des gains de productivité de 200 à 300 %.
Lawrence Putnam de Quantitative Software Management [3] présente des témoignages qui montrent
que les économies attachées à l’atteinte du niveau 3 sont de l’ordre de 70 à 100 % par an.
Niveau
Délai
Charge
Défauts
Défauts
Coût total
mois.hommes
de maturité
en mois
trouvés
livrés
1
29,8
593,5
1348
61
$5 440 000
2
18,5
143,0
328
12
$1 311 000
3
15,2
79,5
182
7
$728 000
4
12,5
42,8
97
5
$392 000
5
9,0
16,0
37
1
$146 000
Impact estimé sur un projet de développement de logiciel de 200 000 lignes de code
(« Communique » Sematech)
Un article de Steven Burke [4] de 1997 de l’Université Carnegie Mellon annonce des taux
d’amélioration de 215 % sur les charges, de 592 % sur la planification, de 143 % sur la réduction des
erreurs, pour les organismes de niveau 5 par rapport à ceux de niveau 1.
Ces taux ne peuvent certainement pas s’appliquer dans tous les cas ; il est toujours bien délicat de
déclarer qu’un organisme a atteint le niveau 5. Burke souligne que le constat qualitatif d’améliorations
substantielles est plus important que les chiffres eux-mêmes (qui peuvent varier d’un organisme à
l’autre).
Les statistiques confirment les ordres de grandeur de ces tendances. Ainsi, la stagnation d’un
organisme au niveau 1 doit être considérée comme une situation génératrice de coûts. C’est pourquoi
CMM gagne en notoriété chaque année.
Structure de CMM
Les 5 niveaux de maturité
Les titres de ces 5 niveaux sont malheureusement peu significatifs ; nous les rappelons en les illustrant
d’une courte définition.
Initial – niveau 1
Il n'y a pas de méthode formelle, ni de cohérence, ni de standard, sur la base desquels les
systèmes seraient construits. Le processus de développement n'est pas maîtrisé, il n'y a pas de
volonté ferme de le gérer. Le succès dépend essentiellement des efforts individuels et des
compétences des développeurs. Les exigences de qualité, les plannings et les budgets sont en
général, difficilement respectés.
Répétitif– niveau 2
Il y a un consensus dans l'organisme sur la manière dont les choses doivent être gérées, mais
cela n'a été ni formalisé ni écrit. Un management de projet, fondé sur la réussite des projets
précédents, a été mis en place. Le processus de développement est stabilisé, sous le contrôle
d'une gestion rigoureuse des coûts et des délais.
Défini – niveau 3
Le processus de développement est formalisé, documenté et appliqué. Les revues sont menées
avec rigueur et les configurations sont convenablement gérées. Une structure Qualité &
Méthodes précise et met à jour régulièrement les procédures de l'organisme.
Extrait de la Lettre d’ADELI N°38 – Janvier 2000
2
Géré – niveau 4
L'organisme a institué un processus formel de collecte d'informations métriques pour suivre et
gérer son processus de développement ainsi que les systèmes résultants. Des indicateurs
contrôlent le bon déroulement des projets et le respect des objectifs de qualité.
Optimisé – niveau 5
L'organisme exploite les mesures pour optimiser en permanence son processus de
développement. L'organisme maîtrise un processus de correction des aspects qui seraient jugés
insuffisants, à la lecture des indicateurs.
Naturellement, tous les niveaux à partir du 2ème impliquent de définir avec précision et de gérer avec
rigueur les processus de l’organisme.
Les thèmes majeurs
Chaque niveau, à l’exception du niveau 1, implique des améliorations autour de plusieurs thèmes
majeurs.
Chaque thème majeur se décline en objectifs, décrivant les pratiques essentielles qui aident
l’organisme à atteindre le niveau CMM supérieur. Ces pratiques doivent devenir des règles admises,
solidement ancrées dans la culture de l’organisme, qui devront toujours être respectées, y compris en
temps de crise. Les pratiques CMM doivent être supportées par une infrastructure de directives,
d’outils, de formations et de standards. À défaut, toute amélioration visée par la mise en œuvre de
CMM ne sera, au mieux, que temporaire.
Succès de CMM
Pour accroître ses chances de succès, il faut appliquer les principes suivants.
• Impliquer toute la hiérarchie dans la mise en application.
• Définir les politiques relatives aux thèmes majeurs.
• Affecter des responsabilités pour applique les directives correspondantes à ces politiques.
• Allouer des ressources adéquates (encadrement, outils, et temps).
• Donner une formation suffisante.
• Se fixer des buts réalistes.
• Définir des mesures avant de commencer.
• Mesurer les contrôles, les processus et la qualité.
• Vérifier que les membres de l’équipe sont convenablement qualifiés et suivent les procédures
établies.
Niveau 1 CMM – Initial
Les organismes au niveau 1 (ce qui est le cas de 73 % d’entre eux) ne sont pas nécessairement
chaotiques ou sur le chemin du désastre. Certains semblent réussir convenablement, en termes de
profit, de part de marché, et de satisfaction du client. En effet, des organismes de niveau 1, de petite
taille ou qui peuvent décomposer leurs grands projets en petits ou qui disposent de compétences
qualifiées, conservent plus de chances de succès.
Un organisme demeuré au niveau 1 n’est donc pas systématiquement en situation d’échec, mais ses
projets sont moins prévisibles, nécessitent de nombreuses réfections, souffrent de plus de défauts, de
glissement de délais et de dépassement de coût.
De nombreux organismes de niveau 1 se débattent avec des produits de piètre qualité, des
dépassements de coûts, et des effectifs peu productifs. En 1996, le coût global des défaillances de
projets de systèmes d’information, aux États-Unis, était estimé à 145 milliards de dollars. 73 % des
projets sont abandonnés, en retard ou en dépassement de budget [6].
Dans les turbulences commerciales actuelles, des jeunes entreprises de niveau 1 connaissent une
croissance rapide. Mais les technologies évoluant rapidement, cette croissance génère des problèmes
d’organisation que la compétence et la bonne volonté des équipes ne suffisent plus à résoudre. Mettre
en œuvre de meilleurs processus devient alors une obligation vitale.
Extrait de la Lettre d’ADELI N°38 – Janvier 2000
3
Niveau 2 CMM – Répétitif
Un organisme qui décide de relever le défi CMM, commence par s’attaquer au niveau 2. Comme tout
projet, un projet CMM doit être soigneusement encadré. L’objectif du projet doit être réaliste et
planifié avec des jalons objectifs.
Les thèmes majeurs du niveau 2 « répétitif » s’intitulent :
• management des exigences ;
• planification des projets de logiciel ;
• suivi et supervision des projets de logiciel ;
• management de la sous-traitance du logiciel ;
• assurance qualité logiciel ;
• gestion de configuration du logiciel.
Le niveau 2 vise essentiellement les activités relatives à la planification, au management ; il trace les
améliorations relatives à ces thèmes majeurs. Il peut paraître surprenant que les tâches classiques
d’analyse, de conception, de codage, de test et de documentation, ne soient prises en compte que dans
un thème majeur « ingénierie du logiciel » du niveau supérieur (le niveau 3).
Marcher avant de courir
L’idée de sauter directement du niveau 1 au niveau 3 est une tentation fréquente. Bien qu’il soit
théoriquement possible de travailler très tôt sur les améliorations préconisées aux niveaux supérieurs,
les approches correspondantes rendraient l’amélioration globale plus difficile. Souvent, l’organisme
survole les véritables exigences du niveau 2 et se plonge dans l’ingénierie du logiciel, espérant ainsi se
dispenser de la planification des travaux du projet. Ce qui conduit à un dépassement des coûts, à un
mauvais cadrage, à des exigences incomplètes, et à des produits finals peu satisfaisants. Des plans
rigoureux de management du projet constituent un préalable indispensable à l’accueil de procédures
d’ingénierie informatique définies et documentées.
Lorsque l’organisme s’est hissé au niveau 2, des processus applicables à chaque projet individuel
peuvent être déployés. On peut alors mesurer l’efficacité des procédures d’ingénierie du logiciel, les
améliorer et les appliquer à l’ensemble de l’organisme.
Dans la plupart des cas, les chefs de projet auront tendance à suivre naturellement leurs penchants
habituels. Essayer d’introduire simultanément trop de changements dans un organisme n’est pas une
bonne idée. Ainsi, il est important d’essayer de resserrer la cible de la mise en œuvre CMM, en
s’obligeant à une mise en œuvre niveau par niveau.
Les outils et les métriques
La mesure est une exigence capitale à chaque niveau de maturité à partir du 2ème. Par exemple, au
niveau 2, l’organisme doit mesurer l’état de chaque exigence, la charge dépensée en activités de
management des exigences et stabilisation des exigences. Aux niveaux supérieurs de maturité, les
métriques doivent cadrer les progrès et mesurer l’efficience du processus.
CMM n’exige l’emploi d’aucun outil particulier. Il n’impose pas la façon de traiter un thème majeur.
CMM stipule seulement que les pratiques dans chaque thème doivent atteindre leurs objectifs. Un
organisme peut appliquer toute méthode et utiliser tout outil qu’il juge efficaces. Bien que CMM
n’impose aucun outil particulier, l’organisme visant le niveau 2 peut bénéficier grandement de
quelques-uns des outils du marché pour l’aider à automatiser ses pratiques, dans le cadre des thèmes
majeurs.
CMM Niveau 3 – Défini
Lors du passage du niveau 2 au niveau 3, ce sont les activités de management du logiciel, régies par
des processus standard documentés, qui constituent la cible des améliorations.
Tous les projets doivent utiliser une version documentée et approuvée des processus de l’organisme
pour le développement et la maintenance des logiciels.
Les thèmes majeurs pour le niveau 3 « défini » s’intitulent :
Extrait de la Lettre d’ADELI N°38 – Janvier 2000
4
• ciblage des processus de l’organisme ;
• définition des processus de l’organisme ;
• programme de formation ;
• management de l’intégration du logiciel ;
• ingénierie du logiciel ;
• coordination entre les groupes ;
• revues.
On croit souvent que le niveau 3 de CMM exige des pratiques spécifiques de développement du
logiciel, des outils et des méthodes. CMM ne stipule pas comment développer le logiciel ni comment
gérer l’entreprise. Il préconise seulement de suivre et de documenter les processus à appliquer et de
s’assurer que ces processus sont techniquement adaptés.
Les thèmes majeurs définissent des plages de performances qui doivent être satisfaites pour accéder au
niveau de maturité supérieur mais ils ne spécifient ni les méthodes, ni les techniques à utiliser. CMM
n’impose ni algorithmes d’estimations, ni ateliers de génie logiciel, ni méthodologies de
développement, ni standards. Pour s’installer au niveau 3, comme pour le niveau précédent, il est
nécessaire et suffisant de montrer que les pratiques relatives aux thèmes majeurs sont appliquées et
qu’elles atteignent leurs objectifs.
Thèmes majeurs du niveau 3
Le niveau 3 exige des processus standard communs à l’organisme. Ce qui ne signifie pas que chaque
projet, quelle que soit sa taille, doive se fondre dans un processus unique. L’un des thèmes majeurs de
niveau 3 « ciblage des processus de l’organisme » demande la coordination, la définition, la validation
et l’amélioration des processus standard.
On pense généralement que l’implantation d’un processus s’accompagne de bureaucratie et de
foisonnement de papiers. De meilleurs processus doivent permettre aux praticiens d’appliquer les
meilleures méthodes d’ingénierie de logiciel et de gestion de projet, d’une façon disciplinée, efficace
et répétitive.
Il existe plusieurs façons d’endiguer la bureaucratie :
• impliquer les contributeurs majeurs pour rédiger et réviser les processus ;
• rendre les processus adaptables à la taille des projets ;
• ne pas surcharger les petits projets simples avec des processus complexes ;
• utiliser CMM comme un guide pour inclure ce qui est nécessaire.
Si l’organisme décide d’utiliser une méthode commercialisée, il doit examiner sa complétude, son
adaptabilité et son adéquation à votre organisation. De nouvelles méthodes peuvent paraître plus
complexes qu’elles le sont réellement. Des petites différences dans la présentation peuvent gêner son
adoption, à moins d’obtenir des contributeurs majeurs qu’ils s’impliquent dans la création et la
révision de ces nouvelles approches.
Impliquer les contributeurs conduit au thème majeur suivant «Management de l’intégration du
logiciel». Ce thème majeur exige que le processus de développement d’un logiciel soit une version
dérivée du processus standard et que le projet suive ce processus. La formation et les outils sont des
facteurs cruciaux de succès.
Sans surprise, «le programme de formation» est le thème majeur suivant et se décline en trois
objectifs :
• planification de la formation ;
• déploiement des formations : gestion de projets informatiques et techniques préconisées ;
• formation des développeurs.
Les tâches standard d’ingénierie informatique : analyse, conception, codage, test et documentation,
sont toutes incluses dans l’un des thèmes majeurs de niveau 3, appelé «Ingénierie du logiciel». Il faut
s’assurer que :
• les tâches d’ingénierie informatique sont définies, intégrées et cohérentes pour produire le logiciel ;
• la modularité du logiciel est cohérente.
Extrait de la Lettre d’ADELI N°38 – Janvier 2000
5
Le niveau 3 traite du recueil des besoins des clients, de leur organisation et de la traçabilité de tous les
produits des activités d’ingénierie. Maîtriser le processus d’ingénierie des besoins, c’est assurer que
les objectifs de l’ingénierie de production du logiciel seront atteints.
La « Coordination entre les groupes » doit aussi être satisfaite. Les exigences du client sont pleinement
vérifiées et validées par tous les groupes affectés. Tous les problèmes et les engagements doivent être
identifiés, tracés et résolus.
Le rapport 1996 du Standish Group « Chaos » [6] cite les exigences relatives aux modifications
comme une raison majeure des échecs de projets. S’assurer que les exigences sont bien rédigées,
approuvées par toutes les parties prenantes et tracées tout au long du cycle de vie du projet montre que
l’organisme s’efforce d’atteindre le niveau CMM. Un outil peut simplifier cette activité, spécialement
dans les grands organismes aux prises avec des grands projets.
Le dernier thème majeur du niveau 3 est celui des «Revues». Le but des revues est de détecter les
défauts du logiciel par examen méthodique des produits. Il faut rédiger une instruction écrite pour le
déroulement des revues, la découverte de défauts et la formation. Les revues doivent être incluses dans
les plans de projet et les procédures doivent être documentées.
En résumé – quelques clés du succès
CMM n’est pas une recette rapide pour résoudre des problèmes immédiats. Mettre en œuvre CMM
prend du temps, pour intégrer de nouveaux processus, procédures, et, vraisemblablement, des outils. Il
convient, en effet :
• de constituer un groupe central d’experts pour guider la démarche et en assurer le succès ;
• de démarrer, en prenant peu de risques, sur des petits projets conduits par des bonnes compétences ;
• de communiquer, fréquemment et en temps voulu, les succès ;
• de s’assurer que la direction générale s’est engagée à maintenir son effort.
Il faut se rappeler qu’atteindre le niveau 2 prend de 18 à 30 mois. Soyons patients. Si les gens
perçoivent que ce nouvel effort n’est qu’une mode passagère, ils seront réticents à l’adopter. Ils
doivent être convaincus que la réussite de la mise en œuvre de CMM apportera un accroissement de la
productivité, une amélioration de la qualité et un renforcement de la motivation de l’équipe.
Références
1
2
3
4
5
6
« The Capability Maturité Model Guidelines for improving the software process » – Carnegie
Melon University, Software Engineering Institute.
Humphrey W. et al « Software process improvement at Hughes Aircraft » IEEE Software 8, 4
(juillet 1991) pages 11-23.
Putnam Lawrence « The economic value of moving up the SEI scale » Managing system
development, juillet 1994.
Burke Steven « Radical improvements require radical actions : simulating a high-maturity
software organization » - Carnegie Mellon University, Software Engineering Institute, juin 1997.
Hayes Zubrow « Moving on up : data and experience – Doing CMM based process
improvement » - Carnegie Mellon University, Software Engineering Institute.
Standish Group International - http://www.standishgroup.com, 1996
Version originale anglaise de Tracey Briscoe
Adaptation française par Alain Coulon
Secrétaire d’ADELI
Extrait de la Lettre d’ADELI N°38 – Janvier 2000
6