gestion de projets informatiques

7/29/2019 Gestion de Projets Informatiques

1/45

Gestion de projets informatiques

Synthse Thierry IRIE


2/45

Synthse Thierry IRIE 2

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 findu dix-neuvime sicle.

partir du dbut des annes 1960, les entreprises ont commenc raliser lutilitdorganiser le travail en projets. Cette vision de lorganisation axe sur les projets sestamplifie lorsque les organisations ont pris conscience de la ncessit essentielle pourleurs employs de communiquer et de collaborer dans un contexte professionnel

impliquant plusieurs services et professions et, dans certains cas, lensemble dessecteurs industriels.

Aujourdhui, les principes de base de la gestion de projet sont reprsents par letriangle, un symbole rendu populaire par Harold Kerzner dans son ouvragevnement, Project Management: A Systems Approach to Planning, Scheduling, andControlling.

Le triangle du projet traduit la relation existant entre les lments temps, argent etobjectif. L'ajustement de l'un de ces trois facteurs a des rpercussions sur les deuxautres. Par exemple, si lon ajuste le plan de projet pour rduire les prvisions, lonrisque 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 laconception 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 sonlogiciel isolement et le dveloppement industriel dune application de grande taille quipeut rassembler quelques centaines de dveloppeurs sur plusieurs annes.

Dans le premier cas, la mthodologie est une affaire dhabitudes personnelles et seconstitue au fil de lexprience. A chacun de trouver ses propres recettes pourdvelopper vite et bien. Le dveloppeur isol se constitue son propre style de

programmation, son rpertoire dastuces pour rsoudre des problmes de codage qui
http://appendpopup%28this%2C%27pjdefprojecttriangle_1_1%27%29/http://appendpopup%28this%2C%27pjdefprojecttriangle_1_1%27%29/http://appendpopup%28this%2C%27pjdefprojecttriangle_1_1%27%29/http://appendpopup%28this%2C%27pjdefprojecttriangle_1_1%27%29/http://appendpopup%28this%2C%27pjdefprojecttriangle_1_1%27%29/http://appendpopup%28this%2C%27pjdefprojecttriangle_1_1%27%29/http://appendpopup%28this%2C%27pjdefprojecttriangle_1_1%27%29/http://appendpopup%28this%2C%27pjdefprojecttriangle_1_1%27%29/http://appendpopup%28this%2C%27pjdefprojecttriangle_1_1%27%29/http://appendpopup%28this%2C%27pjdefprojecttriangle_1_1%27%29/http://appendpopup%28this%2C%27pjdefprojecttriangle_1_1%27%29/http://appendpopup%28this%2C%27pjdefprojecttriangle_1_1%27%29/


3/45


reviennent souvent, lensemble des comportements qui lui permettent de limiter aumaximum la fastidieuse chasse aux bugs.

Dans lindustrie, les soucis defficacit, de rutilisation de solutions connues, ou deprogrammation sans erreur sont bien sr pris en charge, mais les dfissupplmentaires 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 phnomnena fait que saccentuer avec lapparition et la propagation des langages orientsobjets. 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 dela conception informatique est gnralement flou et incomplet. Rciproquement, leconcepteur est tranger au monde du client. Il sagit donc de trouver un langagecommun entre ces deux mondes pour instaurer un dialogue et identifier les clausescontractuelles de manire satisfaisante pour les deux parties. Il rsulte de ce constatque malgr tous les efforts dployslvolution du cahier des charges au cours du

dveloppement est quasiment invitable.Dautre part, le dveloppement lui-mme est effectu plusieurs, les diffrentesparties dun logiciel sont toujours plus ou moins interdpendantes, si bien qu toutmoment du cycle de vie dun projet, de la spcification la validation finale, lesdveloppeurs et concepteurs doivent se mettre daccord sur les fonctionnalits eninteragissant au quotidien.

Le problme du gnie logiciel est donc de :

limiter lvolution du cahier des charges et rduire le risque de malentendu entreclients et concepteurs ainsi quentre quipes de concepteurs en sappuyant sur unlangage de modlisation standardet non ambigu ; rpondre le plus rapidement possible une volution du cahier des charges enrduisant le temps du cycle lmentaire qui spare les spcifications de laralisation ; limiter au maximum les rpercussions dune modification dans une phase dudveloppement sur les autres phases ; fournir des moyens de communication et de structuration du travail collectif lesplus 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 appelleprojetl'ensemble des actions entreprendre afin de rpondre un besoindfini dans des dlaisfixs. Un projet possde galement un cotet fait donc l'objetd'une budgtisation de moyens et d'un bilan indpendant de celui de l'entreprise. Onappelle livrables les rsultats attendus du projet.

Projet informatique :


4/45


Un projet informatique un ensemble dactions mises en uvre, afin de produire lesrsultats et fournitures dfinies en rponse aux objectifs clairement dfinis, dans desdlais fixs (date dbut et date de fin), mobilisant des ressources humaines etmatrielles et possdant un cot prvisionnel et des gains esprs.

Conduite de projet :On appelle conduite de projetl'organisation mthodologique mise en uvre pour faireen sorte que l'ouvrage ralis par le MOE rponde aux attentes du MOA et soit livrdans les conditions de cot et de dlai prvus initialement.

Gestion ou management de projet :La gestion de projeta pour objectif d'assurer la coordination des acteurs et des tchesdans un souci d'efficacit et de rentabilit. Le management de projet s'inscrit toujoursdans 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 desvalidations entre l'mergence du besoin et la livraison du produit.

Cycle de vie de l'ouvrage :Le cycle de vie de l'ouvragecorrespond aux tapes et aux livrables ncessaires laralisation de l'ouvrage.

3.2 Concepts importants

Matriser le dveloppementIl sagit de pouvoir:

Utiliser des techniques dindustrialisation (cf. calculettes, micros) ; Concevoir chaque logiciel comme une brique dun projet (cest-dire travailleren mode projet) ; Dcliner les fondamentaux (CMM, ISO, SPICE,...) relatifs aux aspectsdvaluation des cots et mtrologie.

Conduire le dveloppementLa conduite du dveloppement consiste simposer des processus formels dedveloppement. 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 dudveloppement ; automatis ; adaptable ; processus formel et exhaustif de tests ;

technologie jour (objets, Java, AGL,...).


5/45


3.3Acteurs dun projet

Matrise douvrage ou MOA :On appelle matrise douvrage toute personne physique ou morale propritaire delouvrage. Il dtermine les objectifs, le budget et les dlais de ralisation.

Matrise duvre ou MOE :On appelle matrise duvrepersonne physique ou morale qui reoit mission de lamatrise douvrage pour assurer la conceptionet la ralisation de louvrage.

Comit Directeur ou CD :Le Comit Directeurest 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 structuretemporaire, mise en place spcifiquement pour le projet, qui a pour but de piloter leprojet de faon autonome, c'est--dire en se distinguant de la hirarchie permanentede la socit. Le Comit de pilotage est cependant charg de rendre compte au ComitDirecteur des problmes rencontrs au cours du projet lorsqu'une dcision de niveaustratgique doit tre prise au cours du projet. A la fin du projet, le Comit de Pilotageest 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 alorsdsign et une date prvisionnelle de dmarrage du projet est fixe.

Le Groupe deprojetLa matrise d'uvre est organise autour d'un groupe de projet, son organe dedcision. Ce groupe a pour mission de produire l'ensemble des travaux relevant desattributions 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 dveloppementet/ou de paramtrage, interne ou externe. Il organise l'assurance qualit et suitl'avancement et la consommation des ressources du projet. Organe de dcision de lamatrise d'uvre, il communique avec la matrise d'ouvrage au travers de runions oude 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.


6/45



7/45


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

1. Principes

Rappelons que la conduite de projet informatiqueest lorganisation mthodologiquemise en uvre pour faire ensorte que louvrage ralis par le matre duvre rpondeaux 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 sarsolution.

- 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 afinde 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 programmedaction.

b) Lors de la ralisation :


8/45


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


9/45


2. Modles de conduite et gestion de projets informatiques

Il existe plusieurs modles de conduite et gestion de projets informatiques :

a) Les modles basssur les livrables : modles linairesDans 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 spiraleLe modle en spirale de Boehm met en uvre une valuation rgulire des risqueslis au projet permettant la mise en uvre de solutions techniques pour annihiler oucontrer ces risques. Cette valuation englobe les autres approches. Un cycle de spiraleutilise :

Un modle de dveloppement en cascade (quand un risque dintgration estidentifi) ;Le prototypage quand le risque est li lacceptation de linterface utilisateur parle client, par exemple.

3. Les rfrentiels

La fabrication dun logiciel de qualit respectant les contraintes de budget et de dlaisncessite :

le choix dune architecture ;la mise en uvre de mthodes, de techniques, de standards, des normes etdes 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 parles aboutissements suivants :- Vision ;- Architecture ;- Fonctionnalits ;- Livraison.


10/45


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, Contraintesde 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 partieprenante, dune architecture candidate, de comportement et de conception descomposants 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 un plan prtabli et des critresdvaluation, rsultant en un produit excutable.


11/45



12/45


4.3 Les intervenants

Les principaux intervenants du cycle de dveloppement sont les gestionnaires duprojet 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 logicielfiable, 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. Lesactivits sont reprsentes dans des processus spars.

Le Processus ici est squentiel: Chaque tape doit tre termine avant que la suivantecommence.

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 duschma ci-dessous :


13/45


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 ducycle de vie et celles de fin : Les phases du dbut doivent tre accompagnes dune planification des phases defin : Lors de la planification, on dveloppe et documente les plans de test.

5.4 Modle en spiraleIl 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 sontvalues par diffrentes techniques (prototypage, simulation, ...), ltape est raliseet la suite est planifie. Le nombre de cycles est variable selon que le dveloppement est classique ouincrmental.

5.5 Processus unifi

Ce modle prsente les particularits suivantes :


14/45


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 biencomprendre les dsirs et les besoins de ses futurs utilisateurs).

Un cas d'utilisation est une fonctionnalit du systme produisant un rsultatsatisfaisant pour l'utilisateur. Les cas d'utilisation saisissent les fonctionnels et leurensemble forme le modle des cas d'utilisation qui dcrit les fonctionnalits compltesdu systme.

Ce modle est centr sur larchitecture (cest--dire les diffrentes vues du systmequi doit tre construit). Il est Itratif et incrmental.

Itratif: Pour parler de la croissance et laffinement successifs dun systme par lebiais ditrations multiples, retours en arrire et adaptation cycliques

Incrmental: Pour parler de dcoupage du travail en plusieurs parties qui sont autantde 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 systmetest, intgr et excutable.

5.6 Activits de dveloppement

Elles sont dcrites de faon indpendante en indiquant leur rle, utilisent et produisentdes artefacts. Selon le modle, une activit peut jouer un rle plus ou moins importantet 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 :


15/45


identification de plusieurs solutions et valuation des cots et bnfices dechacune 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, pourchacune 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, servicesrendus, 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 nonfonctionnelles 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 lelogiciel 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 domaineModle de lexistant (ventuellement) Dfinition du modle conceptuel. Plan de validation, dossier de tests d intgration

d) Conception

Objectifs :Dfinition de larchitecture gnrale du logiciel. Spcification de la maniredont chacun des composants du logiciel sera ralis et comment ils interagiront.

Activits :


16/45


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 moduleproposition 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 (modlelogique), 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 lafabrication 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.


17/45


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 versionofficielle, 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 documentationTrace dexploitation et dvolution

6. Dclinaison des diffrentes tapes de la Gestion de projets informatique6.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, leshypothses)

Elle seffectue tout au long du cycle de vie du projet. Dans sa mise en uvre, il faudraviter 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 plusde ) ; 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, nouvellestechnologies, manque d'exprience en estimation, oublis, productivit n'est pas 40 heures/ semaine , optimisme non fond.

a.1) Dmarche et conseils


18/45


Dmarche : Entres : objectifs techniques, objectifs de dlais, environnement, priode,historique, rfrences Sorties : estimation Itrations : augmenterlinformation 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 estimationspasses. Ce qui est analys concerne : taille, dure, effort, complexit, cot.

Modle paramtrique : Les estimations sont bases sur des modles mathmatiques reposant surdivers paramtres : COCOMO, SLIM, PRICE-S, SoftCost,

Oracle :Equipe dexperts, atteinte dun consensus par ngociation

PERT : Estimations reposant sur lhypothse dune rpartition normale desestimations ;Raliser plusieurs estimations avec une mthode par analogie ou oracle lapire (l), la moyenne (m), la meilleure (h) ; Effort = (l+4m+h)/6

Bottom-up: Les estimations par analogie, PERT, paramtrique, oracle sont faites paractivit ou composant lmentaire.Puis consolides jusquau sommet du projet.

N.B. : Aucune technique nest meilleure ou pire que les autres. Utiliser plusieurstechniques en parallle et comparer les rsultats : si trop de diffrence, augmenter laquantit 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 dumontant de fonctionnalit (taille du logiciel) en sappuyant sur cinq (5) types defonctionnalits : Input, Output, Inquiry, Internal Logical File, External Interface File.

Et lon dtermine par la suite le nombre de fonctions (FC = nombre de fonctions) enfonction despondrations associes aux fonctionnalits prcdemment dtermines.


19/45


Un ajustementest fait selon leur complexit ci partir de 14 facteurs nots de 0 (pasdinfluence) 5 (fondamental) ; les 14 fonctions tant entre autre : Communication parmessage, distribution de donnes ou de fonctions, haut taux de transaction, calculcomplexe, 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 dusystme 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 dunombre de personnes qui vont raliser ce travail. Il permet dobtenir un cotprvisionnel. 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.


20/45


Exemple: Un projet de 60 mois/homme reprsente lquivalent du travail dunepersonne pendant 60 mois. Si on value le cot du mois/homme 12 millions deF.CFA en moyenne, le projet sera estim 720 millions de F.CFA.

La taille :On mesure la tai l ledes projets leur charge :

Si Charge < 6 HM : trs petit projet Si 6 HM< Charge


21/45


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 jusqulimplmentation, 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

Pou r la v arian te COCOMO d ite in termdiai re, les facteurs suivants sont pris encompte :

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 estdvelopp Systme de dveloppement interactif ou non

Pour le personnel Aptitude lanalyse


22/45


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, desnouvelles informations acquises. Cest aussi un outil incontournable pour la gestion duprojet. 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 ;


23/45


Traduire la dfinition du projet en une liste de tches accomplir ; Prparer une liste exhaustive, documente et structure des travaux dontlaccomplissement est ncessaire la production des biens livrables du projet.

Elle ncessite la constitution dune base de donnes des travaux qui sert de base auxautres tapes de planification. Cette base est le principal instrument de communicationentre les intervenants.

La planification structurelle permet galement lidentification et description des lots detravail principaux de mme que celles des tches lmentaires qui y affrant.

Les Etapes :

La planification structurelle se dcline en plusieurs tapes :

Planif icat ion struc turel le sommaire

Elle consiste subdiviser le projet en lots de travail ; un lot tant un bien livrable duprojet. Dans cette tape, il faudra toujours prvoir les lots de support pour tchesponctuelles.

Plan if ic ati on s tr uc tu re ll e dtai lle

Ici, il faudra subdiviser les lots de travail principaux jusqu lidentification de tcheslmentaires et effectuer une reprsentation laide dun organigramme de tche(Work Breakdown Structure)

Con fo rm itet compltude

A ce niveau, on doit avoir suffisamment confiance dans le caractre exhaustif de laliste des tches pour tre assur que, une fois complte de faon suffisante chacunedes 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 physiqueshirarchises.


24/45


Ici, nous avons une description structure de toutes les tches du projet, rapportesau dcoupage du produit.

b-2) Planification oprationnelle

Rle :

La planification oprationnelle consiste :

Crerun rseau ordonnanc dactivits partir des tches delorganigrammetechnique ; Estimer de la dure dune activit et des ressources requises pour lacomplter ; Identifier le chemin critique dans un rseau ordonnanc et calculer les margestotales, 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 deschanciers 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 :


25/45


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 degarantie, pondration pour tenircompte 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 prcdencelogique 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 estreprsente 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 auxdates relles de dbut et de fin.

Exemple de reprsentation dun diagramme de Gantt:


26/45


6.2 Suivi de projet

Rle :

Le suivi de projet consiste valuer la situation relle du projet, la comparer lasituation prvue au plan dexcution et prendre les dcisions ncessaires pourcorriger la situation, si des carts sont observs ou prvus.

La matrise des ressources et la gestion de la qualit du produit sont des fonctions encours de ralisation du projet quelle que soit la phase atteinte dans la progression duprojet. 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 revuesrgulires 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 ;


27/45


Expliquer les retards et les dpassements de cot ; Proposer des mesures correctives, den valuer les rpercussions et de lesmettre rapidement en uvre ; Rpondre des conditions changeantes du milieu (le projet, sonenvironnement).

Cette capacit demande davoir des points de repre : Cest la planification du projet.

- ContrleLe contrle est une activit dacquisition des informations sur la progression duprojet. 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 lavancementLe suivi de lavancement se ralise par un enchanement de plusieurs activits sous-jacentes. Il sagit entre autre de :

o AnalyseLe but de lanalyse est de vrifier si la situation actuelle est telle que prvue. Elledcline 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 avecla situation prvue. La slection de mesures correctives par la ralisation de propositions et de lanalysede leffet de mesures correctives et enfin par la ralisation de recommandations.

o Causes dcartCette 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 techniqueIl sagit ici de mettre en relief les lments suivants :

Occurrence dun problme technique imprvu ; Difficults techniques majeures dont la mise en relation de diversescomposantes ; 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.

CotsIl sagit ici de mettre en relief les lments suivants :


28/45


Difficult de financement ; Difficults techniques imposant lutilisation de plus de ressources humainesou 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.

chanciersIl sagit ici de dcliner les indicateurs suivants :

Dure plus longue que prvue pour complter une activit, pour rsoudre unproblme 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 ladure des activits venir, sur leur programmation, etc. (Boucle de rtroactionpositive).

Mise en uvreIl sagit ici de veiller lapplication effective des mesures suivantes :

Approbation des mesures retenues ; Communication aux personnes concernes ; Mise en application.

- Co nsei ls lmen tai resAfin de pouvoir sassurer de la bonne marche du suivi de lavancement du projet, il estimportant de tenir compte des conseils suivants :

Toujours donner lheure juste ; Sassurer que le cot du contrle, de lanalyse et de la miseen uvre demeureinfrieur aux bnfices esprs du suivi et du contrle des ressources ; Ne prendre que les informations pertinentes la matrise des ressources et de laqualit du produit ; Vrifier que le contrle et lanalyse se font rapidement pour que les mesurescorrectives demeurent dactualit ; Organiser le contrle autour des biens livrables.

6-3. Clture de projetInvitablement, les projets se terminent; il est dans la dfinition mme dunprojet quil

ne dure quun temps prcis dans la vie dune organisation. Les faons dont les projetsse 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.


29/45


Fin normale dun projetLa plupart des projets se terminent favorablement avec la livraison du produit ou dusystme au client; ce client peut tre linterne delorganisation, projet dimplantationdquipement dans une usine, ou lexterne, projet de construction, projet de sous-traitance industrielle.

Fin normale dun projet et intgration lorganisationDans certains cas de projets, surtout lorsque le client est interne, il arrive trsfrquemment 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 avortIl peut arriver quon doive arrter un projet pour des questions techniques, budgtairesou lgales. Des procdures doivent alors tre prises pour compenser, sil y a lieu, laou les parties lses.

En situation normale, clturer un projet dsigne une srie dactivits que doitraliser les responsables du projet. Lutilisation de listes de vrification est frquentelors de la fermeture de dossiers.

De mme, il est important de veiller ce que les routines de clture suivantes soienteffectivement 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 clture ont traliss (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 volutionsPour 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 sortiesaccompagne de progrs importants au niveau des fonctionnalits, et/ou changementnotable 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 corrigedes bugs attendus par les clients (mais non bloquants), et apporte des modificationslgres ; 3me chiffre : numro des corrections, versions rsultant de la maintenance

Pour ce qui est des versions, une approche de fait est habituellement de mise dansleur notifications :


30/45


- 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 projetIl sagit de :

Plannings, plans, estimations ; Rapports ; Dfinitions de standards ; Documents de travail ; Courriers (mails).

Documentation TechniqueSuivant 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


31/45



32/45


7. Les outilsPlusieurs outils sont habituellement utiliss dans le cadre de la conduite et la gestionde 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.


33/45


Chapitre 3 : Lapproche CMMI pour le dveloppement

1. Contexte et historique

Dans les annes 1980, le Dpartement de la Dfense des tats-Unis (DoD) ademand l'laboration d'un rfrentiel de critres lui permettant d'valuer sesfournisseurs de logiciels. Aprs une lente maturation, le SEI (Software EngineeringInstitute) financ par le DoD a prsent en 1991 leCapability Maturity Model(CMM).Ce modle de rfrence ne concerne que les bonnes pratiques du gnie logiciel. Aprsun fort engouement pour ce modle, d'autres modles similaires ont vu le jour, telsque :

SE-CMM (pourSystem Engineering) ; SA-CMM (pourSoftware Acquisition) ;

IPD-CMM (pourIntegrated Product Development) ; People CMM pour le management des ressources humaines ; SS-CMM pourSupplier Sourcing.

Tant et si bien quil fallut rebaptiser le CMM initial en SW-CMM (pourSoftware).

En 2001, le SEI a propos une nouvelle version de son modle, le CMMI (CapabilityMaturity Model Integration) qui englobe les bonnes pratiques des autres modles, saufla gestion des ressources humaines qui n'est pas encore considre (version 1.1). Laversion actuelle du modle a t ractualise en 2006 (version 1.2). Cette dernireversion 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 laralisation de tout type de produit (ou systme). C'est cependant dans ledveloppement et la maintenance de logiciel qu'il est le plus utilis. Sa porte utiles'tendant de l'apparition d'un besoin jusqu' la livraison du produit correspondant, il ya d'autres modles utiles pour d'autres domaines du logiciel, par exemple pour lesinfrastructures et oprations ITIL. Il existe aussi d'autres rfrentiels de bonnespratiques, 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 lgrementdiffrents. Les deux reprsentations sappuient sur les mmes PAs mais ceux-ci sontutiliss diffremment :

Rep rsen tati on con tin ue : La reprsentation continue privilgie de regarderlvolution au niveau de chaque domaine de processus (PA) et dy associer des stadesde dveloppement de la capacit du processus;

Reprsen tat ion tage: La reprsentation tage prconise une volution partage au niveau de toute lorganisation de dveloppement. Elle permet ainsi de dfinirle niveau de maturit (ML) de lorganisation.
http://fr.wikipedia.org/wiki/Ann%C3%A9es_1980http://fr.wikipedia.org/wiki/D%C3%A9partement_de_la_D%C3%A9fense_des_%C3%89tats-Unishttp://fr.wikipedia.org/wiki/R%C3%A9f%C3%A9rentielhttp://fr.wikipedia.org/wiki/Logicielhttp://fr.wikipedia.org/w/index.php?title=SEI&action=edit&redlink=1http://fr.wikipedia.org/wiki/1991http://fr.wikipedia.org/wiki/Capability_Maturity_Modelhttp://fr.wikipedia.org/wiki/Capability_Maturity_Modelhttp://fr.wikipedia.org/wiki/Capability_Maturity_Modelhttp://fr.wikipedia.org/wiki/G%C3%A9nie_logicielhttp://fr.wikipedia.org/wiki/People_CMMhttp://fr.wikipedia.org/wiki/Ressources_humaineshttp://fr.wikipedia.org/wiki/Ressources_humaineshttp://fr.wikipedia.org/wiki/R%C3%A9f%C3%A9rentielhttp://fr.wikipedia.org/wiki/ITILhttp://fr.wikipedia.org/wiki/ITILhttp://fr.wikipedia.org/wiki/R%C3%A9f%C3%A9rentielhttp://fr.wikipedia.org/wiki/Ressources_humaineshttp://fr.wikipedia.org/wiki/Ressources_humaineshttp://fr.wikipedia.org/wiki/People_CMMhttp://fr.wikipedia.org/wiki/G%C3%A9nie_logicielhttp://fr.wikipedia.org/wiki/Capability_Maturity_Modelhttp://fr.wikipedia.org/wiki/1991http://fr.wikipedia.org/w/index.php?title=SEI&action=edit&redlink=1http://fr.wikipedia.org/wiki/Logicielhttp://fr.wikipedia.org/wiki/R%C3%A9f%C3%A9rentielhttp://fr.wikipedia.org/wiki/D%C3%A9partement_de_la_D%C3%A9fense_des_%C3%89tats-Unishttp://fr.wikipedia.org/wiki/Ann%C3%A9es_1980


34/45


2. Les niveaux daptitude et de maturit

Les niveaux sont employs dans le CMMI pour dcrire une dmarche volutiverecommande une organisation qui souhaite amliorer les processus quelleapplique 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 dentreprisesentires (habituellement petites) ou de plus petits groupes tels quun groupe de projetsou une division au sein de lentreprise.

Le CMMI propose deux voies damlioration. Lune permet aux organisationsdamliorer progressivement les processus dun ou de plusieurs domaines quelle achoisis. Lautre permet damliorer un ensemble de processus apparents en traitantde manire incrmentale des ensembles de domaines de processus successifs.

Ces deux voies sont associes deux types de niveaux correspondant. Pour lareprsentation continue, nous employons le terme de niveau daptitude . Pour lareprsentation tage, nous employons celui de niveau de maturit .

Indpendamment de la reprsentation que vous choisissez, le concept de niveau restele mme. Les niveaux caractrisent le passage dun tat mal dfini un tat quiemploie desinformations quantitatives afin de dterminer et de grer les amliorationsncessaires pour rpondre aux objectifs stratgiques dune organisation.

Pour atteindre un niveau donn, une organisation doit satisfaire tous les objectifsappropris du domaine de processus ou de lensemble des domaines de processusviss par lamlioration, indpendamment du fait quil sagisse de niveau daptitude oude niveau de maturit.

Les deux reprsentations fournissent des mthodes de mise en uvre delamlioration de processus pour atteindre les objectifs stratgiques. Elles fournissenttoutes deux le mme contenu essentiel et emploient les mmes composants dumodle.

2-1 Les niveaux de maturit ou reprsentation tage

Comme le montre la figure, la reprsentation tage exprime lvolution des pratiquesde dveloppement en fonction dune vue organisationnelle. La premire tape est de

dfinir le primtre observer : lorganisation . Puis, on observe son comportementau regard des 5 niveaux de maturit (ML) regroupant les 22 PAs :


35/45


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 traduitla mise en oeuvre effective de pratiques de base au niveau des projets mais sansharmonisation au niveau de lorganisation (par exemple chaque projet gre

diffremment sa planification, ses configurations); il sadresse essentiellement auxChefs de Projet.

ML 3 : Niveau Dfini o les processus sont organiss, ractifs et matriss. LeML 3 traduit le dploiement harmonis de pratiques dfinies au niveau delorganisation ; il sadresse toute la population et met laccent sur lengineering produitet lorganisation centrale.

ML 4 : Niveau Quantifi o les processus sont mesurs et contrles. Le ML 4traduit 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 5traduit la maturit de lorganisation o veille technologique et amlioration continueconcourent lexcellence du livrable.


36/45



37/45


Chacun des Processus Areas (PA) doit rpondre des objectifs qui peuvent tre :

Spcif iq ues (SG), intrinsquement relis la nature de lactivit couverte parle PA;

Gnriques (GG), transversaux et identiques dun PA lautre. Ces objectifsse dclinent en pratiques qui dcrivent le comportement attendu de la part delorganisation 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.


38/45


2-2 Les niveaux daptitude ou reprsentation continue

La reprsentation continue utilise une vision cible de lvolution des pratiques dedveloppement. Contrairement la reprsentation tage qui regroupe sous desniveaux de maturit les diffrents PAs, la reprsentation continue exprime la capacitde chaque PA au sein de lorganisation suivant une chelle de 6 niveaux.

Cette reprsentation permet lentreprise dentreprendre un programmedamlioration sur un bouquet de PAs quelle a slectionn.

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 dedveloppement et de maintenance qui sont partages entre les diffrentes disciplinesdingnierie (ingnierie systme, ingnierie logiciel)

Project Management Process Areas (Gestion de projet) : Ils couvrent les activitsde gestion de projet lies la planification, au suivi et au contrle du projet

Support Process Areas (Support) : Ils couvrent les activits qui soutiennent ledveloppement et la maintenance du produit. Ce sont des processus qui permettentdexcuter dautres processus. En gnral, ils sadressent des processus lis auprojet mais peuvent aussi sadresser aux processus de lorganisation. Par exemple, lePA Process and Product Quality Assurance peut tre utilis avec tous les autresPAs pour fournir une valuation objective des processus et des produits de travaildcrits dans tous les secteurs de processus

Process Management Process Areas (Gestion des processus) : Ils concernenttoutes les activits transversales du projet lies la dfinition, la planification, lerapprovisionnement, 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 activitsrelatives la planification, la surveillance et au contrle du projet. Les domaines deprocessus de cette catgorie sont les suivants :

Planification de projet ; Surveillance et contrle de projet ;


39/45


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 activitsrelatives ltablissement et la maintenance du plan de projet, llaboration et aumaintien des engagements, la surveillance de lavancement au regard du plan, lamise en uvredactions correctives et la gestion des accords avec les fournisseurs.

La figure ci-dessous fournit une vue densemble des interactions entre les domainesde processus de la gestion de projet basique entre eux ou avec dautres catgories dedomaines. Comme on le constate, les domaines de processus de la planification deprojet 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, lesparties prenantes nassurent pas simplementlexpertise technique du produit et du dveloppement de processus, mais galementleurs implications mtiers.

La planification dbute avec la dtermination des exigences qui dfinissent le produitet le projet ( Que construire la figure 4.3). Le plan de projet aborde les diversesactivits de ralisation et de gestion du projet.

Le projet passe en revue les autres plans qui laffectent avec les diverses partiesprenantes concernes et tablit avec elles des engagements lgard de leurscontributions 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 desurveillance et de mise en place dactions correctives. Le plan de projet spcifie leniveau de surveillance appropri, la frquence des revues davancement et lesmesures employes pour surveiller cet avancement.

Lavancement est principalement dtermin par comparaison du statut du projet auplan. Quand le statut rel scarte de manire significative des valeurs attendues, desactions correctives appropries sont mises en uvre. Ces actions peuvent porter surla 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 sourcesdes produits qui peuvent tre employs pour rpondre certaines exigences du projetsont 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 desproduits dactivit et des processus slectionns.

Laccord avec le fournisseur est rvis si ncessaire. Les revuesdacceptation et lestests sont effectus sur le composant produit par le fournisseur.


40/45


Domaines de processus de la gestion de projet basique


41/45


3-2. Domaines de processus de la gestion de projet avance

Les domaines de processus de la gestion de projet avance traitent des activits tellesque :

tablir un processus ajust partir de lensemble des processus standards delorganisation ;

tablir lenvironnement de travail du projet partir des normesdenvironnementde 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 domainesde processus de la gestion de projet avance ainsi quavec dautres catgories dedomaines. Chaque domaine de processus de la gestion de projet avance dpend dela 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 lesprocessus ajusts du projet partir de lensemble des processus standards delorganisation. Le projet est gr en recourant aux processus ajusts du projet. Leprojet utilise les actifs de processus de lorganisation ety contribue. Lenvironnementde travail du projet est dvelopp et maintenu partir des normes denvironnement detravail de lorganisation.

La gestion du projet veille ce que les parties prenantes concernes coordonnentleurs efforts en temps utile. cette fi n, elle assure la gestion de limplication desparties prenantes. Elle sintresse galement lidentification, la ngociation et ausuivi des dpendances critiques et rsout les problmes de coordination du projet avecles parties prenantes concernes.

Avec les additions IPPD, le domaine Gestion de projet intgre +IPPD tablit etmaintient 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 lacoordination des quipes est assure.

Bien que lidentification et la surveillance des risques soient abordes dans lesdomaines de processus Planification de projet et Surveillance et contrle deprojet , le domaine de processus Gestion des risques assure une approchecontinue et long terme de la gestion des risques grce lidentification desparamtres de risques, lvaluation des risques et lattnuation des risques.

Le domaine de processus Gestion de projet quantitative applique des techniquesquantitatives et statistiques pour contrler la qualit des produits et les performancesdes processus. Les objectifs de qualit et de performance des processus du projetsont dfinis en fonction des objectifs tablis par lorganisation.

Le processus ajust du projet se compose en partie des lments de processus et dessous-processus dont la performance peut tre prvue. Au minimum, il est ncessairede comprendre la variation de processus subie par les sous-processus vitaux pouratteindre les objectifs de qualit et de performance des processus. Une actioncorrective est initie quand des causes spciales de variation des processus sontidentifies.


42/45


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 dedveloppement et de maintenance des diverses disciplines de lingnierie. Leurdescription a t rdige en employant la terminologie de lingnierie gnrale, desorte que nimporte quelle discipline technique implique dans le processus dedveloppement de produit (par exemple ingnierie logicielle ou constructionmcanique) peut les employer loccasion de lamlioration de processus.

Les domaines de processus de cette catgorie intgrent galement les processus lisaux diffrentes disciplines de lingnierie au sein dun unique processus dedveloppement, autorisant ainsi une stratgie de lamlioration de processus orienteproduit. Une telle stratgie cible les objectifs stratgiques essentiels plutt que lesdisciplines techniques spcifiques. Cette approche des processus vite efficacementla drive vers une mentalit organisationnelle cloisonne .

Les domaines de processus de lingnierie sappliquent la ralisation de nimportequel 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 desystmes qui insre le dveloppement dans le contexte des phases de la vie duproduit. Les domaines de processus de lingnierie apportent cette base technique. Enoutre, la mise en uvre de lIPPD saccompagne damplifications ddies auxpratiques spcifiques des domaines de processus de lingnierie qui mettent laccentsur le dveloppement simultan et se concentrent sur toutes les phases de la vie duproduit.

Les domaines de processus de la catgorie Ingnierie sont les suivants : Dveloppement des exigences ; Gestion des exigences ;

Solution technique ; Intgration de produit ;


43/45


Vrification ; Validation.

La figure ci-dessous fournit une vue densemble des interactions au sein des sixdomaines de processus de lingnierie.

Le domaine de processus Dveloppement des exigences identifie les besoins duclient et traduit ces besoins en exigences produit. Lensemb le des exigences produitest analys pour produire une solution conceptuelle de haut niveau. Cet ensembledexigences est alors alloupour laborer un premier jeu dexigences composantesde produit. Dautres exigences qui aident dfinir le produit sont drives et allouesaux composants de produit. Cet ensemble dexigences produit et composants deproduit dcrit clairement la performance du produit, les caractristiques de conception,les exigences de vrification et ainsi de suite, dans des termes que le dveloppeurcomprend et emploie.

Le domaine de processus Dveloppement des exigences fournit des exigences audomaine Solution technique , qui convertit les exigences en architecture de produit,conception de composants de produit et composants de produit proprement dits (parexemple codage ou fabrication). Ces exigences sont galement fournies au domainede processus Intgration de produit , qui combine les composants de produit etvrifie les interfaces pour sassurer que les exigences dinterface fournies par ledveloppement des exigences sont respectes.

Le domaine de processus Gestion des exigences maintient les exigences. Il dcritles activits dobtention et de contrle des modifications aux exigences et sassure queles autres plans et donnes appropris sont tenus jour. Il permet la traabilit entreles exigences client, les exigences produit et les exigences composants de produit.

Le domaine de processus Gestion des exigences sassure que les modificationsaux exigences sont reportes dans les plans de projet, les activits et les produitsdactivit. Ce cycle de changements peut avoir une incidence sur tous les autresdomaines de processus de lingnierie. La gestion des exigences est donc une suitedvnements dynamiques, souvent rcursive.

Le domaine de processus Gestion des exigences est fondamental pour laconception dun processus dingnierie contrl et disciplin.

Le domaine de processus Solution technique dveloppe les ensembles dedonnes techniques relatifs aux composants de produits qui seront employs par lesdomaines de processus Intgration de produit ou Gestion des accords avec les

fournisseurs . Les solutions possibles sont examines dans le but de choisir laconception optimale en fonction des critres tablis. Ces critres peuvent tresensiblement diffrents suivant les produits, les types de produits, lenvironnementdexploitation, les exigences de performance, les besoins en support et le cot ou leschanciers de livraison.

Le choix de la solution dfinitive sappuie sur les pratiques spcifiques du domaine deprocessus Analyse et prise de dcision .

Le domaine de processus Solution technique sappuie sur les pratiques spcifiquesdu domaine Vrification pour assurer la vrification de la conception et les revuespar les pairs avant la construction finale.


44/45


Le domaine de processus Vrification sassure que les produits dactivit retenusrpondent aux exigences dfi nies. Ce domaine slectionne les produits dactivit etles mthodes de vrification qui seront employes pour les vrifier au regard desexigences spcifies. La vrification est gnralement un processus incrmental quicommence 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 constituentune mthode prouve de rsolution anticipe des dfauts. Elles fournissent en outreune image pertinente des produits dactivit et des composants des produits qui ontt dvelopps et maintenus.

Le domaine de processus Validation valide par paliers les produits au regard desbesoins du client. La validation peut tre effectue soit en environnement oprationnelsoit en environnement simul. La coordination avec le client lgard des exigencesde 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 desprocessus. Ces lments valids peuvent souvent exiger dtre revrifis et revalids.Les problmes dcouverts pendant la validation sont habituellement rsolus par lesdomaines de processus Dveloppement des exigences ou Solution technique .

Le domaine de processus Intgration de produit comprend les pratiquesspcifiques 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 etValidation, en mettant en uvreles processus dintgration de produit. Ses pratiquesvrifient les interfaces et les exigences dinterface des composants de produit avantlintgration de produit. Cest l un vnementessentiel du processus dintgration.Pendant lintgration de produit dans lenvironnement oprationnel, les pratiquesspcifiques du domaine de processus Validation sont employes.

Domaines de processus de lingnierie

Rcursivit et itrativit des processus dingnierie


45/45

La plupart des normes de processus reconnaissent quil existe deux maniresdappliquer les processus : rcursivement ou itrativement.

Il y a rcursivit quand un processus sapplique aux niveaux successifs des lmentsdun systme dans une structure de systme. Les rsultats delapplication un niveausont employs comme entres pour le niveau suivant de la structure. Par exemple, leprocd de vrification est conu poursappliquer au produit assembl, aux principauxcomposants du produit et mme aux composants des composants. Le degr depntration du processus de vrification du produit dpend entirement de la taille etde la complexit du produit final.

Il y a itration quand des processus sont rpts au mme niveau du systme. Unenouvelle information est cre par la mise en uvredun processus et ralimente unprocessus apparent. Cette information soulve gnralement des questions quidoivent tre rsolues avant de finaliser les processus. Par exemple, une itration seproduira trs vraisemblablement entre le dveloppement des exigences et la solutiontechnique. Une nouvelle application des processus peut rsoudre les questions ainsi

souleves. Litrationpeut assurer la qualit avant lapplication du processus suivant.Les processus dingnierie (par exemple le dveloppement ou la vrification desexigences) sont mis en uvre plusieurs reprises sur un produit pour sassurer quilsont t correctement traits avant la livraison au client.

De plus, ils sont appliqus aux composants de produit. Par exemple, quelquesquestions souleves par les processus associs aux domaines de processus Vrification et Validation peuvent tre rsolues par des processus lis auxdomaines de processus Dveloppement des exigences ou Intgration de produit. La rcursivit et litration de ces processus permettentau projet de sassurer de laqualit de tous les composants du produit avant quil soit livr au client.