Développé par le Software Engineering Institute américain à la fin des années 1980, le modèle CMM (Capability maturity model) définit les meilleures pratiques permettant d’optimiser les performances des projets logiciels. Le résultat permet de juger du niveau de maturité de l’entreprise. Le CMM définit une échelle de cinq niveaux de maturité : de 1 (niveau initial) à 5 (niveau d’optimisation).
A chacun de ces niveaux de maturité correspondent des secteurs clés, au nombre de 2 à 7 par niveau. Le premier niveau caractérise les entreprises pour lesquelles n’existe aucun pré-requis en matière de développement et de maintenance logiciel. Au détriment du respect des délais, de la disponibilité des applications et des bogues…
Au niveau 2 (niveau reproductible), apparaissent une gestion des exigences (entre l’utilisateur et le logiciel), des procédures de planification, de suivi et de supervision des projets logiciels (pour les coûts, les délais, les fonctionnalités…), une gestion formalisée de la sous-traitance, une assurance qualité et une gestion de la configuration logiciel. Le niveau 3 (niveau défini) se caractérise, entre autres, par des processus documentés et normalisés de développement et de maintenance, un suivi qualité, un programme de formation. Le niveau 4 (niveau maîtrisé) intègre la gestion de la qualité logiciel, avec des objectifs quantitatifs et une base de données spécifique. Les variations de performances sont contrôlées (en distinguant les variations aléatoires et significatives). La capacité du processus logiciel, à ce niveau, est dite prévisible, dans la mesure où ce processus opère dans des limites mesurables.
Enfin, au niveau 5 (niveau d’optimisation) interviennent la prévention des défauts, la gestion des changements technologiques et de processus. Pour atteindre un niveau de maturité x, une entreprise doit satisfaire à tous les objectifs que l’on peut regrouper en trois catégories : les processus de gestion (planification, suivi, supervision, assurance-qualité…), les processus organisationnels (gestion du changement, formation…) et les processus d’ingénierie (prévention des bogues, gestion de la qualité…).
Le CMM intègre également environ 300 pratiques clés, qui précisent ce qui est à faire (mais pas comment le faire…). Ces pratiques clés sont réparties en cinq caractéristiques communes : l’engagement de réalisation (mise en place de directives avec l’appui de la direction générale), la capacité de réalisation (ressources, structures, formation), les activités réalisées (description des rôles et des procédures, actions correctrices…), les mesures et analyses (exemple de mesures pour déterminer l’état et l’efficacité des activités réalisées), vérification et mise en œuvre (audit et assurance-qualité).
D’où vient le CMM ?
Le CMM a été la réponse directe, dans les années 1980, à la frustration ressentie par l’Air Force dans son processus d’achat de logiciels. L’Air Force et d’autres divisions du département de la Défense avaient commencé à sous-traiter des quantités sans cesse croissantes de développement et peinaient dans le choix des entreprises. La Carnegie Mellon University emporta l’offre qui visait à créer une organisation, le SEI, pour améliorer le processus d’enquêtes sur les fournisseurs. En 1986, le SEI embaucha Watts Humphrey, ancien chef de projet informatique d’IBM, pour l’associer à ces travaux.
Watts Humphrey diagnostiqua immédiatement que l’Air Force courait après un faux problème. « Nous nous étions concentrés sur l’identification des personnes compétentes, mais nous n’avions pas vu que tous les projets étaient en situation difficile – indépendamment des exécutants », se rappelle-t-il. « Donc nous avons dit : concentrons-nous sur l’amélioration du travail plutôt que sur les propositions seulement ».
En 1987, la première version du modèle CMM consistait en un questionnaire destiné à identifier les bonnes pratiques logicielles au sein des entreprises soumettantes. Mais la forme du questionnaire était telle que les entreprises n’avaient pas besoin d’être bonnes à quoi que ce soit, sinon à remplir les questionnaires. « Il était facile de plancher pour le test », dit Jesse Martak, ancien chef du groupe de développement de la branche Défense de Westinghouse, maintenant propriété de Northrop Grumman. « Nous savions comment traiter le système. »
En 1991, le SEI a donc redéfini ce système, pour en faire un modèle détaillé de bonnes pratiques logicielles, et procédé à la mise en place d’un groupe de certificateurs seniors, formés et autorisés par le SEI à aller dans les entreprises vérifier si elles faisaient vraiment ce qu’elles disaient faire. Les certificateurs seniors sont à la tête d’une équipe de personnes issues de l’entreprise en cours d’évaluation (en règle générale de trois à sept, selon la taille de l’entreprise). Ensemble, ils cherchent à prouver que l’entreprise met en place les règles et procédures du CMM, sur la base d’un échantillon « représentatif » de projets de l’entreprise (en règle générale entre 10 et 30 %). L’équipe mène aussi une série d’entretiens confidentiels avec chefs de projet et développeurs – en règle générale sur une à trois semaines selon, de nouveau, la taille de la structure – pour vérifier ce qui s’y passe réellement. Il s’agit d’une mission difficile pour le personnel interne de l’équipe, car on leur demande de dénoncer leurs collègues.