Capability Maturity Model Integration

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

CMMI, sigle de Capability Maturity Model + Integration, est un modèle de référence, un ensemble structuré de bonnes pratiques, destiné à appréhender, évaluer et améliorer les activités des entreprises d'ingénierie.

CMMI a été développé par le Software Engineering Institute de l'université Carnegie-Mellon, initialement pour appréhender et mesurer la qualité des services rendus par les fournisseurs de logiciels informatiques du département de la Défense des États-Unis(DoD). Il est maintenant largement employé par les entreprises d'ingénierie informatique, les directeurs des systèmes informatiques et les industriels pour évaluer et améliorer leurs propres développements de produits[1]. CMMI est une marque déposée par le Software Engineering Institute[2].

Le modèle CMMI[modifier | modifier le code]

Le modèle CMMI définit une échelle de mesure de la maturité à cinq niveaux, ainsi que les indicateurs nécessaires pour évaluer les activités menées par une équipe par rapport à cette échelle - l'équipe peut être un groupe de travail, un ou plusieurs projets, une société voire une institution d'État.

CMMI est un cadre générique de processus qui se décline en trois modèles (appelés constellations) :

  • CMMI-DEV pour le développement de systèmes (logiciel ou autre, modèle publié en août 2006[3])
  • CMMI-ACQ pour la maîtrise des activités d'achat (modèle publié en novembre 2007[4])
  • CMMI-SVC pour la fourniture de services (modèle publié en février 2009[5])

La particularité de ces trois modèles de processus est qu'ils ont une partie commune (le noyau ou core en anglais) qui représente environ 60 % des pratiques. D'un modèle à l'autre, les différences portent essentiellement sur la catégorie « Ingénierie » dont les pratiques varient selon l'activité concernée.

Le modèle CMMI est majoritairement utilisé dans des sociétés d'informatique, toutefois les principes de CMMI s'appliquent à n'importe quelle activité d'ingénierie : architecture, mécanique, électronique…

Maturité[modifier | modifier le code]

D'après la définition donnée dans le CMMI, la maturité d'une organisation est le degré auquel celle-ci a déployé explicitement et de façon cohérente des processus qui sont documentés, gérés, mesurés, contrôlés et continuellement améliorés.

Un niveau de maturité (Maturity Level) (pour l'approche étagée) correspond à l'atteinte d'un niveau de capabilité uniforme pour un groupe de processus. Un niveau de capabilité (Capability Level) mesure l'atteinte des objectifs d'un processus pour le niveau donné (concerne l'approche continue de CMMi) .

Historique[modifier | modifier le code]

Dans les années 1980, le Département de la Défense des États-Unis (DoD) a demandé l'élaboration d'un référentiel de critères lui permettant d'évaluer ses fournisseurs de logiciels. Après une lente maturation, le SEI (Software Engineering Institute) financé par le DoD a présenté en 1991 le Capability Maturity Model (CMM). Ce modèle de référence ne concerne que les bonnes pratiques du génie logiciel. Après un fort engouement pour ce modèle, d'autres modèles similaires ont vu le jour, tels que :

  • SE-CMM (pour System Engineering) ;
  • SA-CMM (pour Software Acquisition) ;
  • IPD-CMM (pour Integrated Product Development) ;
  • People CMM pour le management des ressources humaines ;
  • SS-CMM pour Supplier Sourcing.

Tant et si bien qu’il fallut rebaptiser le CMM « initial » en SW-CMM (pour Software).

En 2001, le SEI a proposé une nouvelle version de son modèle, le CMMI (Capability Maturity Model Integration) qui englobe les bonnes pratiques des autres modèles, sauf la gestion des ressources humaines qui n'est pas encore considérée (version 1.1). La version du modèle a été réactualisée en 2006 (version 1.2). Cette version du CMMI tendait à simplifier le modèle et améliorait la prise en compte des composants de type matériel. La dernière version du modèle date de 2011 (version 1.3)

Le CMMI-DEV est un modèle de processus (référentiel de bonnes pratiques) pour la réalisation de tout type de produit (ou système). C'est cependant dans le développement et la maintenance de logiciel qu'il est le plus utilisé. Sa portée utile s'étendant de l'apparition d'un besoin jusqu'à la livraison du produit correspondant, il y a d'autres modèles utiles pour d'autres domaines du logiciel, par exemple pour les infrastructures et opérations ITIL.

Descriptif du modèle[modifier | modifier le code]

Dans l'approche étagée (il existe une approche dite "continue"), les bonnes pratiques préconisées par le modèle (version 1.2) sont rassemblées en 22 domaines de processus eux-mêmes regroupés en 5 niveaux de maturité. Les domaines de processus rattachés à un niveau de maturité M ne peuvent être stabilisés et efficaces que si les domaines de processus des niveaux inférieurs ( < M ) sont déjà stabilisés et efficaces (principe d'empilement). Les 5 niveaux sont :

« Initial » (niveau de maturité 1)
Il n'y a pas de grand pilier directionnel, aucune façon de faire ou standard ne sont établis (ou bien ils sont documentés mais ne sont pas utilisés), tout doit être fait. Il n'y a pas de surveillance (monitoring), aucune évaluation de performance et la communication est absente. Les faiblesses ne sont pas identifiées et les employés ne sont pas au courant de leurs responsabilités de façon définie et absolue. Les réactions aux incidents se font en mode urgence, sans identification claire des priorités. À ce niveau les solutions ainsi que les projets sont décidés, développés et instaurés par un individu. Les compétences et les ressources propres de cet individu sont la raison du succès ou de l'échec du projet (par dérision, ce niveau est aussi nommé héroïque ou chaotique). Il n'y a pas de description du niveau de maturité 1 dans le modèle.
« Managed », soit discipliné en français (niveau de maturité 2)
Une discipline est établie pour chaque projet et se matérialise essentiellement par des plans de projet (plan de développement, d'assurance qualité, de gestion de configuration…). Le chef de projet a une forte responsabilité dans le niveau 2 : il doit définir, documenter, appliquer et maintenir à jour ses plans. D'un projet à l'autre, il capitalise et améliore ses pratiques de gestion de projet et d'ingénierie.
« Defined », soit ajusté en français (niveau de maturité 3)
Ce niveau est caractérisé par une standardisation adéquate des pratiques, une capitalisation centralisée (en particulier sur les mesures réalisées dans les projets) et une maîtrise du référentiel interne (ou Système Qualité). Il existe des lignes directrices, un plan stratégique et une planification de l'amélioration de processus pour le futur, en ligne avec les objectifs d'affaire de l'organisation. Les employés sont formés et conscients de leurs responsabilités ainsi que de leurs devoirs.
« Quantitatively managed », soit géré quantitativement en français (niveau de maturité 4)
Les projets sont pilotés sur la base d'objectifs quantitatifs de qualité produit et processus. La capacité des activités (ou sous-processus) critiques est déterminée par l'organisation, ainsi que les modèles de performance et de prévision associés. L'expression de la qualité demandée par le client est prise en compte pour quantifier les objectifs du projet et établir des plans selon la capacité des processus de l'organisation.
« Optimizing », soit en optimisation en français (niveau de maturité 5)
Les processus qui sont gérés quantitativement pour le pilotage de projet (niveau de maturité 4) sont en optimisation constante afin d'anticiper les évolutions prévues (besoins clients, nouvelles technologies…).

Le niveau 1[modifier | modifier le code]

Le niveau 1 Initial est le niveau où le résultat final est imprévisible. À ce niveau l'effort individuel prévaut à l'effort collectif dirigé vers un but établi. L’atteinte des résultats repose plus sur les hommes, sur leur engagement et bonne volonté, que sur l’application disciplinée de bonnes pratiques. La réussite d'un projet repose en général sur le talent d'un individu, c'est pourquoi on surnomme ironiquement ce niveau l'ère des héros. Mais une réussite éventuelle ne sera pas nécessairement reproductible.

L'évaluation de l'efficacité et des performances est absente. La direction n'établit pas de plan ou de vision qui sont liés à des besoins. La documentation est inexistante.

Exemple[modifier | modifier le code]

La supervision des sauvegardes est réalisée par un technicien qui s'intéresse aux systèmes de sauvegarde. Il comprend et maîtrise ce qu'il réalise. En général il vérifie quotidiennement les résultats des traitements de la veille, personne ne le contrôle ou supervise. Si nécessaire il applique les correctifs au système, néanmoins, il travaille de manière autarcique. Si pour une raison quelconque (surcharge, congés) il n'est pas en mesure de réaliser les contrôles nécessaires, ceux-ci ne sont alors pas pris en charge.

Le niveau 2 (managed / discipliné)[modifier | modifier le code]

Pour le niveau 2, les activités et produits (techniques et de gestion, intermédiaires et finaux) sont maîtrisés par le projet. Les processus projet sont disciplinés, ce qui se caractérise par :

  • les activités sont planifiées et exécutées conformément à une politique (ou directive) d'organisation,
  • les rôles, responsabilités et acteurs sont définis et connus,
  • les acteurs disposent des compétences et des ressources adéquates pour réaliser les produits,
  • les produits sont contrôlés,
  • la mise en œuvre du processus fait l'objet d'un suivi, de vérifications et d'ajustement si nécessaire.

Le niveau 2 se compose de sept domaines de processus traitant de :

Chacun de ces sept domaines de processus contribue à donner à l'organisation une bonne visibilité sur ses développements : visibilité sur le contenu, les coûts, les délais, la qualité des produits développés et des processus utilisés. Typiquement, les membres d'une équipe de développement, comme le management, connaissent l'état d'avancement de leur projet et des évolutions en cours, ainsi que ce qu'il reste à faire.

Le niveau 3 (Defined / ajusté)[modifier | modifier le code]

Le niveau 3 est Ajusté. À ce niveau, l’organisation dispose d’un ensemble de processus standards qui sont ajustés par chaque projet, selon le contexte client propre, avec des règles fixées par l'organisation. Les processus standards sont développés, maintenus, supportés et leur application contrôlée par un groupe processus (le SEPG - Software/System Engineering Process Group ou EPG). Chaque projet capitalise son expérience et permet de bonifier le capital collectif. C'est aussi à ce niveau que les cycles de vie et processus d'ingénierie sont standardisés par typologie de projet.

Le niveau 3 met en place des boucles d'amélioration : l'expérience, les forces et difficultés rencontrées lors des développements, sont capitalisées pour améliorer les développements futurs. Par exemple, des problèmes rencontrés sur un projet seront analysés dans un bilan de fin de projet pour éventuellement enrichir une base de risques types et anticiper ce problème lors de développements similaires.

Le niveau 3 repose sur les bases du niveau 2. Ainsi le domaine de niveau 2 "Gestion des exigences" est complété au niveau 3 par le domaine "Développement des exigences". Une fois que, au niveau 2, l'organisation a appris à gérer ses exigences, elle peut au niveau 3 mettre en place des pratiques d'ingénierie pour définir ces exigences. D'une manière générale, les domaines de processus de niveau 2 sont des pré-requis pour les domaines de niveau 3.

Le niveau 3 se compose de onze domaines de processus traitant de :

  • Expression des besoins (Requirements Development)
  • Gestion des risques (Risk Management)
  • Méthode de prise de décision (Decision Analysis and Resolution)
  • Définition du processus organisationnel (Organizational Process Definition)
  • Focalisation sur le processus organisationnel (Organizational Process Focus)
  • Formation à l’organisation (Organizational Training)
  • Gestion de projet intégrée (Integrated Project Management)
  • Solution technique (Technical Solution)
  • Intégration du produit (Product Integration)
  • Recette technique (Vérification)
  • Recette fonctionnelle (Validation)


On trouve ainsi dans ce niveau une accumulation de choses que l’on peut regrouper sous les thèmes suivants :

  • l’ingénierie des exigences, de l’expression des besoins aux spécifications et à la recette ;
  • le perfectionnement de la gestion de projet ;
  • la « personnalisation » de la gestion de chaque projet et la capitalisation de l’expérience d’un projet à l’autre ;
  • les méthodes de prise de décision.

Le niveau 4 (Quantitatively managed / Géré quantitativement)[modifier | modifier le code]

Le niveau 4 est Géré Quantitativement. À ce niveau, les processus clés sont sous contrôle statistique (surveillance d’indicateurs quantitatifs, et actions correctrices si dérives). Élimination des causes spéciales de variation.

  • Ex. la capitalisation a permis d’établir la productivité moyenne du processus (taille produite/charge consommée). Le projet se fixe un objectif de productivité en relation et prend des mesures dès qu’il y a des dérives.

Les méthodes statistiques de contrôle des processus mises en place au niveau 4 permettent de focaliser les actions d'amélioration sur les pratiques pour lesquelles ces actions sont les plus utiles. Au niveau des projets, elles permettent d'identifier des activités n'ayant pas atteint des résultats attendus et ainsi prendre des actions. Par exemple, en fonction de la taille, technologie, complexité d'un nouveau composant, les tests doivent permettre d'identifier un nombre de défauts compris dans une fourchette définie. Si le nombre de défauts identifiés est en dehors de cette fourchette, une analyse sera lancée pour en comprendre les raisons. Cette fourchette est définie à partir de calculs statistiques basées sur des résultats des tests des précédents composants développés.

Le niveau 4 se compose de deux domaines de processus traitant de :

  • Performance des processus (Organizational Process Performance)
  • Gestion quantitative du projet (Quantitative Project Management)

Le niveau 5 (optimizing / en optimisation)[modifier | modifier le code]

Le niveau 5 est En Optimisation. L’organisation est dans une boucle permanente d’optimisation (réduction des causes communes de variation) des processus et des technologies, optimisation basée sur des analyses coût/bénéfice. Des analyses causales statistiques menées régulièrement permettent ces améliorations.

Les boucles permanentes d'optimisation sont mises en place dès le niveau 3. Au niveau 5, celles-ci se basent sur des méthodes statistiques pour focaliser les analyses causales sur les événements dont l'analyse apportera des informations permettant d'optimiser les processus, en évitant de perdre du temps sur l'analyse d'événement apportant moins d'information.

Le niveau 5 se compose de deux domaines de processus traitant de :

  • Innovation organisationnelle (Organizational Innovation and Deployment)
  • Analyse causale et solution des problèmes (Causal Analysis and Resolution)

Les autres composants[modifier | modifier le code]

  • Les objectifs génériques : le modèle CMMi fournit 5 objectifs génériques (GG). Ces objectifs génériques (et les pratiques associées) s'appliquent à tous les domaines de processus (PA).
  • Les pratiques génériques : les pratiques génériques appartiennent aux objectifs génériques. Elles doivent être systématiquement implémentées pour prétendre atteindre un niveau de maturité ou de capacité.
  • Les objectifs spécifiques : les objectifs spécifiques sont liés à un domaine de processus (PA).
  • Les pratiques spécifiques : elles sont liées à un objectif spécifique, donc à un domaine de processus (PA).
  • Les produits d'activité : ce sont tous les éléments générés par un projet (plan de projet, spécification, cahier de test unitaire, revue par les pairs, etc.)

Les autres déclinaisons[modifier | modifier le code]

  • CMM-TSP (Team Software Process) qui détermine les pratiques normées d'une équipe projet.
  • CMM-PSP (Personal Software Process) qui détermine les pratiques normées d'une ressource individuelle de développement.

Pour aller plus loin[modifier | modifier le code]

Et l'ISO 9001 dans tout ça ?

CMMI et ISO 15504 alias SPICE

  • CMMI, utilisé en mode continu, est un des modèles de processus accepté par la norme ISO 15504.

Et la maintenance logicielle

  • CMMI ne peut être utilisé pour la maintenance quotidienne des logiciels. Il existe cependant d'autres modèles pour ce type d'activité, comme le modèle de la maturité de la maintenance S3M[6].

Notes et références[modifier | modifier le code]

  1. http://www.cmmifaq.info/#1 CMMi FAQ
  2. Software Engineering Institute's Trademarks and Service Marks : http://www.sei.cmu.edu/legal/marks/ (consulté le 11 mai 2014).
  3. http://www.sei.cmu.edu/library/abstracts/reports/06tr008.cfm
  4. http://www.sei.cmu.edu/library/abstracts/reports/10tr032.cfm
  5. http://www.sei.cmu.edu/library/abstracts/reports/10tr034.cfm
  6. A April A Abran, « Software Maintenance Management - evaluation and continuous improvement »,‎ 2008 (consulté le 16 juillet 2008)

Bibliographie[modifier | modifier le code]

  • François Dufay, CMMI par l'exemple : Pour une mise en place opérationnelle, Éditions Eyrolles,‎ 16 juillet 2010, 287 p. (ISBN 9782212126877)
  • (en) Mary Beth Chrissis, Mike Konrad et Sandy Shrum, CMMI: Guide des bonnes pratiques pour l'amélioration des processus, Pearson,‎ 13 juin 2008, 750 p. (ISBN 9782744073045)
  • Richard Basque, CMMI : Un itinéraire fléché vers le Capability Maturity Model Integration Version 1.2, Éditions Dunod,‎ novembre 2006, 253 p. (ISBN 9782100497119)
  • (en) Dennis M. Ahern (trad. Q-Labs), Comprendre CMMI, une introduction pratique à l'amélioration de processus, Éditions Cépaduès,‎ 13 juin 2006, 279 p. (ISBN 9782854287196)
  • Emmanuele Delbaldo, CMMI light : La performance tangible, AFNOR Éditions,‎ janvier 2008, 232 p. (ISBN 9782124755912)
  • Moustanir Lamnabhi, Evaluer avec CMMI : Etape par étape, AFNOR Éditions,‎ 10 juillet 2008, 274 p. (ISBN 9782124651245)

Voir aussi[modifier | modifier le code]

Liens externes[modifier | modifier le code]