La méthode CMM a été désignée pour guider à la construction d'organisation logiciel en sélectionnant les processus d'amélioration de la stratégie en déterminant le processus actuel d'évaluation et en identifiant les quelques issues les plus critiques pour les logiciels de qualité et le processus d'amélioration. En se focalisant sur un ensemble limité d'activités et en travaillant agressivement afin de les achever, une organisation peut régulièrement perfectionner sa vaste organisation de processus logiciel pour être capable d'avoir des gains continus et durables.
L'organisation en étages de la méthode CMM est basée sur les principes de production de qualité qui existent depuis les six dernières années. Dans les années 1930, Walter Shewart a promulgué les principes du contrôle de qualité. Ses principes ont été énormément développés et démontrés avec succès dans le monde par W. Edward Deming et Joseph Juran. Ces principes ont été adaptés par le SEI (Software Engineering Institute) dans une structure de maturité qui établit un projet de direction et une technique de fondation pour les contrôles de quantités de production logiciel.
La structure de maturité dans laquelle les principes de qualité avaient été adaptés à inspiré en premier Philip Crosby. La grille de maturité de ce dernier décrit cinq niveaux évolutifs en adoptant les principes de qualité. Cette structure de maturité a été adaptée au processus de logiciel par Ron Radice et ses collègues qui travaillaient sous la direction de Watts Humphrey chez IBM. Humphrey a amené la structure de maturité au SEI en 1986, en ajoutant le concept de niveaux de maturité et en développant la fondation pour son utilisation courante et entière des logiciels de l'industrie.
Les versions de la structure de maturité de Humphrey sont décrites dans les rapports techniques du SEI. Un premier questionnaire de maturité a été réalisé en 1987 comme un outil pour fournir les organisations avec un chemin pour caractériser la maturité de leurs logiciels de processus. Deux méthodes, un logiciel de processus d'évaluation et un logiciel de capacité d'évaluation, ont été développées pour estimer les logiciels des processus de maturité en 1987. Depuis 1990, le SEI, avec l'aide du gouvernement et de l'industrie, a favorisé l'expansion et redéfinie le modèle basé sur plusieurs années d'expérience dans cette application de processus d'amélioration logiciel.
En conclusion, CMM est donc un modèle d'évaluation et d'évolution des capacités de développement logiciel qui a été mis au point par le SEI à la demande du gouvernement américain. Le cadre conceptuel du modèle d'évolution des capacités logiciel a pour origine les travaux de Watts Humphrey. Dans le cadre du développement d'applications, CMM permet à une organisation de s'évaluer et d'améliorer par paliers ses pratiques méthodologiques.
Le CMM - Capability Maturity Model ou encore modèle d'évaluation et d'évolution des capacités de développement logiciel, est un système qualité permettant d'atteindre des objectifs de coûts, de délais et de qualité. Contrairement à la norme ISO 9000, CMM a été conçu spécifiquement pour le développement logiciel. Ce modèle offre à une organisation cherchant à améliorer ses capacités de développement logiciel :
Pour pouvoir s'améliorer, l'organisation doit tout d'abord prendre connaissance de son niveau de maturité actuel. Pour ce faire, elle rempli des questionnaires produit par le SEI (Software Engineering Institute). Ces questionnaires servent de base pour mettre en évidence ses lacunes et se positionner dans la grille de maturité définie par le SEI.
Puis l'organisation se fixe un niveau de maturité supérieur
à atteindre. Grâce au CMM, elle dispose alors d'une liste
détaillée des actions à entreprendre. En réalisant
l'ensemble des étapes intermédiaires du plan d'action, l'organisation
atteint le niveau de maturité recherché.
Le schéma ci-dessous décrit la structure interne des niveaux de maturités :
Le CMM défini cinq niveaux de maturité, qui hiérarchisent la compétence d'une organisation dans le développement logiciel. Ces niveaux sont :
A l'exception du niveau 1, chaque niveau de maturité comporte plusieurs secteurs clés. Ces secteurs clés caractérisent les domaines à améliorer, pour répondre aux exigences des chaque niveau de maturité. A titre d'exemple, les secteurs clés du niveau 2 sont :
Chaque secteur clé comprend cinq caractéristiques communes. Celles-ci indiquent si la mise en ?uvre d'un secteur clé est efficace, reproductible et durable. Les caractéristiques communes à chaque secteur clés sont les suivantes :
Enfin chaque secteur clé est décrit par des pratiques clés à respecter. Si ces pratiques clés sont mises en ?uvre, on atteint l'amélioration requise pour le secteur clé. Il est à noter que les pratiques clés sont regroupées en terme de caractéristiques communes dans la documentation du CMM.
Niveau 1 - le niveau
"initial"
A ce niveau, l'organisation n'est pas dans un environnement stable, pour l'évaluation, le développement et la maintenance de logiciels.
Lors d'un projet, souvent des moments de crise surviennent ; le peu de méthode qui existait est alors abandonnée pour tenter des raccourcis dans le processus de réalisation et de validation, c'est à dire que des pratiquent d'engagement purement réactives seront choisies : "le codage et les tests". Cela aura pour effet d'amplifier la dérive du projet. A ce moment là, le succès du projet dépend entièrement des capacités de ses dirigeants et/ou de l'équipe qui le réalise. Ce succès varie avec leur connaissance et leur motivation. Par conséquent, la stabilité du projet dépend entièrement de ces personnes mais quand ces dernières quittent le projet alors il n'est plus stable.
Niveau 2 - le niveau
"reproductible"
A ce niveau, la gestion de nouveaux projets est basée sur l'expérience d'anciens projets similaires. Par conséquent, c'est l'engagement permanent des ressources humaines qui garantie une pérennité du savoir-faire dans la limite de leur présence au sein de l'organisation des nouveaux projets.
Niveau 3 - le niveau
"défini"
A ce niveau, les directives de gestion de projet sont établies. Le processus standard de développement et d'évolution du logiciel est documentée, il contient de façon claire les procédés d'ingénieries logiciel et de gestion de projet. Un programme de formation est également mis en place au sein de l'organisation afin que les utilisateurs et les informaticiens acquièrent les connaissances et les compétences nécessaires pour assumer le nouveau rôle qui leur a été confié.
Niveau 4 - le niveau
"maîtrisé"
A ce niveau, l'organisation se fixe des objectifs qualitatifs et quantitatifs ; la productivité et la qualité sont mesurées. Un contrôle est assuré, il se base sur la validité des jalons majeurs du projet dans le cadre d'un programme planifié sur mesure. Quand les limites (à respecter) sont dépassées, cela déclenche une action particulière afin de modifier la situation.
Niveau 5 - le niveau
"optimisé"
A ce niveau, l'organisation entière est centrée sur l'amélioration continue des processus, c'est sa principale préoccupation. L'organisation a les moyens d'identifier et de mesurer les faiblesses de ses processus et a pour but de limiter le nombre de défections en déterminant leurs causes. Une cellule de veille technologique identifie puis acquiert et met en ?uvre les produits innovant. Elle cherche les pratiques d'ingénierie logiciel les plus efficaces, particulièrement celles dont la synergie permet l'amélioration continue de la qualité. L'amélioration se fait donc tout d'abord par une plus grande maîtrise des avancements dans les processus existants et puis par les innovations utilisant les nouvelles technologies et méthodes.
Les secteurs clés
du niveau 2 "reproductible"
Gestion des exigences Planification de projet Suivi et supervision de
projet Gestion de la sous-traitance Assurance-qualité Gestion de configuration Les secteurs clés
du niveau 3 "défini"
Les 7 secteurs clés de ce niveau portent à la fois sur les aspects relatifs au projet et à l'organisation. À ce niveau, l'organisation met sur pied une infrastructure permanente. Elle permet d'institutionnaliser les processus efficaces d'ingénierie et de gestion de façon qu'ils soient appliqués dans le cadre de tous les projets :
Focalisation organisationnelle Définition du processus Programme de formation Gestion logiciel intégrée Ingénierie de produits
logiciel Coordination intergroupes Revues par les pairs Les secteurs clés
du niveau 4 "maîtrisé"
Les 2 secteurs clés de ce niveau sont axés sur la compréhension quantitative et qualitative des produits du processus. Comme on peut le constater ces deus secteurs clés sont fortement interdépendants :
Gestion quantitative de
processus Gestion de la qualité
logiciel Les secteurs clés
du niveau 5 "optimisé"
Les 3 secteurs clés de ce niveau couvrent la mise en ?uvre d'un programme d'amélioration continue et mesurable du processus. Les préoccupations en découlant doivent être abordées simultanément au sein de l'organisation et dans le cadre des projets spécifiques :
Prévention des défauts Gestion des changements
technologiques Gestion des changements
du processus
Engagement de réalisation Capacité de réalisation Activités réalisées Mesure et analyse Vérification de
mise en ?uvre
Chaque pratique clés est décrite par une simple phrase, souvent suivie d'une description plus détaillée. De plus, on y trouve également des exemples et conseils d'applications.
Prenons l'exemple d'une organisation qui a but de documenter ses estimations des délais, afin de pouvoir les intégrer dans les planning et les suivis de projet. Pour ce faire, elle doit établir une procédure documentée, lui permettant d'évaluer la taille du logiciel. Si cette évaluation n'est pas basée sur une procédure documentée, l'estimation peut varier grandement suivant les appréhensions.
L'ensemble des pratiques clés sont décrites dans le guide Key Practices of the Capability Maturity Model, Version 1.1. Ce document de 482 pages, fourni également des indications sur l'interprétation des cas pratiques. En ce qui concerne l'exemple précédent, voici la manière dont le cas pratique est décrit :
Bien sûr, CMM n'est pas garant de la réussite d'un projet. Il ne couvre pas tous les domaines abordés dans la conduite de projet, comme par exemple la motivation des équipes, la diminution du turn-over en gardant les personnes les plus compétentes ? Ces aspects ont cependant été abordés dans d'autres contextes. CMM n'intègre pas ces aspects, et se préoccupe de fournir un cadre structuré, dans lequel le développement logiciel doit progresser de manière hiérarchisée et effective.
Le CMM identifie un ensemble de pratiques pour un projet de développement logiciel mature, et fourni des exemples de démarche à suivre- sans être exhaustif ou trop directif. Le CMM donne les caractéristiques d'un développement logiciel effectif, mais c'est à l'organisation elle-même de trouver l'alchimie entre les moyens humains, technologiques et les procédés de développement.
F.P. Brooks,
. "No Silver
Bullet: Essence and Accidents of Software Engineering," IEEE
Computer, Vol. 20, No. 4, April 1987, pp. 10-19.
P.B. Crosby, .
Quality is Free, McGraw-Hill,
New York, NY, 1979.
B. Curtis,
. "Managing
the Real Leverage in Software Productivity and Quality," American
Programmer, Vol. 3,
No. 7, July 1990, pp. 4-14.
W. Edwards Deming,
. Out
of the Crisis, MIT Center
for Advanced Engineering Study, Cambridge, MA, 1986.
Report
of the Defense Science Board Task Force on Military Software,
Office of the Under Secretary of Defense for Acquisition, Washington, D.C., September
1987.
M.E. Fagan, ."Advances
in Software Inspections," IEEE
Transactions on Software Engineering,
Vol. 12, No. 7, July, 1986, pp. 744-751.
P. Fowler and S.
Rifkin, .Software
Engineering Process Group Guide,
Software Engineering Institute, CMU/SEI-90- TR-24, ADA235784,
September, 1990.
D.P. Freedman and
G.M. Weinberg, .
Handbook of Walkthroughs, Inspections,
and Technical Reviews, Third Edition, Dorset
House, New York, NY, 1990.
A. Gabor,
. The
Man Who Discovered Quality, Random
House, New York, NY, 1990.
Embedded
Computer Systems: Significant Software Problems on C-17 Must Be Addressed, GAO/IMTEC-92-48,
May 1992.
W.S. Humphrey,
. Characterizing
the Software Process: A Maturity Framework,
Software Engineering Institute, CMU/SEI-87-TR-11, ADA182895,
June 1987.
W.S. Humphrey and
W.L. Sweet, .
A Method for Assessing the Software
Engineering Capability of Contractors,
Software Engineering Institute, CMU/SEI-87-TR-23, ADA187320,
September 1987.
W.S. Humphrey,
. "Characterizing
the Software Process," IEEE Software, Vol.
5, No. 2, March, 1988, pp. 73-79.
W.S. Humphrey,
. Managing
the Software Process, Addison-Wesley,
Reading, MA, 1989.
W.S. Humphrey, D.H. Kitson, and J. Gale, . "A Comparison of U.S. and Japanese Software Process Maturity,"Proceedings of the 13th International Conference on Software Engineering, Austin, TX, 13-17 May 1991, pp. 38-49.
Le site du SEI (Software Engineering Institute) est le site officiel donnant toutes les informations concernant le Capacity Maturity Model. On pourra notamment :
- avoir une description du CMM.
- télécharger les dernières versions des rapports techniques relatifs au CMM.
- obtenir des indications sur les formations
Ce site décrit les différents phases d'un projet RAD ( Ré-ingéniérie du Développement d'Applications ). On y trouve notamment une description synthétique du modèle CMM.
Le Capacity Maturity Model à été dérivé sous diverses formes. Ce document décrit rapidement les différentes versions du CMM.
Cette page web est un portail vers la majorité des sites web de l'assurance qualité logiciel. Un tableau très complet regroupe l'ensemble des liens, classés par catégories. On y trouve notamment des adresses des normes ISO-9000, du projet SPICE, ?
Cette page fournit une large quantité d'informations, de cours, d'archives liés au CMM. De plus elle contient également un portail vers des sites liés CMM
