accueilLogicielsDéveloppement et Qualité LogicielsModèles d’évaluation des logiciels free/libres open-source
 

Capability Maturity Model Integration (CMMI)


Pour les organismes développant des logiciels, des services ou délégant leur intégration, un modèle d’évaluation est proposé par le Software Engineering Institue, le « Capability Maturity Model Integration » (CMMI). Il permet de mesurer la maturité des processus de l’organisation liés aux développements de logiciels ou de services ou à la gestion des relations contractuelles. Chacun de ces aspects est traité dans un document spécifique, bien que la plupart des processus étudiés soient communs [1]. Ainsi CMMI pour l’acquisition est destiné à la gestion des relations avec les sous-traitants qui ont la responsabilité de concevoir et fournir des logiciels ou des services. CMMI pour le développement se focalise plus particulièrement sur les processus de développement. Enfin, CMMI pour les services est orienté vers les processus de gestion et de fourniture de services, incluant les détails de gestion de la disponibilité, des interruptions, du point de vue technique et organisationnel.

 
Quel que soit le document utilisé, le modèle CMMI propose deux approches pour l’évaluation de la maturité des processus et de leur évolution dont la plus utilisée est la représentation étagée [2]. Dans ce cas, l’organisation est catégorisée en fonction de niveaux de maturité. Chaque niveau de maturité est caractérisé par des secteurs clés, eux-mêmes définis par un ensemble de pratiques.

Dans le niveau par défaut, appelé « initial », des processus liés aux projets de logiciels peuvent exister au sein de l’organisation, mais leur exécution n’est pas vérifiée systématiquement car non obligatoire. Ce niveau ne fait l’objet d’aucun secteur clé. De ce fait, les estimations des coûts financiers et en temps des projets sont variables. La gestion des projets ne repose pas sur des indicateurs clés établis par l’établissement. Elle est uniquement basée sur les délais et ne prend pas en compte d’éventuelles successions de problèmes. De plus, les projets ne font l’objet d’aucune capitalisation des difficultés ou erreurs rencontrées. Cette situation n’implique pas que les produits ou services fournis ne sont pas de qualité, mais que tous les engagements ne sont pas obligatoirement respectés et qu’il n’existe pas de moyen de reproduire les sources de succès dans les projets.

Atteindre le second niveau, appelé « discipliné » ou « reproductible », implique qu’un minimum de discipline existe dans les projets bien que des variations subsistent. Ainsi, l’utilisation de processus définis au niveau de l’organisation est contrôlée, les réalisations sont comparées aux exigences initiales et des actions correctrices sont mises en place. De plus, les rôles et responsabilités de chacun des acteurs impliqués sont clairement établis. Ces exigences ont notamment pour conséquence d’améliorer la fiabilité des estimations. Ce niveau est caractérisé par les six secteurs clés « Gestion de configuration logiciel », « Assurance qualité logiciel », « Gestion sous-traitance au forfait », « Suivi de projet », « Planification » et « Gestion des exigences ».
Le niveau suivant, appelé « ajusté » ou « défini », met l’accent sur l’amélioration et à la prévention.

Cela implique la mise en place de processus de capitalisation systématiques à la fin des projets, ce qui entraîne le perfectionnement des processus existants et la réutilisation du savoir-faire, des réalisations telles le code applicatif ou la documentation. Cette cohérence entre les projets conduit à une meilleure gestion des risques. Ce niveau est caractérisé par les sept secteurs « Revues par les pairs », « Coordinations intergroupes », « Ingénierie produit logiciel », « Gestion intégrée de projet », « Formation », « Définition du processus » et « Amélioration du processus ».

Au quatrième niveau, appelé « quantifié » ou « contrôlé », l’organisation exploite des modèles de performances et de prévision basés sur des indicateurs quantitatifs et est capable de mesurer les impacts liés aux évolutions de processus. Chaque projet doit alors respecter des objectifs qui sont régulièrement évalués. L’examen systématique des données issues des projets permet d’éviter une régression de la maturité obtenue. Ce niveau est caractérisé par les deux secteurs clés « Gestion de la qualité logiciel » et « Gestion quantitative du processus ».

Le dernier niveau « optimisé » correspond à une optimisation permanente des processus. Il repose sur la mise en œuvre de processus d’innovation et d’analyse des causes et solutions des problèmes rencontrés par les projets. L’organisation a alors appris à gérer les changements et à assurer un suivi des performances individuelles et collectives. Le cinquième niveau est caractérisé par les trois secteurs clés « Gestion des évolutions du processus », « Gestion des évolutions de la technologie » et « Prévention des défauts ».

PNG - 88.5 ko
Echelle de maturité à cinq niveaux de CMMI

Comme le démontrent H. Glazer, J. Dalton, D. Anderson, M. Konrad et S. Shrum, les modèles CMMI peuvent être utilisés pour des organismes dont la gestion de projet suit des méthodes Agiles [3]. Aussi, la maturité, la pérennité et l’engagement de qualités des projets de logiciels FLOSS qui reposent sur des développements itératifs pourraient être évalués à l’aide de modèles tels que CMMI pour le développement et les services. Cependant, la difficulté de tels projets réside dans l’organisation des développements qui peuvent être réalisés en dehors de tout processus explicite. C’est pourquoi, il est plus difficile d’appliquer CMMI aux processus de développement. De ce fait, les méthodes de gestion de projet et de production du code propres aux logiciels FLOSS doivent être prises en compte par un modèle de maturité spécifique. K.-J. Stol et M. Ali Babar [4] ont retenu vingt approches pour l’évaluation des logiciels libres parmi lesquelles cinq utilisent des critères relatifs aux coûts totaux de possession (TCO : « Total Cost of Ownership » en anglais) ainsi qu’à la maturité du projet.

 

Retour vers le haut de la page   PDF
Article précédent Page d'accueil Article suivant
< 1. Introduction Sommaire | 3. Modèles d’évaluation de la maturité des logiciels Free/Libres Open Source >

 

Guillaume HARRY
Envoyer un courriel

 

Contenu sous licence Creative Commons CC-BY-NC-ND


[1] M. Phillips, S. Shrum. Which CMMI Model Is for You ?. Software Engineering Institute, Carnegie Mellon University, 4 pages, 2011

[2] Equipe produit CMMI. CMMI pour le développement, version 1.3. Software Engineering Institute, Carnegie Mellon University, 570 pages, 2010

[3] H. Glazer, J. Dalton, D. Anderson, M. Konrad, S. Shrum. CMMI or Agile : Why Not Embrace Both !. Software Engineering Institute, Carnegie Mellon University, 45 pages, 2008

[4] K.-J. Stol, M. Ali Babar. A Comparison Framework for Open Source Software Evaluation Methods. Dans Open Source Software : New Horizons, pages 389-394, 2010


ARESU
Direction des Systèmes d'Information du CNRS

358 rue P.-G. de Gennes
31676 LABEGE Cedex

Bâtiment 1,
1 Place Aristide Briand
92195 MEUDON Cedex



 

 

Direction des Systèmes d'Information

Pôle ARESU

Accueil Imprimer Plan du site Credits