CMMi : maîtrisez enfin vos développements

Conduite de projet dossier
CMMi : maîtrisez enfin vos développements ?
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éveloppement logiciels. Le constat posé, le
DoD a demandé au SEI une
approche de l’évaluation des entreprises, dépassant la simple méthodologie 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éveloppeurs. 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éveloppements).
CMMi se focalise sur les processus plutôt que sur les technologies ou les personnes 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 apportent les meilleurs bénéfices lorsqu’elles sont insérées dans une
démarche plus globale à l’entreprise… encore fallait-il y penser
[DMH5] !
Le Modèle est construit sur une
vision, construite sur une étude des
bonnes pratiques et de leurs interactions. Il [DMH6] comporte 25 processus 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’appliquent 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 correspondant à un niveau supérieur à 1,
sont appelés pratiques avancées.
– d’objectifs génériques : à chaque
niveau de capacité (1 à 5) ne correspond qu’un seul objectif générique, qui décrit l’institutionnalisation que l’organisation doit
atteindre pour parvenir à ce
niveau. Chacun est décliné dans
tous les secteurs de processus.
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 promoteur 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élocalisation des développements en Inde
et la nécessité de partager des
référentiels pour contractualiser
et piloter les projets.
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 partiellement. 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 correspondant 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écution. Son adhérence par rapport à sa
description est évaluée.
(1) Software Engineering Institute créé par le Ministère de la Défense Américain (DoD).
• La revue n° 80 - Septembre 2005
CMMi est l’acronyme de Capability
Maturity Model Integration, traduisons concrètement Modèle d’évaluation 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éveloppement des systèmes. Développé
par le SEI (1), il est une évolution du
CMM.
9
dossier :Conduite de projet
Niveau 3 – Défini : un processus
défini est géré. Il est basé sur un processus standard défini au niveau de
l’organisation, décrivant les éléments de processus fondamentaux.
Niveau 4 – Géré, contrôlé : les processus sont suivis et contrôlés tout
au long de leur exécution : des
mesures et des analyses sont effec-
Level
tuées. Des critères de qualité et de
performance permettent d’évaluer
et de gérer les processus.
Niveau 5 – En optimisation : les processus 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
Project Management
Engineering
5
Optimizing
4
Quantitatively
Managed
3
Defined
2
Managed
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 processus clés), gestion de projet, (8
processus clés), ingénierie (6 processus clés) et support (6 secteurs clés).
Support
Process Management
CAR: Causal Analysis
& Resolution
OID: Organizational
Innovation &
Deployment
QPM: Quantitative
Project Management
OPP: Organizational
Process Performance
IPM: Integrated
Project Management
RSKM: Risk Management
IT Integrated Teaming
ISM: Integrated
Supplier Management
RD: Requirements
Development
TS: Technical Solution
PI: Product Integration
VER: Verification
VAL: Validation
DAR: Decision Analysis
& Resolution
OEI: Organizational
Environment
for Integration
PP: Project Planning
PMC: Project Monitoring
& Control
SAM: Supplier Agreement
Management
REQM: Requirements
Management
MA: Measurement
& Analysis
PPQA: Process
& Product
Quality Assurance
CM: Configuration
Management
OPF: Organizational
Process Focus
OPD: Organizational
Process Définition
OT: Organizational
Training
• La revue n° 80 - Septembre 2005
1
Initial
10
Dans la représentation étagée, c’est
un niveau global de maturité de l’organisation 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éveloppement des systèmes logiciels à
savoir : développement, déploiement 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 concentrant sur les besoins et attentes du
client, et sur les contraintes liées à
la solution adoptée.
– Développement intégré des produits 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 exigences 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 uniquement en complément d’autres
composants.
– Sourcing fournisseur CMMi®SE/SW/IPPS/SS : Lorsque le travail
devient complexe, les projets peuvent nécessiter des ressources
externes pour exécuter certaines
fonctions, ou pour modifier les produits. Quand ces activités ont une
importance critique, il peut être
intéressant au projet d’analyser et
de surveiller les activités du fournisseur avant la livraison de produits. 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 soustraitance dans le domaine de l’informatique, 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.
Conduite de projet dossier
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 processus actuels,
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 encourent.
Un des volets importants de la
démarche concerne alors la communication : en interne pour la mise en
place et vers l’extérieur comme
avantage concurrentiel potentiel.
– d’aider à la gestion de la complexité
des développements,
Les risques du CMMi
– donner des gisements d’efficience
aux processus concernés.
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 :
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 : sponsorship du management, implication 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écessite 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
– 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 focaliser sur les compétences nécessaires ou les technologies réellement 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 contrepartie, elles ne seront pas toutes suivies. Rappelons que des auto-évaluations 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 importante. La méthode itérative en partant 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 évidemment 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 indispensables.
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 diminution 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émentaires [DMH12] : les normes ISO 9000
traitent plutôt des processus du système qualité dans leur globalité, en
fixant les fondamentaux d’une
démarche qualité, alors que les
modèles du SEI s’attachent aux processus de développement de façon
plus concrète.
ISO SPICE (Software Process
Improvement Capability dEtermination) 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.
• La revue n° 80 - Septembre 2005
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.
11
dossier :Conduite de projet
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 processus, ainsi qu'un ensemble d'exigences 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 identifie 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 aptitude), 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é.
• La revue n° 80 - Septembre 2005
Le modèle évalue les procédés des
organisations en matière de déve-
12
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ésentation continue du CMMi. Il subsiste
cependant un certain nombre de
différences :
– CMMi dispose de quatre groupes
de processus dans sa représentation continue (processus, projet,
opérationnel, support), alors que
SPICE en a cinq.
– Deux architectures sont disponibles 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 bureaucratique par rapport à de telles
méthodologies ou client et développeur sont côtes à côtes. Cependant
si le CMMi est interprété et déployé
de façon appropriée, la « compatibilité » des deux approches peut être
intéressante. Trois points conciliables :
– L’approche a priori linéaire des
développements de CMMi et l’approche incrémentale des méthodologies « Agile ».
– La complexité de CMMi laisse penser 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 documentation 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