SUJET DE SYNTHESE 2003 / 2004 – B8
COCOMO
Auteur : BERTOUX Christophe
Décembre 2003
COCOMO
Page 1
BERTOUX
RESUME
COCOMO est un acronyme pour COnstructive COst MOdel .C’est une méthode pour estimer le coût d’un projet en fonction du nombre de lignes de code source .Il s’appuie sur un cycle de développement en V découpé en phases et activités .Les équations du modèle sont différentes selon les typologies de programmes .Son évolution COCOMO II est utilisé pour les projets basés sur une technologie moderne et réutilisation des composants .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 .
COCOMO
Page 2
BERTOUX
TABLE DES MATIERES
1 – INTRODUCTION
4
2 – COCOMO
4
2.1 – TYPOLOGIE DES PROGRAMMES INFORMATIQUE
5
2.2 – PHASE DU MODEL COCOMO
5
3 – LE MODELE COCOMO 81
6
3.1 – EQUATION DE BASE DU MODELE
6
3.2 – VENTILATION PAR PHASE DU PROJET
8
3.3 – REPARTITION DE L’EFFORT ET DE LA DUREE PAR PHASE
9
4 – CAS DES APPLICATIONS COMPOSITES
10
4.1 COMBINAISON DE S,P,E PROGRAMMES
10
4.2 – LA REUTILISATION DES COMPOSANTS LOGICIEL
11
4.3 – LES PROGICIELS ET LES COTS
12
5 – LES MODELES COCOMO ITERMEDIAIRES ET DETAILLES
12
5.1 – LE MODELE INTERMEDIAIRE
12
5.2 – LE MODELE DETAILLE
16
6 – LE MODELE COCOMO II
16
6 – 1 MOTIVATION
16
6.2 – LES HYPOTHESES DE BASE DU MODELE COCOMO II
18
6.3 – LE MODELE NOMINAL COCOMO II
18
7 – COCOTS
20
CONCLUSION
21
ANNEXE
22
GLOSSAIRE
27
BIBLIOGRAPHIE
28
COCOMO
Page 3
BERTOUX
1 - INTRODUCTION
L’estimation de la durée et de la valeur des coûts d’un projet s’établissent très tôt dans le cycle de développement d’un projet ,c'est-à-dire à l’issue de la phase d’expression de besoins et de définitions des exigences comportementales ,lorsque la spécification fonctionnelle est élaborée dans ses grandes lignes .L’approche la plus scientifique et la plus précise du problème de l’estimation des coûts de développement de logiciels est celle qui consiste à utiliser un modèle .Un tel modèle sera basé sur l’analyse de projets terminés .Le modèle le mieux documenté dont les paramètres sont adaptables à l’environnement est le modèle COCOMO d’écrit par BOEHM en 1981. 2 - COCOMO
COCOMO est un acronyme pour COnstructive COst MOdel .C’est une méthode pour estimer le coût d’un projet logiciel dans le but d’éviter les erreurs de budget et les retards de livraison ,qui sont malheureusement habituels dans l’industrie de développement logiciel .La méthode COCOMO est issue du modèle en spirale pour la planification des projets qui définit quatre cadrans dans chaque spire dont un seul pour le développement et trois pour la gestion du projet . Il a été développé par BOEHM en 1981 sur une étude de 63 projets logiciels de 2.000 à 100.000 lignes de codes dans l’entreprise TRW Int .Il permet d’estimer les coûts et la durée du développement d’un logiciel en s’appuyant sur une donnée de base : le nombre de lignes de code source prévisibles ,exprimé en Kilo Instructions Source Livrées(KISL) .A défaut ,il permet le calcul du nombre de lignes de code source que pourra produire un effort donné ; ou à partir d’une durée de développement , l’effort et le volume du code. Ce modèle général se compose de trois modèles différents : le modèle de base , le modèle intermédiaire , le modèle détaillé . - Le modèle de base est assez simpliste , il établit des équations de l’effort et du temps de mise en œuvre avec le nombre de lignes de code source d’un programme (KISL).Les coefficients de ces équations sont des paramètres dont la valeur diffère selon la typologie d’un programme. Ce modèle donne par ailleurs une répartition de l’effort et du temps de développement par rapport à un cycle de vie standard . -Le modèle intermédiaire est un affinement du modèle de base et ne s’applique qu’à l’effort . Il prend en compte des paramètres (cost drivers , au nombre de quinze .cf. tableau 1 en annexe) qui corrigent la valeur de l’effort déterminée à partir d’équations dérivées du modèle de base . la valeur de ces paramètres est évaluée à partir de caractéristiques liées à l’application , à son ingénierie et à ses contraintes d’exploitation. Chaque paramètre prend une valeur nominative de 1 , et peut varier selon son importance dans le projet -Le modèle détaillé ajuste les facteurs de coût du modèle intermédiaire en les adoptant au modèle par phase : définition initiale du produit ,définition détaillée , codage , intégration, car le poids relatif du facteur n’est pas homogène d’une phase à l’autre . Il fait également apparaître une notion fondamentale de l’ingénierie système concernant l’organisation hiérarchique du système en trois niveaux : système , sous système et module. Comme tout modèle d’estimation , les conditions d’application et d’emploi de COCOMO doivent être soigneusement précisées . les formules de calcul établies ne sont pas des formules COCOMO
Page 4
BERTOUX
magiques indépendante de la réalité du projet . Les facteurs de coût du modèle intermédiaire sont des paramètres ayant une forte teneur subjective . Une des difficultés principales du modèle réside dans la détermination a priori du nombre de lignes de code livrées . 2.1 -TYPOLOGIE DES PROGRAMMES INFORMATIQUE •
Programme de type S : programme dont la spécification est parfaitement définie et stable , et dont l’activité de programmation consiste essentiellement à traduire la spécification en code informatique : ce sont des programmes de type organic si l’on prend la dénomination utilisé par Boehm . Ces projets sont réalisés par une équipe de taille relativement petite travaillant dans un environnement familier et dans un domaine d'application connu de l'équipe. En conséquence, le surcoût 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 résolvant une classe de problème semblables avec incorporation de critères d’optimisation qui peuvent varier selon les besoins de l’usagé : ce sont des programmes de type semi-detached . De tels programmes contiennent des algorithmes complexes qui requièrent une validation soignée . Pour des projets de mode semi-détaché, l'équipe projet peut être composée de programmeurs de divers niveaux d'expérience. Les membres de l'équipe ont une expérience limitée de ce type de système. Ils peuvent être totalement inexpérimentés en ce qui concerne quelquesuns des aspects du système à développer, mais pas tous.
•
Programme de type E : programmes réagissant à des stimuli de l’environnement (humains , capteurs , autres systèmes …)qui peuvent être aléatoires , de durée quelconque , potentiellement entachés d’erreurs , ou déclencher une action prioritaire nécessitant d’interrompre différents 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 systèmes , sont souvent de complexité exponentielle car l’ordre d’arrivée des stimuli est quelconque . La caractéristique principale d'un projet de mode embarqué est que le système doit fonctionner sous des contraintes particulièrement fortes. Le système à développer est une partie d'un système complexe et fortement connecté de matériels et de logiciels, de normes et de procédures opérationnelles. En conséquence, les modifications de spécifications destinées à contourner des problèmes logiciels sont en général impossibles et les coûts de validation extrêmement élevés. Du fait de la nature même de ces projets, il est inhabituel de disposer d'ingénieurs logiciels expérimentés dans le domaine d'application.
2.2 -PHASE DU MODELE COCOMO Le modèle COCOMO s’appuie sur un cycle de développement du logiciel en V découpé en activités et phases (cf. figure 1 en annexe) ; on peut rattacher ces phases et ces activités aux processus définissant les cinq types de référentiels textuels documentaires (RFT) . La notion de phase dans le modèle COCOMO correspond au processus dominant dans la phase . ce COCOMO
Page 5
BERTOUX
processus de développement comporte ainsi trois phases principales . Les phases du modèle COCOMO sont : Phase 1 : expression du besoin et planification : RFT [EB/EC] ; Phase 2 : développement ; -
Phase 2.1 : conception générale :RFT [CG] , Phase 2.2 : réalisation(programmation au sens large) , . Phase 2.2.1 : conception détaillée : RFT [CD] . Phase 2.2.2 : codage et tests unitaires : RFT [P/TU] Phase 2.3 : tests et intégration :RFT [VVT]
Phase 3 : exploitation et support Le cœur du modèle est basé sur l’analyse de la phase 2 , le développement du logiciel et ce qui en est la matérialisation la plus visible : les lignes de code source livrées . L e modèle fait l’hypothèse que l’effort dédié à cette phase est estimé à partir de l’effort calculé par la phase 2 , car tout effort entraîne des coûts d’organisation et de communications indépendants du contenu . Les coûts constatés dans la phase 3 dépendent d’une part du taux d’erreurs résiduelles , de la qualité de la documentation et d’autre part du nombre de systèmes installés . 3 -LE MODELE COCOMO 81
3.1 –EQUATIONS DE BASE DU MODELE Le modèle COCOMO 81 détermine , pour la phase 2 du cycle de développement , des équations qui relient entre elles trois des quatre quantités fondamentales du processus de conduite de projet : - effort moyen de développement (EFF) exprimé en homme x mois (h x m) - durée de développement en mois (TDEV) - taille du logiciel à réaliser (KISL), exprimé en milliers d’instructions source livrées . Dans cette version du modèle COCOMO décrit par Boehm, un homme-mois correspond à 152 heures de travail effectif. Ce chiffre tient compte des absences pour formation et vacances. De façon discutable, la définition d'une ligne source livrée exclut normalement les logiciels d'aide aux développeurs, bien que l'effort nécessaire à leur développement puisse être significatif. Les commentaires et les lignes blanches sont exclus du décompte des lignes sources. Le modèle COCOMO simple suppose que les besoins ne seront pas significativement modifiés pendant le développement du système et aussi que le déroulement du projet est suivi à la fois par le client et par l'organisation qui le développe. Les équations suivantes établissent les relations entre effort , durée de développement et taille du logiciel à réaliser : EFF = a x (KISL)^b COCOMO
Page 6
BERTOUX
TDEV = 2.5 x (EFF)^c Boehm a déterminé les valeurs de a et de b à partir des résultats d’analyse statistique effectuées sur un échantillon significatif de projets de tous secteurs applicatifs .Ces mesures ont permis de déterminer des valeurs moyennes de a ,b c en fonction de la typologie des programmes analysés Le tableau ci-dessous donne les valeurs de a ,b ,c . Typologie
a
b
c
S
2.4
1.05
0.38
P
30.
1.12
0.35
E
3.6
1.20
0.32
A partir des valeurs obtenues pour l’effort (EFF) et la durée (TDEV) ,on peut déduire un certain nombre d’informations intéressantes : l’effectif moyen (N) à affecter au projet et la productivité moyenne de l’équipe impliquée dans la phase 2 : N = EFF / TDEV Productivité = KILS / EFF Pour illustrer le modèle COCOMO simple, prenons l'exemple d'un projet de mode organic ayant une taille estimée à 32'000 lignes sources livrées. D'après la première é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 déduisons le temps nécessaire à la réalisation du projet: TDEV =
2.5 * 9110.38 = 14 mois.
Le nombre de personnes requises pour réaliser le projet dans cet intervalle de temps est donc: / TDEV = 91/14 = 6.5 personnes. N = EFF Considérons maintenant un grand projet logiciel embarqué ayant une taille estimée d'environ 128'000 lignes sources livrées. Le modèle COCOMO simple donne les résultats 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 modèle COCOMO simple est destiné à donner un ordre de grandeur de l'effort requis pour réaliser un projet. Avant de passer au modèle intermédiaire, considérons quelques-unes des hypothèses qui sous-tendent le modèle simple. Tout d'abord, ce modèle suppose un niveau de productivité qui a certainement été obtenu à partir de données 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 intéressante du modèle COCOMO simple est que la durée nécessaire à la réalisation du projet est fonction de l'effort total requis pour le projet et non du nombre d'ingénieurs logiciels. Ceci confirme l'hypothèse qu'ajouter du personnel à un projet en retard ne permettra sans doute pas de rattraper le temps perdu. Malheureusement, le modèle COCOMO simple n'est pas particulièrement utile pour estimer la faisabilité d'un projet lorsque les ressources en personnel sont limitées 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 réalisé en 30 mois avec seulement 3 personnes disponibles. Le modèle 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 nécessaire. Le modèle COCOMO intermédiaire prend en compte certains de ces facteurs (cost drivers). 3.2 - VENTILATION DE L’EFFORT PAR PHASE DU PROJET -
Stratégie de recouvrement des activités par phase : approche générale
L’organisation du modèle en phases et sous-phases conduit naturellement à un certain degré de chevauchement des activités .Ce recouvrement est lié à la nature même du développement .La définition d’un MCD (modèle conceptuel des données ) concerne la phase conception générale (phase 2.1).Un premier MCD sera produit au cours de cette phase .UN second MCD de granularité plus fine , correspond au schéma de la base de données, ce dernier modèle ayant été développé au cours de la phase de conception détaillée (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/activités du modèle COCOMO
Pour la simplicité et la clarté du modèle , Boehm a adopté (figure 1 en annexe), et c’est une pure convention de commodité de calcul , une approche qui distingue ce qu’il appelle phase du projet , par rapport aux activités traditionnelles du développement logiciel telles qu’elles doivent apparaître dans la gestion de projet Dans cette approche , une activité comme la conception d’une base de données peut se trouver ventilée dans deux phases , au sens COCOMO , du projet .La réalisation du MCD sera clairement dans la phase de conception générale , alors que le schéma et les transactions d’administration seront dans celle de conception détaillée .Il faut donc faire très attention au maniement des phases par rapport aux activités qui figurent dans le plan projet . COCOMO
Page 8
BERTOUX
Rappelons que les processus ou activités de développement 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 rédaction des manuels utilisateurs . En faisant cette convention ,Boehm propose une répartition des activités par phase selon un taux propre de l’effort correspondant à l’activité dans la phase ;ces répartitions sont données dans les tableaux 7.1 ,7.2 ,7.3 ,en annexe ,pour chaque typologie de programme et par taille de programme . Le modèle met en évidence une notion que l’on pourrait appeler activité dominante au sein d’une phase .Pour les phases autres que la phase 2.3 RFT[VVT] , si l’on examine les tableaux 7.1 ,7.2 ,7.3 ,l’activité dominante d’une phase correspond à l’intitulé de la phase .
3.3 – REPARTITION DE L’EFFORT ET DE LA DUREE PAR PHASE
Le modèle COCOMO propose un premier mode ,très simple , de répartition de l’effort et de la durée fondé sur le découpage en phases , sans recouvrement de phases . L’effectif moyen de l’équipe est déterminé par phase ,comme étant le rapport de l’effort sur la durée .L’exploitation de cette information est plus intéressante que la valeur de l’effectif global ,dans la mesure où elle permet d’évaluer le nombre de personnes à affecter par phase du projet et ,de ce fait ,d’identifier des pics de charge ,périodes au cours desquelles le nombre de ressources sollicitées est le plus important et requiert un management particulièrement soigné .Cette valeur est encore plus problématique que la précédente ,pour les mêmes 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 coûts va conditionner le bon fonctionnement de l’ensemble du projet .En effet , la figure ci-dessous donne le pourcentage de ressources à affecter à chaque phase du cycle de vie , par rapport à l’effectif 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 réelles , 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 déterminer l’effort d’une application composite est de considérer la moyenne pondérée de l’effort de l’application sur les fonctions EFFs , EFFp , EFFe , appelée effort moyen pondéré ,c'est-à-dire : Effort moyen pondéré = p x EFFs(KISL) + q x EFFp(KISL) + r x EFFe(KISL) Où EFFs ,EFFp ,EFFe, sont les trois fonctions effort associées respectivement aux programmes de type S , P , E .Il faut noter que chacune de ces fonctions est appliquée à la totalité des instructions source. Cependant , il est nécessaire de montrer que cette équation est valide , c'est-à-dire que la valeur d’effort moyen pondéré est toujours supérieure à la somme des efforts des parties d’application , c'est-à-dire à : Somme effort = EFFs (KISLs) + EFFp (KISLp) + EFFe (KISLe )
Cette dernière équation ne prend en compte l’effort d’intégration de l’application .Par conséquent , elle n’a pas lieu d’être considéré pour calculer l’effort global , mais peut être fort utile pour déterminer l’effort d’intégration des trois composantes S,P,E .Ce dernier sera égal à: Effort d’intégration = effort moyen pondéré – Somme effort
COCOMO
Page 10
BERTOUX
Pour que tout ce qui vient d’être dit soit valide , démontrons que : Effort moyen pondéré > somme effort
Il suffit en fait de démontrer pour la partie S de l’application que : p x EFFs(KISL) > EFFS(KISLs)
, avec p = KISLs / KISL et p < 1
L’inéquation précédente se réécrit : 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 dernière inéquation est toujours vrai .Le même raisonnement s’applique pour les parties P et E de l’application . On peut conclure qu’une erreur dans la classification provenant de la typologie d’une application peut faire varier les coûts de façon très importante .Il faut donc être extrêmement rigoureux quant à la typologie de l’application et éviter les excès d’optimisme . 4.2 - LA REUTILISATION DE COMPOSANTS LOGICIEL La tendance actuelle , théorisée dans COCOMO II , que l’on peut constater dans la mise en œuvre des applications , en particulier client-serveur , est que celles-ci sont de plus en plus amenées à utiliser des composants génériques .De même , certains composants sont liés au patrimoine d’une organisation ou accessibles à tous dans la philosophie du logiciel libre ; ce dernier permettant l’utilisation sans frais de composants déjà existant dans le cadre d’un projet .Encore faut-il que ces composants soient facilement accessibles , que leur caractéristiques non fonctionnelles soient connues , ce qui n’est pas toujours le cas ; cela requiert de toute façon un effort pour les rechercher et les homologuer . La réutilisation devrait être une opération de type boîte blanche , car elle consiste à prendre un module du code source existant et à l’intégrer dans une application en cours de réalisation .La question qui se pose est celle de l’impact , en termes de réduction de l’effort , de l’introduction d’un composant réutilisable dans une application : boîte blanche ne veut pas dire coût nul Si KISLtot est le nombre total de lignes de code à livrer et KISLreuse celui qui sera réutilisé , on a une équation d’effort de réalisation de l’application qui sera de la forme : Effort tot = Effot reuse + Effort af
Où Effort reuse est l’effort de développement des composants qui sont réutilisés et Effort af est celui qui reste à fournir pour réaliser l’application .La valeur à déterminer son Effort af en utilisant les formules appropriées , soit : Effort af = a x (KISLtot)^b – k x a’ x (KISL)^b’
avec k < 1
Cette équation fait l’hypothèse que la réutilisation de KISLreuse ne coûte rien en programmation et que l’on économise une partie de l’effort de conception .Mais cela est moins évident en intégration du composant lui-même qu’il est prudent de comptabiliser , surtout s’il faut le réassembler .C’est ce qu’exprime la constante k<1 , dont une valeur vraisemblable serait k = 0.5 . COCOMO
Page 11
BERTOUX
Le calcul de cet effort d’intégration doit être considéré comme une approximation théorique , car il ne s’appuie que sur le nombre d’instructions .Il ne considère pas non plus l’évaluation de la complexité des interfaces entre les modules réutilisés et l’application principale , qui peut jouer un rôle important dans le calcul de cet effort d’intégration : plus une interface sera simple , plus les tests d’intégration seront facile à réaliser , moins cet effort sera significatif .Dans son stade ultime , le composant devient une fonction assimilable à une instruction du langage source ; le paramètre fondamental est alors la maturité du code et le nombre de défauts résiduels 4.3 – LES PROGICIELS ET LES COTS L’utilisation de composants COTS (Commercial Off The Shelf ) est la plupart du temps une opération de type boîtes noires , c'est-à-dire que l’on n’a jamais accès au code source .Ces composants sont , comme pour les composants réutilisables , censés intégrer toutes les caractéristiques de qualité et de confiance en vue de leur bon fonctionnement opérationnel ; ces caractéristiques doivent cependant être impérativement validées avant toute acquisition .La tendance , à l’heure actuelle , est de les utiliser de plus en plus dans la mise en œuvre d’applications , afin de répondre plus rapidement à des demandes de fonctionnalités bien précise .L progiciel est en fait une application complète qu’il faut paramétrer compte tenu du contexte d’emploi .Les scripts de paramétrage sont ce qui correspond à la programmation ; il faut noter que les langages de scripts sont quasiment toujours propriétaires et que leur sémantique est généralement mal définie . En conséquence , ne connaissant pas en règle générale les informations de base d’un composant COTS , évaluer l’effort d’intégration d’un COTS au reste de l’application s’avère difficile .cependant , on peut toujours tenter une estimation en comptant les lignes de code source correspondant aux scripts de paramétrage . En conclusion , il faut toujours faire l’hypothèse que l’effort d’intégration , à part quelques situation triviales , est loin d’être négligeable .L’intégration nécessite tout de bien connaître les caractéristiques des interfaces du COTS , comme c’est le cas pour les composants réutilisables .Ces interfaces se trouvent souvent sous la forme de fichiers de paramètre et sont nombreuses et pas toujours standardisées , voire mal stabilisées . Une architecture d’application basée sur un découpage en fonctions indépendantes , s’appuyant sur des concepts standardisés , est certainement une bonne approche .Elle permet de bien isoler le COTS , ses fonctionnalités , ses interfaces , du reste de l’application et de pouvoir l’isoler le plus possible dans la perspective de l’intégrer avec le minimum de risque et d’effort . 5 – LES MODELES COCOMO INTERMEDIAIRES ET DETAILLES
5.1 – LE MODELE INTERMEDIAIRE Le modèle COCOMO intermédiaire s'appuie sur les équations d'effort et de durée du modèle simple. Il applique ensuite une série de multiplications qui prennent en compte d'autres facteurs tels que la fiabilité requise, la taille de la base de données, les contraintes de temps d'exécution et de taille mémoire, la qualification du personnel et l'utilisation d'outils logiciels. En tout, quinze facteurs supplémentaires sont introduits. Ils sont divisés en quatre classes: attributs du produit, attributs de l'environnement matériel et logiciel, attributs du personnel et attributs du projet.
COCOMO
Page 12
BERTOUX
Les attributs du projet sont: •
•
•
Fiabilité requise du logiciel (FIAB): notée sur une échelle allant de très faible, où une
défaillance ne pose pas de problème particulier, à très élevée, où une défaillance met en péril la vie humaine, en passant par moyenne, où une défaillance est la cause de pertes recouvrables. Taille de la base de données (DONN): notée de faible, où la taille de la base de données (en octets) est moins de dix fois le nombre de lignes sources livrées, à très élevée, où la taille de la base de données est plus de mille fois plus grande que le programme, en passant par moyenne, où la taille de la base de données est entre dix et cent fois la taille du système. Complexité du produit (CPLX): notée sur une échelle allant de très faible à très élevée. Les produits de complexité faible utilisent des opérations d'E/S (entrées/sorties) simples, des structures de données simples et du code «linéaire». Les produits de complexité moyenne utilisent des opérations d'E/S évoluées, multi-fichiers, des procédures de bibliothèque et des communications entre modules. Une complexité élevée peut signifier: traitement parallèle, gestion de données complexes, etc.
Les attributs de l'environnement matériel et logiciel sont les contraintes de temps d'exécution et d'espace mémoire qui affectent la productivité. Il y a quatre attributs de ce type: •
• •
•
(TEMP): noté de moyen à très élevé. Moyen signifie que 50% de la puissance disponible sera utilisée, très élevé signifie que 95% de la puissance disponible sera utilisée. Contraintes d'espace mémoire (ESPA): noté de la même manière que TEMP. Volatilité de la machine virtuelle (VIRT): la machine virtuelle est la combinaison de matériel et de logiciel sur laquelle le produit logiciel est développé. Ce facteur sera noté faible si cette machine n'est modifiée «qu'occasionnellement (une fois par an), moyen si elle est modifiée tous les six mois et très élevé si elle est modifiée toutes les deux semaines. Contraintes du système de développement (CSYS): notée de très faible pour le développement à l'aide d'un système interactif, à très élevée pour un système non interactif et peu disponible. Contraintes de temps d'exécution
Cinq attributs du personnel sont pris en compte afin de refléter l'expérience et l'aptitude de l'équipe de développement travaillant sur le projet. Ces attributs sont: l'aptitude à l'analyse (APTA), l'expérience dans le domaine d'application (EXPA), l'expérience de la machine virtuelle (EXPV), l'aptitude à la programmation (APTP) et l'expérience du langage de programmation (EXPL). Ils sont tous notés de très faible, qui signifie peu ou pas d'expérience, à très élevé. qui signifie plus de trois ans d'expérience, en passant par moyen, qui signifie au moins un an d'expérience. Les attributs du projet sont liés à l'utilisation d'outils, au contrôle de l'avancement du projet et à l'utilisation de méthodes de programmation modernes telles que la conception fonctionnelle descendante, les revues de conception et de codage, la programmation structurée, etc. Les attributs du projet sont les suivants: •
(PMOD): noté de très faible, en l'absence de méthode, à très élevé lorsque la méthode est évoluée et l'équipe expérimentée dans son utilisation.
Méthodes de programmation modernes
COCOMO
Page 13
BERTOUX
•
•
Outils logiciels (OLOG): la disponibilité d'outils logiciels peut avoir un impact
significatif sur l'effort nécessaire au développement d'un système. Cette disponibilité est notée de très faible lorsque seuls des outils très primitifs, tels que des assembleurs, sont utilisés, à très élevée lorsque des outils couvrant l'intégralité du cycle de vie sont disponibles. Durée requise du développement (DREQ): cet attribut mesure l'écart entre la durée de développement de la durée obtenue avec le modèle COCOMO simple. Une valeur très faible signifie une durée écourtée, alors qu'une valeur très élevée signifie une durée rallongée. Des valeurs élevées ou des valeurs faibles impliquent toutes deux un effort de développement supplémentaire.
Les multiplicateurs associées à ces attributs sont montrées à la table1 en annexe qui est extraite de Boehm (1981). Notez que TB signifie très bas, B bas, M moyen, E élevé, TE très élevé et TTE très, très élevé. Dans l'estimation des coûts de maintenance, les valeurs sont les mêmes pour tous les attributs, à l'exception de FIAB, PMOD et DREQ. En effet, dans l'estimation des coûts de maintenance, la durée de développement initiale n'est pas pertinente. En revanche, l'utilisation de méthodes modernes de programmation a un effet plus positif en ce qui concerne l'augmentation de la productivité en période de développement. Cet effet augmente avec la taille du produit. Une valeur faible de l'attribut FIAB permet de diminuer l'effort de développement nécessaire mais risque d'augmenter l'effort de maintenance. De plus, atteindre une bonne fiabilité en période de maintenance est plus facile lorsque ce facteur a été pris en compte en période de développement. Les modèles COCOMO simples et intermédiaires peuvent être critiqués en ce qu'ils sont basés sur des variables qui sont très difficiles à estimer (taille du produit) et sur des attributs dont l'évaluation est inévitablement subjective et approchée. De plus, le modèle intermédiaire ne prend pas en compte des attributs tels que le type d'application à développer, 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 très haute qualité. Ces défauts sont caractéristiques de tous les modèles d'estimation de coûts qui ont été proposés. Cependant, l'utilisation systématique d'un modèle tel que le COCOMO, ou de tout autre modèle, dans le cadre d'une organisation donnée, est susceptible d'améliorer l'exactitude des estimations de coût. Il n'est cependant guère possible d'utiliser ces modèles algorithmiques pour comparer des estimations entre organisations différentes à cause de la nature subjective des évaluations des attributs. En fait. après avoir expérimenté le modèle COCOMO. on peut découvrir que les constantes du modèle doivent être modifiées pour refléter les circonstances locales. Boehm propose une méthode utilisant une approximation de type moindres carrés pour adapter la valeur des constantes à des coûts effectivement mesurés. De plus, selon les modes de travail particuliers à une organisation, il est possible d'éliminer ou de combiner des attributs du modèle intermédiaire, ou d'ajouter de nouveaux attributs. Par exemple, les attributs de personnel peuvent être regroupés en un seul attribut. CSYS peut être supprimé dans le cas où un seul système interactif de développement est utilisé. OLOG peut être supprimé lorsqu'un système tel qu'Unix, avec sa bibliothèque d'outils standard, est utilisé. De nouveaux attributs pourront être créés pour refléter le domaine d'application ou le fait que
COCOMO
Page 14
BERTOUX
certains projets traitent des données confidentielles, avec toutes les considérations de sécurité que cela implique. Un des principaux bénéfices de l'utilisation de ces méthodes d'estimation de coût est qu'elles fournissent des données quantitatives au processus de décision de la direction. Ceci est très précieux, même dans le cas où ces estimations sont approximatives. L'utilité de tels modèles est à nouveau démontrée dans les exemples qui suivent. Considérons une situation où le modèle COCOMO simple prévoit un effort de 45 hommes-mois pour développer un système embarqué sur micro-ordinateur.· Le matériel est constitué d'un microprocesseur 16 bits fonctionnant à 4 Mhz et d'une mémoire centrale de 64 Koctets. Les multiplicateurs du modèle COCOMO intermédiaire ont tous une valeur moyenne à l'exception des suivants: FIAB 1,15 ESPA 1,21 TEMP 1,10 OLOG 1,10 Ainsi, utilisant le modèle intermédiaire pour estimer l'effort nécessaire, nous obtenons: EFF =
45 * 1.15 * 1.21 * 1.10 * 1.10 = 76 hommes-mois.
Étant donné que le coût mensuel d'un ingénieur est de 6'000 $, le coût total de développement pour ce projet est de: COUT =
76 * 6000 = 456'000 $. A l'examen de ces résultats, il est clair que les contraintes matérielles affectent de façon significative les coûts de développement. Supposons maintenant que nous puissions utiliser un microprocesseur compatible fonctionnant à 8 Mhz et 128 Koctets de mémoire centrale. Supposons de plus que pour ce faire, il soit nécessaire de développer une interface matérielle avec un coût supplémentaire 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 modifiés. Le coût du logiciel devient: COUT = 45
* 1.24 * 1.15 * 6000 = 385'020 $ D'où une économie de 70'980 $ obtenue en achetant du matériel plus performant. Supposons maintenant qu'il soit possible d'acheter un système de développement Unix au prix de 150'000 $. L'effet de cet investissement serait de diminuer la valeur de l'attribut d'expérience de la machine virtuelle puisque l'équipe projet est familière avec Unix, et de diminuer la valeur de l'attribut OLOG puisque de nombreux outils sont disponibles sous Unix. Le coût du logiciel devient: COUT =
45 * 0.91 * 0.87 * 1.10 * 1.15 * 6000 = 270'405 $. Ainsi le coût du système de développement Unix est entièrement amorti sur ce seul projet. Étant donné qu'Unix a toutes les chances de pouvoir être réutilisé pour d'autres projets, il s'agit d'un investissement extrêmement rentable. Ces exemples illustrent bien l'apport des modèles de coûts extrêmement simples. Boehm montre de plus comment les différentes estimations de coût 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 résultats plus précis. 5.2 – LE MODELE DETAILLE Le modèle détaillé donne un découpage plus précis des valeurs des facteurs de coût , définis dans le modèle intermédiaire , par phase du cycle de développement .L’analyse de nombreux projets montre en effet que leur valeur n’est pas constante tout au long du cycle de développement du logiciel . On peut dire que le modèle détaillé offre un très grand niveau de détaille pour exprimer les caractéristiques de l’effort par phase du projet .encore faut il que ces valeurs , qui sont des constantes , puissent être ajustées par rapport à un contexte organisationnel éminemment variable , comme cela est proposé dans le modèle COCOMO II qui intègre la maturité des organisations .
6 – LE MODELE COCOMO II
6.1 – MOTIVATION Le modèle COCOMO II est basé sur l’idée d’améliorer et de réactualiser le modèle COCOMO 81 en considérant les besoins suivants : -
développer un modèle d’estimation 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 problématique du maquettage / prototypage , de l’utilisation des progiciels et des perspectives offertes par l’approche composants réutilisables comme les logiciels « libre/gratuit » ;
-
adapter les paramètres qualitatifs du modèle intermédiaire de COCOMO pour prendre en compte les progrès en ingénierie du logiciel , ou tout simplement la plus grande diversité des projets , tant en ce qui concerne les coûts que les durées de réalisation des logiciels .
Le modèle COCOMO II prend en compte les pratiques prévisibles de développement du logiciel aux états unis , à l’horizon 2005 , sur la base d’une répartition sociologique des activités relevant de l’informatique en cinq secteurs , selon le niveau d’expertise informatique requis .Le poids respectif de chaque secteur est caractérisé par le nombre de personne s impliquées dans le processus de réalisation d’applications de la manière suivante . Développement d’ « applications »/solutions par l’utilisateur final 55 millions de personnes impliquées à des degrés divers
COCOMO
Page 16
BERTOUX
Générateurs et adaptations D’applications 0.6 M d’informaticiens
Composition/assemblage D’applications 0.7 M d’informaticiens
Intégration de système 0.7 M d’informaticiens
Développement d’infrastructures informatiques 0.75 M d’informaticiens
Le secteur n°1 concerne le développement de solutions par l’utilisateur 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 l’information au niveau le plus fin des acteurs .L’ingénierie de ces « applications » se fait au moyen d’outils de génération mis en œuvre par l’usager , permettant une meilleure flexibilité et plus de réactivité dans le développement , ainsi qu’une meilleure prise en compte de ses besoins puisque c’est l’usager qui « code » plutôt que le service ou la direction informatique .Le nombre de personnes impliquées dans le développement des « vraies » applications est estimé aux états unis à 2.75 millions pour les années 2005 . Le secteur n°2 dédié aux infrastructures , concerne l’informatique traditionnelle en particulier toute solution permettant de gérer le traitement de transactions te l’informatique répartie sur différents sites géographiques .A l’inverse du secteur n°1 , les personnes impliquées dans ces développement sont , ou devraient être , des ingénieurs informaticiens qualifiés , mais qui , souvent , maîtrisent peu le domaine applicatif .Les entreprises de ce secteur économique sont les éditeurs de logiciel et bien sûr les constructeurs de matériel informatique . Le secteur n°3 , dédié aux générateurs et adaptations d’applications , réalise les progiciels destinés à la gestion des entreprises et qui sont mis en œuvre par les usagers .Ces progiciels , de tés grande taille , généralement très coûteux , nécessitent presque toujours des adaptations faites à l’aide de langages ad hoc fournis par le vendeur ou à l’aide de scripts de paramétrages. Le secteur n°4 de composition/assemblage d’application concerne les applications qui sont trop spécifiques pour être réalisé avec un progiciel clés en main , tel que pour le secteur 3 cidessus , mais suffisamment simples ou matures pour être développé à partir de composants logiciels existants et de progiciels que l’on va faire interopérer .Les composants proviennent à la fois du secteur infrastructure et du secteur des métiers .Les logiciels libre sont une source importante de composants dont la pérennité n’est évidemment garantie ,mais cela peut faire gagner du temps .Une application du secteur n°1 pourra migrer, une fois la maturité atteinte , vers une solution du secteur n°4 . Enfin , le secteur n°5 de l’intégration de système concerne le développement d’applications informatiques complexes à forte innovation , intégrées dans des systèmes de grande taille , généralement temps réel et de haut niveau de confiance .Tous les systèmes des secteurs spatial , aéronautique , énergie , transport , nécessitent , compte tenu de leur particularité , qu’une grande partie de leur développements soient spécifiques , quand bien même une partie importante sera réalisé à l’aide de composants ou de progiciels .La taille des logiciels intégrés dans de tels systèmes se chiffre en millions de lignes source . 6.2 – LES HYPOTHESES DE BASE DU MODELE COCOMO II
COCOMO
Page 17
BERTOUX
Le modèle de développement des systèmes informatisés utilisé par COCOMO II est basé sur le cycle de développement dit « en spirale » proposé par BOEHM dans les années 1980-1990 et sur l’analyse du cycle de développement basé sur les processus qui devait donner naissance au modèle CMM .Notons au passage que la spirale peut parfaitement se représenter par une succession de V préalables au développement proprement dit , de façon à lever progressivement les risques et les incertitudes . La vraie bonne approche est celle de l’ingénierie système qui consiste à considérer le cycle système dans sa globalité .Ce cycle est généralement divisé en quatre phases : faisabilité , définition , développement et retrait .La phase faisabilité est celle où les concepts fonctionnels du système sont débroussaillés , éventuellement à l’aide de maquettes qui sont des objets jetables , ou à l’aide de prototypes très rudimentaires .La phase de définition est celle où l’on définit l’architecture globale du système et les interfaces correspondantes , éventuellement à l’aide de prototypes qui sont des morceaux incomplets du système réel ; l’analyse des caractéristiques non fonctionnelles est alors impérative .La phase de développement est la phase traditionnelle où l’on réalise le logiciel en une ou plusieurs versions ; elle implique tés rapidement une forte activité de maintenance qu’il faut gérer en parallèle avec le développement .La phase de retrait , pour ce qui concerne le logiciel , consiste à examiner ce qui peut être conservé ou réutilisé dans le futur système qui se substituera à l’ancien . La phase de faisabilité implique une activité de maquettage / prototypage précoce s’apparentant au secteur composition / assemblage d’applications. La phase de définition est celle où toutes les incertitudes concernant l’architecture à mettre en place doivent être levées .Le modèle d’estimation correspondant est COCOMO II estimation précoce .Cela correspond au découpage en applications avec les bases de données bien identifiés , ainsi que l’infrastructure des communications indispensables à l’interopérabilité et les contrôles correspondants . La phase de développement est celle couverte par COCOMO 81 .Le modèle de COCOMO II est appelé post architecture pour bien indiquer que les aléas de l’architecture sont supposés tous résolus . Enfin , le secteur du développement d’applications par l’utilisateur final est considéré comme hors modèle . 6.3 – LE MODELE NOMINAL COCOMO II Le nombre de KISL est estimé soit directement à partir des lignes de code source , soit à l’aide de table de conversion des points de fonctions en KISL . L’effort nominal est calculé à partir de la même équation d’effort que le modèle COCOMO intermédiaire , 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 durée calendaire nominale (NS , pour Nominal Schdule )est donnée 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 différences entre cette équation et celle du modèle COCOMO 81 intermédiaire concerne uniquement le mode de calcul des paramètres de l’équation . Pour le modèle estimation précoce , 6 facteurs de coûts sont considérés .Pour le modèle postarchitecture , 16 facteurs de coûts sont considérés .Le facteur de coût SCED(compression des délais)est traité à part car il n’intervient que de façon indirecte . L’exposant a intègre 5 facteurs d’échelle SF(scale factors) qui sont donné dans le tableau de la figure 3 de l’annexe .Lorsque b≤1 COCOMO II fait apparaître ce que Boehm appelle des économies d’échelle que l’on peut expliquer par une meilleure planification des versions et une meilleure répartition des tâches au sein d’un projet système . Le facteur d’échelle SF est une agrégation de 5 paramètres : PREC , FLEX , RESL , TEAM , PMAT . PREC caractérise le degré de familiarité et/ou d’innovation de l’application. FLEX caractérise le niveau de flexibilité auquel le développement doit se conformer .Par exemple , plus un système doit être conforme aux besoins d’une organisation cible soumise aux changements , plus la flexibilité sera élevée . PREC et FLEX correspondent , en gros , à la typologie S,P,E de COCOMO 81 . RESL , TEAM , et PMAT concernent la façon dont le processus de développement est conduit . RESL caractérise la façon dont les incertitudes , en particulier celles qui concernent l’architecture , sont résolues . TEAM caractérise la cohésion de l’équipe de développement , en particulier pour ce qui concerne les relations MOA , MOE et les divers sous-traitants . PMAT caractérise le niveau de maturité de processus de développement au sens du CMM . Signalons enfin la correspondance entre les facteurs de coûts de COCOMO 81 et de COCOMO II . Facteur de coût COCOMO 81
Remarques
Estimation Précoce
Postarchitecture
RCPX
RELY
Identique
DATA
DATA
Identique
CPLX
CPLX
Identique
TIME
Identique
RELY
TIME
COCOMO
Facteur de coût COCOMO II
PDIF
Page 19
BERTOUX
STOR VIRT ACAP PCAP AEXP VEXP LEXP TOOL
STOR PVOL ACAP PCAP APEX PLEX LTEX TOOL
PERS PREX FCIL
MODP SCED
PMAT SCED RUSE RCPX PERS FCIL
SCED RUSE DOCU PCON SITE
Identique Identique Identique Identique Identique Identique Les outils ont été significativement améliorés. La maturité du processus remplace MODP Identique Nouveau Nouveau Nouveau Nouveau
7 – COCOTS
On utilise de plus en plus des composants standard disponibles sur le marché (COTS) pour créer de gros systèmes logiciels , la nécessité de prédire raisonnablement le véritable coût du cycle de vie de ces composants s’accroît . Les composants COTS offre des avantages à court terme sur le plan de l’élaboration et de la planification , mais ils compliquent l’entretien à long terme requis après l’installation .De plus , les risques associés aux logiciels COTS sont differents des risques associés à la création de systèmes de toutes pièces .Ces risques uniques peuvent compliquer davantage l’élaboration et l’entretien après l’installation . COCOTS est un modèle qui élargit le modèle de coût COCOMO II et qui permet de modéliser les composants COTS dans le contexte général de l’élaboration de système à l’aide de composants COTS .On présente le modèle actuel, ainsi que des conclusions préliminaires issues de l’analyse des données de l’étalonnage collectées jusqu’à maintenant .
COCOMO
Page 20
BERTOUX
CONCLUSION
COCOMO semble être le plus connu des modèles d'estimation de coût de projet logiciel , il 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. Les principales faiblesses de COCOMO 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. Enfin il est conseillé avant toute utilisation d’outils de ce type , de comprendre en profondeur la teneur du modèle .
COCOMO
Page 21
BERTOUX
ANNEXES
FIGURE 1
COCOMO
Page 22
BERTOUX
FIGURE 2 1: Multiplicateurs
d'attributs de projet
Attributs 6c|Valeurs TB
B
M
E
TE
TTE
FIAB
0,75
0,88 1,00 1,15 1,40 --
DONN
--
0,94 1,00 1,08 1,16 --
CPLX
0,70
0,85 1,00 1,15 1,30 1,65
TEMP
--
--
1,00 1,11 1,30 1,66
ESPA
--
--
1,00 1,06 1,21 1,56
VIRT
--
0,87 1,00 1,15 1,30 --
CSYS
--
0,87 1,00 1,07 1.15 --
APTA
1,46
1.19 1,00 0,86 0,71 --
EXPA
1,29
1,13 1,00 0,91 0,82 --
APTP
1,42
1,17 1,00 0,86 0,70 --
EXPV
1,21
1,10 1,00 0,90 --
--
EXPL
1,14
1,07 1,00 0,95 --
--
PMOD
1,24
1,10 1,00 0,91 0,82 --
OLOG
1,24
1,10 1,00 0,91 0,83 --
DREQ
1,23
1,08 1,00 1,04 1.10 --
: Multiplicateurs d'attributs de projet appliqués à la maintenance
Taille du produit (en KLSL) 5c|Valeurs TB
B
FIAB
1,35
1,15 1,00 0,98 1,10
PMOD 2
1,25
1,12 1,00 0,90 0,81
8
1,30
1,14 1,00 0,88 0,77
32
1,35
1,16 1,00 0,86 0,74
128
1,40
1,18 1,00 0,85 0,72
512
1.45
1,20 1,00 0,84 0,70
COCOMO
Page 23
M
E
TE
BERTOUX
COCOMO
Page 24
BERTOUX
COCOMO
Page 25
BERTOUX
FIGURE 3 Facteurs D’échelle(SFj)
Très bas
Bas
Nominal
Précédence
Elevé
Totalement En grande partie En partie Plutôt familier sans sans sans :2.48 précédent :6.20 précédent :4.96 précédent :3.72 Flexibilité du Figé :5.07 Flexibilité Une certaine En développement occasionnelle :4.05 flexibilité :3.04 conformité : 2.03 Architecture/ Un peu :7.07 En partie :5.65 Souvent : 4.24 Généralement : résolution des 2.83 risques Cohésion de Interaction très Interaction plutôt Coopération de Coopération l’équipe difficile : 5.48 difficile : 4.38 base :3.29 appréciable : 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
Très élevé
En grande partie familier :1.24 D’une certaine conformité :1.01 La plupart du temps :1.41 Coopération importante :1.10 Niveau 4 : 1.56
BERTOUX
GLOSSAIRE
SIGLE
SIGNIFICATION
KISL EFF TDEV COTS
Kilo Instruction Source Livrées Effort moyen de développement (h x m) Durée de développement Commercial-Of-The-Shelf(Composant sur étagère) Modèle de Donnée Utilisateur Modèle Conceptuel des Données Maturité des architectes Expérience du domaine applicatif Complexité de l’application Taille de la base de donnée Besoins de documentation couverts Pratique des langages et outils de programmation utilisés Maturité des programmeurs Turnover du personnel Expérience d’utilisation de la plate-forme d’exploitation Stabilité de la plate-forme d’exploitation Contraintes de fiabilités du logiciel Réutilisation composants de l’application Contrainte de planification Développement sur plusieurs site Contrainte d’occupation mémoire Contrainte sur la durée d’exécution Utilisation d’outils logiciel
MDU MCD ACAP APEX CPLX DATA DOCU LTEX PCAP PCON PLEX PVOL RELY RUSE SCED SITE STOR TIME TOOL
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, Coût et durée 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 génie logiciel ,Que sais-je ? n° 2956
COCOMO
Page 28
BERTOUX
