InfoPro l’essentiel se forMer type d’ouvrage …...CMMI 1.3 Guide complet de CMMI-DEV et...

www.dunod.com

InfoPro

CMM

I 1.3

r. B

asq

ue

MAN

AGEM

ENT

des

SYST

ÈMES

D’IN

FOR

MAT

ION

ManageMent des systèMes d’inforMation

applications Métiers

études, développeMent, intégration

exploitation et adMinistration

réseaux & télécoMs

CMMI 1.3

Guide complet de CMMI-DEVet traduction de toutes les pratiques

CMMI-ACQ et CMMI-SVC

type d’ouvrage

l’essentiel se forMer retoursd’expérience

RichaRd Basque

est instructeur cMMi et évaluateur scaMPi certifié par le sei. il est aussi le fondateur d’alcyonix, société de services spécialisée en amélioration de processus, aujourd’hui intégrée dans le groupe sqLi, qui utilise le cMMi en interne depuis plusieurs années dans son réseau d’agences.

Le forum de discussion cmmi-en-francais (sur Yahoo!) fondé par l’auteur prolonge ce livre par des discussions enrichissantes entre les membres.Retrouvez également sur www.dunod.com les suppléments gratuits de l’ouvrage.

Cet ouvrage s’adresse aux managers et aux praticiens du domaine de l’ingénierie des systèmes ou du logiciel (directeurs, responsables de la qualité, chefs de projet).Le cMMi, dont la version 1.3 a été publiée à l’automne 2010, est de plus en plus largement utilisé pour évaluer la maturité de processus, pour développer des plans d’amélioration ou pour mettre en œuvre des pratiques plus matures.ce livre est un guide commenté du pourquoi et du comment de ce modèle de bonnes pratiques. il a surtout pour vocation d’aider concrètement les organisations qui veulent réussir leurs projets, dans les délais, dans les budgets et à la satisfaction de leurs clients.Élaboré par un spécialiste du domaine, il vous apportera des conseils utiles à chaque étape du parcours.

CMMI 1.3 Guide complet de CMMI-DeV et traduction de toutes les pratiques CMMI-aCq et CMMI-sVC

Richard Basque

« Si vous envisagez de tirer le meilleur profit du modèle CMMI et que vous vous interrogez sur la meilleure façon de le déployer dans votre organisation, ce livre vous est destiné. »

Mike Konrad (The software engineering institute)

« Avec cette nouvelle édition, Richard contribue encore une fois à cette vision de l’amélioration continue que nous souhaitons partager avec la CMMI Product Suite. »

Mike Phillips (The software engineering institute)

6917009ISBN 978-2-10-055831-5

Richard Basque

Préfaces de Mike Konrad, Mike Phillips

“Basque_55831” (Col. : InfoPro) — 2011/3/17 — 11:37 — page XIX — #19

i

i

i

i

i

i

i

i

Table des matières

Préface de Mike Konrad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII

Préface de Mike Phillips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX

Note de l’auteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI

Avant-propos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXV

Chapitre 1 – La genèse d’un modèle de meilleures pratiques . . . . . . . . . . . . . . . . . . . . 1

Chapitre 2 – L’étoile CMMI dans la galaxie des modèles . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 ISO9001:2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 ISO/IEC 15504 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 ISO12207 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 iCMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5 ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.6 SA-CMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.7 PMBOK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.8 COBIT et Sarbanes-Oxley (SOX) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.9 Agile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.10 eSCM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.11 SCAMPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

“Basque_55831” (Col. : InfoPro) — 2011/3/17 — 11:37 — page XX — #20

i

i

i

i

i

i

i

i

XX CMMI 1.3

Chapitre 3 – Une échelle de maturité organisationnelle . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 La parabole de la visite chez le médecin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 La parabole du trajet en voiture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3 Le CMMI au regard de ces paraboles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4 Tronc commun et parties spécifiques dans les trois constellations du CMMI . . . 24

Chapitre 4 – Terminologie particulière au CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Organisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2 Projet et travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3 Manager et gestionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.4 Chef de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.5 Groupe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.6 Représentation, niveau, maturité et aptitude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.7 Nomenclature des niveaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.8 Adéquat, approprié, au besoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.9 Établir et maintenir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.10 Client et utilisateur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.11 Fournisseur et prestataire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.12 Parties prenantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.13 Produits d’activité, produits et services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.14 Évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.15 Actifs processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.16 CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Chapitre 5 – L’architecture du modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1 Les deux représentations du CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1.1 La représentation étagée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1.2 La représentation continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.1.3 Que choisir ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.2 Les différents composants du CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2.1 Domaine de processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

“Basque_55831” (Col. : InfoPro) — 2011/3/17 — 11:37 — page XXI — #21

i

i

i

i

i

i

i

i

Table des matières XXI

5.2.2 Intention, notes explicatives et références . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2.3 Objectifs et pratiques génériques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.2.4 Objectifs spécifiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2.5 Pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.2.6 Exemples de produits d’activité typiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.2.7 Sous-pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.2.8 Élaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.2.9 Divers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Chapitre 6 – Les niveaux 0 et 1 : des cas très particuliers . . . . . . . . . . . . . . . . . . . . . . 59

Chapitre 7 – Le niveau 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.1 Interprétation de l’objectif générique GG2 et des pratiques génériques GP2.1à GP2.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.1.1 GP2.1 – Établir une directive organisationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.1.2 GP2.2 – Planifier le processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.1.3 GP2.3 – Fournir les ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.1.4 GP2.4 – Assigner la responsabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.1.5 GP2.5 – Former les personnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.1.6 GP2.6 – Contrôler les produits d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7.1.7 GP2.7 – Identifier et impliquer les parties prenantes concernées . . . . . . . . . . . . . 72

7.1.8 GP2.8 – Surveiller et contrôler le processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.1.9 GP2.9 – Évaluer la conformité de manière objective . . . . . . . . . . . . . . . . . . . . . . . 74

7.1.10 GP2.10 – Passer le statut en revue avec la hiérarchie . . . . . . . . . . . . . . . . . . . . . . 74

7.2 Interprétation des pratiques spécifiques dans les domaines de processusde la constellation DEV au niveau de maturité 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.2.1 Gestion des exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.2.2 Planification de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

7.2.3 Surveillance et contrôle de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

7.2.4 Gestion des accords avec les fournisseurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

7.2.5 Mesure et analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

7.2.6 Assurance qualité processus et produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

7.2.7 Gestion de configuration (un domaine de processus de la catégorie Support dansla représentation continue) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

“Basque_55831” (Col. : InfoPro) — 2011/3/17 — 11:37 — page XXII — #22

i

i

i

i

i

i

i

i

XXII CMMI 1.3


8.1 Interprétation de l’objectif générique GG3 et des pratiques génériques GP3 . . . 113

8.1.1 GP3.1 – Établir un processus ajusté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

8.1.2 GP3.2 – Recueillir des retours d’expériences relatifs au processus . . . . . . . . . . . . 114


8.2.1 Développement des exigences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

8.2.2 Solution technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

8.2.3 Intégration de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

8.2.4 Vérification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

8.2.5 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

8.2.6 Focalisation sur le processus organisationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

8.2.7 Définition du processus organisationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

8.2.8 Formation organisationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

8.2.9 Gestion de projet intégrée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

8.2.10 Gestion des risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

8.2.11 Analyse et prise de décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156



9.1.1 Performance du processus organisationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

9.1.2 Gestion de projet quantitative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Chapitre 10 – Le niveau 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

10.1 Interprétation des pratiques spécifiques dans les domaines de processusde la constellation dev au niveau de maturité 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

10.1.1 Analyse causale et résolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

10.1.2 Gestion de la performance organisationnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Chapitre 11 – Un cas concret . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Chapitre 12 – Les bénéfices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Chapitre 13 – Utilisations possibles du CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

13.1 Guide de bonnes pratiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

“Basque_55831” (Col. : InfoPro) — 2011/3/17 — 11:37 — page XXIII — #23

i

i

i

i

i

i

i

i

Table des matières XXIII

13.2 Sources de gabarits (modèles) pour des processus à améliorer ou à définir . . . . . 197

13.3 Source d’inspiration pour une approche d’amélioration continue et progressive 198

13.4 Référentiel pour s’auto-évaluer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

13.5 Référentiel pour évaluer des tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

13.5.1 Fournisseurs potentiels (sélection) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

13.5.2 Fournisseurs actuels (audit en cours de projet en vue d’une décision de go/nogo) 199

13.5.3 « Due diligence » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

ANNEXES

Annexe A – Indicateurs des pratiques du CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Annexe B – La pénétration du CMMI dans le monde . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Annexe C – Les « certifications » du SEI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Annexe D – « Histoires vécues » et autres histoires . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Annexe E – CMMI-ACQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Annexe F – CMMI-SVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Références bibliographiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

“Basque_55831” (Col. : InfoPro) — 2011/3/17 — 11:37 — page 41 — #71

i

i

i

i

i

i

i

i

L’architecture du modèle

5

Dans ce chapitre, nous expliquerons la structure du modèle CMMI.

Globalement, chaque constellation du CMMI couvre un ensemble de disciplines1

(ou métiers) et non uniquement la discipline du logiciel comme le faisait son ancêtre(le SW-CMM).

Avant d’examiner l’architecture interne du modèle, il importe donc de rappelerque sa portée dépasse le monde du logiciel. Le « I » du sigle CMMI signifie Integration.Le CMMI intègre en effet des disciplines multiples. Nous associons le concept dediscipline à celui d’un « corpus de connaissances » qui est souvent à la base de ladéfinition de toute discipline. Ainsi le développement de logiciel constitue l’une desdisciplines. On peut décrire un corpus de connaissances requises de la part de ceuxqui visent à exercer cette discipline. Par exemple, pour la discipline du logiciel, ce futl’objet du projet SWEBOK (Software Engineering Body of Knowledge). Pour la disciplinede la gestion de projet, on peut penser au PMBOK (Project Management Body ofKnowledge) du PMI (Project Management Institute). Mais revenons au CMMI : dans saconstellation DEV, il va chercher son contenu dans les disciplines de développementde logiciel (Software Engineering), mais aussi de développement de systèmes (SystemEngineering) et de développement matériel (Hardware Engineering).

Par cette approche ouverte aux disciplines variées, la portée du CMMI pourraitbien s’étendre et absorber d’autres disciplines dans ses versions futures. Véritable« work-in-progress », l’avenir du CMMI se dirigera vers où sa communauté d’utilisateursvoudra bien le diriger. Évidemment, bien que le CMMI soit à géométrie variable, onpeut s’intéresser seulement aux disciplines qui nous intéressent. Rien n’oblige unutilisateur du modèle à utiliser toutes les disciplines couvertes par le modèle.

1. Voir la note en bas de page de la première page du chapitre 1.


i

i

i

i

i

i

i

i

42 Chapitre 5. L’architecture du modèle

Lors du passage de la version 1.1 à la version 1.2 du CMMI, les auteurs ontconstaté qu’il serait utile de grouper les disciplines par vocation ; ils ont désigné cesregroupements par le mot « constellation ». Ainsi, le trio logiciel, système et matérieldans un contexte de projet d’élaboration ou de construction d’un livrable se nommeDEV (qui signifie « Développement »). Lors du passage à la version 1.2, à cetteconstellation DEV se sont déjà ajoutées les constellations ACQ (pour acquisition)et SVC (pour services). Lors de la publication de la version 1.3 du CMMI, on netrouve toujours que ces 3 constellations : DEV, ACQ et SVC, Mais on peut imaginerque d’autres constellations du CMMI se rajouteront au fil des années en fonction desbesoins exprimés par la collectivité qui utilise le CMMI. Certains grands utilisateursdu CMMI souhaiteraient par exemple mettre sur étagère les bonnes pratiques dupassage du développement du prototype à l’industrialisation à grande échelle (à laligne de production). D’autres aimeraient voir intégrer dans la famille CMMI lesbonnes pratiques de gestion du personnel que l’on trouve dans P-CMM. L’avenir nousdira qui seront les futurs « enfants » du CMMI.

5.1 LES DEUX REPRÉSENTATIONS DU CMMI

Deux visions de l’expression de l’évolution de la capacité de développement se sontaffrontées lors de la genèse du modèle CMMI. Une école de pensée privilégiaitde considérer l’évolution des pratiques par stade ou par étape, en situant cetteévolution au niveau de toute une organisation de développement. Héritière de lavision implémentée dans le modèle SW-CMM (ancien modèle du SEI qui ne traitaitque du développement logiciel), cette approche se nomme « Staged » qu’on a traduitpar « Étagée ». Une autre école de pensée, née lors de la conception du modèleSE-CMM (un autre ancien modèle auquel a également fortement contribué le SEI etqui était axé sur le développement de système où le logiciel joue un rôle prépondérantmais n’est qu’un élément du projet de développement) privilégiait de focaliser surl’évolution de chaque domaine de processus (Process Area) spécifique et d’y associerdes stades de développement de l’aptitude du domaine de processus en question.Cette approche se nomme « Continuous » qu’on a traduit par « Continue ». Elle futégalement adoptée par le projet SPICE qui a défini une norme ISO/IEC 15504 quis’appuie justement sur une représentation continue.

Confronté à ces deux visions du monde de l’évolution des processus et n’arrivantà opter ni pour l’une ni pour l’autre, le SEI a tranché à la Salomon en proposant lesdeux représentations. Le modèle CMMI se présente donc en représentation étagéeet aussi en représentation continue. Nous verrons un peu plus loin que cette doublepersonnalité du CMMI apporte plus d’avantages que d’inconvénients.

5.1.1 La représentation étagée

La représentation étagée exprime l’évolution des pratiques en fonction d’une vueplus globale ou organisationnelle. Quand on songe à déployer le CMMI, on définitd’abord un périmètre cible que le CMMI désigne par le vocable « l’organisation ». Ceci


i

i

i

i

i

i

i

i

5.1 Les deux représentations du CMMI 43

peut très bien correspondre à toute une société ou seulement à un sous-ensemblede celle-ci : une division, une ligne d’affaire, un site géographique. Puis on observele comportement de cette entité au regard d’une échelle comportant cinq niveauxde maturité organisationnelle. C’est un peu comme les stades de développementde l’intelligence proposés par Piaget. L’organisation, selon la représentation étagée,passe par cinq niveaux de maturité. Chaque niveau est associé à la maîtrise, partoute l’organisation, d’un certain nombre de domaines de processus. Le modèle faitdébuter l’évolution d’une organisation au niveau de maturité 1 (Initial) et proposeune progression jusqu’au niveau de maturité 5 (En optimisation). Pour monter d’unniveau, il faut que toute l’organisation maîtrise, et donc institutionnalise, l’ensembledes domaines de processus associés au niveau supérieur.

Figure 5.1 — La représentation étagée.

La représentation étagée se présente comme une espèce d’escalier. En référence àma jeunesse et ma période rock, je le nomme souvent « Stairway to heaven » puisquece « Stairway » aboutit au « Heaven » des processus : le niveau de maturité 5, celui del’optimisation, le but ultime de la démarche d’amélioration de processus. Le niveauplancher (le plus bas niveau) correspond au niveau de maturité 1. Toute organisationqui veut développer des produits ou offrir des services commence d’abord, comme unbébé, par « ramper » de façon plus ou moins organisée et disciplinée. Ses processus detravail se structurent progressivement et s’organisent de plus en plus, tout comme lebébé devient enfant. L’organisation se dirige vers une maîtrise accrue de la disciplinede développement. On peut alors constater que l’organisation a atteint un plateausupérieur : le niveau de maturité 2 dit « Discipliné ». Progressivement, les intervenantsau sein de l’organisation se rendent compte à quel point il serait utile de capitalisersur les expériences passées pour devenir de plus en plus performants. On réutilisealors des processus organisationnels standards. En même temps, on s’efforce de bienajuster ces processus communs ou standards aux spécificités des projets ou des services,comme lorsqu’on achète du prêt-à-porter et qu’on fait ajuster son costume ou sa robe.Pour y arriver, on doit maîtriser plusieurs domaines de processus additionnels. Unefois ces processus de capitalisation (et quelques autres) maîtrisés, l’organisation estau niveau de maturité 3 ou « Ajusté ». La prochaine étape, le niveau de maturité 4,sera associée à une approche de gestion quantitative généralisée dans tous les projetset services de l’organisation ; le niveau se nomme d’ailleurs « Géré quantitativement ».Enfin, le nirvana est associé à l’optimisation continue, le niveau de maturité 5 (« En


i

i

i

i

i

i

i

i


optimisation »). À cette étape, l’organisation est une espèce de machine qui s’auto-optimise sans arrêt.

5.1.2 La représentation continue

La représentation continue utilise une vision plus ciblée de l’évolution des pra-tiques. En effet, plutôt que de chercher à exprimer les stades d’évolution de toutel’organisation en cinq paliers, avec des bouquets de processus comme le fait lareprésentation étagée, la représentation continue exprime la capacité ou l’aptitude dechaque processus pris séparément au sein de l’organisation. Schématiquement, au lieud’un seul escalier pour illustrer la maturité de toute l’organisation, il faut un escalierpar domaine de processus pour exprimer sa capacité ou son aptitude. En fait, plutôtque de recourir à des images d’escaliers, on utilise plutôt des diagrammes à colonnesoù chaque colonne (on dit parfois « silo » ou « cheminée ») traduit, par sa hauteur eten fonction d’une échelle graduée de zéro à cinq, le niveau d’aptitude du processus.L’ensemble des colonnes pour les processus choisis constitue ainsi un profil d’aptitudepour l’organisation.

Le lecteur attentif aura remarqué que j’ai dit ci-dessus que l’échelle de la repré-sentation continue commence à zéro plutôt qu’à 1 comme dans la représentationétagée. En effet, comme elle est plus ciblée et ne porte que sur un processus à lafois, la représentation continue doit pouvoir exprimer la situation où la réalisationdes activités de base d’un processus est tout simplement nulle ou très incomplète.Ceci constitue alors le niveau zéro de ce processus. Si on y réfléchit bien, dans lareprésentation étagée, il serait pour le moins surprenant que pour tout un bouquetde processus, aucun d’eux ne soit réalisé ; un niveau de maturité zéro dans lareprésentation étagée devient donc inutile et l’échelle de référence commence donc,tout simplement, à 1. C’est moins déprimant diront avec humour certains partisans dela représentation étagée de commencer à 1 que de partir à zéro ! À partir du niveau 2,les deux représentations expriment sensiblement la même idée de progression maisappliquée à l’aptitude d’un processus donné dans le cas de la représentation continueet à la maturité de toute l’organisation dans le cas de la représentation étagée.

Figure 5.2 — La représentation continue.


i

i

i

i

i

i

i

i

5.1 Les deux représentations du CMMI 45

5.1.3 Que choisir ?

Alors, comment choisir : étagée ou continue ? Examinons les avantages et les incon-vénients de l’une et de l’autre.

La représentation étagée permet en une seule image forte (la maturité de l’organi-sation caractérisée par un seul chiffre) d’exprimer de façon très synthétique un étatdes lieux ou un objectif à atteindre. Ainsi, suite à une évaluation de la maturité d’uneorganisation, avec la méthode SCAMPI par exemple, on dira : « L’évaluation a révéléque cette organisation fonctionne à un niveau de maturité 1 (ou 2, ou 3, etc.). » Pourla Direction d’une telle organisation, l’objectif est simple à fixer : « D’ici x mois – ouannées –, nous nous fixons comme organisation l’objectif d’atteindre le niveau de maturité 2(ou 3, ou 4, etc.). » Cette même Direction peut comparer son organisation à une autre,grâce à cette caractérisation par un seul chiffre de la maturité organisationnelle ; fairece que l’on appelle communément du « benchmarking ». En utilisant les statistiquespubliées par le SEI, il est facile de se comparer, de déterminer à quelle catégorie(plus ou moins mature) d’organisations on appartient. L’ensemble des personnes d’unemême organisation peut facilement se rallier autour de cet objectif simple : être auniveau actuel + 1 d’ici « n » mois ou années.

Tout ça est vrai diront les tenants de la représentation continue. Mais la simplicitén’est pas toujours bonne conseillère ! L’image d’un seul niveau de maturité pourtoute l’organisation est peut-être séduisante et forte dans son dépouillement zenmais simplifie exagérément la réalité qu’elle cherche à modéliser. La représentationcontinue permet d’exprimer toute la subtilité de la progression de l’aptitude desdifférents processus que l’on cherche à mettre en œuvre. N’est-il pas exagérémentsimpliste de vouloir progresser sur un ensemble de processus (par exemple la Gestion deconfiguration et la Planification de projet) au même rythme ? La représentation continue,à cet égard, offre cette subtile distinction dans la progression, pas nécessairementsynchrone, de l’aptitude de plusieurs processus. Pour l’équipe de soutien au processus,la planification de l’amélioration peut se décliner en objectifs beaucoup plus clairs :atteindre le niveau d’aptitude « n » de tel ou tel processus. L’éléphant, c’est connu,se mange mieux par petites bouchées. Faut-il donc laisser nos lecteurs sur ce débatd’experts ? Je me souviendrai toujours de cette boutade de deux collègues de lacommunauté des évaluateurs CMMI : pourquoi pas les deux ? En 2002, lors de laconférence SEPG (Software Engineering Process Group) qui se tenait cette année-là àPhœnix en Arizona, Agapi Svolou et Tim Kasse proposaient un nouveau concept :l’approche « con-stagious ». Ceci a frappé l’imaginaire des participants. La peur despandémies et la contagion par les virus de toutes sortes hantait déjà les esprits. Ils ontretourné le concept de contagion et en ont fait quelque chose de positif. Une approchepositivement « contaminante » serait idéale. Un amalgame de la représentation étagéeet de la représentation continue correspond sans doute, de toute façon, aux besoinscomplémentaires de deux types de personnes dans la même organisation. D’une part,le management qui doit fixer des objectifs et qui doit suivre la progression de toutel’organisation vers l’atteinte de ces objectifs se sentira à l’aise avec la représentationétagée. Les gens du terrain, ceux qui, telles de vaillantes fourmis ouvrières dans lafourmilière, doivent déployer une à une les améliorations de processus apprécieront


i

i

i

i

i

i

i

i


les repères plus fréquents et ciblés de la représentation continue. Une publicitébien connue en Amérique présente le côté « sage » et le côté « givré » d’un certainpetit-déjeuner fait de petits carrés à base de céréale et conclut que les deux « côtés »sont importants. Exit la controverse : il faut assumer les deux côtés de sa personnalité.

Pour les besoins de ce livre et pour éviter d’entraîner le lecteur dans un parcourssystématiquement parallèle (un petit bout d’étagé puis un petit bout de continu, enboucle), j’ai fait un choix éditorial basé sur mon vécu sur le terrain. Mes clientsutilisent à plus de 80 % la représentation étagée. Je choisis donc de développerprioritairement, dans la suite de ce livre, l’approche étagée. Ceci ne constitue pas undéni des avantages bien réels de la représentation continue. En fait, lorsqu’on regardesereinement le contenu du livre CMMI dans les deux représentations, on s’aperçoitrapidement que le contenu important (la description des pratiques) est identique !Moins de 10 % (et encore !) des pages sont différentes. De plus, les cours officielssur le CMMI combinent à la fois la représentation continue et la représentationétagée. D’ailleurs, les auteurs du CMMI, lorsqu’ils ont publié le modèle en anglais enformat livre à couverture rigide (plutôt qu’en version classeur à anneaux) ont choisicette approche de présenter le modèle dans ses deux représentations. La version 1.3quant à elle, même dans le « Technical Report » original du SEI, combine les deuxreprésentations dans un seul manuel.

Soyez donc rassurés. Je parlerai surtout « étagé » dans ce livre mais je n’abandonne-rai pas à leur sort les partisans « continus ». Je leur ai déjà consacré toute une page !

5.2 LES DIFFÉRENTS COMPOSANTS DU CMMI1

Le CMMI est une construction qui utilise divers composants. Ça me rappelle mes jeuxde briques de plastique qui occupaient mes journées de vacances lorsque j’étais enfant.Il y avait de petites briques, des plus grandes, des pièces de fondation sur lesquelles ondevait commencer par disposer ses briques. Elles étaient toutes de couleur rouge et enplastique souple : c’était avant les Legos (hélas ça me rappelle mon vieil âge !). Aussi,bien sûr, il y avait des portes, des fenêtres... Je m’arrête : on aura compris l’image descomposants ! Le composant fondamental du CMMI est le « domaine de processus ». Enreprésentation étagée, chaque niveau de maturité est associé à un ensemble précis dedomaines de processus ; la notion de niveau est appliquée à cet ensemble de domainesde processus et on parle de niveau de maturité de l’organisation. En représentationcontinue, chaque domaine de processus est pris séparément ; la notion de niveau estappliquée à chaque domaine de processus pris individuellement et grâce aux pratiquesgénériques appliquées à chacun, on parle alors de niveau d’aptitude du domaine deprocessus.

Voyons donc comment chaque domaine de processus est décrit dans le CMMI.

1. Je suggère fortement au lecteur de suivre dans le CMMI (version française complète approuvéepar le SEI ou version originale anglaise) les sections qui correspondent à celles que l’on aborde ici.Les exemples tirés du CMMI dans les pages qui suivent permettront au lecteur de facilement serepérer dans le modèle CMMI.


i

i

i

i

i

i

i

i

5.2 Les différents composants du CMMI 47

Niveau de maturité

Représentation étagée

Domaines

de processus

Objectifs

génériques

Objectifs

spécifiques

Pratiques

spécifiquesPratiques

génériques Niv

eau

d’a

ptitu

de

Représentation continue

Domaines

de processus

Objectifs

génériques

Objectifs

spécifiques

Pratiques

spécifiquesPratiques

génériques

Figure 5.3 — Architecture fondamentale du CMMIdans ses deux représentations (étagée et continue).

5.2.1 Domaine de processus

Le composant fondamental du CMMI est le domaine de processus (Process Area).L’ensemble des activités accomplies peut se décrire en fonction d’une espèce detoponymie des processus. Le CMMI, dans sa version 1.3 et dans la constellationDEV, propose un total de 22 domaines de processus ; la constellation ACQ en compteégalement 22 et la constellation SVC quant à elle en compte 24. Si on se rappelle quele CMMI est un livre, alors les domaines de processus en sont les chapitres. Le CMMIutilise rigoureusement le même schéma de décomposition et d’écriture pour chacunde ses chapitres, c’est-à-dire pour chacun de ses domaines de processus. Ceci est bienpratique : quand on a lu le contenu d’un domaine de processus, on retrouve facilementla même structure dans tous autres domaines de processus. Ceci facilite grandementl’apprentissage du modèle et la navigation à l’intérieur du CMMI puisqu’on trouvetoujours les mêmes choses aux mêmes endroits, comme dans l’atelier de tout bonbricoleur ou dans les armoires de toute bonne cuisinière. Mais j’aurais pu tout aussi biendire de toute bonne bricoleuse ou de tout bon cuisinier : la langue française permetces subtilités ! Citons, à titre d’exemple, quelques domaines de processus : Gestion desexigences (REQM), Planification de projet (PP), Validation (VAL), Analyse causale etrésolution (CAR). Les sigles entre parenthèses sont ceux que l’on utilise courammentpour désigner les noms de domaines ; on aura compris que ce sont simplement lespremières lettres de chaque mot composant les noms de domaine en anglais.


i

i

i

i

i

i

i

i


5.2.2 Intention, notes explicatives et références

Les toutes premières lignes d’un « chapitre » de domaine de processus décriventl’intention (Purpose) du domaine en question. Lors de mes cours sur le CMMI, jedis souvent qu’il n’y a aucune excuse valable pour ignorer de quoi est fait le CMMI.Dans un seul trajet de la maison au travail, même en voiture (avec les feux rouges)on aura le temps de lire au moins ces petits paragraphes que l’on trouve au tout débutdes domaines de processus. Qui n’a pas 15 minutes dans sa vie pour lire le CMMI ?L’intention nous situe tout de suite dans le contexte de base du domaine de processus.Ainsi, dans le chapitre consacré au domaine de Planification de projet, les auteursdébutent par « L’intention du domaine de processus Planification de projet est d’établir etmaintenir des plans qui décrivent les activités du projet ». Voilà en quelques mots simplesbien campés le caractère fondamental du « personnage » Planification. Ce paragrapheest ensuite suivi de notes explicatives (en général une page environ) qui brossentde façon un peu plus étoffée et de manière plus littéraire la nature du domaine deprocessus.

Tableau 5.1 — Exemple tiré du CMMI de la description de l’intention (« Purpose »)d’un domaine de processus et des notes explicatives (« Introductory Notes »).

Project planningA Project Management Process Areaat Maturity Level 2

Planification de projetUn domaine de processus de la catégorieGestion de projet du niveau de maturité 2

Purpose Intention

The purpose of Project Planning (PP) is toestablish and maintain plans that define projectactivities.

L’intention de « Planification de projet » (PP) estd’établir et maintenir les plans qui définissent lesactivités de projet.

Introductory Notes Notes explicatives

(...) The Project Planning process area involvesthe following :• Developing the project plan• Interacting with stakeholders appropriately• Getting commitment to the plan• Maintaining the plan(...)

(...) Voici ce que comprend le domaine deprocessus Planification de projet :• développement de projet ;• interaction adéquate avec les partiesprenantes ;• obtention d’un engagement envers le plan ;• maintien du plan.(...)

Le lecteur attentif aura remarqué dans la version originale anglaise du CMMI que lenom du domaine de processus est toujours suivi, en plus petits caractères une ligne endessous, de deux informations juxtaposées dans une expression sibylline. On y donned’abord l’appartenance du domaine de processus dans la représentation continue c’est-à-dire sa « catégorie » ; puis on précise aussi son appartenance dans la représentation


i

i

i

i

i

i

i

i


étagée, c’est-à-dire son « niveau de maturité ». Ainsi, en ce concerne notre exemple,PP appartient à la catégorie « Gestion de projet » dans la représentation continue etest situé au niveau de maturité 2 dans la représentation étagée.

Suite aux quelques paragraphes de notes explicatives, les auteurs listent lesréférences entre domaines de processus. À titre d’exemple, la Planification de projet(PP) est liée au Développement des exigences (RD) parce qu’il faut évidemmentconnaître le contenu (obtenu de RD) de ce que doit couvrir le plan de projet(développé en PP). Dans chacun des domaines, les auteurs ont ainsi commodémentregroupé tous les liens entre domaines de processus.

Tableau 5.2 — Exemple tiré du CMMI de liens entre PPet les autres domaines de processus (Related Process Area).

Related Process Areas Références entre domainesde processus

Refer to the Requirements Development processarea for more information about eliciting,analyzing, and establishing customer, product,and product component requirements.

Refer to the Technical Solution process area formore information about selecting, designing, andimplementing solutions to requirements.Refer to the Measurement and Analysis processarea for more information about specifyingmeasures.

Refer to the Requirements Management processarea for more information about managingrequirements.Refer to the Risk Management process area formore information about identifying and analyzingrisks and mitigating risks.

Pour plus d’informations sur l’obtention etl’explicitation, l’analyse et la documentation desexigences client, produit et composants deproduit, reportezvous au domaine de processusDéveloppement des exigences. Pour plusd’informations sur la sélection, la conception etl’implémentation de solutions aux exigences,reportezvous au domaine de processus Solutiontechnique.Pour plus d’informations sur la spécification desmesures, reportezvous au domaine de processusMesure et analyse.Pour plus d’informations sur la gestion desexigences, reportezvous au domaine deprocessus Gestion des exigences.Pour plus d’informations sur l’identification etl’analyse des risques et sur la réduction desrisques, reportezvous au domaine de processusGestion des risques.

Poursuivons la lecture du domaine de processus. À la suite du paragraphe d’inten-tion, de la page de notes explicatives et des références croisées entre domaines, ontrouve un tableau des objectifs et des pratiques associées à chacun d’eux. Exploronsce que ces concepts veulent dire dans le contexte du CMMI.

5.2.3 Objectifs et pratiques génériques

Le lecteur trouve dans une section qui précède la description détaillée de chaquedomaine de processus une section consacrée à une série d’objectifs et de pratiquesdites Génériques. On remarquera le caractère différent de ces objectifs et de leurspratiques associées quand on les compare aux objectifs et pratiques Spécifiques des


i

i

i

i

i

i

i

i


pages subséquentes (les pages consacrées à chaque domaine de processus). Si lesobjectifs et pratiques Spécifiques sont intimement associés à la nature même dudomaine de processus, les objectifs et pratiques Génériques s’appliquent à chacun desdomaines de processus contenus dans le CMMI. Les objectifs et pratiques spécifiquessont, comme on peut s’y attendre, très différents dans leur formulation même d’undomaine de processus à l’autre. Si on parle d’estimation (une activité qui, en toutelogique, est bel et bien spécifique à la planification) dans le domaine de processusPlanification de projet, on parlera d’actions correctives en Surveillance et contrôle deprojet, de préparation d’un environnement d’essais en Vérification, pour ne donnerque quelques exemples illustrant le caractère spécifique (forcément) des objectifs etpratiques Spécifiques. Par contraste, les objectifs et pratiques décrits dans le chapitrequi précède ceux consacrés aux différents processus présentent un caractère Générique.On peut les copier-coller d’un domaine de processus à l’autre, en ne changeant quele nom du domaine de processus auquel on l’applique. Les objectifs et pratiquesgénériques d’un domaine de processus sont, de plus, intimement liés au niveau dematurité de l’organisation (en représentation étagée) ou d’aptitude du processus (enreprésentation continue). On peut dire que l’objectif générique, avec son train depratiques associées, situe le degré d’institutionnalisation d’un domaine de processusalors que les objectifs spécifiques en décrivent les activités de base.

Comme ils sont communs à tous les domaines de processus, le CMMI ne les décritcomplètement qu’une seule fois, au tout début de la partie II. Mais il ne faut jamaisoublier qu’ils s’appliquent à chacun des 22 (ou 24, pour la constellation SVC) domainede processus même s’ils ne sont pas recopiés.

Attention : le numéro d’un objectif générique correspond au niveau de maturitéauquel il correspond. Ainsi GG2 signifie que cet objectif est requis de chaque domainede processus (en plus de ses pratiques spécifiques) pour atteindre le niveau 2. Parcontre le numéro d’un objectif spécifique est NON signifiant et en vise qu’à donnerune identification unique à chaque objectif. De plus, pour les objectifs (et pratiquesd’ailleurs) spécifiques, ce numéro n’impose aucune séquence chronologique : le CMMIn’impose absolument pas qu’un objectif SG2 soit réalisé après un objectif SG1 dansun même domaine de processus. De la même façon, le CMMI n’impose pas qu’unepratique SP1.1 soit accomplie avant une activité SP1.2 ou même une activité SP2.3.Bien se rappeler que le numéro d’un objectif et d’une pratique n’a de sens que dansle cas des Génériques.

Ayant choisi de structurer mon livre par niveau de maturité selon la représentationétagée, on trouvera les objectifs génériques et les pratiques génériques associées endébut de chapitre correspondant à chaque niveau de maturité.

5.2.4 Objectifs spécifiques

Dans le CMMI, chaque domaine de processus comporte un certain nombre d’objectifs

(goals) à atteindre. Il y a deux types d’objectifs : les spécifiques, propres à chaquedomaine de processus, et les génériques, identiques ou communs d’un domaine de


i

i

i

i

i

i

i

i


processus à l’autre. Comme je le soulignais précédemment, je reviendrai sur lesobjectifs génériques un peu plus loin.

Lorsqu’on évalue une organisation vis-à-vis le CMMI, les objectifs représententautant de critères pour juger de la satisfaction, par l’organisation, des exigences dumodèle au regard du domaine de processus. Petites phrases très courtes, les objectifsd’un domaine de processus sont à ce point fondamentaux que la maîtrise de tous lesobjectifs est obligatoire pour décréter la satisfaction du domaine de processus. Quandon fait une évaluation des processus sur la base du CMMI, il suffit qu’un seul objectifne soit pas satisfait pour considérer que le domaine de processus ne soit pas satisfait !Ceci peut sembler excessif au profane. Mais il lui suffira d’un exemple pour comprendreque cela va quasiment de soi.

Tableau 5.3 — Exemple tiré du CMMI de la table des objectifs spécifiqueset des pratiques spécifiques associées pour PP.

Specific Goal and Practice Summary Objectifs et pratiques spécifiques

SG 1 Establish EstimatesSP 1.1 Estimate the Scope of the ProjectSP 1.2 Establish Estimates of Work

Product and Task AttributesSP 1.3 Define Project LifecycleSP 1.4 EstimateEffort

and Cost

SG 1 Établir les estimationsSP 1.1 Faire l’estimation de la portée

du projetSP 1.2 Établir les estimations des attributs des

produits d’activité et des tâchesSP 1.3 Définir le cycle de vie du projetSP 1.4 Estimer la charge et le coût

SG 2 Develop a Project PlanSP 2.1 Establish the Budget and ScheduleSP 2.2 Identify Project RisksSP 2.3 Plan Data ManagementSP 2.4 Plan Project ResourcesSP 2.5 Plan Needed Knowledge

and SkillsSP 2.6 Plan Stakeholder InvolvementSP 2.7 Establish the Project Plan

SG 2 Développer un plan de projetSP 2.1 Établir le budget et le calendrierSP 2.2 Identifier les risques du projetSP 2.3 Prévoir la gestion des donnéesSP 2.4 Prévoir les ressources du projetSP 2.5 Prévoir les connaissances

et aptitudes nécessairesSP 2.6 Prévoir l’implication des parties

prenantesSP 2.7 Établir le plan de projet

SG 3 Obtain Commitment to the PlanSP 3.1 Review Plans that Affect the ProjectSP 3.2 Reconcile Work and Resource LevelsSP 3.3 Obtain Plan Commitment

SG 3 Obtenir l’engagement sur le planSP 3.1 Plan en revue les plans qui ont

des répercussions sur le projetSP 3.2 Concilier les niveaux de charge

et de ressourcesSP 3.3 Obtenir l’engagement au plan


i

i

i

i

i

i

i

i


Ainsi, dans le domaine de processus Planification de projet comprend trois objectifsspécifiques (identifiés par SG pour Specific Goal puis un chiffre séquentiel) :

• SG1 – Établir les estimations.• SG2 – Développer un plan de projet.• SG3 – Obtenir l’engagement sur le plan.

Peut-on imaginer avoir des lacunes sérieuses vis-à-vis l’un ou l’autre de ces objectifset néanmoins espérer satisfaire l’intention du domaine de processus qui est : « Établiret maintenir les plans qui décrivent les activités du projet » ? On voit bien que la naturetout à fait basique des objectifs les rend indissociables de la satisfaction de l’intentiondu domaine de processus. Si on me permet cette image : le « syndicat » des objectifsest complètement solidaire de son domaine de processus.

Précisons aussi que le texte des objectifs (il en est de même pour les pratiques) estdisponible en deux versions : la version courte et la version complète ou allongée. Laversion courte sert essentiellement aux discussions entre personnes impliquées dansdes évaluations par exemple et qui réfèrent souvent aux pratiques ou aux objectifs. Ilsse parlent donc entre experts et coupent court. Notons que ce texte abrégé est parfoistrompeur car il oublie des éléments importants de la pratique ou de l’objectif. Il fautdonc référer à la version plus longue de l’objectif ou de la pratique comme référentielofficiel. C’est un peu comme dans un texte de loi : il y a les titres courts et le texteofficiel qui est la référence.

Tableau 5.4 — Exemple tiré du CMMIdu texte court et du texte long d’un objectif dans PP.

SG 1 Establish Estimates SG 1 Établir les estimations

Estimates of project planning parametersare established and maintained .

Les estimations des paramètresde planification de projetsont établies et maintenues.

5.2.5 Pratiques

Dans le CMMI, les pratiques représentent les composants de base de chaque domainede processus. Une pratique décrit un comportement attendu, de la part d’une organi-sation ou d’un projet, qu’on peut rattacher à un objectif spécifique, dans le cas d’unepratique spécifique, ou à un objectif générique, dans le cas d’une pratique générique.À l’aide d’un texte assez court de 3 ou 4 lignes tout au plus, une pratique exprime uneaction normalement accomplie dans le cadre d’un processus de développement quirespecterait les enseignements du CMMI.

Attention : le CMMI n’impose pas les pratiques de façon incontournable. Il autorise eneffet le déploiement de façons de faire qui respectent l’intention sans nécessairementrespecter la lettre de la pratique. On parlera, dans de telles situations, d’approchesalternatives acceptables. Par exemple, le texte d’une pratique peut demander « Évaluer


i

i

i

i

i

i

i

i


si les composants de produit devraient être développés, achetés ou réutilisés en s’appuyantsur des critères établis » (pratique SP2.4 du domaine Solution Technique). Dans unprojet donné ou dans une organisation donnée, il pourrait arriver qu’une directiveexclut d’emblée l’achat ou la réutilisation de composants ; dans un tel cas, évidemment,l’esprit de la pratique reste respecté même si une évaluation de ces options n’est paseffectuée puisque exclue par directive.

Dans chaque domaine du CMMI, chaque objectif est associé à quelques pratiques,généralement de deux à quatre pratiques ; exceptionnellement, un objectif peut sedécliner en plus de cinq pratiques. C’est le cas notamment, de l’objectif génériqueGG2 qui comporte dix pratiques génériques ; il s’agit du maximum ! Un tel objectifdevient, de ce fait, assez difficile à satisfaire puisqu’aucune faiblesse significative, parmiles dix pratiques, ne doit venir entraver l’atteinte de cet objectif pour pouvoir ledéclarer satisfait.

A-t-on remarqué que le sigle de chaque pratique est composé de celui du domainesuivi d’un tiret, puis du sigle GP pour Generic Practice ou SP pour Specific Practice.Après le sigle « SP » ou « GP » on trouve le numéro de l’objectif auquel est associéela pratique, un point, puis un numéro unique pour chaque pratique à l’intérieur del’objectif. Cette convention est assez simple et permet de repérer immédiatementl’objectif auquel est associée une pratique.

Poussons un peu plus loin notre découverte des composants du CMMI. Nous avonsmaintenant compris, la notion de niveau de maturité ou d’aptitude, de domaine,d’objectif et de pratique. Nous sommes maintenant prêts pour découvrir plus à fondles détails du concept de pratique. Poussons donc la porte de la pratique et découvronsce qui s’y cache.

5.2.6 Exemples de produits d’activité typiques

Immédiatement sous le libellé officiel de la pratique, les auteurs expliquent en textelibre la signification de la pratique. Il s’agit de précieuses informations pour interprétercorrectement une pratique. Mais la perle du CMMI se situe juste après ce texteexplicatif : les exemples de produits d’activité !

Les auteurs du CMMI ont fait preuve d’un grand sens pratique en listant souschaque pratique quelques exemples de produits (ou livrables) que l’on s’attend detrouver dans un projet, une activité ou une organisation qui applique la pratique.Ceci va aider grandement un projet, une activité ou une organisation à comprendreconcrètement ce que l’on attend de lui ou d’elle.

Si on prétend par exemple avoir maîtrisé et utilisé la pratique qui vise à « Établiret maintenir les procédures et critères pour l’intégration des composants du produit » (PI-SP1.3), on devrait normalement pouvoir montrer les produits d’activité suivants :

1. Des procédures pour l’intégration du produit.

2. Des critères pour l’intégration du produit.

Ce sont là les deux exemples de produits d’activité de la pratique PI-SP1.3.Chacun d’eux peut servir de révélateur du degré de déploiement de la pratique en


i

i

i

i

i

i

i

i


question. Plus la pratique est institutionnalisée, plus ces deux produits d’activité serontsystématiquement disponibles dans les projets. Ils constituent en quelque sorte despreuves de l’accomplissement de la pratique.

Important : il faut toujours se rappeler, comme leur nom le précise, que ce ne sontque des EXEMPLES de produits d’activité et ne pas se limiter à ceuxci. Chaqueorganisation, projet ou activité pourrait démontrer l’accomplissement de la pratiquepar d’autres produits d’activités tout aussi pertinents. Sur la base de mes expériencesterrain, je dirais qu’en général ceux qui sont précisés dans le CMMI représentent debons exemples types.

Les organisations qui veulent déployer le CMMI trouveront bien commode deconnaître ainsi de façon concrète les documents que l’on s’attend de trouver. Lesévaluateurs de la maturité des processus peuvent ainsi demander à l’avance auxorganisations à évaluer de collecter ces produits d’activité typiques comme preuves dubon déploiement des pratiques. À l’arrivée sur site, les évaluateurs peuvent alorsvérifier si les éléments collectés répondent bien aux produits d’activité typiquesattendus. Ceci rend le processus d’évaluation très discipliné et beaucoup plus efficace.

Tableau 5.5 — Exemple tiré du CMMI du texte donnant la significationd’une pratique suivie des produits d’activité typiques dans PI

(Typical Work Products).

SP 1.3 Establish Product IntegrationProcedures and Criteria

SP 1.3 Établir les procédureset critères d’intégration de produit

Establish and maintain proceduresand criteria for integrationof the product components.

Établir et maintenir les procédureset critères pour l’intégrationdes composants de produit.

(...) (...)

Example Work Products Exemples de produits d’activité

1. Product integration procedures.2. Product integration criteria.

1. Procédure d’intégration de produit.2. Critères d’intégration de produit.

Notons que dans la constellation ACQ, on trouvera non seulement des exemplesde produits d’activité pour l’organisation mais aussi des exemples de livrables dufournisseur (« example supplier deliverable » en anglais). Le CMMI-ACQ veut ainsi faireressortir que dans l’interaction entre organisation et fournisseur, des produits doiventnormalement être demandés au fournisseur si on applique les bonnes pratiques.

5.2.7 Souspratiques

La plupart des pratiques du CMMI se décomposent à leur tour en sous-pratiques.Celles-ci permettent d’élaborer sur les différents aspects d’une pratique et servent àinterpréter la pratique plus finement et de façon cohérente. Dans le cadre de certainesévaluations que j’ai pilotées, certains de mes membres d’équipe avaient tendance à


i

i

i

i

i

i

i

i


prendre les sous-pratiques comme une espèce de liste de contrôle (check-list) servant àvérifier point par point si une pratique était satisfaite ou non. Il m’a fallu maintes foisexpliquer que ce n’est pas ce que visaient les auteurs du CMMI avec les sous-pratiques :un quasi-automatisme pour juger du déploiement d’une pratique. Il est vrai que ceserait parfois bien pratique d’avoir une telle liste qui éviterait de porter des jugements.

Mais ce serait faire bien peu de cas de la nécessité d’appliquer avec intelligence leCMMI en tenant compte des variables de chaque environnement : objectifs straté-giques, nombre d’employés, nature des produits ou services, culture organisationnelle,etc. Les sous-pratiques doivent être lues comme des moyens de mieux comprendreune pratique, surtout lorsque celle-ci est très « englobante » ou vague. Par exemple, lapratique SP2.1 de Gestion des accords avec les fournisseurs (SAM) demande de Réaliseravec le fournisseur les activités telles qu’elles sont spécifiées dans l’accord avec le fournisseur.Ma foi, cela tombe sous le sens tellement c’est trivial. Lorsqu’on prend la peine de lireles sous-pratiques, on découvre qu’on suggère une surveillance de la performance dufournisseur, des rencontres techniques périodiques, des rencontres de management,etc. Ces sous-pratiques apportent un éclairage plus net sur le texte plutôt vague de lapratique. Deux équipes d’évaluation différentes risquent peu d’interpréter la pratiquetrès différemment. En l’absence de sous-pratiques, dans l’exemple choisi, le risque degrandes variations dans l’interprétation serait considérable.

Tableau 5.6 — Exemple tiré du CMMIde souspratiques (Subpractices) dans SAM.

SP 2.1 Execute the Supplier Agreement SP 2.1 Exécuter l’accord avec le fournisseur

Perform activities with the supplier asspecified in the supplier agreement.

Réaliser les activités avec le fournisseurtelles qu’elles sont spécifiées dans l’accordavec le fournisseur.

(...)Subpractices :1. Monitor supplier progress and performance(e.g. schedule, effort, cost, technical performance)as defined in the supplier agreement.(...)4. Conduct reviews with the supplier as specifiedin the supplier agreement.

(...)Souspratiques :1. Surveiller l’avancement et la performancedu fournisseur (par exemple : calendrier, charge,coût, performance technique) tels qu’ils sontdéfinis dans l’accord fournisseur.(...)4. Conduire des revues avec le fournisseur selonles spécifications de l’accord.

5.2.8 Élaboration

Le composant élaboration est utilisé dans la section portant sur les objectifs etpratiques spécifiques.. On le retrouve comme explication des pratiques génériquesappliquées à un domaine en particulier. L’élaboration décrit la particularité de lapratique générique appliquée au domaine en question. Le lecteur familier avec lesapproches orientées objet retrouvera dans l’élaboration le concept d’instanciation.Par exemple, la pratique GP2.3 exige de Fournir les ressources adéquates pour mettre en


i

i

i

i

i

i

i

i


œuvre le processus, développer les produits d’activité et fournir les services couverts par leprocessus. Lorsque cette pratique est associée au domaine de Planification de projet, letexte d’élaboration suggère qu’on aura besoin d’outils d’estimation. Lorsque la mêmepratique est associée au domaine de Validation, le texte d’élaboration suggère qu’onpourrait avoir besoin d’outils de génération de jeux d’essais. Par le biais de l’élaboration,on donne une couleur locale en quelque sorte à la pratique générique.

Tableau 5.7 — Exemple tiré du CMMId’une élaboration (Elaboration) en PP (Planification de Projet.)

GP 2.3 Provide Resources GP 2.3 Fournir les ressources

Provide adequate resourcesfor performing the project planningprocess, developing the work products,and providing the servicesof the process.

Fournir les ressources adéquatespour mettre en œuvre le processusde planification de projet, déveloperles produits d’activité et fournirles services couverts par le processus.

PP Elaboration :Special expertise, equipment, and facilities inproject planning may be required.Special expertise in project planning mayinclude the following :• Experienced estimators• Schedulers• Technical experts in applicable areas(e.g., product domain and technology)

Élaboration pour PP :Pour planifier le projet, une expertise,des installations ou des équipements spéciauxpeuvent être nécessaires.Voici des exemples de compétences spéciales :• estimateurs expérimentés ;• ordonnanceurs ;• experts techniques dans les domainesapplicables (comme le domaine du produit et latechnologie).

Examples of resources provided include thefollowing :• Spreadsheet programs.• Estimating models.• Project planning and scheduling packages.

Exemples de ressources fournies :• tableurs ;• modèles d’estimation ;• outils de planification de projetet d’ordonnancement.

5.2.9 Divers

Le CMMI enrichit le texte de plusieurs exemples, notes explicatives et références.Il importe ici de souligner qu’avec l’avénement de la version 1.3 plusieurs notesexplicatives ont été ajoutées dans la constellation DEV sur les approches ditesAgiles. Le SEI a ainsi réagi à une vague d’incompréhension qui a déferlé vers lesannées 2007 et suivantes. Certains intégristes des approches dites Agiles ont pensélimiter l’application du CMMI dans leurs organisations en qualifiant le CMMId’incompatible avec les approches Agiles. Il a fallu du temps et plusieurs publicationsd’experts reconnus pour dénouer ce nœud d’incompréhension malheureux et faire ladémonstration que les approches Agiles constituent UNE des façons (le comment)d’implémenter quelques pratiques du CMMI (qui ne décrit que le quoi et non lecomment). Pour bien fixer cette idée de compatibilité entre CMMI et Agile, les auteurs


i

i

i

i

i

i

i

i


ont profité de la version 1.3 pour ajouter aux endroits appropriés des explicationspertinentes.

Tableau 5.8 — Exemple tiré du CMMId’une explication sur Agile dans PPSP1.5.

In Agile environments, the sustainedinvolvement of customer and potential endusers in the project’s product developmentactivities can be crucial to project success ; thus,customer and enduser involvement in projectactivities should be monitored.

Dans les environnements Agiles, l’implicationsoutenue du client et des utilisateurs finauxprobables dans les activités de développementpeut être cruciale au succès du projet ; parconséquent, l’implication du client et desutilisateurs finaux dans les activités du projet doitêtre surveillée.

Avezvous bien LU ?

(Les réponses se trouvent dans le texte.)

a) Nommez et expliquez les disciplines couvertes par le CMMIDEV.

b) Comparez la nomenclature des niveaux de maturité et des niveaux d’aptitude ;indiquez quelles sont les similitudes et quelles sont les différences.

c) Combien le CMMI comptetil de domaines de processus pour ses différentesconstellations?

d) Pourquoi ne trouveton pas dans le CMMIDEV de domaine deprocessus qui traiterait du soutien à l’utilisateur final lorsqu’un applicatif est production ?

e) Que veulent dire les sigles suivants ?1) PPQASP2.1 ;2) PPGP2.6 ;3) SAMGG3 ;4) MAGP2.3.

f) Si vous cherchiez des exemples de preuves de déploiement d’une pratiquespécifique donnée, quelle partie précise dans le livre du CMMI pourrait vous aider ?

g) Qu’estce qui permet de trouver des particularités propres à un domaine deprocessus donné pour chaque pratique générique?

www.dunod.com

InfoPro

CMM

I 1.3

r. B

asq

ue

MAN

AGEM

ENT

des

SYST

ÈMES

D’IN

FOR

MAT

ION

ManageMent des systèMes d’inforMation

applications Métiers

études, développeMent, intégration

exploitation et adMinistration

réseaux & télécoMs

CMMI 1.3

Guide complet de CMMI-DEVet traduction de toutes les pratiques

CMMI-ACQ et CMMI-SVC

type d’ouvrage

l’essentiel se forMer retoursd’expérience

RichaRd Basque

est instructeur cMMi et évaluateur scaMPi certifié par le sei. il est aussi le fondateur d’alcyonix, société de services spécialisée en amélioration de processus, aujourd’hui intégrée dans le groupe sqLi, qui utilise le cMMi en interne depuis plusieurs années dans son réseau d’agences.

Le forum de discussion cmmi-en-francais (sur Yahoo!) fondé par l’auteur prolonge ce livre par des discussions enrichissantes entre les membres.Retrouvez également sur www.dunod.com les suppléments gratuits de l’ouvrage.

Cet ouvrage s’adresse aux managers et aux praticiens du domaine de l’ingénierie des systèmes ou du logiciel (directeurs, responsables de la qualité, chefs de projet).Le cMMi, dont la version 1.3 a été publiée à l’automne 2010, est de plus en plus largement utilisé pour évaluer la maturité de processus, pour développer des plans d’amélioration ou pour mettre en œuvre des pratiques plus matures.ce livre est un guide commenté du pourquoi et du comment de ce modèle de bonnes pratiques. il a surtout pour vocation d’aider concrètement les organisations qui veulent réussir leurs projets, dans les délais, dans les budgets et à la satisfaction de leurs clients.Élaboré par un spécialiste du domaine, il vous apportera des conseils utiles à chaque étape du parcours.

CMMI 1.3 Guide complet de CMMI-DeV et traduction de toutes les pratiques CMMI-aCq et CMMI-sVC

Richard Basque

« Si vous envisagez de tirer le meilleur profit du modèle CMMI et que vous vous interrogez sur la meilleure façon de le déployer dans votre organisation, ce livre vous est destiné. »

Mike Konrad (The software engineering institute)

« Avec cette nouvelle édition, Richard contribue encore une fois à cette vision de l’amélioration continue que nous souhaitons partager avec la CMMI Product Suite. »

Mike Phillips (The software engineering institute)

6917009ISBN 978-2-10-055831-5

Richard Basque

Préfaces de Mike Konrad, Mike Phillips

InfoPro l’essentiel se forMer type d’ouvrage …...CMMI 1.3 Guide complet de CMMI-DEV et...

Documents

Transcript of InfoPro l’essentiel se forMer type d’ouvrage …...CMMI 1.3 Guide complet de CMMI-DEV et...