CMMI et le PMBOK

Dans le portefeuille de programme d’amélioration des performances et capacités de mon entreprise actuelle, nous avons un projet de certification CMMI en cours pour notre informatique interne. Je reviendrai sur ce sujet dans un prochain article afin de parler plus en détail de la méthode utilisée pour ce projet. Car, en effet, se lancer dans une telle entreprise doit être conduit comme un projet avec ses objectifs, sponsors, parties prenantes, livrables, planning, ressources, plan de communication… Étant certifié PMP et, comme vous le savez, ayant occupé de nombreuses fonctions bénévoles au sein de PMI, le sujet proposé par Dave Nielsen m’a-t-il intéressé : CMM et le PMBOK. En voici une traduction personnelle.

CMM ou CMMI sont peut être les normes de qualité les plus en vue pour le logiciel. CMM/CMMI va au-delà de la portée de standards comme l’ISO (l’organisation internationale de normalisation) pour définir les critères de bons processus logiciels. Ceci rend ce standard très attractif dans toutes les organisations informatiques. CMM/CMMI est destiné à diriger les processus de l’organisation informatique dans son ensemble et le cycle de vie complet des applications doit inclure les processus utilisés pour diriger le développement du logiciel. L’influence de CMM/CMMI sur les processus qui gouvernent le développement logiciel signifie qu’il influence aussi la manière dont les projets de développement logiciels sont gérés. PMBOK de PMI’S (le Corpus de connaissances en management de projet) est reconnu dans le monde entier comme la Bible des meilleures pratiques en management de projet. Celles-ci s’appliquent à la gestion de projets dans n’importe quelle industrie y compris l’industrie informatique donc les meilleures pratiques du PMBOK seront sous l’influence de CMM/CMMI dans toute organisation qui souhaite appliquer les deux standards.

Pour autant que je le sache, personne n’a essayé de créer un standard CMM ou CMMI qui soit adapté au PMBOK et personne n’a personnalisé le PMBOK pour accommoder CMM ou CMMI. Cet article est ma tentative d’offrir des conseils au chef de projet qui est chargé de manager un projet logiciel dans une organisation qui est certifiée à un niveau CMM/CMMI de 2 ou plus. Heureusement, ces deux standards ne sont en aucun cas mutuellement exclusifs; cependant ils s’influencent vraiment. Aussi, un peu de soin devrait être pris avec les processus utilisés pour le projet. La meilleure façon d’adresser les rapports est par Secteur de Processus Clef (KPA) qui arrive à s’aligner assez étroitement sur les Domaines de Connaissance décrits dans le PMBOK. Ceci n’est pas un manuel pour réaliser CMM ou atteindre la certification CMMI, ni un manuel d’exécution des meilleures pratiques du PMBOK, j’indique simplement des façons de d’aligner les deux standards. Puisque l’audience prédestinée de cet article est principalement des chefs de projet, je commencerai en fournissant un certain contexte sur CMM/CMMI.

Contexte

CMM signifie Capability Maturity Model. CMMI standards pour CMM + Intégration est développé à partir de CMM. CMM a été développé pour le gouvernement de fédéral des États Unis par l’Institut de Génie logiciel (SEI), qui est associé à l’Université de Melon Carnegie (CMU) dans le but de mesurer la qualité des processus d’une entreprise travaillant pour le département de la défense. CMM s’est développé pour devenir un plan pour l’amélioration continue du logiciel en 5 étapes : Initial, Répétable, Défini, Managé et en Optimisation, puis encore raffiné pour aborder des problèmes de l’intégration CMM traité à travers l’organisation toute entière. La manière dont le SEI a tenté de faire cela est d’identifier des secteurs de processus différents, de définir les processus critiques à chaque secteur de processus et de définir des critères que les processus doivent atteindre. Les processus dans chacun des Secteurs de Processus Clefs (KPA) se développent au long de chacun des niveaux de maturité jusqu’à ce qu’ils atteignent le niveau 5. Cela ne signifie pas que les processus de chaque praticien doit atteindre le niveau 5. Le niveau 5 est destiné à des organisations comme la NASA qui ont besoin de ce niveau de maturité de processus.

Le niveau 1 est l’étape de départ pour le modèle et en fait n’importe quelle organisation qui crée du logiciel sera définie au niveau 1. Le niveau 2 exige que les processus de management de projet soient établis pour suivre à la trace le coût, le planning et le contenu. C’est l’étape à laquelle sera n’importe quel projet qui met en œuvre les meilleures pratiques du PMBOK et qui n’exige aucune rationalisation entre le PMBOK et CMM. Le niveau 3 exige que des processus logiciels tant pour le management que la réalisation soient documentés, standardisés et mis en œuvre à travers l’organisation sur tous les projets. C’est le niveau qui exige un degré de coordination entre le management de projet et CMM.

Le niveau 2 CMM exige des processus dans les secteurs suivants :

  • Gestion des exigences
  • Planification du projet logiciel
  • Suivi de projet logiciel et surveillance
  • Management de sous-traitance de logiciel
  • Assurance qualité logiciel
  • Gestion de configuration logicielle

Tous ces secteurs, à l’exception de la gestion de configuration logicielle, sont décrits en détail par le PMBOK. La gestion de configuration logicielle n’est pas couverte et considère normalement que le projet héritera ces processus de l’organisation exécutant le projet. Le management de sous-traitance de logiciel ne s’applique pas à chaque projet, si votre projet n’exige l’obtention d’aucun produit ou service extérieur, ce secteur peut être ignoré.

CMM se concentre sur la compréhension des besoins du client du projet logiciel, la traduction de ces besoins dans des exigences et la documentation de ces exigences. La capacité recherchée dans ce secteur est une compréhension commune de ce que sont ces exigences et leur documentation appropriée pour qu’elles puissent être utilisées à l’exécution et le suivi des activités du projet. La planification de projet se concentre sur le développement d’évaluations réalistes pour le travail qui doit être exécuté et l’obtention des engagements de faire le travail. La planification inclut aussi l’identification des objectifs, l’évaluation d’effort, l’évaluation des besoins en ressources, la planification du travail et l’identification des risques du plan. Le suivi et le contrôle de projet exigent que le chef de projet établisse une visibilité suffisante de la performance de projet pour que les déviations du plan puissent être détectées et corrigées. Les corrections peuvent inclure la re-planification du travail ou la prise d’actions qui permettront à l’équipe d’exécuter le plan existant. La gestion de contrat de sous-traitance gouverne comment les sous-traitants qualifiés sont choisis et managés. Le but e l qualité est de fournir la visibilité dans les processus utilisés et produits construits en passant en revue ces produits et processus pour s’assurer de la conformité par rapport aux standards établis. La gestion de configuration logicielle établit et maintient l’intégrité des produits et des composants se construisant partout et dans tout le cycle de vie du logiciel. Cette intégrité est établie en contrôlant les changements de configuration de produit à l’aide d’une bibliothèque de référence. Les changements au référentiel sont contrôlé par des processus de management du changement.

Le niveau 3 se concentre sur le projet et les problèmes organisationnels qui formalisent un génie logiciel et des processus de management efficaces à travers tous les projets. Le but est l’amélioration des processus de l’organisation. Le chef de projet ne peut pas être responsable des standards organisationnels, mais peut assurer que le projet qu’il gère supporte des processus de niveau 3. Les secteurs qui comprennent le niveau 3 sont :

Les processus d’organisation (le focus est appliqué à ce niveau en général)

  • Définition de processus d’organisation
  • Programme de formation
  • Gestion logicielle Intégrée
  • Ingénierie de produit logiciel
  • Coordination entre groupes
  • Revue de pairs

La définition des processus développe et maintient le jeu de processus qui délivrent les améliorations de performance. Elle définit aussi les données requises par la management de processus quantitatifs. Un exemple de ces données serait les résultats de test. Le processus n’adresse pas de tests spécifiques, mais plutôt comment les résultats de test seront utilisés pour améliorer le développement logiciel. La formation est concentrée sur le développement des compétences et de la connaissance pour exécuter les processus CMM mis en œuvre et les tâches demandées par le plan de projet. Les processus et le focus dans ce secteur sont à peu près inchangés par rapport au PMBOK. L’intégration adapte les processus du projet dans les standards, la politique et les actifs de l’organisation en répondant aux besoins techniques du projet. Les PMOs ou PMCs en sont probablement l’exemple le plus commun. Les processus d’ingénierie sont simplement les processus et les outils utilisés pour produire le logiciel. Un exemple d’ingénierie de produit logiciel est RAD (le Développement Rapide d’Application). Les compilateurs de code et des plateformes de développement Web sont d’autres exemples. La coordination entre groupes intègre les processus et outils utilisés par les groupes au sein du projet. Un exemple de cette intégration serait la participation du groupe d’Analyste Métier/Business dans l’examen des spécifications produites par le groupe de développement logiciel. Les revues de pairs se réfèrent aux revues de conception et de code.

3 réflexions sur “CMMI et le PMBOK

  1. Bonjour MICHEL,
    Depuis le début des années 1990, J’ai mis en place des systèmes qualité basés sur le PMBoK et certifiés ISO9001 pour des groupes de développement logiciels et de puces. Puis des systèmes qualité basés sur le PMBoK tout en restant certifiés ISO9001 et devant être aussi certifiés CMMI L2 puis L3.
    Ensuite j’ai dû ajouté en plus la conformité à l’EFQM.
    Si je me suis intéressé à l’OPM3 c’est qu’il a été développé par le PMI avec des experts du SEI, donc un rapprochement entre PMBoK et CMMI.
    Au total, le plus difficile reste pour les ingénieurs et les personnes qui travaillent sur le projet de leur fournir un environnement simple. CMMI en particulier peut très rapidement s’avérer un monstre d’administration qui va plomber le budget des projets et l’ambiance de l’équipe.
    La première exigence pour un chef de projet dans ces environnements est de faire le tri entre ce dont on a besoin pour le projet et ce qu’on ne fera pas. Il faut ensuite l’écrire dans le projet pour ne pas se faire taper sur les doigts par des assesseurs (terme CMMI) trop rigides. (Il y en a beaucoup, plus que chez les auditeurs ISO9000 aujourd’hui).
    Ensuite il faut avoir des outils simples qui montrent directement aux membres de l’équipe pourquoi on fait telle et telle chose et à quel besoin ça répond concrètement pour le projet.
    Dans des périodes de crise comme celle que nous traversons actuellement, il faut rester très vigilent sur les dérives bureaucratiques et budgétaires que de tels modèles peuvent générer.
    Finalement les standards sont plus souples que les modèles.
    Il faut utiliser ces outils comme des guides pour diminuer les risques et ne rien oublier d’important, mais surtout il ne faut jamais perdre le bon sens. Et le bon sens peut recommander de sauter à pieds joints sur certaines exigences. Il faut évidemment être prêt à en justifier les raisons, mais il ne faut pas hésiter.
    Bon courage,
    THIERRY

    J'aime

  2. Ping : Bulletin juin 2010 : Bonnes vacances ! « Le bulletin PMI Lévis-Québec

  3. Ping : CMMI et le PMBOK | DEVOPS | Scoop.it

n'hésitez pas à commenter les billets et à partager vos idées.

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur la façon dont les données de vos commentaires sont traitées.