Chapitre2
CHAPITRE II
Les Méthodes D'estimation De Coûts
De Logiciel
1. INTRODUCTION
De nombreux projets d'informatisation sont
confrontés au problème de l'estimation de l'effort
nécessaire à leur réalisation. L'objectif des chercheur et
responsables informatiques est de fournir des estimations exactes et
précises de l'effort de développement de projets logiciels
à une étape prématurée du cycle de vie du logiciel
Pour répondre à ce type de
difficulté et atteindre cet objectif, plusieurs méthodes
d'estimations d'effort a été développées.
Dans ce chapitre, nous présentons les
différentes techniques d'estimation des coûts de
développement de logiciels, ainsi nous représentons celles se
basent sur l'expertise, analogie et la stratégie descendante ou
ascendante. Nous exposons, en particulier, deus modèles, les
modèles algorithmiques
(paramétriques) sont les plus cités dans
la littérature. Ils sont développés en appliquant des
méthodes statistiques (la régression simple ou multiple,
l'analyse en Composantes principales, l'analyse bayésienne, ...etc.) ou
des méthodes de l'analyse numérique telle que l'interpolation
polynomiale sur des données historiques. Des exemples de tels
modèles sont COCOMO'81, COCOMO II, PUTNAM-SLIM et ceux se basant sur les
points de fonction.
Et les modèle non algorithmiques
(non
paramétrique) utilisant des approches de
l'intelligence artificielle telles que les réseaux de neurones, le
raisonnement par analogie, les arbres de régression.
[ALI]
Pour chaque technique de modalisation, nous
représentons les avantages et les inconvénients.
2. LE CONCEPT JOURS HOMMES
Le « Jour*Homme» est
l'unité de mesure de la charge de travail dans le contexte d'un
projet.
Concrètement, si un projet est estimé
à «cent jours pour une personne à plein
temps» pour arriver à son terme, on pourra
considérer qu'il s'agit d'un projet estimé à
« 100 jours hommes» comme l'indique
l'intitulé du résultat de l'évaluation, si l'on confie la
réalisation de ce projet à un unique homme, ce dernier devrait
(sauf erreur d'estimation, et sauf évènements extérieurs
perturbant la réalisation du projet) passer exactement cent jours
à le réaliser.
Cependant, nous pouvons nous permettre de supposer que
tout projet, à un certain niveau, est
« scindable » :
c'est-à-dire que l'on va pouvoir le décomposer (dans
la mesure où ce projet est de taille intuitivement suffisamment
élevée) en un ensemble de tâches. Et ceci est
aussi vrai dans les projets informatiques
« classiques », que dans les projets de la
nouvelle économie.
Si ce projet est partitionnable (et ce sera
quasiment toujours le cas), il est raisonnablement possible
d'effectuer plusieurs de ces tâches en parallèle - donc de les
faire effectuer par plusieurs hommes simultanément. Partant de ce
postulat, et dans un cadre idéal (figure II.1), on peut
donc considérer qu'un projet de 36 J*H
(planifié pour 12 hommes sur 3 jours) pourra
être effectué en 9 jours par 4 hommes. [GEO]
Fig II.1 -le principe de jour homme.
[GEO]
Une définition plus complète donnés par
SELON BROKS : « l'homme-mois comme
unité de mesurer la taille d'un travail est un mythe dangereux et
trompeur. Il implique que les hommes et les mois sont interchangeables. Les
hommes et les mois sont des biens interchangeables seulement lorsqu'une
tâche peut être partitionnée entre plusieurs employés
sans qu'il faille une communication entre eux ».
3. LIGNE DE CODE
Le nombre de milliers de ligne de code représente
la "taille" du projet. C'est principalement en fonction de cette "taille" que
l'on estimera le temps nécessaire à la réalisation du
projet.
On considère la définition de la ligne de
code donnée par N.E.Fenton (SOFTWARE
METRICS: A RIGOROUS AND PRACTICAL DATA, 1998)
:« Une ligne de code est toute ligne du texte d'un programme qui
n'est pas une ligne de commentaire, ou une ligne blanche, sans
considération du nombre d'instructions ou de fragments d'instructions
dans la ligne. Sont incluses toutes les lignes contenant des en-têtes de
programmes, des déclarations, et des instructions exécutables et
non exécutables. » [GEO]
On utilise les lignes de code dans les études
statistiques pour montrer que le ligne de code corrèle mieux que tout
autre mesure(par exemple, mesure de HLSTED, de McCABE) avec
les différentes autres données de mesure telles que celles sur
l'effort de développement et de maintenance et sur les erreurs.
4. TECHNIQUE D'ESTIMATION DES
COÛTS
Il existe plusieurs méthodes d'estimation de coût de
logiciel :
· Les modèles paramétriques(ou
algorithmique) ;
· Le jugement de l'expert(ou la méthode
Delphi);
· L'estimation par analogie ;
· Price to Win (gagner pour
plaire) ;
· La méthode descendante ;
· La méthode ascendante ;
· Les modèles non paramétriques(ou non
algorithmique).
4.1. Les modèles paramétriques d'estimation
des coûts (algorithmiques)
Les modèles paramétriques d'estimation des
coûts de développement de logiciels se basent essentiellement sur
une équation centrale exprimant l'effort en fonction d'un certain nombre
de variable considérées comme étant les principales
conductrices du coût.
En plus, le modèle pourra utilise des tables ou
des formules prédéterminées pour évaluer les
entrées de son équation centrale.la mise au point d'un
modèle paramétrique d'estimation suppose donc que la forme de
l'équation central du modèle est connu .cette équation
central représente la relation exprimant l'effort en fonction des
facteurs affectant les coûts.
Du fait que les modèles paramétriques
étaient les premières appliquées dans le domaine de
l'estimation des coûts .Plusieurs modèle paramétriques ont
été développés :
Des exemples de ces modèles sont :
· Les modèles linéaires.
· Les modèles analytiques.
Ø Halstead (1975)
Ø Putnam (1978)
· Point de fonction (Albert et Gaffney 1983)
· Cocomo (Boehm)
Ø Cocmo81 (Boehm 1981)
Ø CocomoII (Boehm 1995)
4.1.1. Les modèles
linéaires
Un modèle linéaire est de la forme :
Effort =
a0+a1x1+a2x2+ ...
+amxm (Equation 1).
Ou les xi sont les facteurs affectant l'effort et les ai
sont des coefficients choisis pour fournir le meilleur ajustement à
l'ensemble des données historiques observées.
Le coût de développement est
généralement obtenu par multiplication de l'effort par un
coût constant de la main d'oeuvre.
Une étude, réalisée par le system
développement corporation ver la moitié des années
soixante, examina plus de 100 conducteurs de coûts possibles, en
utilisant un échantillon de 169 projet.
Le meilleur modèle linéaire obtenue alors
était un modèle de 13 variables avec une estimation significative
de 40 homme-mois (HM) et une déviation standard de 62 HM.
4.1.2. Le modèle analytique
Les modèles analytiques adoptent une
équation centrale non-linéaire. Leur utilisation est
nécessaire quand la relation initiale, exprimant l'effort en fonction
des facteurs du coût, n'est pas toujours linéaire et qu'aucune
transformation des variables n'est possible afin de rendre cette relation
linéaire.
Dans la littérature, on ne trouve que peu de
modèles analytique qui ont été développés
(Halsted, 1975 ; Putnam, 1978). En effet :
· Souvent, un modèle linéaire satisfaisant et
concurrent peut être mis en place, éventuellement après la
transformation des variables.
· Quand cette relation n'est pas linéaire,
l'identification de la forme de la relation exprimant l'effort en fonction des
facteurs du coût est souvent très ardu.
· Les praticiens, dans leur majorité,
préfèrent apporter des améliorations de détail au
modèle linéaire concurrent plutôt que l'étudier le
modèle non-linéaire initial.
Fig II.2 - Exemple où relation
Effort-taille n'est pas linéaire.
Dans ce qui suit, nous représentons
brièvement deux exemples de modèles analytique : le
modèle d'Halstead et le modèle Putnam.
4.1.2.1. Le modèle d'Halstead
En 1972, Murice Halstead a entreprise une étude
empirique des algorithmes afin de tester l'hypothèse sel0n laquelle,
dans un programme, le comptage des opérateurs(expressions
verbales) et des opérandes(noms ou désignations
de données) pouvait faire apparaître des taille
corrélations avec le nombre des erreurs contenues dans les algorithmes
(Halstead,1975).
Suite de cette étude empirique, Halstead avait
défini quatre métriques basées sur l'analyse lexicale du
code source :
1 = nombre d'opérateurs distincts
2 = nombre d'opérandes distincts.
N1 = nombre totale d'utilisation des
opérateurs.
N2 = nombre total d'utilisation des
opérandes.
En suite, Halstead avait utilisé ces quatre
métriques pour développer une panoplie de formule
d'évaluation de certains attributs d'un logiciel tels que le vocabulaire
et le volume d'un programme, l'effort et la durée de codage d'un
programme. Les deux équations en rapport avec l'effort et la
durée de codage d'un programme sont respectivement :
Effort= (Equation
2)
Durée=
Où N=N1+N2. Cette équation d'estimation de
l'effort à partir des quatre métriques de base d'Halstead n'a pas
eu beaucoup d'intérêt dans la plupart des travaux de recherche en
estimation des coûts du fait que plusieurs hypothéses
adoptées par Halstead sont considérées comme
erronées (fenton et pflegger, 1997). En plus, la plupart des mesures
proposées par Halstead sont basées sur le code source d'un
logiciel ; les autres phases du cycle de développement telles que
la spécification et la conception ne sont pas prises en
considération bien qu'elles requièrent souvent un effort
considérable. [ALI]
4.1.2.2. Le modèle Putnam
En 1978, Putnam a proposé un modèle
d'estimation de l'effort de développement et de maintenance d'un
logiciel en se basant sur les remarques et sur les conclusions de Norden avait
déjà déduit en étudiant des projets de
développement dans beaucoup de domaine autres que le génie
logiciel (Putnam, 1978). En effet, Norden n'avait observé que la
distribution de l'effort total sur tout le cycle de la fonction de Rayleigh
(fig II.3).
Ainsi, Putnam avait utilisé cette fonction pour
exprimer la répartition de l'effort total de développement sur
tout le cycle de vie d'un logiciel (développement et maintenance).
Effort(t) = CT
(Equation 3)
Où Effort(t) représente l'effectif
cumulé à l'instant t, CT est l'effort total de tout le cycle de
vie du logiciel et td est le temps de développement.
Fig II.3- répartition de
l'effort selon la courbe de Rayleigh et la courbe classique. [ALI]
A partir des résultats obtenus ci-dessus et
d'observation des projets réels, Putnam établi une relation entre
la charge totale, le nombre d'instruction et la durée du
développement. L'effort à fournir est en relation inverse
à la puissance 4 du temps de développement. Ce qui signifie que
par exemple un raccourcissement du temps de développement de 10% suppose
une augmentation de la charge totale de 40%. Dans le modèle de Putnam,
l'augmentation de la durée diminue la charge tandis que son
raccourcissement l'accroît. [ALI]
4.1.3. Point de fonction
4.1.3.1. Présentation historique de la
fonction
Les points de fonction constituent la
métrique de pointe dans le monde du logiciel. Alors qu'originellement,
la méthode des points de fonctions est une méthode
destinée à évaluer la taille d'un projet logiciel, et ce,
indépendamment de la technologie utilisée pour le
réaliser.la puissance et l'utilité de cette méthode se
sont étendues à d'autres usages, loin de leur propos initial. En
ce début de 21e siècle, les points de fonction s'appliquent
maintenant aux domaines suivants :
· Etudes de données de référence.
· Estimation des coûts de développement.
· Gestion des litiges en contrats informatique.
· Gestion des litiges en taxation des logiciels.
· Estimation de coûts de maintenance.
· Contrats d'externalisation.
· Analyse des processus d'amélioration.
· Estimation de la qualité.
· Dimensionnement de tous les livrables (documentation,
code source, jeux d'essai).
· Coûts de mise en conformité an
2000.
En octobre 1979, Alan Albrecht, d'IBM, propose une
première version de sa méthode. Cette parution n'a pas
été sans réactions. C'était en effet la
première fois que l'on proposait une mesure de la production de
logicielle basée sur les fonctions utilisateurs. Elle doit aider
à prévoir la taille d'un projet, son effort de
développement et la productivité du développement
informatique.
Cette méthode à l'origine était
fondée sur quatre entités (entrée, sortie,
interrogation, fichiers) sans catégorie de complexité
avec un intervalle d'ajustement de +/- 25%. Depuis 1984, les comptages se font
a partir des entités entrées, sorties, interrogations,
données externes et internes, avec pour chacune de ces entités un
niveau de complexité simple, moyen ou élevé.
Les points de fonction se voulaient une méthode
pour mesurer un « problème » contrairement aux
nombre de ligne de code (LOC) qui mesuraient une
« solution ».
4.1.3.2. Paramètres de points de
fonction
Les points de fonctions reposaient, à l'origine,
sur un calcul basé sur quatre entités (entrée, sortie,
interrogation, fichiers), et ce, sans catégorisation de
complexité. (Albrecht, 1979) Depuis le milieu des années 80, avec
l'IFPUG13, et la normalisation AFNOR, le comptage des points de fonctions se
fait à partir des entités suivantes :
· Données internes (GDI)
Relatif à l'aspect statique du Système
d'Information.
Groupe de données logiquement liées, ou de
groupe de paramètres de contrôle, et
identifiables par l'utilisateur. Ces données sont mises
à jour et utilisés à l'intérieur de la
frontière de l'application.
Notons que certaines entités reliées par une
cardinalité (1,1) sont susceptibles de former un seul
et même GDI.
· Données externes (GDE)
Relatif à l'aspect statique du Système
d'Information.
Groupe de données logiquement liées, ou groupe
de paramètre de contrôle, et identifiables par
l'utilisateur. Ces données sont utilisées par l'application, mais
mises à jour par une autre application. Le GDE est un
GDI dans un autre domaine.
· Entrées (ENT)
Relatif à l'aspect dynamique du Système
d'Information.
Ce sont les données, ou les paramètres de
contrôle, qui entrent dans l'application considérée. Ces
entrées maintiennent un ou plusieurs GDI, initialisent ou
contrôlent un traitement, et font l'objet d'un traitement unique.
Une Entrée correspond donc à un écran de
saisie, ou à une réception de données. Il est à
noter qu'à chaque GDI doit correspondre au moins une entrée,
permettant sa mise à jour.
· Sorties (SOR)
Relatif à l'aspect dynamique du Système
d'Information.
Ce sont les données, ou les paramètres de
contrôle qui sortent de l'application. Ces sorties sont le
résultat d'un traitement unique. (Ce traitement unique doit être
différent d'une simple extraction de données). Ce peut être
un écran de visualisation, ou un message vers une autre application.
· Interrogations (INT)
Relatif à l'aspect dynamique du Système
d'Information.
Ce sont des données élémentaires qui
correspondent à une extraction de données.
L'INT ne met à jour aucun GDI.
Ces entités peuvent être définies sur
trois acteurs (fig II.4) :
Ø L'application.
Ø L'utilisateur.
Ø Les autres Applications. [GEO]
Fig II.4 - Principe des Points de
Fonctions.
4.1.4. Cocomo
4.1.4.1. Cocomo'81
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.
Il a été développé par Dr.
Barry Boehm en 1981 pour estimer le coût, en s'appuyant sur une
donnée de base : le nombre de ligne de code source
prévisible, exprimé en Kilo
Instruction Source
Livrées(KISL). A l'origine il a
été construit sur une étude de 63 projets logiciels de
2000 à 100.000 lignes de code dans l'entreprise TRW Inc.
Il permet de formuler des estimations de l'effort et du
temps de développement ainsi que ceux de maintenance d'un logiciel. En
plus, il fournit la répartition de cet effort sur les quatre phases du
cycle de développement (Analyse, Conception, Codage et Tests unitaires,
Intégration et Tests) et sur les huit activités de chaque phase
(Analyse de besoins, Conception, Programmation, Plan de test,
Vérification et Validation, Gestion du projet, Gestion des
configurations et Assurance qualité, Documentation).
Le modèle COCOMO'81 existe en trois
modèles: le modèle de base, le modèle Intermédiaire
et le modèle Détaillé.
· Modèle de Base
Le
modèle de base est assez simpliste. Il estime l'effort (le
nombre de mois-homme) en fonction du nombre de lignes de code, la
productivité (le nombre de lignes de code par personne par mois) et un
facteur d'échelle qui dépend du type de projet. Les 3 types de
projet identifiés sont :
Ø organique :
organisation simple et
petites équipes expérimentées. (ex: système de
notes dans une école)
Ø semi-détaché :
entre
organique et imbriqué. (ex: système bancaire interactif)
Ø imbriqué :
techniques
innovante, organisation complexe, couplage fort avec beaucoup d'interactions.
(ex : système de contrôle aérospatial.)
· Modèle Intermédiaire
Le
modèle intermédiaire introduit 15 facteurs de productivité
(appelés 'cost drivers'), représentants un avis subjectif et
expert du produit, du matériel, du personnel, et des attributs du
projet.
Chaque facteur prend une valeur nominative de 1, et peut varier
selon son importance dans le projet. Ils sont semblables aux points de fonction
utilisés par d'autres modèles. Les 15 facteurs sont
multipliés pour donner un facteur d'ajustement - qui vient modifier
l'estimation donnée par la formule de base.
· Modèle Expert
Le modèle
expert inclue toutes les caractéristiques du modèle
intermédiaire avec une estimation de l'impact de la conduite des
coûts sur chaque étape du cycle de développement:
définition initiale du produit, définition
détaillée, codage, intégration. De plus, le projet est
analysé en termes d'une hiérarchie : module, sous système
et système. Il permet une véritable gestion de projet, utile pour
de grands projets.
4.1.4.2. Cocomo II
Le modèle COCOMO II il 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 grand
diversité des projets, tant en ce qui concerne les coûts que les
durées de réalisation des logiciel.
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.
COCOMO II est constitué en fait de trois
modèles :
· Modèle de composition
d'application
Ce modèle est utilisé pour les projets
fabriqués à l'aide des toolkits d'outils graphiques. Il est
basé sur les nouveaux « Object Points ».
· Modèle avant
projet
Modèle utilisé pour obtenir une estimation
approximative avant de connaître l'architecture définitive. Il
utilise un sous ensemble de facteurs de productivité (Cost drivers). Il
est basé sur le nombre de lignes de code ou les points de fonction non
ajustés.
· Modèle post-architecture
Il
s'agit du modèle le plus détaillé de COCOMO II. A utiliser
après le développement de l'architecture générale
du projet. Il utilise des facteurs de productivité (Cost drivers) et des
formules.
4.1.5. Limitation des modèles
paramétriques
Les modèles paramétriques d'estimation des
coûts (linéaires ou analytiques) supposent la connaissance de la
forme de la relation exprimant l'effort en fonction des facteurs conducteurs du
coût. Autrement dit, la forme de l'équation centrale du
modèle est bien connue et il suffit donc de déterminer les
paramètres de cette équation en utilisant des techniques
statistiques ou des méthodes théoriques du domaine de
l'approximation des fonctions. En estimation des coûts de logiciels, on
détermine souvent la forme de l'équation centrale du
modèle en utilisant des connaissances relevant de l'environnement
étudié ou en adoptant des formes déjà
établies dans d'autres environnements.
Une autre limitation des modèles
paramétriques d'estimation des coûts est qu'ils requièrent
une adaptation ou une calibration quand on veut les appliquer dans des
environnements différents de ceux où ils ont été
développés. En effet, le modèle paramétrique
représente l'état de l'environnement étudié
à l'aide de la forme de son équation centrale ainsi que les
conducteurs du coût qu'il considère. Cependant, vu que les
environnements de développement et/ou de maintenance de logiciels n'ont
pas généralement les mêmes caractéristiques,
l'application d'un modèle, initialement mis au point dans un
environnement à un autre, n'est pas souhaitable. Des exemples de
caractéristiques qui peuvent différencier deux environnements de
développement de logiciels sont le type d'applications logicielles
développées (Scientifique, Gestion, Business, etc.), les
méthodes et les outils de développement utilisés, et les
contraintes imposées sur l'application (fiabilité,
portabilité, complexité, etc.).
Selon Gulizian, la calibration d'un modèle
paramétrique est sa reformulation sur une base de données de
projets logiciels d'un environnement autre que celui du modèle initial.
Ainsi, les équations du modèle calibré, y compris son
équation centrale, ont les mêmes structures que celles du
modèle initial mais pour lesquelles les coefficients sont
recalculés. L'adaptation d'un modèle paramétrique est la
modification des formes de certaines de ses équations ainsi que l'ajout
ou la suppression de facteurs affectant le coût dans le modèle.
Souvent en estimation des coûts, les chercheurs et les industriels
utilisaient ces deux techniques (calibration et adaptation) pour mettre au
point des modèles propres à leurs environnements à partir
de modèles déjà mis au point dans d'autres environnements.
Bien que la calibration (ou l'adaptation) représente, dans certains cas,
une solution au problème de l'utilisation d'un modèle
paramétrique ailleurs que dans son environnement, elle reste
insuffisante quand les différences entre les environnements sont
très flagrantes. [ALI]
4.2. Jugement de l'expert (méthode
Delphi)
Cette technique consiste à consulter un ou
plusieurs experts qui utilisent leurs expériences ainsi que leur
compréhension du projet afin de fournir une estimation à son
coût. Elle était parmi les premières techniques
utilisées en estimation des coûts. Il est préférable
d'avoir plusieurs valeurs estimées du coût émanant de
plusieurs experts pour alléger les problèmes de
subjectivité, de pessimisme et d'optimisme (Boehm,
1981). Il y a plusieurs façons de combiner les
différentes valeurs estimées du coût d'un projet logiciel.
La plus simple est d'utiliser une des méthodes statistiques telles que
la moyenne, la médiane ou le mode de toutes les valeurs pour
déterminer une estimation du coût. Cette approche présente
l'inconvénient d'être sujette aux préjugés des
estimations extrêmes. Une autre méthode
référée souvent dans la littérature par la
méthode Delphi, consiste à réitérer ce processus
d'estimation plusieurs fois jusqu'à ce qu'un consensus soit
établi. L'idée principale de la méthode Delphi est qu'un
coordinateur distribue une description du projet logiciel (souvent le
dossier d'analyse des besoins du logiciel) ainsi qu'un formulaire
d'estimation aux experts; ensuite, les experts remplissent les formulaires et
les renvoient au coordinateur. Ce dernier pourra, dépendamment de la
version de la méthode Delphi, convoquer une réunion des experts
pour discuter des différentes estimations. Ce processus est
réitéré jusqu'à l'adoption d'une estimation par
tout le groupe. [ALI]
4.3. Estimation par analogie
Dans cette technique d'estimation, l'évaluateur
compare le projet logiciel dont on veut estimer le coût avec des projets
logiciels déjà achevés. Il doit identifier les
similarités et les différences entre le nouveau projet et tous
les anciens projets. Pour cela, il doit auparavant décrire les projets
logiciels par un ensemble de caractéristiques. Les ressemblances entre
les caractéristiques du nouveau projet avec celles des projets
achevés déterminent les degrés de similarité entre
les projets. Ensuite, il utilise ces degrés de similarité pour
déterminer une estimation au coût du nouveau projet.
Dans sa première version informelle, l'estimation
par analogie a été considérée comme une alternative
de l'estimation par les jugements des experts. En effet, les experts raisonnent
souvent par analogie quand on leur demande une évaluation du coût
d'un logiciel à partir de son dossier d'analyse des besoins. Ainsi, les
experts utilisent leurs connaissances sur des projets déjà
achevés et déterminent implicitement les similarités et
les différences entre le nouveau projet et les projets achevés.
Cependant, plusieurs versions formelles de l'estimation par analogie ont
été récemment développées (Vicinanza
et Prietula, 1990; Malabocchia, 1995; Shepperd et Schofield, 1997).
Par ce fait, on la considère de plus en plus comme une technique
d'estimation qui se base sur la modélisation. D'ailleurs, le
modèle d'estimation des coûts, que nous développons dans
cette thèse, adopte une version floue de l'estimation par analogie. Le
quatrième chapitre décrira l'état de l'art des versions
formelles de l'estimation par analogie ainsi que notre nouvelle
modélisation de l'estimation par analogie. Notre modèle
d'estimation par analogie aura comme avantage la prise en considération
de la tolérance des imprécisions, la gestion des incertitudes et
l'apprentissage.
4.3.1. Processus d'estimation par
analogie
· Caractérisation des projets logiciels par un
ensemble de variables (complexité logicielle, compétence des
analystes, méthodes de développement utilisées, ...).
· Evaluation de la similarité entre le nouveau projet
et les projets logiciels historiques.
· Utilisation des valeurs des coûts réels des
projets similaires au nouveau projet pour en déduire une estimation
à son coût.
4.3.2. Limitation de l'estimation par
analogie
· Elle ne traite pas convenablement le cas des projets
logiciels décrits par des valeurs linguistiques telles que
« bas »,
« élevé », et
« complexe »
· Elle ne permet pas la gestion de l'incertitude au niveau
des estimations fournies
· Elle ne permet pas l'apprentissage
4.4. La méthode « prise to
Win » (gagner pour plaire)
Pour illustre cette méthode, nous allons
présenter deux exemples :
Exemple1 :
« Nous savons que ce travail est
estimé a deux millions et aucun de nos experts ne croient pouvoir le
faire avec moins d'un million et demi. Mais nous savons aussi que le client ne
dispose gue d'un budget d'un million. Maintenant, nous allons arranger
l'estimation du coût et la rendre crédible ».
Exemple2 :
« Nous devons absolument annoncer ce produit
à la conférence national sur le génie logiciel en juin
prochain, et nous sommes encire en Septembre. Cela signifie que nous disposons
de 9 mois pour réaliser le logiciel ».
Ces deux exemples illustrent très bien le nom de
la méthode (Price to Win, gagner pour plaire).cette
méthode a permis de conclure un grand nombre de contrats de logiciels
pour un grand nombre de compagnies. Ceci n'a pas empêché que
certains contrats ont du être réalisés pour
différentes raisons (budgétaires) alors que
d'autres contrats ont permis la réalisation de projets de très
mauvaises qualité.
Dans ce type de méthode, le résultat est
que l'argent et le temps diminuent avant que le travail ne soit fait : le
personnel devient furieux, un grand nombre de programmeurs travaillent de
longues heures essayant justes d'éviter un désastre complet.
Néanmoins, la principale raison qui fait cette
méthode continue a être utilisée est que la technologie de
l'estimation du coût du logiciel n'a pas donné des techniques
assez puissantes pour aider les clients ou les développeurs a
différencier avec conviction une estimation légitime d'une
estimation « Price to Win »
4.5. Estimation ascendante et
descendante
4.5.1. Estimation ascendante
Dans l'estimation ascendante, le projet logiciel
(ou le logiciel) est décomposé en plusieurs
tâches (ou composantes) constituant ainsi une
arborescence de toutes les tâches (ou composantes) du
projet logiciel (ou du logiciel).
Tout d'abord, on estime l'effort nécessaire pour
chaque tâche du plus bas niveau dans l'arborescence; ensuite, on
détermine progressivement l'effort des autres tâches, se
retrouvant dans un niveau supérieur dans l'arborescence, en combinant
les efforts nécessaires associés aux sous-tâches. En
général, l'effort nécessaire d'une tâche sera la
somme de ceux de ses sous-tâches. Cependant, dans le cas des projets
logiciels complexes, d'autres techniques plus sophistiquées, telles que
celles se basant sur des formules mathématiques typiques ou sur des
règles d'induction (si-alors), peuvent être
utilisées afin de mettre en valeur la complexité des interfaces
de communication entre les tâches.
4.5.2. Estimation descendant
Dans l'estimation descendante, on évalue une
estimation globale de l'effort de tout le projet logiciel; ensuite, on
répartit cet effort total sur toutes les tâches du projet
logiciel. Dans les deux cas de l'estimation ascendante ou descendante, les
valeurs estimées de l'effort sont déterminées en utilisant
la technique du jugement de l'expert, l'estimation par analogie ou un
modèle d'estimation.
4.6. Les modèles non paramétriques
d'estimation des coûts (non algorithmique)
Les modèles non-paramétriques d'estimation
des coûts ont été développés pour
remédier aux inconvénients cités ci-dessus dans les
modèles paramétriques. Ils n'ont pas une équation centrale
d'estimation de l'effort. Ainsi, les modèles non-paramétriques
n'exigent au préalable aucune forme à la relation exprimant
l'effort en fonction des conducteurs du coût. Ils modélisent cette
relation en utilisant des techniques d'intelligence artificielle telles que le
raisonnement à base de cas, les réseaux de neurones, les
algorithmes génétiques, les systèmes à base de
règles et les arbres de décision. Les modèles
non-paramétriques représentent donc une alternative prometteuse
quand la relation entre l'effort et les conducteurs du coût semble
n'avoir aucune forme prédéfinie.
Dans cette section, nous présentons les
modèles non-paramétriques utilisant les réseaux de
neurones, les arbres de décision et les algorithmes.
4.6.1. Les réseaux de neurones
La modélisation par les réseaux de
neurones est inspirée de la structure biologique du cerveau humain. Un
réseau de neurones est caractérisé par son architecture,
son algorithme d'apprentissage et ses fonctions d'activation. Dans la
littérature, plusieurs modèles de réseaux de neurones ont
été développés. Ils peuvent être
classifiés en deux catégories principales: les réseaux de
neurones « feedforward »
où il n'y a aucune boucle dans l'architecture du réseau, et
les réseaux récurrents où une ou plusieurs
boucles récursives apparaissent dans l'architecture du réseau. Le
Perceptron multicouches utilisant l'algorithme d'apprentissage de
rétro-propagation est souvent le plus adopté en estimation des
coûts de logiciels. Dans ce modèle, les neurones sont
organisés en couches et chaque couche ne peut avoir des connexions que
vers la couche suivante. La figure II.5 illustre un exemple
d'un tel réseau pour l'estimation de l'effort de développement de
logiciels. Le réseau produit un résultat
(effort) en propageant ses entrées initiales
(facteurs du coût ou attributs du projet logiciel)
à travers les différents neurones du réseau jusqu'à
la sortie. Chaque neurone d'une couche calcule sa sortie en appliquant sa
fonction d'activation à ses entrées. Souvent, la fonction
d'activation d'un neurone est la fonction Sigmoïde définie par:
f(x)= (Equation
4)
Fig II.5 -
Architecture d un réseau de neurones à trois couches pour
l'estimation de l'effort.
La configuration d'un réseau de neurones pour
l'estimation de l'effort de développement de logiciels nécessite
le choix d'une architecture adéquate, un algorithme d'apprentissage et
des fonctions d'activation. Dans le cas d'un Perceptron
multicouches, la configuration se restreint au choix des
différents paramètres de sa topologie tels que le nombre de
couches cachées, le nombre de neurones par couche, et les valeurs
initiales des poids de connexions (wij et
bj). Dans la pratique, ces paramètres sont
déterminés en se fiant sur une base de données de projets
logiciels déjà achevés. Ainsi, on divise la base de
données en deux ensembles: un ensemble de projets logiciels pour
entraîner le réseau et l'autre pour tester le réseau.
L'utilisation des réseaux de neurones pour estimer le
coût d'un logiciel a trois avantages principaux.
· Les réseaux neurones permettent l'apprentissage
automatique à partir des situations et des résultats
précédents. L'apprentissage est très important pour les
modèles d'estimation des coûts car l'industrie des logiciels est
en évolution croissante.
· Les réseaux neurones permettent un traitement
parallèle de l'information. Ainsi, le processus d'estimation du
modèle profitera de la grande puissance de calcul de toutes les machines
disponibles surtout que, souvent, le processus de formulation d'une estimation
engage des calculs très intensifs.
· Les réseaux neurones peuvent modéliser les
relations complexes existantes entre la variable dépendante (coût
ou effort) et les variables indépendantes du modèle (facteurs de
coût). En effet, les réseaux de neurones sont reconnus en tant
qu'approximateurs universels de fonctions continues à valeurs dans
l'ensemble des réels. Hornik,
Stinchcombe et White ont particulièrement montré
qu'un réseau de neurones
« feedforwad », avec une seule
couche cachée et des fonctions d'activation continues et
non-linéaires, peut approcher n'importe quelle fonction continue
à valeurs dans l'ensemble des réels et ceci au degré de
précision qu'on veut (Hornik, Stinchcombe et
White, 1989).
Cependant, L'approche neuronique a trois limitations qui
l'empêchent d'être acceptée comme une pratique usuelle en
estimation des coûts:
· L'approche neuronique est considérée comme
étant une approche boîte noire. Par conséquent, il
est difficile d'expliquer et d'interpréter son processus.
· Les réseaux de neurones ont été
utilisés spécifiquement pour les problèmes de
classification et de catégorisation, alors qu'en estimation des
coûts, nous traitons un problème de généralisation
et non pas de classification.
· Les réseaux neurones n'existe aucune
démarche standard pour le choix des différents paramètres
de la topologie d'un réseau de neurones (nombre de couches, nombre
d'unités de traitement par couche, valeurs initiales des poids de
connexions, etc.). [ALI]
4.6.2. Les arbres de régression
Les arbres de régression constituent un outil de
modélisation simple et de plus en plus répandu par la
diversité des applications qui lui font appel. Plusieurs approches de
construction de ces arbres ont été développées; ces
approches dépendent du type de la connaissance disponible du domaine
étudié selon qu'elle est discrète ou continue. Des
exemples de telles approches sont CART, ID3
et C4.5 .La construction de l'arbre de
régression s'effectue à partir d'un échantillon de
données historiques dit d'apprentissage.
Les arbres de régression, en particulier
binaires, ont été utilisés avec succès pour la mise
au point de plusieurs modèles d'estimation en génie
logiciel. En estimation des coûts, ils ont
été utilisés pour estimer l'effort de développement
d'un logiciel. Premièrement, chaque projet logiciel est décrit
par un ensemble de variables qui serviront à la prédiction de son
effort de développement. Ensuite et progressivement, à partir de
la racine de l'arbre, le projet logiciel auquel on veut estimer le coût
emprunte le chemin approprié, selon les valeurs de ses variables, en
descendant dans l'arborescence jusqu'à l'une des feuilles de l'arbre.
Chaque feuille contient une valeur numérique représentant
l'effort de développement des projets logiciels associés.
La figure II.6 illustre un arbre de
régression binaire construit à partir des projets du
COCOMO'81. Dans cet arbre de régression binaire, la
racine représente la variable AKDSI de chaque projet
logiciel; si la valeur de l'AKDSI du projet logiciel est supérieure
à 315,5, alors son effort est estimé à
9000H-M; sinon, on passe au deuxième niveau de l'arbre
où il y a un seul noeud représentant aussi la variable
AKDSI et ainsi de suite jusqu'à l'une des feuilles de
l'arbre.
Fig II.6- Arbre de
régression construit à partir des 63 projets logiciels du
COCOMO'81.
En général, la plupart des algorithmes de
construction d'un arbre de régression binaire, à partir d'un
ensemble de projets logiciels historiques, sont basés sur une
stratégie descendante. Cette stratégie consiste à choisir,
parmi tous les attributs décrivant le projet logiciel, celui qui divise
mieux l'ensemble de tous les projets
logiciels en deux sous-ensembles disjoints. Souvent, on choisit l'attribut qui
minimise l'erreur moyenne quadratique (MSE) de la variable
dépendante (l'effort de développement) des
projets logiciels historiques. L'erreur moyenne quadratique d'un sous-ensemble
S de projets logiciels est calculée par:
MSE(S) = (Equation 5)
Où Effort k est
l'effort réel du k ème projet logiciel de
S et Effort est la moyenne
arithmétique d'Effort k.
· L'attribut est mesuré par des valeurs
discrètes. Dans ce cas, pour chaque attribut Vi, on
divise l'ensemble de tous les projets logiciels T en des
sous-ensembles Tij contenant des projets logiciels ayant la
même valeur Aj de l'attribut Vi.
· L'attribut est mesuré par des valeurs
numériques continues. Dans ce cas, pour chaque attribut
Vi, on divise l'ensemble de tous les projets logiciels en
k-1 sous ensemble selon l'ordre des valeurs observées
de Vi (où k est le nombre de valeurs
observées de Vi).
Ainsi, on choisit l'attribut Ai qui maximise la
différence :
MSE = MSE(T) - (Equation 6)
L'expansion d'un noeud de l'arbre s'arrête quand le
nombre de projets logiciels classifiés dans ce noeud est assez petit ou
ces projets logiciels sont jugés similaires. Dans ce cas, le noeud
représente une feuille de l'arbre et l'effort estimé de tout
nouveau projet logiciel, qui sera classifié dans ce noeud, est
calculé en fonction des valeurs réelles des efforts de tous les
projets logiciels historiques de ce noeud (en général, on
considère la moyenne ou la médiane).
La modélisation de l'estimation des coûts
par les arbres de régression présente l'avantage d'être
facile à expliquer et à utiliser contrairement au cas de celle
utilisant les réseaux de neurones. En effet, un chemin dans l'arbre de
régression peut être représenté par une règle
du type:
Si condition1
et condition2 et ... et conditionN Alors
Effort=CTS
Par exemple, dans la figure II.5, le chemin
indiqué par des flèches peut être représenté
par la règle suivante:
Si (AKDSI =111.0) et (TIME= 1.415) et (TKDSI=26.0)
Alors Effort = 57.3H-H
Ce genre de règles est facilement
interprétable car les règles ressemblent à celles qu'on
Utilise dans notre quotidien. Ainsi, une modélisation par un arbre de
régression binaire n'est qu'un cas particulier d'un système
à base de règles Si-Alors.
4.6.3. Les algorithmes
génétiques
Les algorithmes génétiques sont
inspirés des concepts de l'évolution et de la sélection
naturelle élaborés par Charles Darwin. Ils ont
été utilisés comme des méthodes heuristiques dans
les problèmes d'optimisation où l'espace de recherche de la
solution est de taille assez grande. Le pionnier du domaine est John
Holland qui a le premier tenté d'implanter artificiellement des
systèmes évolutifs (Holland, 1975).
L'idée de base de la théorie Darwinienne de l'évolution
postule que seulement les meilleurs éléments d'une population
survivent et transmettent à leurs descendants leurs
caractéristiques biologiques à travers des opérations
génétiques telles que le croisement, la mutation
et la sélection. Dans l'implantation informatique du
principe de l'évolution, le problème étudié est
représenté par une chaîne binaire (formée de 0 et 1)
symbolisant les chromosomes de son équivalent biologique. Ainsi,
à partir d'une population, c'est-à-dire à partir d'un
ensemble de chaînes binaires (chromosomes).
· les chromosomes les mieux adaptés se
reproduisent le plus souvent et
Contribuent davantage aux populations futures
(sélection),
· lors de la reproduction, les chromosomes des parents
sont combinés et mélangés pour reproduire les chromosomes
des enfants (croisement),
· le résultat du croisement peut être
à son tour modifié par des perturbations aléatoires
(mutation) ;
En général, un algorithme
génétique est composé de trois étapes principales
bien que d'autres variations sont possibles (Goldberg, 1989; Davis, 1991):
1- Générer aléatoirement une population
initiale de N chromosomes (solutions);
2- répéter les sous étapes suivantes
jusqu'à une condition d'arrêt (souvent on
fixe un temps d'exécution ou un nombre d'itérations)
2.1- évaluer la fitness de chaque
chromosome de la population et sélectionner
Ceux ayant les meilleurs scores;
2.2- reproduire une nouvelle population de chromosomes en
appliquant les deux opérations génétiques (croisement et
mutation) aux chromosomes sélectionnés dans 2.1;
2.3- Remplacer l'ancienne population par la nouvelle
population obtenue de 2.1 et 2.2 ;
3- Choisir comme solution au problème qui a le
meilleur score dans la population finale.
Récemment, les algorithmes
génétiques ont été appliqués en estimation
des coûts de développement de logiciels. Shukla a utilisé
les algorithmes génétiques dans l'apprentissage d'un Perceptron
multicouches afin de trouver le vecteur des poids W qui permette au Perceptron
multicouches de fournir des estimations acceptables. Ses
expérimentations se sont basées sur la base de données du
COCOMO'81. Il identifie un Perceptron multicouches PN par un vecteur de poids
W(PN). À chaque vecteur de poids W(PN), il associe un chromosome de M
éléments où M est le nombre d'éléments de
W(PM). La figure II.7 illustre un exemple d'un Perceptron
multicouches ainsi que le chromosome qui lui est associé; ce Perceptron
comporte 18 poids de connexions auxquels il associe un chromosome de 18
éléments. Chaque élément du chromosome
représente un poids du vecteur W(PN). Pour coder un poids, il lui
réserve dix bits. Ainsi, le chromosome associé sera
composé de 180 bits. La fonction de fitness utilisée
pour sélectionner les chromosomes dans une population est:
F (W) = E (W) =
(Equation7)
Shukla utilise une technique hybride de sélection
des chromosomes qui vont survivre dans la prochaine population. Cette technique
considère les deux premiers chromosomes ayant les meilleurs scores F(W)
et applique sur les autres la stratégie de la roue roulante dans
laquelle chaque chromosome reçoit une part de la roue proportionnelle
à son score F(W). Pour l'opérateur de croisement, Shukla a
utilisé une version modifiée de l'opérateur standard afin
d'éviter que des bits, représentant des poids appartenant
à différentes couches du Perceptron, soient interchangés.
Les autres paramètres de l'algorithme, tels que la taille de la
population, la probabilité accordée à l'opérateur
de croisement ainsi que celle accordée à l'opérateur de
mutation, ont été choisis en exécutant plusieurs fois
l'algorithme sur les données du COCOMO'81.
Fig II.7 - Exemple d'un Perceptron multicouches et sa
représentation avec un chromosome.
Dolado, Burgess et
Lefley ont respectivement utilisé la programmation
génétique (Genetic Programing) pour le
développement de modèles d'estimation des coûts de
logiciels. La programmation génétique (GP) est une variante
des algorithmes génétiques qui n'exige pas que la
représentation des chromosomes soit seulement sous forme de
chaînes binaires, mais elle peut être sous d'autres formes telles
que des équations, des programmes, des circuits, et des plans.
Dans ces deux expérimentations de la programmation
génétique en estimation des coûts, l'équation,
exprimant l'effort en fonction des variables affectant le coût, a
été représentée par un arbre binaire dont
les noeuds sont soit des opérandes ou soit des opérateurs. Les
opérandes sont les conducteurs du coût tels que la
complexité et la fonctionnalité du logiciel, et la
compétence du personnel. Ils sont généralement
dans les feuilles de l'arbre binaire. Les opérateurs, quant
à eux, représentent les différentes opérations
susceptibles d'être dans l'équation exprimant
L'effort en fonction des conducteurs du
coût. Des exemples de ces opérateurs sont +, -,
*, /, Racine carrée, Logarithme, et l'Exponentiel. La
figure II.8 illustre la représentation de
l'équation Effort=0,03453*FP/Ln(FP)
par un arbre binaire:
Fig II.8 -
Représentation de l'équation Effort=0,03453*FP/Ln(FP)
par un arbre binaire. [ALI]
Les deux variantes de la programmation
génétique utilisées respectivement par Dolado, Burgess et
Lefley sont presque les mêmes avec des différences mineures au
niveau des choix de certains paramètres tels que la fonction
d'évaluation de la fitness de chaque arbre binaire, la taille
de chaque population, et la technique de sélection des arbres binaires.
Voici brièvement la description du programme génétique
utilisé par Dolado, Burgess et Lefley :
1- Générer aléatoirement une population de P
équations, c'est-à-dire P arbres binaires. Dolado a
utilisé les opérateurs suivants: +, -, *, /, Racine
carrée, Carrée, Logarithme, Exponentiel. Burgess et Lefley ont
utilisé les opérateurs suivants: +, -, *. Ils ont aussi
limité la taille de chaque population à 1 000, la profondeur de
chaque arbre binaire à quatre, et le nombre maximal des noeuds dans un
arbre à 64.
2- Répéter jusqu'à un nombre maximal de
génération ;
2.1- Évaluer la fitness de
chaque équation:
· Dolado utilise la fonction MSE (Mean Square
Error):
MSE =
(Equation8)
où N est le nombre de projets logiciels,
Effortréel,i est l'effort réel du ième
projet, et Effortestimé,i est l'effort estimé
du ième projet par l'équation.
· Burgess et Lefely ont utilisé la moyenne des
erreurs relatives (MMRE):
MMRS =
(Equation9)
2.2- sélectionner les équations ayant les meilleurs
scores de la fonction de fitness:
· Dolado utilise la technique de la roue roulante
(Roulette Wheel) en affectant à chaque équation, i, une
probabilité égale à fi fi où fi
est la fitness de l'ième équation.
· Burgess et Lefley choisissent les cinq premières
équations ayant les meilleurs scores.
2.3- Appliquer les deux opérateurs de croisement et de
mutation aux équations sélectionnées. Le croisement de
deux équations consiste au choix d'un noeud N1 dans l'arbre
représentant la première équation, d'un noeud N2 dans
l'arbre représentant la deuxième équation, et
échanger les deux sous-arbres de racine respectivement N1 et N2. La
figure II.9 illustre un exemple de l'opération de
croisement appliquée sur les deux équations:
Effort=0,03453*FP/Ln(FP) et Effort= 4.3
+2.1*FP+1.01*FP2. Certaines précautions sont
nécessaires pour éviter les problèmes
d'incompatibilité des opérateurs avec des opérandes
(valeur négative avec la fonction Logarithme par exemple).
L'opérateur de mutation est appliqué sur chaque équation
sélectionnée en choisissant aléatoirement un noeud de
l'arbre binaire (opérateur ou opérande) et en le remplacant par
un autre élément (opérateur ou opérande) ;
2.4- construire la nouvelle population ;
3- choisir l'équation ayant le meilleur score de
fitness.
Fig II.9 -
Résultats de l'application de l'opérateur de croisement aux deux
équations:
Effort=0,03453*FP/Ln(FP) et Effort= 4.3
+2.1*FP+1.01*FP2.
L'utilisation du principe de l'évolution en
estimation des coûts présente l'avantage de fournir une recherche
heuristique de l'équation exprimant l'effort en fonction des conducteurs
du coût. Ainsi, à partir d'un ensemble d'équations
initiales, l'algorithme recherche celle qui représente
adéquatement la relation. Ceci présente un avantage sur les
techniques paramétriques classiques telles que la régression
linéaire où une seule forme de l'équation est
évaluée. Cependant, comme dans le cas des réseaux de
neurones, la configuration d'un algorithme génétique (ou
un programme génétique) nécessite le choix de
plusieurs paramètres tels que la fonction de fitness, la taille
de chaque population et la taille de l'arbre binaire représentant
l'équation. Ces paramètres sont souvent déterminés
par expérimentations. Ils dépendent donc de la base de projets
logiciels utilisée.
Les modèles non algorithmiques sont basés sur
des approches de l'intelligence artificielles telles que les réseaux de
neurones, le raisonnement par analogie et les arbres de régression. Les
avantages et les inconvénients de ces modèles sont :
[IDR]
· Avantages
Ils peuvent modéliser des relations complexes entre les
différents facteurs affectant le coût.
Dans le cas des réseaux de neurones, ils incluent
automatiquement des algorithmes d'apprentissages.
Leur comportement est facilement compréhensible sauf pour
le cas des réseaux de neurones.
· Inconvénients
Ils ne sont pas faciles à développer.
On ne peut pas les utiliser sont les programmer.
Ils impliquent des calculs très intensifs pour
générer l'estimation.
5. RESUME SUR LES METHODES D'ESTIMATION
Un certain nombre de méthodes d'estimation ont
été développés. Dans la figure
II.10 nous allons présenter les principales méthodes
utilisées pour l'estimation des coûts de développement de
logiciels.
Suite a notre recherche, nous avons distingué Sept
méthodes : modèles paramétrique, jugement de
l'expert, l'estimation par analogie, Price to Win, méthode descendante
et modèles non paramétrique.
Les modèles paramétriques fournissent plusieurs
algorithmes produisant une estimation du coût, les formes les plus
communes des algorithmes sont (les modèles linéaires, les
modèles analytiques, pionts de fonction et cocomo)
Les modèles non paramétriques sont
représentés par (les réseaux de neurones, les arbres de
régression et les algorithmes génétiques).
Fig II.10 - méthodes
d'estimation de coûts de développement de logiciel
6. CONCLUSION
L'estimation des coûts de
développement de logiciels est l'un des problèmes critiques les
plus débattus en métrologie de logiciels. La maîtrise et
l'évaluation de ces coûts semblent encore préoccuper aussi
bien les chercheurs que les responsables et les chefs de projets logiciels.
Dans ce chapitre, nous avons présenté un ensemble de techniques
d'estimation des coûts, spécifiquement celles se basant sur la
modélisation. Ainsi, nous avons décrit des exemples de
modèles paramétriques et non-paramétriques. Chaque type de
modèle d'estimation a des avantages et des inconvénients et aucun
modèle n'a pu prouver qu'il performe mieux que tous les autres dans
toutes les situations.
| 
