CMMI : Capability Maturity Model Integration
Le Capability Maturity Model Integration (CMMI) SE/SW/IPPD/SS v1.1 a été publié en 2003 par le Software Engineering Institute (SEI) de l'université Carnegie Mellon. Une mise à jour a été publiée en 2006 portant le nom de CMMI for Development, Version 1.2. La version 1.3 est en cours d'élaboration. CMMI est un modèle de bonnes pratiques qui repose sur une amélioration progressive des processus de développement informatique de l'entreprise.
CMMI intègre d'anciens modèles développés dans les années 90. Chacun de ces modèles est spécifique à des domaines distincts de l'ingénierie informatique:
- SE (Systems Engineering) : Ingénierie système;
- SW (SoftWare) : Développement logiciel;
- SS (Supplier Sourcing) : Gestion des fournisseurs;
- IPPD (Integrated Product and Process Development) : Développement intégré des produits et processus.
CMMI for Dev. 1.2 regroupe 22 domaines de processus "Process Area" (PA).
Deux modèles de représentation coexistent, correspondant à deux points de vue légèrement différents. Les deux représentations s'appuient sur les mêmes PAs mais ceux-ci sont utilisés différemment :
- Représentation continue : La représentation continue privilégie de regarder l'évolution au niveau de chaque domaine de processus (PA) et d'y associer des stades de développement de la capacité du processus;
- Représentation étagée : La représentation étagée préconise une évolution par étage au niveau de toute l'organisation de développement. Elle permet ainsi de définir le niveau de maturité (ML) de l'organisation.
CMMI représentation étagée
Comme le montre la figure, la représentation étagée exprime l'évolution des pratiques de développement en fonction d'une vue organisationnelle. La première étape est de définir le périmètre à observer : "l'organisation". Puis, on observe son comportement au regard des 5 niveaux de maturité (ML) regroupant les 22 PAs:
- ML 1 : Niveau "Initial" où les processus sont non répétables et non maîtrisés.
- ML 2 : Niveau "Géré" où les processus sont planifiés et répétables. Le ML 2 traduit la mise en oeuvre effective de pratiques de base au niveau des projets mais sans harmonisation au niveau de l'organisation (par exemple chaque projet gère différemment sa planification, ses configurations...); il s'adresse essentiellement aux Chefs de Projet.
- ML 3 : Niveau "Défni" où les processus sont organisés, réactifs et maîtrisés. Le ML 3 traduit le déploiement harmonisé de pratiques définies au niveau de l'organisation ; il s'adresse à toute la population et met l'accent sur l'engineering produit et l'organisation centrale.
- ML 4 : Niveau "Quantifié" où les processus sont mesurés et contrôles. Le ML 4 traduit une gestion quantitative des processus, basée sur des analyses statistiques (les performances de l'organisation sont prévisibles ).
- ML 5 : Niveau "Optimisé" où l'organisation est en amélioration continue. Le ML 5 traduit la maturité de l'organisation où veille technologique et amélioration continue concourent à l'excellence du livrable.
Niveau de maturité | Abréviation | Nom anglais | Nom Français | Catégorie | Intention |
---|---|---|---|---|---|
2 | CM | Configuration Management | Gestion de configuration | Support | Établir et maintenir l'intégrité des produits de travail en utilisant l'identification de configuration, la commande de configuration, la comptabilité de statut de configuration, et les audits de configuration |
2 | MA | Measurement and Analysis | Mesure et analyse | Support | Développer et soutenir des possibilités de mesure qui sont employées pour soutenir les besoins de la gestion de l'information |
2 | PMC | Project Monitoring and Control | Surveillance et contrôle de projet | Gestion de projet | Fournir une analyse du progrès du projet de sorte que des modalités de reprise appropriées puissent être prises quand l'exécution du projet dévie de manière significative du plan |
2 | PP | Project Planning | Planification de Projet | Gestion de projet | Établir et maintenir les plans qui définissent les activités du projet |
2 | PPQA | Process and Product Quality Assurance | Assurance qualité produit et processus | Support | Fournir au personnel et aux managers une vision objective sur les processus et produits de travail associés |
2 | REQM | Requirements Management | Gestion des exigences | Ingénierie | Contrôler les exigences des produits du projet et de ses composants et identifier les contradictions entre ces conditions et les plans du projet et produits du travail |
2 | SAM | Supplier Agreement Management | Gestion des accords avec les fournisseurs | Gestion de projet | Contrôler l'acquisition des produits des fournisseurs pour lesquels il existe un accord formel |
3 | DAR | Decision Analysis and Resolution | Analyse et prise de décision | Support | Étudier, selon des critères définis et un processus d'évaluation formel, plusieurs solutions possibles en vue d'une prise de décision |
3 | IPM | Integrated Project Management | Gestion de Projet Intégré | Gestion de projet | Définir et gérer le projet et les engagements de ses acteurs selon un processus (PDP) dérivé des processus de l 'organisation |
3 | OPD | Organizational Process Definition | Définition du processus organisationnel | Gestion des processus | Définir et maintenir le référentiel de l'organisation |
3 | OPF | Organizational Process Focus | Focalisation sur le processus organisationnel | Gestion des processus | Définir et mettre en oeuvre les améliorations du processus de l'organisation à partir de l'analyse des forces et des faiblesses des processus de l'organisation et de leur capitalisation |
3 | OT | Organizational Training | Formation organisationnelle | Gestion des processus | Développer les compétences des personnes pour leur permettre d'exercer leur mission avec efficacité |
3 | PI | Product Integration | Intégration du Produit | Ingénierie | Intégrer les composants produits, tester et livrer la solution |
3 | RD | Requirements Development | Développement Exigences (Produit et Client) | Ingénierie | Analyser et produire les exigences client, et celles induites sur le produit et ses composants |
3 | RSKM | Risk Management | Gestion des Risques | Gestion de projet | Identifier les problèmes potentiels avant qu'ils ne surviennent et prendre les actions préventives appropriées |
3 | TS | Technical Solution | Solution Technique | Ingénierie | Concevoir et développer la solution |
3 | VAL | Validation | Validation | Ingénierie | Démontrer que le produit ou composant, placé dans son environnement cible, répond aux exigences |
3 | VER | Verification | Vérification | Ingénierie | Vérifier que les produits élémentaires sélectionnés sont conformes à leurs spécifications |
4 | OPP | Organizational Process Performance | Performances du processus organisationnel | Gestion des processus | Mesurer les performances des process de l'organisation et les analyser par rapports aux objectifs |
4 | QPM | Quantitative Project Management | Gestion de projet quantitative | Gestion de projet | Gérer quantitativement le Project's Defined Process de façon à atteindre les objectifs définis de qualité et les objectifs de performance |
5 | CAR | Causal Analysis and Resolution | Résolution et Analyse Causale | Support | Identifier et supprimer les causes des défauts et problèmes pour éviter leur réapparition dans le futur |
5 | OID | Organizational Innovation and Deployment | Innovation et déploiement organisationnel | Gestion des processus | Sélectionner et mettre en oeuvre les améliorations et innovations qui impactent de façon mesurable sur les processus et technologies et permettent à l'organisation d'atteindre ses objectifs de qualité et de performance |
Chacun des Processus Areas (PA) doit répondre à des objectifs qui peuvent être :
- spécifques (SG), intrinsèquement reliés à la nature de l'activité couverte par le PA;
- génériques (GG), transversaux et identiques d'un PA à l'autre.
Ces objectifs se déclinent en pratiques qui décrivent le comportement attendu de la part de l'organisation ou d'un projet (Pratique spécifique (SP), Pratique générique (GP)).
Afin de prouver la bonne implémentation de chacune des pratiques, des preuves PII (Practice Implementation Indicator) doivent être collectées.
Le document ci-joint récapitule toutes les pratiques de CMMI et les questions à se poser lors d'une évaluation : support
CMMI représentation continue
La représentation continue utilise une vision ciblée de l'évolution des pratiques de développement. Contrairement à la représentation étagée qui regroupe sous des niveaux de maturité les différents PAs, la représentation continue exprime la capacité de chaque PA au sein de l'organisation suivant une échelle de 6 niveaux.
Cette représentation permet à l'entreprise d'entreprendre un programme d'amélioration sur un bouquet de PAs qu'elle a sélectionnés.
Une décomposition proposée par le SEI regroupe les 22 Process Area en 4 catégories (comme le montre le tableau précédent) définissant le CMMI Framework :
- Engineering Process Areas (Ingénierie) : Ils couvrent les activités de développement et de maintenance qui sont partagées entre les différentes disciplines d'ingénierie (ingénierie système, ingénierie logiciel)
- Project Management Process Areas (Gestion de projet) : Ils couvrent les activités de gestion de projet liées à la planification, au suivi et au contrôle du projet
- Support Process Areas (Support) : Ils couvrent les activités qui soutiennent le développement et la maintenance du produit. Ce sont des processus qui permettent d'exécuter d'autres processus. En général, ils s'adressent à des processus liés au projet mais peuvent aussi s'adresser aux processus de l'organisation. Par exemple, le PA "Process and Product Quality Assurance" peut être utilisé avec tous les autres PAs pour fournir une évaluation objective des processus et des produits de travail décrits dans tous les secteurs de processus
- Process Management Process Areas (Gestion des processus) : Ils concernent toutes les activités transversales du projet liées à la définition, la planification, le réapprovisionnement, le déploiement, l'exécution, le contrôle, la direction, l'évaluation, la mesure et les processus d'amélioration
IDEAL : Initiating, Diagnosing, Establishing, Acting, Learning
Le SEI a défini un modèle de support d'amélioration continue. Les paragraphes suivants fournissent une définition générale de chaque étape du modèle
- Phase initiale : C'est ici que l'infrastructure d'amélioration initiale est établie, que les rôles et les responsabilités de l'infrastructure sont définis et que les premières ressources sont assignées. Au cours de cette étape, un plan d'amélioration continue des processus est établi pour guider l'organisation jusqu'à la fin des phases initiales, de diagnostic et d'établissement. L'approbation de l'initiative est obtenue de pair avec un engagement relatif aux ressources futures requises pour le travail qu'il reste à faire. Les objectifs généraux du programme sont définis au cours de la phase initiale. Ils sont établis en fonction des besoins de gestion de l'organisation et seront peaufinés et précisés au cours de la phase d'établissement du modèle IDEAL. Deux éléments clés sont habituellement établis, soit un groupe directeur de gestion et un groupe d'exécution des processus. En outre, au cours de la phase initiale, des plans sont établis pour annoncer le démarrage de l'initiative et il est suggéré d'effectuer des évaluations organisationnelles pour établir l'état de préparation de l'organisation à l'égard d'une initiative d'amélioration.
- Phase de diagnostic : La phase de diagnostic du modèle IDEALSM lance l'organisation sur la voie de l'amélioration continue des processus. Elle sert à établir les fondements pour les prochaines étapes. Au cours de cette phase, le plan d'action est mis en oeuvre conformément à la vision de l'organisation, à son plan d'activités stratégiques, aux leçons tirées à la suite d'efforts d'amélioration antérieurs, aux questions de gestion clés que doit régler l'organisation et à ses objectifs à long terme. Des activités d'évaluation sont exécutées afin d'établir la ligne de référence de l'état actuel de l'organisation. Les résultats obtenus et les recommandations formulées à partir de ces évaluations et de toutes les autres activités servant à établir la base de référence seront comparés aux efforts d'amélioration en cours ou prévus afin d'être intégrés dans le plan d'action
- Phase d'établissement : Au cours de la phase d'établissement, les enjeux sur lesquels l'organisation a décidé de se pencher dans le cadre de ses activités d'amélioration sont classés par ordre de priorité. Des stratégies en vue d'apporter des solutions sont mises au point. Le projet de plan d'action sera élaboré conformément à la vision de l'organisation, à son plan d'activités stratégiques, aux leçons tirées à la suite d'efforts d'amélioration antérieurs, aux questions de gestion clés que doit régler l'organisation et à ses objectifs à long terme. Au cours de la phase d'établissement, des objectifs mesurables sont dégagés à partir des objectifs généraux définis au cours de la phase initiale et seront inclus dans la version finale du plan d'action. Les paramètres requis pour surveiller les progrès réalisés sont également définis, des ressources sont engagées et la formation est dispensée aux groupes de travail technique ou aux équipes d'exécution des processus. Le plan d'action mis au point servira à orienter les activités d'amélioration puisqu'il tient compte des constatations et des recommandations priorisées de la phase de diagnostic. En outre, au cours de cette phase, des gabarits de plan d'action tactique sont créés et mis à la disposition des équipes d'exécution des processus qui les compléteront et les réaliseront.
- Phase d'exécution : La phase d'exécution du modèle IDEAL sert à l'élaboration de solutions touchant les secteurs d'amélioration relevés au cours de la phase de diagnostic, à leur mise à l'essai et à leur diffusion dans toute l'organisation. Des plans seront élaborés afin d'exécuter des projets pilotes pour vérifier et évaluer les processus nouveaux ou améliorés. Lorsque l'exécution réussie de projets pilotes aura démontré que les nouveaux processus peuvent être adoptés, diffusés et institutionnalisés dans toute l'organisation, des plans pour les instaurer seront alors élaborés et mis en oeuvre.
- Phase d'amélioration : La phase d'amélioration a pour objectif de rendre la prochaine utilisation du modèle IDEAL plus efficace. À cette étape, les solutions ont été élaborées, les leçons ont été tirées et les paramètres relatifs au rendement et à la réalisation des objectifs ont été cernés. Ces objets ont été ajoutés à la base de données sur les processus qui deviendra une source d'information pour le personnel chargé d'utiliser à nouveau le modèle. À l'aide de l'information recueillie, il sera possible d'évaluer la stratégie, les méthodes et l'infrastructure utilisées au cours du programme d'amélioration. Ainsi, des correctifs ou des ajustements peuvent être apportés à la stratégie, aux méthodes ou à l'infrastructure avant le début du prochain cycle d'amélioration des processus. Les questions à se poser sont notamment les suivantes : Le rendement de l'infrastructure (groupe directeur de gestion, groupe d'exécution des processus, équipes d'exécution des processus...) a-t-il été adéquat? Les méthodes employées par les équipes d'exécution des processus au cours de leurs activités d'élaboration des solutions ont-elles été satisfaisantes ? Les activités de communication du programme ont-elles été suffisantes ? Le parrainage doit-il être réaffirmé ? Faut-il accomplir une autre activité de référence ? Le point de réinsertion dans le modèle IDEAL au cours du prochain cycle dépend étroitement des réponses données à des questions comme celles-ci.
SCAMPI : Standard CMMI Appraisal Method for Process Improvement
SCAMPI, Standard CMMI Appraisal Method for Process Improvement, est une méthode qui utilise le CMMI comme référentiel pour identifier les forces et faiblesses du processus logiciel et/ou système d'une entreprise ou d'un organisme. Cette méthode s'appuie sur une discipline et des règles rigoureuses qui assure l'exhaustivité et l'objectivité de l'évaluation. Elle se caractérise par la large place faite au consensus (c'est une équipe qui accomplit l'évaluation) et à l'implication de l'entité évaluée dans sa propre évaluation. Le SEI a développé cette méthode, gère un programme d'accréditation de chefs évaluateurs et diffuse périodique ment des statistiques.
Bien que conçue pour pouvoir évaluer des projets d'envergure, la méthode SCAMPI n'est pas réservée qu'aux grandes entreprises ou aux grands organismes. Plusieurs variations définies dans la méthode permettent de moduler un SCAMPI en accord avec chaque profil d'entreprise ou organisme à évaluer.
Il existe trois types de SCAMPI : SCAMPI Class C, Class B et Class A. La distinction principale entre ces trois évaluations est leur centre d'application :
- SCAMPI C est une évaluation d'"Approche" ;
- SCAMPI B est une évaluation de "Déploiement" ;
- SCAMPI A est une évaluation d'"Institutionnalisation".
Seule l'évaluation SCAMPI Class A pourra déterminer officiellement le niveau de maturité de l'entreprise. Elle est généralement précédée d'une ou plusieurs évaluation SCAMPI Class B et/ou C.
- SCAMPI Class C : L'évaluation initiale SCAMPI Class C mesure la cohérence du référentiel de l'organisation avec les exigences du modèle CMMI. Les objectifs d'évaluation Class C :
- fournir une formation sur CMMI et SCAMPI ;
- s'assurer d'une interprétation appropriée des pratiques ;
- fournir une compréhension commune du référentiel de l'entreprise ;
- identifier les forces et les faiblesses ;
- aider le SEPG à planifier des actions d'amélioration de processus ;
- aider la direction à identifier les objectifs d'organisation ;
- fournir les informations stratégiques pour des activités d'amélioration de processus ;
- identifier ou valider les membres clefs pour l'amélioration de processus.
- SCAMPI Class B L'évaluation SCAMPI Class B analyse la profondeur du déploiement des pratiques du référentiel. Elle permet de :
- examiner l'adéquation entre l'approche sélectionnée et le contexte :
- comprendre les variations entre les pratiques actuelles ;
- déterminer les membres qui vont guider la mise en oeuvre ;
- identifier les corrections nécessaires
- comprendre les diverses mises en oeuvre du référentiel :
- impliquer et ouvrir le dialogue avec les équipes techniques sur ce qui fonctionne ;
- examiner les " direct artefacts " résultant de la mise en oeuvre ;
- chercher des éléments d'entrée pour mettre à jour l'approche
- s'assurer d'avoir centré l'approche avec les objectifs business :
- valider le plus d'éléments possible du modèle ;
- réfléchir aux éléments restant du modèle.
- préparer l'évaluation de Class A.
- examiner l'adéquation entre l'approche sélectionnée et le contexte :
- SCAMPI Class A Les entreprises souhaitant faire reconnaître et communiquer leur niveau de maturité CMMI doivent soumettre leurs processus à une évaluation SCAMPI Class A, seule évaluation déterminant le niveau de maturité de l'organisation. Cette approche intègre des intervenants internes formés à l'évaluation de maturité organisationnelle. Les résultats définitifs indiquent la notation obtenue (niveau de maturité) ainsi que la description des forces et opportunités d'amélioration de chaque domaine de processus du périmètre évalué. La figure suivante montre les étapes de la préparation et de l'évaluation SCAMPI A.
Conclusion
CMMI peut être défini comme un modèle d'amélioration continue. En effet, CMMI est basé sur des pratiques spécifiques qui peuvent assimilées à des buts à atteindre en terme d'organisation et qui se définissent effectivement par des résultats observables ("Gérer les modifications aux exigences au fur et à mesure de leur évolution en cours de projet"...). D'un autre coté, il y a des pratiques génériques constituant une base d'institutionnalisation des processus.
Le challenge pour les entreprises souhaitant respecter CMMI est le choix de l'implémentation des pratiques. Le danger résulte en général d'un mauvais choix d'implémentation; car si sur le terrain chaque entreprise est libre d'implémenter les pratiques comme elle le souhaite, elle risque, par manque de créativité, inspiration heureuse ou conseils avisés, de mettre en place des solutions très lourdes, contraignantes et sans réelle valeur ajoutée (grands volumes de documentation, circuits de communication à rallonge...). Ce point est à l'origine de beaucoup de préjugés concernant CMMI (CMMI = de la documentation à n'en pas finir). Donc l'enjeu principal de la mise en place d'une démarche CMMI est le bon choix d'implémentation des pratiques afin de ne pas alourdir inutilement le quotidien des participants aux projets.
Références
- Les livres de référence :
- Richard Basque. "CMMI un itinéraire fléché vers le Capability Maturity Model Integration". Dunod, 2004
- Richard Basque. "CMMI : Un itinéraire fléché vers le Capability Maturity Model Integration Version 1.2". Dunod, 2006
- Mary Beth Chrissis, Mike Konrad, and Sandy Shrum. "CMMI : Guidelines for Process Integration And Product Improvement". Addison-Wesley Professional, 2006
- SEI Software Engineering Institute. "CMMI for Development, Version 1.2". SEI, 2006
- Les liens :
- http://www.sei.cmu.edu/cmmi/index.html
- Cette page contient tous les documents officiels de CMMI : http://www.sei.cmu.edu/cmmi/models/