Concepts du Capability Maturity Model

De la maîtrise des processus d'ingénierie du logiciel découle la maîtrise de la qualité des produits et des services issus de ces processus. Cette qualité mesurable est une caractéristique démontrée de la réussite économique des entreprises et de la performance des organisations. Cette section aborde l’indispensable normalisation des pratiques d’ingénierie appliquées à la production des systèmes d’information. Aucune méthode de développement d’application ou de conduite de projet ne peux plus faire abstraction de l’obligation d’industrialiser les développements pour en accroître la fiabilité et la maîtrise de réalisation.

CMM, le modèle d’évaluation et d’amélioration des capacités d’une organisation à produire du logiciel respecte les exigences du méta modèle ISO 15504. Les 18 pratiques clés qui le compose sont brièvement, mais raisonnablement expliquées. Initialement situé au niveau « organisation », CMM se décline maintenant au niveau « équipe » (TSP) et  au niveau  « individuel » (PSP).

L’Agilité, dans le contexte organisationnel de la conduite de projets, doit composer avec une juste rigueur et s’en faire une alliée.

CMM et le standard ISO 15504

Le mouvement de normalisation spécialisé dans l’ingénierie des projets du système d’information regroupe[1] désormais SEI-CMM et ISO-SPICE. Initialisé par le SEI[2], l’organisme américain à l’origine de CMM (Capability Maturity Model), cette tendance irrévocable vers l’industrialisation trouve son aboutissement dans  la norme ISO 15504, issue du projet SPICE (Software Process Improvement Capability dEtermination).

A ce sujet visiter - La foire aux questions - sur le site de Richard Basque le traducteur de CMM en Français

Le CMM, ou modèle d'évaluation et d'évolution des capacités de développement logiciel, a été mis au point par le SEI et traduit par le CRIM[3]. CMM est un standard de fait, aussi le projet SPICE s’est-il inspiré de sa structure pour se présenter sous la forme d’une  norme internationale : ISO/IEC 15504. Heureusement, le chef de projet n’aura pas à composer avec deux normes proches mais distinctes, ISO 15504 s’étant finalement orientée vers  une offre de métamodèle dans laquelle le CMM s’inscrit. Mais il pourra choisir parmi des méthodes distinctes dans leurs conditions de mise en œuvre, mais préconisant des pratiques identiques et répondant aux exigences d’une norme commune. Ce chapitre a choisi de détailler CMM, compte tenu de son pragmatisme, de sa réelle notoriété et de sa large implantation.

CMM répertorie des pratiques de planification, d'ingénierie et de gestion qui, lorsqu'elles sont appliquées, améliorent la capacité de l'organisation à atteindre des objectifs de coût, de délai, de qualité et de fonctionnalité.

Dans un premier temps, une évaluation permet à l’organisation de diagnostiquer sa « maturité » (ou son niveau qualité) dans la conduite de projet, sur une échelle de 1 à 5. Le but de cette évaluation est généralement, dans un second temps, d’engager une démarche d'amélioration [4] ().

Thierry Tacquet, dans Objectif technologie déclare : « L'amélioration de la qualité du logiciel doit être considérée comme un processus continu au sein duquel l'organisation se meut en permanence, où elle introduit de nouvelles pratiques, en modifie ou en supprime d'autres. Une étape importante est la détermination de l'état initial par une collecte de données, qui sera renouvelée pour constater, confirmer et réorienter l'amélioration du processus dans son ensemble. Le cadre de cette amélioration s'inscrit dans celui de l'amélioration de la qualité, décrit par les normes ISO ».

Uniformisation CMM / SPICE

A l’origine, la différence principale entre CMM et l’amélioration recherchée par le modèle SPICE correspondait à une évaluation plus fine, processus par processus. Avec SPICE, chaque processus était évalué individuellement et se voyait attribuer son propre niveau de maturité. D’autre part, le niveau 1 (Initial) de CMM était scindé en deux niveaux, ce qui permettait de distinguer un  « état de maîtrise inexistante des processus », d’un  «  état de maîtrise informelle des processus ». Cette distinction naturelle est prévue depuis longtemps [5] dans l’outil Évaluateur pour différencier l’efficacité des organisations en fonction des résultats réellement obtenus :

1.      CMM-1-Bas : absence de méthode ou méthode empirique ayant déjà conduit à des débordements ou à des échecs de projet ;

2.      CMM-1-Haut : méthode « maison » n’ayant jamais conduit à des débordements ou à des échecs de projet.

A ces détails près, les objectifs des deux modèles SEI-CMM et ISO-SPICE, étaient globalement identiques, et il en était de même des principes et de la structure d’évaluation qu’ils préconisaient. Les principaux et récents changements dans la philosophie de ces normes se situent dans la recherche d’une qualité effective comprenant :

ú         la gestion des responsabilités organisationnelles,

ú         la gestion des ressources humaines et matérielles,

ú         la gestion des processus de production,

ú         l’évaluation quantitative des améliorations.

Un méta modèle

Par ailleurs, le comité SPICE a modifié son mandat original qui visait la création d'une méthode et d'un modèle. Le nouveau mandat exigeait du comité la création d’un standard pour des « Exigences » relatives à des méthodes et à des modèles qui seraient alors comparables. Cet élargissement et cette généralisation du périmètre présentent l'avantage de faciliter le consensus  international et de stimuler le développement de solutions adaptées à différents besoins tout en partageant un ensemble de règles communes. Le projet SPICE s’est donc orienté vers un aspect de metamodèle lui permettant d’englober d’autres démarches d’amélioration de la qualité des développements.

Les cadres méthodologiques et les méthodes du futur, à commencer par CMM,  devront se référencer à la norme ISO 15504.

Ce principe offre un avantage évident : créer une nouvelle méthode à partir d’une déclinaison de CMM, elle-même normalisée ISO 15504, offrira un référentiel dont la robustesse et l'utilité auront été vérifiées dans de nombreuses applications à travers le monde. Et, selon le site Web Alcyonix, « utiliser un tel modèle comme référentiel pour ses investissements en matière d'amélioration de processus logiciel constitue certainement un bon moyen de minimiser ses risques et de maximiser ses bénéfices ».

Spécialisation projets industriels et progiciels

  • SW-CMM Capability Maturity Model for Software development
  • SA-CMM  Software Acquisition Capability Maturity Model
  • SE-CMM  Systems Engineering Capability Maturity Model
  • IPD-CMM Integrated Product Development Capability Maturity Model
  • Le CMM s'appelle en fait SW-CMM© (SW pour SoftWare), et son ambition se limite à couvrir le processus de développement logiciel. CMM existe depuis près de 10 ans. Juste avant la publication de la version 2, le SEI a réorienté ses efforts vers une intégration plus large des pratiques « de système et de logiciel ». Cette combinaison permet de couvrir plus largement les diverses préoccupations propres aux projets industriels. Cette recherche a abouti à un modèle combiné et intégré nommé CMMI qui  étend la portée du modèle à toutes les activités « système » et non seulement aux activités « logiciel ». Progressivement, le SEI va encourager l'utilisation du modèle CMMI plutôt que du CMM tout en continuant à soutenir pleinement le CMM durant la phase de transition prévue pour la fin de 2003. De plus, le modèle CMMI a été structuré en deux représentations (« staged », comme le SW-CMM le proposait initialement et « continuous », comme l'impose ISO15504).

    Une variante destinée à normaliser les processus d’acquisition d’un progiciel a été publiée en mars 2002 [6] sous le sigle SA-CMM©. Le SEI a déjà concrétisé son intention de faire du CMMI un modèle conforme à ISO/IEC 15504. 

    Déclinaisons entreprise, équipe et individu

    Plus récemment, la norme CMM, qui se préoccupe du niveau « organisation » s’est vu décliner en deux niveaux plus fins l’équipe : (TSP[7]) et la ressource individuelle (PSP).


    Figure 2. — ROI relatif aux trois niveaux


    Maturité : évaluation et amélioration

    CMM détermine 18 secteurs clés permettant à l’organisation de situer sa maturité et de fixer son objectif d’amélioration par rapport à 5 niveaux précis . Chaque niveau comporte plusieurs [8] « secteurs clés ».

    Chacun des 18 secteurs clés fait référence à des « caractéristiques communes » qui se matérialisent par des « pratiques clés » (Figure 3). La mise en œuvre de toutes les pratiques clés d’un niveau permet à l’organisation de considérer qu’elle a atteint ce niveau de maturité. CMM dispose de l’immense avantage d’être modulaire et de discerner 5 niveaux de maturité, donc d’évolution progressive.


    Les 5 niveaux de maturité

    Niveau 1 « initial »

    L'organisation ne dispose pas de procédures formalisées d’évaluation, de développement et d’évolution de ses applications. L’engagement de ses ressources humaines ne permet pas une capitalisation de l’expérience du fait du turnover. Des crises surviennent en cours de projet. Lorsque l'échec se matérialise, les éventuels rudiments de méthode sont abandonnés pour tenter des raccourcis dans le processus de réalisation et de validation. Les efforts d'organisation régressent alors vers des pratiques d'engagements purement réactives, de type « codage et tests » qui amplifient la dérive.

    Niveau 2 « reproductible »

    La gestion des nouveaux projets est fondée sur l'expérience mémorisée à l'occasion de projets semblables. L’engagement permanent des ressources humaines garantit une pérennité du savoir-faire dans la limite de leur présence au sein de l’organisation.

    Niveau 3 « défini »

    Des directives de gestion de projet et des procédures en permettant l'application sont établies. Le processus standard de développement et d’évolution logiciel est documenté. Il intègre en un tout cohérent les procédés d'ingénierie logiciel et de gestion de projet. Un programme de formation est en place dans l'organisation afin que les utilisateurs et les informaticiens acquièrent les connaissances et les compétences nécessaires pour assumer les rôles qui leur ont été confiés.

    Niveau 4 « maîtrisé »

    L'organisation se fixe des objectifs quantitatifs et qualitatifs. La productivité et la qualité sont évaluées. Ce contrôle se fonde sur la validation des jalons majeurs du projet dans le cadre d'un programme planifié de mesures.

    Niveau 5 « optimisé »

    L'amélioration continue des processus est la principale préoccupation. L'organisation se donne les moyens d'identifier et de mesurer les faiblesses de ses processus. Une cellule de veille technologique identifie puis acquiert et met en œuvre les produits innovants. Elle recherche les pratiques d'ingénierie logiciel les plus efficaces, particulièrement celles dont la synergie permet l’amélioration continue de la qualité.

    Figure 3. — Détail d'un niveau du CMM

     

    Tableau 1. Structure d’évolution de CMM

    Niveaux de maturité

    Un niveau de maturité est un palier d'évolution bien défini dans le cheminement vers un processus logiciel mature. Cinq niveaux constituent la structure haute du CMM.

    Capacité du processus

    Cette notion recouvre la capacité d’obtenir des résultats en respectant un processus logiciel.

    Secteurs « clés »

    Chaque niveau de maturité comporte divers secteurs clés. Chaque secteur clé identifie un ensemble d'activités.

    Objectifs

    Les objectifs synthétisent les pratiques d'un secteur clé. L’observation de ces pratiques permet de déterminer si les activités d’un secteur clé sont réellement mises en œuvre.

    Caractéristiques communes

    Les caractéristiques communes indiquent si la mise en œuvre d'un secteur clé est efficace, durable et reproductible.

    Pratiques « clés »

    Chaque secteur clé est décrit en termes de pratiques clés (infrastructure et activités) dont la mise en œuvre contribue à satisfaire les objectifs de ce secteur clé. Les pratiques clés sont réparties en cinq caractéristiques communes :

    1.      engagement de réalisation,

    2.      capacité de réalisation,

    3.      activités réalisées,

    4.      mesures et analyse,

    5.      vérifications de la mise en œuvre.

     

    Le livret : Introduction à la normalisation ISO / CMM   (720 Ko)

     


    [1] LEuropean Software Institute (ESI) propose un mapping entre SPICE et CMM.

    [2] Software Engineering Institute

    [3] Centre de Recherche Informatique de Montréal,  Québec, Canada (www.CRIM.ca).

    [4] Accessoirement la certification « qualité » des compétences.

    [5] Onglet 4, Méthode, Qualité.

    [6] http://www.sei.cmu.edu/arm/SA-CMM.html

    [7] TSP : Teams Software Process ; PSP : Personal Software Process

    [8] A l’exception du niveau 1 qui correspond à une absence formelle de normalisation.


    www.RAD.fr ® © Jean-Pierre Vickoff