programme d’amélioration de la performance des processus … · 2012-12-20 · la performance...

G É N I E L O G I C I E L n N o 7 6 M A R S 2 0 0 6

PROCESSUS

17

1. INTRODUCTIONLes méthodes de développement logiciel structu-rées, tel que le Rational Unified Process® (RUP)3

de la société IBM, ont connu un essor importantces dernières années. Ces méthodes suscitent beau-coup d’enthousiasme et sont particulièrement effi-caces dans la résolution de problèmes d’ordre

général, tel que l’attribution des tâches, la docu-mentation et l’organisation des processus. Cepen-dant, ces méthodes ne peuvent fournir dessolutions à tous les problèmes surtout lorsque cesderniers sont propres à l’organisation et exigentune solution sur mesure [10]. Les gestionnairess’interrogent alors sur la manière de corriger ces

Programme d’améliorationde la performance des processuslogiciels dans une société d’État

québécoiseF R É D É R I C R H E A U L T E T C L A U D E Y . L A P O R T E

Résumé : Le but de cet article est de présenter une méthode structurée d’un programme d’amélioration dela performance des processus logiciels dans une société d’État québécoise. Notre hypothèse est qu’un pro-gramme a davantage de chances de réussite si les solutions sont orientées vers la correction de problèmes tan-gibles plutôt que vers l’atteinte d’un standard ou d’une norme de facto et s’il est basé sur des pratiques éprouvéesde l’industrie.

Ce travail a été réalisé en entreprise lors d’un programme d’amélioration des processus regroupant environ150 personnes réparties entre trois projets. Le modèle IDEALSM (Initiating, Diagnosing, Establishing, Acting &Learning)1 a servi de cadre de référence, l’approche orientée but (goal problem approach) complétait le modèleIDEALSM en décrivant les principales actions à entreprendre et comment les réaliser. Le Capability Maturity Model®

(CMM®)2 a été utilisé comme outil de référence puisqu’il regroupe de nombreuses pratiques éprouvées par l’in-dustrie. Les résultats du programme d’amélioration sont documentés dans : le diagnostic de la situation, de laproposition des solutions, dans le plan d’action et le rapport des leçons apprises.

Une évaluation similaire était effectuée, à grand coût, par une entreprise externe à l’organisation et le résultatobtenu par l’entreprise devait être comparé à celui de notre diagnostic. Les résultats des deux analyses ont étéprésentés à la direction du développement informatique de l’organisation. Devant la similitude des résultats, ladirection a accepté d’utiliser le diagnostic et la stratégie d’amélioration présentés dans ce travail.

Suite à la mise en place du plan d’action et de l’application des solutions, les principales conclusions sontles suivantes : 1) les pratiques recommandées par le CMM® ne doivent pas devenir la finalité du programmed’amélioration et la résolution des problèmes pour augmenter la performance de l’organisation doit demeurerl’objectif premier, 2) toujours obtenir le soutien et la participation de la direction et des employés avant mêmede démarrer un tel programme, 3) un diagnostic rigoureux prouvera le sérieux de la démarche et servira defondation à toute initiative d’amélioration, 4) le modèle IDEALSM joint à l’approche orientée but offre uneméthode complète pour la réalisation d’un programme d’amélioration.

t


PROCESSUS

18

problèmes et comment opérer les changementsdans l’organisation.

Ce travail expose une démarche structuréequi permettra de corriger graduellement les pro-blèmes liés à la performance des processus logi-ciels. La démarche discutée a été utilisée dans lecadre d’un programme de développement infor-matique majeur d’une société d’État québécoise.Afin de préserver la nature confidentielle du pro-jet, ni le nom de la société d’État, ni le nom desparticipants ne seront indiqués. Le programmevise l’intégration de tous les systèmes d’infor-mation de la société et du développement desapplications logicielles. Environ 150 personnestravaillent au développement des différentsmodules qui composeront le système d’informa-tion. Ce système d’information comprendra 12modules qui couvriront la plupart des opérations(approvisionnement, livraison, production, fac-turation, finance, comptabilité, etc.) de l’entre-prise. La société prévoit déployer tous les modulesà l’intérieur d’une période de 5 ans. Le présenttravail couvre le développement des applicationsde finance et de compatibilité. L’organigrammedu projet finance/comptabilité est présenté à lafigure 1. L’équipe de projet est composée d’unchef de projet et d’un contrôleur de projet (PCO,Project Control Officer).

problèmes majeurs ont été identifiés et ont étésolutionnés grâce à l’implantation de la méthodeRUP®. De plus, suite à l’analyse post mortemd’un projet précédent, des ajustements étaientnécessaires dans certains domaines : • Exigences exprimées de manière insatisfaisante.• Communication entre les analystes et les déve-

loppeurs imprécise et ambiguë.• Architecture trop complexe.• Incohérence entre les exigences, la conception et

l’implantation.• Propagation incontrôlée des changements.

Face à cette situation, l’organisation a décidéde mettre en place un programme d’améliorationde la performance des processus logiciels(PAPPL). Le présent travail a été mené durantcette initiative et a pour but de décrire la méthodeemployée lors du programme d’amélioration. Letravail a contribué au programme en posant lesactions suivantes : • Fournir un cadre de travail au travers duquel le

programme évolue.• Soutenir le programme en exposant les pratiques

éprouvées afin que le programme repose sur desfondements reconnus.

• Collecter l’information telle que la liste des pro-blèmes, des causes et des conséquences des pro-blèmes auprès des intervenants, analyser lesrésultats obtenus aux différentes étapes du pro-gramme et présenter les résultats aux dirigeantsen fonction de modèles et d’approches théo-riques.

• Proposer des solutions pratiques et participer àleur implantation.

La méthode de travail choisie pour atteindreces objectifs repose sur les éléments suivants : lemodèle IDEALSM (Initiating, Diagnosing, Establi-shing, Acting & Learning) qui a servi de cadre deréférence et sur l’approche orientée but [16] quicomplète le modèle IDEALSM en détaillant lesmoyens à employer pour réaliser les phases dumodèle IDEALSM. Les solutions proposées pourcorriger la situation s’inspirent des pratiques del’industrie telles que décrites par le CapabilityMaturity Model® (CMM®). Les résultats de ceprojet d’amélioration se retrouvent dans les docu-ments suivants : le diagnostic de la situation, laproposition des solutions, le plan d’action et le rap-port des leçons apprises. Des extraits de ces docu-ments seront présentés dans les sections ci-dessous.

2. CHOIX DE L’APPROCHEIl existe plusieurs approches de l’amélioration dela performance des processus mais deux d’entreelles apparaissent comme les plus populaires maispas nécessairement les plus efficaces.

La première approche consiste à documentertout le processus de développement de manière

Figure 1 : Organigramme du projet

Jusqu’à tout récemment (2004), le processusde développement de la société d’État était orga-nisé sous la forme d’une usine à logiciels (softwarefactory). Une usine à logiciels fonctionne selonle principe de la sous-traitance. Un groupe, consi-déré comme le client, transmet les exigences etvérifie la qualité du produit alors qu’un autregroupe, considéré comme l’usine, s’occupe exclu-sivement du développement et du déploiement.Trois projets, dont celui discuté dans cet article,transmettaient les exigences à un centre de déve-loppement qui se chargeait de développer les logi-ciels. Cependant, suite à des résultats peusatisfaisants tel que le dépassement des échéan-ciers et des coûts, la qualité du produit insatisfai-sante, l’entreprise a décidé d’adopter un mode dedéveloppement plus traditionnel en intégrant lesmembres de l’usine, les concepteurs et les codeurs,à l’intérieur des projets.

Durant la même période, le groupe d’ingé-nierie des processus logiciels (SEPG) travaillait àla mise en place de la méthode RUP® afin de stan-dardiser le processus de développement. Plusieurs

t


PROCESSUS

19

détaillée. Le principe est le suivant : si les pra-tiques sont bien documentées, elles pourront êtrecommuniquées et elles s’imposeront d’elles-mêmes en tant que pratiques éprouvées ou bonnespratiques. Quand tout le personnel d’une mêmeorganisation aura adopté ces pratiques, le pro-blème lié à la qualité des livrables sera résolu. Iln’est pas facile d’identifier les problèmes que ces« meilleures pratiques » sont censées corriger.D’une part, peu d’évaluation est faite pour savoirquelle pratique est réellement la meilleure et,d’autre part, il n’y a pas de forum pour partagerl’expérience acquise dans ce domaine. Cetteapproche résulte en une quantité de documentsqui est laissée de côté parce qu’elle est trop lourdeà supporter.

Dans une seconde approche, l’organisations’engage à se conformer à un standard tel qu’ISO9001 ou un modèle tel que le CMM® développépar le SEI. Dans l’optique où l’entreprise désire,par exemple, « atteindre le niveau 3 endécembre », le but premier du programme d’amé-lioration sera alors de rédiger des procédures expli-quant comment la compagnie devra opérer. Étantdonné que le but du niveau 3 est de documenter leprocessus, les organisations croient qu’en forçantla mise en place de procédures et de documenta-tion les bénéfices se réaliseront d’eux-mêmes. Lerésultat est habituellement un mélange de béné-fices, de frustration et de papier [7].

Ces deux approches peuvent mener à des amé-liorations concrètes pour l’organisation. Mais ellescomportent un risque élevé d’échec, car ellesencouragent les équipes à viser des objectifs (c’est-à-dire la documentation des processus) qui sontsecondaires par rapport aux problèmes quotidiens.Le succès de ces approches dépend de l’habiletéde l’auteur à communiquer ses idées à travers lesdocuments qu’il produit. Aussi, si la communica-tion n’est pas adéquate entre l’émetteur du docu-ment et le récepteur de celui-ci, et c’estgénéralement le cas, alors le programme d’amé-lioration échouera.

L’approche alternative est de lier chaque acti-vité d’amélioration aux objectifs d’affaires et auxproblèmes de l’organisation. Toute améliorationdoit viser un problème réel de l’organisation. Leprogramme d’amélioration n’est pas organisé enfonction de l’atteinte d’un standard ou de l’im-plantation d’une quelconque méthode mais bien enfonction des objectifs et des problèmes de l’or-ganisation. La méthode que nous avons choisies’inspire principalement du modèle « IDEAL: AUser’s Guide for Software Process Improvement »[13], et de l’ouvrage : Making Process Improve-ment Work [16]. On trouve dans le tableau 1 unexemple d’une grille d’évaluation de l’approcheorientée vers les buts.

La méthode décrite dans ce travail conduitl’entreprise à s’intéresser à des problèmes quoti-diens que la direction et les employés désirent éli-miner. Des actions sont continuellement prisesafin que l’entreprise atteigne ses objectifs d’af-faires. Les améliorations apportées au processussont ainsi assimilées graduellement et chaqueaction répond directement à un problème de l’or-ganisation. Le résultat de ce type de programmed’amélioration est mesuré par des gains notablesde la qualité et de la productivité et non par laquantité de documentation créée ou le niveauCMM atteint.

La démarche utilisée dans le cadre de ce tra-vail est similaire aux démarches d’améliorationentreprises par les sociétés telles Bombardier,CAE Électronique, Keops Informatique, Lock-heed Martin, Oerlikon Aerospatiale et Spar Aero-spatiale. Ces sociétés avaient pour but d’augmenterla qualité et la productivité du développement etde l’entretien de logiciels. C. Laporte [11] sou-ligne que le Modèle d’évolution des capacités(CMM®) a été utilisé avec succès par ces entre-prises pour l’évaluation des programmes d’amé-lioration. L’auteur [12] précise aussi que lesactions suivantes ont eu un impact important surle succès d’un programme d’amélioration :

Tableau 1 : Exemple d’une grille d’évaluation de l’approche orientée vers les buts

(Les acronymes SPP, RM, etc. sont les acronymes des domaines de processus du CMM. Par exemple, l’acronyme RM signifie Requirements Management)

Tableau 2 : Actions ayant un impact important.

Le modèle d’évolution des capacités CMMLe Modèle d’évolution des capacités

(CMM®) logiciel est un cadre décrivant les élé-ments essentiels d’un processus logiciel efficace[14]. Ce modèle sera utilisé pour évaluer la situa-tion présente et pour proposer des recommanda-tions. Le CMM® décrit, étape par étape, lecheminement depuis un processus improvisé versun processus optimisé.

Le CMM® constitue ainsi un guide pourl’amélioration des pratiques en matière de déve-loppement et de maintenance du logiciel. Les pra- t


PROCESSUS

20

tiques du CMM® (exemple : gestion des exigences,gestion de projet, revue par les pairs, etc.) exprimentles meilleures façons de travailler pour produiredes logiciels de qualité tout en respectant les bud-gets et les délais [2].

Les pratiques clés sont ordonnées par phase, dela plus rudimentaire jusqu’à la plus élaborée. LeCMM® permet donc d’établir un standard par rap-port auquel il est possible de mesurer la maturité duprocessus logiciel et de le comparer à l’état de lapratique de l’industrie (benchmarking) [9]. LeCMM® peut également être utilisé par l’organisa-tion pour orienter le programme d’amélioration enidentifiant les forces et faiblesses du processus.

Le modèle d’amélioration IDEALSM

Le modèle IDEAL [13], développé par le Soft-ware Engineering Institute, est un cadre de réfé-rence pour la planification et la gestion desprogrammes d’amélioration. Ce modèle sera uti-lisé pour nous assurer d’avoir une méthode struc-turée et complète. Le modèle est constitué des cinqphases suivantes :1. Phase d’initiation : Apprendre le processus

d’amélioration, octroyer les ressources initiales,construire l’infrastructure du processus.

2. Phase de diagnostic : Évaluer la situationactuelle, proposer des recommandations, démar-rer un plan d’action.

3. Phase de planification : Établir les objectifs etles priorités, compléter le plan stratégique &tactique

4. Phase d’action : Rechercher et développer dessolutions aux problèmes actuels. Étendre lesréussites au reste de l’entreprise.

5. Phase de bilan : Dresser une liste des leçonsapprises. Préparer le prochain cycle.

Par exemple, la phase d’initiation, souventoubliée par les néophytes en amélioration, décrit lesactivités pour mettre en place l’infrastructured’amélioration.. On définit les rôles et les respon-sabilités tels que le groupe de direction (Manage-ment Steering Group MSG) et le grouped’ingénierie des processus (Software EngineeringProcess Group SEPG). C’est aussi lors de cettephase que les ressources sont assignées. En fonctiondes besoins d’affaires, une première ébauche duplan d’amélioration est établie. Un élément cri-tique au succès de la démarche d’amélioration estl’engagement de la direction. Cet engagement estdémontré par l’approbation des budgets néces-saires, l’assignation de ressources qui sont norma-lement assignée à un autre projet de l’organisation,l’approbation d’un échéancier et la participationaux réunions de suivi de la démarche.

Dans les sections suivantes, on décrira chacunedes phases du projet d’amélioration mené dans lasociété d’État québécoise selon le modèle IDEAL.

3. PHASE D’INITIATION DU MODÈLE IDÉALLa phase d’initiation sert à établir l’infrastructurequi supportera le Programme d’amélioration dela performance des processus (PAPPL). L’infra-structure quant à elle sert à développer et institu-tionnaliser le processus d’amélioration. Durantcette phase, il est question d’évaluer la nécessitéet la faisabilité du PAPPL, de former les équipeset d’attribuer les rôles et les tâches.

3.1 LANCEMENT DU PROGRAMME D’AMÉLIORATION

Objectif : Rassembler l’information nécessaire àla rédaction de la proposition initiale du pro-gramme d’amélioration des processus.

Tâches :• Former l’équipe d’amélioration et déterminer les

rôles. a- Membre de la directionb- Membre du SEPG (Software Engineering Pro-

cess Group)c- Analyste

• Évaluer le climat organisationnel pour un pro-gramme d’amélioration.

• Identifier les initiatives ou les politiques de l’or-ganisation pouvant influencer le PAPPL.

• Sélectionner une stratégie qui satisfasse les besoinsdes dirigeants et des employés.

3.2 FORMER L’ÉQUIPE ET DÉTERMINER LES RÔLES

Un plan d’amélioration nécessite la désignation d’unepersonne responsable. Idéalement, cette dernière seral’utilisateur du plan et souvent la personne à quiincombe d’établir les objectifs d’affaires. Il faut doncidentifier rapidement cette personne afin de s’assu-rer que le plan répond à ses besoins. Il n’est pasrecommandé d’attendre d’avoir un plan completavant de trouver un responsable, car il y a un risquede ne pas trouver preneur. Il est préférable de consul-ter les gestionnaires de projets, les gestionnairesseniors ou des responsables de division afin deconnaître leurs besoins, de construire l’ébauche d’unplan et d’établir les objectifs conjointement.

Le groupe d’ingénierie des processus logi-ciels (SEPG) ne devrait pas être le responsabledu projet, car ses membres ne sont pas directe-ment affectés par l’atteinte des objectifs d’af-faires. Ils devraient cependant fournir le supportnécessaire sur le plan technique.

3.3 ÉVALUER LE CLIMAT ORGANISATIONNEL POUR UN

PROGRAMME D’AMÉLIORATION

La probabilité que l’initiative soit acceptée parles collègues et les supérieurs doit être évaluée ;il est suggéré de dresser une liste des facteurs quijoueront en faveur et ceux qui seront nuisibles audémarrage du PAPPL :

Les éléments positifs sont :• Objectifs d’affaires identifiés.

t


PROCESSUS

21

• Support de la direction pour la standardisationdes processus.

• L’atteinte du CMM® niveau 3 pourrait démon-trer l’efficacité du service de développementlogiciel lors de l’élaboration des prochains bud-gets.

• Organisation bien structurée avec un SEPG quisupporte le processus.

• Motivation du personnel à améliorer la situation.• Coût de gestion du projet d’amélioration peu

élevé.

Les éléments négatifs sont :• Processus relativement instable et immature.• Problèmes reliés au développement de logiciels

(par exemple budget, échéancier, qualité)• Le personnel est continuellement en apprentis-

sage et les changements déjà en cours sont rela-tivement nombreux.

• Les améliorations éventuellement apportées auprocessus sont considérées comme des risquespar les gestionnaires de projet, qui ont leurpropre méthode et qui sont plutôt réfractairesau changement.

• Peu de planification au niveau des améliorationsà moyen et long terme ; le SEPG se contentant« d’éteindre les feux ».

Afin d’évaluer immédiatement l’intérêt de ladirection et du gestionnaire de projet pour unetelle initiative, il est recommandé d’informer l’en-tourage de la situation et de l’intention de propo-ser un PAPPL. Une lettre peut être distribuée parcourriel à cet effet. Il est important de tâter le ter-rain immédiatement pour savoir comment pro-mouvoir le PAPPL et connaître les acteurs quisupporteront la démarche.

3.4 ÉVALUER LES BESOINS D’AFFAIRES

Objectif : Comprendre du point de vue du mana-gement, les besoins d’affaires qui soutiendront lePAPPL.

Tâches : • Identifier les besoins d’affaires• Interviewer les gestionnaires pour collecter leurs

besoins.• Déterminer comment le programme peut satis-

faire ces besoins.

Il existe habituellement plusieurs raisons dedémarrer un PAPPL mais elles sont rarement ali-gnées sur les besoins d’affaires [16]. Dans le casétudié ici, les besoins d’affaires ont été identifiéspour que le programme ait une valeur évidentepour les dirigeants. Les besoins d’affaires sui-vants ont été identifiés :• L’importance de livrer un système opérationnel

dans un délai précis oblige l’organisation à adop-ter des mesures pour améliorer l’efficacité duprocessus.

• La nécessité pour l’organisation de dégagerdavantage de bénéfices laisse croire que lesdépenses en informatique seront réduites. Or, ilest impératif de démontrer que la situation (pro-cessus) est maîtrisée et que des mesures sont enplace afin de s’assurer de l’efficacité des dépar-tements malgré les problèmes passés.

• Stabiliser le processus de développement etdévelopper un cadre structuré afin de limiterl’apparition répétée des mêmes problèmes.

3.5 CONSTRUIRE UNE PROPOSITION

Objectif : Construire la proposition initiale quiexpliquera le pourquoi et le comment du projet.

Tâches : • Identifier les participants• Déterminer les objectifs• Discuter de la méthode utilisée pour mener à

terme le PAPPL.• Établir un plan de haut niveau

Le tableau ci-dessous présente un exemple deproposition initiale qui a été utilisée pour exposerles grandes lignes et les objectifs du programmeaux différents intervenants.

Tableau 3 : Exemple de proposition d’échéancier

3.6 ÉDUQUER ET OBTENIR LE SUPPORT

Objectif : Informer les participants de la démarched’amélioration entreprise et susciter de l’intérêtpour le projet.

Tâche : • Faire un briefing : communiquer la proposition

à l’organisation

Un courriel a été envoyé aux membres du pro-jet pour les informer de la proposition et, par lasuite, la communication directe avec les autresemployés a permis de bâtir un engagement suffi-sant pour l’étude. Une brève présentation a aussiété faite aux dirigeants afin de leurs donner unevue d’ensemble du projet. t


PROCESSUS

22

3.7 OBTENIR L’APPROBATION DU PROGRAMME D’AMÉ-LIORATION

Objectif : Obtenir l’engagement officiel de ladirection pour le PAPPL.

Tâches : • Présenter la proposition• Obtenir l’approbation

Ce projet a tout d’abord été présenté au SEPG.Il s’agissait tout d’abord d’établir un diagnosticpour déterminer :• les problèmes,• leurs causes,• les conséquences.

Au même moment, une évaluation similaire étaiteffectuée, à grand coût, par une entreprise externe àl’organisation et le résultat obtenu par l’entreprisedevait être comparé à celui de notre diagnostic. Lesrésultats des deux analyses ont été présentés à ladirection du développement informatique de l’or-ganisation. Devant la similitude des résultats, ladirection a accepté d’utiliser le diagnostic présentédans ce travail afin d’orienter les actions du SEPGvisant l’amélioration du processus.

Certains points sont importants à retenirlorsque l’on désire introduire un programmed’amélioration :

diaires et par les discussions fréquentes entre lesemployés concernant les manières d’améliorer lesprocessus. Tous les employés savent qu’ils peuventcontribuer à l’étude et que leurs commentairessont considérés par la direction.

Encourager le partage d’information - Voicicertaines actions qui ont été entreprises pour dif-fuser l’information :• Encourager tous les employés à faire parvenir de

l’information pouvant contribuer à l’étude. Pro-fiter de l’expérience et des connaissances desemployés a permis de recueillir quantité d’infor-mations (pratiques et théoriques).

• Faire des rencontres formelles et informelles pourdiscuter des manières d’améliorer le processus :recueillir les commentaires et diffuser l’infor-mation sous forme de courriel.

• Rendre disponibles les documents du projet, telque le diagnostic, sur le réseau corporatif. Lesparticipants peuvent voir l’évolution du pro-gramme et obtenir la confirmation que leurs com-mentaires sont intégralement transmis.

Résumé - Les objectifs de cette phase sontatteints si l’infrastructure a été définie en termesde participants, de rôles et de responsabilités. L’in-frastructure doit être en place et opérationnelle. Laplupart des activités de cette phase devront êtrecontinuellement ajustées durant le PAPPL.

4. PHASE DE DIAGNOSTICSELON LE MODÈLE IDÉAL

Le diagnostic présente la situation actuelle de l’or-ganisation. Cette évaluation (baseline) est essen-tielle pour affecter des priorités aux actions etpour développer le plan d’action. Le diagnosticinforme de la performance actuelle du processusainsi que de ses forces et faiblesses.

4-1 INFORMATION NÉCESSAIRE AU DIAGNOSTIC

Tâches : • Déterminer les informations nécessaires pour le

diagnostic.• Documenter les problèmes avec leurs causes, consé-

quences et impacts• Préparer une grille pour les réponses• Préparer une liste de questions si l’interviewé ne

perçoit pas de problème a priori [4]. Le tableau ci-dessous donne quelques exemples de questions uti-lisées lors des interviews.

• Rencontrer au moins un représentant de chaquemétier (durée de chaque rencontre : 1 heure).

3.8 ÉTABLIR L’INFRASTRUCTURE DU PROGRAMME D’AMÉ-LIORATION

Tâches :• Établir le groupe de direction (Management Stee-

ring Group – MSG).• Établir le groupe d’ingénierie des processus

(SEPG).• Maintenir la visibilité.• Encourager le partage et la diffusion de l’infor-

mation.

Établir un groupe de direction : Un groupeest formé du directeur au développement des sys-tèmes et du responsable de service (responsabledes trois projets formant le programme). Le res-ponsable du SEPG fait aussi partie du groupe. L’im-plication des gestionnaires de projets n’est pasnégligeable puisqu’ils ont habituellement le pouvoirde mettre en œuvre ou non le changement.

Maintenir la visibilité : La visibilité est main-tenue par la diffusion des diagnostics intermé- Tableau 4 : Exemples de questions utilisées lors des entrevues

t


PROCESSUS

23

4.2 PLAN DU DIAGNOSTIC

Tâches : • Documenter la méthode pour procéder à l’éva-

luation initiale (voir Chapitre 5 : Méthode dediagnostic)

• Déterminer les ressources nécessaires pour l’ef-fort d’évaluation. Les ressources consultées ontété les suivantes :

5. MÉTHODE DE DIAGNOSTICL’approche choisie débute par l’identification desobjectifs d’affaires [5] pour ensuite révéler lesproblèmes qui empêchent d’atteindre ces objectifs.Le diagnostic permet d’avoir une idée de l’étatactuel de la situation (baseline). La liste des objec-tifs d’affaires sera établie en discutant avec lesdirecteurs et les problèmes seront découverts enquestionnant les participants des projets. Pourdémarrer la discussion, la direction établit la listedes objectifs à atteindre durant les 6-18 prochainsmois. Ensuite, les participants énumèrent les prin-cipaux problèmes qu’ils rencontrent. À cette étape,les problèmes qui empêcheront l’atteinte desobjectifs sont déjà cernés. Ce lien entre les objec-tifs d’affaires et les obstacles permet d’affecterdes priorités aux problèmes et d’orienter le pland’action. Voici une liste d’objectifs d’affaires del’organisation identifiés par la direction : • Établir des planifications réalistes à +/- 10%• Livrer avec succès le produit Acme (nom fictif)• Réduire la quantité de travail repris à +/- 10%• Améliorer la performance de nos produits vedettes• Conserver notre clientèle• Continuer à faire des profits

L’entrevue est l’occasion d’identifier les causeset les conséquences des problèmes. Chaque détailest important ; aussi ne faut-il pas négliger de notertous les points soulevés et toutes les informationsrecueillies. Si les explications doivent être clari-fiées, il ne faut pas hésiter à questionner, à connaîtrele ou les « pourquoi ? » de cet état de choses [16].À ce stade, il n’est pas impératif de catégoriser l’in-formation, à savoir s’agit-il d’un problème, d’unecause ou d’une conséquence ; le recueil d’infor-mation est suffisant à cette étape.

5.1 PARTICIPATION DE LA DIRECTION

Les gestionnaires de haut niveau doivent com-prendre et agir en fonction de cinq principes [18] :• Établir une vision d’une organisation améliorée• Démontrer leur engagement par des actions

concrètes posées « dans le feu de l’action »• Obtenir le soutien des autres gestionnaires• Octroyer les ressources• Corriger activement les lacunes au niveau orga-

nisationnel

Ces principes se traduiront par un comporte-ment conséquent des gestionnaires qui affectera lecours des projets. Le gestionnaire prêchera parl’exemple et accordera ses actions avec sesparoles. Des actions concrètes vont convaincreles employés de donner leur appui au projet etempêcheront les éléments résistants de fairedérailler l’initiative.

5.2 PARTICIPATION DES EMPLOYÉS

C’est à cette étape que les solutions sont présen-tées aux participants des projets. Il est impératif

4.3 PROCÉDER À L’ÉVALUATION

Tâches : • Interviewer les membres de l’équipe de déve-

loppement• Revoir et analyser les procédures et lignes direc-

trices• Valider les informations recueillies avec les par-

ticipants• Envoyer par courriel des rapports d’entrevue et

collecte des commentaires des participants.

4.4 PRÉSENTER LES RÉSULTATS DE L’ÉVALUATION

Tâche : Préparer un briefing présentant laméthode, les sources de données, les forces et fai-blesses ainsi que les prochaines étapes

4.5 RÉDIGER LE RAPPORT FINAL

Tâche : Rédaction du rapport final. Diagnostic del’organisation. Présenter le diagnostic qui a été effec-tué dans l’organisation concernée. Par exemple, ence qui concerne l’objectif d’affaires livrer à tempsles projets en cours à +/- 10% de l’échéancier, les élé-ments suivants ont été identifiés :

4.6 COMMUNIQUER LE RÉSULTAT À L’ORGANISATION

Cette activité est pratiquée afin de maintenir l’ap-pui pour le projet et d’obtenir un consensus avantl’étape suivante.

Tâches : • Préparer un briefing.• Envoyer un courriel avec le diagnostic final• Rencontrer le chef de projet pour présenter les

résultats du diagnostic

Tableau 5 : Exemple de problèmes reliés aux objectifs d’affaires

t


PROCESSUS

24

d’établir une relation de confiance. Le fait queleurs problèmes aient été considérés, qu’ils ontété écoutés et que le « pouvoir » de changer lasituation leur est donné entraînera que le PAPPLsera perçu positivement par la majorité desemployés. Souvent les employés émettront desopinions ou des idées qu’ils n’oseront pas soule-ver auprès de leurs supérieurs. Il faut tirer avan-tage de ces occasions pour approfondir lesproblèmes et les lacunes qui sont rarement discu-tés ouvertement lors des réunions.

5.3 REGROUPER LES PROBLÈMES ET LES OBJECTIFS

Pour mieux comprendre l’importance des pro-blèmes, il est suggéré de les regrouper sous lesobjectifs d’affaires visés. Si un problème ne peutêtre associé à un objectif et qu’il semble relati-vement peu important, il peut être laissé de côté.Remarquez qu’en compilant les différents pro-blèmes de l’organisation, certaines personnes seretrouvent responsables de sections complètes duplan d’action. Par exemple, si le service du mar-keting est interrogé, l’engagement auprès du clientsera probablement souligné, tandis que le ges-tionnaire de projet traitera de la planification etl’analyste de la gestion des exigences. Ces per-sonnes communiquent les problèmes qui les affec-tent et désirent que des progrès soient réalisésdans leurs domaines respectifs.

5.4 CLARIFIER LES PROBLÈMES ET LES OBJECTIFS

Pour que les problèmes et les objectifs soient signi-ficatifs aux yeux des gestionnaires, il est parfoisnécessaire de les reformuler ou de les vulgariser.Ainsi, concernant des informations provenant duservice des ressources techniques, le langage etles termes utilisés sont souvent inconnus des ges-tionnaires. Pour éviter des erreurs d’interpréta-tion, il vaut mieux reformuler et décrire lesproblèmes identifiés et ne pas hésiter à utiliserdes exemples. Les objectifs doivent aussi êtrequantifiés si possible afin de mesurer éventuelle-ment leur réalisation.

Pour que l’organisation soutienne les effortsdéployés à l’amélioration des processus, il estimpératif de démontrer que le changement résou-dra des problèmes critiques qui mèneront à l’at-teinte d’objectifs prioritaires.

Autre point : il faut se méfier des percep-tions. Si, lors d’un entretien, un employé dit :« la méthode est trop lourde », il ne faut pasprendre pour acquis qu’il s’agit là du véritableproblème. Demandez : « Pourquoi ? » ; on vousrépondra peut-être : « il y a trop de documenta-tion ». Lorsqu’il n’y aura plus d’explication au« Pourquoi ? », il est fort probable que la cause duproblème sera identifiée. Le diagnostic porteraalors sur des faits et non sur de simples percep-tions. Ne pas confondre cause, problème et consé-

quence : la conséquence est habituellement asso-ciée à la perception puisqu’elle est directementobservable.

5.5 AFFECTER DES PRIORITÉS ASSIGNÉES

AUX PROBLÈMES

Affecter des priorités aux problèmes servira àorienter la stratégie du plan d’action. Procéder dela manière suivante : pour chaque étape, utilisezune échelle de 1 à 5 (1 = faible et 5 = élevé). Sides données spécifiques (exemple : revenus, pro-fits, coûts, efforts) sont disponibles pour une étape,ces données doivent être utilisées plutôt que desnombres relatifs. Réviser les estimés au fur et àmesure que le plan d’action s’affine. Les tableauxsuivants illustrent le résultat de cette démarchepour quelques-uns des constats effectués.

Tableau 6 : Exemple des priorités assignées à la diminutiondes reprises

5.6 CHOIX DES MESURES DES OBJECTIFS

Pour déterminer l'atteinte des objectifs, uneméthode pour mesurer le progrès accompli aucours du programme doit être retenue. Larecherche d'unités de mesure oblige à reconsidé-rer nos objectifs et à réfléchir aux activités decontrôle du plan d'action.

V. Basili [1] propose une approche, Goal-Question-Metric (GQM), afin d'identifier correc-tement les mesures qui conviennent à chaqueobjectif. Il recommande : « d'identifier les objec-tifs, de choisir un ensemble de questions qui, lors-qu'elles sont répondues, indiquent les progrèsréalisés, afin de définir et de recueillir les don-nées pour répondre à ces questions ». Le tableauci-dessous illustre ceci.

Tableau 7 : Exemple des priorités assignées à la mesure des objectifs

6. PHASE DE PLANIFICATIONSELON LE MODÈLE IDÉAL

L’établissement d’un plan d’action stratégique estune étape critique à l’intérieur du programmed’amélioration des processus logiciel (PAPPL).

t


PROCESSUS

25

C’est durant cette phase que l’on développe leplan en se basant sur la vision, le plan d’affaireset les ressources approuvées pour améliorer leprocessus.

Il n’est pas recommandé de déléguer cettephase au SEPG. Il faut tout d’abord s’assurer del’appui des gestionnaires supérieurs et ensuitetrouver le soutien dans le groupe de travail. Dansle cadre de ce projet, le support du groupe estdéterminant puisque le changement s’opère à labase avec les employés. Le diagnostic sert deforum où il est possible de formuler des opinions,d’émettre des suggestions, bref d’être entendu.

6.1 SÉLECTIONNER UNE MÉTHODE DE PLANIFICATION

Le but de cette activité est double : 1) choisir uneapproche pour la planification du programmed’amélioration et 2) développer des habiletés degestion pour établir un plan solide qui servira debase au programme.

Tâches :• Revoir les besoins de planification• Sélectionner une approche• Réviser les méthodes déjà en place

6.2 REVOIR LA VISION DE L’ORGANISATION

Tâches :• Modifier ou générer une nouvelle vision si les

gestionnaires jugent que la vision actuelle n’estpas adéquate

• Identifier les buts pour le programme d’amé-lioration

• Identifier les motivations basées sur la vision• Revoir l’impact de la nouvelle vision

À l’origine, le système informatique qui étaitdéveloppé par l’organisation (et sur lequel le pré-sent travail repose) devait à la fois être utilisé à l’in-terne par l’organisation et, par la suite, êtrecommercialisé. Aussi, pour le commercialiser, l’or-ganisation avait mis en place une structure de type« usine à logiciel » où différents projets recueillentles exigences propres à leur système et sous-trai-taient le développement à « l’usine », principale-ment formée de concepteurs et de codeurs. De plus,l’organisation privilégiait un mode de développe-ment par composants, ce qui représentait un défipour la conception et le développement.

Après une période d’essai, devant l’ampleurde la tâche et les difficultés rencontrées, la direc-tion décidait de redéfinir l’envergure du pro-gramme. La commercialisation du logiciel étaitabandonnée, le groupe de conception et dévelop-pement était intégré aux différents projets et l’im-portance du développement par composantmulti-plates-formes était reconsidérée. Ce travailexamine l’impact de ces changements et évalueles problèmes liés à la structure (usine).

6.3 REVOIR LE PLAN D’AFFAIRES DE L’ORGANISATION

Tâches :• Modifier ou rédiger un nouveau plan d’affaires

si le plan présent n’est pas adéquat• Identifier les objectifs d’affaires du programme

d’amélioration

Les objectifs d’affaires ont été modifiés par lechangement de vision :• L’idée de commercialiser le logiciel est abandon-

née.• L’accent est mis sur la livraison : il est impératif

de livrer un logiciel opérationnel dans les délaisprévus.

• La méthode et le choix des processus ne sont plusexclusivement la responsabilité du SEPG maisaussi des projets qui peuvent les adapter à leursbesoins afin de respecter les échéanciers.

Tous les efforts doivent être faits afin d’ob-tenir des résultats à court terme et d’alléger leprocessus dans le but de diminuer la durée ducycle de développement et d’obtenir rapidementune application opérationnelle.

6.4 DÉTERMINER LES ENJEUX D’AFFAIRES

Tâches :• Développer des critères pour le lancement du

programme d’amélioration basés sur les enjeuxd’affaires

• Revoir les enjeux à court terme et à longterme

Dans le présent cas, il est évident que touteamélioration doit avoir un impact à court terme.Puisqu’il est impératif de livrer les systèmes dansles délais prévus, les effets des améliorations doi-vent être perçus dès leur application sans quoielles seront vues comme un fardeau. La marge demanœuvre est mince et lesdites améliorationsdevront cibler des problèmes précis.

Enjeux à court terme :• Livrer un logiciel opérationnel• Respecter le calendrier de livraison• Satisfaire les besoins des utilisateurs en interne• Alléger le processus de développement.

Enjeux à long terme :• Maîtriser le processus de développement pour

être capable de le répéter• Bâtir des mesures pour améliorer la capacité

d’estimer et de planifier• Augmenter la productivité des employés.

6.5 REVOIR LES AMÉLIORATIONS PASSÉES

Typiquement, les gens répètent les mêmes com-portements, qu’ils soient bons ou mauvais. L’or-ganisation doit s’assurer que les erreurs du passéne sont pas répétées et que les initiatives proposéessont suivies et évaluées. t


PROCESSUS

26

Tâches :• Définir une stratégie pour gérer les barrières qui

ont gêné les efforts d’amélioration par le passé• Identifier les changements réussis et les échecs

Le Chapitre 11 présente l’analyse post mortemd’un projet mené antérieurement au programmed’amélioration. Les recommandations issues decette analyse qui ont été suivies y sont indiquées.Celles concernant des améliorations qui ont étéprises en compte, jusqu’à maintenant, ont été per-çues comme bénéfiques au processus.

6.6 DÉCRIRE LES MOTIVATIONS À S’AMÉLIORER

Tâches :• Décrire les motivations requises pour passer de

la situation actuelle à celle désirée• Documenter les motivations dans le plan stra-

tégique d’amélioration• Lier les motivations aux problèmes et aux objec-

tifs. Les motivations des gestionnaires à amé-liorer le processus sont les suivantes :

• Augmenter la productivité des employés• Ajuster le processus de manière proactive plutôt

que réactive• S’assurer de ne pas répéter les erreurs passées et

que les changements sont bénéfiques• Démontrer aux employés qu’il existe une vision

et un plan en vue d’améliorer la situation• Prouver à la haute direction que la situation est

maîtrisée et que des progrès tangibles sontconstamment réalisés.

6.7 IDENTIFIER LES EFFORTS D’AMÉLIORATION PRÉSENTS

ET FUTURS

Tâches :• Identifier les efforts en place ou anticipés• Estimer les ressources pour le déploiement des

actions du plan d’amélioration• Estimer le nombre de ressources prêtes à parti-

ciper aux améliorations

Les efforts d’amélioration sont habituellementnombreux dans les organisations dont les processusn’ont pas encore atteint un niveau de maturité suf-fisamment élevé pour être stables. De plus, ceschangements profitent de peu de coordination.Puisque les ressources budgétaires sont partagéesentre les différents changements, il est nécessairede recenser les différentes actions pour les coor-donner, les évaluer et décider de leur financement.

La gestion du programme d’amélioration del’efficacité des processus relève avant tout de lagestion du changement. La réussite de la phased’implantation dépend, entre autres, du degréd’adaptation au changement des employés. Larésistance au changement dépend de l’effortdemandé à l’individu. Pour de meilleurs résultats,l’impact total du changement ne doit pas dépasserla courbe d’apprentissage des individus.

Efforts en cours : • Recueillir des données pour les estimations• Mettre en place un processus d’assurance qua-

lité efficace• Détailler la phase de conception et ses livrables• Accélérer le processus de développement• Diminuer la lourdeur de la tâche de test, réduire

la documentation.

Liste des efforts en regard de leur intensitépar rôle :

6.8 ATTRIBUER LES RÔLES ET LES RESPONSABILITÉS

Tâches :• Documenter les rôles dans la section « Organi-

sation » du plan stratégique d’amélioration.• Définir les rôles pour le MSG, le SEPG et les

autres participants

Groupe de direction (MSG - management stee-ring group):Composition :

Rôles :• Définir la stratégie du plan d’action. • Évaluer la faisabilité des initiatives• Supporter l’implantation des actions d’amélio-

ration.

Groupe d’ingénierie des processus logiciel(SEPG / TWG – Technical Working Group)

Composition : 4 membres du groupe SEPG (3architectes et 1 gestionnaire de projets)

Rôles :• Proposer des moyens d’appliquer les décisions

du MSG• Supporter l’implantation des améliorations• Mesurer les efforts et les améliorations néces-

saires.

6.9 AFFECTER DES PRIORITÉS AUX ACTIVITÉS

DE DÉVELOPPEMENT

Tâches :• Définir les critères pour le choix des actions à

mettre en place• Définir les critères pour mesurer l’atteinte d’un

objectif

t


PROCESSUS

27

6.10 CRITÈRES SERVANT À L’ORDONNANCEMENT DES

ACTIONS

Ces critères ont été évalués par les participantslors de la rédaction du diagnostic.• Priorité du problème• Coûts de la solution• Effort disponible par la ressource affectée.

6.11 CRITÈRES SERVANT À MESURER L’ATTEINTE DES

OBJECTIFS

Satisfaction des employés (Le problème est-ilréglé : oui ? / non ? / partiellement ?

Les employés affectés directement par leschangements sont invités à se prononcer sur l’im-pact des changements.

6.12 CONCILIER LES ACTIONS D’AMÉLIORATION EN

COURS ET CELLES PLANIFIÉES

Tâches :• Construire une matrice démontrant les liens entre

les améliorations en cours et celles planifiées• Revoir les objectifs et sous-objectifs• Revoir le résultat du diagnostic

6.13 TROUVER UNE MANIÈRE DE MESURER L’ATTEINTE

DES OBJECTIFS

Tâches :• Trouver des unités pour mesurer les progrès réa-

lisés

Des données ne sont disponibles que pour cesdeux mesures : Temps planifié au regard du tempseffectif (SPI - Schedule Performance Index), satis-faction des employés.

6.14 TRANSFORMER LES OBJECTIFS DU PROGRAMME

D’AMÉLIORATION EN OBJECTIFS MESURABLES

Tâches :• Trouver un moyen de mesurer les sous-objec-

tifs

Aucune mesure et aucun historique n’étaientdisponibles sur les projets passés au moment dedébuter le programme d’amélioration. Ces don-nées auraient permis de mesurer rigoureusementl’amélioration de l’efficacité des processus. Lesobjectifs de ce cycle d’amélioration sont doncévalués en termes absolus. L’objectif a-t-il étéatteint : oui / non.

6.15 CRÉER OU METTRE À JOUR LE PLAN STRATÉGIQUE

Tâches :• S’assurer de la cohérence du plan• Préparer la version finale

6.16 CONSTRUIRE UN CONSENSUS, REVOIR ET APPROU-VER LE PLAN STRATÉGIQUE

Le plan d’action doit être validé avec les employésavant d’être mis en application. Le succès d’unplan d’action repose sur l’adhésion de celui-ci par

les employés et l’énonciation claire des objectifset des résultats anticipés.

Tâches :• Obtenir les commentaires et les suggestions• Résoudre les idées conflictuelles• Publier le plan (envoyer une copie à tout le per-

sonnel concerné)• Présenter et revoir le plan à tous les niveaux de

l’organisation

6.17 FORMER LE GROUPE DE TRAVAIL TECHNIQUE

(TWG) Il est recommandé que chaque solution du plansoit sous la responsabilité de petits groupes à l’in-térieur de l’organisation. L’équipe doit être forméede volontaires provenant de l’auditoire visé parl’amélioration. C’est une manière d’améliorer laparticipation et la motivation du personnel et des’assurer de l’application du plan.

Tâches :• Planifier les actions des membres• Assigner les responsabilités

7. MÉTHODE DE PLANIFICATION DU PROJET7-1 PLAN STRATÉGIQUE

Pour orienter la stratégie, nous considérons lesproblèmes documentés, les recommandations duCMM®, les enjeux d’affaires et les motivations.

Le plan stratégique a été présenté et acceptépar le MSG et le SEPG. Il a été par la suite présentéaux membres du projet lors d’une rencontre avecles membres. Cette rencontre avait pour objectifd’envoyer un signal clair aux employés que leurssuggestions ont été entendues par la direction etqu’il existe une vision pour améliorer la situa-tion.

Le modèle d’évolution des capacités logi-ciel (CMM®) a été utilisé à titre de référencepour produire les recommandations et orienterla planification stratégique. Puisque la résolu-tion de problèmes individuels (approche orientéeproblème) a été privilégiée plutôt que le respectd’un standard quelconque, les pratiques duCMM® qui pourraient nous permettre derésoudre chaque problème pris individuellementont été répertoriées et appliquées afin de pro-duire des solutions appropriées pour l’entreprise.Il n’est pas question ici de rédiger des procé-dures pour améliorer le processus (approcheorientée vers les processus) mais d’utiliser cer-taines pratiques du CMM® pour résoudre unesituation problématique.

On donne dans le tableau ci-dessous quelquesrecommandations concernant les différents pro-blèmes identifiés lors du diagnostic et des pistesde solution. t


PROCESSUS

28

On présente ci-dessous les éléments de hautniveau du plan stratégique élaboré à partir desrecommandations et des suggestions des partici-pants.

7-2 PLAN TACTIQUE

Le plan tactique présente les actions concrètes àentreprendre pour atteindre les objectifs du planstratégique, les actions sont affectées de priori-tés et un responsable leur est attribué. La méthodeemployée a été la suivante : • Étape 1. Estimer la gravité relative d’un pro-

blème. • Étape 2*. Estimer les coûts relatifs de l’im-

plantation des solutions liées à cet objectif.• Étape 3*. Déterminer la priorité. La priorité est

déterminée par le calcul de bénéfices ÷ coûts• Étape 4*. Ordonner les problèmes en fonction

d’une séquence d’implantation.* Ces étapes seront entreprises lorsque les

solutions seront disponibles.

À l’étape 4 : il est recommandé de porter uneattention particulière aux interdépendances entreles objectifs et les problèmes, l’ordre logiqued’implantation et la disponibilité des ressourcesainsi que leur capacité d’apprentissage. L’ordon-nancement de la séquence d’implantation est fonc-tion de chaque problème. Il est aussi possible deregrouper les problèmes selon des phases d’im-plantation. Par exemple, une première phase pour-rait s’attarder à la formation et à la mise en placed’outils, la seconde phase porterait sur l’implan-tation d’un projet pilote pour tester les habiletésacquises et promouvoir les nouvelles méthodeset la dernière phase consisterait en des activitésd’évaluation et d’ajustement. Ainsi, le fait qu’unélément de la solution puisse corriger plusieursproblèmes serait pris en compte. Le tableau Vmontre l’ordre d’exécution des actions.

Tableau 8 : Exemple de recommandation

Le tableau ci-dessous donne un extrait d’unplan d’action :

Tableau 9 : Extrait d’un plan d’action

Tableau 10 : Ordre d’exécution des actions

Dans le projet actuel, il a été décidé que l’ontenterait de mettre en place l’ensemble des amé-liorations proposées dans le plan stratégique. Ilrestait à déterminer l’importance relative de cha-cune des améliorations afin de savoir quellesactions seraient prioritaires s’il advenait qu’ilserait impossible de toutes les mettre en place.Dès le début du projet, nous avons accordé uneattention particulière à la mise en place du pro-cessus itératif et à l’intégration des ressources ducentre de livraison et des ressources du centre desexigences. Le tableau suivant illustre l’ordon-nancement des actions en fonction du coût et béné-fices. On a aussi assigné des responsables pourchaque action affectée d’une priorité.

t


PROCESSUS

29

8. PHASE D’IMPLANTATIONSELON LE MODÈLE IDÉAL

La phase d’action est le point culminant du pro-gramme d’amélioration. C’est à ce moment-cique l’efficacité du programme d’amélioration estvérifiée. L’objectif de cette phase est d’implanterles solutions déterminées à la phase de planifi-cation dans le but de corriger les problèmes sou-levés lors de la phase de diagnostic. Lesprincipales tâches concernent l’affinement dessolutions proposées, l’intégration des solutionsau processus existant et le support aux utilisa-teurs du nouveau processus.

8.1 COMPLÉTER LE PLAN TACTIQUE AVEC LE GROUPE

TECHNIQUE (TWG)À cette étape, l’étendue du projet d’améliorationsera définie. Le programme d’amélioration nedoit pas être trop ambitieux afin de s’assurer d’ob-tenir des résultats concrets. Le projet devra avoirune durée limitée dans le temps, soit de 6 à 9mois. Il est important d’obtenir un équilibre entrele dessein d’une solution idéale et l’atteinte derésultats rapide. Le plan tactique produit à cetteétape sera approuvé par le comité de direction(MSG).

Tâches :• Revoir le plan tactique• Revoir les données du baseline• Développer des tâches et des critères de sélection• Structurer un plan d’action – (work breakdown

structure) - WBS.• Organiser le WBS et planifier les jalons et les

livrables• Réviser et affiner le plan tactique

8.2 DÉVELOPPER DES SOLUTIONS

Ici, nous identifierons des solutions aux problèmesexistants. Les solutions devront cadrer avec laculture organisationnelle afin qu’elles soient faci-lement acceptées et partagées par tous.

Tâches :• Décrire les problèmes• Définir les buts• Analyser les problèmes

• Générer des alternatives pour solutionner tous lesproblèmes

• Préciser des métriques• Sélectionner la meilleure solution pour chaque

problème

8.3 PILOTER LES SOLUTIONS

Valider à l’intérieur du projet pilote les solutionschoisies constituera l’objectif de cette étape. Cessolutions nécessiteront certains ajustements avantd’être implantées dans l’organisation.

Tâches :• Choisir des critères de sélection pour le projet

pilote.• Identifier un ou des projets pilotes • Sélectionner l’équipe du projet pilote• Former l’équipe du projet pilote• Implanter les solutions• Exécuter et suivre le projet pilote• Évaluer les résultats du projet pilote• Recueillir les leçons apprises

8.4 DÉTERMINER LE SUPPORT À LONG TERME

Il va de soi que les solutions à long terme néces-sitent un soutien à long terme. Le support auxaméliorations devra être planifié pour les annéesà venir et sera développé en parallèle avec lessolutions qu’il doit soutenir.

Tâches :• Répondre aux besoins du Groupe de travail

(TWG) en matière de support• Définir les futurs besoins du Groupe de tra-

vail (TWG) afin de lui apporter un supportadéquat.

8.5 DÉVELOPPER UNE STRATÉGIE POUR L’EXÉCUTION

Une fois que les solutions sont déterminées et queles moyens pour assister les employés sont prêts,les améliorations peuvent être implantées à tra-vers l’organisation. Le Groupe de travail (TWG)doit produire un document qui explique la méthoded’implantation des améliorations. On y retrou-vera les informations suivantes :• La formation nécessaire• Les outils et méthode utilisés• Les étapes d’implantation• L’information pour obtenir du support

Le Groupe de travail (TWG) doit égalementpréparer un gabarit du plan d’implantation quisera utilisé lors de l’implantation d’améliorationsau cours des autres projets.

Tâches :• Créer un plan d’implantation pour chaque solu-

tion• Réviser le plan d’implantation avec le Groupe

de travail (TWG) et le Groupe de direction(MSG).

Tableau 11 : Exemple d’ordonnancement des actions

t


PROCESSUS

30

8.6 REMETTRE AU SEPG L’INFORMATION PERTINENTE

AU PLAN D’AMÉLIORATION

Les documents produits lors des phases précé-dentes du programme d’amélioration doivent êtreremis au Groupe d’ingénierie (SEPG) afin de véri-fier que le contenu de ces documents est respecté.

Tâches :• Identifier les documents produits par les diffé-

rents groupes : Les documents concernant leprogramme d’amélioration dont le diagnostic,les recommandations du CMM® et le plan stra-tégique et tactique.

• Collecter les documents• Joindre des descriptifs aux documents• Organiser et cataloguer tous les documents• Regrouper tous les documents dans un seul docu-

ment• Revoir le contenu avec le Groupe d’ingénierie

logiciel (SEPG)• Archiver les documents

8.7 FAIRE LE COMPTE-RENDU DU TRAVAIL DU GROUPE

TECHNIQUE (TWG)Le Groupe technique présente un document inti-tulé « Leçons apprises » en guise de conclusionafin de préparer les itérations subséquentes. Cecompte rendu du Groupe de travail devra être com-muniqué à toute l’organisation.

Tâches :• Revoir le programme d’amélioration avec le

Groupe de travail (TWG) et recueillir les leçonsapprises.

• Marquer la fin des activités• Dissoudre l’équipe

8.8 IMPLANTER LES SOLUTIONS

Une fois que les améliorations ont été implantéeset leur efficacité prouvée à l’intérieur du projetpilote, il est temps de les évaluer, de les mettre àjour et de les déployer au sein de l’organisation.

Tâches :• Informer toute l’organisation des changements

à venir• Affiner le plan et la stratégie d’exécution• Rencontrer et informer les membres de chaque

projet• Affiner le plan et la stratégie d’exécution pour

chaque projet• Former les membres des projets• Implanter les améliorations• Évaluer le déploiement

8.9 PLANIFIER LE SUPPORT À LONG TERME

Les améliorations ne doivent pas exiger un suiviconstant : le contraire démontrerait que les solu-tions implantées étaient inadéquates. Les membresdes projets ne doivent pas non plus exiger du sup-port ; cependant, l’expertise nécessaire sera dis-

ponible lors de l’introduction des changements etde la formation des employés.

Tâches :• Le Groupe d’ingénierie (SEPG) supporte les

projets à long terme• Le Groupe de direction (MSG) vérifie que tous

les groupes respectent leurs engagements quantaux améliorations mises en œuvre.

9. PHASE DE BILAN SELON LE MODÈLE IDÉALMaintenant qu’un premier cycle du programmed’amélioration a été complété, il est nécessairede revoir ce qui a été accompli pour se préparerpour le prochain cycle d’amélioration. Il faut pro-fiter de cette phase pour analyser les améliora-tions proposées et réviser la méthode employéepar le programme lui-même. Un autre objectif decette phase est aussi d’obtenir de la visibilité enréaffirmant l’appui de la direction au programme.

9-1 RECUEILLIR LES LEÇONS APPRISES

Le but de cette étape est de s’assurer que toutel’information concernant les leçons apprises estdisponible avant de débuter le prochain cycle. Onen profitera aussi pour faire un rappel des activi-tés des phases précédentes et des résultats obtenus.[9, 20].

Tâches :• Rassembler les leçons apprises. Les sources sont

les membres du Groupe de travail, le personneldu projet et les gestionnaires

• Analyser les leçons apprises

Il faut s’assurer, à cette étape, que la méthodeutilisée lors du programme d’amélioration est lameilleure. Pour faire suite à la collecte de l’in-formation, il est nécessaire d’identifier les zonesd’amélioration possibles pour modifier ou chan-ger l’approche utilisée dans le programme d’amé-lioration.

Tâches :• Réviser : les leçons apprises, les artéfacts, l’ap-

proche globale, la communication, les résultatsavec les intervieweurs, l’efficacité de la structuremise en place.

• Interviewer les gestionnaires et inclure leurintrant

• Comparer les résultats avec la littérature sur lesujet

9.2 RÉVISER L’APPROCHE ORGANISATIONNELLE

À ce stade, il faut rendre plus efficace le proces-sus du programme d’amélioration qui sera utilisédurant le prochain cycle. Il faudra aussi être enmesure de modifier le ou les processus de déve-loppement de façon à réduire la résistance au chan-gement et à implanter plus rapidement lesmodifications.

t


PROCESSUS

31

Tâches :• Revoir le processus d’amélioration• Documenter la nouvelle approche• Changer la structure organisationnelle si néces-

saire

9.3 MESURER L’APPUI DE LA DIRECTION

L’appui de la direction est essentiel pour un pro-gramme d’amélioration. Il est maintenant temps des’assurer ce cet appui de la direction pour la pour-suite du programme et de la disponibilité des res-sources pour le prochain cycle.

Tâches :• Confirmer l’appui de la haute direction• Revoir l’approche du programme d’améliora-

tion avec la haute direction• Revoir la disponibilité des ressources avec la

haute direction• Établir des objectifs stratégiques.

Les objectifs stratégiques ont été identifiés unepremière fois durant la phase d’initiation puis révisésen cours de projet. Aussi, des objectifs clairs et mesu-rables aident-ils à établir une tactique cohérente etpermettent de mesurer objectivement les résultats.

Tâches :• Réviser les objectifs des phases précédentes

pour savoir s’ils sont toujours pertinents.• Définir, s’il y a lieu, de nouveaux objectifs qui

soient cohérents avec la vision de l’organisa-tion, ses besoins d’affaires et sa stratégie.

9.4 CRÉER OU REVOIR LA PROPOSITION DU PROGRAMME

D’AMÉLIORATION

En attendant qu’un nouveau plan stratégique soitémis ou révisé, il est recommandé d’avoir un planintérimaire.

Tâche : Développer un plan qui guidera le pro-gramme d’amélioration

9.5 POURSUIVRE LE PROGRAMME D’AMÉLIORATION

Le but de cette activité est de s’assurer de la transitionentre la phase de révision et la phase de diagnostic.

Tâche : Obtenir l’approbation de la haute directionpour la poursuite du programme d’amélioration.

10. DISCUSSION DES RÉSULTATS OBTENUSCette section présente les principaux résultats dece travail. On y retrouve dans un premier temps lesrésultats concernant l’analyse des méthodes uti-lisées et, ensuite, les résultats concrets obtenuspour faire suite à la mise en place des améliora-tions du processus.

10.1 RÉSULTATS OBTENUS

Lors de l’étape du diagnostic, deux objectifsavaient été établis : 1) respecter les échéanciers à

l’intérieur d’une fourchette de +/- 10%, 2) dimi-nuer la quantité de travail repris (rework). Lesrésultats obtenus sont les suivants :• Respecter à +/- 10% les échéanciers de départ.

Le premier objectif a été respecté puisque lesdépassements étaient inférieurs à 8%. Il fautcependant souligner que les coûts du projet ontété dépassés (données indisponibles) avec l’ajoutde 2 ressources (1 concepteur et 1 développeur)en cours de projet.

• Diminuer la quantité de travail repris Le deuxième objectif n’a pu être mesuré quan-titativement puisqu’il n’existait pas de donnéeshistoriques. Mais, il est de l’avis de tous que laquantité de travail repris et le nombre d’erreurstrouvées lors de conception et du développe-ment ont nettement diminué. Cela peut s’expli-quer par l’expérience acquise au niveau desrevues par les pairs et par une meilleure connais-sance du domaine d’affaires en général. Afin demesurer la quantité de travail repris lors des pro-chains projets, le responsable de l’assurancequalité a conservé, à des fins de comparaison, lenombre d’erreurs détectées lors de la revue parles pairs, le temps passé à corriger les spécifi-cations suite au dépôt officiel ainsi que lenombre d’erreurs dans le code lors de la phase detest.

11. DISCUSSION DES LEÇONS APPRISESCette section décrit les résultats obtenus lors del’analyse post mortem rédigée à la fin du pro-gramme d’amélioration. Les volets qui seront pré-sentés sont : 1) les leçons apprises concernant lesmodèles et méthodes utilisés et 2) les leçonsapprises concernant les améliorations apportéesau processus de développement logiciel.

11.1 LEÇONS APPRISES CONCERNANT LES MODÈLES

ET MÉTHODES UTILISÉS

Utiliser le modèle IDEALSM : Le modèle IDEALSM

fournit une approche claire quant à la marche àsuivre pour le processus d’amélioration. Chaquephase est décrite ainsi que les tâches à remplirpour compléter cette phase. Le modèle est cohé-rent, relativement simple et complet. Cependant,le modèle n’explique pas comment réaliser unetâche : il n’est pas expliqué comment réaliser undiagnostic, un plan d’action ou une analyse postmortem ; il a fallu se référer à la méthode orien-tée vers les buts.

Utiliser la méthode orientée vers les buts :Cette méthode complète le modèle IDEALSM enexpliquant comment réaliser la plupart des tâchesdu modèle. Les auteurs de la méthode compren-nent aussi l’importance de produire rapidementdes résultats tangibles pour donner de la crédibi-lité au programme. Au départ du projet, l’approcheorientée sur les processus a été considérée mais ilest rapidement apparu que cette technique ne ferait t


PROCESSUS

32

qu’ajouter à la lourdeur et à la documentationexistant et susciterait peu d’intérêt de la part desemployés et de la direction sans pour autant appor-ter de solutions concrètes à court terme. Cetteapproche n’est pas recommandée si elle n’est pasdirectement liée à l’objectif d’être évalué dans lecadre d’une attestation CMM.

Utiliser le CMM® ou le CMMI : Le CMM®s’est avéré un outil intéressant lors de la produc-tion des recommandations. Grâce au diagnosticnous avons identifié plusieurs activités (analysedes exigences, gestion de projets, revue par lespairs, etc.) présentant des lacunes. Le CMM® pro-pose, pour chaque activité, une liste d’actions àentreprendre pour s’assurer que l’activité est cor-rectement menée. Le CMM® a été utilisé tel une« boîte à outils » que nous utilisions selon nosbesoins lors de la recherche de solutions. Nousn’avons donc pas fait usage du CMM® de lamanière proposée par l’approche orientée vers lesprocessus (par opposition à la méthode orientéevers les buts) où il est tenté d’appliquer intégra-lement le modèle CMM® et de conduire les acti-vités qu’il propose.

Intégrer la formation à l’intérieur du proces-sus et offrir un support continu et en tout temps :Les membres du SEPG ont offert la formation. Lesnouvelles techniques, particulièrement au niveau dela conception détaillée, ont été enseignées lorsd’ateliers et ensuite la production des premiers élé-ments de livraison a eu le support du SEPG. Il estimportant que le support soit disponible à toutmoment et que les ressources soient à portée demain des exécutants. Une question qui reste en sus-pend peut retarder la production.

Choisir l’ordre des améliorations : Il est pré-férable de choisir des améliorations qui auront uneffet immédiat ou qui sont attendues depuis long-temps. De cette manière, il est plus facile d’ac-quérir le soutien des employés et de la direction.

Le diagnostic en tant qu’outil de communica-tion : Le diagnostic, tel que présenté dans ce docu-ment, aura permis d’obtenir une image très clairede la situation de l’organisation et de communiquerles problèmes aux employés. Mais, c’est surtout auniveau de la direction que le diagnostic a eu le plusd’impact en révélant précisément les problèmes,leurs causes et leurs conséquences. Ce livrable a étéfort utile pour obtenir le soutien de la direction etprouver la nécessité du programme.

11.2 LEÇONS APPRISES CONCERNANT LES AMÉLIORA-TIONS APPORTÉES AU PROCESSUS DE DÉVELOPPEMENT

LOGICIEL

Passer du mode « usine logiciel » à un mode« projet » : Le mode de développement de type« usine à logiciel » (software factory) est carac-

térisé par le fait que le groupe qui réalise laconception et le développement du logiciel n’estpas attitré par un seul projet, mais pat plusieurs etce groupe reçoit les exigences de différents projetset réalise le développement pour chacun d’eux.La manière de communiquer les exigences n’estdonc pas la même et la relation entre le groupedes exigences et test et celui du développements’apparente davantage à de la sous-traitance. Avantd’implanter ce mode de développement les acteursdoivent être à l’aise avec le processus actuel, lesdeux équipes doivent avoir une certaine maturitépour qu’elles puissent envisager de travailler sépa-rément et les règles d’affaire doivent être parfai-tement assimilées par le groupe des exigences.Ces trois facteurs n’étaient réunis avant la mise enplace du mode de développement de type « usineà logiciel » La majorité des ressources étant plusfamilière avec le mode de développement par pro-jet, le risque que représentait le mode de déve-loppement « usine à logiciel » a été éliminéautomatiquement. Nous sommes donc revenusvers un mode de développement traditionnel enattendant que les conditions nécessaires au succèsde l’autre méthode soient rassemblées.

Migrer vers un processus itératif : Il s’agit làsûrement d’une des améliorations les plus signi-ficatives. Développer à la fois un nombre restreintde cas d’utilisation permet de réduire les risquesliés à l’implantation d’une nouvelle architecturetout en obtenant rapidement des résultats. Ajoutonsaussi qu’il est possible de livrer graduellementdes fonctions, ce qui atteste que le projet pro-gresse et qui constitue, par le fait même, unesource de motivation pour les employés et pour ladirection. Même si un projet subit occasionnelle-ment des ratés, il est nécessaire d’obtenir desrésultats concrets afin de maintenir l’intérêt pourle programme d’amélioration.

Maîtriser la phase de conception détaillée etses livrables : Les livrables de cette phase sont desdiagrammes : diagrammes de séquence et dia-grammes de classes. La phase de conceptiondétaillée suit la phase d’analyse fonctionnelle etutilise comme intrant le cas d’utilisation et le scé-narimage (écrans et éléments de données). L’im-plantation de cette phase facilite la réalisation dela phase suivante : celle de développement (rédac-tion du code), car servant de pont entre les ana-lystes et les codeurs, cette phase permet de validerla faisabilité des exigences et de clarifier les ques-tions relatives au domaine d’affaires. Nousn’avons pas noté de gain ni de perte en producti-vité puisque le temps passé en conception estperdu en développement. Mais, avec l’expérience,nous croyons que cette phase améliorera la qualitédu produit, réduira les risques tant au plan du res-pect des exigences seulement techniques tout enaméliorant la qualité du produit.

t


PROCESSUS

33

Développer un plan de projet à court terme :Le plan de projet à court terme se résumait à uneliste d’actions qui étaient nécessaires à court terme(moins de deux semaines). Cette liste nous per-mettait de faire un suivi relativement serré du pro-jet du point de vue opérationnel (c’est-à-dire parrapport au plan stratégique et tactique). Chaqueproblème, aussi anodin soit-il, est pris en chargepour s’assurer qu’il ne deviendra pas un obstacledans le processus de développement.

Améliorer la qualité des exigences : Aucuneaction n’a été entreprise en ce sens durant ce cycledu programme d’amélioration. La phase des exi-gences était déjà trop avancée pour y introduire desaméliorations au moment où le programme d’amé-lioration a débuté. Cependant, nous avons détectéplusieurs faiblesses au niveau de l’analyse d’af-faires, faiblesses qui seront corrigées lors des pro-chaines phases du projet.

Recueillir des données pour les estimations et lesmesures : De ce côté, nous avons accompli beaucoupde progrès. L’utilisation de MS-Projet Server©9 per-met à chacun de saisir directement ses estimés surune interface client et devient donc responsable, parle fait même, du respect des échéanciers. Aupara-vant, les estimations étaient assurées entièrementpar le gestionnaire de projet qui recevait peu d’in-formation de la part de l’exécutant. Autres amélio-rations, toutes les données liées à la gestion de projetsont conservées et il est possible de produire direc-tement des analyses de performances.

12. CONCLUSIONLes faits saillants du programme d’amélioration sontles suivants :• Il a été possible de livrer les projets dans les délais

prévus. • Les gestionnaires de projets maîtrisent davantage

le concept de développement itératif. • La nouvelle structure de l’organisation a amélioré

la communication entre les intervenants.• La documentation produite répond davantage aux

besoins des utilisateurs et est moins lourde à sup-porter.

En ce qui concerne l’introduction et la gestiond’un programme d’amélioration, les leçons apprisespeuvent être résumées de la façon suivante :• S’assurer non seulement du support de la direc-

tion pour démarrer le programme, mais aussi decelui des employés ; si le changement s’opère parla base, il sera plus facile à mettre en œuvre etaura de meilleures chances de succès.

• Débuter par des améliorations dont les effets serontvisibles rapidement afin de donner un certain élanau programme d’amélioration et de préparer le ter-rain pour les améliorations plus difficiles.

• Établir un diagnostic solide, car, dans le cas quinous concerne, le programme n’a vraiment

démarré que lorsque les dirigeants ont constatéles résultats du diagnostic. Non seulement lesproblèmes et leurs causes étaient énoncés clai-rement, mais la qualité même du travail a motivéles dirigeants à poursuivre et supporter le pro-gramme d’amélioration.

En conclusion, les objectifs du travail ont étéatteints. L’utilisation du modèle IDEALSM, commecadre de référence, et de l’approche orientée versles buts ont permis de structurer l’ensemble duprogramme d’amélioration et d’organiser lestâches. L’approche orientée vers les buts a per-mis d’identifier et de résoudre rapidement desproblèmes qui perduraient depuis des mois touten minimisant l’impact des changements. Lessolutions recommandées, grâce à l’utilisation duCMM® et des entrevues menées auprès des par-ticipants, ont été appliquées avec succès. Les docu-ments qui ont été produits : le diagnostic, lesrecommandations et le plan stratégique et tactiqueont fourni aux dirigeants les informations néces-saires pour coordonner le programme et faciliterla prise de décision.

13. RECOMMANDATIONSCe premier cycle d’amélioration a permis de résoudreune partie des lacunes du processus existant. Mais,un programme d’amélioration est aussi un processusitératif qui vise à améliorer constamment la perfor-mance des processus. Suite au recueil des leçonsapprises, les sujets que devrait aborder le prochaincycle d’amélioration sont les suivants :

Il sera intéressant d’observer comment leprogramme d’amélioration sera perçu maintenantque plusieurs problèmes ont été réglés et que lesgestionnaires maîtrisent davantage le processus. Secontenteront-ils du statu quo puisque les résultatslaissent penser que le processus est relativementefficace ou seront-ils intéressés à poursuivre leprogramme, encouragés par les résultats obtenuslors du premier cycle. Néanmoins, il est mainte-nant démontré qu’une approche structurée faci-lite l’amélioration de la performance des processusd’une organisation et permet de réduire les risquesassociés aux changements.

14. RÉFÉRENCES

[1] V. Basili et D. M. Weiss : A methodology forcollecting valid software engineering data ;IEEE Transactions on Software Engineering, t


PROCESSUS

34

vol. SE-10, n° 6, pp ; 728-738, novembre1984.

[2] R. Basque : Le modèle d’évolution des capa-cités logiciel (CMM) du SEI : un guide depratiques clés pour les informaticiens sou-cieux de qualité ; Centre de Recherche Infor-matique de Montréal, CRIM, 2000

[3] M. K. Daskalantonakis : Achieving higherSEI levels ; IEEE Software, vol. 11, n° 4,pp. 17-24, juillet 1994.

[4] D. K. Dunaway et S. Masters : CMM apprai-sal for internal process improvement (CBAIPI): Method Description ; Pittsburgh, PA,Software Engineering Institute, CarnegieMellon University, 1996

[5] N. Hill : Law of success ; Success Unlimi-ted. The 21st-Century Edition, High RoadMedia, 1979

[6] W. S. Humphrey : Software quality assu-rance: Managing the software process ;Addison-Wesley, Reading, MA, 1989

[7] P. Jalote : CMM in practice – Processes forexecuting software projects at Infosys ; Addi-son Wesley, 2000.

[8] N. L. Kerth : Project retrospectives: A hand-book for team reviews ; Dorset House Publi-shing, New York, 2001.

[9] D. H. Kitson et S. Masters : An analysis ofSEI, software process assessment results:1987-1991 ; Software Engineering Institute,1992.

[10] P. Krutchen : The Rational Unified Process,An Introduction (3e éd.) ; Addison Wesley,2003

[11] C. Y. Laporte : Maturation du génie logicielau Québec : Où en sommes-nous ? ; L’Ex-pertise informatique, vol. 2, no 1, été 1996,pages 2 à 9.

[12] C. Y. Laporte et S. Trudel : Addressing thepeople issues of process improvement acti-vities at Oerlikon Aerospace; Software Pro-cess-Improvement and Practice, WileyInterscience, vol. 4, 1998.

[13] B. McFeeley : IDEAL: A user’s guide forsoftware process improvement ; SoftwareEngineering Institute, Pittsburgh, PA, Car-negie Mellon University, 1996.

[14] M. Paulk et Coll. : Pratiques du modèled’évolution des capacités logicielles, Ver-sion 1.1 ; Software Engineering Institute,rapport technique numéro. Pittsburgh, PA,Carnegie Mellon University, 1993.

[15] N. Potter et M. Sakry : Goal-ProblemApproach for scoping an improvement pro-

gram ; The Process Group Post Newsletter,vol. 6, n° 2, septembre 1999.

[16] N. Potter et M. Sakry : Making ProcessImprovement Work ; Addison-Wesley, 2002.

[17] D. J. Reifer : The 3P’s of software manage-ment, Tutorial Software Management, (5e

éd.) ; IEEE Computer Society, 1997.[18] S. Sheard : What is senior management com-

mitment? ; Proceedings of the 11th AnnualSymposium of the International Council onSystems Engineering, 2001. Republié in Pro-ceedings of the Software Technology Confe-rence, Salt Lake City, UT, 2002.

[19] B. Tuckman et M. Jensen : Stages of smallgroup development ; Group and Organiza-tional Studies, 2, pp. 419-427, 1977.

[20] K. E. Wiegers et J. Rothman : Looking back,looking ahead ; Software Development., vol.9, n°. 2, février 2001.

NOTES

1 IDEAL SM est une marque de service de Car-negie Mellon University.

2 Capability Maturity Model, CMM et CMMIsont enregistrés auprès de l’U.S. Patent andTrademark Office par Carnegie Mellon Uni-versity.

3 RUP et Rational Unified Process sont desmarques de commerce de la société IBM

4 PPL Planification de Projet Logiciel5 Suivi et Supervision de Projet logiciel6 Définition du Processus de l’Organisation7 Gestion Logiciel Intégrée8 Ingénierie de Produits Logiciels9 Marque de commerce de la société Microsoft.

LISTE DES ABRÉVIATIONS ET DES SIGLES

AQL Assurance Qualité LogicielleCMM® Capability Maturity Model®CPI Cost Performance IndexIDEALSM Initiating, Diagnosing, Establishing,

Acting & LearningISO Organisation Internationale de Stan-

dardisationMSG Management Steering Group PAPPL Programme d’amélioration de

la performance des processusPI Productivity IndexQI Quality Index.RUP® Rational Unified Process® TWG Technical Working GroupSEI Software Engineering InstituteSEPG Software Engineering Process GroupSPI Schedule Performance Index

t

programme d’amélioration de la performance des processus … · 2012-12-20 · la performance...

Documents