SUJET DE SYNTHESE 2003 / 2004 B8

COCOMO

Auteur : BERTOUX Christophe Dcembre 2003

COCOMO

Page 1

BERTOUX

RESUME COCOMO est un acronyme pour COnstructive COst MOdel .Cest une mthode pour estimer le cot dun projet en fonction du nombre de lignes de code source .Il sappuie sur un cycle de dveloppement en V dcoup en phases et activits .Les quations du modle sont diffrentes selon les typologies de programmes .Son volution COCOMO II est utilis pour les projets bass sur une technologie moderne et rutilisation des composants .Un nouveau modle appel COCOTS , est en cours de dveloppement par lquipe de COCOMO .Ce modle permet destimer les cots et planifier des projets logiciels utilisant des composants existants .Cest encore un projet de recherche .

COCOMO

Page 2

BERTOUX

TABLE DES MATIERES

1 INTRODUCTION 2 COCOMO 2.1 TYPOLOGIE DES PROGRAMMES INFORMATIQUE 2.2 PHASE DU MODEL COCOMO 3 LE MODELE COCOMO 81 3.1 EQUATION DE BASE DU MODELE 3.2 VENTILATION PAR PHASE DU PROJET 3.3 REPARTITION DE LEFFORT ET DE LA DUREE PAR PHASE 4 CAS DES APPLICATIONS COMPOSITES 4.1 COMBINAISON DE S,P,E PROGRAMMES 4.2 LA REUTILISATION DES COMPOSANTS LOGICIEL 4.3 LES PROGICIELS ET LES COTS 5 LES MODELES COCOMO ITERMEDIAIRES ET DETAILLES 5.1 LE MODELE INTERMEDIAIRE 5.2 LE MODELE DETAILLE 6 LE MODELE COCOMO II 6 1 MOTIVATION 6.2 LES HYPOTHESES DE BASE DU MODELE COCOMO II 6.3 LE MODELE NOMINAL COCOMO II 7 COCOTS CONCLUSION ANNEXE GLOSSAIRE BIBLIOGRAPHIE

4 4 5 5 6 6 8 9 10 10 11 12 12 12 16 16 16 18 18 20 21 22 27 28

COCOMO

Page 3

BERTOUX

1 - INTRODUCTION Lestimation de la dure et de la valeur des cots dun projet stablissent trs tt dans le cycle de dveloppement dun projet ,c'est--dire lissue de la phase dexpression de besoins et de dfinitions des exigences comportementales ,lorsque la spcification fonctionnelle est labore dans ses grandes lignes .Lapproche la plus scientifique et la plus prcise du problme de lestimation des cots de dveloppement de logiciels est celle qui consiste utiliser un modle .Un tel modle sera bas sur lanalyse de projets termins .Le modle le mieux document dont les paramtres sont adaptables lenvironnement est le modle COCOMO dcrit par BOEHM en 1981. 2 - COCOMO COCOMO est un acronyme pour COnstructive COst MOdel .Cest une mthode pour estimer le cot dun projet logiciel dans le but dviter les erreurs de budget et les retards de livraison ,qui sont malheureusement habituels dans lindustrie de dveloppement logiciel .La mthode COCOMO est issue du modle en spirale pour la planification des projets qui dfinit quatre cadrans dans chaque spire dont un seul pour le dveloppement et trois pour la gestion du projet . Il a t dvelopp par BOEHM en 1981 sur une tude de 63 projets logiciels de 2.000 100.000 lignes de codes dans lentreprise TRW Int .Il permet destimer les cots et la dure du dveloppement dun logiciel en sappuyant sur une donne de base : le nombre de lignes de code source prvisibles ,exprim en Kilo Instructions Source Livres(KISL) .A dfaut ,il permet le calcul du nombre de lignes de code source que pourra produire un effort donn ; ou partir dune dure de dveloppement , leffort et le volume du code. Ce modle gnral se compose de trois modles diffrents : le modle de base , le modle intermdiaire , le modle dtaill . - Le modle de base est assez simpliste , il tablit des quations de leffort et du temps de mise en uvre avec le nombre de lignes de code source dun programme (KISL).Les coefficients de ces quations sont des paramtres dont la valeur diffre selon la typologie dun programme. Ce modle donne par ailleurs une rpartition de leffort et du temps de dveloppement par rapport un cycle de vie standard . -Le modle intermdiaire est un affinement du modle de base et ne sapplique qu leffort . Il prend en compte des paramtres (cost drivers , au nombre de quinze .cf. tableau 1 en annexe) qui corrigent la valeur de leffort dtermine partir dquations drives du modle de base . la valeur de ces paramtres est value partir de caractristiques lies lapplication , son ingnierie et ses contraintes dexploitation. Chaque paramtre prend une valeur nominative de 1 , et peut varier selon son importance dans le projet -Le modle dtaill ajuste les facteurs de cot du modle intermdiaire en les adoptant au modle par phase : dfinition initiale du produit ,dfinition dtaille , codage , intgration, car le poids relatif du facteur nest pas homogne dune phase lautre . Il fait galement apparatre une notion fondamentale de lingnierie systme concernant lorganisation hirarchique du systme en trois niveaux : systme , sous systme et module. Comme tout modle destimation , les conditions dapplication et demploi de COCOMO doivent tre soigneusement prcises . les formules de calcul tablies ne sont pas des formules

COCOMO

Page 4

BERTOUX

magiques indpendante de la ralit du projet . Les facteurs de cot du modle intermdiaire sont des paramtres ayant une forte teneur subjective . Une des difficults principales du modle rside dans la dtermination a priori du nombre de lignes de code livres . 2.1 -TYPOLOGIE DES PROGRAMMES INFORMATIQUE Programme de type S : programme dont la spcification est parfaitement dfinie et stable , et dont lactivit de programmation consiste essentiellement traduire la spcification en code informatique : ce sont des programmes de type organic si lon prend la dnomination utilis par Boehm . Ces projets sont raliss par une quipe de taille relativement petite travaillant dans un environnement familier et dans un domaine d'application connu de l'quipe. En consquence, le surcot d la communication est faible, les membres de l'quipe savent ce qu'ils ont faire et le font rapidement. Programme de type P : programmes algorithmiques rsolvant une classe de problme semblables avec incorporation de critres doptimisation qui peuvent varier selon les besoins de lusag : ce sont des programmes de type semi-detached . De tels programmes contiennent des algorithmes complexes qui requirent une validation soigne . Pour des projets de mode semi-dtach, l'quipe projet peut tre compose de programmeurs de divers niveaux d'exprience. Les membres de l'quipe ont une exprience limite de ce type de systme. Ils peuvent tre totalement inexpriments en ce qui concerne quelquesuns des aspects du systme dvelopper, mais pas tous. Programme de type E : programmes ragissant des stimuli de lenvironnement (humains , capteurs , autres systmes )qui peuvent tre alatoires , de dure quelconque , potentiellement entachs derreurs , ou dclencher une action prioritaire ncessitant dinterrompre diffrents traitements en cours qui seront repris plus tard . Ces programmes dits de type embedded (embarqu) , car on finit toujours par trouver de tels programmes dans les couches les plus basses des systmes , sont souvent de complexit exponentielle car lordre darrive des stimuli est quelconque . La caractristique principale d'un projet de mode embarqu est que le systme doit fonctionner sous des contraintes particulirement fortes. Le systme dvelopper est une partie d'un systme complexe et fortement connect de matriels et de logiciels, de normes et de procdures oprationnelles. En consquence, les modifications de spcifications destines contourner des problmes logiciels sont en gnral impossibles et les cots de validation extrmement levs. Du fait de la nature mme de ces projets, il est inhabituel de disposer d'ingnieurs logiciels expriments dans le domaine d'application.

2.2 -PHASE DU MODELE COCOMO Le modle COCOMO sappuie sur un cycle de dveloppement du logiciel en V dcoup en activits et phases (cf. figure 1 en annexe) ; on peut rattacher ces phases et ces activits aux processus dfinissant les cinq types de rfrentiels textuels documentaires (RFT) . La notion de phase dans le modle COCOMO correspond au processus dominant dans la phase . ce COCOMO Page 5 BERTOUX

processus de dveloppement comporte ainsi trois phases principales . Les phases du modle COCOMO sont : Phase 1 : expression du besoin et planification : RFT [EB/EC] ; Phase 2 : dveloppement ; Phase 2.1 : conception gnrale :RFT [CG] , Phase 2.2 : ralisation(programmation au sens large) , . Phase 2.2.1 : conception dtaille : RFT [CD] . Phase 2.2.2 : codage et tests unitaires : RFT [P/TU] Phase 2.3 : tests et intgration :RFT [VVT]

Phase 3 : exploitation et support Le cur du modle est bas sur lanalyse de la phase 2 , le dveloppement du logiciel et ce qui en est la matrialisation la plus visible : les lignes de code source livres . L e modle fait lhypothse que leffort ddi cette phase est estim partir de leffort calcul par la phase 2 , car tout effort entrane des cots dorganisation et de communications indpendants du contenu . Les cots constats dans la phase 3 dpendent dune part du taux derreurs rsiduelles , de la qualit de la documentation et dautre part du nombre de systmes installs . 3 -LE MODELE COCOMO 81 3.1 EQUATIONS DE BASE DU MODELE Le modle COCOMO 81 dtermine , pour la phase 2 du cycle de dveloppement , des quations qui relient entre elles trois des quatre quantits fondamentales du processus de conduite de projet : - effort moyen de dveloppement (EFF) exprim en homme x mois (h x m) - dure de dveloppement en mois (TDEV) - taille du logiciel raliser (KISL), exprim en milliers dinstructions source livres . Dans cette version du modle COCOMO dcrit par Boehm, un homme-mois correspond 152 heures de travail effectif. Ce chiffre tient compte des absences pour formation et vacances. De faon discutable, la dfinition d'une ligne source livre exclut normalement les logiciels d'aide aux dveloppeurs, bien que l'effort ncessaire leur dveloppement puisse tre significatif. Les commentaires et les lignes blanches sont exclus du dcompte des lignes sources. Le modle COCOMO simple suppose que les besoins ne seront pas significativement modifis pendant le dveloppement du systme et aussi que le droulement du projet est suivi la fois par le client et par l'organisation qui le dveloppe. Les quations suivantes tablissent les relations entre effort , dure de dveloppement et taille du logiciel raliser : EFF = a x (KISL)^b

COCOMO

Page 6

BERTOUX

TDEV = 2.5 x (EFF)^c Boehm a dtermin les valeurs de a et de b partir des rsultats danalyse statistique effectues sur un chantillon significatif de projets de tous secteurs applicatifs .Ces mesures ont permis de dterminer des valeurs moyennes de a ,b c en fonction de la typologie des programmes analyss Le tableau ci-dessous donne les valeurs de a ,b ,c . Typologie S P E a 2.4 30. 3.6 b 1.05 1.12 1.20 c 0.38 0.35 0.32

A partir des valeurs obtenues pour leffort (EFF) et la dure (TDEV) ,on peut dduire un certain nombre dinformations intressantes : leffectif moyen (N) affecter au projet et la productivit moyenne de lquipe implique dans la phase 2 : N = EFF / TDEV Productivit = KILS / EFF Pour illustrer le modle COCOMO simple, prenons l'exemple d'un projet de mode organic ayant une taille estime 32'000 lignes sources livres. D'aprs la premire quation, le nombre d'homme-mois requis pour ce projet est de: EFF = 2.4 * 321.05 = 91 hommes-mois De la seconde quation, nous dduisons le temps ncessaire la ralisation du projet: TDEV = 2.5 * 9110.38 = 14 mois. Le nombre de personnes requises pour raliser le projet dans cet intervalle de temps est donc: N = EFF/TDEV = 91/14 = 6.5 personnes. Considrons maintenant un grand projet logiciel embarqu ayant une taille estime d'environ 128'000 lignes sources livres. Le modle COCOMO simple donne les rsultats suivants: EFF = 3.6 * 1281.20 = 1216 hommes-mois TDEV = 2.5 * 12160.32 = 24 mois N = 1216/24 = 51 personnes.

COCOMO

Page 7

BERTOUX

Le modle COCOMO simple est destin donner un ordre de grandeur de l'effort requis pour raliser un projet. Avant de passer au modle intermdiaire, considrons quelques-unes des hypothses qui sous-tendent le modle simple. Tout d'abord, ce modle suppose un niveau de productivit qui a certainement t obtenu partir de donnes historiques. Dans le cas du mode organic, la productivit est de 352 KISL/homme-mois, ce qui correspond environ 16 lignes sources par personne et par jour. Dans le cas du mode embarqu, la productivit est de 105 KISL/homme-mois, c'est--dire environ 4 lignes sources par personne et par jour. Une conclusion plus intressante du modle COCOMO simple est que la dure ncessaire la ralisation du projet est fonction de l'effort total requis pour le projet et non du nombre d'ingnieurs logiciels. Ceci confirme l'hypothse qu'ajouter du personnel un projet en retard ne permettra sans doute pas de rattraper le temps perdu. Malheureusement, le modle COCOMO simple n'est pas particulirement utile pour estimer la faisabilit d'un projet lorsque les ressources en personnel sont limites et la date de livraison assez souple. Par exemple, il n'est pas certain qu'un projet estim 14 mois pour 6,5 personnes puisse tre ralis en 30 mois avec seulement 3 personnes disponibles. Le modle COCOMO simple est utile pour donner des ordres de grandeur mais il est souhaitable de prendre en compte d'autres facteurs que la taille et le mode du projet pour estimer l'effort ncessaire. Le modle COCOMO intermdiaire prend en compte certains de ces facteurs (cost drivers). 3.2 - VENTILATION DE LEFFORT PAR PHASE DU PROJET Stratgie de recouvrement des activits par phase : approche gnrale

Lorganisation du modle en phases et sous-phases conduit naturellement un certain degr de chevauchement des activits .Ce recouvrement est li la nature mme du dveloppement .La dfinition dun MCD (modle conceptuel des donnes ) concerne la phase conception gnrale (phase 2.1).Un premier MCD sera produit au cours de cette phase .UN second MCD de granularit plus fine , correspond au schma de la base de donnes, ce dernier modle ayant t dvelopp au cours de la phase de conception dtaille (phase 2.2.1) ; en relationnel , par exemple , il est courant de denormaliser ce stade certaines relation et tableaux du MCD pour des raisons de performance . Approche phase/activits du modle COCOMO

Pour la simplicit et la clart du modle , Boehm a adopt (figure 1 en annexe), et cest une pure convention de commodit de calcul , une approche qui distingue ce quil appelle phase du projet , par rapport aux activits traditionnelles du dveloppement logiciel telles quelles doivent apparatre dans la gestion de projet Dans cette approche , une activit comme la conception dune base de donnes peut se trouver ventile dans deux phases , au sens COCOMO , du projet .La ralisation du MCD sera clairement dans la phase de conception gnrale , alors que le schma et les transactions dadministration seront dans celle de conception dtaille .Il faut donc faire trs attention au maniement des phases par rapport aux activits qui figurent dans le plan projet .

COCOMO

Page 8

BERTOUX

Rappelons que les processus ou activits de dveloppement au sens de l ISO/CEI 12207 sont : analyse des besoins ,conception ,programmation ,planification des tests , v&v ,conduite de projet ,gestion de configuration ,assurance qualit et rdaction des manuels utilisateurs . En faisant cette convention ,Boehm propose une rpartition des activits par phase selon un taux propre de leffort correspondant lactivit dans la phase ;ces rpartitions sont donnes dans les tableaux 7.1 ,7.2 ,7.3 ,en annexe ,pour chaque typologie de programme et par taille de programme . Le modle met en vidence une notion que lon pourrait appeler activit dominante au sein dune phase .Pour les phases autres que la phase 2.3 RFT[VVT] , si lon examine les tableaux 7.1 ,7.2 ,7.3 ,lactivit dominante dune phase correspond lintitul de la phase .

3.3 REPARTITION DE LEFFORT ET DE LA DUREE PAR PHASE

Le modle COCOMO propose un premier mode ,trs simple , de rpartition de leffort et de la dure fond sur le dcoupage en phases , sans recouvrement de phases . Leffectif moyen de lquipe est dtermin par phase ,comme tant le rapport de leffort sur la dure .Lexploitation de cette information est plus intressante que la valeur de leffectif global ,dans la mesure o elle permet dvaluer le nombre de personnes affecter par phase du projet et ,de ce fait ,didentifier des pics de charge ,priodes au cours desquelles le nombre de ressources sollicites est le plus important et requiert un management particulirement soign .Cette valeur est encore plus problmatique que la prcdente ,pour les mmes raisons . Concernant les ressources affecter au projet , on constate que plus un programme est de typologie complexe , plus un grand nombre de ressource est affecter sur les phases avals du projet (sous phase 2.2 et 2.3) .Toutefois , il doit tre clair que le bon usage de ces ressources est totalement conditionn par la qualit du travail architectural effectu en 2.1 , c'est--dire que moins de 20% des cots va conditionner le bon fonctionnement de lensemble du projet .En effet , la figure ci-dessous donne le pourcentage de ressources affecter chaque phase du cycle de vie , par rapport leffectif total du projet et en fonction de la typologie pour un projet nominal .

COCOMO

Page 9

BERTOUX

4 CAS DES APPLICATIONS COMPOSITES 4.1 COMBINAISON DE S,P,E PROGRAMMES Dans des situations relles , une application est toujours un assemblage de programmes de type S,P,E qui interviennent respectivement dans des proportions p ,q ,r telles que : p + q + r =1 une bonne approximation pour dterminer leffort dune application composite est de considrer la moyenne pondre de leffort de lapplication sur les fonctions EFFs , EFFp , EFFe , appele effort moyen pondr ,c'est--dire : Effort moyen pondr = p x EFFs(KISL) + q x EFFp(KISL) + r x EFFe(KISL) O EFFs ,EFFp ,EFFe, sont les trois fonctions effort associes respectivement aux programmes de type S , P , E .Il faut noter que chacune de ces fonctions est applique la totalit des instructions source. Cependant , il est ncessaire de montrer que cette quation est valide , c'est--dire que la valeur deffort moyen pondr est toujours suprieure la somme des efforts des parties dapplication , c'est--dire : Somme effort = EFFs (KISLs) + EFFp (KISLp) + EFFe (KISLe) Cette dernire quation ne prend en compte leffort dintgration de lapplication .Par consquent , elle na pas lieu dtre considr pour calculer leffort global , mais peut tre fort utile pour dterminer leffort dintgration des trois composantes S,P,E .Ce dernier sera gal : Effort dintgration = effort moyen pondr Somme effort

COCOMO

Page 10

BERTOUX

Pour que tout ce qui vient dtre dit soit valide , dmontrons que : Effort moyen pondr > somme effort Il suffit en fait de dmontrer pour la partie S de lapplication que : p x EFFs(KISL) > EFFS(KISLs) , avec p = KISLs / KISL et p < 1 Linquation prcdente se rcrit : p x a x (KISL)^b > a x (p x KISL)^b , ce qui est quivalent montrer que : p > p^b , autrement dit que p^b-1 <1 . Comme 0 < p < 1 et 0 < b-1 <1, la dernire inquation est toujours vrai .Le mme raisonnement sapplique pour les parties P et E de lapplication . On peut conclure quune erreur dans la classification provenant de la typologie dune application peut faire varier les cots de faon trs importante .Il faut donc tre extrmement rigoureux quant la typologie de lapplication et viter les excs doptimisme . 4.2 - LA REUTILISATION DE COMPOSANTS LOGICIEL La tendance actuelle , thorise dans COCOMO II , que lon peut constater dans la mise en uvre des applications , en particulier client-serveur , est que celles-ci sont de plus en plus amenes utiliser des composants gnriques .De mme , certains composants sont lis au patrimoine dune organisation ou accessibles tous dans la philosophie du logiciel libre ; ce dernier permettant lutilisation sans frais de composants dj existant dans le cadre dun projet .Encore faut-il que ces composants soient facilement accessibles , que leur caractristiques non fonctionnelles soient connues , ce qui nest pas toujours le cas ; cela requiert de toute faon un effort pour les rechercher et les homologuer . La rutilisation devrait tre une opration de type bote blanche , car elle consiste prendre un module du code source existant et lintgrer dans une application en cours de ralisation .La question qui se pose est celle de limpact , en termes de rduction de leffort , de lintroduction dun composant rutilisable dans une application : bote blanche ne veut pas dire cot nul Si KISLtot est le nombre total de lignes de code livrer et KISLreuse celui qui sera rutilis , on a une quation deffort de ralisation de lapplication qui sera de la forme : Effort tot = Effot reuse + Effort af O Effort reuse est leffort de dveloppement des composants qui sont rutiliss et Effort af est celui qui reste fournir pour raliser lapplication .La valeur dterminer son Effort af en utilisant les formules appropries , soit : Effort af = a x (KISLtot)^b k x a x (KISL)^b avec k < 1 Cette quation fait lhypothse que la rutilisation de KISLreuse ne cote rien en programmation et que lon conomise une partie de leffort de conception .Mais cela est moins vident en intgration du composant lui-mme quil est prudent de comptabiliser , surtout sil faut le rassembler .Cest ce quexprime la constante k<1 , dont une valeur vraisemblable serait k = 0.5 .

COCOMO

Page 11

BERTOUX

Le calcul de cet effort dintgration doit tre considr comme une approximation thorique , car il ne sappuie que sur le nombre dinstructions .Il ne considre pas non plus lvaluation de la complexit des interfaces entre les modules rutiliss et lapplication principale , qui peut jouer un rle important dans le calcul de cet effort dintgration : plus une interface sera simple , plus les tests dintgration seront facile raliser , moins cet effort sera significatif .Dans son stade ultime , le composant devient une fonction assimilable une instruction du langage source ; le paramtre fondamental est alors la maturit du code et le nombre de dfauts rsiduels 4.3 LES PROGICIELS ET LES COTS Lutilisation de composants COTS (Commercial Off The Shelf) est la plupart du temps une opration de type botes noires , c'est--dire que lon na jamais accs au code source .Ces composants sont , comme pour les composants rutilisables , censs intgrer toutes les caractristiques de qualit et de confiance en vue de leur bon fonctionnement oprationnel ; ces caractristiques doivent cependant tre imprativement valides avant toute acquisition .La tendance , lheure actuelle , est de les utiliser de plus en plus dans la mise en uvre dapplications , afin de rpondre plus rapidement des demandes de fonctionnalits bien prcise .L progiciel est en fait une application complte quil faut paramtrer compte tenu du contexte demploi .Les scripts de paramtrage sont ce qui correspond la programmation ; il faut noter que les langages de scripts sont quasiment toujours propritaires et que leur smantique est gnralement mal dfinie . En consquence , ne connaissant pas en rgle gnrale les informations de base dun composant COTS , valuer leffort dintgration dun COTS au reste de lapplication savre difficile .cependant , on peut toujours tenter une estimation en comptant les lignes de code source correspondant aux scripts de paramtrage . En conclusion , il faut toujours faire lhypothse que leffort dintgration , part quelques situation triviales , est loin dtre ngligeable .Lintgration ncessite tout de bien connatre les caractristiques des interfaces du COTS , comme cest le cas pour les composants rutilisables .Ces interfaces se trouvent souvent sous la forme de fichiers de paramtre et sont nombreuses et pas toujours standardises , voire mal stabilises . Une architecture dapplication base sur un dcoupage en fonctions indpendantes , sappuyant sur des concepts standardiss , est certainement une bonne approche .Elle permet de bien isoler le COTS , ses fonctionnalits , ses interfaces , du reste de lapplication et de pouvoir lisoler le plus possible dans la perspective de lintgrer avec le minimum de risque et deffort . 5 LES MODELES COCOMO INTERMEDIAIRES ET DETAILLES 5.1 LE MODELE INTERMEDIAIRE Le modle COCOMO intermdiaire s'appuie sur les quations d'effort et de dure du modle simple. Il applique ensuite une srie de multiplications qui prennent en compte d'autres facteurs tels que la fiabilit requise, la taille de la base de donnes, les contraintes de temps d'excution et de taille mmoire, la qualification du personnel et l'utilisation d'outils logiciels. En tout, quinze facteurs supplmentaires sont introduits. Ils sont diviss en quatre classes: attributs du produit, attributs de l'environnement matriel et logiciel, attributs du personnel et attributs du projet.

COCOMO

Page 12

BERTOUX

Les attributs du projet sont:

Fiabilit requise du logiciel (FIAB): note sur une chelle allant de trs faible, o une dfaillance ne pose pas de problme particulier, trs leve, o une dfaillance met en pril la vie humaine, en passant par moyenne, o une dfaillance est la cause de pertes recouvrables. Taille de la base de donnes (DONN): note de faible, o la taille de la base de donnes (en octets) est moins de dix fois le nombre de lignes sources livres, trs leve, o la taille de la base de donnes est plus de mille fois plus grande que le programme, en passant par moyenne, o la taille de la base de donnes est entre dix et cent fois la taille du systme. Complexit du produit (CPLX): note sur une chelle allant de trs faible trs leve. Les produits de complexit faible utilisent des oprations d'E/S (entres/sorties) simples, des structures de donnes simples et du code linaire. Les produits de complexit moyenne utilisent des oprations d'E/S volues, multi-fichiers, des procdures de bibliothque et des communications entre modules. Une complexit leve peut signifier: traitement parallle, gestion de donnes complexes, etc.

Les attributs de l'environnement matriel et logiciel sont les contraintes de temps d'excution et d'espace mmoire qui affectent la productivit. Il y a quatre attributs de ce type:

Contraintes de temps d'excution (TEMP): not de moyen trs lev. Moyen signifie que 50% de la puissance disponible sera utilise, trs lev signifie que 95% de la puissance disponible sera utilise. Contraintes d'espace mmoire (ESPA): not de la mme manire que TEMP. Volatilit de la machine virtuelle (VIRT): la machine virtuelle est la combinaison de matriel et de logiciel sur laquelle le produit logiciel est dvelopp. Ce facteur sera not faible si cette machine n'est modifie qu'occasionnellement (une fois par an), moyen si elle est modifie tous les six mois et trs lev si elle est modifie toutes les deux semaines. Contraintes du systme de dveloppement (CSYS): note de trs faible pour le dveloppement l'aide d'un systme interactif, trs leve pour un systme non interactif et peu disponible.

Cinq attributs du personnel sont pris en compte afin de reflter l'exprience et l'aptitude de l'quipe de dveloppement travaillant sur le projet. Ces attributs sont: l'aptitude l'analyse (APTA), l'exprience dans le domaine d'application (EXPA), l'exprience de la machine virtuelle (EXPV), l'aptitude la programmation (APTP) et l'exprience du langage de programmation (EXPL). Ils sont tous nots de trs faible, qui signifie peu ou pas d'exprience, trs lev. qui signifie plus de trois ans d'exprience, en passant par moyen, qui signifie au moins un an d'exprience. Les attributs du projet sont lis l'utilisation d'outils, au contrle de l'avancement du projet et l'utilisation de mthodes de programmation modernes telles que la conception fonctionnelle descendante, les revues de conception et de codage, la programmation structure, etc. Les attributs du projet sont les suivants:

Mthodes de programmation modernes (PMOD): not de trs faible, en l'absence de mthode, trs lev lorsque la mthode est volue et l'quipe exprimente dans son utilisation.

COCOMO

Page 13

BERTOUX

Outils logiciels (OLOG): la disponibilit d'outils logiciels peut avoir un impact significatif sur l'effort ncessaire au dveloppement d'un systme. Cette disponibilit est note de trs faible lorsque seuls des outils trs primitifs, tels que des assembleurs, sont utiliss, trs leve lorsque des outils couvrant l'intgralit du cycle de vie sont disponibles. Dure requise du dveloppement (DREQ): cet attribut mesure l'cart entre la dure de dveloppement de la dure obtenue avec le modle COCOMO simple. Une valeur trs faible signifie une dure courte, alors qu'une valeur trs leve signifie une dure rallonge. Des valeurs leves ou des valeurs faibles impliquent toutes deux un effort de dveloppement supplmentaire.

Les multiplicateurs associes ces attributs sont montres la table1 en annexe qui est extraite de Boehm (1981). Notez que TB signifie trs bas, B bas, M moyen, E lev, TE trs lev et TTE trs, trs lev. Dans l'estimation des cots de maintenance, les valeurs sont les mmes pour tous les attributs, l'exception de FIAB, PMOD et DREQ. En effet, dans l'estimation des cots de maintenance, la dure de dveloppement initiale n'est pas pertinente. En revanche, l'utilisation de mthodes modernes de programmation a un effet plus positif en ce qui concerne l'augmentation de la productivit en priode de dveloppement. Cet effet augmente avec la taille du produit. Une valeur faible de l'attribut FIAB permet de diminuer l'effort de dveloppement ncessaire mais risque d'augmenter l'effort de maintenance. De plus, atteindre une bonne fiabilit en priode de maintenance est plus facile lorsque ce facteur a t pris en compte en priode de dveloppement. Les modles COCOMO simples et intermdiaires peuvent tre critiqus en ce qu'ils sont bass sur des variables qui sont trs difficiles estimer (taille du produit) et sur des attributs dont l'valuation est invitablement subjective et approche. De plus, le modle intermdiaire ne prend pas en compte des attributs tels que le type d'application dvelopper, la quantit de documentation requise, la continuit du personnel, la qualit des interfaces, etc. Il suppose en outre peu de changements dans les besoins et une gestion de projet de trs haute qualit. Ces dfauts sont caractristiques de tous les modles d'estimation de cots qui ont t proposs. Cependant, l'utilisation systmatique d'un modle tel que le COCOMO, ou de tout autre modle, dans le cadre d'une organisation donne, est susceptible d'amliorer l'exactitude des estimations de cot. Il n'est cependant gure possible d'utiliser ces modles algorithmiques pour comparer des estimations entre organisations diffrentes cause de la nature subjective des valuations des attributs. En fait. aprs avoir expriment le modle COCOMO. on peut dcouvrir que les constantes du modle doivent tre modifies pour reflter les circonstances locales. Boehm propose une mthode utilisant une approximation de type moindres carrs pour adapter la valeur des constantes des cots effectivement mesurs. De plus, selon les modes de travail particuliers une organisation, il est possible d'liminer ou de combiner des attributs du modle intermdiaire, ou d'ajouter de nouveaux attributs. Par exemple, les attributs de personnel peuvent tre regroups en un seul attribut. CSYS peut tre supprim dans le cas o un seul systme interactif de dveloppement est utilis. OLOG peut tre supprim lorsqu'un systme tel qu'Unix, avec sa bibliothque d'outils standard, est utilis. De nouveaux attributs pourront tre crs pour reflter le domaine d'application ou le fait que

COCOMO

Page 14

BERTOUX

certains projets traitent des donnes confidentielles, avec toutes les considrations de scurit que cela implique. Un des principaux bnfices de l'utilisation de ces mthodes d'estimation de cot est qu'elles fournissent des donnes quantitatives au processus de dcision de la direction. Ceci est trs prcieux, mme dans le cas o ces estimations sont approximatives. L'utilit de tels modles est nouveau dmontre dans les exemples qui suivent. Considrons une situation o le modle COCOMO simple prvoit un effort de 45 hommes-mois pour dvelopper un systme embarqu sur micro-ordinateur. Le matriel est constitu d'un microprocesseur 16 bits fonctionnant 4 Mhz et d'une mmoire centrale de 64 Koctets. Les multiplicateurs du modle COCOMO intermdiaire ont tous une valeur moyenne l'exception des suivants: FIAB 1,15 ESPA 1,21 TEMP 1,10 OLOG 1,10 Ainsi, utilisant le modle intermdiaire pour estimer l'effort ncessaire, nous obtenons: EFF = 45 * 1.15 * 1.21 * 1.10 * 1.10 = 76 hommes-mois. tant donn que le cot mensuel d'un ingnieur est de 6'000 $, le cot total de dveloppement pour ce projet est de: COUT = 76 * 6000 = 456'000 $. A l'examen de ces rsultats, il est clair que les contraintes matrielles affectent de faon significative les cots de dveloppement. Supposons maintenant que nous puissions utiliser un microprocesseur compatible fonctionnant 8 Mhz et 128 Koctets de mmoire centrale. Supposons de plus que pour ce faire, il soit ncessaire de dvelopper une interface matrielle avec un cot supplmentaire de 30'000 $. Avec ce nouveau processeur, les attributs ESPA et TEMP prennent alors une valeur moyenne. Du fait de la compatibilit, les attributs de personnel ne sont pas modifis. Le cot du logiciel devient: COUT = 45 * 1.24 * 1.15 * 6000 = 385'020 $ D'o une conomie de 70'980 $ obtenue en achetant du matriel plus performant. Supposons maintenant qu'il soit possible d'acheter un systme de dveloppement Unix au prix de 150'000 $. L'effet de cet investissement serait de diminuer la valeur de l'attribut d'exprience de la machine virtuelle puisque l'quipe projet est familire avec Unix, et de diminuer la valeur de l'attribut OLOG puisque de nombreux outils sont disponibles sous Unix. Le cot du logiciel devient: COUT = 45 * 0.91 * 0.87 * 1.10 * 1.15 * 6000 = 270'405 $. Ainsi le cot du systme de dveloppement Unix est entirement amorti sur ce seul projet. tant donn qu'Unix a toutes les chances de pouvoir tre rutilis pour d'autres projets, il s'agit d'un investissement extrmement rentable. Ces exemples illustrent bien l'apport des modles de cots extrmement simples. Boehm montre de plus comment les diffrentes estimations de cot peuvent tre faites au niveau des

COCOMO

Page 15

BERTOUX

phases du cycle de vie et pourquoi une estimation au niveau du composant et non pas au niveau du produit peut donner des rsultats plus prcis. 5.2 LE MODELE DETAILLE Le modle dtaill donne un dcoupage plus prcis des valeurs des facteurs de cot , dfinis dans le modle intermdiaire , par phase du cycle de dveloppement .Lanalyse de nombreux projets montre en effet que leur valeur nest pas constante tout au long du cycle de dveloppement du logiciel . On peut dire que le modle dtaill offre un trs grand niveau de dtaille pour exprimer les caractristiques de leffort par phase du projet .encore faut il que ces valeurs , qui sont des constantes , puissent tre ajustes par rapport un contexte organisationnel minemment variable , comme cela est propos dans le modle COCOMO II qui intgre la maturit des organisations .

6 LE MODELE COCOMO II 6.1 MOTIVATION Le modle COCOMO II est bas sur lide damliorer et de ractualiser le modle COCOMO 81 en considrant les besoins suivants : dvelopper un modle destimation fond sur une architecture de processus mieux adapt que le cycle en V aux nouvelles pratiques de la programmation , en particulier en se positionnant sur la problmatique du maquettage / prototypage , de lutilisation des progiciels et des perspectives offertes par lapproche composants rutilisables comme les logiciels libre/gratuit ;

adapter les paramtres qualitatifs du modle intermdiaire de COCOMO pour prendre en compte les progrs en ingnierie du logiciel , ou tout simplement la plus grande diversit des projets , tant en ce qui concerne les cots que les dures de ralisation des logiciels .

Le modle COCOMO II prend en compte les pratiques prvisibles de dveloppement du logiciel aux tats unis , lhorizon 2005 , sur la base dune rpartition sociologique des activits relevant de linformatique en cinq secteurs , selon le niveau dexpertise informatique requis .Le poids respectif de chaque secteur est caractris par le nombre de personne s impliques dans le processus de ralisation dapplications de la manire suivante . Dveloppement d applications /solutions par lutilisateur final 55 millions de personnes impliques des degrs divers

COCOMO

Page 16

BERTOUX

Gnrateurs et adaptations Dapplications 0.6 M dinformaticiens

Composition/assemblage Dapplications 0.7 M dinformaticiens

Intgration de systme 0.7 M dinformaticiens

Dveloppement dinfrastructures informatiques 0.75 M dinformaticiens Le secteur n1 concerne le dveloppement de solutions par lutilisateur final , qui est de loin le plus important ; il se justifie par le fait que les entreprises , des plus grandes aux plus petites , ont un besoin de traitement de linformation au niveau le plus fin des acteurs .Lingnierie de ces applications se fait au moyen doutils de gnration mis en uvre par lusager , permettant une meilleure flexibilit et plus de ractivit dans le dveloppement , ainsi quune meilleure prise en compte de ses besoins puisque cest lusager qui code plutt que le service ou la direction informatique .Le nombre de personnes impliques dans le dveloppement des vraies applications est estim aux tats unis 2.75 millions pour les annes 2005 . Le secteur n2 ddi aux infrastructures , concerne linformatique traditionnelle en particulier toute solution permettant de grer le traitement de transactions te linformatique rpartie sur diffrents sites gographiques .A linverse du secteur n1 , les personnes impliques dans ces dveloppement sont , ou devraient tre , des ingnieurs informaticiens qualifis , mais qui , souvent , matrisent peu le domaine applicatif .Les entreprises de ce secteur conomique sont les diteurs de logiciel et bien sr les constructeurs de matriel informatique . Le secteur n3 , ddi aux gnrateurs et adaptations dapplications , ralise les progiciels destins la gestion des entreprises et qui sont mis en uvre par les usagers .Ces progiciels , de ts grande taille , gnralement trs coteux , ncessitent presque toujours des adaptations faites laide de langages ad hoc fournis par le vendeur ou laide de scripts de paramtrages. Le secteur n4 de composition/assemblage dapplication concerne les applications qui sont trop spcifiques pour tre ralis avec un progiciel cls en main , tel que pour le secteur 3 cidessus , mais suffisamment simples ou matures pour tre dvelopp partir de composants logiciels existants et de progiciels que lon va faire interoprer .Les composants proviennent la fois du secteur infrastructure et du secteur des mtiers .Les logiciels libre sont une source importante de composants dont la prennit nest videmment garantie ,mais cela peut faire gagner du temps .Une application du secteur n1 pourra migrer, une fois la maturit atteinte , vers une solution du secteur n4 . Enfin , le secteur n5 de lintgration de systme concerne le dveloppement dapplications informatiques complexes forte innovation , intgres dans des systmes de grande taille , gnralement temps rel et de haut niveau de confiance .Tous les systmes des secteurs spatial , aronautique , nergie , transport , ncessitent , compte tenu de leur particularit , quune grande partie de leur dveloppements soient spcifiques , quand bien mme une partie importante sera ralis laide de composants ou de progiciels .La taille des logiciels intgrs dans de tels systmes se chiffre en millions de lignes source . 6.2 LES HYPOTHESES DE BASE DU MODELE COCOMO II

COCOMO

Page 17

BERTOUX

Le modle de dveloppement des systmes informatiss utilis par COCOMO II est bas sur le cycle de dveloppement dit en spirale propos par BOEHM dans les annes 1980-1990 et sur lanalyse du cycle de dveloppement bas sur les processus qui devait donner naissance au modle CMM .Notons au passage que la spirale peut parfaitement se reprsenter par une succession de V pralables au dveloppement proprement dit , de faon lever progressivement les risques et les incertitudes . La vraie bonne approche est celle de lingnierie systme qui consiste considrer le cycle systme dans sa globalit .Ce cycle est gnralement divis en quatre phases : faisabilit , dfinition , dveloppement et retrait .La phase faisabilit est celle o les concepts fonctionnels du systme sont dbroussaills , ventuellement laide de maquettes qui sont des objets jetables , ou laide de prototypes trs rudimentaires .La phase de dfinition est celle o lon dfinit larchitecture globale du systme et les interfaces correspondantes , ventuellement laide de prototypes qui sont des morceaux incomplets du systme rel ; lanalyse des caractristiques non fonctionnelles est alors imprative .La phase de dveloppement est la phase traditionnelle o lon ralise le logiciel en une ou plusieurs versions ; elle implique ts rapidement une forte activit de maintenance quil faut grer en parallle avec le dveloppement .La phase de retrait , pour ce qui concerne le logiciel , consiste examiner ce qui peut tre conserv ou rutilis dans le futur systme qui se substituera lancien . La phase de faisabilit implique une activit de maquettage / prototypage prcoce sapparentant au secteur composition / assemblage dapplications. La phase de dfinition est celle o toutes les incertitudes concernant larchitecture mettre en place doivent tre leves .Le modle destimation correspondant est COCOMO II estimation prcoce .Cela correspond au dcoupage en applications avec les bases de donnes bien identifis , ainsi que linfrastructure des communications indispensables linteroprabilit et les contrles correspondants . La phase de dveloppement est celle couverte par COCOMO 81 .Le modle de COCOMO II est appel post architecture pour bien indiquer que les alas de larchitecture sont supposs tous rsolus . Enfin , le secteur du dveloppement dapplications par lutilisateur final est considr comme hors modle . 6.3 LE MODELE NOMINAL COCOMO II Le nombre de KISL est estim soit directement partir des lignes de code source , soit laide de table de conversion des points de fonctions en KISL . Leffort nominal est calcul partir de la mme quation deffort que le modle COCOMO intermdiaire , soit n EFFns = a x KISL^b x Fci i=1 5 dans laquelle a= 2.94 et b =0.91 + 0.01 x SFj j=1 La dure calendaire nominale (NS , pour Nominal Schdule )est donne par :

COCOMO

Page 18

BERTOUX

TDEVns = 3.67 x (EFFns)^f 5 Dans laquelle F = 0.28 + 0.2 x 0.1 x SFj = 0.28 + 0.2 x (b 0.91) J=1 La diffrences entre cette quation et celle du modle COCOMO 81 intermdiaire concerne uniquement le mode de calcul des paramtres de lquation . Pour le modle estimation prcoce , 6 facteurs de cots sont considrs .Pour le modle postarchitecture , 16 facteurs de cots sont considrs .Le facteur de cot SCED(compression des dlais)est trait part car il nintervient que de faon indirecte . Lexposant a intgre 5 facteurs dchelle SF(scale factors) qui sont donn dans le tableau de la figure 3 de lannexe .Lorsque b1 COCOMO II fait apparatre ce que Boehm appelle des conomies dchelle que lon peut expliquer par une meilleure planification des versions et une meilleure rpartition des tches au sein dun projet systme . Le facteur dchelle SF est une agrgation de 5 paramtres : PREC , FLEX , RESL , TEAM , PMAT . PREC caractrise le degr de familiarit et/ou dinnovation de lapplication. FLEX caractrise le niveau de flexibilit auquel le dveloppement doit se conformer .Par exemple , plus un systme doit tre conforme aux besoins dune organisation cible soumise aux changements , plus la flexibilit sera leve . PREC et FLEX correspondent , en gros , la typologie S,P,E de COCOMO 81 . RESL , TEAM , et PMAT concernent la faon dont le processus de dveloppement est conduit . RESL caractrise la faon dont les incertitudes , en particulier celles qui concernent larchitecture , sont rsolues . TEAM caractrise la cohsion de lquipe de dveloppement , en particulier pour ce qui concerne les relations MOA , MOE et les divers sous-traitants . PMAT caractrise le niveau de maturit de processus de dveloppement au sens du CMM . Signalons enfin la correspondance entre les facteurs de cots de COCOMO 81 et de COCOMO II .

Facteur de cot COCOMO 81

Facteur de cot COCOMO II Estimation Prcoce RCPX Postarchitecture RELY DATA CPLX PDIF TIME

Remarques

RELY DATA CPLX TIME

Identique Identique Identique Identique

COCOMO

Page 19

BERTOUX

STOR VIRT ACAP PCAP AEXP VEXP LEXP TOOL MODP SCED

PERS PREX FCIL

STOR PVOL ACAP PCAP APEX PLEX LTEX TOOL PMAT

Identique Identique Identique Identique Identique Identique Les outils ont t significativement amliors. La maturit du processus remplace MODP Identique Nouveau Nouveau Nouveau Nouveau

SCED RUSE RCPX PERS FCIL

SCED RUSE DOCU PCON SITE

7 COCOTS On utilise de plus en plus des composants standard disponibles sur le march (COTS) pour crer de gros systmes logiciels , la ncessit de prdire raisonnablement le vritable cot du cycle de vie de ces composants saccrot . Les composants COTS offre des avantages court terme sur le plan de llaboration et de la planification , mais ils compliquent lentretien long terme requis aprs linstallation .De plus , les risques associs aux logiciels COTS sont differents des risques associs la cration de systmes de toutes pices .Ces risques uniques peuvent compliquer davantage llaboration et lentretien aprs linstallation . COCOTS est un modle qui largit le modle de cot COCOMO II et qui permet de modliser les composants COTS dans le contexte gnral de llaboration de systme laide de composants COTS .On prsente le modle actuel, ainsi que des conclusions prliminaires issues de lanalyse des donnes de ltalonnage collectes jusqu maintenant .

COCOMO

Page 20

BERTOUX

CONCLUSION COCOMO semble tre le plus connu des modles d'estimation de cot de projet logiciel , il reste la rfrence en matire d'estimation dtaille des cots et surtout de la ventilation de ces cots suivant les phases des projets. Les estimations de COCOMO sont d'autant plus fiables, que les paramtres du projet sont bien connus, c'est--dire qu'on a profit des projets prcdents pour talonner ces paramtres. Les principales faiblesses de COCOMO rside dans la ncessit d'avoir une estimation du nombre de lignes du logiciel. Cette taille du logiciel n'est connue qu' la fin de la ralisation et le problme de son estimation reste entier. Enfin il est conseill avant toute utilisation doutils de ce type , de comprendre en profondeur la teneur du modle .

COCOMO

Page 21

BERTOUX

ANNEXES

FIGURE 1

COCOMO

Page 22

BERTOUX

FIGURE 2 1: Multiplicateurs d'attributs de projet Attributs 6c|Valeurs TB FIAB DONN CPLX TEMP ESPA VIRT CSYS APTA EXPA APTP EXPV EXPL PMOD OLOG DREQ 0,75 -0,70 ----1,46 1,29 1,42 1,21 1,14 1,24 1,24 1,23 B M E TE TTE 0,88 1,00 1,15 1,40 -0,94 1,00 1,08 1,16 -0,85 1,00 1,15 1,30 1,65 --1,00 1,11 1,30 1,66 1,00 1,06 1,21 1,56

0,87 1,00 1,15 1,30 -0,87 1,00 1,07 1.15 -1.19 1,00 0,86 0,71 -1,13 1,00 0,91 0,82 -1,17 1,00 0,86 0,70 -1,10 1,00 0,90 -1,07 1,00 0,95 ----

1,10 1,00 0,91 0,82 -1,10 1,00 0,91 0,83 -1,08 1,00 1,04 1.10 --

: Multiplicateurs d'attributs de projet appliqus la maintenance Taille du produit (en KLSL) 5c|Valeurs TB FIAB PMOD 2 8 32 128 512 1,35 1,25 1,30 1,35 1,40 1.45 B M E TE 1,15 1,00 0,98 1,10 1,12 1,00 0,90 0,81 1,14 1,00 0,88 0,77 1,16 1,00 0,86 0,74 1,18 1,00 0,85 0,72 1,20 1,00 0,84 0,70

COCOMO

Page 23

BERTOUX

COCOMO

Page 24

BERTOUX

COCOMO

Page 25

BERTOUX

FIGURE 3 Facteurs Dchelle(SFj) Prcdence Trs bas Bas Nominal Elev Trs lev En grande partie familier :1.24 Dune certaine conformit :1.01 La plupart du temps :1.41 Coopration importante :1.10 Niveau 4 : 1.56

Totalement En grande partie En partie Plutt familier sans sans sans :2.48 prcdent :6.20 prcdent :4.96 prcdent :3.72 Flexibilit du Fig :5.07 Flexibilit Une certaine En dveloppement occasionnelle :4.05 flexibilit :3.04 conformit : 2.03 Architecture/ Un peu :7.07 En partie :5.65 Souvent : 4.24 Gnralement : rsolution des 2.83 risques Cohsion de Interaction trs Interaction plutt Coopration de Coopration lquipe difficile : 5.48 difficile : 4.38 base :3.29 apprciable : 2.19 Maturit du Niveau 1 bas : Niveau 1 haut : Niveau 2 :4.68 Niveau 3 : processus 7.8 6.24 3.12

COCOMO

Page 26

BERTOUX

GLOSSAIRE

SIGLE KISL EFF TDEV COTS MDU MCD ACAP APEX CPLX DATA DOCU LTEX PCAP PCON PLEX PVOL RELY RUSE SCED SITE STOR TIME TOOL

SIGNIFICATION Kilo Instruction Source Livres Effort moyen de dveloppement (h x m) Dure de dveloppement Commercial-Of-The-Shelf(Composant sur tagre) Modle de Donne Utilisateur Modle Conceptuel des Donnes Maturit des architectes Exprience du domaine applicatif Complexit de lapplication Taille de la base de donne Besoins de documentation couverts Pratique des langages et outils de programmation utiliss Maturit des programmeurs Turnover du personnel Exprience dutilisation de la plate-forme dexploitation Stabilit de la plate-forme dexploitation Contraintes de fiabilits du logiciel Rutilisation composants de lapplication Contrainte de planification Dveloppement sur plusieurs site Contrainte doccupation mmoire Contrainte sur la dure dexcution Utilisation doutils logiciel

COCOMO

Page 27

BERTOUX

BIBLIOGRAPHIE

Boehm, Barry W., Software Engineering Economics, (1981) Boehm, Barry W., Software engineering economics, IEEE Trans. on Software Engineering.,(1984). Shepperd, Martin, Fundation of Software Measurement, (1994) Katwijk, J. van, Inleiding software engineering, (1994) Pressman, Roger S., (adapted by Darrel Ince) Software engineering "A practitioner's approach", (1994)

J.Printz,C.Deh,B.Mesdon,N.Treves, Cot et dure des projets informatiques (2002) Boehm, C.Abts, A.Winsor Brown, S.Chulani,B.Clark ,E.Horowitz,R.Madachy, D.Reiffer, B.Steece, Software cost estimation with COCOMO II ,(2000) J.Prntz, le gnie logiciel ,Que sais-je ? n 2956

COCOMO

Page 28

BERTOUX