Informations générales sur CMMI

Le guide complet de l'intégration CMMI (Capability Maturity Model Integration) pour le développement est publié par le Software Engineering Institute sous le titre « CMMI: Guidelines for Process Integration and Product Improvement ». Cet ouvrage décrit de manière spécifique CMMI for Development (CMMI-DEV) version 1.3, qui est l'un des modèles de la suite de produits CMMI à la date de rédaction de cet article. Ce modèle est extrêmement stable et devrait continuer à être à jour bien au-delà de l'année 2010. « CMMI Distilled: A Practical Introduction to Integrated Process Improvement » est un autre ouvrage utile et accessible sur ce sujet. Pour plus d'informations sur ces deux ouvrages, voir Ressources supplémentaires plus loin dans cette rubrique.

Le CMMI a vu le jour en 1987 sous le nom de Capability Maturity Model (CMM), un projet du Software Engineering Institute, qui est un centre de recherche basé à Carnegie-Mellon University. Ce centre a été établi et est financé par le United States Department of Defense. CMM for Software a été publié en 1991 ; il est basé sur une liste de vérifications de facteurs de succès critiques dans les projets de développement logiciel durant la fin des années 1970 et le début des années 1980. Ce modèle a également bénéficié de recherches menées chez International Business Machines (IBM) Corporation et par Philip Crosby and W.Edwards Deming, leaders dans le domaine de l'assurance de la qualité. Le nom, Capability Maturity Model, et les cinq niveaux de la Représentation par étape (comme discuté plus loin dans cet article) ont été inspirés par le Manufacturing Maturity Model de Crosby. Appliqué principalement aux programmes de défense, le modèle CMM a été largement adopté et a connu plusieurs révisions et itérations. Son succès a mené au développement de modèles CMM pour différents sujets au-delà des logiciels. La prolifération de nouveaux modèles était perturbante. Le gouvernement a donc fondé un projet de deux ans impliquant plus de 200 experts de l'industrie et académiques intégrant l'ingénierie système, l'ingénierie logicielle et le développement de produits. Cela a donné naissance à CMMI.

L'élément clé à 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 ayant prouvé leur efficacité dans les domaines du développement logiciel et de l'ingénierie système. Pourquoi utiliser un tel modèle ? Quel est son objectif ? Et comment l'utiliser au mieux ? Il s'agit de questions essentielles qui sont peut-être les aspects les plus incompris de l'intégration CMMI.

Pourquoi utiliser un modèle ?

Sans modèle décrivant le mode de fonctionnement de nos organisations, les fonctions dont elles ont besoin et comment ces fonctions interagissent, il est difficile de canaliser les efforts en vue d'une amélioration. Un modèle nous permet de mieux comprendre les différents éléments de nos organisations et nous aide à formuler un langage et une discussion de ce qui doit être amélioré et des moyens d'y parvenir. Un modèle offre les avantages suivants :

• il fournit une infrastructure est un langage communs pour aider à communiquer ;

• il permet d'exploiter des années d'expérience ;

• il aide les utilisateurs à se focaliser de manière spécifique sur les améliorations tout en gardant à l'esprit le contexte global ;

• il est souvent pris en charge par des formateurs et des conseillers ;

• il peut fournir une norme pour aider à résoudre les désaccords.

Quel est l'objectif du modèle CMMI ?

Théoriquement, l'objectif du modèle et d'évaluer la maturité des processus d'une organisation et de fournir une aide à l'amélioration des processus qui permettra d'améliorer les produits. Si vous discutez directement avec les employés du Software Engineering Institute, ils vous diront peut-être que le modè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 traduit la probabilité qu'une organisation puisse tenir ses promesses ou délivrer des produits de qualité ayant une forte attractivité pour le marché. On peut également estimer que le modèle constitue un bon indicateur des performances de l'organisation dans les situations de stress. Une organisation à capacité et à maturité élevées acceptera les événements inattendus et stressants, et réagira, évoluera et ira de l'avant. Une organisation à faible maturité et capacité aura tendance à paniquer dans les situations de stress, à suivre de manière aveugle des procédures inutiles ou à ignorer totalement tout processus et à sombrer dans le chaos.

Le CMMI n'est pas un bon indicateur des performances économiques d'une organisation. Bien que les organisations à maturité élevée puissent mieux gérer les risques et avoir un comportement plus prévisible, une certaine aversion aux risques a été observée parmi les entreprises les plus matures. Cette aversion peut mener à un manque d'innovation ou à une évidence de bureaucratie marquée ayant comme conséquences des délais d'exécution plus longs et un manque de compétitivité. Les entreprises à maturité plus faible tendent à être plus innovatrices et créatives, mais aussi chaotiques et imprévisibles. Quand des résultats sont obtenus, ils sont souvent le résultat d'un effort héroïque de la part d'individus ou de responsables.

Quel est le meilleur moyen d'utiliser le modèle CMMI ?

Le modèle a été conçu pour servir de base pour une initiative d'amélioration des processus, son rôle en matière d'évaluation se limitant à la mesure de l'amélioration. Cette utilisation a rencontré un succès mitigé. Il est très facile de se méprendre et de considérer le modèle comme une définition de processus et d'essayer de le suivre, plutôt que comme une carte qui identifie des lacunes dans les processus existants. La composante fondamentale de CMMI est une zone de processus qui définit des objectifs et plusieurs activités qui sont souvent utilisées pour les atteindre. Processus et Assurance de la qualité produit sont deux exemples de zone de processus. Gestion de la configuration en est un autre. Il est important de bien comprendre qu'une zone de processus n'est pas un processus. Un processus peut couvrir plusieurs zones de processus est une même zone de processus peut impliquer plusieurs processus.

Le modèle CMMI-DEV est en fait constitué de deux modèles qui partagent les mêmes éléments sous-jacents. Le premier de ces modèles, et le plus familier, est la Représentation par étape, qui présente 22 zones de processus mappées à l'un des cinq niveaux de maturité organisationnelle. L'évaluation d'une organisation fournit des informations sur son niveau d'exploitation, qui constituent un indicateur quant à sa capacité à gérer les risques et par conséquent à tenir ses promesses.

Les niveaux 4 et 5 sont souvent considérés comme les niveaux de maturité les plus élevée. Il existe souvent une différence marquée entre les organisations à maturité élevée, qui démontrent des comportements d'optimisation et de gestion quantitative, et les organisations à maturité plus faible, qui sont simplement gérées ou qui suivent des processus définis. Les organisations à maturité plus élevées présentent une variabilité plus faible dans les processus et utilisent souvent des indicateurs clés dans le cadre d'une méthode de gestion statistiquement défendable. En conséquence, elles tendent à être plus prévisibles et plus rapides quand il s'agit de répondre aux nouvelles informations, en supposant que d'autres aspects bureaucratiques n'y fassent pas obstacle. Quand les organisations à faible maturité tendent à présenter un effort héroïque, les organisations à maturité plus élevée peuvent suivre des processus de manière aveugle en situation de stress et ne pas reconnaître qu'une modification de processus pourrait être une réponse plus appropriée.

Le second modèle, la Représentation continue, modélise la capacité de processus dans chacune des 22 zones de processus, ce qui permet à l'organisation de personnaliser ses efforts d'amélioration en fonction des processus qui offrent la valeur commerciale la plus élevée. Cette représentation est plus alignée avec le modèle d'origine de Crosby. Les évaluations effectuées par rapport à ce modèle permettent de générer des profits de capacités plutôt qu'un chiffre unique. Bien entendu, le niveau de maturité organisationnelle étant le niveau que la plupart des responsables et des cadres supérieurs comprennent, il existe des manières de mapper les résultats d'une évaluation de modèle continu aux cinq étapes.

L'utilisation du modèle par étape comme base pour un programme d'amélioration des processus peut être dangereuse, car les implémenteurs risquent d'oublier que le modèle CMMI n'est pas un processus ni un modèle de flux de travail, mais qu'il fournit des objectifs que les processus et les flux de travail doivent atteindre. Le fait d'atteindre ses objectifs améliorera la maturité de l'organisation et la probabilité que les événements se dérouleront comme prévu. L'erreur la plus importante consiste peut-être à avoir comme objectif d'atteindre un niveau, puis à créer des processus et une infrastructure simplement pour satisfaire l'évaluation. L'objectif de toute activité d'amélioration des processus doit être une amélioration mesurable, et non un chiffre.

Le modèle continu semble avoir plus de succès en tant que guide à l'amélioration des processus et certaines sociétés de conseil choisissent de proposer une aide axée uniquement sur ce modèle. 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 qui sont déterminés par les niveaux de maturation. Le modèle continu se prête également plus naturellement à l'application d'une amélioration des processus dans les domaines dans lesquels il est plus susceptible de générer un bénéfice économique pour l'organisation. Par conséquent, ceux qui suivent le modèle continu sont davantage susceptibles de recevoir des commentaires positifs suite à une initiative basée sur le modèle CMMI. Les commentaires positifs, à leur tour, sont plus susceptibles de mener au développement d'un cycle vertueux d'améliorations.

Éléments du modèle CMMI

Le modèle CMMI est divisé en 22 zones de processus, répertoriées dans le tableau ci-dessous :

Dans la Représentation par étape, les zones de processus sont mappées à chaque étape, comme illustré ci-dessous.

Dans la Représentation continue, les zones de processus sont mappées à des groupements fonctionnels, comme illustré ci-dessous.

Chaque zone de processus est constituée de composants requis, attendus et informatifs. Seuls les composants requis sont réellement obligatoires pour satisfaire à une évaluation par rapport au modèle. Les composants requis sont les objectifs génériques et spécifiques pour chaque zone de processus. Les composants attendus sont les objectifs génériques et spécifiques pour chaque objectif générique ou spécifique. Notez que chaque composant attendu étant simplement attendu et non requis, cela indique qu'une pratique générique ou spécifique peut être remplacée par une pratique équivalente. Les pratiques attendues sont là pour guider les implémenteurs et les évaluateurs. Si une pratique alternative est choisie, il incombera à l'implémenteur d'en informer l'évaluateur et de justifier le fait qu'une pratique alternative soit appropriée. Les composants informatifs fournissent des détails qui aident les implémenteurs à démarrer une initiative d'amélioration guidée par le modèle CMMI. Ils comprennent des pratiques secondaires de pratiques génériques et spécifiques et des produits de travail typiques.

Il est très important de bien comprendre que seuls les objectifs génériques et spécifiques sont requis. Tous les autres éléments sont fournis uniquement à titre de recommandations. Les exemples de composants attendus et informatifs fournis dans la documentation CMMI sont très souvent tirés de grands projets d'intégration de systèmes de défense et aéronautiques. Ces projets sont gérés par des sociétés qui sponsorisent et soutiennent le Software Engineering Institute de Carnegie-Mellon University. Ces projets peuvent ne pas refléter le type de projet entrepris dans votre organisation, ni les tendances les plus récentes de l'industrie telles que l'émergence de méthodes de développement logiciel agiles.

Ressources supplémentaires

Pour plus d'informations, voir les ressources web suivantes :

• CMMI for Development, Version 1.3, Improving processes for developing better products and services Software Engineering Process Management Program

• Institut CMMI

• CMMI: Guidelines for Process Integration and Product Improvement (2nd Edition), Mary Beth Chrissis, Mike Konrad et Sandy Shrum; Addison-Wesley Professional, 2006.

• CMMI Distilled: A Practical Introduction to Integrated Process Improvement (3rd Edition), Dennis M. Ahren, Aaron Clause et Richard Turner; Addison-Wesley Professional, 2008.

Voir aussi

Concepts

Modèle de processus CMMI