Vous êtes sur la page 1sur 45

Gestion de projets informatiques

Synthse Thierry IRIE

Chapitre 1 : Gnralits sur la gestion de projets informatiques

1. Contexte et historique La gestion de projet est gnralement considre comme une discipline moderne. Cependant il faut noter que la racine de ses principes fondamentaux provient de la fin du dix-neuvime sicle. partir du dbut des annes 1960, les entreprises ont commenc raliser lutilit dorganiser le travail en projets. Cette vision de lorganisation axe sur les projets sest amplifie lorsque les organisations ont pris conscience de la ncessit essentielle pour leurs employs de communiquer et de collaborer dans un contexte professionnel impliquant plusieurs services et professions et, dans certains cas, lensemble des secteurs industriels. Aujourdhui, les principes de base de la gestion de projet sont reprsents par le triangle, un symbole rendu populaire par Harold Kerzner dans son ouvrage vnement, Project Management: A Systems Approach to Planning, Scheduling, and Controlling.

Le triangle du projet traduit la relation existant entre les lments temps, argent et objectif. L'ajustement de l'un de ces trois facteurs a des rpercussions sur les deux autres. Par exemple, si lon ajuste le plan de projet pour rduire les prvisions, lon risque d'accrotre les cots et de faire baisser l'objectif. De mme, les projets informatiques connaissent ces similitudes. Dans la suite du cours nous aborderons la gestion de projet informatique dans son aspect relatif la conception et la ralisation de logiciels. 2. Le projet logiciel et la gestion de projet logiciel Il y a une grande diffrence entre lactivit dun dveloppeur passionn qui ralise son logiciel isolement et le dveloppement industriel dune application de grande taille qui peut rassembler quelques centaines de dveloppeurs sur plusieurs annes. Dans le premier cas, la mthodologie est une affaire dhabitudes personnelles et se constitue au fil de lexprience. A chacun de trouver ses propres recettes pour dvelopper vite et bien. Le dveloppeur isol se constitue son propre style de programmation, son rpertoire dastuces pour rsoudre des problmes de codage qui

Synthse Thierry IRIE

reviennent souvent, lensemble des comportements qui lui permettent de limiter au maximum la fastidieuse chasse aux bugs. Dans lindustrie, les soucis defficacit, de rutilisation de solutions connues, ou de programmation sans erreur sont bien sr pris en charge, mais les dfis supplmentaires que pose le partage du travail viennent sy ajouter. Au fil du temps, les projets informatiques sont devenus de plus en plus complexes et ce phnomne na fait que saccentuer avec lapparition et la propagation des langages orients objets. Les quipes de conception deviennent donc de plus en plus importantes, entranant un besoin croissant de communication entre les divers spcialistes. Dune part, le besoin exprim par le client souvent incomptent dans le domaine de la conception informatique est gnralement flou et incomplet. Rciproquement, le concepteur est tranger au monde du client. Il sagit donc de trouver un l angage commun entre ces deux mondes pour instaurer un dialogue et identifier les clauses contractuelles de manire satisfaisante pour les deux parties. Il rsulte de ce constat que malgr tous les efforts dploys lvolution du cahier des charges au cours du dveloppement est quasiment invitable. Dautre part, le dveloppement lui-mme est effectu plusieurs, les diffrentes parties dun logiciel sont toujours plus ou moins interdpendantes, si bien qu tout moment du cycle de vie dun projet, de la spcification la validation finale, les dveloppeurs et concepteurs doivent se mettre daccord sur les fonctionnalits en interagissant au quotidien. Le problme du gnie logiciel est donc de : limiter lvolution du cahier des charges et rduire le risque de malentendu entre clients et concepteurs ainsi quentre quipes de concepteurs en sappuyant sur un langage de modlisation standard et non ambigu ; rpondre le plus rapidement possible une volution du cahier des charges en rduisant le temps du cycle lmentaire qui spare les spcifications de la ralisation ; limiter au maximum les rpercussions dune modification dans une phase du dveloppement sur les autres phases ; fournir des moyens de communication et de structuration du travail collectif les plus efficaces possible pour permettre une collaboration distribue ; terme, automatiser le passage de la spcification limplmentation. Tout au long de ce cours nous tenterons de transmette des recettes devant permettre au mieux de palier ces problmes. 3. Quelques connaissances de base 3.1 Dfinitions Projet : On appelle projet l'ensemble des actions entreprendre afin de rpondre un besoin dfini dans des dlais fixs. Un projet possde galement un cot et fait donc l'objet d'une budgtisation de moyens et d'un bilan indpendant de celui de l'entreprise. On appelle livrables les rsultats attendus du projet.
Projet informatique :

Synthse Thierry IRIE

Un projet informatique un ensemble dactions mises en uvre, afin de produire les rsultats et fournitures dfinies en rponse aux objectifs clairement dfinis, dans des dlais fixs (date dbut et date de fin), mobilisant des ressources humaines et matrielles et possdant un cot prvisionnel et des gains esprs. Conduite de projet : On appelle conduite de projet l'organisation mthodologique mise en uvre pour faire en sorte que l'ouvrage ralis par le MOE rponde aux attentes du MOA et soit livr dans les conditions de cot et de dlai prvus initialement. Gestion ou management de projet : La gestion de projet a pour objectif d'assurer la coordination des acteurs et des tches dans un souci d'efficacit et de rentabilit. Le management de projet s'inscrit toujours dans le typique Cot-Dlais-Qualit.

Cycle de vie du projet : On appelle cycle de vie du projet l'enchanement dans le temps des tapes et des validations entre l'mergence du besoin et la livraison du produit. Cycle de vie de l'ouvrage : Le cycle de vie de l'ouvrage correspond aux tapes et aux livrables ncessaires la ralisation de l'ouvrage. 3.2 Concepts importants
Matriser le dveloppement

Il sagit de pouvoir : Utiliser des techniques dindustrialisation (cf. calculettes, micros) ; Concevoir chaque logiciel comme une brique dun projet (cest-dire travailler en mode projet) ; Dcliner les fondamentaux (CMM, ISO, SPICE,...) relatifs aux aspects dvaluation des cots et mtrologie.
Conduire le dveloppement

La conduite du dveloppement consiste simposer des processus formels de dveloppement. Il sagit en particulier de : processus dassurance qualit ; points de contrle (milestones) ; mthode structure, phase ; produits finis en fin de phase: inspection et validation aprs chaque phase du dveloppement ; automatis ; adaptable ; processus formel et exhaustif de tests ; technologie jour (objets, Java, AGL,...).

Synthse Thierry IRIE

3.3 Acteurs dun projet Matrise douvrage ou MOA : On appelle matrise douvrage toute personne physique ou morale propritaire de louvrage. Il dtermine les objectifs, le budget et les dlais de ralisation. Matrise duvre ou MOE : On appelle matrise duvre personne physique ou morale qui reoit mission de la matrise douvrage pour assurer la conception et la ralisation de louvrage. Comit Directeur ou CD : Le Comit Directeur est charg de : contrler le droulement du projet ; dcider du lancement des phases ; arbitrer. Comit de Pilotage ou CP : Lors du lancement du projet, un Comit de Pilotage, compos de responsables organisationnels de la MOA, est nomm afin d'en assurer le suivi. Cest une structure temporaire, mise en place spcifiquement pour le projet, qui a pour but de piloter le projet de faon autonome, c'est--dire en se distinguant de la hirarchie permanente de la socit. Le Comit de pilotage est cependant charg de rendre compte au Comit Directeur des problmes rencontrs au cours du projet lorsqu'une dcision de niveau stratgique doit tre prise au cours du projet. A la fin du projet, le Comit de Pilotage est dissous et le chef de projet retrouve ses attributions originales. Chef de projet : Un Chef de projet de la MOA assure la fonction d'animation du projet. Il est alors dsign et une date prvisionnelle de dmarrage du projet est fixe. Le Groupe de projet La matrise d'uvre est organise autour d'un groupe de projet, son organe de dcision. Ce groupe a pour mission de produire l'ensemble des travaux relevant des attributions de la matrise d'uvre. Il est gnralement constitu de la faon suivante: o un chef de projet qui assure la fonction d'animation, o des ingnieurs de conception et de ralisation, o un responsable qualit et mthodes charg de la planification, o ventuellement des experts. Le groupe de projet a pour principale tche de grer les quipes de dveloppement et/ou de paramtrage, interne ou externe. Il organise l'assurance qualit et suit l'avancement et la consommation des ressources du projet. Organe de dcision de la matrise d'uvre, il communique avec la matrise d'ouvrage au travers de runions ou de tableaux de bord permettant le pilotage du projet. Comit des Utilisateurs : Le Comit des utilisateurs est charg de (ou des) : o la conception: choix, validation ; o demandes auprs du C.D.

Synthse Thierry IRIE

Synthse Thierry IRIE

Chapitre 2 : Principes, mthodes et techniques de conduite et de gestion de projets informatiques


1. Principes Rappelons que la conduite de projet informatique est lorganisation mthodologique mise en uvre pour faire en sorte que louvrage ralis par le matre duvre rponde aux attentes du matre douvrage dans les contraintes de dlai, cot et qualit.

Elle implique dans sa dclinaison les facteurs de gestion suivants : - La gestion des hommes ; - La gestion technique ; - La gestion des moyens. Cette dclinaison peut tre reprsente ainsi :

La conduite et la gestion de projet informatique constituent un processus difficile matriser compte tenu des facteurs de risques inhrents et des exigences lies sa rsolution. Les Facteurs de risque sont: les cots et les dlais respecter ; les technologies matriser ; les ressources humaines grer.

Pour rduire ces risques, il faudra : Dfinir des principes de base, communs lensemble des projets afin de clarifier la terminologie ; Coordonner les intervenants ; Veiller la cohrence des diffrentes activits. La conduite de projet informatique se situe 2 niveaux : a) Lors de la conception : Il sagit ici de fixer les objectifs, la stratgie, les moyens, lorganisation et le programme daction. b) Lors de la ralisation :
Synthse Thierry IRIE 7

Il sagit ici de sassurer du bon droulement du projet, de la qualit, du respect des dlais et des budgets, faciliter les travaux de mise en uvre et de maintenance.

Synthse Thierry IRIE

2. Modles de conduite et gestion de projets informatiques Il existe plusieurs modles de conduite et gestion de projets informatiques : a) Les modles bass sur les livrables : modles linaires Dans ce cas le processus de dveloppement est divis en tapes indpendantes, conscutives ou non. Chaque tape donne lieu une revue et produit un document b) Les modles bass sur le risque : modle en spirale Le modle en spirale de Boehm met en uvre une valuation rgulire des risques lis au projet permettant la mise en uvre de solutions techniques pour annihiler ou contrer ces risques. Cette valuation englobe les autres approches. Un cycle de spirale utilise : Un modle de dveloppement en cascade (quand un risque dintgration est identifi) ; Le prototypage quand le risque est li lacceptation de linterface utilisateur par le client, par exemple. 3. Les rfrentiels La fabrication dun logiciel de qualit respectant les contraintes de budget et de dlais ncessite : le choix dune architecture ; la mise en uvre de mthodes, de techniques, de standards, des normes et des outils en vigueur au sein de lorganisation. Ces mthodes, techniques, standards, normes, outils concernent aussi bien : la production de composants logiciels (dfinition des besoins, conception, ralisation, tests,...) ; le contrle (planification, valuation,...) du processus de production.

4. Le cycle de dveloppement 4.1 Les phases du cycle de dveloppement Le cycle de dveloppement de projet logiciel se compose de quatre phases : - Phase de pr-tude ; - Phase dlaboration ; - Phase de construction ; - Phase de transition. Chaque tape sachevant respectivement par les aboutissements suivants : - Vision ; - Architecture ; - Fonctionnalits ; - Livraison.
Synthse Thierry IRIE 9

Dclinaison des diffrentes tapes : Pr-tude : Il sagit de la dfinition de la porte du projet et dveloppement des cas. Vision : Il sagit de glossaire, de la dtermination des parties prenantes et des utilisateurs, Dtermination de leurs besoins, Besoins fonctionnels et non fonctionnels, Contraintes de conception. Elaboration : Il sagit de la planification du projet, spcification des caractristiques, des fondements de larchitecture Architecture : Il sagit de document darchitecture logicielle, de diffrentes vues selon la partie prenante, dune architecture candidate, de comportement et de conception des composants du systme. Construction : Il sagit de construction du produit. Transition : Il sagit ici de la prparation du produit pour les utilisateurs. 4.2 Les itrations du cycle de dveloppement Une itration est une squence dactivits selon u n plan prtabli et des critres dvaluation, rsultant en un produit excutable.

Synthse Thierry IRIE

10

Synthse Thierry IRIE

11

4.3 Les intervenants Les principaux intervenants du cycle de dveloppement sont les gestionnaires du projet et les spcialistes techniques.

5. Dtail des modles et activits de dveloppement Les modles de dveloppement permettent de : Organiser les diffrentes phases du cycle de vie pour l'obtention d'un logiciel fiable, adaptable et efficace ; Guider le dveloppeur dans ses activits techniques ; Fournir des moyens pour grer le dveloppement et la maintenance (ressources, dlais, avancement, etc.). Plusieurs modles sont proposs : Modle code-and-fix ; Modle (linaire) en cascade ; Modle en V ; Modle en spirale ; ... Processus unifi. 5.1 Modle en cascade Ce modle permet latteinte de lobjectif par atteinte ordonne de sousobjectifs. Les activits sont reprsentes dans des processus spars. Le Processus ici est squentiel: Chaque tape doit tre termine avant que la suivante commence. Des proccupations en rapport avec les livrables sont mises : la fin de chaque tape, le livrable est vrifi et valid. Vrification: le livrable est-il correct ? Validation: est-ce le bon produit ? (Compar lnonc de ltape). 5.2 Modle en cascade Ce modle est dclin par lenchainement des tapes conjointement aux arcs du schma ci-dessous :

Synthse Thierry IRIE

12

5.3 Modle en V Le modle en V se caractrise par les lments suivants : Une amlioration du modle en cascade ; Il met en vidence la symtrie et la relation quil y a entre les phases du dbut du cycle de vie et celles de fin : Les phases du dbut doivent tre accompagnes dune planification des phases de fin : Lors de la planification, on dveloppe et documente les plans de test.

5.4 Modle en spirale Il se caractrise par les points suivants : La mise de laccent sur lvaluation des risques. A chaque tape, aprs avoir dfini les objectifs et les alternatives, celles-ci sont values par diffrentes techniques (prototypage, simulation, ...), ltape est ralise et la suite est planifie. Le nombre de cycles est variable selon que le dveloppement est classique ou incrmental.

5.5 Processus unifi Ce modle prsente les particularits suivantes :

Synthse Thierry IRIE

13

Le regroupement des activits mener pour le dveloppement dun systme logiciel, bas sur la notion dobjets pilot par les cas dutilisation (Il faudra dans ce cas bien comprendre les dsirs et les besoins de ses futurs utilisateurs). Un cas d'utilisation est une fonctionnalit du systme produisant un rsultat satisfaisant pour l'utilisateur. Les cas d'utilisation saisissent les fonctionnels et leur ensemble forme le modle des cas d'utilisation qui dcrit les fonctionnalits compltes du systme. Ce modle est centr sur larchitecture (cest--dire les diffrentes vues du systme qui doit tre construit). Il est Itratif et incrmental. Itratif : Pour parler de la croissance et laffinement successifs dun systme par le biais ditrations multiples, retours en arrire et adaptation cycliques Incrmental : Pour parler de dcoupage du travail en plusieurs parties qui sont autant de mini-projets. Chaque mini-projet reprsente une itration ou tape de courte dure (1 mois) qui donne lieu un incrment. Le rsultat de chaque itration est un systme test, intgr et excutable.

5.6 Activits de dveloppement Elles sont dcrites de faon indpendante en indiquant leur rle, utilisent et produisent des artefacts. Selon le modle, une activit peut jouer un rle plus ou moins important et parfois ne pas exister du tout. Les activits de dveloppement concernent : Planification (tude de la faisabilit) ; Spcification des besoins (Requirement analysis) ; Analyse (Spcification formelle) ; Conception (Spcification technique) ; Implmentation (Codage) et tests unitaires ; Intgration et tests densemble ; Livraison ; Maintenance. a) Planification Objectif :

Synthse Thierry IRIE

14

identification de plusieurs solutions et valuation des cots et bnfices de chacune d'elles. Activit : simulation de diffrents scnarios de dveloppement Rsultats : Rapport danalyse prliminaire et un schma directeur contenant : La dfinition du problme et les diffrentes solutions tudies, avec, pour chacune delles, les bnfices attendus, les ressources requises (dlais, livraison, etc.). b) Spcification des besoins Objectifs : dfinition de ce que doit faire le logiciel. Activits : Description du problme traiter afin didentifier les besoins de l'utilisateur, de spcifier ce que doit faire le logiciel : informations manipules, services rendus, interfaces, contraintes ; Mise en uvre des principes : abstraction, sparation des problmes, sparation des besoins fonctionnels. Rsultats : cahier des charges et plan qualit. un dossier d'analyse comprenant les spcifications fonctionnelles et non fonctionnelles du produit. une bauche du manuel utilisateur pour les non informaticiens. une premire version du glossaire contenant les termes propres au projet. un plan de test du futur systme (cahier de validation). c) Analyse Objectifs : Analyse dtailles de toutes les fonctions et autres caractristiques que le logiciel devra raliser pour lusager, telles que vues par lusager. Activits : Rpondre au Que fait le systme ? , Modlisation du domaine dapplication Analyse de lexistant et des contraintes de ralisation Abstraction et sparation des problmes, sparation en units cohrentes Rsultats : Dossier danalyse et plan de validation Modle du domaine Modle de lexistant (ventuellement) Dfinition du modle conceptuel. Plan de validation, dossier de tests dintgration d) Conception Objectifs : Dfinition de larchitecture gnrale du logiciel. Spcif ication de la manire dont chacun des composants du logiciel sera ralis et comment ils interagiront. Activits :

Synthse Thierry IRIE

15

Rpondre au Comment raliser le systme Dcomposition modulaire, dfinition de chaque constituant du logiciel : informations traites, traitements effectus, rsultats fournis, contraintes respecter Rsultats : dossier de conception + plan de test global et par module proposition de solution au problme spcifi dans lanalyse organisation de lapplication en modules et interface des modules (architecture du logiciel), description dtaille des modules avec les algorithmes essentiels (modle logique), structuration des donnes. e) Implmentation Objectifs : Ralisation des programmes dans un (des) langage(s) de programmation, Tests selon les plans dfinis lors de la conception. Activits : traduction dans un langage de programmation, Mise au point (dbogage). Rsultats : dossiers de programmation et codes sources. Collection de modules implments, non tests, Documentation de programmation qui explique le code. c) Tests unitaires Objectifs : test spar de chacun des composants du logiciel en vue de leur intgration Activits : ralisation des tests prvus pour chaque module les tests sont faire par un membre de l'quipe n'ayant pas particip la fabrication du module Rsultats : rsultats des tests avec les jeux dessais par module selon le plan de test. d) Intgration et test du systme Objectifs : Intgration des modules et test de tout le systme. Activits : Assemblage de composants tests sparment ; Dmarche dintgration (ascendante, descendante ou les deux) ; Conception des donnes de tests ; Tests Alpha : l'application est mise dans des conditions relles d'utilisation, au sein de l'quipe de dveloppement (simulation de l'utilisateur final) ; Documentation des lments logiciels. Rsultats : Rapports de test ; Manuel dutilisation.

Synthse Thierry IRIE

16

e) Livraison, maintenance, volution Objectifs : Livraison du produit final l'utilisateur, Suivi, modifications, amliorations aprs livraison. Activits : Tests Bta : distribution du produit sur un groupe de clients avant la version officielle, Livraison tous les clients, Maintenance : corrective, adaptative, perfective. Rsultats : la version finale du manuel utilisateur, les traces dvolution du systme, les rapports dexploitation Produit et sa documentation Trace dexploitation et dvolution 6. Dclinaison des diffrentes tapes de la Gestion de projets informatique 6.1 Avant-projet Cette tape est caractrise par deux principales activits : LEstimation ; La Planification. a) Estimation Lestimation permet de connatre : - Le cot dune vue de lesprit qui deviendra ralit au bout dun temps fini. - Leffort de dveloppement (cot), la dure du projet (temps), autre (quipement, voyage, formation), ajouter (la logique des calculs, les hypothses) Elle seffectue tout au long du cycle de vie du projet. Dans sa mise en uvre, il faudra viter de : Faire trop prcis (travailler avec des marges derreur importantes) ; Sous-estimer (tre exhaustif dans la liste des choses estimer) ; Sur-estimer (ne pas intgrer systmatiquement tous les cots possibles) ; Confondre objectif et estimation (rsister il ne faut pas que a cote plus de ) ; Vouloir tout estimer (savoir avouer son ignorance). Qualit de lestimation Rendue dans les dlais, homogne en prcision, honnte, complte, hypothses explicites, raliste, proche du cot rel. Qualits de lestimateur Utile au client, organis, objectif, comptent, cratif, raliste, manie lanalogie Limites Manque de donnes historiques pour faire l'estimation, nouvelles technologies, manque d'exprience en estimation, oublis, productivit n'est pas 40 heures/ semaine , optimisme non fond. a.1) Dmarche et conseils

Synthse Thierry IRIE

17

Dmarche : Entres : objectifs techniques, objectifs de dlais, environnement, priode, historique, rfrences Sorties : estimation Itrations : augmenter linformation et comparer avec le rsultat Conseils : Toute information est bonne prendre et classer Les projets dj raliss sont la meilleure source (tableau de bord) Exploiter les offres de ses fournisseurs Adhrer aux associations professionnelles Lire les revues spcialises de sa profession tre organis, tre cratif, affter ses outils Constituer une check-list Vrifier ses estimations Remettre jour ses donnes a.2) Mthodes destimation Il existe plusieurs mthodes destimation. Nous pour citer les mthodes : Par analogie : Exploration des expriences passes, catalogue des projets et estimations passes. Ce qui est analys concerne : taille, dure, effort, complexit, cot. Modle paramtrique : Les estimations sont bases sur des modles mathmatiques reposant sur divers paramtres : COCOMO, SLIM, PRICE-S, SoftCost, Oracle : Equipe dexperts, atteinte dun consensus par ngociation PERT : Estimations reposant sur lhypothse dune rpartition norm ale des estimations ; Raliser plusieurs estimations avec une mthode par analogie ou oracle la pire (l), la moyenne (m), la meilleure (h) ; Effort = (l+4m+h)/6 Bottom-up: Les estimations par analogie, PERT, paramtrique, oracle sont faites par activit ou composant lmentaire. Puis consolides jusquau sommet du projet. N.B. : Aucune technique nest meilleure ou pire que les autres. Utiliser plusieurs techniques en parallle et comparer les rsultats : si trop de diffrence, augmenter la quantit dinformations prises en compte. Cas de la mthode dAlbrecht ou Mthode des Points de fonction - Taille du logiciel : La mthode dAlbrecht ou mthode des Point de fonction se charge de la mesure du montant de fonctionnalit (taille du logiciel) en sappuyant sur cinq (5) types de fonctionnalits : Input, Output, Inquiry, Internal Logical File, External Interface File. Et lon dtermine par la suite le nombre de fonctions (FC = nombre de fonctions) en fonction des pondrations associes aux fonctionnalits prcdemment dtermines.

Synthse Thierry IRIE

18

Un ajustement est fait selon leur complexit ci partir de 14 facteurs nots de 0 (pas dinfluence) 5 (fondamental) ; les 14 fonctions tant entre autre : Communication par message, distribution de donnes ou de fonctions, haut taux de transaction, calcul complexe, conception multi-sites, conception facilement maintenable, FP = FC * PCA PCA = 0,65+0,01 Somme(ci) KLSL = -5 + 0,2 FP Types de fonctionnalits Input (entre utilisateur) Entre de donne ou de contrle qui requiert un traitement crans, transactions, fichier de donnes, etc. Output (sortie utilisateur) Sortie de donne ou de contrle aprs un traitement du systme crans, transactions, fichier de donnes, etc. Internal files (fichiers internes) Regroupement logique de donnes ou de contrle interne au systme Bases de donnes, rpertoires, etc. External interface files (fichiers externes) Fichier ou excutable qui sortent des limites du systme Bibliothques, bases de donnes externes, paquetages gnriques, etc. Inquiry (requtes) Entre ou sortie d'une requte demandant une rponse immdiate du systme Interruptions, appels, etc. - Facteurs dinfluence Interconnections Distribution des fonctions Performance Utilisation oprationnelle lourde Taux de transaction Entre de donnes en ligne Facilit dutilisation Mise jour en ligne Traitements complexes Rutilisation du code Facilit d'installation Facilit d'opration Sites multiples Flexibilit Effort, Dure et Taille : Effort ou charge : Leffort ou la charge reprsente la quantit de travail ncessaire, indpendamment du nombre de personnes qui vont raliser ce travail. Il permet dobtenir un cot prvisionnel. Leffort sexprime en homme/jour, homme/mois ou homme/anne. Un homme/mois (HM) reprsente lquivalent du travail dune personne pendant un mois, gnralement 20 jours ; Un homme/mois (HM)=152 heures de travail par mois.

Synthse Thierry IRIE

19

Exemple: Un projet de 60 mois/homme reprsente lquivalent du travail dune personne pendant 60 mois. Si on value le cot du mois/homme 12 millions de F.CFA en moyenne, le projet sera estim 720 millions de F.CFA. La taille : On mesure la taille des projets leur charge : Si Charge < 6 HM : trs petit projet Si 6 HM< Charge <12 HM : petit projet Si 12 HM< Charge <30 HM : projet moyen Si 30 HM < Charge < 100 HM : grand projet Si Charge > 100 HM : trs grand projet La dure : La dure dpend du nombre de personnes. Exemple : 60 HM peut correspondre : 1 personne pendant 5 ans 5 personnes pendant un an 10 personnes pendant 6 mois 60 personnes pendant 1 mois Homme-mois Un homme-mois est lunit de mesure de leffort : Un homme pendant un mois Deux hommes-mois = 2 hommes pendant 1 mois, ou 1 homme pendant deux mois Selon Brooks : Lhomme-mois comme unit pour mesurer la taille dun travail est un mythe dangereux et trompeur. Il implique que les hommes et les mois sont interchangeables. Les hommes et les mois sont des biens interchangeables seulement lorsquune tche peut tre partitionne entre plusieurs employs sans quil faille une communication entre eux . Cas de la mthode COCOMO

Cest un modle paramtrique et dont lHypothse se dcline par les besoins du logiciel sont relativement stables, le projet est gr la fois par le client et par le fournisseur. La Formule destimation est : Effort = A (KLSL) b KLSL : Kilo Lignes Sources Livres : ligne source quelque soit le nombre dinstructions par ligne, sans tenir compte des commentaires ni du logiciel support A et b estimes partir de lanalyse des historiques A et b dpendent des trois classes de projet : o Organique car caractris par de petites quipes (faible communication, distribution efficace du travail, ), un environnement stable, des applications bien comprises ; o Semi-dtach car chaque quipe est de taille moyenne (personnes exprimentes dbutants) et les problmes ne sont pas tous matriss ; o Dtach car caractris par une grande quipe, rpartie et un nouvel environnement. Pour la variante COCOMO dite simple, nous avons les indicateurs suivants :

Synthse Thierry IRIE

20

La charge HM : Homme-mois = 152 h Organique : HM = 2,4 (KLSL) 1,05 Semi-dtach : HM = 3,0 (KLSL) 1,12 Dtach : HM = 3,6 (KLSL) 1,20

Attention : Le nombre de personnes employes sur un projet nest pas uniforme pendant le temps de dveloppement (Effectif crot jusqu limplmentation, dcrot ensuite) Le temps de dveloppement TDEV : Organique : TDEV = 2,5 (HM) 0,38 Semi-dtach : TDEV = 2,5 (HM) 0,35 Dtach : TDEV = 2,5 (HM) 0,32

Pour la variante COCOMO dite intermdiaire, les facteurs suivants sont pris en compte : Point de dpart : HM et TDEV sont du modle simplifi Introduction de quinze facteurs correctifs, valus de VeryLow XtraHigh Pour le projet : Fiabilit requise du logiciel Taille de la base de donnes Complexit du produit Pour les contraintes de lenvironnement Contraintes de temps dexcution Contraintes de place mmoire Stabilit de la machine virtuelle (matriel + logiciel) sur lequel le logiciel est dvelopp Systme de dveloppement interactif ou non Pour le personnel Aptitude lanalyse

Synthse Thierry IRIE

21

Exprience du domaine Exprience de la machine virtuelle Aptitude la programmation Exprience du langage Pour les mthodes Mthode de programmation moderne Outils logiciels Dure de dveloppement b) Planification La planification est un processus dynamique tenant compte de la situation relle, des nouvelles informations acquises. Cest aussi un outil incontournable pour la gestion du projet. Elle permet de : dfinir les travaux raliser ; fixer des objectifs ; coordonner les actions ; matriser les moyens ; diminuer les risques ; suivre les actions en cours ; rendre compte de l'tat d'avancement du projet. Nous pouvons distinguer trois types de planification : - La planification structurelle ; - La planification oprationnelle ; - La planification budgtaire. Chacune delle rpondant des proccupations particulires. Nous reprsentons ci-dessus un schma de synthse des approches nonces.

b-1) La Planification structurelle Rle : La planification structurelle consiste : Identifier les travaux complter ;

Synthse Thierry IRIE

22

Traduire la dfinition du projet en une liste de tches accomplir ; Prparer une liste exhaustive, documente et structure des travaux dont laccomplissement est ncessaire la production des biens livrables du projet. Elle ncessite la constitution dune base de donnes des travaux qui sert de base aux autres tapes de planification. Cette base est le principal instrument de communication entre les intervenants. La planification structurelle permet galement lidentification et description des lots de travail principaux de mme que celles des tches lmentaires qui y affrant. Les Etapes : La planification structurelle se dcline en plusieurs tapes : Planification structurelle sommaire Elle consiste subdiviser le projet en lots de travail ; un lot tant un bien livrable du projet. Dans cette tape, il faudra toujours prvoir les lots de support pour tches ponctuelles. Planification structurelle dtaille Ici, il faudra subdiviser les lots de travail principaux jusqu lidentification de tches lmentaires et effectuer une reprsentation laide dun organigramme de tche (Work Breakdown Structure) Conformit et compltude A ce niveau, on doit avoir suffisamment confiance dans le caractre exhaustif de la liste des tches pour tre assur que, une fois complte de faon suffisante chacune des tches lmentaires y apparaissant, le produit vis est effectivement ralis et conforme aux exigences initiales. Exemples de reprsentation :

Product Breakdown Structure Dans cette reprsentation nous avons un dcoupage du systme en units physiques hirarchises.

Synthse Thierry IRIE

23

Ici, nous avons une description structure de toutes les tches du projet, rapportes au dcoupage du produit. b-2) Planification oprationnelle Rle : La planification oprationnelle consiste : Crer un rseau ordonnanc dactivits partir des tches de lorganigramme technique ; Estimer de la dure dune activit et des ressources requises pour la complter ; Identifier le chemin critique dans un rseau ordonnanc et calculer les marges totales, libres et dindpendance ; Utiliser les diffrents modes de prsentation des rsultats. Caractristiques : Elle prsente les caractristiques suivantes : Forme la base pour la planification et la prdiction dun projet ; Facilite le choix des ressources pour complter un projet lintrieur des chanciers et du budget ; Fournit les renseignements ncessaires pour prendre des dcisions ; Identifie les dpendances entres les activits ; Identifie le chemin le plus long : le chemin critique ; Permet deffectuer lanalyse des risques dchancier. Dans une planification oprationnelle, Toute tche est assigne une personne ; Tout participant est inform de : ses rles et responsabilits ; son degr dautonomie et dautorit ; des rles et responsabilits des autres. Les donnes de dpart sont : Organigramme technique ; Processus de dveloppement. Exemple de reprsentation dune planification oprationnelle :

Synthse Thierry IRIE

24

Activits de la planification oprationnelle : La planification oprationnelle se base sur une organisation dans le temps des activits caractrise par les lments suivants : Activits/Dpendances : Contraintes temporelles entre activits, Structure logique des activits. Ressources associes aux activits ; Dure dune activit : dure dans le meilleur des cas, ajout dun dlai de garantie, pondration pour tenir compte de limprvu. Les diffrentes activits sont cartographies laide de diagrammes (Pert, Gantt, etc.). Diagramme Pert Le diagramme Pert est un graphe ordonn dcrivant les contraintes de prcdence logique des activits. Il permet de : Lister les tches ; Indiquer la charge de chacune ; Prciser les liens de dpendance entre tches ; Classer les tches selon leur rang. Diagramme de Gantt Le diagramme de Gantt prsente un calendrier sur lequel chaque activit est reprsente par une barre grise dbutant la date de dbut au plus tt et terminant la date de fin au plus tard, sur laquelle glisse une barre blanche correspondant aux dates relles de dbut et de fin. Exemple de reprsentation dun diagramme de Gantt :

Synthse Thierry IRIE

25

6.2 Suivi de projet Rle : Le suivi de projet consiste valuer la situation relle du projet, la comparer la situation prvue au plan dexcution et prendre les dcisions ncessaires pour corriger la situation, si des carts sont observs ou prvus.

La matrise des ressources et la gestion de la qualit du produit sont des fonctions en cours de ralisation du projet quelle que soit la phase atteinte dans la progression du projet. Elles impliquent une base de comparaison que constitue le plan de ralisation, produit de la planification du projet et de lutilisation des ressources. Pour ce faire, il est ncessaire de mettre en place un processus de suivi et de revues rgulires entre le chef de projet et les membres de l'quipe. De mme un "journal de bord" est tenu jour. Il permet de garder une trace : des informations communiques ; des problmes rencontrs ; des dcisions prises ; des responsables dsigns pour mener bien les actions ; la date de ralisation de l'action. Activits de suivi de projet Plusieurs activits jalonnent le suivi de projet. Nous pouvons citer : - Matrise des ressources La matrise des ressources implique la capacit de (d) : Expliquer les difficults rencontres au plan technique ;

Synthse Thierry IRIE

26

Expliquer les retards et les dpassements de cot ; Proposer des mesures correctives, den valuer les rpercussions et de les mettre rapidement en uvre ; Rpondre des conditions changeantes du milieu (le projet, son environnement). Cette capacit demande davoir des points de repre : Cest la planification du projet. - Contrle Le contrle est une activit dacquisition des informations sur la progression du projet. Elle concerne donc : Ce qui est complt ; Les ressources effectivement utilises ; La date de dbut et de fin. Le contrle se penche aussi sur ce qui est en cours. Cest--dire le pourcentage (%) davancement savoir la date de dbut, les ressources utilises (matriaux, quipement, main duvre). Les questions rsoudre dans cette activit sont : Quoi documenter ? quelle frquence ? Avec quelle rsolution ? Problmes rencontrs ? - Suivi de lavancement Le suivi de lavancement se ralise par un enchanement de plusieurs activits sousjacentes. Il sagit entre autre de : o Analyse Le but de lanalyse est de vrifier si la situation actuelle est telle que prvue. Elle dcline cet effet : La compilation des informations recueillies. A savoir : Le Calcul des cots effectivement engags et dbourss ; La Validation de lestim du % davancement ; La Nature exacte des problmes rencontrs (la recherche des causes). Lanalyse prvisionnelle - valeur acquise. Il sagit en fait de dune comparaison avec la situation prvue. La slection de mesures correctives par la ralisation de propositions et de lanalyse de leffet de mesures correctives et enfin par la ralisation de recommandations. o Causes dcart Cette activit a pour objet de faire ressortir les facteurs de performance technique, les cots, les chanciers et les indicateurs de la mise en uvre. Performance technique Il sagit ici de mettre en relief les lments suivants : Occurrence dun problme technique imprvu ; Difficults techniques majeures dont la mise en relation de diverses composantes ; Problme de fiabilit dans les matriaux, les quipements achets ; Changement impos par le client ; Apparition dun nouveau produit sur le march ; Rvision des spcifications techniques. Cots Il sagit ici de mettre en relief les lments suivants :

Synthse Thierry IRIE

27

Difficult de financement ; Difficults techniques imposant lutilisation de plus de ressources humaines ou dquipement ; Majoration des cots des matriaux, de la main-duvre, de lnergie, etc. Monitoring erron ; Dlai dans la mise en uvre des mesures correctives ; Estimation initiale incorrecte. chanciers Il sagit ici de dcliner les indicateurs suivants : Dure plus longue que prvue pour complter une activit, pour rsoudre un problme technique ; Dure requise pour rsoudre un problme nouveau ; Mauvaise estimation de la dure des activits raliser ; Pnurie de ressources humaines, matrielles et dquipement ; Rpercussions des retards de ralisation des activits qui prcdent sur la dure des activits venir, sur leur programmation, etc. (Boucle de rtroaction positive). Mise en uvre Il sagit ici de veiller lapplication effective des mesures suivantes : Approbation des mesures retenues ; Communication aux personnes concernes ; Mise en application. - Conseils lmentaires Afin de pouvoir sassurer de la bonne marche du suivi de lavancement du projet, il est important de tenir compte des conseils suivants : Toujours donner lheure juste ; Sassurer que le cot du contrle, de lanalyse et de la mise en uvre demeure infrieur aux bnfices esprs du suivi et du contrle des ressources ; Ne prendre que les informations pertinentes la matrise des ressources et de la qualit du produit ; Vrifier que le contrle et lanalyse se font rapidement pour que les mesures correctives demeurent dactualit ; Organiser le contrle autour des biens livrables. 6-3. Clture de projet Invitablement, les projets se terminent; il est dans la dfinition mme dun projet quil ne dure quun temps prcis dans la vie dune organisation. Les faons dont les projets se terminent peuvent toutefois varier. Aussi pouvons-nous distinguer : - La fin normale dun projet ; - La fin normale dun projet et intgration lorganisation ; - Fin dun projet avort.

Synthse Thierry IRIE

28

Fin normale dun projet La plupart des projets se terminent favorablement avec la livraison du produit ou du systme au client; ce client peut tre linterne de lorganisation, projet dimplantation dquipement dans une usine, ou lexterne, projet de construction, projet de sous traitance industrielle. Fin normale dun projet et intgration lorganisation Dans certains cas de projets, surtout lorsque le client est interne, il arrive trs frquemment quon invite les membres de lquipe devenir ou redevenir membres part entire lorganisation. On parle donc dintgration des rsultats et des ressources du projet. Fin dun projet avort Il peut arriver quon doive arrter un projet pour des questions techniques, budgtaires ou lgales. Des procdures doivent alors tre prises pour compenser, sil y a lieu, la ou les parties lses. En situation normale, clturer un projet dsigne une srie d activits que doit raliser les responsables du projet. Lutilisation de listes de vrification est frquente lors de la fermeture de dossiers. De mme, il est important de veiller ce que les routines de clture suivantes soient effectivement accomplies : Sassurer de la fin de lensemble des travaux, incluant les tches en sous-traitance ; Validation du client comme quoi il a reu le produit/systme et les autres livrables ; Sassurer que la documentation est jour et que les rapports de cltur e ont t raliss (si requis) ; Rgler les dernires transactions financires (facturation) ; Relocalisation du personnel, des quipements, des matriaux ; Consolider la documentation conserver. 6-4 Gestion des activits transverses Les activits transverses sont de quatre ordres : La gestion de configurations ; Les documentations ; Les outils ; Les Hommes. a) Gestion des versions et des volutions Pour ce qui est de la gestion des versions et des volutions des applicatifs, une approche spcifique est considrer : - Appliquer une numrotation trois : 1er chiffre : Cest un numro de versions majeures du produit, dont la sortie saccompagne de progrs importants au niveau des fonctionnalits, et/ou changement notable denvironnement dutilisation ou de portabilit ; 2me chiffre : Cest un numro des versions mineures. Lincrment est ralis chaque fois que lquipe de dveloppement libre une version du produit qui corrige des bugs attendus par les clients (mais non bloquants), et apporte des modifications lgres ; 3me chiffre : numro des corrections, versions rsultant de la maintenance Pour ce qui est des versions, une approche de fait est habituellement de mise dans leur notifications :

Synthse Thierry IRIE

29

- Version Alpha : Il sagit en fait dune version termine en cours de test et de revue de qualit. - Version Bta : Il sagit en fait dune version alpha valide en test auprs dun panel de clients privilgis.

b) Documentations Nous distinguons plusieurs types de documentation : Documentation de gestion du projet Il sagit de : Plannings, plans, estimations ; Rapports ; Dfinitions de standards ; Documents de travail ; Courriers (mails). Documentation Technique Suivant quelle est utilise par les utilisateurs ou par lquipe technique, nous avons : Variante utilisateur : o Manuel dinstallation, o Manuel dadministration, o Manuel dutilisation, o Manuel de rfrence. Variante systme : o Cahier des charges, o Dossier danalyse et de conception du systme, o Dossier darchitecture du systme, o Dossier darchivage des programmes et des listings, o Documents de validation, o Documents de tests, o Guide de maintenance. Prsentation synthtique de documentations

Synthse Thierry IRIE

30

Synthse Thierry IRIE

31

7. Les outils Plusieurs outils sont habituellement utiliss dans le cadre de la conduite et la gestion de projet : Les outils ddis des tches spcifiques ; Les ateliers de gnie logiciel (AGL) : Analyse et conception ; Programmation, prototypage ou dveloppement rapide (RAD) ; Construction dinterface homme-machine ; Vrification ; Documentation, version, collaboratif. Les Environnements intgrs pour un support tout le dveloppement.

Synthse Thierry IRIE

32

Chapitre 3 : Lapproche CMMI pour le dveloppement

1. Contexte et historique Dans les annes 1980, le Dpartement de la Dfense des tats-Unis (DoD) a demand l'laboration d'un rfrentiel de critres lui permettant d'valuer ses fournisseurs de logiciels. Aprs une lente maturation, le SEI (Software Engineering Institute) financ par le DoD a prsent en 1991 le Capability Maturity Model (CMM). Ce modle de rfrence ne concerne que les bonnes pratiques du gnie logiciel. Aprs un fort engouement pour ce modle, d'autres modles similaires ont vu le jour, tels que :

SE-CMM (pour System Engineering) ; SA-CMM (pour Software Acquisition) ; IPD-CMM (pour Integrated Product Development) ; People CMM pour le management des ressources humaines ; SS-CMM pour Supplier Sourcing.

Tant et si bien quil fallut rebaptiser le CMM initial en SW-CMM (pour Software). En 2001, le SEI a propos une nouvelle version de son modle, le CMMI ( Capability Maturity Model Integration) qui englobe les bonnes pratiques des autres modles, sauf la gestion des ressources humaines qui n'est pas encore considre (version 1.1). La version actuelle du modle a t ractualise en 2006 (version 1.2). Cette dernire version du CMMI tend simplifier le modle et amliore la prise en compte des composants de type matriel. La version 1.3 est en cours dlaboration. Le CMMI-DEV est un modle de processus (rfrentiel de bonnes pratiques) pour la ralisation de tout type de produit (ou systme). C'est cependant dans le dveloppement et la maintenance de logiciel qu'il est le plus utilis. Sa porte utile s'tendant de l'apparition d'un besoin jusqu' la livraison du produit correspondant, il y a d'autres modles utiles pour d'autres domaines du logiciel, par exemple pour les infrastructures et oprations ITIL. Il existe aussi d'autres rfrentiels de bonnes pratiques, par exemple pour la petite maintenance du logiciel. CMMI-DEV 1.2 regroupe 22 domaines de processus Process Area (PA). Deux modles de reprsentation coexistent, correspondant deux points de vue lgrement diffrents. Les deux reprsentations sappuient sur les mmes PAs mais ceux-ci sont utiliss diffremment : Reprsentation continue : La reprsentation continue privilgie de regarder lvolution au niveau de chaque domaine de processus (PA) et dy associer des stades de dveloppement de la capacit du processus; Reprsentation tage : La reprsentation tage prconise une volution par tage au niveau de toute lorganisation de dveloppement. Elle permet ainsi de dfinir le niveau de maturit (ML) de lorganisation.

Synthse Thierry IRIE

33

2. Les niveaux daptitude et de maturit Les niveaux sont employs dans le CMMI pour dcrire une dmarche volutive recommande une organisation qui souhaite amliorer les processus quelle applique pour dvelopper et maintenir ses produits et services. Les niveaux peuvent galement rsulter de lactivit de cotation des valuations1. Les valuations peuvent concerner des organisations constitues dentreprises entires (habituellement petites) ou de plus petits groupes tels quun groupe de projets ou une division au sein de lentreprise. Le CMMI propose deux voies damlioration. Lune permet aux organisations damliorer progressivement les processus dun ou de plusieurs domaines quelle a choisis. Lautre permet damliorer un ensemble de processus apparents en traitant de manire incrmentale des ensembles de domaines de processus successifs. Ces deux voies sont associes deux types de niveaux correspondant. Pour la reprsentation continue, nous employons le terme de niveau daptitude . Pour la reprsentation tage, nous employons celui de niveau de maturit . Indpendamment de la reprsentation que vous choisissez, le concept de niveau reste le mme. Les niveaux caractrisent le passage dun tat mal dfini un tat qui emploie des informations quantitatives afin de dterminer et de grer les amliorations ncessaires pour rpondre aux objectifs stratgiques dune organisation. Pour atteindre un niveau donn, une organisation doit satisfaire tous les objectifs appropris du domaine de processus ou de lensemble des domaines de processus viss par lamlioration, indpendamment du fait quil sagisse de niveau daptitude ou de niveau de maturit. Les deux reprsentations fournissent des mthodes de mise en uvre de lamlioration de processus pour atteindre les objectifs stratgiques. Elles fournissent toutes deux le mme contenu essentiel et emploient les mmes composants du modle. 2-1 Les niveaux de maturit ou reprsentation tage

Comme le montre la figure, la reprsentation tage exprime lvolution des pratiques de dveloppement en fonction dune vue organisationnelle. La premire tape est de dfinir le primtre observer : lorganisation . Puis, on observe son comportement au regard des 5 niveaux de maturit (ML) regroupant les 22 PAs :

Synthse Thierry IRIE

34

ML 1 : Niveau Initial o les processus sont non rptables et non matriss. ML 2 : Niveau Gr o les processus sont planifis et rptables. Le ML 2 traduit la mise en oeuvre effective de pratiques de base au niveau des projets mais sans harmonisation au niveau de lorganisation (par exemple chaque projet gre diffremment sa planification, ses configurations); il sadresse essentiellement aux Chefs de Projet. ML 3 : Niveau Dfini o les processus sont organiss, ractifs et matriss. Le ML 3 traduit le dploiement harmonis de pratiques dfinies au niveau de lorganisation ; il sadresse toute la population et met laccent sur lengineering produit et lorganisation centrale. ML 4 : Niveau Quantifi o les processus sont mesurs et contrles. Le ML 4 traduit une gestion quantitative des processus, base sur des analyses statistiques (les performances de lorganisation sont prvisibles). ML 5 : Niveau Optimis o lorganisation est en amlioration continue. Le ML 5 traduit la maturit de lorganisation o veille technologique et amlioration continue concourent lexcellence du livrable.

Synthse Thierry IRIE

35

Synthse Thierry IRIE

36

Chacun des Processus Areas (PA) doit rpondre des objectifs qui peuvent tre : Spcifiques (SG), intrinsquement relis la nature de lactivit couverte par le PA; Gnriques (GG), transversaux et identiques dun PA lautre. Ces objectifs se dclinent en pratiques qui dcrivent le comportement attendu de la part de lorganisation ou dun projet (Pratique spcifique (SP), Pratique gnrique (GP)). Afin de prouver la bonne implmentation de chacune des pratiques, des preuves PII (Practice Implementation Indicator) doivent tre collectes.

Synthse Thierry IRIE

37

2-2 Les niveaux daptitude ou reprsentation continue La reprsentation continue utilise une vision cible de lvolution des pratiques de dveloppement. Contrairement la reprsentation tage qui regroupe sous des niveaux de maturit les diffrents PAs, la reprsentation continue exprime la capacit de chaque PA au sein de lorganisation suivant une chelle de 6 niveaux. Cette reprsentation permet lentreprise dentreprendre damlioration sur un bouquet de PAs quelle a slectionn. un programme

Une dcomposition propose par le SEI regroupe les 22 Process Area en 4 catgories (comme le montre le tableau prcdent) dfinissant le CMMI Framework : Engineering Process Areas (Ingnierie) : Ils couvrent les activits de dveloppement et de maintenance qui sont partages entre les diffrentes disciplines dingnierie (ingnierie systme, ingnierie logiciel) Project Management Process Areas (Gestion de projet) : Ils couvrent les activits de gestion de projet lies la planification, au suivi et au contrle du projet Support Process Areas (Support) : Ils couvrent les activits qui soutiennent le dveloppement et la maintenance du produit. Ce sont des processus qui permettent dexcuter dautres processus. En gnral, ils sadressent des processus lis au projet mais peuvent aussi sadresser aux processus de lorganisation. Par exemple, le PA Process and Product Quality Assurance peut tre utilis avec tous les autres PAs pour fournir une valuation objective des processus et des produits de travail dcrits dans tous les secteurs de processus Process Management Process Areas (Gestion des processus) : Ils concernent toutes les activits transversales du projet lies la dfinition, la planification, le rapprovisionnement, le dploiement, lexcution, le contrle, la direction, lvaluation, la mesure et les processus damlioration

3. Les domaines de processus Gestion de projet de CMMI


Les domaines de processus de la catgorie Gestion de projet couvrent les activits relatives la planification, la surveillance et au contrle du projet. Les domaines de processus de cette catgorie sont les suivants : Planification de projet ; Surveillance et contrle de projet ;
38

Synthse Thierry IRIE

Gestion des accords avec les fournisseurs ; Gestion de projet intgre + IPPD2 ; Gestion des risques ; Gestion de projet quantitative. 3-1. Domaines de processus de la gestion de projet basique

Les domaines de processus de la gestion de projet basique traitent des activits relatives ltablissement et la maintenance du plan de projet, l laboration et au maintien des engagements, la surveillance de lavancement au regard du plan, la mise en uvre dactions correctives et la gestion des accords avec les fournisseurs. La figure ci-dessous fournit une vue densemble des interactions entre les domaines de processus de la gestion de projet basique entre eux ou avec dautres catgories de domaines. Comme on le constate, les domaines de processus de la planification de projet incluent llaboration du plan de projet, limplication des parties prenantes concernes, lobtention de lengagement sur le plan et la maintenance de ce dernier. Lorsquon recourt laddition IPPD, les parties prenantes nassurent pas simplement lexpertise technique du produit et du dveloppement de processus, mais galement leurs implications mtiers. La planification dbute avec la dtermination des exigences qui dfinissent le produit et le projet ( Que construire la figure 4.3). Le plan de projet aborde les diverses activits de ralisation et de gestion du projet. Le projet passe en revue les autres plans qui laffectent avec les diverses parties prenantes concernes et tablit avec elles des engagements lgard de leurs contributions au projet. Par exemple, ces plans couvrent la gestion de configuration, la vrification, la mesure et lanalyse. Le domaine de processus Surveillance et contrle de projet inclut les activits de surveillance et de mise en place dactions correctives. Le plan de projet spcifie le niveau de surveillance appropri, la frquence des revues davancement et les mesures employes pour surveiller cet avancement. Lavancement est principalement dtermin par comparaison du statut du projet au plan. Quand le statut rel scarte de manire significative des valeurs attendues, des actions correctives appropries sont mises en uvre. Ces actions peuvent porter sur la rvision de la planification. Le domaine de processus Gestion des accords avec les fournisseurs rpond la ncessit pour le projet dintgrer le travail produit par les fournisseurs. Les sources des produits qui peuvent tre employs pour rpondre certaines exigences du projet sont identifies de manire proactive. Le fournisseur est slectionn et un accord avec le fournisseur est tabli pour le grer. Lavancement et la performance du fournisseur sont suivis grce la surveillance des produits dactivit et des processus slectionns. Laccord avec le fournisseur est rvis si ncessaire. Les revues dacceptation et les tests sont effectus sur le composant produit par le fournisseur.

Synthse Thierry IRIE

39

Domaines de processus de la gestion de projet basique

Synthse Thierry IRIE

40

3-2. Domaines de processus de la gestion de projet avance Les domaines de processus de la gestion de projet avance traitent des activits telles que : tablir un processus ajust partir de lensemble des processus standards de lorganisation ; tablir lenvironnement de travail du projet partir des normes denvironnement de travail de lorganisation ; coordonner les parties prenantes concernes et collaborer avec elles ; grer les risques ; former et soutenir les quipes intgres pour la conduite des projets ; grer quantitativement les processus ajusts du projet. La figure ci-dessous fournit une vue densemble des interactions entre les domaines de processus de la gestion de projet avance ainsi quavec dautres catgories de domaines. Chaque domaine de processus de la gestion de projet avance dpend de la capacit planifier, surveiller et contrler le projet. Les domaines de processus de la gestion de projet basique fournissent cette capacit. Les domaine de processus Gestion de projet intgre tablit et maintient les processus ajusts du projet partir de lensemble des processus standards de lorganisation. Le projet est gr en recourant aux processus ajusts du projet. Le projet utilise les actifs de processus de lorganisation et y contribue. Lenvironnement de travail du projet est dvelopp et maintenu partir des normes denvironnement de travail de lorganisation. La gestion du projet veille ce que les parties prenantes concernes coordonnent leurs efforts en temps utile. cette fi n, elle assure la gestion de limplication des parties prenantes. Elle sintresse galement lidentification, la ngociation et au suivi des dpendances critiques et rsout les problmes de coordination du projet avec les parties prenantes concernes. Avec les additions IPPD, le domaine Gestion de projet intgre +IPPD tablit et maintient une vision partage du projet et une structure dquipes de projets intgres. Les quipes intgres sont ensuite mises en place pour la ralisation du projet, et la coordination des quipes est assure. Bien que lidentification et la surveillance des risques soient abordes dans les domaines de processus Planification de projet et Surveillance et contrle de projet , le domaine de processus Gestion des risques assure une approche continue et long terme de la gestion des risques grce lidentification des paramtres de risques, lvaluation des risques et lattnuation des risques. Le domaine de processus Gestion de projet quantitative applique des techniques quantitatives et statistiques pour contrler la qualit des produits et les performances des processus. Les objectifs de qualit et de performance des processus du projet sont dfinis en fonction des objectifs tablis par lorganisation. Le processus ajust du projet se compose en partie des lments de processus et des sous-processus dont la performance peut tre prvue. Au minimum, il est ncessaire de comprendre la variation de processus subie par les sous-processus vitaux pour atteindre les objectifs de qualit et de performance des processus. Une action corrective est initie quand des causes spciales de variation des processus sont identifies.

Synthse Thierry IRIE

41

Domaines de processus de la gestion de projet avance

4. Les domaines de processus Ingnierie Les domaines de processus de la catgorie Ingnierie couvrent les activits de dveloppement et de maintenance des diverses disciplines de lingnierie. Leur description a t rdige en employant la terminologie de lingnierie gnrale, de sorte que nimporte quelle discipline technique implique dans le processus de dveloppement de produit (par exemple ingnierie logicielle ou construction mcanique) peut les employer loccasion de lamlioration de processus. Les domaines de processus de cette catgorie intgrent galement les processus lis aux diffrentes disciplines de lingnierie au sein dun unique processus de dveloppement, autorisant ainsi une stratgie de lamlioration de processus oriente produit. Une telle stratgie cible les objectifs stratgiques essentiels plutt que les disciplines techniques spcifiques. Cette approche des processus vite efficacement la drive vers une mentalit organisationnelle cloisonne . Les domaines de processus de lingnierie sappliquent la ralisation de nimporte quel produit ou service du domaine de dveloppement (par exemple produits logiciels, produits matriels, services ou processus). La base technique de lIPPD repose sur une approche rigoureuse de lingnierie de systmes qui insre le dveloppement dans le contexte des phases de la vie du produit. Les domaines de processus de lingnierie apportent cette base technique. En outre, la mise en uvre de lIPPD saccompagne damplifications ddies aux pratiques spcifiques des domaines de processus de lingnierie qui mettent laccent sur le dveloppement simultan et se concentrent sur toutes les phases de la vie du produit. Les domaines de processus de la catgorie Ingnierie sont les suivants : Dveloppement des exigences ; Gestion des exigences ; Solution technique ; Intgration de produit ;

Synthse Thierry IRIE

42

Vrification ; Validation.

La figure ci-dessous fournit une vue densemble des interactions au sein des six domaines de processus de lingnierie. Le domaine de processus Dveloppement des exigences identifie les besoins du client et traduit ces besoins en exigences produit. Lensemb le des exigences produit est analys pour produire une solution conceptuelle de haut niveau. Cet ensemble dexigences est alors allou pour laborer un premier jeu dexigences composantes de produit. Dautres exigences qui aident dfinir le produit sont drives et alloues aux composants de produit. Cet ensemble dexigences produit et composants de produit dcrit clairement la performance du produit, les caractristiques de conception, les exigences de vrification et ainsi de suite, dans des termes que le dveloppeur comprend et emploie. Le domaine de processus Dveloppement des exigences fournit des exigences au domaine Solution technique , qui convertit les exigences en architecture de produit, conception de composants de produit et composants de produit proprement dits (par exemple codage ou fabrication). Ces exigences sont galement fournies au domaine de processus Intgration de produit , qui combine les composants de produit et vrifie les interfaces pour sassurer que les exigences dinterface fournies par le dveloppement des exigences sont respectes. Le domaine de processus Gestion des exigences maintient les exigences. Il dcrit les activits dobtention et de contrle des modifications aux exigences et sassure que les autres plans et donnes appropris sont tenus jour. Il permet la traabilit entre les exigences client, les exigences produit et les exigences composants de produit. Le domaine de processus Gestion des exigences sassure que les modifications aux exigences sont reportes dans les plans de projet, les activits et les produits dactivit. Ce cycle de changements peut avoir une incidence sur tous les autres domaines de processus de lingnierie. La gestion des exigences est donc une suite dvnements dynamiques, souvent rcursive. Le domaine de processus Gestion des exigences est fondamental pour la conception dun processus dingnierie contrl et disciplin. Le domaine de processus Solution technique dveloppe les ensembles de donnes techniques relatifs aux composants de produits qui seront employs par les domaines de processus Intgration de produit ou Gestion des accords avec les fournisseurs . Les solutions possibles sont examines dans le but de choisir la conception optimale en fonction des critres tablis. Ces critres peuvent tre sensiblement diffrents suivant les produits, les types de produits, lenvironnement dexploitation, les exigences de performance, les besoins en support et le cot ou les chanciers de livraison. Le choix de la solution dfinitive sappuie sur les pratiques spcifiques du domaine de processus Analyse et prise de dcision . Le domaine de processus Solution technique sappuie sur les pratiques spcifiques du domaine Vrification pour assurer la vrification de la conception et les revues par les pairs avant la construction finale.

Synthse Thierry IRIE

43

Le domaine de processus Vrification sassure que les produits dactivit retenus rpondent aux exigences dfi nies. Ce domaine slectionne les produits dactivit et les mthodes de vrification qui seront employes pour les vrifier au regard des exigences spcifies. La vrification est gnralement un processus incrmental qui commence par la vrification des composants de produits et se conclut habituellement par la vrification des produits entirement assembls. La vrification concerne galement les revues par les pairs. Ces dernires constituent une mthode prouve de rsolution anticipe des dfauts. Elles fournissent en outre une image pertinente des produits dactivit et des composants des produits qui ont t dvelopps et maintenus. Le domaine de processus Validation valide par paliers les produits au regard des besoins du client. La validation peut tre effectue soit en environnement oprationnel soit en environnement simul. La coordination avec le client lgard des exigences de validation est un lment important de ce domaine de processus. La porte du domaine de processus Validation stend la validation des produits, des composants de produit, des produits dactivit intermdiaires slectionns et des processus. Ces lments valids peuvent souvent exiger dtre revrifis et revalids. Les problmes dcouverts pendant la validation sont habituellement rsolus par les domaines de processus Dveloppement des exigences ou Solution technique . Le domaine de processus Intgration de produit comprend les pratiques spcifiques relatives la production de la meilleure squence dintgration possible, lintgration des composants de produit et la livraison du produit au client. Lintgration de produit recourt aux pratiques spcifiques des domaines Vrification et Validation, en mettant en uvre les processus dintgration de produit. Ses pratiques vrifient les interfaces et les exigences dinterface des composants de produit avant lintgration de produit. Cest l un vnement essentiel du processus dintgration. Pendant lintgration de produit dans lenvironnement oprationnel, les pratiques spcifiques du domaine de processus Validation sont employes.

Domaines de processus de lingnierie

Rcursivit et itrativit des processus dingnierie

Synthse Thierry IRIE

44

La plupart des normes de processus reconnaissent quil existe deux manires dappliquer les processus : rcursivement ou itrativement. Il y a rcursivit quand un processus sapplique aux niveaux successifs des lments dun systme dans une structure de systme. Les rsultats de lapplication un niveau sont employs comme entres pour le niveau suivant de la structure. Par exemple, le procd de vrification est conu pour sappliquer au produit assembl, aux principaux composants du produit et mme aux composants des composants. Le degr de pntration du processus de vrification du produit dpend entirement de la taille et de la complexit du produit final. Il y a itration quand des processus sont rpts au mme niveau du systme. Une nouvelle information est cre par la mise en uvre dun processus et ralimente un processus apparent. Cette information soulve gnralement des questions qui doivent tre rsolues avant de finaliser les processus. Par exemple, une itration se produira trs vraisemblablement entre le dveloppement des exigences et la solution technique. Une nouvelle application des processus peut rsoudre les questions ainsi souleves. Litration peut assurer la qualit avant lapplication du processus suivant. Les processus dingnierie (par exemple le dveloppement ou la vrification des exigences) sont mis en uvre plusieurs reprises sur un produit pour sassurer quils ont t correctement traits avant la livraison au client. De plus, ils sont appliqus aux composants de produit. Par exemple, quelques questions souleves par les processus associs aux domaines de processus Vrification et Validation peuvent tre rsolues par des processus lis aux domaines de processus Dveloppement des exigences ou Intgration de produit . La rcursivit et litration de ces processus permettent au projet de sassurer de la qualit de tous les composants du produit avant quil soit livr au client.

Synthse Thierry IRIE

45