Principes et valeurs CMMI

De David J. Anderson. David J. Anderson est l'auteur de deux livres, « Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results » [1] publié en 2003 et « Kanban: Successful Evolutionary Change for your Technology Business » [2] publié en 2010. Il faisait partie de l'équipe qui a créé la méthode de développement logiciel Agile, développement basé sur la fonctionnalité, à Singapour entre 1997 et 1999. Il est l'auteur des principes de gestion de projets Agile définis dans la déclaration d'interdépendance datant de 2005. David a créé MSF for CMMI Process Improvement, et co-écrit la note technique du Software Engineering Institute, « CMMI or Agile: Why Not Embrace Both! » [3] Il est vice-président de Lean Software & Systems Consortium, http://www.leanssc.org et dirige un cabinet international de formation et de conseil en gestion, David J. Anderson & Associates Inc., http://www.agilemanagement.net qui aide les entreprises technologiques à améliorer leurs performances à travers de meilleures stratégies de gestion et de prise de décision.

Janvier 2012

Anderson décrit comment l'examen des organisations sous un angle lentille CMMI fournit des analyses précieuses pour les gestionnaires, les ingénieurs de production et les parties prenantes externes, y compris les clients, les investisseurs, les organismes de gouvernance et les vérificateurs.

S'applique à

Gestion du cycle de vie des applications ; CMMI

Introduction

The Meaning of Organizational Maturity

Inspiration for the CMMI Model

CMMI is a Model

Understanding CMMI Made Simple

CMMI Appraisals

Le modèle CMM d'origine a été publié pour la première fois en 1991. Il a évolué pour devenir le CMMI (Capability Maturity Model Integration) une décennie plus tard. CMMI est maintenant une famille de trois constellations (comme on les appelle) et cet article fait référence spécifiquement à CMMI pour la constellation de développement (CMMI-DEV). Le CMM a été développé pour aider le Ministère de la défense des États-Unis à mieux comprendre les échecs coûteux dans des projets logiciels dans le cadre des programmes à grande échelle pour les marchés publics de fournitures. Une évaluation basée sur CMM a été utilisée pour déterminer l'« adéquation » des contrats publics. Cela évolue ultérieurement en un modèle d'évaluation défini basé sur CMMI.

Le concept de maturité organisationnelle reste controversé. Comment par exemple, la maturité d'organisation peut être évaluée ? Est-ce que le comportement d'une organisation est réellement distinct du comportement et des actions de ses membres ? Le concept qu'une organisation peut être évaluée à un niveau particulier de maturité et qu'il s'agit d'un indicateur de la capacité à fournir un travail fiable au gouvernement fait l'objet d'un débat. Toutefois, je reste un fervent défenseur du CMMI et je crois qu'examiner les organisations à la lentille CMMI fournit des analyses précieuses pour les gestionnaires, les ingénieurs de processus et les parties prenantes externes, notamment les clients, les investisseurs, les instances et les auditeurs de gouvernance.

Signification de la maturité d'organisation

Dans CMMI, la maturité est destinée à impliquer une approche et une capacité d'évaluer et de gérer les risques et le jugement utilisés pour la prise des décisions. Le terme « maturity » (maturité) est en fait utilisé dans le sens courant utilisé pour les personnes. Par exemple, les assureurs peuvent nous indiquer que les hommes de 18 ans sont plus enclins à avoir un accident de voiture que les femmes de 55 ans. Un jeune homme de 18 ans risque d'avoir un jugement moins objectif en prenant des décisions concernant la gestion d'un véhicule et risque d'avoir une expérience insuffisante quant à l'évaluation correcte des risques impliqués dans un plan d'action spécifique. Cela peut entraîner des accidents qu'une femme à 55 ans pourrait éviter. Les compagnies d'assurance sont particulièrement bonnes pour l'évaluation des risques car elles collectent des données statistiques et effectuent une corrélation avec les preuves.

Un problème avec CMMI est la nature péjorative perçue pour le terme « maturité ». On suppose toujours que davantage de maturité est préférable à moins de maturité. Et cette maturité supérieure doit toujours être envisagée. Si nous devions considérer cela dans différents termes, cela n'aurait pas toujours un sens. Une compagnie d'assurance peut évaluer le coût d'une assurance moins chère pour les personnes plus âgées. Toutefois, une équipe de course automobile est susceptible de valoriser l'exubérance et la prise de risques des jeunes. Pour l'équipe de course, les accidents de voiture sont inhérents à l'activité. En fait, les gestionnaires qui n'ont jamais eu d'accident de voiture seront congédiés.

Cela signifie que les niveaux de maturité requis doivent correspondre aux circonstances et au contexte. Plus n'est pas nécessairement mieux, mais être capable d'identifier et d'évaluer correctement la maturité d'organisation aide à évaluer si une entreprise est capable de gérer les risques et d'effectuer un jugement approprié en prenant des décisions de projet et de produit.

Il doit y avoir une corrélation forte entre le niveau de maturité et la probabilité d'obtenir ou de fournir les résultats souhaités. Une organisation à maturité élevée a de très fortes chances d'atteindre un résultat proche du résultat attendu. Cela implique d'avoir la maturité et la capacité d'évaluer les résultats possibles, probables et réalisables et de définir les objectifs en conséquence. Une organisation à faible maturité a moins de chances de définir des objectifs réalisables et d'atteindre un résultat souhaitable par rapport à une attente. Le revers de la médaille est qu'une organisation de niveau de maturité élevé peut devenir réticente à prendre des risques et rarement définir facilement des objectifs réalisables, tandis qu'une organisation de maturité plus faible peut obtenir des résultats exceptionnels via une combinaison de chance et de travail acharné.

Inspiration pour le modèle CMMI

Le modèle CMM d'origine a été développé par Watts Humphrey et a été évoqué pour la première fois (sans toutefois porter le nom de CMM) dans l'ouvrage Managing the Software Process[4]. Il a été inspiré par le mouvement pour l'assurance qualité en production du 20ème siècle et l'ouvrage de Joseph Juran, W. Edwards Deming et Philip Crosby. Le terme « maturity model » et ses cinq niveaux ont été inspirés par le modèle Manufacturing Maturity Model de Crosby. Toutefois, CMM doit être vu comme une véritable synthèse d'idées. Le terme « capacité » est très probablement inspiré par Deming.

Deming a utilisé le terme « fonctionnalité » avec une signification très spécifique qui va peut-être bien au-delà de la simple compréhension du mot dans le langage commun. Plus précisément, une fonction peut être considérée comme « la philosophie naturelle » d'un système ou d'une opération dans un système. Deming a encouragé les gestionnaires à « étudier la fonctionnalité » et à l'analyser statistiquement. Il a développé son système de connaissances approfondies[5] qui doit être utilisé comme une infrastructure de décision pour aider les gestionnaires à effectuer des interventions de conception de systèmes pertinentes. Deming était un véritable penseur de systèmes. Dans ce cas, le mot « système » implique un processus exécuté par des personnes. Il n'y a aucun intention d'impliquer une technologie ou une automation.

Deming était convaincu, preuve à l'appui, que proposé 95 % des performances d'un système provenaient de la conception du système et non des capacités des personnes qui travaillent dans le système. En d'autres termes, pour créer l'amélioration, il doit exister un focus sur la modification du processus, le système dans lequel les personnes travaillent, plutôt qu'un focus sur l'amélioration de la performance individuelle. Par conséquent, il ne croyait pas aux objectifs, à la gestion par les objectifs, aux affiches de motivation ou à la punition des personnes en raison de performances médiocres.

Deming a donc fourni à un modèle de fonction avec son système de connaissances approfondie, et Crosby a fourni un modèle de maturité. Humphrey a pensé à synthétiser ces concepts ensemble et à les appliquer au champ de l'ingénierie logicielle, et il en résulte le processus CMM (Capability Maturity Model).

Vu que le focus sur l'estimation et la poursuite des niveaux de maturité à qualifier des contrats gouvernementaux, la modélisation de la capacité et l'influence de Deming ont disparu en grande partie de la documentation sur CMM et CMMI. Toutefois, l'influence de Deming peut être clairement vue dans les zones de processus définies à des niveaux de maturité plus élevés.

Le modèle CMMI a toujours été destiné à représenter une infrastructure permettant d'encourager l'émergence d'une culture d'amélioration continue au sein d'une organisation, et il a toujours été destiné à être un mode de pensée systémique. Les racines de CMMI présentent des analogies évidentes avec Lean.

CMMI est un modèle

Le CMMI est un modèle pour comprendre la maturité et les capacités organisationnelles. Il ne s'agit pas d'une norme ou d'un développement logiciel ou d'une définition d'un processus de développement logiciel. Les méthodes génériques décrites dans cet article font référence aux capacités de processus et non à un projet ou un produit donné en cours de développement. Par exemple, la planification, qui est indiquée dans le tableau suivant, fait référence à l'organisation de l'implémentation des processus et non pas à une livraison de projet ou de produit.

Le modèle CMMI se compose de 22 domaines de processus, ainsi que de trois objectifs génériques que toutes les organisations doivent poursuivre.

Les 3 objectifs génériques sont les suivantes :

Les 22 domaines de processus sont organisés en 4 catégories : ingénierie, gestion de projet, gestion des processus, et prise en charge. Chaque processus est constitué d'un à trois objectifs spécifiques et des trois objectifs génériques. Pour chaque objectif, plusieurs méthodes sont fréquemment prévues pour que cet objectif soit atteint. Dans une pratique, il peut y avoir des sous-pratiques suggérées. Le modèle CMMI requiert ou prescrit uniquement les objectifs. Les méthodes définies dans les objectifs du modèle CMMI sont destinées mais ne sont pas obligatoires. En cas d'absence, elles doivent être substituées par une pratique de remplacement équivalente. Le tableau suivant indique le regroupement des processus :

Focus d'organisation	Domaine de traitement
Ingénierie	Développement des spécifications Solution technique Intégration de produit Vérification Validation
Gestion de projet	Planification de projet Suivi et contrôle de projet Gestion de projet intégrée Gestion des accords avec les fournisseurs Gestion des spécifications Gestion des risques Gestion de projet quantitative
Gestion des processus	Focus de processus d'organisation Définition de processus organisationnels Formation organisationnelle Performances des processus organisationnels Innovation et déploiement organisationnels
Prise en charge	Gestion de la configuration Assurance qualité de processus et produits Mesures et analyses Analyse de décision et résolution Analyse causale et résolution

Le principe est simple : si une organisation peut se montrer capable d'atteindre les objectifs de chaque domaine de processus, alors elle peut indiquer avoir la capacité dans ce domaine de processus particulier.

Les domaines de processus sont également regroupés en niveaux de maturité, qui fournissent une méthode abrégée pour décrire la maturité. Bien que le regroupement des domaines de processus en niveaux reste controversé sur plusieurs niveaux, la version actuelle 1.3 du modèle (en considérant que le CMMI est bien la version 2 du CMM) est tout à fait correcte d'après mon observation des organisations au cours des deux dernières décennies. Les organisations chaotiques de faible maturité ont tendance à développer des capacités dans les domaines de processus définis au niveau de maturité 2 avant de développer des capacités dans les domaines de processus définis à des niveaux supérieurs.

Le tableau suivant indique le regroupement des processus dans des niveaux.

Niveau de maturité	Domaines de processus
5	CAR – Analyse causale et résolution OPM - gestion des performances organisationnelles
4	OPP – Performances des processus organisationnels QPM – Gestion de projet quantitative
3	RD – Développement des spécifications TS – Solution technique PI – Intégration de produit VER – Vérification VAL – Validation IPM – Gestion de projet intégrée RSKM – Gestion des risques OPF – Focus de processus d'organisation OPD – Définition de processus organisationnels OT – Formation organisationnelle DAR – Analyse de décision et résolution Assurance qualité de processus et produits
2	CM – Gestion de la configuration MA – Mesures et analyses SAM – Gestion des accords avec les fournisseurs PP – Planification de projet PMC – Suivi et contrôle de projet RM – Gestion des spécifications
1	Le modèle de niveau 1 ne comporte aucun domaine de processus. Le niveau 1 représente un processus non défini sans l'introspection ou la possibilité de définir un processus ou de répéter des résultats via la présentation du processus qui l'a produite. Techniquement, dans une évaluation CMMI, une organisation qui n'atteint pas les objectifs pour les processus du niveau 2 du modèle reste un modèle de niveau 1. Donc les organisations avec des processus émergents seront techniquement encore considérées comme un modèle de niveau 1 même si elles ont beaucoup mûri depuis le chaos de départ.

Le tableau suivant présente une vue d'ensemble en termes de disposition de l'objet ou de l'objectif de chaque processus :

Domaine de traitement	Objectif
CAR – Analyse causale et résolution	rechercher la cause première des problèmes de processus exceptionnels (variations de cause spéciales, pour utiliser le W. le vocabulaire d'Edwards Deming), et proposent et implémentent les modifications de processus pour empêcher une récurrence. L'attention est dirigée sur le comportement inhabituel des processus stables compris de manière quantitative. Les surprises quotidiennes seraient probablement considérées comme une composante de la gestion des risques (RSKM, risk Management) plutôt que de l'analyse causale et résolution (CAR).
CM – Gestion de la configuration	Outre le contrôle de version du code source, ce domaine de processus couvre l'ensemble des tâches administratives liées aux environnements système, les configurations de composants, les plateformes, les logiciels intermédiaires, les applications et la documentation. La capacité à générer et à déployer correctement du code fait partie de ce processus.
DAR - Analyse de décision et résolution	Pour toutes les décisions importantes dans un projet ou un développement de produit, indiquez qu'un ensemble de solutions de remplacement ou des options ont été prises en compte et que les éléments contextuels ont été utilisés pour évaluer la conformité des différentes options. Enregistrez la décision et les raisons du choix.
IPM - Gestion de projet intégrée	Ce deuxième niveau de gestion de projet dans le modèle CMMI implique qu'une société est capable de gérer simultanément plusieurs projets potentiellement dépendants. On y parvient souvent en utilisant un bureau de gestion de programme ou de portefeuille.
MA – Mesures et analyses	Collecter des données sur le processus, le projet et les performances du produit. Génère des métriques et des indicateurs sous forme de rapports sur les données.
OPD - Définition de processus organisationnels	La société doit avoir une ou plusieurs définitions de processus définies dans un contexte. Un contexte décrira un profil de risque. Chaque projet peut être évalué en fonction de ses risques et d'une définition de processus sélectionnée dans le catalogue organisationnel, puis adapté de manière appropriée.
OPF – Focus de processus d'organisation	La société doit considérer que la définition de processus définit et affecte la capacité et que l'amélioration de la capacité provient principalement de l'amélioration des processus. Par conséquent, l'organisation gère proactivement ses définitions de processus et surveille (à l'aide du domaine de processus PPQA) pour assurer que ces définitions sont suivies.
OPM - gestion des performances organisationnelles	Ce processus encapsule le concept de connaissances statistiques des performances par rapport à la capacité attendue. Les modifications apportées au processus destiné à améliorer la capacité sont accessibles et le modèle sous-jacent du processus être considérées si les résultats observés ne reflètent pas ceux attendus par le modèle de processus sous-jacent au moment où la définition de processus a été modifiée. La société gère ses performances via ses processus afin de répondre à ses besoins.
OPP – Performances des processus organisationnels	Ce processus encapsule le concept de la comparaison de performances, souvent appelé « benchmarking ». OPP crée des modèles de processus à partir de données de planification pour permettre la comparaison. Cela permet à une société de répondre à des questions telles que « Parmi nos trois équipes de produit, laquelle devrions nous choisir pour [ce projet spécifique] ? »
Formation organisationnelle	Les capacités individuelles pour les pratiques spécifiques sont importantes pour les performances de processus et les fonctionnalités système. Un système à fortes performances qui se comporte correctement disposera d'une forte capacité à réduire la variabilité des capacités au niveau de pratique local.
Intégration de produit	Capacité à intégrer plusieurs composants pour former un produit complet et à gérer les éléments requis pour le rendre possible.
Suivi et contrôle de projet	Rassemblez les données relatives aux projets récents, comparez-les à des plans, des projections et des simulations, et prenez les mesures appropriées en fonction des données.
Planification de projet	Planifiez des projets en fonction des évaluations, des simulations, et de l'analyse des spécifications.
Assurance qualité de processus et produits	Essentiellement une fonction d'audit de compatibilité de processus. Conçu pour montrer que le système fonctionne conformément aux spécifications. Permet d'éviter des erreurs de gestion potentielles pour modifier le processus de résolution d'un problème lorsque le processus actuel n'est pas respecté réellement comme prévu.
Gestion de projet quantitative	Il s'agit du troisième niveau, le niveau supérieur, de la gestion de projet dans le modèle CMMI. Il implique que, statistiquement saines, les méthodes quantitatives sont utilisées pour planifier, surveiller et gérer des projets.
Développement des spécifications	Il existe un processus défini et reproductible pour solliciter, négocier, analyser et documenter les spécifications.
Gestion des spécifications	Les spécifications sont suivies durant tout le cycle de projet et il existe, idéalement, une traçabilité de bout en bout entre une configuration fournie et la requête d'origine des spécifications.
Gestion des risques	Bien que le modèle CMMI global puisse être considéré comme une infrastructure de gestion des risques, ce domaine de processus traite spécifiquement du « risque événementiel » ou de la probabilité et de l'impact des variations de cause spéciales et des surprises quotidiennes. Ce processus requiert la réduction des risques, l'atténuation, la planification d'urgence, la gestion des problèmes et la résolution.
Gestion des accords avec les fournisseurs	Capacité à gérer des fournisseurs externes, à définir des contrats, à gérer le contrat, et à accepter la fourniture du produit ou du service souhaité.
Solution technique	Toutes les compétences requises relatives à l'architecture, la conception et le codage de logiciels.
Validation	Test d'acceptation par rapport aux spécifications du client.
Vérification	Test par rapport à une conception (à partir de la solution technique). Cherche à s'assurer que le produit actuellement généré est conçu comme prévu, et remonté de façon à répondre aux besoins des utilisateurs et fonctionne dans leur environnement.

Pour chaque processus, un niveau de capacité peut être évalué. Quatre niveaux de capacité sont définis dans la v1.3 de CMMI :

0. Incomplet

1. Effectué

2. Managed

3. (défini par)

Si chaque objectif spécifique est atteint et certains objectifs génériques sont atteints, la capacité pour une zone de processus spécifique est relevée d'au moins un niveau. Le niveau 1 de la capacité implique que les membres de l'équipe savent quoi faire et le font effectivement. Toutefois, la pratique spécifique a peu de chances d'afficher la stabilité si elle est analysée statistiquement. Les pratiques sont suivies, mais il existe toujours un manque de cohérence. Le niveau 2 de la capacité implique que l'équipe comprend comment fonctionne un élément et dispose d'un niveau de compétence qui rend la performance d'une pratique prévisible et qui inclut le contrôle statistique. Il est probable que la formation ou les méthodes de travail collaboratives sont en place pour accroître la cohérence entre les membres de l'équipe. Le niveau 3 de la capacité implique une maîtrise de la compétence et la possibilité de développer des techniques nouvelles et améliorées qui permettent d'atteindre l'objectif. La capacité de niveau 3 implique que toute analyse statistique nécessiterait la nouvelle définition des références après chaque modification explicite de la technique ou pratique sous-jacente.

Simplicité de compréhension de CMMI

Le modèle CMMI déclare fondamentalement que les organisations nouvelles et immatures, au début, développeront des fonctions en pratique pour gérer les configurations et le contrôle de la source, pour collecter des données sur les projets et le travail qu'elles entreprennent, pour planifier des projets, le suivi des spécifications, surveiller la progression des projets, et prendre des mesures en fonction de la comparaison des données réelles par rapport à un plan. C'est l'essence même du niveau de maturité 2.

Alors que les fonctions de niveau 2 de maturité se mettent en place, l'organisation et ses membres commencent à s'intéresser à d'autres problèmes. Ainsi, la capacité à définir des spécifications, les tests, l'architecture et la conception, l'intégration et des processus qui peuvent être répétés commence à émerger. Avec la stabilisation de la situation, on comprend mieux la manière dont la culture et le style de gestion affectent les performances et, qu'un mode de pensée systémique est nécessaire pour améliorer les performances. Lorsque les choses deviennent plus stables et que les problèmes quotidiens tels que la planification et le contrôle de projet deviennent une seconde nature, il reste du temps pour prendre en compte la gestion des risques et les possibilités et options d'analyse avant de prendre des décisions. La coordination de plusieurs projets dépendants et d'une gouvernance améliorée des ressources partagées peut être effectuée. Il est possible qu'un programme de formation, un modèle de tutorat, un modèle de tutorat maître-élève ou simplement des formulaires classiques de travail collaboratif émergent pour améliorer les capacités et élever le niveau de performance global. Si nécessaire, un audit interne ou une fonction d'assurance qualité de processus peut émerger. Tout ceci constitue l'essence du niveau de maturité 3.

Lorsqu'une organisation s'exécute à un niveau de maturité 3 solide, tout fonctionne parfaitement. La société tient ses promesses et est considérée très fiable et digne de confiance. Un niveau de confiance élevé découle des relations avec les clients. Les responsables seniors commencent à poser des questions telles que « Dans quoi devrais-je investir pour de meilleurs résultats ? » et « Quelle équipe génère les meilleures performances économiques ? » Les directeurs commencent à développer des analyses plus avancées des capacités et des performances et se rendent compte qu'ils peuvent utiliser la simulation et l'analyse statistique pour améliorer la qualité du produit, la livraison au client et la satisfaction du client. Les décisions de gestion sont désormais totalement objectives et défendables avec les données statistiques. C'est l'essence même d'une société de niveau de maturité 4. Pour la plupart des responsables seniors, le niveau de maturité 4 représente leur état idéal. Tout fonctionne parfaitement avec des données de performances comparatives et la possibilité de tenir les promesses faites à un niveau élevé de précision. Les performances économiques sont considérablement améliorées et les performances de l'organisation sont fortement prévisibles.

Les comportements de maturité de niveau 5 émergent souvent longtemps avant qu'une organisation n'atteigne réellement le niveau 5. L'analyse de la cause première est souvent observé dans des organisations de niveau 3 de maturité. Si l'analyse de la cause première est effectuée à l'aide de données quantitatives et est statistiquement défendable, cela en fait une fonction de niveau 5. L'émergence d'un processus formalisé pour l'innovation de processus et le déploiement des améliorations peut également se produire avant que l'organisation puisse vraiment être considérée au niveau 5 de maturité. Au niveau 5, l'amélioration des processus a été institutionalisée et inculquée dans la culture de l'organisation. La culture consiste à toujours à dépasser le statu quo et rechercher à améliorer les capacités, la qualité des produits et les performances économiques.

Évaluations CMMI

Une évaluation de la maturité CMMI est établie par une évaluation. Un processus standard permet d'effectuer des évaluations : SCAMPI, méthode d'évaluation CMMI standard pour l'amélioration des processus. Cela a été introduit pour apporter de la répétabilité au processus et de la confiance dans les résultats. Le évaluations sont classées suivant trois niveaux de rigueur : classe A, B, et C, la classe A étant la plus rigoureuse. Les évaluations de la classe A sont requises pour une évaluation au niveau du modèle qui soit acceptable pour les spécifications du domaine public ou du Ministère de la défense des États-unis.

Toutes les évaluations de classe A et la plupart des évaluations de classe B et C sont menées par les experts CMMI, qui sont autorisés par le Software Engineering Institute à réaliser des évaluations. Les consultants ont suivi d'un programme de formation complet avant d'être autorisés à pratiquer. Certains experts ont suivi une formation complémentaire et sont désignés comme experts à maturité élevée CMMI. Les organisations qui recherchent un modèle d'évaluation de niveau 4 ou 5 doivent utiliser un expert à maturité élevée.

L'évaluation recherche des preuves que les méthodes ont été conduites pour atteindre les objectifs dans les domaines de processus du CMMI. Dans une organisation exécutant un portefeuille de projets et éventuellement avec plusieurs divisions commerciales, une formule complexe est utilisée pour déterminer le nombre de projets dont la portée doit être évaluée. L'objectif de cette opération est de garantir la couverture juste d'un exemple d'ensemble de projets qui montrent que l'organisation présente une capacité institutionnalisée dans chaque processus requis. L'expert détermine les projets à évaluer selon cette formule.

Dans chaque projet évalué, des preuves démontrant que les pratiques ont été terminées doivent être collectées, car elles sont requises pour afficher la capacité suffisante dans la zone du processus. Pour chaque pratique, un expert recherche les preuves difficiles et réelles, appelés artefacts et sont souvent trouvées dans la preuve justificative telles que les plans, le code source, les conceptions et les documents d'architecture. De plus, elles recherchent des affirmations. Une affirmation est généralement une preuve par ouï-dire, par exemple, des membres du personnel discutant de la conduite d'une pratique, ou des anecdotes sur la participation à une réunion de planification. Des affirmations sont collectées en interviewant le personnel impliqué dans les projets évalués. Les affirmations peuvent renforcer la preuve justificative ou la réfuter, incitant l'expert à remettre en cause la validité des documents.

Les évaluations CMMI ne sont pas requises pour que le modèle CMMI soit utile. Le CMMI aide les organisations de développement de logiciels à comprendre leur capacité et leur maturité et comparent cela aux attentes de leurs clients et des autres parties prenantes externes. Le fait d'avoir une idée approximative de l'emplacement où une organisation effectue les mappages par rapport au modèle CMMI permet d'évaluer comment elle peut réagir sous contrainte et sa capacité de livraison par rapport aux attentes. Les organisations ont noté qu'exécuter des activités de maturité supérieure sans avoir de base solide des comportements de maturité inférieure peut souvent être imprévisible. C'est alors que les comportements élevés de maturité sont présents et cela est louable, ces pratiques de maturité élevées ne sont pas toutes fiables et ne sont pas construites sur une base solide.

Les évaluations CMMI sont souvent utilisées comme un moyen de valider une initiative d'amélioration de processus à l'échelle de l'organisation. La pression de « réussir le test » est réelle. L'objectif est alors de montrer que chaque pratique est bien suivie dans chaque domaine de processus et d'en apporter la preuve. Les éléments réellement importants peuvent alors être perdus de vue, par exemple montrer son aptitude à répondre aux attentes du client et améliorer cette aptitude grâce à des actions de gestion explicites. L'objectif de « réussir le test » a souvent provoqué des effets secondaires et des dysfonctionnements significatifs dans les sociétés. Par conséquent, le modèle CMMI a connu de nombreux détracteurs dans l'industrie. C'est vraiment dommage, car je crois réellement que le modèle CMMI est valide et qu'il fournit des analyses précieuses pour les gestionnaires d'une société. Ces analyses doivent permettre d'améliorer la capacité, les performances et la satisfaction des clients.

[1] Anderson, David J., « Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results », Prentice Hall PTR, 2003

[2] Anderson, David J., « Kanban: Successful Evolutionary Change for your Technology Business », Blue Hole Press, 2010

[3] Glazer, Hillel et Jeff Dalton, David J. Anderson, Michael D. Konrad, Sandra Shrum, CMMI or Agile: Why not embrace both!, Software Engineering Institute, November 2008

[4] Humphrey, Watts S., « Managing the Software Process », Addison Wesley Professional, 1989

[5] Deming, W. Edwards, The New Economics for Industry, Government, Education, 2nd Edition, The MIT Press, 2000