Conservatoire National des Arts et Métiers Oral probatoire -- Analyse des...

33
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

Transcript of Conservatoire National des Arts et Métiers Oral probatoire -- Analyse des...

  • 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