3. GESTION DE PROJET
Contents
1. De nombreuses exp riences ont montr la sup riorit de l valuation par les points de fonction Jones constate une marge d erreur de 200 avec les points de fonction alors qu elle est de 800 avec le nombre de lignes de code source La m thode des points de fonction ne repose sur aucune technologie il y a videmment une relation entre le nombre de lignes de codes et le nombre de points de fonction que l on peut trouver dans les archives de sa propre entreprise ou bien en utilisant les tables de conversion nombre de points de fonction nombre de lignes de code que l on peut trouver sur le site de l IFPUG table de correspondance r pertoriant plus de 500 langages Cette table permet de pr dire le nombre de lignes assez t t Elle permet aussi d tudier les productivit s compar es lors de programmation dans diff rents langages et de convertir la taille d une application dans n importe quel langage Comme on peut le voir sur les caract ristique g n rales retenues pour un syst me la m thode des points de fonctions a t d finie pour des projets essentiellement orient s gestion En 1986 la m thode dite des Features Gestion de projet Anne Marie Hugues 15 02 01 3 5 points propose des extensions pour pouvoir tre appliqu e en contexte industriel logiciels embarqu s t l coms syst mes d exploitation elle prend en compte un nouveau param tre le nombre d algorithmes Sur les projets syst mes d information les d2. d acc s La fronti re entre requ te externe et donn e externe est assez floue Nous dirons que les requ tes concernent exclusivement les acc s une base de donn es alors que les donn es externes combinent ces acc s avec des calculs et traitements plus ou moins complexes Fichiers logiques internes Internal Logical Files ILF s Un groupe de donn es corr l es enti rement r sidant dans les limites de l application mis jour par les donn es externes enti rement contr l par le programme Par exemple un fichier une table dans une base de donn es Fichier interfaces externes External Interface Files EIF s Un groupe de donn es corr l es utilis es pour des r f rences seulement Les donn es r sident enti rement hors de l application et sont mises jour par une autre application c est donc un ILF pour une autre application Apr s que les composants du projet aient t ainsi classifi s chaque param tre est affect d un score faible moyen lev Pour les transactions EI s EO s EQ s le score est calcul sur le nombre de fichiers mis jour ou r f renc s FTR s et le nombre de types de donn es impliqu es DET s FTR s Donn es 15 Tableau 3 2 Table El Une requ te est not e faible moyenne ou haute comme une sortie externe EO mais on lui attribue une valeur plut t comme une entr e externe La notation est bas e sur le nombre total des l ments de donn es et
3. 12 02 01 Gestion de projet On calcule ensuite le facteur d ajustement partir de 14 caract ristiques g n rales du syst me Pour chaque caract ristique on value le degr d influence DI de 0 aucune influence 5 tr s grande influence La table ci dessous donne un aper u des caract ristiques g n rales du syst me pour les auteurs du manuel utilisateurs de l IFPUG Caract ristiques Description g n rales du syst me Communication de Combien de facilit s de communication pour aider au transfert ou l change donn es d information avec l application ou le syst me Distribution du Comment les donn es et les traitements distribu s sont ils g r s traitement et des donn es Crit res de L utilisateur a t il des exigences en mati re de temps de r ponse performance Configuration Quel est l tat de charge actuel de la plate forme mat rielle sur laquelle le mat rielle tr s charg e syst me sera mis en exploitation Fr quence des Quelle est la fr quence d ex cution des transactions quotidien hebdomadaire transactions mensuel Donn es saisies en Quel est le pourcentage de donn es saisies en temps r el temps r el Efficacit des Les interfaces ont elles t dessin es pour atteindre l efficacit maximale de interfaces utilisateur l utilisateur Mise jour en temps Combien de fichiers logiques internes sont ils mis jour en temps r el r el des fichie
4. ches siles objectifs ont t atteints et si ce n est pas le cas pour quelle raison A partir des rapports individuels le chef de projet peut tablir un rapport d activit de l quipe 3 6 2 Diagrammes 45 Ils permettent de mesurer l ange de d rive des objectifs En ordonn e on repr sente les points cl exemple revue de fin de phase obtention du prototype tels qu ils sont planifi s TO On utilise la m me chelle en abscisse et en ordonn e d o l appellation 45 On suppose que les abscisses repr sentent des mois Sur la figure suivante la revue P1 est pr vue T0 3 P 1 TO T1 T2 A l instant TO 1 la revue est toujours pr vue T T0 3 A l instant T0 2 la revue est repouss e d un mois P2 A l instant T0 3 T1 la revue est encore repouss e d un mois P3 A l instant T1 1 la revue est maintenue P3 A l instant T2 P3 la revue a effectivement lieu On mesure l angle a form par la droite passant par les points de premi re et derni re estimation horizontale si a 0 alors l objectif initial a t atteint On tablit des seuils acceptables 1 20 bon niveau Gestion de projet Anne Marie Hugues 15 02 01 3 19 2 lt a lt 30 niveau moyen a gt 30 niveau m diocre d rive importante 3 7 ORGANISATION DU TRAVAIL 3 7 1 l ments de r flexion pour le partage du travail La r partition du travail entre les membres d une quipe ne peut pas toujours se faire Cela d pend de la
5. des types de fichiers r f renc s combinaison d doublonn e des entr es et sorties Si un fichier ou un type est utilis plusieurs fois il est r pertori une seule fois Gestion de projet Anne Marie Hugues 15 02 01 3 3 l ments de Donn es FTR s Tableau 3 3 Table EO et EQ Pour les fichiers externes et internes ILF s and EIF s le score haut moyen lev est bas sur le type des l ments d enregistrements Record Element Type s et le nombre de types des donn es Data Element Type s Un type d l ment d enregistrement est un sous groupe reconnaissable de donn es dans un ILF ou EIF Un type de donn e est un champ unique non r cursif Data Elements Tableau 3 4Table ILF and EIF On r capitule ensuite dans un tableau les scores de chacun des param tres et on obtient le nombre de points de fonction bruts UFP RET s Points de fonction Caract ristiques Faibl T TET programme UDE OTOP EXIS Haute complexit Total complexit moyenne Nombre d entr es externes __ 4 _ 6 Nombre de requ tes Nombre de fichiers logiques 7 10 15 internes nn Nombre de fichiers interfaces LE ie 10 5 __ 7 __ 10 externes Nombre points de Multipli par facteur d ajustement TCF Total de points de fonction ajust s AFP Tableau 3 5 Multiplicateurs de points de fonction source adapt de Applied Software Measurement Jones 1991 3 4 Anne Marie Hugues
6. 28 DD et CUT 56 52 48 s 40 o T y 20 23 26 29 32 IMBRIQUE po RPD 8 32 34 36 38 DD et CUT 48s Jo 44 40 36 32 22 24 26 28 30 Tableau 3 11 distribution du temps de d veloppement par phases en pourcentage EXEMPLE Soit un projet estim 32 KDSI en mode organique HM 2 4 32 1 05 91 HM TDEV 2 5 91 0 38 14 Mois PRODUCTIVITE 32000 DSI 91 HM 352 DSI HM FSP 9 HM 14 MOIS 6 5 FSP Conform ment au tableau 3 10 on a PHASE DE CONCEPTION 0 16 91 14 5 HM PHASE DE CODAGE 0 62 91 56 5 HM PHASE D INT GRATION 0 22 91 20 HM Conform ment au tableau 3 11 on a PHASE DE CONCEPTION 0 19 14 2 6 Mois PHASE DE CODAGE 0 55 14 7 7 Mois PHASE D INTEGRATION 0 26 14 3 7 Mois En divisant on obtient le nombre de personnes n cessaires pour chaque phase Le mod le interm diaire Le mod le de base ne prend en compte que le nombre de lignes source et induit des discontinuit s un peu brutales au niveau du personnel entre chaque phase du cycle de vie ce qui peut perturber l organisation du projet Le mod le interm diaire introduit 15 facteurs de productivit appel s cost drivers repr sentants un avis subjectif du produit du mat riel du personnel et des attributs du projet Chaque facteur prend une valeur nominative de 1 et peut varier selon son importance dans le projet Ces facteurs sont rapprocher des caract rist
7. de l architecture g n rale du projet Il utilise des facteurs de productivit cost drivers et des formules Les facteurs utilis s sont class s en Facteurs d chelle Urgence Flexibilit de d veloppement r solution d architecture Risque Coh sion d quipe et Maturit de Processus 3 3 3 Conclusion COCOM6O reste le plus connu des mod les d estimation de co t de projet logiciel Mais le mod le d origine n adresse pas les projets utilisant les composants logiciel existants COCOMO II r pond ce probl me mais est encore jeune Le projet de recherche appel COCOTS est suivre pour les personnes d sirant estimer un projet logiciel moderne COCOMO reste la r f rence en mati re d estimation d taill e des co ts et surtout de la ventilation de ces co ts suivant les phases des projets Les estimations de COCOMO sont d autant plus fiables que les param tres du projet sont bien connus c est dire qu on a profit des projets pr c dents pour talonner ces param tres La principale faiblesse r side dans la n cessit d avoir une estimation du nombre de lignes du logiciel Cette taille du logiciel n est connue qu la fin de la r alisation et le probl me de son estimation reste entier m me si l approche par les points de fonction peut fournir une aide Ainsi le management devra valuer la justesse des pr visions tout au long de la dur e de vie du projet Les r sultats montrent que les valeurs r elles sont
8. e sur 161 points de donn es en utilisant l approche statistique Bayesienne pour combiner les donn es empiriques avec les avis d experts De plus elle peut tre re calibr e sur les donn es de l entreprise Un nouveau mod le appel COCOTS est en cours de d veloppement par l quipe de COCOMO Ce mod le permet d estimer les co ts et planifier des projets logiciels utilisant des composants existants C est encore un projet de recherche Pour les projets bas s sur une technologie traditionnelle le mod le original de 1981 est encore valable d autant plus qu il est maintenant rod et bien document 3 3 2 COCOMO 81 Le mod le COCOMO 81 s appuie sur une estimation de l effort en homme mois HM calcul e par la formule Effort C M taille s C facteur de complexit M facteur multiplicateur Taille en milliers de lignes de code source livr es KDSI s proche de 1 Hypoth ses KDSI livr Exclut en g n ral les environnements de tests les supports de d veloppement Exclut les commentaires Inclut le shell HOMMES MOIS HM MM 152 Heures Normes am ricaines tient compte des vacances arr ts maladie Le mod le COCOMO 81 est en fait constitu de trois mod les le mod le de base le mod le interm diaire le mod le d taill ou expert Le mod le de base Le mod le de base estime l effort le nombre de homme mois en fonction du nombre de milliers d instructions source livr es KDST de la productivit
9. gales 20 pr s aux valeurs estim es par COCOMO dans 68 des cas 3 10 Anne Marie Hugues 12 02 01 Gestion de projet 3 4 AUTRES METHODES D ESTIMATION 3 4 1 Estimation rapide du calendrier Jone s First Order Estimation Practice Une m thode d estimation rapide du temps de d veloppement consiste le calculer partir de l effort en utilisant la formule Temps de d veloppement en mois 3 0 HM 1 3 ou TDEV 3 0 effort Jones d finit 3 types de projets logiciels syst mes syst mes d exploitation pilotes compilateurs biblioth ques de code logiciel de gestion syst mes d information utilis s par une seule entreprise e Business Software in house systems that are used by a single organization They run on a limited set of hardware perhaps only a single computer Payroll systems accounting systems inventory control system as well as there IS IT and MIS software are in that category e Shrink wrap Software software that is packaged and sold commercially word processors spreadsheet but also financial analysis software screenplay writing and legal case management programs Systems software does not include Embedded software firmware real time sytems scientific sofware and the like Productivity for this kinds of systems would be much lower For you particular project you can mix the models for example 40 Business 60 shrink wrap and recompute the schedule and effort obtained with the following tables with
10. le nombre de lignes de code par personne par mois et d un facteur d chelle qui d pend du type de projet Les 3 types de projet identifi s sont e organique Il est d fini par une innovation minimale une organisation simple en petites quipes exp riment es ex petite gestion syst me de notes dans une cole petits syst mes d exploitation traducteurs 3 6 Anne Marie Hugues 12 02 01 Gestion de projet e m dian semi detached Il est d fini par un degr d innovation raisonnable exemples Compilateurs Contr le de processus simple syst me bancaire interactif e imbriqu Dans ces projets le niveau d innovation est important l organisation complexe couplage fort avec beaucoup d interactions exemples Gros syst me d exploitation Syst mes transactionnels complexes syst me de contr le a rospatial TYPE DE PROJET effort en homme mois HM Temps de d veloppement ORGANIQUE 2 4 KDS1 1 0 2 5 HM 0 38 MEDIAN 3 0 KDSD 12 2 5 HM 9 35 IMBRIQUE 3 6 KDSI 29 2 5 HM 9 32 Tableau 3 7 formules d estimation COCOMO pour le mod le de base EXEMPLES Effort HM 2KDSI 8KDSI 32KDSI 128 KDSI 512 KDSI Organique 5 21 3 91 392 M dian 6 5 31 146 687 3250 Imbriqu 8 3 44 230 1216 6420 Tableau 3 8 Effort en HOMMES MOIS HM en fonction de la taille et du type de projet TDEV mois 2KDSI 8KDSI 32KDSI 128 KDSI 512 KDSI Organique 4 6 8 14 24 M dian 4 8 8 3 14 24 42
11. n est quelques changements mineurs dans certains coefficients pourvu qu il n y ait pas trop de r utilisation Si la r utilisation intervient pendant le d veloppement clairement les co ts et dur es devraient tre r duits Il n existe aujourd hui aucun outil d valuation fiable prenant en compte la r utilisation Par contre si le d veloppement se fait en vue de la r utilisation il faudra pr voir une augmentation des estimations Des publications r centes ont montr que le d veloppement de composant r utilisable peut prendre jusqu 3 fois plus de temps que pour un composant similaire non r utilisable On peut supposer qu a long terme les conomies faites gr ce la r utilisation surpasseront le surco t occasionn rapprocher de l amortissement d un investissement 3 6 SUIVI DE PROJET Une fois le planning d fini il importe de le respecter Au niveau d quipes de 4 10 personnes le responsable de projet utilise des fiches de suivi ou rapports d activit s qui permettent d identifier les d rives et d assurer le contr le budg taire Il en d duit L actualisation du graphe PERT Le diagramme de GANTT actualis Des diagrammes 45 qui donnent une perception visuelle de la d rive par rapport aux objectifs 3 6 1 Rapports d activit s Chaque membre de l quipe fournit un rapport d activit hebdomadaire succinct qui d crit l objectif atteindre pour la semaine le temps pass sur les diff rentes t
12. nature de la t che effectuer Les diagrammes ci dessous donnent une id e de la dur e du projet en fonction du nombre de personnes affect es dans 3 cas diff rents DUREE DU PROJET PERSONNEL TACHE PARFAITEMENT PARTITIONNEE Exemple codage et tests unitaires DUREE DU PROJET PERSONNEL TACHE NON PARTITIONNABLE Exemple analyse et conception globale DU DU PROJET PERSONNEL TACHE NECESSITANT UNE COMMUNICATION COMPLEXE Exemple d veloppement d un syst me d exploitation embarqu avec fortes contraintes espace temps 3 20 Anne Marie Hugues 12 02 01 Gestion de projet 3 7 2 Les acteurs principaux d un projet Le chef de projet Il est responsable de l ensemble du projet la fois au niveau des co ts et des d lais Il est responsable de la r daction et du suivi du plan projet Le responsable qualit Il est responsable de la mise en oeuvre du manuel qualit sur un projet donn Il r dige et fait appliquer le plan qualit du projet Le responsable des ressources mat rielles Il assure la disponibilit du mat riel conform ment la planification Le responsable de l int gration Il est responsable de la mise en oeuvre du plan d int gration Le responsable de la qualification Il est responsable de la mise en oeuvre du plan de qualification Le responsable des performances Il est responsable des tests de performances conform ment au cahier des charges et au plan qualit Il prend les mesures n ces
13. these proportions Le tableau 3 14 emprunt Jones donne une estimation de la dur e partir du nombre de points de fonction Type de logiciel Meilleur de la classe Moyen Pire de la classe Syst mes 0 43 0 45 0 48 Gestion 0 41 0 43 0 46 Petits projets 0 39 0 42 0 45 Tableau 3 14 Exposants pour le calcul de la dur e a partir des points de fonction source adapt de Determining Software Schedules Jones 1995c Ces exposants ont t calcul s partir de l analyse de milliers de projets Exemple pour un petit projet ayant 350 points de fonction confi une quipe moyenne on trouve 350 soit environ 12 mois calendaires Cette pratique ne remplace pas des m thodes plus pr cises mais donne une approximation rapide qui vaut mieux que la simple devinette On notera que l on retrouve la m me forme de m trique que dans COCOMO 81 de base et des chiffres sensiblement quivalents Estimation Ballpark Schedule Before using these tables you may want to reduce the schedule here is how to recompute effort ossible if ou use nominal roject table Schedule Compression factor desired schedule initial schedule compressed schedule effort initial effort Schedule Compression factor If you have an initial schedule of 12 months and an initial effort of 78 man months and you want a 10 months schedule that yield a compressed schedule effort of 94 man months which means that the 17 percent reduction
14. 0 000 27 2 900 15 590 19 1 000 500 000 30 3 900 17 780 20 1 400 Efficient Schedule the one you could reach with a good team and very good management source derived from data in Software Engineering Economics Boehm 1981 An Empirical Validation of Software Cost Estimation Models Kemerer 1987 Applied software Measurement Jones 1991 Measures for Excellence Putman and Myers 1992 and Assessment and Control of Software risks Jones 1994 Systems Products Business Products Shrink Wrap products System Size Schedule Effort Schedule Effort Schedule Effort lines of code calendar man calendar man calendar man months months months months months months 10 000 8 24 4 9 5 9 8 15 000 10 38 5 8 8 7 12 20 000 11 54 7 11 8 18 25 000 12 70 7 14 9 23 30 000 13 97 8 20 9 32 35 000 14 120 8 24 10 39 40 000 15 140 9 30 10 49 45 000 16 170 9 34 11 57 50 000 16 190 10 40 11 67 60 000 18 240 10 49 12 83 70 000 19 290 11 61 13 100 80 000 20 345 12 71 14 120 90 000 21 400 12 82 15 140 100 000 22 450 13 93 15 160 120 000 23 560 14 115 16 195 140 000 25 670 15 140 17 235 160 000 26 709 15 160 18 280 180 000 28 910 16 190 19 320 3 12 Anne Marie Hugues 12 02 01 Gestion de projet 200 000 29 1 300 17 210 20 360 250 000 32 1 300 19 280 22 470 300 000 34 1 650 20 345 24 590 400 000 38 2 350 22 490 27 830 500 000 42 3 100 25 640 29 1 100 Nominal Schedule Average team average project a normal project source derived fr
15. 3 GESTION DE PROJET 3 1 ESTIMATION DES COUTS ET DUREE eenessssnsnsennsnnsese 1 3 2 ESTIMATION DE LA TAILLE VIA LES POINTS DE FONCTION ALBRECHE 79 he unes nationale 1 3 3 ESTIMATIONS DES COUTS MODELE COCOMO CONSTRUCTIVE COST MODEL BOEHM SD ons mnere ei ttien ner i tests 2 33 1 Le Mod le d basent rt ln ee Es part rare aii 2 Ds TY POUICSES NA Mn iets cate cay ee ies a E E E E 3 3 3 3 Distribution par DRASS Lens A Lt Re Er aes 3 3 3 4 Limitations du mod le de bas s cats dents dd 5 3 3 5 Le mod le interm diaire ss rennais 5 3 4 ELEMENTS DE PLANIFICATION semences 6 3 4 1 D composition structur e des activit s WBS 6 3 4 2 Ordonnancement et d pendances Graphe PERT 8 3 4 3 R partition des activit s diagramme de Gantt 8 3 5 PLAN PROJE Donini s ea Ksa SiE r E a aaae 9 3 5 1 Contenu du plan projet Le SU ne eu 10 3 5 2 Mod le de plan projet IEEE 1987 s ssssessssessesessssessessssssessessessees 10 3 5 3 Planification pour le paradigme orient objets 10 3 6 SUIVI DE PROJET sysscscsdschacseavsiuscadsssvencepsbus ed Csonecsdaneetstacscnesseapeustacdiosens qaniaves 11 3 6 1 RAP POTtSHd ACHV IFES Len RUE a or nn ne Qi mnt 11 2 02 Diagramme ASTRA E A ne ne 11 3 7 ORGANISATION DU TRAVAIL ccssscccssssccsscssosssosssscoescsccsscrseescossescsensnesss 12 3 7 1 l ments de r flexion pour le partage du trav
16. IRECTION ET PLUSIEURS QUIPES 3 7 6 La taille des quipes Structuration en groupes de 2 10 personnes Nombre magique 7 2 3 7 7 Facteurs humains Outre l organisation du travail d quipe il faut veiller Aux motivations individuelles et la motivation collective de l quipe Aux relations entre les membres et avec l ext rieur A la dynamique du chef de projet Aux cueils viter Sur sp cialisation Trop de niveaux Pas assez de niveaux D responsabilisation A la formation et en particulier au temps d apprentissage du domaine Mais il faut savoir que de grandes variations sont li es aux facteurs humains Temps de codage 1A25 Temps de mise au point 1A 26 Temps CPU utilis 1AII Temps d ex cution 1A13 Lignes crites 1A5 Nombres d erreurs 1A10 Ces variations peuvent tre r duites par M thodologies de d veloppement Standards normes Confort mat riel logiciel en aucun cas elles ne peuvent tre annul es 3 8 ORGANISATION DE LA DOCUMENTATION La documentation associ e un projet doit tre le reflet de la vie de ce projet Elle est labor e et mise jour tout au long du projet Elle est constitu e par un ensemble de documents dont certains sont associ s aux phases verticales du cycle de vie et d autres sont plus transversaux Elle est r alis e par des sp cialistes partir de documents fournis par l quipe de d veloppement 3 8 1 Documents de r f
17. Il permet une v ritable gestion de projet utile pour de grands projets Le mod le expert n est pas d crit ici Gestion de projet Anne Marie Hugues 15 02 01 3 9 3 3 2 COCOMO II A la lecture du paragraphe pr c dent sur COCOMO 81 plusieurs questions viennent l esprit une seule entreprise est elle repr sentative comme base de d veloppement de COCOMO COCOMO reste tr s li au nombre de lignes de code surtout le mod le de base mais plus les programmeurs sont experts et leur salaire lev moins ils crivent de lignes de code pour un m me projet Comment prendre en compte le r utilisation Afin de prendre en compte ces critiques COCOMO II Boehm 98 est apparue COCOMO II peut tre calibr pour mieux correspondre aux projets de l entreprise COCOMO II tient compte de la r utilisation COCOMO II est constitu de trois mod les Mod le de composition d application Ce mod le est utilis pour les projets fabriqu s l aide des toolkits d outils graphiques Il est bas sur les nouveaux Object Points Mod le avant projet Mod le utilis pour obtenir une estimation approximative avant de conna tre l architecture d finitive Il utilise un sous ensemble de facteurs de productivit cost drivers Il est bas sur le nombre de lignes de code ou les points de fonction non ajust s Mod le post architecture Il s agit du mod le le plus d taill de COCOMO II A utiliser apr s le d veloppement
18. Imbriqu 4 9 8 4 14 24 41 Tableau 3 9 Temps de d veloppement en mois en fonction de la taille et du type de projet Le temps de d veloppement commence apr s les sp cifications fonctionnelles et s arr te apr s l int gration De ces chiffres on peut d duire la productivit KDSI HM et le nombre moyen de personnes sur le projet FSP HM TDEV On peut ensuite calculer la distribution de l effort par phases en RPD Requirements and Preliminary Design Conception globale et Plan d int gration DD Detail Design Conception d taill e CUT Code and Unit Test Programmation et Tests unitaires IT Integration and Test Int gration PROJET ORGANIQUE 2 KDSI 8KDSI 32KDSI 128KDI 512 KDSI RPD ie 16 16 6 DD 26 23 24 23 CUT 42 4 3 3 IT Pte 19 2 235 O PROJET MEDIAN _ TT RPD DD o 27 26 353 4 23 CUT Pay 3i 3 3 2 IT 19 2 23 23 31 a eS ee ee PROJET IMBRIQUE Ooo ST T ee ne eee RPD DD 28 237 26 235 24 CUT 32 30 23 2 24 IT 22 23 23 31 34 Gestion de projet Anne Marie Hugues 15 02 01 3 7 Tableau 3 10 distribution de l effort par phases en pourcentatge ORGANIQUE _ 2KDSI__ 8 KDSI__ 32 KDSI__ 128 KDI__ 512 KDSI RED 19S 19 199 DD et CUT 63 Jo 59 55 51 NT 18 22 26 30 ER a RS MEDIAN Se Rs RE ee EE RPD A 25 26 27
19. ail 12 3 7 2 Les acteurs principaux d un DrOJet issues dire 13 3 7 3 Profil des membres d une QUIPE er nm ere ane aes 13 3 7 4 N cessit de la structuration rie davcivsseeeetcu ans decades 14 3 7 5 Les types d organisation anne tint ne dat 14 3 7 6 La taille des quipes RSR Se re ne 16 21 14 Facteurs humains Se Casse 16 3 8 ORGANISATION DE LA DOCUMENTATION cscssscsssssccsscssccsssseeees 16 3 8 1 Documents de r f rence saunas beset sdacriantinesemterseeducsss 16 3 82 Forme d s doc ments suchcsariscistsaeleaisaeeaceslaestadebredeagdaneza uetladuanaeieas 17 3 8 3 Documentation utilisateurs 03 5 426 24 speeletasiandosiasavenecsdaxdiasineduararsesdaucsds 17 3 8 4 Documentation interne ESA cn eee en 18 3 9 CONCLUSION Sn einer radis 18 3 GESTION DE PROJET Il n est pas rare pour un projet logiciel de d passer le d lai estim de 25 100 c est m me partir de ces constatations que la crise du logiciel est apparue Aujourd hui si quelques projets ont encore des d rapages parfois catastrophiques certains ne d passent les pr visions que de 5 10 seulement le pr sent chapitre donne quelques indications pour parvenir ce type de r sultat Il est indispensable pour le client comme pour le fournisseur chef de projet et management d estimer l avance la dur e calendrier et le co t effort d un projet logiciel Il convient galement d en mesurer les risques en recensant les d pendances ext r
20. ammation style rigueur communication sens du groupe Int gration C est une phase o la comp tence requise est bien souvent celle d un ing nieur syst me Gestion de projet Anne Marie Hugues 15 02 01 3 21 Qualification Ici il s agit plut t de la comp tence d un ing nieur d application c est dire tr s proche du domaine du produit qualifier Maintenance La maintenance requiert des qualit s de rigueur analyse et expertise 3 7 4 N cessit de la structuration Dans un groupe non structur de N personnes il y a N N 1 2 interactions I Exemple N 3 gt 3 N 11 gt 1 55 Il faut donc structurer les quipes pour diminuer le temps pass a la communication Calcul du temps en heures jour pour des groupes non structur s N 4 gt T 2 N 8 gt T 4 N 16 gt T 6 N 24 gt T 7 5 Cependant la communication Am liore la compr hension du projet Permet une plus grande mobilit dans le projet Mais aussi Fait perdre du temps Peut nuire a la documentation dont on peut croire qu elle devient moins n cessaire 3 7 5 Les types d organisation Les extr mes PETIT GROUPE DE TRAVAIL SANS AUTORITE DEFINIE EGOLESS PROGRAMMING Le travail s effectue par consensus le travail de chacun devient le travail de tous L quipe s enrichit par le travail quotidien en commun les revues et inspections de code On limine l attachement son programme ses id es Cette notion appara t pour
21. cients pour le calcul d effort et de temps dans le mod le interm diaire Calcul de l effort HM dans le mod le interm diaire Identifier le mode de d veloppement organique m dian imbriqu Ceci donne 4 coefficients au mod le p productivit nominative e chelle appliqu e la taille du logiciel c constante du mod le et d chelle appliqu e au temps de d veloppement conform ment au tableau 3 13 Estimer le nombre de lignes du code source en KDSJ puis calculer le nombre d homme mois par la formule appropri e du tableau 3 13 On obtient HM base Estimer les 15 facteurs de productivit et calculer le facteur d ajustement a en multipliant les facteurs ensemble conform ment au tableau 3 12 Multiplier l effort nominal par le facteur d ajustement HM HM base a Calculer le temps de d veloppement en utilisant le tableau 3 13 TDEV c HH d on notera que les coefficients restent inchang s par rapport au mod le de base Dans le mod le interm diaire les coefficients multiplicateurs s appliquent uniform ment sur l ensemble des phases Mod le expert Le mod le expert inclut toutes les caract ristiques du mod le interm diaire avec une estimation de l impact de la conduite des co ts sur chaque tape du cycle de d veloppement d finition initiale du produit d finition d taill e codage int gration De plus le projet est analys en terme d une hi rarchie module sous syst me et syst me
22. es aux activit s 3 4 1 D composition structur e des activit s WBS La planification commence par un recensement des t ches r aliser La d composition structur e des activit s WBS Work Breakdown Structure permet de recenser l ensemble des activit s d un projet et de les d composer La d composition appara t sous forme arborescente Il s agit d une d composition purement statique elle ne tient pas compte du temps et par cons quent ne s attache pas l ordonnancement des activit s Elle permet une pr sentation analytique on doit d composer Gestion de projet Anne Marie Hugues 15 02 01 3 13 jusqu obtenir des activit s qui soient bien d finies et facile g rer c est dire dont les entr es et r sultats sont parfaitement identifi s et dont la responsabilit est confi e une ou des personnes pr cise s Elle permet au chef de projet de planifier son projet en tablissant le graphe PERT de celui ci Elle permet le suivi budg taire du projet en liaison avec les activit s l mentaires identifi es lors de la construction du PERT La WBS doit tre compl te car elle conditionne l laboration du PERT et donc du budget Elle doit tre non ambigu dans la d finition des activit s Elle doit d finir des activit s dont le r sultat est mesurable ces activit s feront l objet d affectation de ressources Il est noter que certaines activit s existent dans tout projet laboration des diff rents doc
23. et de fin au plus t t les couples au dessous sont les dates de d but et de fin au plus tard A ce niveau les activit s sont les plus l mentaires possibles Si le projet n cessite plusieurs quipes on a des PERT plusieurs niveaux 3 4 3 R partition des activit s diagramme de Gantt Ce diagramme permet de faire appara tre la r partition des activit s dans le temps et l affectation des individus Il est indispensable pour d finir le plan projet Il fournit une description d taill e des co ts en homme x mois et des dates pour chaque t che et pour chaque phase du projet A chaque tache sous tache on associe un objectif qui permet de rep rer la terminaison de l activit On d finit des points cl s milestones qui servent de borne interm diaire exemple r alisation d un prototype On d finit les revues qui sont aussi des milestones on n oubliera pas la t che de pr paration de la revue 3 16 Anne Marie Hugues 12 02 01 Gestion de projet activit 1 Cumul act 1 7 2 1 2 2 2 3 5 2 4 3 2 5 2 3 3 Tot mens 1 Cumul 1 Attention aux pics brutaux le passage du mois 6 au mois 7 n est pas judicieux on passe de 4 1 il est souvent n cessaire de proc der un lissage 3 5 PLAN PROJET C est l un des l ments cl s du cycle de vie C est aussi un l ment de base de la planification du d veloppement Le responsable du plan projet est le chef de projet du d veloppemen
24. eux m thodes convergent mais sur un petit syst me temps r el on a pu constater des divergences pouvant aller jusqu 45 points de fonction contre 70 features points 3 3 ESTIMATIONS DE L EFFORT MODELE COCOMO BOEHM 1981 1998 L estimation de l effort en homme mois fait suite l estimation de la taille en lignes de code source et permettra de d finir un calendrier pour le projet La m thode COCOMO fournit un algorithme permettant de d river une valuation de l effort et du planning partir de l estimation de la taille du logiciel Nous donnons en r f rence la m thode de Putman and Myers 1992 qui conduit galement une valuation de l effort 3 3 1 Description de la m thode La m thode COCOMO pour COnstructive COst Model a t d velopp par Dr Barry Boehm pour estimer l effort et le temps de d veloppement d un produit logiciel A l origine elle a t construite partir d une analyse des donn es par r gression pratiqu e sur 63 projets logiciels gestion et informatique industrielle comprenant de 2000 100 000 lignes de code dans l entreprise TRW USA COCOMO l avantage d tre un mod le ouvert Les donn es de calibrage les formules et tous les d tails des d finitions sont disponibles La participation son d veloppement est encourag e Aujourd hui COCOMO II est un nouveau produit beaucoup plus adapt l aspect r utilisation des composants modules existants La version 1998 a t calibr
25. for Future Software Life Cycle Processes COCOMO 2 0 Bohem et al 1995 http www ifpug org McConnell Steve Rapid Development Microsoft Press 1996 Presents all the factor to achieve rapid development from risk evaluation good practices classical mistake etc to team psychology or negociating Really great Boehm Barry W Software Engineering Economics Englewood Cliffs N J Prentice Hall 1981 COCOMO cost estimation model by its creator DeMarco Tom Controlling Software Projects New York Yourdon Press 1982 Describes several estimation models Putnam Lawrence H and Ware Myers Measures of Excellence Reliable Software on Time Within Budget Englewood Cliffs N J Yourdon Press 1992 Presents a full fleged software project estimation Explains how to calibrate a simple cost estimation model to your organisation and how to use it to estimate medium to large projects Jones Capers Assessment and Control of Software Risks Englewood Cliffs N J Yourdon Press 1994 Estimation Project management 3 26 Anne Marie Hugues 12 02 01 Gestion de projet Gilb Tom Principles of Software Engineering Management Workingham Englang Addison Wesley 1988 Practical advices for estimating software schedule Focus on the importance of controlling the project to achieve your objectives rather than passive prediction about it Dreger Brian Function Point Analysis Englewood Cliffs N J Prentice Hall 1989 Function Point Analysis Jones Caper
26. g Practices Manual dont la version courante est le IFPUG Manual 4 1 Le nombre de points de fonctions d un programme est bas sur le nombre et la complexit de cinq param tres Les donn es Entr es externes External Inputs EI Ces donn es peuvent venir d un cran ou d une autre application elles peuvent tre utilis es pour mettre jour un ou plusieurs fichiers internes il peut s agir d informations ou de donn es de contr le Les crans boites de dialogue messages travers lesquels un utilisateur entre une donn e font partie des entr es externes Sorties externes External outputs EO Ce sont les sorties d un programme elles peuvent prendre la forme de fichiers de sortie envoy s d autres application d crans de rapports de graphes destin s l utilisateur final ils sont cr s partir de fichiers logiques internes 3 2 Anne Marie Hugues 12 02 01 Gestion de projet Mod le des points de fonction Autres applications Fonctionnalit s de l application Figure 1 Mod le des points de fonction Les transactions Requ tes externes External Inquiry EQ Un proc d l mentaire mettant en jeu des entr es et des sorties qui r sulte en la production de donn es provenant de plus d un fichier logique interne Le processus ne met pas jour de fichier interne combinaison d entr es sorties o le r sultat appara t sous forme simple et imm diate g n ralement en utilisant une seule cl
27. ieures qui influeront sur les co ts et d lais Une remarque pr alable s impose quant au processus d estimation beaucoup trop souvent le management et les clients ont de la peine comprendre que l estimation est une activit comportant des difficult s intrins ques et la rendent encore plus difficile par ce manque de compr hension Le processus requiert des raffinements successifs il est impossible de fournir une estimation correcte jusqu ce que le logiciel soit appr hend dans son int gralit L estimation des co ts et dur e se fait en trois tapes lors d une r ponse un appel d offres o il s agit de fournir au plus vite une r ponse adapt e au march lors de la planification du projet o il s agit d tablir le plan projet et le plan qualit qui serviront de cadre contractuel au projet lors du d roulement du projet afin d affiner les pr visions et de les mettre jour 3 1 PROCESSUS D ESTIMATION La meilleure fa on d valuer le montant proposer dans un devis est sans doute de conna tre le budget que le client est pr t lui consacrer Il est toutefois peu probable que le client ait la na vet de faire part de ses pr visions de d penses L estimation du co t total d un projet logiciel comprend le co t de d veloppement du logiciel et du mat riel le co t de la formation le co t des outils Nous nous limitons ici au co t de d veloppement du logiciel qui sera calcul en fonction du temps pas
28. ille du produit nombre de lignes de code ou points de fonctions 2 Estimer l effort en homme mois 3 Estimer la dur e en mois ou semaines calendaires 3 2 ESTIMATION DE LA TAILLE VIA LES POINTS DE FONCTION ALBRECHT 79 L estimation des co ts passe comme nous l avons vu en d but de chapitre par l estimation de la taille et de la productivit Dans un premier temps nous avons d fini la productivit en terme de nombre de lignes de code source produites par unit de temps cette m trique simple pr sente cependant certains inconv nients l criture de lignes de code repr sente une toute petite partie du d veloppement pour des langages diff rents un m me logiciel se code avec un nombre de lignes diff rent comment compter le nombre de lignes commentaires on crit souvent du code non livr outils de d veloppement le nombre de lignes ne peut tre compt qu a posteriori Un autre moyen de mesurer la productivit consiste valuer le nombre de fonctionnalit s int ressantes produites par unit s de temps La m thode des points de fonction d finie chez IBM par Albrecht en 1979 puis rafin e en 83 propose ainsi d estimer la taille d un logiciel partir de valeurs connues t t dans le cycle de vie et qui sont ind pendantes du langage choisi pour l impl mentation La m thode est aujourd hui d fendue et mise jour par l IFPUG the International Function Point User Group qui publie the Function Point Countin
29. in the schedule requires a 21 percent increase in effort Most researchers have concluded that it isn t possible to achieve a schedule compression factor lower than about 0 75 0 80 Boehm 1981 Putnam and Myers 1992 Jones 1994 Gestion de projet Anne Marie Hugues 15 02 01 3 11 Shortest possible Schedule it is more a theorical limit you can t reach source derived from data in Software Engineering Economics Boehm 1981 An Empirical Validation of Software Cost Estimation Models Kemerer 1987 Applied software Measurement Jones 1991 Measures for Excellence Putman and Myers 1992 and Assessment and Control of Software risks Jones 1994 Systems Products Business Products Shrink Wrap products System Size Schedule Effort Schedule Effort Schedule Effort lines of code calendar man calendar man calendar man months months months months months months 10 000 6 25 3 5 5 4 2 8 15 000 v 40 4 1 8 4 9 13 20 000 8 57 4 6 11 5 6 19 25 000 9 74 5 1 15 6 24 30 000 9 110 5 5 22 7 37 35 000 10 130 5 8 26 7 44 40 000 11 170 6 34 7 57 45 000 11 195 6 39 8 66 50 000 11 230 7 46 8 79 60 000 12 285 7 57 9 98 70 000 13 350 8 71 9 120 80 000 14 410 8 83 10 140 90 000 14 480 9 96 10 170 100 000 15 540 9 110 11 190 120 000 16 680 10 140 11 240 140 000 17 820 10 160 12 280 160 000 18 960 10 190 13 335 180 000 19 1 100 11 220 13 390 200 000 20 1 250 11 250 14 440 250 000 22 1 650 13 330 15 580 300 000 24 2 100 14 420 16 725 40
30. iques g n rales du produit vus plus haut dans le paragraphe sur les points de fonction Les 15 facteurs sont multipli s entre eux pour donner un facteur d ajustement qui vient modifier l estimation donn e par la formule de base Facteurs de productivit Logiciel RELY Fiabilit requise DATA Volume des donn es manipul es CPLX Complexit du produit Mat riel TIME Contraintes de temps d ex cution STOR Contraintes de taille m moire VIRT Instabilit de la m moire Personnel ECAP Aptitude de l quipe AEXP Exp rience du domaine VEXP Exp rience de la machine virtuelle LEXP Ma trise du langage Projet 3 8 Anne Marie Hugues 12 02 01 Gestion de projet MODP Pratique de d veloppement volu es TOOL Utilisation d outils logiciels SCED Contraintes de d lais REY Os fe 088 LR 2 70 1e ts 1 ta pe o EE CR ER RS o u OR ER RE Eee TIME tt a3 1 66 D STORE nf a ot cd Ey 56 ee PC eee EE eee RO RO RER E E ES a SREB 129 11433 1 0o f 0o82 WE EE EUR DT CE RC RS OS EE RC a MORE 1720 ed ROSE a Bs es Too ota RS EE D EE DE A a E oE Tableau 3 12 Coefficients multiplicateurs pour chacun des facteurs de productivit TYPE DE PROJET effort en homme mois HM Temps de d veloppement ORGANIQUE 3 2 KDSD1 05 2 5 HM 9 38 MEDIAN 3 0 KDSI 12 2 5 HM 9 35 IMBRIQUE 2 8 KDSD1 20 2 5 HM 0 32 Tableau 3 13 coeffi
31. la premi re fois dans Hein 71 Elle est reprise dans les techniques de revues et d inspection de code d velopp es au chapitre validation v rification 3 22 Anne Marie Hugues 12 02 01 Gestion de projet L ORGANISATION CHIEF PROGRAMMER TEAM Il s agit d une structuration de l egoless programming faisant suite un projet r ussi publi par IBM en 1970 Un ing nieur en chef ou chef de projet ou senior programmeur dirige l quipe compos e de 2 5 personnes Il coordonne planifie et v rifie le travail effectu L adjoint seconde l ing nieur en chef et peut tout instant le remplacer L quipe peut s adjoindre les services d un ou plusieurs experts t l coms bases de donn es Le biblioth caire est une ressource partag e par divers projets Son importance ne peut tre n glig e Il maintient et contr le les l ments de la biblioth que de programmes v rifie l int grit des configurations sources donn es bandes documentation Il collecte les donn es qui permettront d valuer la productivit L am lioration de la qualit passe par cette activit d archivage et de contr le Chacun a acc s au travail de tous l ing nieur en chef a le leadership technique Ing nieur en chef O Adjoint O Biblioth caire Ing ni d O O O O O r isation Les structures interm diaires CHEF DE PROJET POUR PLUSIEURS EQUIPES Gestion de projet Anne Marie Hugues 15 02 01 3 23 COMIT DE D
32. lass par rubriques de difficult s croissantes Manuel de R f rence contient toutes les r f rences aux possibilit s du syst me class es par ordre alphab tique Autres documents destin s aux utilisateurs Plaquette publicitaire Carte de R f rence Aide en ligne man 3 8 4 Documentation interne Nous verrons la description pr cise de ces documents dans les chapitres concern s Nous insistons tout particuli rement sur la n cessit de maintenir la coh rence de tous les documents Pour cela il est souhaitable de g rer TOUS les documents avec un gestionnaire de versions par exemple SSCS RCS MAKE L utilisation d un dictionnaire des donn es permettra d avoir des d tails sur toutes les entit s manipul es avec des r f rences crois es 3 9 CONCLUSION La gestion de projet est une des meilleures garanties de l assurance qualit elle permet la ma trise du processus de d veloppement Il existe un certain nombre d outils pour aider le chef de projet dans sa t che Les outils manipulant des graphes PERT et des diagrammes Gantt Mac Project Method1 Teamwork Access Les m thodes COCOMO et Function points peuvent tre programm es tr s simplement sur des tableurs Enfin pour la documentation technique des outils comme Interleaf ou Framemaker seront pr f r s Word pour leur facilit d interfa age avec les outils d analyse et conception qui seront vus au chapitre suivant 3 10 REFERENCES de Cost Models
33. n diagrammes comment s COCOMO 81 COCOMO quation de base COCOMO 81 Universit Thailandaise Bibliographie d Estimations de Logiciel Compil par l Universit de Bournemouth UK Gestion de projet Anne Marie Hugues 15 02 01 3 27
34. om data in Software Engineering Economics Boehm 1981 An Empirical Validation of Software Cost Estimation Models Kemerer 1987 Applied software Measurement Jones 1991 Measures for Excellence Putman and Myers 1992 and Assessment and Control of Software risks Jones 1994 Systems Products Business Products Shrink Wrap products System Size Schedule Effort Schedule Effort Schedule Effort lines of code calendar man calendar man calendar man months months months months months months 10 000 10 48 6 9 7 15 15 000 12 76 7 15 8 24 20 000 14 110 8 21 9 34 25 000 15 140 9 27 10 44 30 000 16 185 9 37 11 59 35 000 17 220 10 44 12 71 40 000 18 270 10 54 13 88 45 000 19 310 11 61 13 100 50 000 20 360 11 71 14 115 60 000 21 440 12 88 15 145 70 000 23 540 13 105 16 175 80 000 24 630 14 125 17 210 90 000 25 730 15 140 17 240 100 000 26 820 15 160 18 270 120 000 28 1 000 16 200 20 335 140 000 30 1 200 17 240 21 400 160 000 32 1 400 18 280 22 470 180 000 34 1 600 19 330 23 240 200 000 35 1 900 20 370 24 610 250 000 38 2 400 22 480 26 800 300 000 41 3 000 24 600 29 1 000 400 000 47 4 200 27 840 32 1 400 500 000 51 5 500 29 1 100 35 1 800 3 5 LEMENTS DE PLANIFICATION On cherche D finir les activit s constituant le projet Organiser les activit s dans le temps valuer les d pendances entre activit s valuer l effort n cessaire pour chaque activit dur e maximum et minimum Affecter les personn
35. que moyens de contr le rapport d activit s ressources humaines quipes affect es au projet Techniques m thodes outils techniques employ s ex OMT OMTools C documentation dates de remise de la doc fonctions support gestion de configuration tests assurance qualit Calendrier budget lots lots avec le d tail des activit s et t ches constituant chaque lot d pendances mat rielles et logicielles pour le projet mais aussi pour tests simulation ressources autres qu humaines Identification des fournisseurs sous contractants budget et allocation de ressource calendrier d taill Gantt comprenant les dates de revues Risques Probl mes Pr occupations Il s agit de lister ici les probl mes potentiels que l on pressent En particulier Hypoth ses sur les effectifs Difficult s techniques nouvelle technologie Conflits sur le calendrier 3 5 3 Planification pour le paradigme orient objets Les m thodes d valuation vues plus haut s appliquent assez bien dans le cas de projet r alis s en suivant le paradigme objet La forte modularit induit une valuation plus facile de chaque l ment Il faut bien videmment tenir compte lors de l valuation de l ensemble des interactions existant entre chaque composant qui g n rent un overhead qu il ne faut pas n gliger 3 18 Anne Marie Hugues 12 02 01 Gestion de projet La m thode COCOMO peut tre appliqu e pratiquement telle quelle si ce
36. r vis actualis I incomplet et dans ce cas la date a laquelle le chapitre doit tre complet Exemples r vision 165 r vision 3 question 165 question 2 commentaire 165 commentaire 5 CLASSIFICATION document de travail sp cification conception code test administration compte rendu de r union MOTS CL S Ils permettent des recherches automatiques CONTENU Le contenu sera pr cis dans les chapitres associ s aux diff rentes phases du cycle de vie R GLES DE STYLE Utiliser des formes actives Faire des phrases courtes une seule id e par phrase Faire des paragraphes courts 7 phrases au plus Pr f rer les listes aux phrases Ne pas h siter r p ter si n cessaire Pas de verbiage viter les r f rences du style 1 2 3 4 5 pour parler d un objet plut t nommer l objet tre pr cis d finir les termes glossaire Attention la grammaire et l orthographe 3 8 3 Documentation utilisateurs Manuel utilisateur Gestion de projet Anne Marie Hugues 15 02 01 3 25 Il doit donner une impression initiale correcte Ce n est pas une plaquette publicitaire Il doit tre possible de lire sans aller dans tous les niveaux de d tail Structure possible Description fonctionnelle simple l aide d exemples de ce que le syst me peut faire Document d installation d crit la proc dure d installation souvent assorti d un fichier A LIRE READ ME Manuel d introduction utilisation normale exemple simples c
37. rence Il s agit des diverses documentations associ es au projet on distingue les l ments destin s aux utilisateurs de eux destin s aux d veloppeurs pendant le d veloppement et aux mainteneurs en phase de maintenance 3 24 Anne Marie Hugues 12 02 01 Gestion de projet Documents li s une phase du cycle de vie essentiellement destin aux d veloppeurs et mainteneurs cahier des charges document de sp cifications fonctionnelles plan d int gration manuel de conception globale et d taill e proc dures de validation tests unitaires d int gration de validation de non r gression code Documents transversaux la vie du projet Le glossaire la liste des abr viations Le plan projet Le plan qualit Documents remis au client Le manuel utilisateur Le manuel d installation Le manuel de maintenance 3 8 2 Forme des documents La documentation adopte une forme sp cifi e par le plan qualit Elle est conforme aux normes et conventions dict es par le manuel qualit de l entreprise Elle doit de toute fa on comporter les notions de num rotation chapitre statut date classification mots cl s Tout comme le reste du produit la documentation doit tre maintenue pour rester en phases avec les volutions du produit NUM ROTATION Elle peut tre unique ou par classe ou par t che STATUT Le statut peut prendre 4 valeurs D d finitif et approuv P partiel sujet modification et ou ajouts R
38. rs internes logiques Calculs complexes L application fait elle appel des traitements logiques ou math matiques complexes R utilisabilit L application est elle d velopp e pour satisfaire un ou plusieurs besoins clients Facilit d installation Quelle est la difficult de conversion et d installation Facilit op rationnelle Quelle est l efficacit et ou l automatisation des proc dures de d marrage backup et r cup ration en cas de panne Portabilit L application est elle sp cifiquement con ue d velopp e maintenue pour tre install e sur de multiples sites pour de multiples organisations Evolutivit L application est elle sp cifiquement con ue d velopp e maintenue pour faciliter le changement Tableau 3 6 Caract ristiques g n rales du syst me Une fois que les caract ristiques g n rales du syst me ont t valu es avec leur degr d influence respectif on peut calculer le degr d influence DI 0 lt DI lt 70 qui est la somme des degr s d influence de chaque caract ristique Le facteur d ajustement ou facteur technique de complexit se calcule par TCF 0 65 DI 100 on a 0 65 lt TCF lt 1 35 Et enfin on calcule le nombre de points de fonctions ajust s FP TCF UFC On peut maintenant calculer les co ts l effort et le calendrier partir d exp riences pr c dentes ou bien utiliser une m thode rapide de calcul du planning voir ci dessous
39. s d velopper celui ci par les ing nieurs dont on conna t le tarif horaire et le taux d implication dans le projet en terme de pourcentage de leur temps Les co ts du d veloppement logiciel sont donc troitement li s la notion de productivit des ing nieurs logiciels c est dire le nombre de lignes de code valid es produites par unit de temps A noter qu ces co ts salariaux charg s il ne faudra pas oublier de rajouter les co ts fixes selon un mode de calcul propre chaque entreprise Dans la suite lorsque nous parlerons de co ts nous entendrons donc effort en terme d hommes mois Une m thode raisonnable pour tablir une r ponse un appel d offres est de faire appel des experts qui vont proc der par analogie avec des projets d j achev s On value chaque l ment important du nouveau syst me en terme de pourcentage de co t d un l ment comparable dans le syst me achev L estimation du co t total du nouveau projet est obtenue par sommation des estimations l mentaires L estimation est un exercice difficile impossible en th orie et faisant donc appel des heuristiques Dans de trop nombreux cas l estimation pr alable est faite la h te dans le but de remporter un march la planification qui s ensuit est souvent p nalis e par une sous estimation initiale des co ts et d lais globaux Nous sugg rons en accord avec B Boehm d viter de donner une estimation qui s appuie sur un chiffre uniq
40. s Applied Software Measurement Assuring Productivity and Quality New York McGraw Hill 1991 Function Point Analysis Boehm Barry W Software Engineering Economics 1981 Cocomo dans toute sa profondeur par l auteur de Cocomo lui m me Boehm Barry W Software engineering economics IEEE Trans on Software Engineering 1984 D tails pour assigner les valeurs aux 15 facteurs de productivit Shepperd Martin Fundation of Software Measurement 1994 Le pourquoi et comment des diff rentes m thodes de mesure de logiciels Katwijk J van Inleiding software engineering 1994 Pressman Roger S adapted by Darrel Ince Software engineering A practitioner s approach 1994 Universite de Californie du Sud Centre de d veloppement de logiciel C est l endroit ou COCOMO a t d velopp et continu de l tre L tat du d veloppement de COCOMO II Les sponsors du programme de recherche T l charger des logiciels et de la documentation COCOTS Projet de recherche pour estimer les co ts les efforts et planifier des projets logiciels utilisant des composants existants COQUALMO Un mod le d estimation logiciel pour quilibrer co t planning et qualit CORADMO Le mod le COCOMO RAD est une extension de COCOMOII centr e sur les co ts de d veloppement logiciel utilisant les techniques du Rapid Application Development Un projet estim avec COCOMO 2 0 Bibliographie Quelques estimateurs en ligne Expert COCOMO II par USC avec es
41. saires pour atteindre les objectifs de performance d finis dans le cahier des charges simulation prototypes Le responsable de la maintenance C est le responsable de l quipe qui prendra en charge la maintenance du produit en g n ral diff rente de l quipe de d veloppement Le responsable de la documentation Il est responsable de la documentation du projet Ceci ne veut pas dire qu il r dige toute la documentation associ e au projet mais plut t qu il s assure de sa r daction Il d finit les normes de pr sentation des documents en accord avec le manuel qualit de l entreprise Il s assure de la mise jour de la documentation REMARQUE Sur les gros projets le chef de projet pourra nommer des responsables pour les phases amont du cycle de vie analyse des besoins sp cifications conception codage 3 7 3 Profil des membres d une quipe Ces profils doivent tre choisis en fonction de l intervention dans les diff rentes phases du cycle de vie Nous r pertorions les qualit s requises suivant les phases D finition et analyse des besoins Savoir anticiper Savoir analyser les strat gies Sp cifications fonctionnelles Clart pr cision coh rence rigueur L id al serait un ing nieur ayant la double comp tence utilisateur et concepteur Conception Cette phase demande des communications intenses Capacit s formaliser et abstraire Programmation et tests unitaires Discipline de progr
42. t L laboration du plan projet se fait d s la phase de planification On proc de ensuite par actualisations successives et raffinements Gestion de projet Anne Marie Hugues 15 02 01 3 17 3 5 1 Contenu du plan projet Le plan projet contient les l ments qui permettent de d finir le projet Domaine d application Objectifs Principales fonctionnalit s Autres caract ristiques Les limites Les performances Sc nario de d veloppement Classification des priorit s et des contraintes Br ve description de chaque composant Ressources Humaines Mat rielles Logicielles Co t Calendrier Ce document n est pas forc ment tr s long C est avant tout un instrument de travail pour le chef de projet et son management C est une garantie de qualit pour le client 3 5 2 Mod le de plan projet IEEE 1987 Introduction r sum du projet fournitures avec les dates documents codes jeux de tests proc dures pour faire voluer le plan projet r f rences des documents cit s dans le plan projet d finitions et acronymes Organisation du projet mod le de processus organisation bornes interm diaires revues avec participants but mat riel dates organisation structurelle voir plus loin organisation des quipes limites et interfaces description des interactions avec autres projets r les et responsabilit s Management Objectifs et priorit s Hypoth ses d pendances contraintes Gestion du ris
43. timation de risque Par Dr Ray Madachy Implementation tr s innovante donnant galement une valuation des risques Interface graphique conviviale COCOMO II par USC Interface lente et moins conviviale Predicate logic software systems Estimation en ligne du mod le interm diaire de COCOMO 81 COCOMO Interm diaire Interactive D velopp par 2 tudiants de l Universit de Caroline du Nord Interface graphique tr s sympathique Manuel d utilisation et Information sur le calculation COCOMO 81 La NASA Estimateur COCOMO mod le de Base COCOMO 81 COCOMO II COSTAR Entreprise commercialisant COCOMO II Critique de COCOMO Par des consultants sp cialis s de la gestion du risque par l utilisation des r seaux Bayesian COCOMO II tant bas sur l approche Bayesian Mod les d valuation de projet logiciel Les mod les orient s activit s Par M JM Jaeger EN FRANCAIS Universit du Texas Projet COCOMO Pr sentation de l histoire de COCOMO Manuel utilisateur et Estimateur en ligne COCOMO 81 Les buts de COCOMO Explications d un professeur de l Universit Britannique Estimation des co ts logiciels Universit de Calgary Bon r sum de la problematique m me si il ne parle pas directement de COCOMO Methodes d estimation des co ts logiciels Pr sentation rapide des diff rentes m thodes d estimation suivie par une pr sentation assez d taill e des 3 mod les de COCOMO 81 Formules COCOMO Pr sentation int ressante e
44. ue mais recommandons plut t d encadrer les pr dictions par une fourchette optimiste pessimiste Le tableau ci dessous Adapt de Cost Models for Future Software Life Cycle Processes COCOMO 2 0 Bohem et al 1995 donne une base d estimation pour passer d un chiffre unique une fourchette gr ce des coefficients multiplicateurs Taille et effort Optimist Optimiste Analyse initiale des besoins 025 ee D finition approuv e des besoins Sp cification des besoins Conception Globale 080 Ps 090 f o no Conception d taill e 090 110 095 Tableau 3 1 Coefficients multiplicateurs pour chaque phase du projet Pour utiliser les facteurs multiplicatifs du tableau il suffit de multiplier le point d estimation unique par les coefficients appropri s de mani re obtenir une fourchette d estimation dont on peut remarquer qu elle se Gestion de projet Anne Marie Hugues 15 02 01 3 1 resserre au fur et mesure que l on avance dans les phases 0 90 1 10 en conception d taill e contre 0 25 4 en analyse initiale des besoins donc au moment de la r ponse l appel d offres Plut t que d estimer la dur e du projet dans son ensemble on peut le d compose et estimer chacun de ses composants Nous verrons que cette technique s applique tr s bien l approche objets du fait de l ind pendance des diff rents objets entre eux De mani re g n rale le processus d estimation passe par 3 tapes 1 Estimer la ta
45. uments du cycle de vie Inspections Revues Construction d outils Apprentissage Exemples de sch mas de WBS arborescences NOUVEAUX PRODUITS OU EXTENSIONS 0000 Activite de Activites de Activites de Activites de GESTION DEVELOPPEMENT MAINTENANCE QUALIFICATION 1000 2000 3000 4000 Id crit plus loin 3 14 Anne Marie Hugues 12 02 01 Gestion de projet Activites de d veloppement 2000 D finition des Pr paration besoins d finition du annonce produit 2400 D finition des besoins i documentation client cahier des charges D finition du produit D veloppement Sp cifications fonciionnelles 2300 plan projet D finition des objectifs tude de faisabilit tude d opportunit sp cifications d objectifs plan de la phase 1 3 4 2 Ordonnancement et d pendances Graphe PERT On utilise un graphe de d pendances PERT Project valuation and Review Technique Pour chaque t che on indique une date de d but et de fin au plus t t et au plus tard Le diagramme permet de d terminer le chemin critique qui conditionne la dur e minimale du projet Ces techniques ne sont en aucun cas propres au g nie logiciel elles sont par exemple tr s fortement appliqu es dans le BTP Exemple Gestion de projet Anne Marie Hugues 15 02 01 3 15 0 3 3 7 7 9 11 15 5 11 Les dur es apparaissent dans les cercles les couples au dessus sont les dates de d but
Download Pdf Manuals
Related Search