Modèle de maturité des capacités

Le modèle de maturité des capacités ( CMM ) est un modèle de développement créé en 1986 après une étude de données recueillies auprès d'organisations ayant signé un contrat avec le ministère de la Défense américain , qui a financé la recherche. Le terme « maturité » fait référence au degré de formalité et d'optimisation des processus, depuis les pratiques ad hoc jusqu'aux étapes formellement définies, en passant par les mesures de résultats gérées et l'optimisation active des processus.

L’objectif du modèle est d’améliorer les processus de développement de logiciels existants , mais il peut également être appliqué à d’autres processus.

En 2006, le Software Engineering Institute de l'Université Carnegie Mellon a développé le modèle d'intégration de la maturité des capacités , qui a largement remplacé le CMM et corrige certains de ses inconvénients.

Le modèle de maturité des capacités a été développé à l'origine comme un outil permettant d'évaluer objectivement la capacité des processus des entrepreneurs gouvernementaux à mettre en œuvre un projet logiciel sous contrat. Le modèle est basé sur le cadre de maturité des processus décrit pour la première fois dans IEEE SoftwareManaging the Software Process de Watts Humphrey paru en 1989. Il a ensuite été publié sous forme d'article en 1993 et sous forme de livre par les mêmes auteurs en 1994

Bien que le modèle provienne du domaine du développement de logiciels , il est également utilisé comme modèle pour aider aux processus commerciaux en général et a également été largement utilisé dans le monde entier dans les bureaux gouvernementaux, le commerce et l'industrie.

Dans les années 1980, l'utilisation des ordinateurs s'est généralisée, est devenue plus souple et moins coûteuse. Les organisations ont commencé à adopter des systèmes d'information informatisés et la demande de développement de logiciels a augmenté de manière significative. De nombreux processus de développement de logiciels en étaient encore à leurs balbutiements, avec peu d'approches standard ou de « meilleures pratiques » définies.

En conséquence, la croissance s'est accompagnée de difficultés de croissance : les échecs de projets étaient fréquents, le domaine de l'informatique en était encore à ses débuts et les ambitions en termes d'échelle et de complexité des projets dépassaient la capacité du marché à fournir des produits adéquats dans le cadre d'un budget prévu. Des individus tels qu'Edward Yourdon , Larry Constantine , Gerald Weinberg , Tom DeMarco , et David Parnas ont commencé à publier des articles et des livres avec les résultats de leurs recherches dans le but de professionnaliser les processus de développement de logiciels.

Dans les années 1980, plusieurs projets militaires américains impliquant des sous-traitants de logiciels ont dépassé le budget prévu et ont été achevés bien plus tard que prévu, voire pas du tout. Pour tenter de déterminer les raisons de ce phénomène, l' armée de l'air américaine a financé une étude au Software Engineering Institute (SEI).

La première application d'un modèle de maturité par étapes à l'informatique n'a pas été réalisée par CMU/SEI, mais plutôt par Richard L. Nolan , qui, en 1973, a publié le modèle des étapes de croissance pour les organisations informatiques.

Watts Humphrey a commencé à développer ses concepts de maturité des processus au cours des dernières étapes de sa carrière de 27 ans chez IBM.

Le développement actif du modèle par le Software Engineering Institute (SEI) du Département de la Défense des États-Unis a commencé en 1986 lorsque Humphrey a rejoint le Software Engineering Institute situé à l'Université Carnegie Mellon de Pittsburgh, en Pennsylvanie , après avoir pris sa retraite d'IBM. À la demande de l'US Air Force, il a commencé à formaliser son cadre de maturité des processus pour aider le Département de la Défense des États-Unis à évaluer la capacité des sous-traitants de logiciels dans le cadre de l'attribution des contrats.

Le résultat de l'étude de l'Air Force a été un modèle que l'armée peut utiliser comme une évaluation objective de la maturité des processus des sous-traitants de logiciels. Humphrey a basé ce cadre sur la grille de maturité de la gestion de la qualité développée par Philip B. Crosby dans son livre « Quality is Free ». L'approche de Humphrey diffère en raison de son idée unique selon laquelle les organisations font mûrir leurs processus par étapes en fonction de la résolution des problèmes de processus dans un ordre spécifique. Humphrey a basé son approche sur l'évolution par étapes d'un système de pratiques de développement de logiciels au sein d'une organisation, plutôt que de mesurer la maturité de chaque processus de développement distinct indépendamment. Le CMMI a donc été utilisé par différentes organisations comme un outil général et puissant pour comprendre puis améliorer les performances générales des processus d'entreprise.

Le modèle de maturité des capacités (CMM) de Watts Humphrey a été publié en 1988 et sous forme de livre en 1989, dans Managing the Software Process .

Les organisations ont été initialement évaluées à l’aide d’un questionnaire de maturité des processus et d’une méthode d’évaluation des capacités logicielles conçue par Humphrey et ses collègues du Software Engineering Institute.

La représentation complète du modèle de maturité des capacités en tant qu'ensemble de domaines de processus et de pratiques définis à chacun des cinq niveaux de maturité a été initiée en 1991, la version 1.1 étant publiée en juillet 1993. Le CMM a été publié sous forme de livre en 1994 par les mêmes auteurs Mark C. Paulk, Charles V. Weber, Bill Curtis et Mary Beth Chrissis.

L'application du modèle CMMI au développement de logiciels a parfois été problématique. L'application de plusieurs modèles qui ne sont pas intégrés au sein d'une organisation peut être coûteuse en termes de formation, d'évaluation et d'activités d'amélioration. Le projet Capability Maturity Model Integration (CMMI) a été formé pour résoudre le problème de l'utilisation de plusieurs modèles pour les processus de développement de logiciels. Le modèle CMMI a ainsi remplacé le modèle CMMI, bien que le modèle CMMI continue d'être un modèle de capacité de processus théorique général utilisé dans le domaine public.

En 2016, la responsabilité du CMMI a été transférée à l'Information Systems Audit and Control Association (ISACA). L'ISACA a ensuite publié le CMMI v2.0 en 2021. Il a été à nouveau mis à niveau vers le CMMI v3.0 en 2023. Le CMMI met désormais davantage l'accent sur l'architecture des processus, qui est généralement réalisée sous la forme d'un diagramme de processus. Les exemplaires du CMMI ne sont désormais disponibles que sur abonnement.

Le CMMI a été initialement conçu comme un outil permettant d'évaluer la capacité des entrepreneurs gouvernementaux à réaliser un projet logiciel sous contrat. Bien qu'il provienne du domaine du développement logiciel, il peut être, a été et continue d'être largement appliqué comme modèle général de maturité des processus (par exemple, les processus de gestion des services informatiques ) dans les organisations SI/IT (et autres).

Un modèle de maturité peut être considéré comme un ensemble de niveaux structurés qui décrivent dans quelle mesure les comportements, les pratiques et les processus d’une organisation peuvent produire de manière fiable et durable les résultats requis.

Un modèle de maturité peut être utilisé comme référence pour la comparaison et comme aide à la compréhension, par exemple pour l'évaluation comparative de différentes organisations lorsqu'elles ont un point commun qui peut servir de base de comparaison. Dans le cas du CMM, par exemple, la base de comparaison serait constituée par les processus de développement logiciel des organisations.

Le modèle comporte cinq aspects :

• Niveaux de maturité : un continuum de maturité des processus à 5 niveaux - où le niveau le plus élevé (5e) est un état idéal notionnel dans lequel les processus seraient systématiquement gérés par une combinaison d'optimisation des processus et d'amélioration continue des processus.
• Domaines de processus clés : un domaine de processus clé identifie un ensemble d’activités connexes qui, lorsqu’elles sont exécutées ensemble, permettent d’atteindre un ensemble d’objectifs considérés comme importants.
• Objectifs : les objectifs d'un domaine de processus clé résument les états qui doivent exister pour que ce domaine de processus clé soit mis en œuvre de manière efficace et durable. Le degré d'accomplissement des objectifs est un indicateur du niveau de capacité que l'organisation a établi à ce niveau de maturité. Les objectifs indiquent la portée, les limites et l'intention de chaque domaine de processus clé.
• Caractéristiques communes : les caractéristiques communes comprennent les pratiques qui mettent en œuvre et institutionnalisent un domaine de processus clé. Il existe cinq types de caractéristiques communes : l'engagement à réaliser, la capacité à réaliser, les activités réalisées, la mesure et l'analyse, et la vérification de la mise en œuvre.
• Pratiques clés : Les pratiques clés décrivent les éléments d’infrastructure et de pratique qui contribuent le plus efficacement à la mise en œuvre et à l’institutionnalisation du domaine.

Cinq niveaux sont définis le long du continuum du modèle et, selon le SEI : « La prévisibilité, l'efficacité et le contrôle des processus logiciels d'une organisation sont censés s'améliorer à mesure que l'organisation progresse dans ces cinq niveaux. Bien que cela ne soit pas rigoureux, les preuves empiriques à ce jour soutiennent cette croyance ».

1. Initial (chaotique, ad hoc, héroïsme individuel) - le point de départ de l'utilisation d'un processus de répétition nouveau ou non documenté.
2. Répétable - le processus est au moins suffisamment documenté pour que la répétition des mêmes étapes puisse être tentée.
3. Défini - le processus est défini/confirmé comme un processus métier standard
4. Capable – le processus est géré quantitativement conformément à des paramètres convenus.
5. Efficace – la gestion des processus inclut l’optimisation/l’amélioration délibérée des processus.

Chacun de ces niveaux de maturité est caractérisé par des domaines de processus clés, chacun desquels se décline en cinq facteurs : les objectifs, l'engagement, la capacité, la mesure et la vérification. Ces facteurs ne sont pas nécessairement propres au CMMI, car ils représentent les étapes que les organisations doivent franchir pour devenir matures.

Le modèle fournit un continuum théorique le long duquel la maturité du processus peut être développée progressivement d'un niveau à l'autre. Il n'est pas autorisé/possible de sauter des niveaux.

Niveau 1 - Initial

Les processus à ce niveau se caractérisent par le fait qu'ils ne sont (généralement) pas documentés et qu'ils évoluent de manière dynamique, tendant à être pilotés de manière ad hoc , incontrôlée et réactive par les utilisateurs ou les événements. Cela crée un environnement chaotique ou instable pour les processus (exemple : un chirurgien effectuant une nouvelle opération un petit nombre de fois, les niveaux de résultats négatifs ne sont pas connus).

Niveau 2 – Répétable

Ce niveau de maturité se caractérise par le fait que certains processus sont répétables et peuvent donner des résultats cohérents. La discipline des processus n'est probablement pas rigoureuse, mais lorsqu'elle existe, elle peut contribuer à garantir que les processus existants sont maintenus en période de stress.

Niveau 3 – Défini

Les processus de ce niveau se caractérisent par l'existence d'ensembles de processus standards définis et documentés, établis et susceptibles d'être améliorés dans une certaine mesure au fil du temps. Ces processus standards sont en place. Il se peut que les processus n'aient pas été utilisés de manière systématique ou répétée, suffisamment pour que les utilisateurs deviennent compétents ou que le processus soit validé dans diverses situations. Cela peut être considéré comme une étape de développement : avec une utilisation dans un éventail plus large de conditions et le développement des compétences des utilisateurs, le processus peut évoluer vers un niveau de maturité supérieur.

Niveau 4 – Géré (capable)

Il est caractéristique des processus à ce niveau que, grâce à des mesures de processus, la réalisation effective des objectifs du processus peut être démontrée dans une gamme de conditions opérationnelles. L'adéquation du processus dans de multiples environnements a été testée et le processus a été affiné et adapté. Les utilisateurs du processus ont expérimenté le processus dans des conditions multiples et variées et sont en mesure de démontrer leur compétence. La maturité du processus permet des adaptations à des projets particuliers sans pertes mesurables de qualité ou d'écarts par rapport aux spécifications. La capacité du processus est établie à partir de ce niveau. (Exemple : chirurgien effectuant une opération des centaines de fois avec des niveaux de résultats négatifs proches de zéro).

Niveau 5 – Optimisation (efficace)

À ce niveau de maturité, les processus se caractérisent par le fait qu'ils visent à améliorer continuellement leurs performances par des changements/améliorations technologiques à la fois progressifs et innovants. Au niveau de maturité 5, les processus visent à traiter les causes statistiques communes de variation des processus et à modifier le processus (par exemple, pour modifier la moyenne des performances du processus) afin d'améliorer ses performances. Cela se fera en même temps que la probabilité d'atteindre les objectifs quantitatifs d'amélioration des processus établis sera maintenue.

Entre 2008 et 2019, environ 12 % des évaluations données se situaient aux niveaux de maturité 4 et 5.

Le modèle était initialement destiné à évaluer la capacité des entrepreneurs gouvernementaux à réaliser un projet logiciel. Il a été utilisé à cette fin et peut être adapté à cette fin, mais les critiques ont souligné que la maturité du processus selon le CMM n'était pas nécessairement obligatoire pour un développement logiciel réussi.

Le cadre de processus logiciel documenté est destiné à guider ceux qui souhaitent évaluer la cohérence d'une organisation ou d'un projet avec les domaines de processus clés. Pour chaque niveau de maturité, il existe cinq types de listes de contrôle :