Il y a deux semaines a eu lieu le JUG de Lausanne sur l’analyse de la qualité du code. J’en ai été l’organisateur et la publication de la vidéo de cet événement m’a donné l’occasion de le revivre et m’a donné envie de le commenter. Voilà donc mes impressions personnelles sur cet événement.

Quelques explications pour commencer sur mes motivations : travaillant chez OCTO Suisse, j’audite régulièrement des applications sur des technologies variées, principalement JEE et C/C++ (personne n’est parfait). Comme tout le monde, j’ai mes habitudes et les outils que je maîtrise, et depuis quelques audits la sensation de faire un peu la même chose et de voir très souvent les mêmes problèmes (les deux sont certainement liés). D’où cette pulsion : découvrir de nouvelles manières d’auditer, de nouveaux outils, de nouveaux problèmes…

Tout d’abord je dis bravo aux éditeurs qui se sont tous pliés aux règles du jeu et qui ont réalisé ce mini-audit dans un format de présentation assez original et pas si facile. En deux mots, ils devaient présenter le résultat de l’audit de la même application avec leur outil, en 20 minutes et avec un maximun de démo et un minimum de slides (voir ici pour plus de détails). Ils l’ont tous fait de manière différente et je vais essayer de passer au travers de ce que j’ai aimé / moins aimé.

Sur la forme

J’avoue que j’ai été particulièrement impressionné par Freddy de Sonar. Pour moi c’est le seul à avoir réussi à donner une vision globale de la qualité d’IceScrum2 et qui a donné son plan d’action pour remédier à ces problèmes de qualité. En fait cela marque une différence d’approche très nette entre les éditeurs. Alors que Sonar a eu une approche top-down, les autres éditeurs ont eu plutôt une approche bottom-up. Henri d’XDepend a également eu une approche top-down mais c’était moins formalisé (il n’y a pas de dashboard dans l’outil) et il manquait un vrai plan d’action.

Autre élément de forme, Freddy a fait sa présentation en duo, avec lui en speaker et une personne au clavier pour la démo. C’était un plus indéniable, lui permettant de se concentrer sur le discours.

Sur le fond

3 éditeurs sur 5 (Coverity, Parasoft, Sonar) étaient d’accord, le logiciel IceScrum2 est d’une qualité moyenne selon leurs benchmarks. Sur ce point, j’ai été fortement impressionné par l’avis et par le benchmark de Coverity : ‘IceScrum2, 4 bugs / 1000 LOC, un logiciel dans la moyenne’. Jusque là rien d’extraordinaire me direz-vous. Ce qui m’a marqué, c’est la pertinence de ces chiffres. La moyenne provient de lignes de codes analysées via le programme Coverity Scan, soit plus de 14,5 milliards de LOC ! Et pour ce qui est de la fiabilité de l’indicateur, le taux de vrai positif (bugs avérés) est au-delà de 70% (je ne me rappelle plus du chiffre exact). J’avoue que j’ai été scotché. J’ai tellement l’habitude de devoir trier les faux-positifs ou les violations mineures dans les outils de qualité que, pour moi, il s’agit d’un vrai différentiateur pour Coverity de ne se concentrer que sur des bugs avérés.

Pour les deux autres éditeurs, Headway et XDepend, la conclusion était moins élogieuse. Ces outils sont positionnés de manière un peu différente, ce sont plus des outils d’analyse de l’architecture que des chercheurs de bugs comme Coverity, Parasoft ou Sonar. Pour Headway, l’architecture était plutôt mauvaise de leur point de vue : le code est spaghetti, il n’y a aucune structure au dessus des classes (*). Du côté d’XDepend, on a plutôt eu le droit à un ensemble de constats mais pas de vraie conclusion sur la qualité globale. Dommage.

Un manque sur lequel pour moi tous les outils se rejoignent, c’est que la plupart des benchmarks nous ont été donné de manière orale par les éditeurs. Extraits choisis : ‘[ndlr pour les duplications] au-delà de 2%, c’est qu’on a des problèmes’, ’4 bugs / 1000 lines of code is average’ etc… Pourquoi ne pas plutôt intégrer ces benchmarks dans les outils et les faire apparaître de manière visuelle (via une couleur, par exemple sur les différentes zones du dashboard Sonar) ?

Sur la technologie

Côté technologie, 3 produits m’ont impressionné : Coverity, (Re)Structure101 et XDepend.

Je ne m’étendrais pas sur XDepend, connaissant bien le produit puisqu’il est édité par OCTO. En deux mots, ce qui m’impressionne toujours avec cet outil c’est sa capacité à vous aider à rentrer dans le code et à l’explorer de manière visuelle. C’est également le seul outil du panel qui vous permet grâce à un langage SQL-like (le CQL) de requêter votre code au-delà des simples recherches sur des classes que vous pouvez faire dans votre IDE (usages, références, définition).

Structure 101 et Restructure 101 m’ont impressionné sur la façon dont ils restituaient et structuraient les dépendances. L’outil arrive à hiérarchiser les dépendances pour les rendre naturellement sous forme de couches. J’ai bien aimé également les notions de fat versus tangled que met en avant l’outil et aussi le discours qui va avec l’outil, notamment le fait que la structuration progressive des langages s’est arrêtée à la classe (label, fonction puis classe). Il y a une réelle valeur à structurer son logiciel à des niveaux d’abstractions supérieurs, ce qui devrait être fait au travers des packages et des binaires par exemple.

Mon troisième waouh va à Coverity. J’ai tout d’abord été impressionné par leur analyseurs. Par exemple leur analyseur ‘Flow Analysis’ est capable de détecter de manière statique des cas habituellement détectés au runtime, car il propage les valeurs de retours et d’appels entre fonctions, ce que ne fait pas l’analyseur ‘Flow Analysis’ de JTest par exemple. Il y avait notamment un cas de mauvaise synchronisation remonté par JTest au runtime alors que Coverity le remontait à l’analyse statique. Ensuite, un autre type d’analyse très impressionnante est leur ‘intention checks’, en français les vérifications de l’intention du développeur. Ces analyseurs détectent de manière statistique des comportements suspicieux. Par exemple un développeur qui ne vérifie pas la valeur de retour d’une fonction alors qu’elle est vérifiée dans 9 cas sur 10 dans le reste du code. Ou un développeur qui utilise l’opérateur == sur un objet alors que dans 5 cas sur 6 c’est equals() qui a été utilisé. Le dernier point, c’est que l’outil a l’air vraiment puissant pour analyser non pas une version d’un logiciel mais toute la vie d’un logiciel. L’analyse présentée par Coverity contenait tout l’historique et les différentes branches d’IceScrum2 et la démo mettait en avant quels défauts étaient présents dans quelle branche, les branches où le défaut avait été corrigé etc… Les autres éditeurs étaient loin de cela et le simple fait d’avoir été capable d’importer l’historique pour une simple démo montre que l’outillage de Coverity doit être à la hauteur. Enfin, c’est peut-être un détail mais les commentaires des erreurs paraissaient vraiment clairs.

Dernier point sur la technologie, je n’avais jamais vu d’analyseurs dynamiques en action et je dois avouer que cela m’a pas mal impressionné. Parasoft et Coverity ont démontré cette fonctionnalité dans leur sessions respectives et quand on voit les bugs qui en ressortent (à première vue surtout des bugs de concurrence) alors qu’ils n’ont stimulé l’application qu’avec quelques clicks, je n’ose pas imaginer la valeur des résultats de ces analyseurs en les faisant tourner sur des tests fonctionnels ou sur des tests de charge.

Sur l’utilisabilité

JTest est clairement le vainqueur ici car il s’intègre directement dans l’outil principal du développeur, son IDE. Pour les autres outils, Sonar et Coverity sont simples et ergonomiques. La difficulté pour maîtriser ces 3 outils ne vient clairement pas de l’outil mais de la compréhension des erreurs remontées par ces outils. Que veut dire cette erreur ? Est-elle importante ? Devrais-je la désactiver sur mon projet ?

Reste XDepend et Structure 101, qui sont deux clients lourds avec des interfaces assez évoluées et riches. Ces outils demandent néanmoins un vrai apprentissage avant d’être maitrisés, c’est très impressionnant en démo mais une fois seul face à la bête, mieux vaut se diriger vers les webcasts pour la prendre en main. Pour donner un ordre d’idée, j’ai encore découvert de nouvelles fonctionnalités sur XDepend au cours de la présentation d’Henri et il m’a bien fallu 2-3 audits avant d’avoir vraiment pris en main la bête.

Sur le prix

Je ne sais pas si on peut corréler le prix et la valeur mais les prix de ces 5 produits sont très différents, allant de gratuit à quelques milliers d’euros voire dizaine de milliers d’euros pour une licence serveur. Coverity est clairement l’outil le plus cher des cinq et ma perception est que ses analyseurs sont les plus évolués (parmi ses concurrents : Sonar et JTest). Reste la question sous-jacente : est-ce que ça en vaut le prix ?

Des regrets ?

Je dois dire que j’ai eu quelques regrets sur cette soirée. Premièrement l’absence d’un des leaders, à savoir CAST Software, qui n’a pas souhaité se joindre au comparatif. Ensuite, le fait qu’on ait principalement vu des problèmes remontés dans du code Java. Je m’attendais à au moins voir des problèmes sur la couche Web (HTML, JavaScript, CSS) et au mieux sur la base de données (schéma, requêtes etc…). Cette déception rejoint d’ailleurs le point précédent car c’est clairement une force de CAST ou de Metrixware d’être capable de faire des analyses multi-technos et aux frontières des technologies.

En parlant des absents, un autre regret est d’avoir dû se limiter dans le nombre d’éditeurs présents. Le concept de la soirée a en fait particulièrement séduit les éditeurs et deux éditeurs se sont montrés inventifs afin de pouvoir participer à l’événement : Kalistick et SQuoRING ont en effet publié dans la foulée leur analyse d’IceScrum2 et je vous encourage à les consulter ici et là.

Un point qui relève plus du détail est que j’espérais voir l’offre de JTest sur la partie génération de tests unitaires. C’est vrai que ça sortait du cadre de l’audit et je comprends donc qu’ils n’aient eu ni le temps ni l’occasion de l’aborder. Une prochaine fois, peut-être…

Enfin un dernier regret, qui est plus un souhait en fait, est de ne pas avoir (encore) essayé les outils. Je connais déjà assez bien Sonar et XDepend mais parmi les 3 restants, j’espère bien essayer sur un prochain audit, dans cet ordre, Coverity, Structure 101 et JTest. Histoire de pouvoir confirmer ou infirmer ce qui est aujourd’hui une première impression.

J’espère vous avoir donné envie d’en savoir plus sur ce thème et sur cette session, vous pouvez retrouvez les slides et la vidéo sur SlideShare et Parleys, bon visionnage !

-
(*) ce constat est à prendre avec des pincettes car Headway a concentré sa présentation sur IceFaces, qui est la librairie JSF qu’utilise IceScrum2 et pas du code IceScrum2 à proprement parler

Suggestion d'articles :

1. ANNONCE : Java User Group exceptionnel le 10 février à Lausanne, Suisse
2. Analyser la qualité de votre code Groovy / Grails
3. Retour sur le BarCamp Java du Mardi 30 Septembre

PMBoK : Project Management Body of Knowledge

Le Project Management Body of Knowledge, ou PMBoK, est un standard international élaboré par le PMI (Project Management Institute) qui décrit l‘ensemble des pratiques et des techniques avancées intervenant dans le management d‘un projet (corpus de connaissances). Il fournit un référentiel commun avec une terminologie claire et précise des phases, livrables et compétences nécessaires au chef de projet. Tous les aspects du management de projet y sont traités avec une approche  » process  » qui permet de systématiser les meilleures pratiques et donc de s‘améliorer en permanence.

Le PMI a catégorisé les groupes de processus en cinq groupes cohérents :

• Démarrage ;
• Planification ;
• Réalisation ;
• Contrôle ;
• Clôture.

Comme le montre la figure, ces groupes de processus, qui se répètent dans chacune des phases du projet, s‘avèrent critiques pour s‘assurer qu‘aucune étape n‘est involontairement oubliée. De même, les disciplines que le chef de projet sera amené à maîtriser sont divisées en neuf domaines de Management :

• management de l‘intégration du projet ;
• management du contenu du projet ;
• management des délais du projet ;
• management des coûts du projet ;
• management de la qualité du projet ;
• management des ressources humaines du projet ;
• management de la communication du projet ;
• management des risques du projet ;
• management des approvisionnements du projet.

Le PMBoK s‘intègre parfaitement dans une démarche d‘amélioration continue des processus basée sur une approche CMMI ou ISO 9001 en proposant des pratiques éprouvées issues de l‘expérience de plus de 90000 personnes travaillant ensemble au sein du PMI dans plus de 100 pays.

Le PMBoK sert également de support à la certification de chef de projet PMP (Project Management Professional) actuellement décernée à 44000 personnes à travers le monde par le PMI.

SWEBoK : SoftWare Engineering Body of Knowledge

Version génie logiciel du PMBoK, SWEBoK est un corpus de connaissances en génie logiciel. Ce corpus a été élaboré par l‘IEEE entre 1998 et 2004. La version de 2004 a reçu l‘approbation de  » Industrial Advisory Board  » américain.

L‘IEEE a reconnu 8 disciplines reliées au génie logiciel :

• Computer engineering ;
• Project management ;
• Computer science ;
• Quality management ;
• Management ;
• Software ergonomics ;
• Mathematics ;
• Systems engineering.

Comme le montre la figure suivante, à travers ce guide, l‘IEEE traite 10 domaines du génie logiciel :

• Software requirements ;
• Software design ;
• Software construction ;
• Software testing ;
• Software maintenance ;
• Software configuration management ;
• Software engineering management ;
• Software engineering process ;
• Software engineering tools and methods ;
• Software quality.

Six Sigma

Présentation de Six Sigma

Six sigma est à l‘origine une démarche qualité née au coeur même de Motorola en 1979. Limitée dans un premier temps aux techniques de SPC (Statistical Process Control / MSP Maitrise Statistique des Procédés), elle est rapidement devenue une véritable méthode de management englobant l‘ensemble des fonctions de l‘entreprise. Six sigma a ensuite été perfectionnée par d‘autres groupes, comme General Electric, l‘ayant mise en oeuvre avec succès. Six sigma est une méthode de management du progrès particulièrement efficace. Issue d‘une démarche fortement connotée qualité à l‘origine, Six sigma est relativement simple sur le plan du principe. Elle est fondée sur une règle : pour satisfaire les clients, il faut délivrer des produits de qualité .

La méthode Six Sigma offre techniques et outils pour améliorer drastiquement la capacité de production des processus tout en réduisant les défauts. Orientée processus de production à l‘origine, la méthode a été généralisé à tous les domaines, IT y compris, et recherche la régularité absolue. En fait la variabilité de la qualité finale est essentiellement la conséquence de l‘instabilité des composants entrant dans la fabrication du produit, de l‘imprécision des procédures de travail et plus globalement de la complexité des processus. 6 sigma impose de rester dans les limites en appliquant le principe : « if you can measure how many defects you have in a process, you can systematically figure out how to eliminate them and get as close to zero defects as possible ». Autrement dit, en résumé : « Si on peut mesurer on peut corriger ».

Six Sigma, la culture de la mesure au service de l‘amélioration continue

Six Sigma n‘est pas une amélioration ponctuelle. C‘est une réforme de fond de l‘ensemble de l‘organisation et des mentalités. Il faut ainsi soigner la formation, l‘accompagnement du changement et la mesure continue de la performance. L‘effort doit être continuellement soutenu.

La réussite du projet repose sur des paramètres bien précis :

• une approche par projet, chacun bien délimité en termes de périmètre d‘action, de délais et de budget ;
• des objectifs clairs, concrets, précis et connus ;
• une formation extensive de l‘ensemble des acteurs directs et indirects du projet ;
• une coopération et une participation de tous les instants ;
• un système de mesure performant.

La généralisation de la mesure est à la base de la méthode Six Sigma. Cependant, cet esprit de mesure ne se limite pas à la phase de mise en oeuvre du projet. C‘est en fait une véritable culture de la mesure qu‘il s‘agit d‘instaurer au sein même de l‘organisation. Il existe deux méthodes de mise en oeuvre de Six Sigma :

DMAIC : Define, Mesure, Analyse, Improve, Control

La méthodologie DMAIC doit être utilisée quand un produit ou un processus sont déjà existants au sein de l‘entreprise, mais ne rencontrent pas la spécification de client ou n‘exécutent pas en juste proportion.

Définir répond à : Quel problème doit être résolu ? Il permet d‘identifier :

• le produit ou le processus à améliorer ;
• ce que le client souhaite avec le CTQ (Critical to Quality).

Mesurer répond à : Quelles sont les performances du processus ? Il permet de mesurer :

• les caractéristiques clefs du produit ;
• les critères de performance du processus.

Analyser répond à : Où et quand apparaissent les défauts ? Il permet de :

• Analyser les différentes parties du processus ou du produit qui affectent la qualité ou contribuent au problème ;
• Trouver les causes de ce problème.

Améliorer répond à : Comment améliorer les performances du processus ? Il permet de :

• Résoudre les problèmes en appliquant les bonnes pratiques.

Contrôler répond à : Quels contrôles mettre en place pour maintenir le gain acquis ? Il permet de :

• Partager les leçons apprises ;
• S‘assurer de la pérennité des acquis.

DMADV : Define, Measure, Analyze, Design, Verify

DMADV, encore appelé DFSS pour Design For Six Sigma, est utilisé pour concevoir de nouveaux produits ou services.

• Définir les objectifs de projet et les exigences client (interne et externe) ;
• Mesurer et déterminer les besoins clients et cahier des charges, benchmark des concurrents ;
• Analyser les options de processus afin de rencontrer les besoins client ;
• Concevoir les processus afin de rencontrer les besoins client ;
• Vérifier l‘exécution de la conception et sa capacité à valider les besoins clients.

ISO 9001v2000 « Systèmes de management de la qualité – Exigences »

Présentation d’ISO 9001v2000

Les normes ISO 9000 ont été originellement écrites en 1987, puis elles ont été révisées en 1994 et à nouveau en 2000. La norme ISO 9001v2000 porte essentiellement sur les processus permettant de réaliser un service ou un produit.

La présente norme internationale encourage l‘adoption d‘une approche processus lors du développement, de la mise en oeuvre et de l?amélioration de l‘efficacité d‘un système de management de la qualité, afin d‘accroître la satisfaction des clients par le respect de leurs exigences. Lorsqu‘elle est utilisée dans un Système de Management de la Qualité (SMQ), cette approche souligne l‘importance de :

• comprendre et de satisfaire les exigences ;
• considérer les processus en termes de valeur ajoutée ;
• mesurer la performance et l‘efficacité des processus ;
• améliorer en permanence des processus sur la base de mesures objectives.

Le Système de Management de la Qualité (SMQ) s‘appuie ainsi sur divers documents permettant de décrire, avec un niveau de précision grandissant, les activités de l‘entreprise et leurs interactions :

• Le Manuel de Management de la Qualité (MMQ) qui présente la politique, l‘organisation et les principes mis en oeuvre dans le cadre du SMQ ainsi que les dispositions pour assurer la conformité aux exigences contractuelles, internes et réglementaires;
• Le Plan Qualité Projet (PQP) qui décrit l‘organisation de l‘équipe de projet, la gestion des configurations, les processus de réalisation et les règles établies au sein du projet en adéquation avec le SMQ mis en place et les souhaits des clients.
• Les processus décrivent l‘enchaînement des activités réalisées, les responsabilités, les éléments d‘entrées et de sorties.
• Les procédures qui décrivent les tâches à réaliser pour une activité donnée faisant partie d‘un processus.
• Les instructions qui décrivent la façon d‘effectuer une tâche donnée.
• Les documents d‘enregistrement qualité sont mis en place pour faciliter la gestion et l‘enregistrement des activités. Constitués de modèles de document, ils permettent de rendre compte, d‘établir et de conserver l‘information.

La réalisation du Système de Management de la Qualité (SMQ) doit répondre aux exigences des 8 chapitres de la norme décrits ci-dessous :

PDCA : Plan, Do, Check, Act, « la roue de Deming »

Défini par Deming, PDCA est basé sur le concept de la remise en cause des méthodes de travail, des flux d‘information, des fonctions, des documents de travail utilisés… afin de mettre en place l‘amélioration continue. La remise en cause comprend l‘analyse de toutes les anomalies rencontrées dans la vie d‘une entreprise, vues ou pas encore vues par les clients. Ce processus constitué de 4 phases (Planifier, Faire, Vérifier, Améliorer) permet de structurer la démarche d‘amélioration continue définie par ISO 9001v2000. En effet, le cycle PDCA est une méthode qui permet d‘exécuter un travail de manière efficace et rationnelle.

Références

Les livres de référence :

• PMI Project Management Institute. « A Guide to the Project Management Body of Knowledge (Pmbok Guide) Third Edition ». Project Management Institute, 2004.
• Maurice Pillet. « Six Sigma : Comment l‘appliquer ». Editions d‘Organisation, 2003.
• Thomas Pyzdek. « The Six Sigma Handbook : A Complete Guide for Green Belts, Black Belts, and Managers at All Levels ». McGraw-Hill Companies, 2003.
• DIN. « Systèmes de management de la qualité ; Exigences ; (ISO 9001 :2000), Version trilingue EN ISO 9001:2000″. DIN, 2000.

Suggestion d'articles :

1. La complémentarité entre les standards de gestion des processus IT
2. La gestion des processus IT
3. ITIL : Information Technology Infrastructure Library

Pourquoi VAL IT?

Value for IT, c’est à dire la création de la valeur pour l’informatique, permet de répondre à la question fondamentale : Est-ce que les investissements en SI sont réellement managés de sorte à :

• obtenir la contribution maximale à la création de valeur?
• à un coût supportable?
• et avec un niveau de risque acceptable?

La réponse de VAL IT est dans la mise en oeuvre de processus qui vont permettre de répondre à vos questions en connaissance de cause, et de bonnes pratiques.

Quels sont les principes de VAL IT?

Val IT distingue 3 domaines de gouvernance des projets SI :

• la gouvernance de la valeur (GV), ou comment s‘organiser pour piloter, maîtriser les projets, décider de leur poursuite et savoir, en toute connaissance de cause d‘où vient la valeur pour l‘entreprise et comment la valoriser;
• la gestion de portefeuille (GP), ou comment organiser les projets élémentaires pour obtenir une vision exploitable des projets lancés ou en cours, et se donner les moyens de piloter le portefeuille de projets;
• la gestion des investissements (GI), qui relève d‘une analyse des projets élémentaires et de construction de programmes qui les englobent, et s‘appuie sur une logique de démonstration de la valeur créée, au travers de l‘outil fondamental qu‘est le business case.

Comment dérouler VAL IT?

Chaque domaine de VAL IT est composé de processus :

• 6 Processus pour la gouvernance de la valeur (GV):
  • GV1 Assurer un leadership informé et engagé
  • GV2 Définir et mettre en oeuvre les processus
  • GV3 Définir les caractéristiques du portefeuille
  • GV4 Aligner et intégrer la gestion de valeur avec la planification financière de l’entreprise
  • GV5 Établir un contrôle de la gouvernance efficace
  • GV6 Améliorer continuellement les pratiques de gestion de la valeur
• 6 Processus la gestion de portefeuille (GP):
  • GP1 Établir une direction stratégique et cibler un investissement mixte
  • GP2 Déterminer la disponibilité et les financements
  • GP3 Gérer la disponibilité des ressources humaines
  • GP4 Évaluer et choisir des programmes pour le financement
  • GP5 Contrôler et rapporter la performance des portefeuilles d’investissement
  • GP6 Optimiser la performance du portefeuille d’investissement
• 10 Processus pour la gestion des investissements (GI):
  • GI1 Développer et évaluer le programme initial du business case
  • GI2 Comprendre le programme candidat et les options d’implémentation
  • GI3 Développer le plan du programme
  • GI4 Suivre les coûts et les bénéfices sur le cycle de vie complet
  • GI5 Développer le programme candidat du business case détaillé
  • GI6 Lancer et gérer le programme
  • GI7 Mettre à jour le portefeuille opérationnel IT
  • GI8 Mettre à jour le business case
  • GI9 Contrôler et suivre le programme
  • GI10 Retirer le programme

Afin de déterminer le niveau de maturité relativement à VAL IT, chacun de ces processus est évalué sur une échelle de 6 valeurs (0 à 6):

• 0 : Non existant;
• 1 : Initié;
• 2 : Répétable;
• 3 : Défini;
• 4 : Géré;
• 5 : Optimisé.

Conclusion

Val IT constitue un complément indispensable à CobiT pour traiter la performance des investissements informatiques et leurs apports à la valeur de l’entreprise. En effet, VAL IT fournit un cadre de référence pour la gestion d’un portefeuille de projets informatiques avec un double focus : gouvernance de la valeur et gestion des investissements.

L’ensemble CobiT v4 et Val IT constituent un cadre de référence complet de la gouvernance des systèmes d’information en traitant respectivement la performance de la fonction informatique, sous l’angle excellence opérationnelle, et celle de la création de valeur via les investissements maîtrisés.

Références

• Les liens :
  • Le site de l’ISACA : http://www.isaca.org/Template.cfm?Section=Val_IT4&Template=/ContentManagement/ContentDisplay.cfm&ContentID=39994
  • Le site de l’AFAI : http://www.afai.asso.fr/index.php?m=29

Suggestion d'articles :

1. COBIT : Control Objectives for Business & Related Technology
2. La complémentarité entre les standards de gestion des processus IT
3. ITIL : Information Technology Infrastructure Library

Créé à la fin des années 80, à l‘initiative du secteur public britannique, ITIL (Information Technology Infrastructure Library) est un référentiel de bonnes pratiques pour la gestion des services informatiques (internes et externes).
ITIL s‘intéresse à la production, qu‘il s‘agisse de fourniture de services informatiques ou d‘exploitation interne.

Principe d’ITIL

ITIL vise à améliorer les services informatiques (prestation de service, service aux utilisateurs…) suivant plusieurs principes :

• constituer un catalogue de bonnes pratiques à partir de démarches reconnues ;
• mettre le client au centre de la démarche de la DSI ;
• organiser les activités suivant des processus bien établis ;
• jeter les bases d‘une évolutivité dans le temps des processus et services.

ITIL met en place plusieurs moyens pour :

• organiser les processus informatiques :
  • définir les processus et leurs interactions ;
  • définir les rôles et les responsabilités.
• améliorer les relations clients-fournisseurs :
  • instituer un point central de relation entre client et fournisseur : le service desk ;
  • définir des moyens d‘échanges entre l‘entreprise et sa DSI aux niveaux stratégique, tactique et opérationnel.
• définir des moyens de contrôle des résultats obtenus ;
• utiliser des processus ou des méthodologies connues par ailleurs.

Description d‘ITIL

Comme le montre la figure, ITIL comporte 6 modules principaux :

• Service Support : support aux utilisateurs ;
• Service Delivery : gestion du service ;
• Software Asset Management : gestion des logiciels ;
• ICT Infrastructure Management : contrôle des processus ;
• Application Management : gestion des projets ;
• Security Management : gestion de la sécurité.

ITIL comporte aussi un module sur l‘utilisation d‘ITIL et un autre sur l‘avenir des services IT. Les 2 premiers (Service Support et Service Delivery) constituent la base d‘ITIL. Dans le Service Support, le Service Desk est le point de contact avec l‘utilisateur.

Le Service Support est destiné au support des utilisateurs et à la gestion des services, suivant 6 processus :

• Service Desk : point central de relation entre client et fournisseur ;
• Incident Management : définition des activités et opérations pour la reprise rapide après incident ;
• Problem Management : surveillance du niveau de service et analyse des incidents ;
• Configuration Management : description détaillée du SI et de ses processus ;
• Change Management : méthodes et procédures pour supporter le changement;
• Release Management : processus de mise en service des nouvelles activités.

Le Service Delivery organise la gestion des services (besoins, ressources, niveau de service, contrôle des coûts…) suivant 6 processus :

• Service Level Management : description des services et mises en place avec l‘utilisateur. Niveaux de service (SLA) ;
• Capacity Management : gestion des ressources et dé‘nition des objectifs de l‘entreprise ;
• Availability Management : contrôle de la conformité du niveau de service par rapport aux engagements ;
• Service Continuity Management : définition et utilisation d‘un plan de surveillance de la continuité du service (sécurité) ;
• Financial Management : définition des seuils de rentabilité, décisionnel financier ;
• Customer Relationship Management.

Conclusion

Pour la gestion d’infrastructure, ITIL constitue le meilleur référentiel à adopter. Les modules les plus exploités par les entreprises sont la gestion opérationnelle des services : Service Support et Service Delivery. Ils regroupent 12 processus appliqués aujourd’hui essentiellement à la production.

La certification ITIL est attribuée uniquement à des individus. Si une entreprise veut démontrer la bonne application des processus, elle devra aller vers la certification ISO 20000, laquelle impose une application exhaustive de ces processus.

Références

• Les livres de référence :
  • Thierry Chamfrault and Claude Durand. « ITIL et la gestion des services : Méthodes, mise en oeuvre et bonnes pratiques ». Dunod, 2006.
  • Christian Dumont. « ITIL : Pour un service informatique optimal ». Eyrolles, 2007.
• Les liens :
  • Le site officiel : http://www.itil-officialsite.com/home/home.asp
  • Le site francophone et gratuit d’ITIL : http://www.itilfrance.com/

Suggestion d'articles :

1. COBIT : Control Objectives for Business & Related Technology
2. ITIL v3: La gestion du cycle de vie de services
3. La gestion des processus IT

Le modèle COBIT (Control Objectives for Business & Related Technology) est une méthode de Maîtrise des Systèmes d’Information (IT Gouvernance) et d’audit de systèmes d’information, éditée par l’Information System Audit & Control Association (ISACA) en 1996. C’est un modèle qui vise à aider le management à gérer les risques (sécurité, fiabilité, conformité) et les investissements.

Les 5 parties de la méthode COBIT

La synthèse est une présentation des concepts et principes de COBIT. Elle présente les domaines, les objectifs de contrôle généraux (aussi appelés processus) et le cadre de référence. Le modèle COBIT constitue une structure de relations et de processus (cadre de référence ou framework) visant à diriger et contrôler l‘entreprise pour qu‘elle atteigne ses objectifs, par l‘utilisation des technologies pour améliorer l‘activité et répondre aux besoins métiers.

Le cadre de référence se décline en check lists méthodiques couvrant 4 domaines, 34 objectifs de contrôle généraux et 302 objectifs de contrôle détaillés. Chacun de ces objectifs répond à 3 familles d‘impératifs : fiduciaire, sécurité et qualité. Comme le montre la figure suivante, la liste des domaines du cadre de référence de COBIT sont :

• le domaine Planification & Organisation : 11 objectifs couvrent tout ce qui concerne la stratégie et les tactiques. Ils identifient les moyens permettant à l‘informatique de contribuer le plus efficacement à la réalisation des objectifs commerciaux de l‘entreprise ;
• le domaine Acquisition & Mise en Place : 6 objectifs concernent la réalisation de la stratégie informatique, l‘identification, l‘acquisition, le développement, l‘installation des solutions informatiques et leur intégration dans des processus commerciaux ;
• le domaine Distribution & Support : 13 objectifs regroupent la livraison des prestations informatiques exigées (l‘exploitation, la sécurité, les plans d‘urgences et la formation) ;
• le domaine Surveillance : 4 objectifs permettent au management d‘évaluer la qualité et la conformité des processus informatiques aux exigences de contrôle.

Le guide d‘audit permet d‘évaluer et de justifier les risques et les faiblesses des objectifs généraux et détaillés et de mettre en place des actions correctives. Ce guide d‘audit répond à 4 principes :

• l‘acquisition d‘une bonne compréhension ;
• l‘évaluation des contrôles ;
• la vérification de la conformité ;
• la justification du risque de ne pas atteindre les objectifs de contrôle.

Le guide de management fournit des indicateurs clés d‘objectifs et de performances et des facteurs clés de succès. C‘est aussi dans ce guide que l‘on trouve le modèle de maturité. Il évalue l‘atteinte d‘un ou plusieurs objectifs généraux sous forme d‘une échelle de 0 à 5:

• 0 : Inexistant;
• 1 : Existant mais non organisé (initialisé au cas par cas) ;
• 2 : Décrit (reproductible mais intuitif) ;
• 3 : Défini (avec documentation) ;
• 4 : Surveillé et mesuré ;
• 5:Optimisé.

Les outils de la mise en oeuvre contiennent une présentation de « success story » d‘entreprises qui ont mis en place rapidement et avec succès la méthode COBIT. Cette partie intègre deux outils d‘analyse de sensibilisation du management et de diagnostic de contrôle informatique.

Le COBIT est donc étroitement lié aux objectifs de l‘entreprise tout en s‘intéressant plus particulièrement à l‘informatique. Il permet de rassurer le management, d‘uniformiser les méthodes de travail et de garantir la sécurité et les contrôles de leurs services informatiques.

Conclusion

COBIT est un outil fédérateur qui permet d’instaurer un langage commun pour parler de la gouvernance des systèmes d’information tout en intégrant les apports d’autres référentiels comme l’ISO 9000, ITIL ou CMMI. Cette spécificité résulte essentiellement du fait que COBIT adresse une population un peu différente que les autres référentiels, en effet COBIT a une coloration plus MOA.

Il a l’avantage d’avoir été conçu pour une approche globale et le désavantage, pour le pilotage, d’être issu de l’audit, ce qui fait que son volet guide de management est méconnu.

Enfin, il existe un COBIT Quickstart permettant un démarrage encore plus rapide et une bonne appropriation du référentiel.

Références

Les liens :

• Le site de l’ISACA : http://www.isaca.org/Template.cfm?Section=COBIT6&Template=/TaggedPage/TaggedPageDisplay.cfm&TPLID=55&ContentID=31519
• Le site de l’AFAI : http://www.afai.asso.fr/index.php?m=29

Suggestion d'articles :

1. ITIL : Information Technology Infrastructure Library
2. VAL IT : Value for IT
3. OCTO Technology participe à la construction de BforBank

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.

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.
• 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/

Suggestion d'articles :

1. Synergies entre CMMI et les Méthodes Agiles
2. La complémentarité entre les standards de gestion des processus IT
3. Intégration continue performante (Part #3)