Partager via

Informations générales sur CMMI

  • Article

Le guide définitif de Capability Maturity Model Integration (CMMI) for Development est publié par le Software Engineering Institute sous le titre « CMMI: Guidelines for Process Integration and Product Improvement ». Ce livre décrit plus précisément CMMI for Development (CMMI-DEV) version 1.2, qui représente l'un des modèles de la suite de produits CMMI actuelle en date de cet article. Ce modèle est extrêmement stable et devrait continuer d'être utilisé bien au-delà de 2010. « CMMI Distilled: A Practical Introduction to Integrated Process Improvement » constitue également un livre utile et accessible à ce sujet. Pour plus d'informations sur ces deux livres, consultez Ressources supplémentaires plus loin dans cette rubrique.

Le modèle CMMI a vu le jour en 1987, sous la forme du Capability Maturity Model (CMM), projet du Software Engineering Institute, qui est un centre de recherche de l'université Carnegie-Mellon. Ce centre a été créé et financé par le département de la Défense des États-Unis. Le CMM for Software a été publié pour la première fois en 1991. Il est basé sur une liste de vérification des facteurs de réussite critiques des projets de développement de logiciels au cours de la fin des années 70 et du début des années 80. Ce modèle repose également sur les recherches d'International Business Machines (IBM) Corporation et des leaders en assurance qualité du 20è siècle Philip Crosby et W. Edwards Deming. Le nom, Capability Maturity Model, et les cinq niveaux de la présentation par étapes (discutés plus loin dans cette rubrique), ont été inspirés par le modèle Manufacturing Maturity Model de Crosby. Principalement appliqué aux programmes de défense, le modèle CMM a été très largement adopté et a connu plusieurs révisions et itérations. Sa réussite a entraîné le développement de CMM pour différents sujets au-delà des logiciels. La prolifération de nouveaux modèles a engendré une certaine confusion. Le gouvernement a donc financé un projet de deux ans impliquant plus que 200 experts industriels et universitaires de façon à créer une infrastructure unique et extensible qui intègre la conception de systèmes, la conception de logiciels et le développement de produits. Le modèle CMMI est le résultat de ce projet.

La chose la plus importante à comprendre à propos de CMMI-DEV est qu'il s'agit d'un modèle. Il ne s'agit pas d'un processus ou d'une prescription à suivre. Il s'agit d'un ensemble de comportements organisationnels qui ont fait la preuve de leur valeur dans le cadre du développement de logiciels et de la conception de systèmes. Pourquoi utiliser un tel modèle ? Quel est son objectif ? Et quelle est la meilleure façon de l'utiliser ? Il s'agit là de questions critiques et qui sont peut-être les points les plus mal compris du modèle CMMI.

Dans cette rubrique

  • Pourquoi utiliser un modèle ?

  • Quel est l'objectif du modèle CMMI ?

  • Quelle est la meilleure façon d'utiliser le modèle CMMI ?

  • Éléments du modèle CMMI

  • Ressources supplémentaires

Pourquoi utiliser un modèle ?

Sans modèle présentant le fonctionnement de nos organisations, les fonctions dont elles ont besoin et la façon dont ces fonctions interagissent, il est difficile de mettre en œuvre des efforts d'amélioration des processus. Un modèle nous permet de comprendre les éléments discrets de nos organisations et nous aide à formuler le langage et les discussions relatifs à ce qui doit être amélioré et comment une telle amélioration peut être accomplie. Un modèle offre les avantages suivants :

  • il fournit une infrastructure et un langage communs pour faciliter la communication ;

  • il s'appuie sur des années d'expérience ;

  • il aide les utilisateurs à disposer d'une vue d'ensemble tandis qu'ils se concentrent spécifiquement sur l'amélioration ;

  • il est souvent pris en charge par les formateurs et les consultants ;

  • il peut constituer une norme pour faciliter la résolution des désaccords.

Quel est l'objectif du modèle CMMI ?

Le manuel indique que l'objectif du modèle est d'évaluer la maturité des processus d'une organisation et de fournir des recommandations quant à l'amélioration des processus permettant de générer des produits améliorés. Si vous parlez directement avec les personnes du Software Engineering Institute, ils peuvent vous dire que le CMMI est un modèle de gestion des risques et qu'il indique la capacité d'une organisation à gérer les risques. Cette indication est une preuve de la capacité d'une organisation à tenir ses promesses ou à fournir des produits de grande qualité recherchés sur le marché. Une autre façon de penser consiste à dire que le modèle fournit un bon indicateur de la façon dont une organisation réagit face au stress. Une organisation à la maturité et aux capacités élevées sait faire face aux événements inattendus et stressants : elle a la capacité de réagir, modifier son comportement et aller de l'avant. Une organisation à la maturité et aux capacités faibles a tendance à paniquer face au stress, à suivre aveuglément des procédures toutes faites, ou à abandonner tout ses processus d'un coup et se limiter au chaos.

Le modèle CMMI n'est pas un indicateur des bonnes performances économiques d'une organisation. Bien que les organisations à la maturité supérieure soient susceptibles de mieux gérer les risques et d'être plus prévisibles, il existe la preuve d'une aversion face au risque parmi les entreprises à la maturité plus élevée. Cette aversion peut mener à un manque d'innovation ou à la preuve d'une plus grande bureaucratie qui génère de longs délais et un manque de compétitivité. Les entreprises de maturité inférieure ont tendance à être plus innovantes et créatives, mais également chaotiques et imprévisibles. Lorsque les résultats souhaités sont atteints, ils sont souvent le résultat d'efforts héroïques de la part des employés et des responsables.

Quelle est la meilleure façon d'utiliser le modèle CMMI ?

Ce modèle a été conçu pour être utilisé en tant que base d'une initiative d'amélioration des processus, son utilisation en matière d'évaluation servant uniquement en tant que système de support pour la mesure de l'amélioration. Cette utilisation a connu un succès mitigé. Il est bien trop facile de prendre le modèle pour une définition de processus et d'essayer de le suivre, au lieu de le considérer comme un plan identifiant les lacunes des processus existants qui peuvent devoir être comblées. Le bloc de construction fondamental du modèle CMMI est un domaine de processus qui définit des objectifs et plusieurs activités qui sont souvent utilisées pour les satisfaire. Un exemple de domaine de processus est l'assurance qualité de processus et produits. Un autre est la gestion de la configuration. Il est important de comprendre qu'un domaine de processus n'est pas un processus. Un processus unique peut concerner plusieurs domaines de processus, et un domaine de processus individuel peut impliquer plusieurs processus.

Le modèle CMMI-DEV consiste en deux modèles qui partagent les mêmes éléments sous-jacents. Le premier et le plus connu est la présentation par étapes, qui présente les 22 domaines de processus mappés à cinq niveaux de maturité d'organisation. L'évaluation d'une organisation consiste à estimer le niveau auquel elle fonctionne, et ce niveau est un indicateur de sa capacité à gérer les risques et, par conséquent, à tenir ses promesses.

Représentation intermédiaire CMMI

Les niveaux 4 et 5 sont les niveaux de maturité les plus élevés. Il y a souvent une grande différence entre les organisations à maturité élevée, qui présentent des comportements d'optimisation et de gestion quantitative, et les organisations de maturité faible, gérées de façon simple ou suivant des processus définis. Les organisations à maturité élevée présentent des processus moins variables et utilisent souvent des indicateurs de tendance dans le cadre d'une méthode de gestion statistiquement défendable. Par conséquent, ces organisations sont généralement à la fois plus prévisibles et plus rapides pour réagir face aux nouvelles informations, en supposant que d'autres tâches bureaucratiques n'entravent pas la procédure. Là où les organisations de maturité faible ont tendance à déployer des efforts héroïques, les organisations à maturité élevées peuvent suivre aveuglément certains processus en cas de stress et ne pas reconnaître qu'un changement de processus serait peut-être plus approprié.

Le deuxième modèle, la présentation en continu, modèle individuellement les fonctionnalités des processus dans chacun des 22 domaines de processus, ce qui permet à l'organisation d'adapter ses efforts d'amélioration aux processus qui offrent la plus grande valeur commerciale. Cette présentation est plus dans la ligne du modèle d'origine de Crosby. Les évaluations par rapport à ce modèle permettent de générer des profils de capacité plutôt qu'un nombre unique. Bien entendu, étant donné que le niveau de maturité d'organisation est le niveau que la plupart des responsables et cadres comprennent, il est possible de mapper les résultats d'une évaluation de modèle continue dans les cinq étapes.

Représentation continue CMMI

L'utilisation du modèle par étapes en tant que base pour un programme d'amélioration des processus peut être dangereux car les implémenteurs peuvent oublier que CMMI n'est pas un processus ou un modèle de workflow, mais qu'il fournit des objectifs de processus et workflows. La satisfaction de ces objectifs améliore la maturité de l'organisation et la probabilité que les événements se déroulent comme prévu. Le plus grand échec consiste peut-être à atteindre un niveau d'objectif, puis à créer des processus et une infrastructure simplement pour réussir l'évaluation. L'objectif des activités d'amélioration des processus doit être une amélioration mesurable, pas un nombre.

Le modèle continu semble avoir connu une plus grande réussite en tant que guide d'amélioration des processus, et certaines entreprises de conseil choisissent de recommander uniquement le modèle continu. La différence la plus évidente est qu'un programme d'amélioration des processus conçu autour du modèle continu ne présente pas les objectifs artificiels déterminés par les niveaux de maturité. Le modèle continu se prête également plus naturellement à l'application de l'amélioration des processus dans les domaines les plus susceptibles de tirer parti d'un avantage économique pour l'organisation. Par conséquent, ceux qui suivent le modèle continu ont plus de chances de recevoir des commentaires positifs suite à une initiative basée sur le modèle CMMI. De plus, ces commentaires positifs ont plus de chances d'aboutir au développement d'un cycle d'améliorations vertueux.

Éléments du modèle CMMI

Le modèle CMMI est divisé en 22 domaines de processus, qui apparaissent dans le tableau suivant :

Acronyme

Domaine de processus

CAR

Analyse causale et résolution

CM

Gestion de la configuration

DAR

Analyse de décision & résolution

IPM

Gestion de projet intégrée

MA

Mesures et analyses

OID

Innovation et déploiement organisationnels

OPD

Définition de processus organisationnels

OPF

Focus de processus d'organisation

OPP

Performances des processus organisationnels

OT

Formation organisationnelle

PI

Intégration de produit

PMC

Suivi et contrôle de projet

PP

Planification de projet

PPQA

Assurance qualité de processus et produits

QPM

Gestion de projet quantitative

RD

Définition de spécifications

REQM

Gestion des spécifications

RSKM

Gestion des risques

SAM

Gestion des accords avec les fournisseurs

TS

Solution technique

VER

Vérification

VAL

Validation

Dans la présentation par étapes, les domaines de processus sont mappés à chaque étape, comme indiqué dans l'illustration suivante.

Représentation intermédiaire affichant les processus

Dans la présentation en continu, les domaines de processus sont mappés à des groupements fonctionnels, comme indiqué dans l'illustration suivante.

Représentation continue affichant les processus

Chaque domaine de processus est constitué de composants requis, attendus et informatifs. Seuls les composants requis sont obligatoires pour effectuer une évaluation par rapport au modèle. Les composants requis sont les objectifs spécifiques et génériques de chaque domaine de processus. Les composants attendus sont les pratiques spécifiques et génériques de chaque objectif spécifique ou générique. Notez que, étant donné qu'un composant attendu est simplement attendu et non pas requis, cela indique qu'une pratique spécifique ou générique peut être remplacée par une pratique équivalente. Les pratiques attendues sont là pour guider les implémenteurs et les experts. Si une autre pratique est choisie, ce sera à l'implémenteur de recommander un expert et de justifier en quoi une autre pratique est appropriée. Les composants informatifs fournissent des détails qui aident les implémenteurs à démarrer avec une initiative d'amélioration de processus guidée par le modèle CMMI. Les composants informatifs incluent des sous-pratiques de pratiques génériques et spécifiques, ainsi que des produits de travail typiques.

Il est très important de comprendre que seuls les objectifs génériques et spécifiques sont obligatoires. Tout le reste est fourni dans un objectif de conseil. Les exemples de composants attendus et informatifs donnés dans la documentation CMMI sont très souvent extraits de projets d'intégration de systèmes de défense et spatiaux. Ces projets sont exécutés par des sociétés qui parrainent et soutiennent le Software Engineering Institute de l'université Carnegie-Mellon. Ces projets peuvent ne pas refléter le type des projets mis en œuvre dans votre organisation. En outre, ils peuvent ne pas refléter les tendances les plus récentes de l'industrie, telles que l'apparition des méthodes Agile software development.

Ressources supplémentaires

Pour plus d'informations, consultez les ressources Web suivantes :

Voir aussi

Concepts

MSF for CMMI Process Improvement v5.0