Capability Maturity Model Integration

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.

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 est discipliné. Les activités et produits (techniques et de gestion, intermédiaires et finals) 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 :

• la gestion des exigences,
• la planification de projet,
• le suivi de projet,
• la gestion des fournisseurs,
• l'utilisation de métriques,
• l'assurance qualité
• et la gestion de configuration.

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 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 :

• Développement des exigences (Requirements Development)
• Gestion des risques (Risk Management)
• Analyse et 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 organisationnelle (Organizational Training)
• Gestion de projet intégrée (Integrated Project Management)
• Solution technique (Technical Solution)
• Intégration de produit (Product Integration)
• Vérification (Vérification)
• Validation (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 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.

Par exemple, 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és 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 du processus organisationnel (organizational process performance)
• Gestion de projet quantitative (quantitative project management)

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 :

• Gestion de la performance organisationnelle (Organizational Innovation and Deployment)
• Analyse causale et résolution (Causal Analysis and Resolution)

• Les objectifs génériques : le modèle CMMi fournit cinq 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.)

• 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.

• Ahern, Dennis M. (trad. Q-Labs), Comprendre CMMI, une introduction pratique à l'amélioration de processus, Éditions Cépaduès, 2006, 279 p. (ISBN 978-2-85428-719-6)
• April, Alain et Abran, Alain, Améliorer la maintenance du logiciel, Montréal, Loze-Dion, 2016, 348 p. (ISBN 978-2-924601-01-3)
• Basque, Richard, CMMI : Un itinéraire fléché vers le Capability Maturity Model Integration Version 1.2, Éditions Dunod, 2009, 253 p. (ISBN 978-2-10-049711-9)
• Chrissis, Mary Beth, Konrad, Mike et Shrum, Sandy (trad. de l'anglais), CMMI : guide des bonnes pratiques pour l'amélioration des processus, Paris, Pearson, 2008, 750 p. (ISBN 978-2-7440-7304-5)
• Delbaldo, Emmanuelle, CMMI light : La performance tangible, La Plaine-Saint-Denis, AFNOR Éditions, 2007, 232 p. (ISBN 978-2-12-475591-2)
• Dufay, François, CMMI par l'exemple : Pour une mise en place opérationnelle, Paris, Éditions Eyrolles, 2010, 287 p. (ISBN 978-2-212-12687-7)
• Lamnabhi, Moustanir, Evaluer avec CMMI : Etape par étape, La Plaine-Saint-Denis, AFNOR Éditions, 2008, 274 p. (ISBN 978-2-12-465124-5)

• (en) Site officiel du CMMI Institute : site officiel du CMMI Institute