Arrière-plan pour l’intégration de Capability Maturity Model (CMMI)

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Le guide définitif de l’intégration de Capability Maturity Model (CMMI) pour le développement est publié par l’institut du génie logiciel sous le titre « CMMI : recommandations pour l’intégration des processus et l’amélioration des produits ». Ce livre décrit spécifiquement CMMI pour le développement (CMMI-DEV) version 1.3, qui est l’un des modèles de la suite de produits CMMI. Vous y trouverez également « CMMI distillé : introduction pratique à l’amélioration de processus intégrée », un autre ouvrage utile et accessible sur l’intégration CMMI.

Notes historiques

Le CMMI a commencé en 1987, nommé Capability Maturity Model (CMM), il s’agit d’un projet de l’institut du génie logiciel (SEI). SEI est un centre de recherche de l’université Carnegie-Mellon, créé et financé par le département de la Défense des États-Unis. Publiée pour la première fois en 1991, la CMM pour logiciel était au départ une liste de vérification des facteurs critiques de réussite. Le modèle a également bénéficié de recherches menées par International Business Machines (IBM) Corporation et par des leaders en assurance qualité du XXe siècle tels que Philip Crosby et W. Edwards Deming. Le nom Capability Maturity Model et les cinq niveaux de la Représentation par étape 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. 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 est source de confusion. En réponse, le gouvernement a financé un projet de deux ans pour créer un cadre unique et extensible qui intègre l’ingénierie des systèmes, le génie logiciel et le développement de produits. Cet effort a impliqué plus de 200 experts de l’industrie et du milieu universitaire. Cela a donné naissance à CMMI.

CMMI-DEV est un modèle. Il ne s'agit pas d'un processus ni d'une prescription à suivre. Au lieu de cela, CMMI-DEV offre un ensemble de comportements organisationnels ayant prouvé leur efficacité dans les domaines du développement logiciel et de l’ingénierie des systèmes. Pourquoi utiliser un tel modèle ? Quel est son objectif ? Et comment l'utiliser au mieux ? Ces questions essentielles sont peut-être les aspects les plus incompris de l'intégration CMMI.

Pourquoi utiliser un modèle ?

Les efforts d’amélioration nécessitent un modèle de fonctionnement de votre organisation, des fonctions dont ils ont besoin et de la façon dont ces fonctions interagissent. Un modèle vous donne une compréhension des éléments organisationnels et vous aide dans les discussions sur ce qui doit ou peut être amélioré et comment y arriver.

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 à prendre en compte l’ensemble tout en se concentrant sur l’amélioration ;
• il est souvent pris en charge par des formateurs et des conseillers ;
• il peut aider à résoudre les désaccords en fournissant des normes convenues.

Quel est l'objectif du modèle CMMI ?

L'objectif du modèle CMMI et d'évaluer la maturité des processus d'une organisation et de fournir une aide pour l'amélioration des processus qui permettra d'améliorer les produits. De plus, CMMI est un modèle de gestion des risques qui permet de mesurer la capacité d’une organisation à gérer les risques. La capacité de gérer les facteurs de risque dans le cadre de la capacité d’une organisation à fournir des produits de haute qualité. Une autre perspective de la gestion des risques est la performance d’une organisation en cas de stress. Une organisation à maturité et à capacité élevées peut facilement répondre à des événements inattendus et stressants. Une organisation à faible maturité et capacité a 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, toutefois, 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 au risque 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 de 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 donc, à 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 établis. 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 aveuglément des processus en situation de stress et ne pas reconnaître qu'une modification de processus pourrait être une réponse plus appropriée.

La Représentation continue modélise la capabilité 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 sur les cinq étapes.

L’utilisation du modèle intermédiaire comme base pour un programme d’amélioration de processus peut être dangereuse lorsque les implémenteurs oublient que CMMI n’est pas un processus ni un modèle de workflow. Au lieu de cela, le CMMI est conçu pour fournir des objectifs pour le processus et flux de travail à 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 a connu le succès en tant que guide d’amélioration des processus. Certains cabinets de conseil choisissent uniquement d’offrir des conseils sur le modèle continu. La différence la plus évidente est qu’un programme d’amélioration de processus conçu autour du modèle continu ne présente pas les objectifs artificiels qui sont déterminés par les niveaux de maturité. Le modèle continu se prête également plus naturellement à l’application d’une amélioration de 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

La table suivante répertorie les 22 domaines de processus qui composent le modèle CMMI (version 1.3) :

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 domaines de processus sont mappés à 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 domaine de processus. Les composants attendus sont les pratiques 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’exécutant d’en informer un é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. Les composants informatifs comprennent des pratiques secondaires de pratiques génériques et spécifiques et des produits de travail typiques.

Seuls des objectifs génériques et spécifiques sont requis. Tous les autres éléments sont fournis uniquement à titre de recommandations. Pour obtenir des exemples de composants attendus et informatifs, la littérature CMMI a extrait des données provenant de volumineux projets de systèmes d’espace et de défense. Ces projets peuvent ne pas refléter le type de projets entrepris dans votre organisation, ni les tendances les plus récentes de l'industrie telles que l'émergence de méthodes Agile software development.

Articles connexes

• Processus CMMI
• L’institut du génie logiciel publie la version 1.3 de la suite de produits CMMI
• CMMI pour le développement : recommandations pour l’intégration des processus et l’amélioration des produits, troisième édition
• CMMI pour le développement : recommandations pour l’intégration des processus et l’amélioration des produits (série SEI en génie logiciel)
• Qu’est-ce que le développement Agile ?