Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
Conservatoire National des Arts et Métiers Oral probatoire
-- Analyse des risques pour les sociétés de services :
Dans quelle mesure ces sociétés ont intérêt à adopter les normes
Auditeur : M. Bras Cyril Tuteur : Mme. Laurent Anne
Responsable CNAM : Pr. Nanard Marc
Remerciements
Je tiens à remercier ici, mesdames Anne Laurent et Maguelonne Teisseire pour les
précisions sur le sujet qu’elles ont bien voulu me donner, les membres du jury pour l’attention
qu’ils voudront bien accorder à mon étude et le Conservatoire National des Arts et Métiers
pour les formations proposées. Enfin, Monsieur Hartz, directeur de projets de la société SQLI
pour les informations qu’il m’a donné.
- 1 -
Sommaire : I. INTRODUCTION :..................................................................................................................................... 2
II. LES RISQUES ............................................................................................................................................. 3 II.1. DEFINITION :......................................................................................................................................... 3 II.2. NATURE :.............................................................................................................................................. 3 II.3. IDENTIFICATION DES RISQUES............................................................................................................... 4 II.4. ANALYSE DES RISQUES ......................................................................................................................... 5
III. LES NORMES............................................................................................................................................. 7 III.1. DEFINITION :......................................................................................................................................... 7 III.2. ELABORATIONS..................................................................................................................................... 7
IV. LES MODELES........................................................................................................................................... 9 IV.1. LE MODELE CMM ................................................................................................................................ 9
IV.1.1. Généralités ................................................................................................................................. 9 IV.1.2. Les niveaux de maturités ............................................................................................................ 9 IV.1.3. Les secteurs clés ....................................................................................................................... 11 IV.1.4. Spécialisations.......................................................................................................................... 12 IV.1.5. Etat des lieux ............................................................................................................................ 12 IV.1.6. Vers une normalisation ISO ..................................................................................................... 13
IV.2. LE MODELE CMMI ............................................................................................................................. 15 IV.2.1. Généralités du modèle.............................................................................................................. 15 IV.2.2. Les niveaux de maturités .......................................................................................................... 15 IV.2.3. Mise en place en entreprise ...................................................................................................... 16 IV.2.4. Avantages ................................................................................................................................. 17 IV.2.5. La gestion des risques dans le modèle CMMI .......................................................................... 17
IV.3. D’AUTRES MODELES ........................................................................................................................... 18 IV.3.1. CBA-IPI .................................................................................................................................... 18 IV.3.2. SCAMPI.................................................................................................................................... 18 IV.3.3. SCE........................................................................................................................................... 19 IV.3.4. RUP .......................................................................................................................................... 19
IV.4. LE CHOIX DU MODELE......................................................................................................................... 20 IV.5. AMELIORATION LIEE A L’UTILISATION DE MODELES........................................................................... 22 IV.6. L’EXPERIENCE DE LA SOCIETE SQLI................................................................................................... 25
IV.6.1. Les difficultés............................................................................................................................ 25 IV.6.2. Avantages pour la gestion des risques...................................................................................... 26 IV.6.3. Choix du modèle CMMI ........................................................................................................... 26
V. RECOMMANDATIONS .......................................................................................................................... 27
VI. CONCLUSION .......................................................................................................................................... 29
VII. BIBLIOGRAPHIE .................................................................................................................................... 30
- 2 -
I. Introduction :
Dans le cadre des études du Conservatoire National des Arts et Métiers préparant au
diplôme d’ingénieur en informatique, il m’a été demandé de réaliser une étude sur l’« analyse
des risques pour les sociétés de services : dans quelle mesure ces sociétés ont intérêt à adopter
les normes ».
La maîtrise des risques est une préoccupation majeure en conduite de projet
informatique. En effet, la pérennité d’une entreprise en dépend très fortement. Une
programmation non rigoureuse ou encore un personnel mal impliqué peut entraîner un échec
du projet.
La normalisation est quelque chose qui fait partie de notre quotidien, en effet la plupart
des produits, des services que nous utilisons sont normalisés. C’est l’assurance pour chacun
de nous d’utiliser un produit, un service conforme. Mais qu’en est il dans le domaine de
l’informatique et plus précisément des sociétés de services informatiques. C’est ce que nous
allons expliquer dans la suite de ce document. Mais avant toute chose il est nécessaire
d’expliquer quelques généralités sur la gestion des risques ou encore les normes.
C’est pourquoi ce document est organisé en quatre parties avec en premier lieu, une
présentation de ce qu’est l’analyse des risques, en second lieu une définition des normes, puis
une introduction aux modèles existant pouvant s’appliquer aux sociétés de services Enfin, une
analyse de tout ce qui aura été évoqué et une tentative de réponse à la question posée par le
sujet.
- 3 -
II. Les risques
La prévention et la gestion des risques sont des préoccupations incontournables pour
la conduite de projets informatiques, cependant avant de rentrer plus profondément dans
l’étude du sujet, il convient de déterminer la notion de risque et tout ce qui s’y rapporte
(nature, probabilité, analyse…).
II.1. Définition :
La définition qui en est donnée dans le dictionnaire [1] est la suivante :
« Risque : Danger dont on peut jusqu’à un certain point mesurer l’éventualité, que l’on peut
plus ou moins prévoir ».
Les risques en conduite de projet informatique sont définis comme la possibilité qu’un
projet ne s’exécute pas conformément aux prévisions de dates, de coût ou d’expression des
besoins, ces dérives étant considérées comme difficilement acceptables, voire inacceptables.
On peut dire que le risque fait partie de notre quotidien et qu’il apparaît dans tous les aspects
de notre vie. En général, on ne voit que les aspects négatifs des conséquences des risques ;
cependant, les risques représentent toute l’incertitude qui peut exister dans un projet, le positif
comme le négatif.
II.2. Nature :
La nature des risques peut être différente suivant le domaine auquel on s’intéresse.
Dans l’étude présente, on se limitera aux risques qui peuvent s’appliquer aux projets
informatiques et donc affecter les sociétés de services. Une liste non exhaustive des risques
auxquels une société de services informatiques peut être confrontée pourrait contenir les
éléments suivants :
- Mauvaise interprétation du cahier des charges
- Pas de suivi tout au long du projet
- Pas de normalisation dans les développements
- Estimations erronées
- Problème de personnel
- Pas d’anticipation des risques
- 4 -
Afin de mieux les identifier où d’identifier les acteurs (humains ou matériels) qui
peuvent remédier à ces risques, il est possible d’établir une classification typologie.
Par exemple :
- Projet
- Contractuel
- Fonctionnel
- Technique
- Organisationnel
Cependant pour arriver à classifier les risques, il faut en premier lieu avoir réalisé leur
analyse. Cette étape est incontournable si l’on souhaite remédier au mieux aux conséquences
de risques non détectés.
II.3. Identification des risques
Avant de pouvoir procéder à l’analyse des risques, il convient d’identifier de façon la
plus approfondie possible les causes de risques, quels événements pourraient être à leurs
sources et pourraient induire le non respect des objectifs. L’identification initiale est fonction
des objectifs, des exigences et du contexte du projet. La liste des facteurs de risques est
réalisée par l’ensemble de l’équipe du projet envisagé. Le facteur de risque étant la
combinaison de la probabilité d’apparition d’un dysfonctionnement et de l’impact de ce
dysfonctionnement sur les utilisateurs et l’environnement. Pour cela, il est possible par
exemple de faire usage d’un questionnaire tel que le Taxonomy Based Risk Identification
Questionnaire [2] définit par SEI (Software Engineering Institute), qui se compose de trois
parties principales : la conception du produit, l’environnement de développement et les
contraintes de programmation ; chacune de ces parties étant subdivisée pour approcher au
mieux l’aspect particulier des risques ou bien en se basant sur l’expérience des projets
antérieurs. Une fois cette liste réalisée, il faut s’assurer que d’autres risques ne peuvent pas
découler de l’accumulation des risques précédents. Le document [13] reprend dans le détail
les processus d’identification et d’analyse des risques.
- 5 -
II.4. Analyse des risques
L’analyse des risques consiste alors à regrouper les risques suivant les critères
évoqués dans le paragraphe II.1 et d’estimer leur probabilité d’apparition. Pour être plus
précis, il est possible de découper cette analyse en trois étapes : probabilité, impact et niveau
de risque du projet. On détermine la probabilité d’apparition de chaque risque particulier, on
la désigne par un niveau de risque (faible, moyen, fort, très fort). Ensuite on s’intéresse à
l’impact que peut avoir un risque en particulier sur le projet considéré. Il est possible d’établir
des niveaux qualitatifs d’impact (négligeable, marginal, critique, catastrophique). L’impact du
risque peut atteindre de nombreux aspects du projet. Afin d’être plus précis encore dans les
parties du projet qui peuvent être impactées, certaines méthodes comme celles utilisées par
l’armée de l’air américaine dans le développement de projet [3], préconise de spécialiser
l’impact en quatre catégories qui sont le coût, la performance, la planification et le support.
Enfin la dernière étape consiste à déterminer le risque global du projet. Il faut pour cela
utiliser les probabilités et les impacts défini précédemment ou plus précisément leurs
estimations. En définissant le risque global, il est alors possible de voir quelles conséquences
il peut avoir sur les autres risques du projet. On peut faire usage d’un tableau croisé pour
déterminer le risque global pour chacune des catégories exposées ci-dessus.
Impact/probabilité Très forte Forte Moyenne Faible Très faible
Catastrophique Fort Fort Modéré Modéré Faible
Critique Fort Fort Modéré Faible Aucun
Marginal Modéré Modéré Faible Aucun Aucun
Négligeable Modéré Faible Faible Aucun Aucun
Tableau Impact / Probabilité
On peut aussi déterminer un poids pour chaque risque qui est le produit de la
probabilité d’apparition (0=faible, 1=moyenne, 2=forte, 3=très forte) du risque par de son
niveau d’impact (0=mineur, 1=moyen, 2=important, 3=majeur). Il existe plusieurs types
d’analyse : lorsque l’impact est évalué en valeur monétaire il s’agit d’analyse quantitative,
sinon il s’agit d’analyse qualitative.
- 6 -
Tout ceci ne représente qu’un aspect théorique de l’analyse des risques ; il existe des
technologies communément utilisées pour cela. Ci-après une liste non limitative de méthodes
utilisables :
- Analyse préliminaire de risque
- Analyse de risque et d’opérabilité
- Analyse par arbre de causes
- Analyse des modes de défaillances, de leurs effets et de leur criticité
- ….
- 7 -
III. Les normes
Dans la majorité des domaines, l’inexistence de normes harmonisées pour des
technologies semblables, dans des pays ou des régions différentes, contribue à la création
d’obstacles techniques au commerce. C’est pourquoi leur création s’est trouvée être un atout
pour les entreprises qui décident d’en faire usage. Cela permet aux entreprises de faire
reconnaître leur savoir faire auprès de leurs clients, de leurs fournisseurs.
III.1. Définition :
La définition qui en est donnée par le dictionnaire [4] est la suivante : « Norme : Règle
fixant les conditions de réalisation d’une opération, de l’exécution d’un objet ou de
l’élaboration d’un produit dont on veut unifier l’emploi ou assurer l’interchangeabilité. Une
norme ISO Norme de productivité : productivité moyenne d’une branche économique. ».
Au delà de la vision abstraite que peut donner le dictionnaire des normes, il s’agit en
fait d’accords documentés contenant les spécifications techniques ou d’autres critères précis
destinés à être utilisés systématiquement en tant que règles, lignes directrices ou définitions de
caractéristiques pour assurer que des processus, produits, services et matériaux sont aptes à
leur emploi.
III.2. Elaborations
Les normes ne sont pas inventées spontanément, leurs apparitions dépend de la
volonté des entreprises de vouloir optimiser et maîtriser leur façon de travailler, leurs
produits, des processus … et d’augmenter la satisfaction du client (par client on entend
ordonnateur, usager …). Pour être fonctionnelles, les normes doivent être en adéquation avec
les attentes et les évolutions des entreprises. Des instances spécialisées d’ordre nationale ou
internationale s’occupent de la proposition et/ou de la validation des normes. Le plus
important organisme de normalisation est l’ISO, créé le 23 février 1947, (International
Organization for Standardization) qui est à la source de nombreuses normes internationales
dans tous les domaines. Il définit 2 grands types de normes : des normes techniques et des
normes de gestion mais également des procédures de certification. La gestion de la qualité et
la certification étant des domaines très vastes, ils ne sont ici donnés qu’à titre illustratif et ne
- 8 -
feront pas l’objet d’une étude approfondie ; étude qui de toute façon serait hors propos ici. Il
regroupe 130 organismes nationaux de normalisation comme par exemple l’AFNOR
(Association Française de NORmalisation) qui établit les normes ISO au niveau national
français. Les normes peuvent aussi être le fruit de travaux développés par des organismes dont
la mission première n’est pas la création de normes, comme par exemple le SEI (Software
Engineering Institute) qui est à l’origine du CMM (Capability Maturity Model ) et du CMMI
(Capability Maturity Model Integrated) ; deux modèles sur lesquels nous reviendrons plus
tard dans cette étude.
- 9 -
IV. Les modèles
IV.1. Le modèle CMM
IV.1.1. Généralités
Le CMM (Modèle d’évaluation des capacités, Capability Maturity Model) est un
modèle d'évaluation et d'évolution des processus logiciels. Il a été élaboré en 1987 par Watts
Humphrey, du SEI (Software Engineering Institute) de l'université Carnegie Mellon de
Pittsburgh (Pennsylvanie, USA) et traduit en français par le CRIM (Centre de Recherche
Informatique de Montréal, Canada). Il fait suite à la volonté du gouvernement américain, plus
précisément du département de la défense qui souhaitait fiabiliser les développements
informatiques dans les domaines de la défense, de l’aéronautique et des télécommunications
et qui va financer le développement de ce modèle.
Ce modèle inventorie des techniques de gestion, de planification et d’ingénierie, qui
permettent d’améliorer l’organisation de façon à atteindre des objectifs de coût, de délai, de
qualité et de fonctionnalité. Pour espérer les atteindre, il faut valider cinq étapes ou niveaux de
maturité, de qualité. Cela permet aussi à l’entreprise d’évaluer son degré d’avancement dans
l’application du modèle au développement d’un projet.
Chacun des cinq niveaux (sauf le premier) comporte plusieurs secteurs clés, 18 au
total faisant référence à des caractéristiques communes. Ces caractéristiques devront être
remplies pour satisfaire aux exigences d’un secteur clé. Nous en donnerons par la suite
quelques exemples.
IV.1.2. Les niveaux de maturités
Comme nous venons de le voir le modèle CMM est organisé suivant cinq niveaux, qui
ont pour but d’identifier l’état dans lequel se trouve l’organisation et les améliorations
nécessaires pour un passage au niveau supérieur dont voici le détail :
- 10 -
- Niveau 1 « Initial » : L’organisation ne dispose pas de procédures
formalisées d’évaluation, de développement et d’évolution de ses
applications. L’organisation du personnel ne permet pas la réutilisation de
l’expérience acquise sur le projet. Le suivi du projet est chaotique et en cas
d’échec se matérialise par l’abandon du peu de méthode mise en place pour
palier au plus vite aux difficultés. Le succès du projet ne repose que sur la
volonté individuelle.
Pas de secteur clé.
- Niveau 2 « Reproductible » : Mise en place de rudiments de gestion de
projet afin d’assurer le suivi des coûts, de la planification et des
fonctionnalités. On utilise l’expérience acquise au cours de projets similaires
déjà effectués. L’organisation du personnel ne varie pas tout au long du
projet dans la limite de leur présence au sein de l’organisation.
Exemples de secteurs clés : planification de projet, assurance qualité.
- Niveau 3 « Défini » : Les processus de développement et d’évolution du
logiciel sont documentés, standardisés et intègrent la conception et la gestion
du projet. Chacun des acteurs du projet (utilisateur, développeur) est formé
aux tâches qu’il devra accomplir. Tous les projets s’appuient sur une
organisation standard et validée.
Exemples de secteurs clés : définition des processus, ingénierie des produits
logiciels.
- Niveau 4 « Maîtrisé » : On évalue autant la productivité que la qualité, en
se fixant des objectifs tant qualitatifs que quantitatifs. Le processus de
développement est validé régulièrement à des moments planifiés, jugés
importants de la vie du projet.
Exemples de secteurs clés : gestion quantitative des processus et de la
qualité logicielle.
- Niveau 5 « Optimisé » : On recherche l’amélioration continue des
processus en identifiant et en évaluant leurs faiblesses. L’innovation est
également un point important, on souhaite utiliser les pratiques d’ingénierie
- 11 -
logicielle les plus efficaces dans un but d’amélioration constante de la
qualité.
Exemples de secteurs clés : gestion des changements technologiques et des
changements de processus
Détail d’un niveau du CMM (source [5])
On remarque qu’un niveau du modèle est répartit en secteurs clés qui réalisent un
objectif définit ; qui permet de créer une étape dans le projet. Chaque secteur clé comporte
plusieurs pratiques qui sont en fait les méthodes permettant la réalisation des objectifs. Le
passage d’un niveau à l’autre ne peut se faire sans obtenir la certification du SEI.
IV.1.3. Les secteurs clés
Comme nous l’avons décrit plus haut, les secteurs clés sont rattachés à un niveau et
représentent un indicateur des points sur lesquels l’organisation doit porter son attention afin
d’améliorer son processus de développement d’applications. Ils sont la décomposition de
chacun des niveaux (sauf le premier).
Les secteurs clés du niveau 2 portent sur l’application de règles simples de gestion de
projet.
- 12 -
Pour le niveau 3, il s’adresse aux possibilités de projets et d’organisation où
l’organisation établit la structure qui va régir les processus de gestion et de développement de
tous les projets.
Pour le niveau 4, c’est la compréhension du processus de développement et des outils
nécessaires développés pour l’occasion
Enfin le niveau 5, couvre les solutions que doit apporter l’organisation des projets
pour améliorer de façon significative le développement d’applications.
Chaque clé vise la satisfaction et la réalisation d’un but. Il est possible de retrouver les
18 secteurs clés dans le document [8].
IV.1.4. Spécialisations
Il existe en fait quatre spécialisations du modèle CMM pour les projets industriels et
progiciels qu’il est nécessaire de présenter ici à des fins de compréhension ultérieure :
- SW – CMM Capability Model for Software development
- SA – CMM Software Acquisition Capability Maturity Model
- SE – CMM Systems Engineering Capability Maturity Model
- IPD – CMM Integrated Product Development Capability Maturity Model
IV.1.5. Etat des lieux
SSII Certification Pays d’origine Effectif (personnes) Datamatics CMM niveau 5 Inde 1600
Estarta CMM niveau 3 Jordanie 200 Grameen Software CMM niveau 2 prévus en
2004 Bangladesh 55
Infosys CMM niveau 5 Inde 10000 Luzoft CMM niveau 4, 5 prévus
en 2004 Russie 450
Mustang Technologies CMM niveau 2, objectif niveau 5
Thaïlande 35
Mastek CMM niveau 5 Inde 1000 Satyam CMM niveau 5 Inde 9300
Tat Consultancy Services CMM niveau 5 Inde 20000 Wipro Technologies CMM niveau 5 Inde 14000
L'échelle de certification CMM s'étend du niveau 1 - le plus bas - au niveau 5 - le plus
haut. En 2002, on comptait au niveau mondial moins de quarante SSII (Société de Service
- 13 -
Informatique) certifiées CMM de niveau 5, indiennes pour un bon nombre d'entre elles.
(Source [6])
D’après le magazine 01 informatique (Source [7]), on estime qu’en Amérique du
Nord, de 70 à 75 % des entreprises ne dépassent pas le niveau 1 du modèle CMM. L'Europe
compte entre 35 et 40 % d'entreprises au niveau 1, et environ 30 % aux niveaux 2 ou 3.
Ceci indique que peu de SSII françaises s’intéressent à ce type d’outil, alors que les
pays comme l’Inde en sont de grands utilisateurs. Nous verrons par la suite que l’utilisation de
tels modèles apporte des avantages non négligeables pour une entreprise.
IV.1.6. Vers une normalisation ISO
Un projet dont le but était la création d’un standard international pour l’évaluation du
processus logiciel est apparu en juin 1995 visant à satisfaire trois objectifs :
- Développer une ébauche fonctionnelle pour évaluer le processus logiciel
- Conduire les sociétés à utiliser les standards
- Favoriser le transfert de compétences de cette norme vers les sociétés du
monde entier
Il s’agit du modèle SPICE (Software Process Improvement and Capability
dEtermination) élaboré par cinq centres techniques internationaux dont les SEI. Ce modèle a
permis de donner naissance à la norme internationale ISO/IEC 15504. Le lien avec le modèle
CMM vient du fait que l’élaboration du modèle SPICE s’est fortement appuyée sur le travail
réalisé par le SEI. On peut donc dire que le modèle ISO SPICE est une normalisation
internationale du modèle CMM.
- 14 -
légende :
CUS : Client
ENG : Développement
SUP : Support
MAN : Gestion des ressources humaines
ORG : Organisation
La différence principale qui existe entre les deux modèles tient au fait que ISO SPICE
recherche une évaluation plus fine par processus ; ce qui explique le fait qu’il existe un niveau
de plus par rapport au modèle CMM. Il s’agit en fait de la division du niveau 1 du CMM en
deux niveaux distinguant un état de maîtrise inexistante des processus et un état de maîtrise
informelle des processus. Le schéma ci-avant reprend l’organisation générale des niveaux du
modèle ISO SPICE (source [9]). On remarque que l’évaluation des niveaux se fait suivant
deux axes, on distingue en effet pour chaque niveau, comment les différentes composantes
(Client, Développement …) de l’entreprise sont concernées par les niveaux.
- 15 -
IV.2. Le modèle CMMI
IV.2.1. Généralités du modèle Il s’agit de la descendance du modèle précédemment exposé. Il s’agit en fait d’une
version étendue du modèle CMM prenant en compte le côté système, suite à une réorientation
des efforts du SEI sur ce dernier point. Le modèle CMMI (Capability Maturity Model
Integration) reprend donc l’amélioration de la gestion, du développement, de la maintenance
des applications mais aussi des équipements et des systèmes, le seul aspect qui n’est pas
encore traité est l’exploitation informatique. Ce qui est renforcé par rapport au modèle CMM,
c’est l’aspect gestion des risques (maîtrise des coûts, des délais, des performances des
applications, des équipements et des systèmes développés). Il tient compte également des
demandes d’évolutions provenant d’industriels ayant utilisé le modèle CMM pendant plus de
huit années. Ce modèle n’entraîne pas d’organisation particulière mais donne des pratiques
pour satisfaire aux exigences du modèle. On souhaite donc améliorer les processus de
fabrication afin de fabriquer des produits de qualité.
IV.2.2. Les niveaux de maturités
Les niveaux de maturités sont au nombre de cinq et assurent les mêmes fonctions que
pour le modèle CMM. Il suffit donc de se reporter au III.3.2. Le schéma ci après reprend
brièvement l’ensemble des niveaux et montre quelles mesures sont nécessaires pour passer
d’un niveau à l’autre. On observe que les risques diminuent plus on s’élève dans les niveaux,
on remarque aussi que les performances augmentent. Ceci s’explique par le fait que
l’organisation normalise sa production et ses actions de production ; réutilisation de morceaux
de codes déjà utilisés sur d’autres projets, même méthode de suivi que sur des projets
similaires ayant connu un succès important. De ce fait, l’organisation va donc générer des
produits de bonne qualité en moins de temps. L’organisation sera donc plus performante.
- 16 -
Les cinq niveaux de maturité du modèle CMMI
IV.2.3. Mise en place en entreprise
La mise en place du modèle CMMI, doit permettre à l’entreprise d’atteindre la
satisfaction d’objectifs stratégiques. Pour cela, il est possible d’utiliser un processus itératif en
cinq étapes avec la coopération d’un prestataire extérieur à l’entreprise qui veillera au respect
des exigences du modèle CMMI.
La première est l’initialisation, elle consiste en l’identification des objectifs
stratégiques que souhaite l’entreprise. Il s’agit également de déterminer le périmètre du projet
et les acteurs qui vont en faire partie. Il s’agit donc d’une première organisation du projet.
La seconde est le diagnostic, il s’agit de l’évaluation du fonctionnement de
l’organisation. Elle est réalisée par le prestataire qui s’introduit dans les équipes et questionne
les participants au projet sous la forme d’un entretien. Il regroupe ensuite les résultats obtenus
avec les documents référentiels de l’organisation afin de les comparer avec les exigences du
modèle CMMI. Les recommandations qui en découlent font ressortir les points forts et faibles
de l’organisation.
La construction constitue la troisième étape. Un plan d’action est mis en place dont le
but est de permettre la mesure de l’état d’avancement du projet et de trouver les solutions
pour remplir les exigences du modèle CMMI. Les procédures où l’écart est grand sont traitées
en premier.
L’étape suivante consiste en la mise en œuvre des solutions trouvées. Un projet pilote
est sélectionné et on observe si les indicateurs choisis dans l’étape précédente sont adaptés.
- 17 -
On se prépare au basculement de toute l’organisation en formant les opérationnels aux
nouvelles pratiques.
Enfin la capitalisation constitue la dernière étape. Elle consiste en un constat de
l’application du cycle d’amélioration mis en place depuis la première étape. L’organisation va
essayer d’être plus performante lors des prochains cycles. Le but avéré étant de modifier
progressivement les pratiques de l’entreprise pour satisfaire aux exigences du modèle CMMI.
IV.2.4. Avantages
Au-delà du fait que ce modèle découle du modèle CMM et reprenne toutes les
avancées de ce dernier, le CMMI est structuré en deux représentations :
- Par étape (« staged ») comme le proposait au départ le modèle SW-CMM.
- Continu (« continuous ») pour respecter les spécifications de la norme ISO
15504
L’objectif à terme du SEI est de faire en sorte que le modèle CMMI soit conforme à la
norme ISO/IEC 15504. De plus, le SEI encourage l’utilisation du CMMI par rapport au
CMM, et soutient la migration du SW-CMM vers le CMMI jusqu’à la fin 2005.
Un autre avantage réside dans le fait que cette méthode prend en compte la gestion des
risques pour un projet informatique.
IV.2.5. La gestion des risques dans le modèle CMMI
Comme nous l’avons abordé au début de ce document, la gestion des risques permet
d’identifier les problèmes avant qu’ils n’apparaissent et de planifier l’apparition de nouveaux
risques liés à l’activité qui pourraient retarder la mise en service du produit.
L’approche du modèle CMMI pour la gestion des risques s’articule en deux parties
avec d’une part la mise en place d’objectifs spécifiques et d’autre part d’objectifs génériques.
Les objectifs spécifiques sont la planification de la gestion des risques, l’analyse des
risques afin de déterminer leur importance par rapport au projet et enfin la réduction des
risques pour réduire l’impact que cela pourrait avoir sur le projet.
Les objectifs génériques visent quant à eux la réussite des objectifs spécifiques, la
définition et la gestion générale du processus, son optimisation et son approche qualitative.
- 18 -
Le détail de chacune des opérations peut être retrouvé dans le document du SEI
concernant le CMMI (source [12], page 288).
IV.3. D’autres modèles
Il existe bien sûr d’autres modèles que ceux que nous venons d’aborder. Mais la
plupart d’entre eux découlent des modèles SW-CMM et/ou CMMI.
IV.3.1. CBA-IPI
CBA IPI ("CMM©-Based Appraisal for Internal Process Improvement" en
anglais) est une méthode qui utilise le SW-CMM comme référentiel pour identifier les
forces et faiblesses du processus logiciel d'une entreprise ou d'un organisme. Cette
méthode s'appuie sur une discipline et des règles rigoureuses qui assurent l'exhaustivité
et l'objectivité de l'évaluation. Elle se caractérise par la large place faite au consensus
(c'est une équipe qui accomplit l'évaluation) et à l'implication de l'entité évaluée dans sa
propre évaluation. Le SEI a développé cette méthode et gère un programme
d'accréditation de chefs évaluateurs. Par extension, on désigne souvent par "un CBA
IPI" une évaluation du processus logiciel réalisée à l'aide de la méthode CBA IPI.
Plusieurs centaines de CBA IPI ont été réalisés à travers le monde depuis la publication
de la méthode CBA IPI sur lesquelles le SEI diffuse périodiquement des statistiques.
IV.3.2. SCAMPI
SCAMPI ("Standard CMMI Appraisal Method for Process Improvement" en
anglais) est une méthode qui utilise le CMMI comme référentiel pour identifier les
forces et faiblesses du processus logiciel et/ou système d'une entreprise ou d'un
organisme. Cette méthode utilise une structure rigoureuse et stricte qui assure ainsi une
évaluation menée jusqu’à son terme et traitant tous les aspects possibles. Elle se
distingue par l'implication de l'entité évaluée dans sa propre évaluation. Le SEI a
développé cette méthode et gère un programme d'accréditation de chefs évaluateurs. Par
extension, on désigne souvent par "un SCAMPI" une évaluation de processus réalisée à
- 19 -
l'aide de la méthode SCAMPI. Plusieurs SCAMPI ont également été réalisés à travers le
monde depuis la publication de la méthode SCAMPI.
IV.3.3. SCE
SCE ("Software Capability Evaluation" en anglais) est une méthode qui utilise le
SW-CMM comme référentiel pour identifier les forces et faiblesses du processus
logiciel d'une entreprise ou d'un organisme. Cette méthode s'appuie sur une discipline et
des règles rigoureuses qui assurent l'exhaustivité et l'objectivité de l'évaluation. En ce
sens, elle ressemble beaucoup au CBA IPI. Toutefois, si le CBA IPI fait une large place
à l'implication de l'entité évaluée dans sa propre évaluation, le SCE se veut une
approche qui implique exclusivement (sauf exceptions) une équipe externe au site
audité.
En général, une organisation qui veut améliorer son propre processus logiciel
utilisera un CBA IPI ou SCAMPI pour poser le diagnostic sur sa capacité courante. Par
ailleurs, si elle désire traiter avec un fournisseur et qu'elle désire vérifier, par un audit, la
capacité du processus logiciel de celui-ci, alors le SCE sera en général préféré, surtout si
cela se fait dans un contexte de sélection d'un fournisseur parmi plusieurs pour un
contrat critique. Les SCE et CBA IPI méthodes se ressemblent. Elles utilisent le même
référentiel de pratiques cibles (le SW-CMM) mais diffèrent dans leur vocation et dans
certaines modalités.
Le SEI a développé la méthode SCE et gère un programme d'accréditation de
chefs auditeurs, sur un mode assez semblable au programme d'accréditation CBA IPI.
Par extension, on désigne souvent par "un SCE" un audit du processus logiciel réalisé à
l'aide de la méthode SCE. Plusieurs centaines de SCE ont été réalisés à travers le monde
depuis la publication de la méthode SCE sur lesquelles le SEI diffuse périodiquement
des statistiques.
IV.3.4. RUP
Rational Unified Process (RUP) est une méthode de développement logiciel qui vise à
mettre en oeuvre de bonnes pratiques telles que :
- 20 -
- Un développement itératif du logiciel : montrer fréquemment au futur
utilisateur, ou au marketing, des versions intermédiaires du logiciel en
construction, ceci afin de mieux maîtriser les risques inhérents au
développement en les levant au plus tôt.
- Gérer les exigences : distinguer et organiser les exigences de l’utilisateur, ou
du marketing, et assurer leur suivi jusque dans le code, ceci afin d’être
capable de démontrer la complète prise en compte des besoins exprimés. Une
architecture logicielle par assemblage de composants : Privilégier une
construction du logiciel par assemblage de composants (sur étagère ou
développés par le projet), pour développer plus vite et tester plus finement.
- Adopter une modélisation graphique des exigences : utiliser les diagrammes
UML par exemple, afin de communiquer mieux et plus rigoureusement entre
développeurs et utilisateurs.
- Vérifier la qualité en continu : faire des démonstrations et des recettes
fréquentes de versions intermédiaires du logiciel en construction, ceci afin
d’habituer l’utilisateur au logiciel à venir et d’assurer progressivement la
bonne prise en compte des besoins.
- Gérer les demandes de changement : enregistrer chaque demande de
changement du projet et des caractéristiques du logiciel afin de maîtriser les
changements tout en les acceptant.
IV.4. Le choix du modèle
Le choix va dépendre du type d’organisation dans la quelle on se trouve et des besoins
qui s’y rattachent En effet, chacun des modèles a des spécificités propres, qui vont
correspondre à tel ou tel besoin d’une société pour le développement d’un projet à leurs tailles
(grand, petit), niveau de complexité ou leur niveau de risque. Certains artisanaux nécessitent
savoir-faire et polyvalence, d'autres industriels nécessitent expertise, et spécialisation. Il est
donc importants d'identifier les types de projet avant de concevoir le processus d’élaboration,
donc le choix du modèle et le profil des équipes. Les projets sont analysés suivant 2 axes ; les
domaines d'application et la taille.
- 21 -
Fonction du domaine d'application
Caractéristique Infrastructure Back-Office Front-Office
Budget 1M€-10M€ 0,5M€ - 2M€ 1M€-5M€
Niveau organisationnel
Division informatique (production et architecture)
Divisions de support Division commerciale ou marketing
Durée 6 mois - 12 mois plus d'un an 2M€
Niveau organisationnel
Service Division Entreprise
Durée 1 an
Impact Interne Changement minimum, ou extension d’une application
Changement moyen ou modification d’un système existant, mais pas de changement de processus
Impact significatif sur les méthodes de travail, BPR
Impact Externe Affecte principalement les processus internes
Impacts indirect sur les clients, peu de conséquences contractuelles
Impact direct sur les clients, conséquences contractuelles importantes
Technologie Standard, technologie éprouvée
Technologie éprouvée, mais nouvelle pour la division
Technologie émergente
- 22 -
Caractéristique Type 1 Type 2 Type 3
Fournisseurs Bonne expérience avec les fournisseurs choisis
Expérience moyenne de certains fournisseurs, gestion des livraisons sur plusieurs sites
Premier outsourcing, pas d’expérience avec un ou plusieurs fournisseurs
Complexité Système isolé Système dépendant d’autres systèmes
Nouveau système, dépendants de systèmes critiques
Au delà des aspects qui viennent d’être évoqués précédemment, il est essentiel pour
l’entreprise de réaliser les avantages liés à l’utilisation des modèles ou de normes dans leurs
activités et les améliorations qui peuvent en découler.
IV.5. Amélioration liée à l’utilisation de modèles
Plusieurs entreprises et organismes ont documenté et présenté publiquement les
bénéfices qu'ils ont obtenus en investissant dans l'amélioration de leur processus. Une étude
du Software Engineering Institute publiée en octobre 2003 donne des statistiques forts
convaincantes sur les retombées positives de l'amélioration de processus dans les domaines
des coûts, des délais, de la qualité, de la satisfaction du client et des retours sur
investissements. Quelle entreprise serait prête à ne pas améliorer ses bénéfices tout en
améliorant ses profits ? Voici donc quelques extraits de l’étude réalisée par le SEI (source
[11]).
Amélioration Société Modèle 33% de réduction pour réparer une erreur Boeing, Australie CMMI
20% de réduction par unité de logiciel Lockheed Martin M&DS CMMI 15% de réduction pour trouver et réparer une
erreur Lockheed Martin M&DS CMMI
4,5% de réduction des frais fixes (“overhead”) Lockheed Martin M&DS CMMI
Amélioration et stabilisation de l'indice des coûts Northrop Grumman IT1 CMMI
Économie de 2 million $US dans les 6 mois de la confirmation de niveau 3 de maturité
selon SW-CMM
Sanchez Computer Associates, Inc. SW-CMM
20% de réduction moyenne de l'écart type Thales Research & Technology SW-CMM
60% de réduction pour l'acceptation des usagers
Thales Research & Technology SW-CMM
Écart type décroît à mesure que le niveau de maturité augmente
Thales Training and Simulation SW-CMM
Impacts sur les coûts
- 23 -
Après observation de ce premier tableau, on constate que l’utilisation des modèles
SW-CMM ou CMMI entraîne une baisse des coûts non négligeable. On remarque également
que cette baisse s’applique à de nombreuses étapes d’élaboration du produit (baisse des coûts
de correction d’erreur, réduction des frais fixes).
Amélioration Société Modèle
Réduction de 50% des délais de livraison Boeing, Australie CMMI 60% de réduction et moins d'actions
extraordinaires lors des audits de pré-tests et de post-tests
Boeing, Australie CMMI
Augmentation approximative de 50% à 95% de respect des jalons General Motors CMMI
Diminution de 50 à moins de 10 des jours de retard General Motors CMMI
Amélioration des performances résultant d'un nombre accru de livraisons par année JP Morgan Chase CMMI
30% d'augmentation de productivité en logiciel Lockheed Martin M&DS CMMI Amélioration et stabilisation de l'indice des
délais Northrop Grumman IT1 CMMI
Respect de tous les jalons (suite de 25), avec une grande qualité et à la satisfaction du client Northrop Grumman IT2 CMMI
10% d'amélioration dans les défauts résiduels entraînant une diminution de reprise des
travaux ("rework") Bosch Gasoline Systems SW-CMM
15% d'amélioration en livraison interne à temps Bosch Gasoline Systems SW-CMM
Délais de livraison prévus avec plus d'acuité JP Morgan Chase SW-CMM Écart type décroît à mesure que le niveau de
maturité augmente Thales Training and
Simulation SW-CMM
Impacts sur les délais Les délais se trouvent être respectés voire même améliorés, au niveau de l’avancement
du projet, mais aussi au niveau de la livraison finale.
- 24 -
Amélioration Société Modèle But atteint de 20 +/- 5 défauts par millier de
lignes de code Northrop Grumman IT1 CMMI
Seulement 2% de tous les défauts trouvés dans les systèmes livrés Northrop Grumman IT1 CMMI
Réduction de 6,6 à 2,1 défauts par millier de lignes de code après cycles d'analyses causales Northrop Grumman IT2 CMMI
Focalisation accrue sur la qualité par les développeurs Northrop Grumman IT2 CMMI
Réduction d'un ordre de grandeur des défauts en usine Bosch Gasoline Systems SW-CMM
Réduction en nombre et sévérité des défauts post-livraison JP Morgan Chase SW-CMM
Plus de 2 millions $US d'économie résultant d'une détection et d'une correction hâtive des
défauts
Sanchez Computer Associates, Inc. SW-CMM
Amélioration de la qualité du code Sanchez Computer Associates, Inc. SW-CMM
Impacts sur la qualité
La qualité se trouve également impactée de façon positive, la qualité du code ainsi que
le nombre d’erreurs se trouve grandement amélioré. Ainsi les produits livrés aux clients sont
donc plus fiables et nécessitent moins de corrections.
Amélioration Société Modèle Amélioration de 55% des primes sur livraison
comparativement à une période où l'organisation était évaluée niveau 2 avec le
SW-CMM
Lockheed Martin M&DS CMMI
A reçu plus de 98% du maximum possible des primes sur livraison de la part du client Northrop Grumman IT1 CMMI
Cote “Exceptionnelle” dans toutes les catégories de performance applicable en tant que sous-
traitant Northrop Grumman IT2 CMMI
Impacts sur la satisfaction des clients
Ce qui découle très logiquement des constatations précédentes, est la satisfaction
accrue du client. En effet, étant donné que l’on livre au client des produits de meilleure
qualité, dans les délais et même moins chers, le client ne peut qu’être satisfait.
- 25 -
Amélioration Société Modèle 5:1 dans les activités Accenture CMMI
13:1 calculés sur les défauts évités par heures passées en formation et en prévention des défauts Northrop Grumman IT2 CMMI
Processus de détection hâtive des défauts, amélioration de la gestion des risques et meilleur contrôle de projets déployés après qu'un projet
pilote ait démontré un ROI positif
Thales TT&S CMMI
Retour sur investissement (“ROI”)
On remarque également un accroissement de la rentabilité des activités
IV.6. L’expérience de la société SQLI
Au cours de ma recherche de documents sur Internet, j’ai remarqué que l’entreprise
SQLI était la première société de services informatiques française à avoir tenté et réussi
l’utilisation du modèle CMMI. J’ai donc pris contact avec cette société et plus précisément
Monsieur Hartz, directeur de projets, un des responsables de la mise en place du modèle, afin
de connaître les difficultés auxquelles l’entreprise avait été confrontées, les avantages pour la
gestion des risques dans les projets informatiques et enfin les raisons du choix du modèle
CMMI.
IV.6.1. Les difficultés
Le groupe SQLI est répartit sur plusieurs sites en France et à l’étranger. Ceci pose
donc problème pour le déploiement de pratiques uniformisées ainsi qu’une certaine difficulté
à formaliser les choses. Il existe également un frein au changement de la part de certains de
leurs collaborateurs qui ne cernent pas l’utilité de l’application de telles méthodes.
L’approche par niveau de maturité soulève aussi quelques problèmes dans le cas d’une
structure multi-sites, puisqu’il faut que toutes les agences aient le même niveau de maturité
pour que l’ensemble de la structure soit validé. L’objectif pour le moment étant la certification
de niveau 2 et 3.
- 26 -
IV.6.2. Avantages pour la gestion des risques
Grâce à l’utilisation de ce modèle, il est plus facile pour la société d’anticiper sur les
problèmes, d’être capable de déterminer par rapport à un style de projet, quel type de
difficulté pourrait survenir. Ceci est réalisé grâce à l’utilisation d’une liste de contrôle
appliquée à tous les projets avant la mise en vente d’un produit logiciel. Ainsi il est plus facile
de prévoir des actions correctives face à tel ou tel projet et de justifier les coûts de
développement.
IV.6.3. Choix du modèle CMMI
L’entreprise SQLI n’est pas convaincue par l’utilité des normes ISO sur les projets
informatiques, en effet les normes telles ISO 9000 s’appliquent à l’ensemble des activités de
l’entreprise et non pas spécifiquement aux besoins liés à l’activité de développement de
produits informatiques. Le choix était également possible avec les méthodes RUP ou Merise
mais ces méthodes étaient beaucoup moins détaillées et nécessitaient la mise en œuvre
d’outils pas toujours adaptés à tous les aspects de l’activité.
En revanche le modèle CMM (SW-CMM) concerne pleinement l’activité de
développement de logiciels, donc au cœur de métier de l’entreprise. Cependant le SEI ayant
annoncé qu’il n’y aurait pas de nouvelles versions du CMM a conduit l’entreprise à choisir le
modèle CMMI ; donnant ainsi une approche innovante à l’entreprise. Le modèle CMM sera
remplacé par le modèle CMMI.
- 27 -
V. Recommandations
Après avoir réalisé la présentation des différents modèles existants, il est possible de
déterminer quel modèle se trouve être le plus adapté ou répondant le mieux à l’interrogation
posée par notre étude.
Les sociétés de services informatiques ont tout intérêt à utiliser les normes ou des
modèles pour la gestion de leurs activités et ce pour plusieurs raisons. Leur utilisation permet
d’améliorer entre autres la qualité, les coûts et la satisfaction du client. Certes leur mise en
œuvre nécessite des modifications de l’organisation de l’entreprise, mais si ces dernières sont
appliquées progressivement, leurs adoptions ne posent alors pas de problèmes majeurs. Cela
nécessite une implication du personnel à tous les niveaux tant hiérarchiques que dans la base.
Pour le problème évoqué par le sujet, il est préférable d’utiliser des normes ou bien des
modèles qui soient plus axés sur la conduite de projets informatiques. En effet, les normes
telles que ISO 9000 (qui visent la satisfaction du client) s’appliquent à tous les éléments de
l’entreprise en général ; or dans notre cas, il est préférable de se focaliser sur le processus de
développement. Rien n’empêche bien sûr l’entreprise de cumuler l’utilisation de plusieurs
normes ou modèles. Les modèles préconisent un mode opératoire pour leur mise en œuvre
dans l’organisation. Ils permettent aussi à l’entreprise d’évaluer son niveau d’organisation
dans la gestion des tâches relatives au développement.
Les risques qui peuvent affecter le projet sont également mieux identifiés qu’il
s’agisse des risques « simples » c’est à dire ceux qui découlent directement du travail à
réaliser que ceux dont la cause peut être moins évidente à distinguer. Le modèle CMMI par
exemple prévoit l’ensemble des activités liées à la prévention du risque, c’est à dire leur
identification, leur probabilité d’apparition. Une bonne organisation du projet ainsi qu’une
bonne documentation font partie des solutions à utiliser.
Au delà de la seule gestion des risques, l’utilisation de modèles ou de normes, permet
des améliorations nettes au niveau des coûts de développement ; en effet en normalisant cette
action il est possible de réutiliser les études et le code réalisés pour des projets similaires. De
ce fait les délais de livraison vont également se trouver raccourcis et les risques mieux
identifiés. Cela permet aux entreprises de livrer des produits plus rapidement ou tout du moins
de respecter les délais plus facilement. L’utilisation de telles méthodes ou modèles permet
donc d’augmenter la qualité des produits développés et donc la satisfaction du client.
- 28 -
Le modèle CMMI, remplit toutes ces conditions et les sociétés qui l’utilisent,
remarquent des changements significatifs (voir IV.5) dans leurs qualités et leurs
performances. De plus, ce modèle est spécifiquement élaboré pour la gestion de projets
informatiques et tiens compte de l’expérience acquise avec le modèle précédent (CMM).
- 29 -
VI. Conclusion
Pourquoi choisir un modèle ? Comme nous l’avons vu dans les paragraphes
précédents, l’utilisation de modèles est bénéfique pour l’entreprise, en ce qui concerne la
qualité, les coûts, et la satisfaction du client.
Bien que leur utilisation entraîne des changements significatifs dans l’organisation de
l’entreprise, leur mise en œuvre, si la société s’applique à suivre les spécifications des
modèles, ne pose pas de problème. Au contraire, elle met au jour les difficultés d’organisation
auxquelles l’entreprise est confrontée et permet ainsi de mieux y remédier.
Cela permet également de bénéficier de l’expérience acquise au cours des projets
précédents, de mieux évaluer les risques qui peuvent survenir, de mieux planifier le
développement de l’application et donc de mieux évaluer les coûts.
Les sociétés ont donc tout intérêt à utiliser les normes ou des modèles et pas
seulement pour la prévention des risques. Comme nous l’avons vu au cours de cette étude, on
constate que les sociétés qui appliquent le plus ces outils, sont situées en Inde. Ces entreprises
sont de taille non négligeable et ajoutent ainsi un atout majeur à leurs compétences. Les
sociétés de services informatiques françaises et européennes sont loin d’avoir atteint les
niveaux d’utilisation de l’Inde, il est donc capital qu’elles s’adaptent si elles veulent pouvoir
rivaliser. Mais ceci révèle un autre problème, les sociétés de services informatiques françaises
sont elles capables de se remettre en question et d’utiliser de telles méthodes ?
- 30 -
VII. Bibliographie
[1] Dictionnaire encyclopédique, Hachette, 1994
[2] Taxonomy-Based Risk Identification, Marvin J. Carr, Software Engineering Institute at
Carnegie Mellon University, Pittsburgh USA, 1993
[3] Software Risk Abatement, United States Air Force pamphlet, 1988
[4] Le petit Larousse illustré, Larousse, 2002
[5] Concepts du Capability Model, Rad.fr le portail de la méthode et de la qualité,
http://www.rad.fr/introcm2.htm
[6] La certification CMM ne suffit pas, Annabelle Bouard, 01 Informatique,
http://www.01net.com
[7] Dean Davison (Meta Group) : « Le CMM bonifie les méthodes de travail du client », 01
Informatique, http://www.01net.com
[8] Capability Maturity Model for Software, Carnegie Mellon University, 2004,
http://www.sei.cmu.edu/cmm/cmm.sum.html
[9] Le modèle SPICE, Q-Labs France, http://www.objectif.fr/spice.html
[10] SPICE website, http://www.sqi.gu.edu.au/spice/
[11] Demonstrating the Impact and Benefits of CMMI : An Update and Preliminary Results,
Dennis R. Goldenson & Daine L.Gibson, CMU/SEI-2003-SR-009, 2003
[12] CMMI-SE/SW/IPPD/SS v1.1 Continuous representation, SEI, 2002,
http://www.sei.cmu.edu
[13] Risque, mode de gestion et succès des projets d’informatisation : une étude empirique,
Jean Talbot, TS 92 Mon-163 Université Montpellier II, 1992
[14] Site dédié au management, à l'urbanisme des systèmes d'information, et à la net
économie, Jérôme Capirossi, http://www.jerome.capirossi.org/prj_mgt/prj_mgt-3.htm
[15] CMM, RAD et UML, une nouvelle donne pour l’ingénierie du développement, GRD
publications, http://www.grd-publications.com/art/ls022/ls022010.htm
[16] Analyse du risque, Institut d’électronique et d’informatique Gaspard Monge, http://www-
igm.univ-mlv.fr/~dr/XPOSE/TesTs/SiteWeb/risquetests.htm
[17] Enquête, les SSII optent de plus en plus pour les centres de développement, 01net,
http://www.01net.com
[18] Le processus itératif, ou « roue de l’amélioration », 01net, http://www.01net.com
[19] Le modèle CMMI, Q-Labs, http://www.q-labs.fr/cmmi.html
- 31 -
[20] Qualité, SQLI CORPORATE, http://www.sqli.com
[21] Capability Maturity Model (SW-CMM) for software, Software Engineering Institute,
http://www.sei.cmu.edu/cmm/cmm.sum.html