CMMi : maîtrisez enfin vos développements

CMMi est l’acronyme de Capability
Maturity Model Integration, tradui-
sons concrètement Modèle d’éva-
luation et d’évolution de la maturité
des processus de développement
logiciel [DMH2] dans l’entreprise. Ce
modèle s’est généralisé au dévelop-
pement des systèmes. Développé
par le SEI (1), il est une évolution du
CMM.
En 1985, le Ministère de la défense
des États-Unis (DoD) observait des
dérives de planning et de budget
des [DMH3] projets de développe-
ment logiciels. Le constat posé, le
DoD a demandé au SEI une
approche de l’évaluation des entre-
prises, dépassant la simple métho-
dologie de maîtrise des budgets. En
1993, la version 1.1 de CMM
(Capability Maturity Model) est
parue et a connu un franc succès au
sein de la communauté des déve-
loppeurs. Entre 1993 et 1998, de
nombreux « CMM » clones ont été
adaptés pour différents secteurs et
des organismes de normalisation
ont voulu intégrer l’approche
et certains ont été agrégés au
sein d’un unique modèle : le
CMMIntegration. La version actuelle
(CMMi version 1.1) date de 2002 et
dépasse largement l’activité du
développement système (logiciels
sur étagère, matériel et développe-
ments).
CMMi se focalise sur les processus plu-
tôt que sur les technologies ou les per-
sonnes car ils apportent une analyse
constructive [DMH4]. CMMi part d’un
principe simple que le travail des
hommes est plus efficace lorsqu’il est
organisé et les technologies appor-
tent les meilleurs bénéfices lors-
qu’elles sont insérées dans une
démarche plus globale à l’entre-
prise… encore fallait-il y penser
[DMH5] !
Le Modèle est construit sur une
vision, construite sur une étude des
bonnes pratiques et de leurs inter-
actions. Il [DMH6] comporte 25 pro-
cessus clés (Process Area) répartis en
5 niveaux (en fait 4 puisque le
niveau 1 correspond au niveau où
aucun processus est maîtrisé).
Chaque process area est composé :
– d’objectifs spécifiques : ils ne s’ap-
pliquent qu’au Process area. La
plupart d’entre eux correspondent
au niveau de capacité 1 [DMH7] :
leurs pratiques associées sont
appelées pratiques de base. Les
objectifs spécifiques correspon-
dant à un niveau supérieur à 1,
sont appelés pratiques avancées.
– d’objectifs génériques : à chaque
niveau de capacité (1 à 5) ne cor-
respond qu’un seul objectif géné-
rique, qui décrit l’institutionnalisa-
tion que l’organisation doit
atteindre pour parvenir à ce
niveau. Chacun est décliné dans
tous les secteurs de processus.
Chacun de ces « process area » peut
alors être évalué par un niveau de
maturité « Staged Maturity Levels »
Niveau 0 – Inachevé : un processus
inachevé est un processus qui n'est
pas exécuté ou ne l’est que partielle-
ment. Un (ou plusieurs) des objectifs
du secteur de processus n'est pas
satisfait.
Niveau 1 – Exécuté : un processus
du niveau de capacité 1 est caracté-
risé comme un « processus exécuté »
totalement. Il satisfait les objectifs
du secteur de processus correspon-
dant au niveau de capacité 1.
Niveau 2 – Géré : un processus géré
est exécuté (processus de niveau de
capacité 1), et est également suivi et
surveillé tout au long de son exécu-
tion. Son adhérence par rapport à sa
description est évaluée.
9
• La revue n° 80 - Septembre 2005
Conduite de projet dossier
CMMi : maîtrisez enfin vos développements ?
Par Daniel Mahé
et Didier Cohen
ASK Conseil
Depuis ces dernières années, les
référentiels de bonnes pratiques
ont le vent en poupe. COBIT pour
la stratégie et la gouvernance
d’ensemble dont l’AFAI est le pro-
moteur en France, ITIL pour les
opérations et les services et celui
qui nous intéresse CMMi pour
l’ingénierie et la conduite des
projets.
CMMi a été particulièrement
remis en selle avec la délocalisa-
tion des développements en Inde
et la nécessité de partager des
référentiels pour contractualiser
et piloter les projets.
(1) Software Engineering Institute créé par le Ministère de la Défense Américain (DoD).

Niveau 3 – Défini : un processus
défini est géré. Il est basé sur un pro-
cessus standard défini au niveau de
l’organisation, décrivant les élé-
ments de processus fondamentaux.
Niveau 4 – Géré, contrôlé : les pro-
cessus sont suivis et contrôlés tout
au long de leur exécution : des
mesures et des analyses sont effec-
tuées. Des critères de qualité et de
performance permettent d’évaluer
et de gérer les processus.
Niveau 5 – En optimisation : les pro-
cessus sont totalement maîtrisés et
l’organisation sait les optimiser ou
en améliorer des points.
Deux modes de représentation du
modèle existent : la représentation
continue (continuous) et la repré-
sentation étagée (staged).
Dans la représentation continue
(voir figure suivante), les secteurs
clés sont regroupés en quatre caté-
gories : gestion de processus, (5 pro-
cessus clés), gestion de projet, (8
processus clés), ingénierie (6 proces-
sus clés) et support (6 secteurs clés).
dossier :Conduite de projet
10
• La revue n° 80 - Septembre 2005
Level Project Management Engineering Support Process Management
5 CAR: Causal Analysis OID: Organizational
Optimizing & Resolution Innovation &
Deployment
4 QPM: Quantitative OPP: Organizational
Quantitatively Project Management Process Performance
Managed
IPM: Integrated RD: Requirements DAR: Decision Analysis OPF: Organizational
Project Management Development & Resolution Process Focus
3 RSKM: Risk Management TS: Technical Solution OEI: Organizational OPD: Organizational
Defined IT Integrated Teaming PI: Product Integration Environment Process Définition
ISM: Integrated VER: Verification for Integration OT: Organizational
Supplier Management VAL: Validation Training
PP: Project Planning REQM: Requirements MA: Measurement
PMC: Project Monitoring Management & Analysis
2 & Control PPQA: Process
Managed SAM: Supplier Agreement & Product
Management Quality Assurance
CM: Configuration
Management
1
Initial
Dans la représentation étagée, c’est
un niveau global de maturité de l’or-
ganisation qui va être évalué, et non
pas un niveau par processus clé. Les
25 processus clés (process area) sont
regroupés par niveaux de maturité
sur une échelle de 1 à 5, comprenant
chacun respectivement 0,7,14,2 et 2
processus clés.
Les 4 composantes du modèle :
– Ingénierie logicielle CMMi®-SW :
ce composant couvre le dévelop-
pement des systèmes logiciels à
savoir : développement, déploie-
ment et maintenance en suivant
des approches systématiques,
strictes et quantifiables.
– Ingénierie des systèmes [DMH8]
CMMi®-SE/SW : Elle couvre le
développement des systèmes
dans leur globalité, qu’ils incluent
ou non du logiciel, en se concen-
trant sur les besoins et attentes du
client, et sur les contraintes liées à
la solution adoptée.
–Développement intégré des pro-
duits et processus CMMi®-
SE/SW/IPPD : L’IPPD est une
approche systématique qui
cherche à établir une collaboration
entre les contributeurs du projet,
afin de répondre au mieux aux
besoins, aux attentes et aux exi-
gences du client. Les processus
soutenant une approche IPPD sont
intégrés avec les autres processus
de l'organisation. Ce composant
est choisi par une organisation uni-
quement en complément d’autres
composants.
– Sourcing fournisseur CMMi®-
SE/SW/IPPS/SS : Lorsque le travail
devient complexe, les projets peu-
vent nécessiter des ressources
externes pour exécuter certaines
fonctions,ou pour modifier les pro-
duits. Quand ces activités ont une
importance critique, il peut être
intéressant au projet d’analyser et
de surveiller les activités du four-
nisseur avant la livraison de pro-
duits. C’est ce type de tâches que
couvre le sourcing fournisseur.
L’intérêt de ce composant est à
mettre en relation directe avec le
développement actuel de la sous-
traitance dans le domaine de l’in-
formatique, en particulier avec les
pays d’Asie (Offshore) où l’on trouve
un nombre d’entreprises certifiées
CMMi niveaux 3, 4 et 5 assez
impressionnant au regard de la
maturité de ces organisations
somme toutes récentes.

Ce référentiel ne peut pas [DMH9]
devenir LA méthode à employer
mais de réduire les risques d’inadé-
quation avec le besoin et de produire
des solutions à valeur ajoutée dès
que possible.
Le bon côté de la vision « normalisée »
proposée dans le CMMi est que,quel
que soit le niveau de maturité de
l’activité de réalisation de logiciels
dans l’entreprise, CMMi permettra
de :
– donner une structure aux proces-
sus actuels,
– d’aider à la gestion de la complexité
des développements,
– donner des gisements d’efficience
aux processus concernés.
Est-il utile de dire que la mise en
place d’une démarche de mise en
œuvre du CMMi [DMH10] dans une
organisation est une démarche
d’entreprise avec ses facteurs de
succès désormais classiques : spon-
sorship du management, implica-
tion du chef de projet et des équipes
opérationnelles, suivi et évaluations
régulières, formation…
Apports
De manière générale, les bénéfices
de la mise en place d’une démarche
d’amélioration des processus sont
indéniables. Le simple fait de se
demander, pour chaque pratique de
l’organisation, si elle est justifiée et
optimale constitue une source de
gisements de gains dont l’entreprise
n’a pas idée tant qu’elle ne s’est pas
lancée dans la démarche.
Le seul fait de remettre à plat tout le
processus de développement néces-
site un formalisme et une rigueur
qui doivent permettre d’en avoir
une meilleure vision. CMMi apporte
ce formalisme et cette rigueur avec
en plus l’utilisation d’un langage
commun à toute l’entreprise et
même à l’extérieur de l’entreprise.
Ensuite, la mise en adéquation de ce
processus avec les pratiques clés de
CMMi doit aboutir à une maîtrise
accrue des coûts, des délais et de la
qualité des produits.Cela dépend du
« sérieux » avec lequel les nouvelles
méthodes seront appliquées.
Cette rationalisation du processus
de développement doit augmenter
la confiance des clients,sensibles à la
diminution des risques qu’ils encou-
rent.
Un des volets importants de la
démarche concerne alors la commu-
nication : en interne pour la mise en
place et vers l’extérieur comme
avantage concurrentiel potentiel.
Les risques du CMMi
Le premier risque est de croire que
plus les processus sont matures au
sens CMMi, moins la dépendance de
l’entreprise aux hommes (et aux
technologies) est faible. Les risques
les plus courants sont présents dans :
– la déresponsabilisation des acteurs
sur le plan de la réussite globale
des projets,
– la baisse de la motivation,
– la baisse de la créativité.
L’approche processus peut se révé-
ler un peu trop restrictive et se foca-
liser sur les compétences néces-
saires ou les technologies réelle-
ment productives et opérationnelles
peut aussi amener une entreprise à
une meilleure qualité de résultat.
Le second risque est de trop
complexifier la démarche et de la
transformer en coquille vide : certes
l’entreprise aura des procédures
claires et formalisées mais en contre-
partie, elles ne seront pas toutes sui-
vies. Rappelons que des auto-éva-
luations doivent être coachées par
des auditeurs « agréés [DMH11] »
par le SEI et que généralement des
audits internes sont mis en place
dans les structures de taille impor-
tante. La méthode itérative en par-
tant de processus simples et proches
de la situation actuelle reste encore
le meilleur moyen d’introduire cette
démarche.
Le risque habituel à toute tentative
de changement communément
appelée la sacro-sainte résistance au
changement n’échappe évidem-
ment pas à CMMi. Si le soutien de la
direction est incontestablement
nécessaire, l’appui et la participation
d’un maximum de collaborateurs au
processus d’amélioration sont indis-
pensables.
Enfin, gardons à l’esprit que CMMi
n’est pas une méthodologie,mais un
modèle :il décrit ce qu’il faut réaliser,
mais il ne dit pas (explicitement)
comment le faire. CMMi n’est pas
une solution miracle qui résoudra
tous vos problèmes : c’est à chaque
organisation de définir les méthodes
et outils à mettre en place de façon à
satisfaire les critères.
Pour les adeptes des normes :
les alternatives à CMMi
Six Sigma : Contrôle de la qualité
basé sur l’étude d’indicateurs de
variation. Les objectifs principaux
sont la diminution des rebus, l’amé-
lioration de la production, la diminu-
tion des niveaux de stock. Au départ
peu orientée vers la réalisation de
logiciels la transposition de cette
démarche de fabrication de produits
se révèle pourtant dans certains cas
une alternative intéressante.
ISO 9000 est destinée à aider les
organisations à mettre en place de
manière efficace un système qualité.
Cette norme et les modèles
CMM/CMMi sont donc complémen-
taires [DMH12] :les normes ISO 9000
traitent plutôt des processus du sys-
tème qualité dans leur globalité, en
fixant les fondamentaux d’une
démarche qualité, alors que les
modèles du SEI s’attachent aux pro-
cessus de développement de façon
plus concrète.
ISO SPICE (Software Process
Improvement Capability dEter-
mination) est un projet qui a débuté
en 1991 par une étude préliminaire
(ISO SC7) avec comme objectif
d’aboutir aux spécifications d'un
standard international en matière
d’amélioration des processus de
développement logiciel.
11
• La revue n° 80 - Septembre 2005
Conduite de projet dossier

Ce programme de travail fut approuvé
en 1993 (par ISO/IEC JTC1), et donna
lieu à une succession de versions :
une première en 1995, une seconde
en 1996, et la version finale, en 1998,
correspondant à la norme ISO 15504.
Le référentiel ISO/SPICE propose un
modèle de management de proces-
sus, ainsi qu'un ensemble d'exi-
gences et de méthodes concernant
l'évaluation et l'amélioration de ces
processus. Le modèle est composé
de la façon suivante :
– une dimension processus, qui iden-
tifie une quarantaine d'activités,
réparties en cinq catégories :
• client/fournisseur,
• engineering,
• projet,
• support,
• organisation.
Une catégorie supplémentaire sera
intégrée dans la prochaine version,
prévue pour 2003/2004 : Processus
d’acquisition.
– une dimension capacité (ou apti-
tude), qui propose des modalités
génériques de mise en œuvre et
de management de ces processus,
selon une hiérarchie décrite en
termes de niveaux de capacité.
Le modèle évalue les procédés des
organisations en matière de déve-
loppement logiciel et détermine
leur niveau de maturité.Les résultats
obtenus permettent d’orienter le
processus d'amélioration.
En fait,le projet SPICE s’est inspiré du
CMM développé plus tôt et composé
de 18 secteurs de processus clés, et
de 5 niveaux de maturité.
SPICE propose ainsi une structure
très proche de celle de la représen-
tation continue du CMMi. Il subsiste
cependant un certain nombre de
différences :
– CMMi dispose de quatre groupes
de processus dans sa représenta-
tion continue (processus, projet,
opérationnel, support), alors que
SPICE en a cinq.
– Deux architectures sont dispo-
nibles pour le CMMi (étagée et
continue), une seule pour SPICE.
– Quatre versions différentes pour
CMMi (SW, SE/SW, SE/SW/IPPD,
SE/SW/IPPS/SS) et une seule pour
SPICE (SW).
Depuis quelques années, la tendance
de SPICE est de se définir comme un
méta modèle, c'est-à-dire une réfé-
rence à laquelle des modèles tels
que CMMi devront se référer.
CMMi et méthodologies modernes
de réalisation des logiciels (Agile)
CMMi peut se révéler trop bureau-
cratique par rapport à de telles
méthodologies ou client et dévelop-
peur sont côtes à côtes. Cependant
si le CMMi est interprété et déployé
de façon appropriée, la « compatibi-
lité » des deux approches peut être
intéressante. Trois points conci-
liables :
– L’approche a priori linéaire des
développements de CMMi et l’ap-
proche incrémentale des métho-
dologies « Agile ».
– La complexité de CMMi laisse pen-
ser que ce référentiel n’est adapté
qu’à des grandes organisations ou
à des grands projets. Cependant
(comme pour les normes ISO), le
référentiel peut se déployer sur
des entreprises de toute taille.
– L’aspect documentation est sans
doute celui qui différencie le plus
des méthodologies Agile (comme
eXtreme Programming), qui réduit
à son stricte minimum la docu-
mentation et CMMi qui tend à
créer des documents et procé-
dures dont une grande partie est
souvent inexploitée (les WOD
Write Only Documents).
Pour en savoir plus…
Le site du SEI, fondateur de CMMi :
http://www.sei.cmu.edu/cmmi/
Le site de l’AFAI (article sur les réfé-
rentiels) :
http://www.afai.fr/article.php3?id_article=224
dossier :Conduite de projet
12
• La revue n° 80 - Septembre 2005