CMMI-C.Foulon-PMI-La Performance de Projets

CMMI - Capability Maturity Model Integration
« Nous avons choisi de faire de la qualité parce que la chance est devenue
trop chère »
Cédric FOULON
PMP
Evaluateur CMMI
Certifié ITIL
© Logica 2008. All rights reserved

Sommaire
Introduction
Un peu d’histoire
CMMI – Quelques définitions
Présentation du modèle
Evaluation
Forces du modèle
Limites du modèle
Pourquoi les sociétés se tournent vers CMMI
Quelques chiffres
Conclusion
Questions / Réponses
23 septembre 2008 C/O:Volvo IT PMI – CMMI 23 Septembre 2008 par Cédric FOULON No. 2
Introduction
• Présentation d’une heure
• Questions/réponses le reste du temps …. Si vous en avez
23 septembre 2008 C/O:Volvo IT

PMI – CMMI 23 Septembre 2008 par Cédric FOULON No. 3
Un peu d’histoire

Il était une fois …..
• Début des années 1980, une étude effectuée sur 9 projets informatiques du
Département de la défense des USA, et correspondant à plusieurs millions
de dollars, affichait les résultats suivants :
– 28,8% avait été payé mais non livré
– 19,2% avait été transformé ou abandonné
– 47,27% n’avait pas été utilisé avec succès
– 2,95% avait été utilisé avec quelques modifications
– 1,77% avait été utilisé tel que livré
• Le gouvernement fédéral américain demande à 2 organismes de mettre au

point une méthode d’évaluation des capacités des maîtres d’œuvres
(prestataires) pour les travaux logiciels :
– Software Engineering Institute (SEI)
– Mitre Corporation

Comment en est - on arrivé là ?
• En vérifiant les proverbes
– « If you fail to plan, you plan to fail »

– « Quand on n’a qu’un marteau, on a tendance à tout traiter comme un clou »
– « Dans la réalité, les malheurs ne s’additionnent pas, ils se multiplient »
– « Si un projet est en position de faiblesse du fait de ses erreurs passées, il est mûr pour
en commettre d’autres, pires »

Les bons ingrédients expliquant la situation
• Ne dites jamais non

– Sortez du périmètre pour être agréable à votre interlocuteur
– Mettez toutes vos chances pour l’échec
◦ Ne vérifier rien
◦ Ne formalisez rien
• Ne soyez pas procédurier
– Changez un composant essentiel juste avant la livraison
– Ne surtout jamais rien formaliser ni vérifier
– Ne vous faites pas peur
– Ne prévoyez rien
– Improvisez
• Et surtout, croyez ….. au Père Noël
– Le projet est facile, il n’y a aucun risque

Que faire pour s’améliorer ?
• Embaucher des supers CP/DP ?
• N’embaucher que des experts pour développer ?
• Faire des heures sup et travailler le week-end ?
• Faire des opérations coups de poing ?
• Faire des plans d’actions ?
 Ceci est déjà fait depuis bien longtemps, alors …..
• Trouver un modèle qui nous permette de changer afin notamment de :

– Renforcer la qualité
– S’industrialiser
– Gagner en productivité
CMMI
CMMI – Quelques définitions

CMMI - Présentation
• Qu’est ce que CMMI ?
– Signification : Capability Maturity Model Integration
– C’est un ensemble de bonnes pratiques relatives aux activités de développement, de
maintenance appliquées aux produits et aux services.
– C’est un modèle qui se base sur :
◦ Un mode itératif qui vise à l’amélioration permanente
◦ Un ensemble de bonnes pratiques (regroupé en 22 processus) à mettre en œuvre sur un projet
◦ Un modèle adaptable aux différentes organisations ou typologie de projet
• Qu’est ce que CMMI n’est pas ?

– Ce n’est pas une méthode de conduite de projet mais une démarche qui vise à porter
l’entreprise à un niveau de maturité qui lui permettra de réaliser correctement ses projets
avec au final :
◦ Satisfaction des utilisateurs finaux
◦ Maîtrise des projets : délais, budget et qualité
◦ Transparence des projets pour tous les acteurs

CMMI - Définition
• Modèle
– Langage commun et une vision partagée
– Permet de savoir où on en est, par comparaison au modèle
– Possède une méthode d’évaluation objective et fiable
– Définit précisément le chemin et les étapes vers l’objectif souhaité (niveau de maturité)
• Processus
– Elément qui répond aux questions qui, quoi, quand, comment
– Aide aux développeurs
– Les process sont regroupés en 4 catégories (Gestion des processus, Gestion de projet,
Ingénierie, Support)
• Objectif
– Notion très importante dans le modèle
– Résultat à atteindre
– Ensemble des caractéristiques observables d’une organisation qui aurait mis en place les
pratiques
– leur atteinte (en totalité) ou pas, donne une mesure du niveau de maturité de l’organisation

CMMI – Les représentations
• CMMI propose 1 modèle mais 2 représentations :
5
– Continue (env. 20%) 4
◦ La démarche de ce type de présentation conduira à
3
l’évaluation de chaque processus indépendamment Capability
des autres 2 Level
◦ On parlera de niveau d’aptitude 1
0 Process Process Process Process

area 1 area 2 area 3 area n
Optimizing
– Etagée (env.80%) Quantitativel

y defined
◦ Evaluation de façon globale de la maturité de
Managed
l’entreprise en 5 niveaux
◦ On parlera de niveau de maturité Defined
Initial
Niveaux de maturité
• NB : Dans la suite de la présentation, on ne parlera que de la représentation étagée sauf si spécifié

CMMI - Structure
• La structure de chaque niveau est

simple et identique. On distingue les
composants suivants : Niveau
– Les niveaux au nombre de 5
– Les domaines de processus (Process Domaines
Area) de 0 à 11 dépendamment du de processus
niveau
– Les objectifs généraux que l’on retrouve
dans tous les processus Objectifs Objectifs
génériques spécifiques
Requis
– Les objectifs spécifiques propres à
chaque processus
Pratiques Pratiques
– Les pratiques comportent une définition, génériques spécifiques
Attendues
des commentaires et éventuellement
des informations complémentaires
(sous-pratiques) Sous- Sous-
Pratiques Pratiques
Informatifs

Exemple
Niveau 2
Niveau • PA : Gestion des exigences du client (REQM)
– SG : Les exigences sont gérées et les
Domaines incohérences avec les plans projet et les livrables
de processus prévus sont identifiées
◦ SP : Obtenir une compréhension commune sur le
sens des exigences avec les fournisseurs de ces
Objectifs Objectifs exigences
génériques spécifiques – Sub P : Établir des critères objectifs pour
l’acceptation des exigences
Pratiques Pratiques – Produit : Résultat de l’analyse des exigences

génériques spécifiques par rapport aux critères
– GG : Le processus (de gestion des exigences) est
géré
Sous- Sous-
Pratiques Pratiques ◦ GP : Une stratégie de mise en œuvre est définie
et permet de planifier et d’exécuter le processus

Présentation du modèle

Répartition des proccesus
N2
N3 PROCESS MANAGEMENT
N4
OrganisationalProcess
ProcessFocus
Focus
N5 OrganisationalProcess
ProcessDefinition
Definition
OrganisationalTTraining
raining
OrganisationalProcess
Process
Performance
Performance
Organisational
Innovation and
Innovation andDeployment
Deployment
Configuration
ConfigurationManagement
Management
Process
Processand Product
and ProductQuality Assurance
Quality Assurance
SUPPORT
Measurement and Analysis

Measurement and Analysis
Causal
CausalAnalysis
Analysisand
andResolution
Resolution
Decision
DecisionAnalysis
Analysisand
and
Resolution
Resolution
Organisational
Environment for Integration (IPPD)
Project
ProjectPlanning
Planning
Project
Project
Monitoring
Monitoringandand
Control
Control Requirements
Requirements Management
Management
MANAGEMENT
ENGINEERING
Supplier
Supplier Agreement
Agreement Management
Management RequirementsDevelopment
Requirements Development
PROJECT
Integrated
Integrated Project
Project Management
Management(IPPD) Technical Solution
Integrated Supplier Management (SS)
Risk Management Product
Product Integration
Integration
Integrated Teaming
Quantitative (IPPD)
Project Management Verification
Risk Management Validation
Quantitative Project Management

Niveau 1 - Initial
IN
• Ce qui caractérise ce niveau : OUT
– Indiscipline généralisé
– Ensemble de mauvaises pratiques
– Pas de processus fiables, on s’en remet à l’expérience de la personne
– Projets pilotés par les délais
– Population de héros
– Pas d'enseignement tiré des difficultés ou erreurs
– Pas de contrôle
– Mode essentiellement réactif
– Incapacité à reproduire les éventuels succès passés
• Conclusion :
– Existence d’un seul non-processus : le mode pompier (gestion par crise)

Niveau 2 - Discipliné
• L’entreprise doit maîtriser 7 des 22 processus :

– Gestion des exigences
◦ Définir
◦ Collecter
◦ Assurer
◦ Tracer
– Planification du projet
– Conduite et maîtrise du projet
– Gestion des achats
– Production et analyses des indicateurs
– Assurance qualité des processus et des produits
– Gestion de la configuration
• Ce niveau ne s’interroge pas sur la pertinence de l’expression de besoin

(suppose que ce point a été traité en amont) mais se limite à sa réalisation
• Correspond à la réalisation d’un projet une fois que l’on a défini ce que l’on
voulait

Niveau 2 - Discipliné
IN
IN OUT
OUT
• Ce qui caractérise ce niveau :
– Discipline dans les projets, bien que des variations subsistent
entre projets
– Processus documenté
– Planification des travaux
– Prévisions, suivi et actions correctives
– Pas de compromis sur la qualité
• Conclusion
– La structure fonctionne au niveau projet
– "Vie" beaucoup plus facile
– Des pratiques de gestion de projet sont mises en œuvre
– Mais ce ne sont pas les mêmes dans les ≠ projets

Niveau 3 - Standardisation
• L’entreprise doit maîtriser 11 nouveaux processus en plus de ceux du

niveau précédent :
– DAR Analyse et prise de décision
– RD Développement des exigences
– IPM Gestion de projet intégrée
– OPD Définition du processus organisationnel
– OPF Focalisation sur les processus organisationnels
– TS Solution technique
– PI Intégration du produit
– VER Recette technique
– VAL Recette fonctionnelle
– OT Formation à l’organisation
– RSKM Gestion des risques
• Correspond au passage d’une structure projet vers une structure

organisationnelle
• Les pratiques mises en œuvre sur le projet sont définies au travers d’une
politique au niveau de l’organisation de l’entreprise

Niveau 3 - suite
IN
– L’organisation a défini des méthodes, outils et documents IN OUT
OUT
– Approfondissement des processus de gestion de projet

– Capitalisation systématique
◦ Mise en place d’un référentiel
◦ Enseignements tirés
◦ Réutilisation savoir-faire, code…
– Prévention
– Culture et compréhension communes
– Standardisation des processus
– Diminution considérable des risques de dérive
• Conclusion
– L’organisation est garante de la pérennité de l’ensemble, le CP n’est plus tout seul
– Le chef de projet puise dans le référentiel en début de projet plutôt que de réinventer la
roue.
– Il n’est pas toujours facile de capitaliser car risque de résistance - on préfère oublier les
écueils

Niveau 4 - Quantification
• La mise en place de ce niveau implique :
– Objectifs quantitatifs
– Correction systématique en cas de dépassement des objectifs
• On va travailler sur la notion de productivité, de performance des projets et

non de l’organisation
• On va donc :
– Récupérer et comparer les statistiques de chaque projet. Pour cela, il faut que les méthodes
de calcul des statistiques soient les mêmes.
– Distinguer les causes normales et les causes spéciales de variation sachant que le but est de
corriger les causes spéciales.
• Attention : L’utilisation de ce niveau n’a de sens que si l’on se base sur un

nombre suffisant de projets afin d’estimer les écarts-types et les moyennes que
l’on utilisera ensuite comme référence pour le suivi de chaque nouveau projet
éligible.

Niveau 4 - Quantification
IN OUT

– Métriques / Indicateurs mis en place et exploités
– Retours d’expérience possibles car processus cohérents
(les comparaisons ont un sens)
– Programme qualité
– Evaluation des impacts liés aux évolutions de processus
• Conclusion
– Le référentiel statistique sert à construire et piloter les projets

Niveau 5 - Optimisation
• Ce niveau nécessite la maîtrise de l’ensemble des processus par

l’entreprise.
• Correspond à un approfondissement de la maîtrise qualitative de la
méthode de l’entreprise
• Acquisition des 2 derniers processus :
– Innovation organisationnelle
◦ Veille technologique et politique innovante
◦ On va chercher le petit plus pouvant nous aider
– Analyse des causes et solution des problèmes
◦ On s’efforce de remonter du constat à la cause afin d’agir.
◦ Le but étant d’accroître les performances
• La mise en place de ce niveau implique en plus de ce qui est effectif au

niveau inférieur :
– Prévention au lieu de correction des erreurs
– Processus toujours en amélioration

Niveau 5 - Optimisation
IN OUT

– Amélioration continue du processus
◦ Gestion dynamique des changements
– Les statistiques sont utilisées pour les processus
standards
◦ La base de statistiques des projets fait évoluer l’ensemble
du système
◦ Optimiser les processus standards sur des bases chiffrées
◦ Ainsi que les modalités des déclinaisons sur les projets
• Conclusion
– Le référentiel sert à construire et améliorer les
processus standards
– Le Nirvana au travail ?

Evaluation

Phase préparatoire
• Pré-requis :
– Ce n’est pas un audit mais un diagnostic
– Analyse des pratiques et de leur mise en œuvre par rapport à celles décrites dans le
modèle
– Effectué par une tierce partie
– Selon une méthode formelle : SCAMPI
◦ Méthode utilisée pour évaluer la maturité ou l’aptitude de l’entreprise au regard de CMMI
• Elément clé du succès

– Soutient inconditionnel du sponsor
– Gestion du changement avec adhésion des participants
• Préparation
– Objectif de l’évaluation avec définition du niveau du modèle ou du processus à couvrir
– Définition du périmètre d’intervention
– Constitution de l’équipe en charge de la préparation à l’évaluation
– Information et sensibilisation au modèle
– Collecte des preuves pour chaque projet entrant dans le scope de l’évaluation
Evaluation
• Evaluation - SCAMPI
– Elément clé permettant le bon déroulement :
◦ Confiance et transparence entre les intervenants
◦ Tout ce qui ce dit est confidentiel
◦ Les constats sont non nominatifs
– Travail en réseau interne à la salle
– Durée est dépendante de l’objectif. Il faut compter 2 semaines pour un niveau de maturité 3
– Travail conjoint entre les interviewés et l’équipe d’évaluation
– Revue des documents fournis
– Validation des données par l’équipe en charge de l’évaluation

Restitution
• Restitution
– A partir d’interviews réalisées et sur la base des preuves apportées
– Constats des forces et faiblesses caractérisant chaque pratique de chaque processus entrant
dans le champs de l’évaluation
– Cotation de chaque objectif ou processus selon une échelle NPFL (Not 15%,Partially
50%,Largely 85%,Fully 100%)
– Pour que le niveau soit atteint, il faut que l’intégralité des pratiques des process area de
l’évaluation soit atteint
• Résultat
– Concerne l’organisation ou une partie de l’organisation ayant été évaluée et non les projets qui
ont été évalués.

Forces du modèle
• CMMI aborde les compétences de l’entreprise, de son organisation et non pas de l’individu
• CMMI décrit les processus qu’il est opportun de maîtriser pour conduire un projet
• CMMI répond de manière précise et efficace en expliquant comment on fait dans notre
métier (informatique).
• Limiter les conflits par anticipation
• Pour toute activité, CMMI demande l’identification et l’assignation de cette dernière à une
ressource
• Uniformisation des process et des documents au sein de l’entreprise
• Amélioration des conditions de travail des équipes
CMMI comme tout modèle n’est pas parfait mais il a le mérite d’exister

Limites et Faiblesses du modèle
• Limites
– CMMI n’est pas une méthode de conduite de projet mais une méthode de qualification
de l’entreprise en conduite de projet
– CMMI ne regarde ni vers l’amont, ni vers l’aval du projet
◦ Arbitrage entre divers projets
◦ Définition des processus de production
◦ Traduction d’un problème technique en impacts clients
◦ Alignements des dépenses sur les priorités métiers
• Faiblesses
– CMMI s’attache au processus et non à la bonne utilisation des ressources
– CMMI ne dit pas comment faire, ni ne fournit d’exemple de document. Il y a donc un
risque de répondre à un processus en utilisant des modèles non lisibles et inexploitables
– CMMI ne garantit aucun résultat
– CMMI ne répond pas à toutes les attentes :
◦ Pas de réponse en cas d’arbitrage (par exemple : comment satisfaire une nouvelle exigence sous
contrainte de délai et de temps?)
◦ CMMI demande des rapports mais ne tient pas compte des difficultés logistiques d’organisation
par exemple

Pourquoi les sociétés se tournent vers CMMI
Commerciale
• CMMI tend à devenir un critère de sélection des fournisseurs
• Amélioration des relations entre les équipes en interne mais également avec le client
• Structurer la relation avec les clients et les sous-traitants
Projet
• Partage d’une vision commune dans l’entreprise
• Meilleure estimation des charges
• Meilleure rentabilité des projets
• Besoin d’amélioration de ses performances face à la concurrence
• Faire progresser les équipes informatiques dans un cadre éprouvé
Organisationnelle
• Justifier les budgets d'amélioration
• Proposer aux décideurs IT un levier de progrès
• Communiquer auprès des DG

Quelques chiffres
• Impact sur les coûts

33 % de réduction pour réparer une erreur Boeing, Australia CMMI
20 % de réduction par unité de logiciel Lockheed Martin M&DS CMMI
15 % de réduction pour trouver et réparer une Lockheed Martin M&DS CMMI

erreur
• Impact sur les délais

Augmentation approximative de 50 % à 95 % de General Motors CMMI
respect des jalons
Diminution de 50 à moins de 10 des jours de retard General Motors CMMI
30 % d’augmentation de productivité en logiciel Lockheed Martin M&DS CMMI

Quelques chiffres
• Impact sur la qualité
Seulement 2 % de tous les défauts trouvés dans les Northrop Grumman IT1 CMMI
systèmes livrés
Focalisation accrue sur la qualité par les Northrop Grumman IT2 CMMI
développeurs
Réduction en nombre et sévérité des défauts post- JP Morgan Chase CMMI
livraison
Plus de 2 millions $US d’économie résultant d’une Sanchez Computers Associates, CMMI
détection et d’une correction hâtive des défauts Inc.
Amélioration de la qualité du code Sanchez Computers Associates, CMMI

Inc.

Conclusion
• C’est un modèle comme un autre qui a ses défenseurs et ses détracteurs, ses
points forts et ses faiblesses. Il a cependant le mérite d’inciter à :
– la capitalisation dans l’entreprise
– la différenciation des tâches
– la formalisation des process et de leur contenu
• Les niveaux les plus substantiels sont les 2 et 3 qui contiennent notamment le
plus grand nombre de processus
• La réussite repose sur la compétence de l’entreprise toute entière, de

l’organisation et de l’adhésion des individus (conduite du changement)
• L’efficacité quand à elle résultera de la conjonction de la compétence de

l’organisation et des individus
• C’est un bon référentiel qualité

Questions/réponses
A votre disposition pour toute

question …

Annexe
•Quantification des composants
Niveau Process Area Objectifs Pratiques

1 0 0 0
2 7 22 125
(7 génériques)
3 11 36 214
(11 génériques)
4 2 3 37
5 2 4 36
Total 22 65 412

Process Areas
Détaillés

Process areas level 2
Etablir les contrôles de base de la gestion de projets
Les exigences sont gérées et les processus sont planifiés,
exécutés, mesurés et contrôlés
• Gestion des exigences
– Gérer les exigences du produit et des composants du produit. Identifier les
incohérences entre ces exigences, l'organisation du projet et les réalisations
du projet.
• Planification des projets
– Etablir et maintenir les plans qui définissent les activités projet.
• Suivi et supervision des projets
– Etablir la visibilité de la progression du projet afin de permettre à la gestion
d'entreprendre des actions correctrices en cas de déviations du plan.
Comparer l'expérience vécue avec les estimations, plans, et engagements,
tels que documentés.
• Gestion de la sous-traitance
– Gérer l'acquisition de produits provenant de fournisseur avec qui il existe un
accord.

Process areas level 2 (suite)
Etablir les contrôles de base de la gestion de projets (suite)
• Mesures et analyses
– Développer et supporter des activités pour répondre aux besoins
d'information de la gestion de projet.
• Assurance qualité processus et produit
– Etablir la visibilité du processus utilisé et du produit développé. Comprend les
revues et audits des activités et produits pour assurer leur conformité aux
normes et aux procédures établies.
• Gestion des configurations
– Etablir et maintenir l'intégrité des produits du projet à travers tout le cycle de
vie. Identifier les items de la configuration, contrôler les modifications,
maintenir l'intégrité et la visibilité de la configuration.

Process areas level 3 1/4
Etablir l'infrastructure pour l'organisation
Permet d'assurer la gestion efficace des processus de gestion et
d'ingénierie de tous les projets.
• Développement des exigences
• Le but de ce secteur clef est de déterminer et de valider toutes les exigences de tous les intervenants du
projet concernant tout le cycle de vie du produit et de ses composants. Le développement des exigences
consiste à :
– Rechercher, analyser, valider et communiquer sur les besoins, attentes et contraintes
des exigences du client pour satisfaire tous les intervenants du projet.
– Collecter et synthétiser les besoins de tous les intervenants projet.
– Développer un cycle de vie des exigences du produit.
– Etablir les exigences client.
• Solution technique
• Le but de la solution technique est de concevoir et implémenter les solutions correspondantes aux
exigences dans un ou des processus cohérents. La « solution technique » est applicable à tous les
niveaux de l'architecture du produit et à tous les produits, les composants, les processus du cycle de vie
et services. Au niveau du processus, on se focalisera sur :
– Evaluer et choisir une conception qui répond à un ensemble d'exigences appropriées
allouées.
– Réaliser la conception détaillée de la solution retenue
– Implémenter la solution retenue.

Etablir l'infrastructure pour l'organisation (suite)
• Intégration du produit
– Le but est d'intégrer les composants du produit et de s'assurer que le
produit répond aux exigences pour pouvoir être livré.
• Vérification
– Le but est de vérifier que, tout au long du cycle de développement,
les produits réalisés répondent à leurs spécifications. En d'autres
termes on peut dire : « Ce que vous avez fabriqué fonctionne ». Ce
secteur clef inclut la revue de pairs, les audits, les inspections, les
tests de performance, les tests de recette, ....

Établir l'infrastructure pour l'organisation (suite)
Validation
• Démontrer que le produit a le comportement attendu dans l'environnement prévu
(opérationnel, formation, fabrication, maintenance, et les services de support). En d'autres
termes on peut dire : « Vous avez fabriqué le bon produit ».
Focalisation organisationnelle sur les processus
• Définir et planifier les responsabilités dans l'organisation pour l'amélioration des processus
et assurer les engagements et ressources nécessaires, à long terme.
• Etablir un groupe responsable, qui va coordonner les activités d'évaluation,
développement, maintenance et amélioration des processus pour les projets courants et
futurs de l'organisation.
Définition du processus pour l'organisation
• Développer et maintenir un processus standard pour tous les projets de l'organisation avec
l'information de support, comme la description des cycles de vie, des directives, des
critères, une banque de données (historique), bibliothèque de documentation du
processus, etc. (software process assets). On vise des bénéfices cumulatifs, de longue
durée, pour l'organisation.

Établir l'infrastructure pour l'organisation (suite)
Programme de formation
• Développer les aptitudes et connaissances (techniques, organisationnelles ou
contextuelles) des employés pour les rendre efficaces dans leurs rôles. Cela revient à :
– Identifier les besoins de formation de l'organisation.
– Réaliser les formations pour répondre à ces besoins.
– Etablir et maintenir les capacités de formation.
– Etablir et maintenir les supports de formation.
Gestion de projet intégré
• Etablir et gérer le projet et l'implication des intervenants projet selon un processus défini et
standardisé dans l'organisation.
Gestion des risques
• La gestion des risques consiste à identifier les problèmes potentiels avant qu'ils ne se
produisent. La gestion des risques est planifiée et activée au besoin durant le cycle de vie
du projet pour réduire les effets des problèmes potentiels identifiés et permettre de tenir
les objectifs.
Analyse et prise de décision
• Analyser et prendre des décisions (principalement techniques) selon un processus formel
et selon des critères pré-définis.

Process areas level 4
Etablir la compréhension quantitative du processus et des produits
logiciels développés
Performance des processus de l'organisation
• Etablir et maintenir une compréhension quantitative de la qualité des produits et
des processus d'un projet pour définir et atteindre les objectifs de qualité
spécifiques.
Gestion quantitative de projet
• Contrôler quantitativement la performance du processus d'un projet.
• Identifier les causes spéciales de variabilité et corriger les circonstances qui les
ont engendrées.

Process area level 5
Etablir l’amélioration continue et mesurable du processus
Déploiement et innovation organisationnelle
Sélectionner et déployer des améliorations mesurables
méthodologiques (processus) ou technologiques. Ces
améliorations répondent aux objectifs qualité et de performance
processus définis à partir des objectifs commerciaux de
l'organisation.
• Identifier les nouvelles technologies bénéfiques (outils, méthodes, processus) et
les transférer à l'organisation de manière ordonnée.
• Améliorer continuellement le processus de l'organisation avec les objectifs
d'améliorer la qualité des logiciels, augmenter la productivité et diminuer la
durée de développement des produits.
Prévention des défauts
• Identifier les causes des défauts et empêcher leurs occurrences par des
modifications des processus.
23 septembre 2008 C/O:Volvo IT PMI – CMMI 23 Septembre 2008 par Cédric FOULON No. 46

CMMI-C.Foulon-PMI-La Performance de Projets

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CMMI-C.Foulon-PMI-La Performance de Projets

Transféré par

Droits d'auteur :

Formats disponibles

CMMI - Capability Maturity Model Integration

© Logica 2008. All rights reserved

CMMI – Quelques définitions

Pourquoi les sociétés se tournent vers CMMI

• Présentation d’une heure

• Questions/réponses le reste du temps …. Si vous en avez

23 septembre 2008 C/O:Volvo IT

23 septembre 2008 C/O:Volvo IT

• Le gouvernement fédéral américain demande à 2 organismes de mettre au

23 septembre 2008 C/O:Volvo IT

• En vérifiant les proverbes

– « If you fail to plan, you plan to fail »

23 septembre 2008 C/O:Volvo IT

• Ne dites jamais non

23 septembre 2008 C/O:Volvo IT

 Ceci est déjà fait depuis bien longtemps, alors …..

• Trouver un modèle qui nous permette de changer afin notamment de :

23 septembre 2008 C/O:Volvo IT

• Qu’est ce que CMMI n’est pas ?

23 septembre 2008 C/O:Volvo IT

23 septembre 2008 C/O:Volvo IT

• CMMI propose 1 modèle mais 2 représentations :

0 Process Process Process Process

– Etagée (env.80%) Quantitativel

• NB : Dans la suite de la présentation, on ne parlera que de la représentation étagée sauf si spécifié

• La structure de chaque niveau est

23 septembre 2008 C/O:Volvo IT

Pratiques Pratiques – Produit : Résultat de l’analyse des exigences

23 septembre 2008 C/O:Volvo IT

23 septembre 2008 C/O:Volvo IT

Measurement and Analysis

23 septembre 2008 C/O:Volvo IT

23 septembre 2008 C/O:Volvo IT

• L’entreprise doit maîtriser 7 des 22 processus :

• Ce niveau ne s’interroge pas sur la pertinence de l’expression de besoin

23 septembre 2008 C/O:Volvo IT

23 septembre 2008 C/O:Volvo IT

• L’entreprise doit maîtriser 11 nouveaux processus en plus de ceux du

• Correspond au passage d’une structure projet vers une structure

23 septembre 2008 C/O:Volvo IT

– Approfondissement des processus de gestion de projet

23 septembre 2008 C/O:Volvo IT

• On va travailler sur la notion de productivité, de performance des projets et

• Attention : L’utilisation de ce niveau n’a de sens que si l’on se base sur un

23 septembre 2008 C/O:Volvo IT

• Ce qui caractérise ce niveau :

23 septembre 2008 C/O:Volvo IT

• Ce niveau nécessite la maîtrise de l’ensemble des processus par

• La mise en place de ce niveau implique en plus de ce qui est effectif au

23 septembre 2008 C/O:Volvo IT

• Ce qui caractérise ce niveau :

23 septembre 2008 C/O:Volvo IT

23 septembre 2008 C/O:Volvo IT

• Elément clé du succès

23 septembre 2008 C/O:Volvo IT

23 septembre 2008 C/O:Volvo IT

23 septembre 2008 C/O:Volvo IT

23 septembre 2008 C/O:Volvo IT

23 septembre 2008 C/O:Volvo IT

• Impact sur les coûts

20 % de réduction par unité de logiciel Lockheed Martin M&DS CMMI

15 % de réduction pour trouver et réparer une Lockheed Martin M&DS CMMI

• Impact sur les délais