Étude sur les cas d’échec ou de réussite partielle en amélioration de … · 2012-12-20 ·...

G É N I E L O G I C I E L N o 9 2 M A R S 2 0 1 0

RETOUR D’EXPÉRIENCE

29

1. INTRODUCTIONSoucieuses de réduire leurs coûts et leurs délais,d'améliorer la qualité de leurs produits et services,d'atteindre un retour sur investissement positif etsatisfaire leurs clients, de nombreuses entreprisesdécident d'entreprendre des projets relatifs à l'amé-lioration des performances de leurs processus logi-ciels.

Une des questions que doit se poser une entre-prise avant d'entreprendre un projet d'améliora-tion est celle de savoir si le projet lui assurera lesrésultats prévus dans les objectifs initiaux et s'ilconduira au succès.

La réponse à cette question passe par :• l'analyse d'expériences relatives à des projets

d'amélioration pour connaître les causes pos-sibles de celles ayant partiellement réussi ousubi un échec,

• l'élaboration d'un rapport contradictoire vis-à-visdes divers articles publiés, ces derniers ne met-tant en valeur que des cas de réussite (cf. rapportdu Software Engineering Institute publié en 2006[18]).

Cette étude servira, entre autres, de guide pourla région de Montréal qui compte environ700 entreprises et plus de 17 000 emplois dans le

Étude sur les cas d’échecou de réussite partielle

en amélioration de processuslogiciels dans des sociétés

québécoisesM I L O U D B E N T T O U M I , C L A U D E Y . L A P O R T E , A L A I N A P R I L

E T S A M I A K A B L I

Résumé : De nombreux articles et rapports publiés depuis plusieurs années sur l’amélioration des processus logi-ciels font référence à des situations à succès ; en particulier, c’est le cas du rapport publié en 2006 par le SoftwareEngineering Institute et intitulé « Performance Results of CMMI-Based Process Improvement ». Par contre, lescas de situations d’échec ou de réussite partielle sont rares, pour ne pas dire presque jamais évoqués, dans ces docu-ments. Le présent article se veut être un rapport contradictoire vis-à-vis de ces différentes publications. Il se basesur l’étude de projets en amélioration de processus logiciels ayant utilisé le modèle d’évolution des « capacitéslogiciel » (SW-CMM) et le Capability Maturity Model Integration for Development (CMMI-DEV) du SoftwareEngineering Institute (SEI). Aussi, cette étude a été conduite sur la base d’entrevues réalisées avec des experts enamélioration de processus logiciels et avec des industriels, entrevues dont les constats et l’analyse ont permis ladéduction d’une vingtaine de facteurs d’échec regroupés selon les trois phases du cycle de vie d’un projet enamélioration. Ainsi, des recommandations ont été proposées aux organisations afin de leur éviter un échec deleurs projets en amélioration de processus logiciels.

Mots clés : Amélioration de processus logiciels, facteurs d’échec, facteurs de réussite partielle, facteurs de réus-site complète, cycle de vie d’amélioration de processus logiciels, très petite entreprises (TPE), CMMI, SW-CMM.


30

secteur du logiciel [17] avec pour objectif d'aiderces dernières à procéder à des investissementspertinents dans l'amélioration de leurs perfor-mances. Ce guide leur permettra également demieux comprendre les causes d'échec ou de réus-site partielle dans leurs projets d'amélioration deperformances.

• Étape 4 : Proposition de recommandations rela-tives aux constats dégagés à destination desentreprises du secteur du génie logiciel désirantréaliser un projet d'amélioration de leurs pro-cessus logiciels.

Dans cette étude, l'accent a été mis sur les casde projets d'amélioration de processus logiciels(PAL) (Software Process Improvement ou SPI)ayant connu un échec ou une réussite partielle.Afin d'éliminer toute ambiguïté, une définitionclaire des mots échec, réussite partielle et réussitecomplète s'impose. En effet, l'échec revêt plu-sieurs définitions ; il traduit en général un objec-tif fixé, mais non atteint. Inversement, la réussiteou le succès traduit en général un objectif fixé etatteint. Entre l'échec et le succès, on peut définirle succès partiel qui peut être distingué du suc-cès total par le pourcentage d'objectifs fixés etatteints.

Il existe des critères, généralement mesu-rables, qui permettent d'évaluer un PAL. La défi-nition de ces critères diffère d'un article à l'autreentre les facteurs de succès ([4], [14], [16], [33],[42]), les paramètres d'évaluation d'un projet ([6],[15], [32], [34]) ou les mesures de performances([18], [19]).

On peut résumer ces critères en cinq catégo-ries : • satisfaction des clients,• respect des calendriers de projets, • capacité à atteindre des objectifs budgétaires, • qualité, • productivité.

Sur la base de ces critères, les projets enéchec, partiellement réussis ou totalement réussisse définissent ainsi :• Projets totalement réussis : projets qui n’ont

échoué sur aucun des cinq critères de succès.• Projets partiellement réussis : projets qui ont

échoué sur un, deux ou trois critères de succès.• Projets non aboutis : projets qui ont échoué sur

plus de trois critères de succès.

3. LA DÉMARCHE DE L’ÉTUDE3.1 ÉTAPE 1 : REVUE DE LA LITTÉRATURE

Lors de cette étape, une revue de la littérature apermis d’analyser et de dégager des constats deperformances dans l’amélioration de processuslogiciels. Cette revue a porté sur les documentspubliés suivants :

3.1.1 Le rapport du Software Engineering InstituteIntitulé « Performance Results of CMMI-BasedProcess Improvement » [18], ce rapport consti-tue le point de départ de l'étude. Sa publicationpar le Software Engineering Institute (SEI), dansun souci d'échange technique, présente des résul-


Tableau 1 : Nombre d’entreprises et d’emplois du secteur du logicieldans la région du Grand Montréal [17]

En ciblant ces entreprises, ce guide permettraaux consultants en amélioration et aux organismesgouvernementaux qui subventionnent les pro-grammes d'amélioration de processus de mieuxcomprendre les causes d'échec ou de réussite par-tielle de projets d'amélioration de performances.

Le présent travail sera aussi utilisé par lesmembres du groupe de travail ISO JTC1/SC7-WG24 [29] qui ont pour objectif d'élaborer unenorme internationale pour aider les très petitesentreprises (TPE), d'au plus 25 employés, quidéveloppent du logiciel, à devenir plus perfor-mantes et plus compétitives.

2. PRÉSENTATION DE L’ÉTUDEL'étude s'est basée sur les résultats de perfor-mances en amélioration de processus logicielsobtenus par des entreprises ayant utilisé lesmodèles Software Capability Maturity Model®(SW-CMM) [40] et Capability Maturity ModelIntegration (CMMI) [8] du Software EngineeringInstitute (SEI). Elle s'est déroulée selon quatreétapes principales :• Étape 1 : Réalisation d'une revue de la littéra-

ture et rédaction des constats de cas d'échec ou desuccès en amélioration de processus logiciels parl'analyse du rapport du SEI intitulé " PerformanceResults of CMMI-Based Process Improvement "publié en août 2006. Cette revue est réalisée éga-lement à partir d'autres articles publiés dans despublications telles que : Software Process Impro-vement and Practice [36], Crosstalk [9], IEEESoftware [25] ainsi qu'à partir de mémoires demaîtrise et de rapports portant sur l'améliorationde processus logiciels.

• Étape 2 : Élaboration de questionnaires etconduite d'entrevues avec des experts en amé-lioration de processus et avec des industriels surla base des constats relatifs à des cas d'échec oude réussite partielle dégagés lors de la revue dela littérature.

• Étape 3 : Analyse des entrevues et élaborationdes constats relatifs aux retours des question-naires


31

tats obtenus suite à l'amélioration de processusavec le modèle CMMI sous forme de mesurestelles que le coût des performances, la qualité duproduit et le retour sur investissement ainsi qued'autres mesures de performances considéréescomme preuves de réussite de l'amélioration deprocessus.

Les résultats de ce rapport proviennent de plu-sieurs secteurs, notamment le secteur des télé-communications, le secteur financier, le secteur dela fabrication et celui des industries de défense.Beaucoup de résultats proviennent d'entreprisesayant un niveau de maturité CMMI élevé (niveau 4ou 5) ; cependant, d'autres résultats impression-nants relèvent d'entreprises dont le niveau de matu-rité est inférieur à 3 (niveaux 1, 2 ou 3).

Le tableau 2 permet de mettre en évidence lesdifférents constats relevés dans le rapport du SEIqui classe les mesures de performances selon sixcatégories : le coût, le calendrier, la productivité,la qualité, la satisfaction du client et le retour sur

investissement.

3.1.2 D’autres rapports et articles issus de larevue de la littératureD'autres articles publiés dans différentes revues, desrapports sur des cas en amélioration de processusainsi que des mémoires de maîtrise ayant commepoint commun le succès ou l'échec en améliorationde processus logiciels ont fait l'objet d'une analysequi a fait ressortir les points suivants :• Tous les résultats publiés dans ces articles sont

positifs, démontrant une absence d'étude de la cau-salité d'échec ou de réussite dans le domaine del'amélioration de processus logiciels. L'absencede descriptions de résultats négatifs ne peut passignifier l'inexistence de cas d'échec de projetsétant donné que plusieurs des articles concernésmentionnent un taux d'échec de plus de 50% desprojets en amélioration de processus logiciels [1],[11], [21], [30], [38], [42]. Ces articles font réfé-rence à des facteurs de succès et suscitent les inter-rogations suivantes : Ces facteurs de succès sont-ilsréciproques par rapport à l'échec ou à la réussite


Tableau 2 : Constats tirés du rapport du SEI


32

partielle ? Un facteur de succès cause-t-il un écheclorsqu'on ne le respecte pas ? N'y a-t-il pas de fac-teurs spécifiques de l'échec qui ne figureraient pasaussi dans les facteurs de la réussite ?

• Certains de ces articles étudient seulement lesfacteurs ou les causes d'échec des projets en TI[16], [20], [24]; ceci peut s'avérer utile dansl'étude des facteurs ou des causes d'échec desprojets d'amélioration de processus logiciels.

• Un certain nombre d'articles traitent des facteurs derisques dans l'amélioration de processus logiciels[13], [38]. Les deux interrogations « Un facteurde risque peut-il être considéré comme un facteurd'échec ? » et, inversement, « Un facteur d'échecpeut-il être considéré comme un facteur derisque ? » sont à prendre en considération pourétudier la relation entre les facteurs de risque etl'échec ou la réussite partielle de projets d'amé-lioration de processus logiciels.

• D'autres articles ([6], [15], [20], [32], [34]) traitentde critères d'évaluation d'un projet qui peuventnous servir à bien définir le degré de succès desPALs. En l'évaluant, on peut savoir si un projetd'amélioration de processus d'amélioration de pro-cessus a conduit à un échec, à une réussite par-tielle ou à une réussite totale.

• Une certaine catégorie d'articles ont été bénéfiquespour la démarche adoptée dans le cadre de la pré-sente étude notamment : - pour déterminer des étapes de réalisation de

ce projet : revue de la littérature, élaborationdes constats, entrevues et le rapport des résul-tats de l'étude [41],

- concevoir le questionnaire selon les exemplesdonnés [13], [23], [26].

- pour établir les mécanismes de recherche desarticles entrant dans la revue de la littérature [31].

Les résultats pertinents de l’analyse de cesarticles peuvent se résumer comme suit :• Plus de 50 % des projets d’amélioration de pro-

cessus logiciels sont des échecs. • Aucune divulgation de résultats de performances

clairs qui démontreraient l’échec de projetsd’amélioration de processus logiciels.

• Le contenu de ces articles fait référence à desfacteurs de succès ou de risques des projetsd’amélioration de processus logiciels, mais aucu-nement aux facteurs et aux causes d’échec.

• Les facteurs de succès et de risque des projetsd’amélioration de processus logiciels peuventservir à étudier les facteurs et les causes d’échec.

• L’étude des facteurs et des causes d’échec deprojets TI peut également servir à définir lesfacteurs et les causes d’échec de projets SPI.

• Les critères d’évaluation de projets peuvent aiderà connaître le niveau de leur succès.

3.2 ÉTAPE 2 : ENTREVUE AVEC LES EXPERTS

ET QUESTIONNAIRE CORRESPONDANT

Cette section décrit l’élaboration de questionnaires

et la conduite d’entrevues avec des experts en amé-lioration des processus et avec des industriels.

3.2.1 Questionnaire d’entrevue À partir des constats énoncés dans la revue de lalittérature, un questionnaire a été élaboré pourguider les experts en amélioration de processuslogiciels (SPI) ainsi que les industriels partici-pant aux entrevues.

Le questionnaire comportait trois volets prin-cipaux :• Volet 1 : Informations personnelles, notamment

des questions relatives à l’expérience du participantdans le domaine de l’amélioration de processuslogiciel comme le nombre d’années d’expérienceen amélioration de processus logiciels et les dif-férentes responsabilités occupées. Il en est de mêmede l’obtention de la part du participant de sonaccord pour la publication de son nom et celui deson entreprise dans la présente étude.

• Volet 2 : Contexte de l’entreprise dans laquellel’amélioration a été faite, notamment des ques-tions relatives à la taille de l’organisation en TI,à son domaine d’activité, à sa situation géogra-phique, à ses certifications en matière de qualitécomme ISO 9000 et/ou au niveau de maturitéCMM ou CMMI.

• Volet 3 : informations sur le projet qui a connu unéchec ou une réussite partielle, notamment, préa-lablement, des définitions relatives aux critères desuccès d’un projet d’amélioration logiciel (projettotalement réussi, projet partiellement réussi etprojet échoué) ainsi que des questions informa-tives relatives au projet échoué ou partiellementréussi (la durée et l’effort pris par ce projet d’amé-lioration, les coûts réel et estimé de l’effort et lerôle du participant dans ce projet). Vingt-huitautres questions viennent à la suite, inspirées dela revue de la littérature, pour faire ressortir lescauses d’échec ou de réussite partielle des diffé-rents projets analysés dans l’étude.

Quatre réponses possibles ont été associéesà chacune de ces questions avec la possibilité dementionner que la question ne s’applique pas aucontexte étudié (NA) :• réponse négative : N, • partiellement positive : PP, • positive : P,• entièrement positive : EP.

Sur une échelle de 0 à 3, une valeur a étéaffectée aux différentes réponses obtenues : • une réponse négative (N) vaut 0, • une réponse partiellement positive (PP) vaut 1,• une réponse positive (P) vaut 2, • et une réponse entièrement positive (EP) vaut 3.

En plus de ces trois volets, une partie « com-mentaires » a été réservée à l’ajout d’informa-



33

tions complémentaires aux vingt-huit questionsque le participant jugera utiles de préciser.

À la fin du questionnaire d’entrevue, unequestion formulée permet à chaque participantd’indiquer les trois facteurs d’échec ou de réussitepartielle en amélioration des processus qu’il jugeles plus importants.

3.2.2 Déroulement et résultats de l’entrevue• Le questionnaire est envoyé aux participants en

même temps que l’invitation à participer et, aprèschaque entrevue, un compte rendu sur la base duquestionnaire rempli est renvoyé au participantpour validation.

• Sept entrevues ont été réalisées dans cette étude(cinq en format papier et deux effectuées par télé-phone), en plus d’un questionnaire rempli en for-mat électronique. La durée moyenne des entrevuesest d’une heure.

• Les participants à cette étude ont de dix à vingtans d’expérience dans le domaine de l’améliorationde processus logiciels, ayant occupé divers rôlestels que chef de projet, gestionnaire, membre duSEPG (Software Engineering Process Group),consultant ou évaluateur.

• Dix projets ont été évalués durant les entrevuesdont deux portant chacune sur deux projets. Parmices deux projets, six ont échoué et quatre ont par-tiellement réussi.

3.2.3 Analyse sur les entreprises participant àl’entrevue• La collecte, par le biais des réponses des partici-

pants, de l’information sur le nombre de projetsréussis, partiellement réussis et en échec a permisde confirmer qu’il n’y a pas eu que des succès enamélioration de processus logiciels. La figure 1présente en pourcentage la répartition de ces troiscatégories de projets.


Figure 1 : Projets en amélioration auxquels les participantsont participé

• La figure 2 illustre le nombre de projets étudiésdans cette étude en fonction de la situation géo-graphique des entreprises dans lesquelles les amé-liorations ont été faites.

• L’analyse des projets montre que les domainesd’activité des entreprises dans lesquelles lesaméliorations ont été faites sont variés : le trans-port, les télécommunications, la finance, la fabri-cation et l’industrie de défense. Le diagrammede la figure 3 montre la répartition des projetsétudiés selon ces différents domaines sectoriels.

• Il s’avère que les entreprises sont de différentes

Figure 2 : Situation géographique des entreprises dans lesquellesles améliorations ont été faites

Figure 3 : Activités des entreprises dans lesquelles les améliorationsont été faites

Figure 4 : Taille des entreprises dans lesquelles les améliorations ont été faites

tailles : TPE (Très Petite Entreprises, c’est-à-dired’au plus 25 employés), PME (Petite et MoyenneEntreprises : entre 25 et 200 employés) et de grandesentreprises (plus de 200 employés) ; de même pourla taille des départements en TI. Le diagramme de lafigure 4 présente, selon leurs tailles, les entreprisesdans lesquelles les améliorations ont été faites. Parmices entreprises, celles qui ont déjà des certificationsISO 9000 ou sont conformes à un niveau de maturitéselon le CMM ou le CMMI.

3.2.4 Résultats des questionnairesToutes les réponses aux vingt-huit questions rela-tives aux entrevues effectuées auprès des dix entre-prises ont été répertoriées dans le tableau 3. Lesabréviations suivantes ont été utilisées : Nbre N : Nombre de réponses NégativesNbre PP : Nombre de réponses Partiellement

PositivesNbre P : Nombre de réponses PositivesNbre EP : Nombre de réponses Entièrement

PositivesNbre NA : Nombre de réponses Non Applicables


34

3.3 ÉTAPE 3 : ANALYSE ET INTERPRÉTATION

DES RÉSULTATS OBTENUS LORS DES ENTREVUES

Cette section présente l’analyse des entrevues etl’élaboration des constats relatifs aux retours desquestionnaires. Les points suivants illustrent ladémarche suivie lors de cette phase d’analyse :

a-Afin de faciliter le traitement et l’analyse sta-tistique des vingt-huit questions du question-naire, une codification a été rendue nécessaire :• Le code 0 sera attribué à la fois à une réponse

négative (N) et à une réponse non applicable(NA)


Tableau 3 : Résumé desréponses relatives aux dixquestionnaires


35


Tableau 4 : Scores des questions pour les dix questionnaires

• Le code 1 sera attribué à une réponse partiel-lement positive (PP),

• Le code 2 sera attribué à une réponse positive(P),

• et le code 3 le sera pour une réponse entière-ment positive (EP).

b-Un score total a été calculé horizontalementdans les dix questionnaires, en additionnant lescore de chaque question dans tous les ques-tionnaires (scores des questions) ; il en est demême du calcul vertical du score d’un regrou-pement de questions dans le même question-naire (scores par questionnaire). Les scores sontsous forme de pourcentages et une illustration dequelques-uns parmi les vingt-huit questions estdonnée dans le tableau 4.

Abréviations :Q1 : Questionnaire de l’entrevue nº 1Q2 : Questionnaire de l’entrevue nº 2Q3 : Questionnaire de l’entrevue nº 3Q4 : Questionnaire de l’entrevue nº 4Q5 : Premier questionnaire de l’entrevue nº 5Q6 : Deuxième questionnaire de l’entrevue nº 5Q7 : Premier questionnaire de l’entrevue nº 6Q8 : Deuxième questionnaire de l’entrevue nº 6Q9 : Questionnaire de l’entrevue nº 7Q10 :Questionnaire de l’entrevue nº 8

c-Les vingt-huit questions ont été classées etregroupées de la façon suivante : 1er regroupement relatif aux questions reliéesà une bonne pratique,2e regroupement relatif aux questions reliées àla rétroaction des personnes concernées parl’amélioration,3e regroupement relatif aux questions informa-tives sur le processus logiciel en amélioration.

Afin de pouvoir comparer les scores des ques-tions entre elles, d’une part, et de donner un sensaux scores totaux calculés verticalement pour

chaque questionnaire, d’autre part [il manque unverbe]. Les scores horizontaux et verticaux destrois regroupements sont illustrés dans la figure 5.

d-Pour chaque questionnaire, les trois facteurs lesplus importants d’échec ou de réussite partielleen amélioration de processus inscrits dans laquestion d’ordre général par le participant ontété analysés par ordre de degré d’importance.Cet état est résumé dans le tableau 5.

e-L’analyse complète des résultats relatifs à l’étudedes dix questionnaires conduit à un constat per-mettant de conforter l’objectif de cette étude.

f- À la lumière de ces constats et de la liste desfacteurs les plus importants proposés par lesparticipants, il a été établi une liste de facteursd’échec en amélioration classés selon les troisphases du cycle de vie du projet d’amélioration(voir le tableau 6).

3.3.1 Le premier regroupement : Questions rela-tives aux bonnes pratiques• Ce regroupement compte les vingt questions sui-

vantes : 1,2, 3, 5, 6, 7, 8, 10, 11, 12, 13, 14, 15,16, 17, 18, 19, 21, 22 et 23.

• Le score général horizontal reste le même pourchaque question par rapport au tableau 4.

• Le score général vertical est de 68.

Remarques et interprétations réalisées au sujetdu 1er regroupement• La plupart des scores horizontaux (par question)

sont compris entre 50 et 80 sauf pour trois scoresqui sont inférieurs à 50 et 4 qui sont supérieursà 80 (figure 5)

• Les scores par questionnaire (verticaux) dépas-sent la moyenne (50) sauf pour deux scores ;six scores sont entre 50 et 80 et deux scoresdépassent 80. La figure 5 englobe les différentsscores par questionnaire du premier regroupe-ment.


36

• Ce regroupement a été scindé en cinq sous-regrou-pements selon le type de bonnes pratiques rela-tivement à des questions qui concernent : lesobjectifs (Questions 1, 2 et 3), les ressources(Questions 5, 6 et 7), le suivi (Questions 12 et13), le soutien et l’engagement (Questions 14,15, 16, 21, 22 et 23) et la planification (Ques-tions 8, 10, 11, 17, 18 et 19).

• L’analyse du 1er sous-regroupement « objectifs »révèle l’existence d’une forte corrélation entreles questions 1 et 17. Il a été constaté que leursscores nuls correspondant à l’absence d’effortsde communication et d’objectifs clairs, raison-nables, appropriés et réalistes du projet d’amé-lioration font référence à la taille de l’organisationqui serait une très petite entreprise (Q2).

• Le 2e sous-regroupement « ressources » annoncedes scores assez élevés et équitables entre lestrois questions (5, 6 et 7) impliquant un équilibreentre la compétence et l’expertise des ressources,d’une part, et la formation des ressources, d’autrepart.

• Le 3e sous-regroupement « suivi » annonce desscores assez élevés sauf pour quelques cas où ily a un manque de suivi et de la revue.

• Le 4e sous-regroupement « soutien et engage-ment » donne des scores moins élevés, sauf pourle cas de l’engagement des spécialistes en SPI.Les scores les moins élevés expliquent le cas oùl’absence de l’engagement est due au fait que lesutilisateurs ne sont pas directement concernéspar l’amélioration. Un autre cas affichant un scoremoins élevé dans tous les regroupements pré-sente la particularité d’être une organisation ayantune certification qualité ISO 9000 et n’ayant pasété évaluée conforme à un niveau de maturitéselon les modèles CMM ou CMMI. On peut direque les certifications demandent et nécessitentle soutien et l’engagement, mais ces derniers nesont pas une condition suffisante pour garantir

la certification ou la conformité à un niveau dematurité donné.

• Le 5e sous-regroupement « planification » a géné-ralement des scores assez élevés sauf pour lesdeux questions sur la gestion des changementset l’évaluation de l’amélioration qui ont eu unscore moins élevé. La gestion des changementsn’était pas considérée dans la plupart des cas étu-diés au même niveau de considération que l’éva-luation quantitative des améliorations.

3.3.2 Le deuxième regroupement : Questions rela-tives à la rétroaction des personnes concernéespar l’amélioration• Ce regroupement compte les trois questions sui-

vantes : 4, 9 et 20.• Le score général horizontal reste le même pour

chaque question par rapport au tableau 4.• Le score général vertical est de 84.

Remarques et interprétations réalisées au sujet dece 2e regroupement• Les scores horizontaux sont très élevés particu-

lièrement pour la question relative à la résistanceau changement (Figure 5).

• Même s’il n’est pas clair à partir des réponses auxquestions, plusieurs bonnes pratiques du premierregroupement peuvent aider à diminuer ou à réduireles trois points de ce deuxième regroupement (larésistance au changement, la pression commer-ciale et la difficulté d’adoption des nouveaux pro-cessus). Les bonnes pratiques principales quipeuvent influencer ces derniers points sont : laformation des ressources, les efforts de commu-nication, l’engagement et l’implication des per-sonnes concernées (utilisateurs, spécialistes…) etla gestion de changement de l’intervenant.

• Les scores verticaux sont généralement trop éle-vés sauf pour une valeur qui ne dépasse pas lamoyenne (figure 5).


Figure 5 : Les scores des questions par questionnaire pour chacun des trois regroupements


37

3.3.3 Le troisième regroupement : Questionsinformatives sur le PAL• Ce regroupement compte les cinq dernières ques-

tions : 24, 25, 26, 27 et 28.• Le score général horizontal reste le même pour

chaque question par rapport au tableau 4.• Le score général vertical est de 40.

Remarques et interprétations réalisées au sujetde ce 3e regroupement :• Ses scores horizontaux sont moins élevés à part

la question sur l’existence d’un champion du PAL(Processus d’amélioration logiciel) qui totalise unscore total de 100 (figure 5). Les dix question-naires font référence à une panoplie de titres dechampions des projets d’amélioration logiciel :expert en assurance qualité logicielle, chef del’unité de gestion des processus des technologiesde l’information, directeur d’usine, directeur d’in-génierie, VP en TI, gestionnaire de processus,directeur de la qualité, VP ingénierie et technolo-gie, gestionnaire intermédiaire.

• Dans la plupart des cas, le PAL était indépendantd’un projet logiciel, il n’était pas considérécomme pré-requis par un projet de développe-ment ; en outre, il n’y avait pas un projet dedéveloppement porteur pour le PAL

• Les scores verticaux sont généralement moins éle-vés sauf pour un score qui atteint les 80. (figure 5)

3.3.4 Facteurs d’échec ou de réussite partielle enamélioration des processus selon leur degré d’im-portanceLe tableau 5 fait état des facteurs les plus importantsmentionnés par les participants en réponse à laquestion générale du questionnaire. Ils ont été clas-sés selon leur degré d’importance correspondant

au nombre de fois que ce facteur a été énoncé dansles différentes réponses.

3.3.5 Constats faisant suite à l’étude et à l’ana-lyse des questionnairesSelon les différents regroupements réalisés sur les dixquestionnaires, les résultats ont été les suivants :• Il y a peu de corrélation avec le contexte dans

lequel les améliorations ont été engagées.• La majorité des questions posées dans le ques-

tionnaire avaient des réponses remarquables (desscores plus ou moins élevés selon la nature de laquestion : bonnes pratiques, rétroaction des per-sonnes concernées par l’amélioration…). Ceciamène à faire ressortir les causes ou facteursd’échec.

• Les facteurs proposés par les personnels inter-viewés complètent et confirment les facteurs syn-thétisés à partir de l’analyse des réponses auxvingt-huit questions.

3.3.6 Liste des facteurs d’échec en améliorationsselon les trois phases du cycle de vie du projet d’amé-liorationLa combinaison des facteurs proposés par les res-sources interviewées et ceux déduits des réponsesaux questionnaires et des analyses conduisent àl’établissement d’une liste d’une vingtaine de fac-teurs d’échec en amélioration. L’opportunité de lesclasser selon les trois phases qui constituent lecycle de vie du projet d’amélioration semble uneétape importante à réaliser (tableau 6). • Phase I relative à la pré-amélioration qui se sub-

divise en deux catégories : la « stratégie » etla « planification ».

• Phase II relative à l’amélioration qui concernel’exécution de l’amélioration.


Tableau 5 : Les facteurs les plus importants d’échec ou de réussite partielle en amélioration des processus selon les personnes interviewées


38

• Phase III relative à la post-amélioration quiconcerne la pérennité.

Note : Les trois premiers facteurs concernentnon seulement la catégorie stratégie et la phasepré-amélioration, mais également les autres phaseset catégories (figure 6).

Il a été jugé intéressant d’illustrer ces vingtfacteurs dans la figure 6 qui permet de les mettre en

évidence selon le passage des projets d’une phaseà l’autre du cycle de vie en amélioration de pro-cessus. Cette figure donne une meilleure visibilitéà l’entreprise quant aux mesures à prendre pouréviter les éventuels échecs de leurs projets en PAL.

3.4 ÉTAPE 4 : LISTE DES RECOMMANDATIONS

Dans cette section, nous proposons des recom-mandations relatives aux constats dégagés à des-tination des entreprises du secteur du génie logiciel


Tableau 6 : Facteurs d’échec ou de réussite partielle en amélioration de processus

Figure 6 : Facteurs d’échec ou de réussite partielle en amélioration des processus


39

désirant réaliser un projet d’amélioration de leursprocessus logiciels.

3.4.1 Recommandations destinées aux organisa-tions entreprenant des PALAfin d’éviter les vingt facteurs considérés commeles causes d’échecs de projet d’amélioration logi-cielles énumérées dans l’analyse faite précédem-ment, les recommandations suivantes sontproposées :1. Le manque de support de la haute direction :

Nous recommandons fortement de chercher lesupport et l’appui de la haute direction pour l’en-gager tout au long du projet d’amélioration logi-cielle.

2. L’absence d’efforts de communication : Il fautimpérativement mettre en place des mécanismesde communication à l’intérieur de chaque caté-gorie aussi bien dans le sens vertical qu’hori-zontal et cela entre les acteurs impliqués dansl’amélioration (décideurs, gestionnaires, spé-cialistes en PAL, etc.).

3. Le manque de formation des personnels : Unprogramme de formation et de sensibilisationdes personnels est nécessaire durant toutes lesphases de l’amélioration en fonction des carac-téristiques techniques et humaines.

4. Les objectifs irréalistes ou cachés : Il faut défi-nir des objectifs clairs, raisonnables, appropriéset réalistes associés au projet d’amélioration.

5. Le manque d’arrimage entre les objectifs du pro-jet et les objectifs d’affaires : L’alignement desobjectifs du projet aux objectifs est déterminant.

6. L’absence d’un projet porteur : Il est importantde bien définir le projet de développement por-teur supportant le PAL.

7. Le manque de visibilité du projet : Augmenter lavisibilité du projet en le faisant connaître davantageaux différents intervenants qui y sont impliqués.

8. L’absence de planification (plan, gestion deconfiguration, assurance qualité…) : Il faut éta-blir une bonne planification du projet ainsi quetoutes les activités connexes telles la gestion deconfiguration et l’assurance de la qualité.

9. L’absence de la gestion du changement : Il fautune bonne sensibilisation et une maîtrise de lagestion du changement du point de vue de latechnologie et des ressources humaines.

10. L’absence d’une évaluation quantitative : Il fautétablir une évaluation quantitative qui puissemesurer la productivité, la qualité et les béné-fices escomptés durant tout le cycle de vie del’amélioration. En effet, en pré-amélioration,l’évaluation va contribuer à dresser un état actueldes performances qui définit clairement les objec-tifs. En cours d’amélioration, l’évaluation vapermettre une bonne orientation et un bon suividu projet. En post-amélioration, l’évaluationcontribuera à mesurer l’alignement des besoinsavec les objectifs assignés au départ du projet.

11. La culture de l’organisation : Il est opportun detrouver un consensus équilibré entre les pointsculturels et les nouveaux processus sans susciterdes changements d’appui à ceux induits par leprojet d’amélioration.

12. La situation organisationnelle difficile de l’or-ganisation : Une organisation doit identifier sesforces et ses faiblesses et doit fortement se pen-cher sur ces derniers afin d’y apporter des amé-liorations organisationnelles avant d’entamerdes projets d’amélioration logicielle palliant ainsid’éventuels échecs ou blocages.

13. Les pressions commerciales : Un engagementet une contribution efficaces des commerciauxdans le projet d’amélioration logicielle, particu-lièrement lors de la définition des objectifs, évi-teront d’aller à contresens de leurs intérêts.

14. La résistance aux changements : Il faut analy-ser et trouver des significations relatives à cetterésistance. Les solutions et les mesures proposéespeuvent être induites par les recommandationsproposées et associées à la culture de l’organi-sation, au manque de formation des personnelset d’engagement des utilisateurs, à l’absenced’efforts de communication et de la gestion duchangement ainsi qu’à l’absence d’implicationdes praticiens.

15. La complexité des implémentations : nous pro-posons de mettre en place au préalable une stra-tégie d’implantation progressive des nouveauxprocessus afin de permettre aux utilisateurs de lesadopter plus facilement suivant un plan de for-mation et des fonds documentaires (exemple desguides aux utilisateurs)

16. La non-implication des praticiens : Nous recom-mandons de susciter l’adhésion des praticiens(programmeurs, architectes, …) dans le projetd’amélioration surtout lors de la définition deses objectifs.

17. L’absence d’engagement des utilisateurs : Il fautégalement faire adhérer les utilisateurs surtoutdans la définition des objectifs correspondants aumieux à leurs besoins.

18. Le manque d’expérience et habileté des membresdu groupe PAL : Nous préconisons de distinguer etde séparer les tâches des membres du groupe PALde celles des autres membres du groupe de génielogiciel afin de mieux cerner le « comment amé-liorer » en plus du « quoi à améliorer ».

19. La pression monétaire : il est nécessaire que lasituation budgétaire de l’organisation supporte leprojet d’amélioration ; il est à remarquer quel’atteinte des objectifs budgétaires des projetslogiciels ne peut être immédiate au tout débutdu changement. Il y a une période dite de« Chaos » qui induit une chute du point de vuedes performances pouvant affecter la situationfinancière de l’entreprise durant cette période.

20. L’absence du maintien de changement : Les per-formances de l’entreprise doivent être constam-



40

ment en amélioration. Le projet d’améliorationne s’arrête pas à l’obtention d’un niveau de matu-rité ou une certification de qualité ; il faut main-tenir le changement pour garder les avantagesacquis.

3.4.2 Recommandations destinées aux personnesentreprenant des études de recherche similairesDans le but d’enrichir le même domaine derecherche, nous proposons d’autres recomman-dations fortement inspirées par les analyses de laprésente étude :• Il est conseillé d’approfondir la recherche biblio-

graphique à propos de l’échec en amélioration deprocessus logiciels et surtout prendre comme based’étude une bibliographie des plus récentes.

• Il est tout indiqué de bien gérer le risque relatif àl’indidisponibilité des experts pour les entrevues,et ce, afin de mener à bien la démarche relative àleurs rencontres. Pour ce faire, il serait judicieuxde prévoir un plus grand nombre de participants àrencontrer, de les motiver suffisamment et deconvenir avec eux des horaires de rencontres quileur conviennent le mieux.

• Il faut élaborer des questionnaires clairs, bien pré-parer les questions à poser lors des rencontres ainsique le contenu des courriels envoyés aux partici-pants qui doit être simple et compréhensible.

• Il est judicieux d’élaborer des comptes rendus ourapports des rencontres le plus tôt possible, la jour-née même de la rencontre ou le lendemain, pour nepas perdre les informations ainsi recueillies.

3.4.3 RemarquesDans sa globalité, cette étude s’est bien dérouléeet les objectifs tracés au départ ont été atteints ;néanmoins certaines difficultés ont été rencon-trées au cours de la réalisation.

Le bon déroulement du projet s’est manifestépar :• une revue de la littérature concernant l’échec

en amélioration de processus logiciels qui nousa aidés à établir des constats sur lesquels estbasée la présente étude,

• des entrevues avec les experts dans le domainede l’amélioration logicielle qui ont permis derecueillir les informations nécessaires profitantdirectement de l’expertise de ces participantspar rapport à des cas réels d’échec ou de réussitepartielle en amélioration de processus logiciels,

• un questionnaire bien préparé, allié à une entrevueefficace, a permis un gain de temps important,

• une élaboration des comptes rendus après chaqueentrevue pour la validation des informationsrecueillies,

• une analyse des résultats obtenus basée sur cesinformations,

• une capacité d’identifier les vingt facteursd’échec ayant le plus d’impact sur les projets

d’amélioration de processus logiciels,• un établissement d’une liste de recommanda-

tions afin d’éviter les vingt facteurs considéréscomme les causes d’échec de PAL.

Parmi les difficultés rencontrées lors de laconduite de ce projet, nous citerons :• La difficulté de maîtriser la planification des

rencontres avec les participants comme prévuau préalable dans le plan du projet

• La difficulté d’avoir certaines réponses à lademande de confirmation de comptes rendus d’en-trevues des participants.

• La rareté des publications traitant de cas d’échecen amélioration de processus logiciels ; ce désa-vantage a contribué à l’élaboration de cette étudepour pallier ce vide dans ce domaine.

• Des difficultés à traduire exactement en françaisquelques termes techniques en anglais, vu que lamajorité des publications étaient en versionanglaise. Il a été décidé d’en préserver quelques-uns dans la langue d’origine en les mettant entreguillemets pour éviter de perdre leur sens.

• Des difficultés rencontrées lors de l’établissementdes causes d’échec étant donné que la plupartd’entre elles (la résistance aux changements, laculture de l’organisation, le manque de formationdes ressources, l’absence d’efforts de communi-cation, la non-implication des praticiens, l’absenced’engagement des utilisateurs et l’absence de lagestion du changement) interfèrent les uns avecles autres.

4. CONCLUSIONAu travers d’une analyse de publications dans ledomaine affirmant que plus de 50 % des projetsd’amélioration sont en échec, cette étude a per-mis de confirmer et de révéler l’existence d’unimportant pourcentage d’échecs ou de réussitespartielles. Ce résultat a été étayé par des infor-mations données par des participants lors desentrevues menées durant l’étude ; ces mêmes par-ticipants avaient constitué une base de données àpartir d’environ 45% de ces publications.

La méthode proposée consiste à élaborer unquestionnaire sur la base de cette revue de la litté-rature pour pouvoir guider les experts du domainedans leurs entrevues. Ces dernières ont conduit àmettre en évidence dix cas d’échec et de réussitepartielle en amélioration de processus logiciels.Après l’analyse de ces cas, il est ressorti une liste devingt facteurs d’échec regroupés selon les troisphases du cycle de vie du projet d’amélioration, àsavoir : pré-amélioration, amélioration et post-amé-lioration. L’un des facteurs d’échec les plus impor-tants est celui de la pérennité auquel nousrecommandons fortement d’améliorer continuelle-ment les processus logiciels afin de préserver lesavantages acquis à la suite du changement.



41

Remerciements : Les auteurs désirent remer-cier les experts suivants qui ont participé àcette étude : Messieurs Luc Bessette, Mar-tin Cloutier, Daniel Dutil, Denis St-Pierre etMarc Taillefer ainsi que d’autres experts quidésirent demeurer anonymes.

5. RÉFÉRENCES[1] P. Abrahamsson : The role of commitment in

software process improvement ; Doctoral dis-sertation, University of Oulu, 2002.

[2] Alain April et Alain Abran : Améliorer la main-tenance du logiciel ; Chapitre 4 du livre : Lesquestions et les problèmes initiaux reliés à l’uti-lisation de modèles d’amélioration des pro-cessus. Loze-Dion, Longueuil Québec, 2006.

[3] Nathan Baddoo et Tracy Hall : De-motivatorsfor software process improvement: an analy-sis of practitioners views ; The Journal of Sys-tems and Software 66 (2003), pp. 23-33.

[4] Anna Börjesson et Lars Mathiassen : Suc-cessful process implementation ; IEEE Soft-ware, volume 21, n° 4 (juillet 2004), pp. 36-44.

[5] Aileen P. Cater-Steel : Process improvementin four small software companies ; IEEESoftware Engineering Conference, 2001. Pro-ceedings. 2001 Australian, 27-28 août 2001,pp. 262-272.

[6] Aileen Cater-Steel : Software process eva-luation: Experience Report. Department ofInformation Systems, Faculty of Business,University of Southern Queensland, Too-woomba, Australie, Electronic Journal ofInformation Systems Evaluation, 5 (2), 2002.

[7] T. Chow et D. B. Cao : A survey study of cri-tical success factors in agile software pro-jects ; Journal of Systems and Software(2007), doi:10.1016/j.jss.2007.08.020.

[8] Capability Maturity Model Integration forDevelopment Version 1.2 ; Software Engi-neering Institute, Carnegie Mellon Univer-sity 2006).

[9] Crosstalk, The journal of defence softwareengineering, website : http://www.stsc.hill.af.mil/crosstalk.

[10] Darren Dalcher et Colin Tully : Learningfrom failures, software process improvementand practice ; Software Process Improve-ment and Pract, 2002, 7, pp. 71-89 (doi:10.1002/spip.15

[11] C. Debou : Goal-based software processimprovement planning ; in Better Software-Practice for Business Benefit: Principles andExperiences, R. Messnarz et C. Tully, Eds. LosAlamitos, Californie, IEEE Computer Society,1999.

[12] Tom DeMarco et Timothy Lister : People-ware Productive Projects and Teams ; DorsetHouse Publishing, 1987.

[13] Vinh Duong : Un questionnaire d’identifi-cation des facteurs de risques des pro-

grammes d’amélioration du processus logi-ciels basés sur le modèle CMM, janvier 2003,Rapport final d’activité de synthèse de laMaîtrise en informatique de gestion, Mont-réal, Université du Québec à Montréal.

[14] Khaled El Emam : A multi-method evalua-tion of the practices of small software pro-jects ; in International Research Workshop onProcess Improvement in Small Settings, Pitts-burgh, PA, SEI, Carnegie Mellon University,2005.

[15] D. Galin et M. Avrahami : Are CMM pro-gram investments beneficial; Analyzing paststudies, IEEE Software, volume 23, n° 6,nov.-déc. 2006, pp. 81-87.

[16] Suzanne Garcia, Caroline Graettinger et KeithKost : Proceedings of the First InternationalResearch Workshop for Process Improvementin Small Settings, 2005. CMU/SEI-2006-SR-001, Software Engineering Process Manage-ment, Pittsburgh, PA, SEI, Carnegie MellonUniversity, janvier 2006.

[17] Réal Gauthier : Une force en mouvement, LaBoule de Cristal ; Centre de Recherche Infor-matique de Montréal, 22 janvier 2004.

[18] Diane L. Gibson, Dennis R. Goldenson etKeith Kost : Performance Results of CMMI-based process improvement ; TechnicalReport CMU/SEI-2006-TR-004, Pittsburgh,PA, SEI, Carnegie Mellon University, 2006.

[19] D. Goldenson, T. Rout et A. Tuffley. « Mea-suring performance results in small settings:How do you do it and what matters most? ;Software Engineering Intitute, Carnegie Mel-lon University, 2006.

[20] David Gwillim, Ken Dovey et Bernhard Wie-der : The politics of post-implementationreviews ; Information Systems Journal (2005)15, pp. 307-319.

[21] Bill C. Hardgrave et Deborah J. Armstrong :Software process improvement: It’s a jour-ney, not a destination ; Communications ofthe ACM, vol. 48, 11, novembre 2005.

[22] Rick Hefner : The top ten reasons improve-ment efforts fail ; TRW, SEI SEPG Confe-rence, mars 1999

[23] James D. Herbsleb et Dennis R. Goldenson :A systematic survey of CMM experience andresults ; Proceedings of the 18th internationalConference on Software Engineering IEEE,1996, pp. 323-330.

[24] C. E. Hillam et H. M Edwards : A case studyapproach to evaluation of Information Tech-nology/Information systems (IT/IS) invest-ment evaluation processes within SMEs ;School of Computing and Engineering Tech-nology, University of Sunderland, UK. 6th

European Conference on the Evaluation ofIT Brunel University, novembre 1999.

[25] IEEE Software, website : http://www. com-puter.org/portal/site/software/



42

[26] Jorn Johansen, Mads Christiansen et MortenKorsaa : ImprovAbility™ Model. A new lookat process improvement and innovation ;Software Engineering Technology, Cross-Talk, vol. 20, n° 2, f évrier 2007, pp. 23-28.

[27] Jukka Kääriäinen, Juha Koskela, Pekka Abra-hamsson et Juha Takalo : Improving require-ments management in extreme programmingwith tool support – an improvement attemptthat failed ; Proceedings of the 30th EURO-MICRO Conference (EUROMICRO’04) IEEE.

[28] Karlheinz Kautz et Peter Axel Nielsen :Understanding the implementation of soft-ware process improvement innovations insoftware organizations ; Blackwell Publi-shing Ltd, Information Systems Journal14(1), pp. 3–22, 2004.

[29] C. Y. Laporte, S. Alexandre et R. V. O’Con-nor : A software engineering lifecycle stan-dard for very small enterprises ; in R. V.O’Connor et al. (réds.): EuroSPI 2008, CCIS16, pp. 129-141.

[30] O. Ngwenyama et P. A. Nielsen : Competingvalues in software process improvement: Anassumption analysis of CMM from an orga-nizational culture perspective ; IEEE Tran-sactions on Engineering Management, vol.50, pp. 100-112, 2003.

[31] Mahmood Niazi : Systematic review of orga-nizational motivations for adopting CMM-based SPI ; février 2006, NICTA TechnicalReport PA005957.

[32] Process Maturity Profile, Software CMM®2005 End-Year Update March, Pittsburgh,PA ; SEI, Carnegie Mellon University, 2006.

[33] Austen Rainer et Tracy Hall : Key successfactors for implementing software processimprovement: a maturity-based analysis ;Journal of Systems and Software, volume 62,n°2, 15 mai 2002, pp. 71-84.

[34] David F. Rico : Using cost benefit analysesto develop a pluralistic methodology forselecting from multiple prescriptive softwareprocess improvement (SPI) strategies ;30 avril, 1999 Submitted in Partial Fulfill-ment of Requirements for the Degree of Mas-

ter of Science in administration (SoftwareEngineering Administration).

[35] Robert Solon Jr. et Joyce Stratz : Benchmarkingthe ROI for software process improvement (SPI) ;Software Tech News 5(4) 2002, pp. 6-11.

[36] Software Process Improvement and Practice,Published by John Wiley and Sons. ISSN(printed): 1077-4866. ISSN (electronic): 1099-1670. website : http://www3.interscience.wiley.com/cgi-bin/jhome/15482.

[37] Mark Staples, Mahmood Niazi, Ross Jeffery,Alan Abrahams, Paul Byatt et Russell Murphy :An exploratory study of why organizations donot adopt CMMI ; The Journal of Systems andSoftware 80 (2007), pp. 883–895.

[38] Joyce Statz, Don Oxley et Patrick O’Toole :TeraQuest Metrics, Inc. : Identifying andmanaging the risks for software processimprovement ; Crosstalk, volume 10, n° 4,pp. 13-18, avril 1997.

[39] Dirk Stelzer et Werner Mellis : Success fac-tors of organizational change in softwareprocess improvement ; Software Process –Improvement and Practice, volume 4, n° 4,pp. 227-250, décembre 1998.

[40] Software Capability Maturity Model Version1.2. (Software Engineering Institute, Carne-gie Mellon University 1993) c’est un modèlepropre au développement logiciel, il a étéremplacé par le CMMI.

[41] Sylvie Tellier, Sylvie Trudel et Éric Lacroix :Les meilleures pratiques en développement delogiciels et de systèmes informatiques, CRIM,CEFRIO et développement économique etrégional Québec, publié par la direction descommunications et des services à la clien-tèle, septembre 2003.

[42] Haakon Ursin Steen : Reporting framework-based software process improvement. A quan-titative and qualitative review of 71experience reports of CMM-based SPI ; Mas-ter Thesis, written for the degree of candi-datus scientarium 29th of October 2004,Simula Research Laboratory & Departmentof Informatics University of Oslo, Norvège,www.simula.no.


Les lois des « modifs »Première loi : Une donnée entraînant la modification de la conception ne sera transmiseaprès, et seulement après, que les plans ont été entérinés.

Deuxième loi : Plus une modification semble mineure, plus elle aura d'impact et plus elle entraî-nera de changements.

Étude sur les cas d’échec ou de réussite partielle en amélioration de … · 2012-12-20 ·...

Documents

Transcript of Étude sur les cas d’échec ou de réussite partielle en amélioration de … · 2012-12-20 ·...