Memoire Online - Un atelier de genie logiciel dedié a l'estimation du cout logiciel

Dans ce premier chapitre nous donnerons les différentes définitions du terme « Génie Logiciel ». Ensuite, nous présenterons le cycle de vie d'un logiciel dans ses différentes phases et ses différents modèles en se focalisant tout particulièrement sur l'estimation du coût d'un projet informatique.

L'appellation génie logiciel concerne l'ingénierie appliquée au logiciel informatique. [LAN 88] Ce terme a été introduit à la fin des années soixante pour répondre à la crise de l'industrie du logiciel. Cette crise est apparue lorsqu' on a prit conscience que la qualité des systèmes produits ne correspond pas a l'attente des clients.

Depuis, le génie logiciel constitue un véritable enjeu stratégique pour le développement des applications informatiques, en particulier les évolutions stratégiques des ateliers de génie logiciel qui concernent :

· Les outils de développement (conception, production, fiabilité, maintenance) ;

· Les outils de modélisation, de conception et d'évolution des architectures. [ALP 95]

Ces outils portent sur une partie ou sur l'ensemble du cycle de vie du logiciel.

Le génie logiciel est le domaine dédié à l'étude, la conception et la réalisation de programmes informatiques. Ce terme a été défini à l'origine par un groupe de travail en 1968, à Garmisch-Partenkirchen, sous le parrainage de l'OTAN.

Actuellement, le Génie Logiciel(en anglais software engineering), peut se définir comme un ensemble composé de méthodes, de modèles, d'outils d'aide au développement et de critères d'évaluation de la qualité permettant à un maître d'oeuvre de produire un logiciel répondant aux besoins exprimés par un maître d'ouvrage.

Le Génie Logiciel est donc l'art de spécifier, de concevoir, de réaliser, et de faire évoluer, avec des moyens et dans des délais raisonnables, des programmes, des documentations et des procédures de qualité en vu d'utiliser un système informatique pour résoudre certains problèmes.

Une définition plus précise décrit le Génie Logiciel comme l'ensemble des activités de conception et de mise en oeuvre des produits et des procédures tendant à rationaliser la production du logiciel et son suivi.

Autrement dit, le Génie Logiciel est « l'art »de produire de bons logiciels, au meilleur rapport qualité/prix. Il utilise pour cela des principes d'ingénierie et comprend des aspects à la fois techniques et non techniques: le génie logiciel est basé sur des méthodologies et des outils qui permettent de formaliser et même d'automatiser partiellement la production de logiciels, mais il est également basé sur des concepts plus informels, et demande des capacités de communication, d'interprétation et d'anticipation.

L'utilisation du génie logiciel dans la production d'un logiciel qui accompli les besoins attendu en même temps qu'il satisfait les objectifs d'un processus d'ingénierie est implantée avec un processus par étapes. Ces différentes étapes forment le cycle de vie d'un logiciel.

Le Génie logiciel se préoccupe des procédés de fabrication des logiciels en s'assurant que les 4 critères suivants soient satisfaits [INT 1] :

· Le système qui est fabriqué répond aux besoins des utilisateurs (contraintes Fonctionnelles),

· La qualité correspond à celle consignée dans le contrat de service initial,

Il faut un temps considérable pour développer un grand système logiciel qui, d'ailleurs, sera utilisé pendant très longtemps .en identifie donc un certain nombre d'étapes distinctes dans cette périodes de développement et d'utilisation, ces étape constituent le cycle de vie du logiciel [LAN 88], de sa conception à sa disparition.

L'objectif d'un tel découpage est de permettre de définir des jalons intermédiaires permettant la validation du développement logiciel, c'est-à-dire la conformité du logiciel avec les besoins exprimés, et la vérification du processus de développement, c'est-à-dire l'adéquation des méthodes mises en oeuvre. [INT 3]

L'étude préalable consiste à élaborer une version de base du cahier des charges, qui doit inclure

· la décision de faisabilité,

· le plan général du projet,

· une estimation approchée du coût et des délais de réalisation.

· Les concepteurs doivent effectuer une enquête précise au niveau des demandeurs de l'application (les clients), et des utilisateurs (souvent le personnel des clients),

· et une étude précise du système d'information les concernant.

c'est-à-dire consiste à définir les services qui seront rendus à l'utilisateur et les contraintes sous lesquelles ce logiciel devra fonctionner. [INT3]

3.1.2. La spécification

La spécification a pour but d'établir une première description du futur système. Cette activité utilise les résultats de l'analyse des besoins, les considérations techniques et la faisabilité informatique pour produire une description de ce que doit faire le système mais sans préciser comment il le fait (on précise le quoi mais pas le comment). [INT3]

3.1.3. La conception

la phase de conception (design phase), généralement décomposée en deux phases successives dont la première est appelée conception générale, conception globale, conception préliminaire ou conception architecturale, et la deuxième conception détaillée. A partir du document de spécification, la phase de conception doit fournir une réponse à la question: «Comment réaliser le logiciel ? ». [INT3]

3.1.3.1. La conception générale

La conception générale consiste en une description de l'architecture du logiciel, c'est à dire obtenir à la fois :

· une décomposition du système d'information en un ensemble de modules et de structures de données,

· et une description du rôle de chaque module individuellement, et en interaction avec les autres. [INT4]

3.1.3.2. La conception détaillée

La conception détaillée consiste à obtenir une description détaillée des traitements et des structures de données (requêtes et tables dans un modèle S.G.B.D ou algorithme et lexique dans un modèle fichiers).

On utilise pour cela des langages intermédiaires entre le langage naturel (homme), et les langages de programmation (ordinateur) par exemple l'algèbre relationnel (S.G.B.D.) ou le « Pseudo code » (programmation classique). [INT4]

3.1.4. La codification

La codification permet de réaliser, à partir de la conception détaillée, d'un ensemble de programme ou de composants de programmes. [INT3]

3.1.5. Les tests unitaires

Les tests unitaires consistent à vérifier le bon fonctionnement du programme et des différents modules le composant (individuel et interactif) par l'intermédiaire de jeux d'essai judicieusement choisis au sein du domaine d'application de ce programme. [INT4]

3.1.6. Les tests systèmes

Les tests systèmes correspondent :

· A la phase d'intégration des divers programmes pour obtenir le logiciel fini,

· Ainsi qu'à l'ensemble des testes qui permettra de vérifier que le logiciel correspond exactement au cahier des charges,

· Et enfin à la rédaction de la documentation utilisateur. [INT4]

3.1.7. L'exploitation [INT4]

L'exploitation consiste à la mise à disposition de l'ensemble des utilisateurs du logiciel fini, de telles façons à ce que ce logiciel soit opérationnel en situation réelle de production.

3.1.8. La maintenance

La maintenance prend trois formes :

· La maintenance corrective permet de corriger les erreurs qui n'ont pas été détectées lors des précédentes phases de tests.

· La maintenance adaptative doit s'occuper de faire évoluer et d'adapter le logiciel à l'apparition de nouvelles contraintes.

· La maintenance perfective a pour objectif l'optimisation des performances du logiciel.

3.2. Modèles cycle de vie

3.2.1. Modèle en cascade

Dans ce modèle le principe est très simple : chaque phase se termine à une date précise par la production de certains documents ou logiciels. Les résultats sont définis sur la base des interactions entre étapes et activités, ils sont soumis à une revue approfondie, on ne passe à la phase suivante que s'ils sont jugés satisfaisants.

Certaines phases portent le nom d'une activité ce qui signifie que l'activité est essentielle pour cette phase, mais n'impose pas qu'elle n'ait lieu que dans cette étape. D'autres activités interviennent, par exemple le contrôle technique et la gestion de la configuration sont présents tout au long du processus.

Le modèle original ne comportait pas de possibilité de retour en arrière. Celle-ci a été rajoutée ultérieurement sur la base qu'une étape ne remet en cause que l'étape précédente, ce qui, dans la pratique, s'avère insuffisant.

Fig I.1 -le cycle de vie en cascade.

3.2.2. Modèle en V

Le principe de ce modèle est qu'avec toute décomposition doit être décrite la recomposition, et que toute description d'un composant est accompagnée de tests qui permettront de s'assurer qu'il correspond à sa description.

Ceci rend explicite la préparation des dernières phases (validation - vérification) par les premières (construction du logiciel), et permet ainsi d'éviter un écueil bien connu de la spécification du logiciel : énoncer une propriété qu'il est impossible de vérifier objectivement après la réalisation.

Fig I.2 - le cycle de vie en V.

3.2.3. Modèle par incrément

Dans les modèles par incrément un seul ensemble de composants est développé à la fois : des incréments viennent s'intégrer à un noyau de logiciel développé au préalable. Chaque incrément est développé selon l'un des modèles précédents.

Avantage :

· chaque développement est moins complexe ;

· les intégrations sont progressives ;

· possibilité de livraisons et de mises en service après chaque incrément ;

· meilleur lissage du temps et de l'effort de développement à cause de la possibilité de recouvrement des différentes phases.

Risque :

· mettre en cause le noyau ou les incréments précédents ;

· ne pas pouvoir intégrer de nouveaux incréments.

FigI.3 - le cycle de vie par incrément

3.2.4. Le prototypage

Ce modèle consiste à produire une version d'essai du logiciel un prototype utilisée pour tester les différents concepts et exigences. Il sert à montrer au client les fonctionnements que l'on se propose de mettre en oeuvre. Après que le client a donné son accord, le développement du logiciel suit généralement les phases du modèle en cascade. Les efforts consacrés à la réalisation du prototype sont le plut souvent compensés par ceux gagnés à ne pas développer de fonctions inutiles.

Caractéristiques :

· Un degré élevé de participation du client.

· Une représentation tangible des exigences du client.

· Très utile quand les exigences sont instables ou incertaines.

Avantages participation du client :

· Le client participe activement dans le développement du produit.

· Le client reçoit des résultats tangibles rapidement.

· Le produit résultant est plus facile à utiliser et à apprendre.

Applicabilité :

· Pour des systèmes interactifs de petite et moyenne taille.

· Pour des parties de grands systèmes (par exemple l'interface utilisateur).

· Pour des systèmes avec une vie courte.

Fig I.4 -Modèle de prototypage

3.2.5. Le modèle en spirale

Proposé par B. Boehm en 1988, ce modèle est beaucoup plus général que le précédent. Il met l'accent sur l'activité d'analyse des risques : chaque cycle de la spirale se déroule en quatre phases:

1-) détermination, à partir des résultats des cycles précédents, ou de l'analyse préliminaire des besoins, des objectifs du cycle, des alternatives pour les atteindre et des contraintes ;

2-) analyse des risques, évaluation des alternatives et, éventuellement maquettage;

3-) développement et vérification de la solution retenue, un modèle « classique» (cascade ou en V) peut être utilisé ici ;

4-) revue des résultats et vérification du cycle suivant.

Avantage

· Un modèle simple est facile à suivre.

Risque :

· Impossibilité de suivre et assurer le bon déroulement du projet ;

· Augmentation du risque cas validation tendit ;

· Modèle difficile à utiliser quand il difficile d'obtenir un énoncé complet de besoins.

Fig I.5 - le cycle de vie en spirale

Alors que le matériel informatique a fait, et continue de faire, des progrès très rapides,

Le logiciel, l'autre ingrédient de l'informatique, traverse une véritable crise. Etant donné que cette crise a été décelée en 1969 déjà et qu'elle dure toujours, il serait plus approprié de parler d'une maladie chronique.

La crise du logiciel (software crisis) peut tout d'abord se percevoir à travers ses symptômes:

· les logiciels réalisés ne correspondent souvent pas aux besoins des utilisateurs;

· les logiciels contiennent trop d'erreurs (qualité du logiciel insuffisante);

· les coûts du développement sont rarement prévisibles et sont généralement prohibitifs;

La crise du logiciel a ensuite des conséquences économiques: aujourd'hui le coût du logiciel est supérieur à celui du matériel. Même si des chiffres précis font défaut, les experts sont unanimes quant à la tendance: partant d'une proportion 50%-50% en 1965, et passant par 70%-30% en 1975, ce rapport avait atteint 80%-20% en 1985. Mais pas seulement en proportion, en valeur également, le coût du logiciel croît à une vitesse vertigineuse. On peut montrer que cette inflation des coûts est surtout due aux frais de maintenance, situés actuellement entre 40% et 75% du coût total d'un système informatique (matériel et logiciel). Or ces frais de maintenance résultent avant tout de la qualité déficiente du logiciel, au moment de sa livraison déjà ou après qu'il ait évolué.

La raison de fond de la crise du logiciel réside dans le fait qu'il est beaucoup plus difficile de créer des logiciels que le suggère notre intuition. Comme les solutions informatiques sont essentiellement constituées de composants immatériels, tels des programmes, des données à traiter, des procédures et de la documentation, on sous-estime facilement leur complexité. Déjà la taille des programmes montre que cette complexité est souvent bien réelle: un million de lignes pour un logiciel de commande et de navigation d'un avion moderne, le décuple pour une station orbitale [INT 2].

Ensemble cohérent d'outils informatiques formant un environnement d'aide à la conception, au développement et à la mise au point de logiciels d'application spécialisés. On retrouvera par exemple dans un AGL des dictionnaires de données, des outils permettant de réaliser des diagrammes, pour faciliter la phase d'analyse et de conception des applications. Puis des générateurs de code ainsi que des aides à la mise au point (encore appelés débogueurs) viendront accélérer la production et la finalisation de l'application.

Il n'est pas rare pour un projet logiciel de dépasser le délai estimer de 25 à 100%, c'est même à partir de ces constatations que la crise du logiciel est apparue...Aujourd'hui si quelques projets ont encore des dérapages parfois catastrophiques, certains ne dépassent les prévisions que de 5 à 10% seulement.

Il est indispensable pour le client comme pour le fournisseur (chef de projet et management) d'estimer à l'avance la durée (calendrier) et le coût (effort) d'un projet logiciel. Il convient également d'en mesurer les risque en recensant les dépendances extérieures qui influeront sur les coûts et délais .une remarque préalable s'impose quant au processus d'estimation beaucoup trop souvent, le management et les client ont de la peine à comprendre que l'estimation est une activité comportant des difficultés intrinsèques et la rendent encore plus difficile par ce manque de compréhension .le processus requiert des raffinement successifs, il est impossible de fournir une estimation correcte jusqu' a ce que le logiciel soit appréhendé dans son intégralité.

Les estimations interviennent dans au moins quatre phase du cycle de vie du projet :

Ø Décrit de façon macrocosmique les fonctions nécessaires a la application ;

A la fin de cette étape, il est possible d'estimer de manière globale le coût de l'outille souhaité. La comparaison entre les gains espérés et le coût du projet rendra possible le calcul du retour sur investissement du projet.

Les décideurs possèdent, de cette étapes, les données suffisantes pour continuer(ou non)de développer le projet.

Le projet prend forme. Les fonctions qu'il regroupe sont décrites avec précision.

Cette étude reste fonctionnelle. On ne parle pas encore technique, même si l'on les écrans ou les traitements qui seront produites (les maquettes des écrans sont souvent créées durant cette phase).

Dans la majorité des cas, le délai d'un projet s'étend sur plus d'une année. Les directions financières se doivent de répartir dans le temps, le coût des étapes du projet.

Par exemple, les études seront menées sur le budget de l'année en cours, la réalisation sur l'année suivante, voire sur les deux années suivantes pour les projets importants.

La maitrise d'oeuvre l'application .À chaque fonctionnalité correspond au moins un objet informatique.

L'estimation est maintenant très proche de la réalité ; elle est plus précise. Les métriques utilisées sont différentes, plus précises elles aussi.

Le découpage en fonctions/taches, qui correspond à la réalité du projet, facilite la lourde mission de planification. L'approche de l'estimation correspond à la logique de la plupart des outils de planification. Les taches élémentaires, ainsi que leur charge, sont connus et facilement intégrées dans les plannings.

Il est question a cette étape, de planifier la réalisation du projet, de maitriser les éventuelles dérives, et de construire une application maitrisée.

La mise à jour des estimations et la saisie des consommés(ou leur intégration automatique), présente trois avantages :

Ø Connaitre en permanence la charge estimée, réactualisée du projet, s'appuyant sur des données statistique issues de l'ensemble des projets terminés (base de référence) ;

Ø Maitriser la dérive éventuelle du projet en comparant le réalisé et l'estimé. La comparaison peut amener à réviser les métriques ou à reconsidérer la complexité des taches sujettes à dérive.

	6.2. L'objectif de l'estimation de coût d'un logiciel · sensibiliser à l'existence de méthodes pour l'estimation de l'effort de développement d'un projet · donner les bases rudimentaires pour estimer l'effort d'un nouveau projet ou l'effort de maintenance d'un projet · donner les éléments qui permettent de nuancer l'effort calculé d'un projet (cohésion de l'équipe, maturité des processus,..) · proposer aux personnes (chefs de projets et/ou analystes) des outils utiles à la négociation de contrats avec leur(s) client(s) · proposer aux personnes (chefs de projets et/ou analystes) un modèle de coût permettant de décider de la stratégie de développement (coding ou reuse de certains composants) 6.3. Les étapes d'estimation d'un projet L'estimation d'un projet informatique comprend quatre étapes : · Estimer la taille du produit à développer. Celle-ci se mesure généralement en nombre d'instructions (lignes de code) ou en points de fonction, mais il existe d'autres unités de mesure possibles. · Estimer la charge en mois hommes ou en jours hommes. · Construire le calendrier du planning. · Estimer le coût du projet en monnaie locale. 6.4. Les difficultés de l'estimation L'estimation des charges des projets informatiques est absolument nécessaire ; mais c'est aussi l'une des activités les plus difficiles du développement de logiciels. Pourquoi est-ce si ardu ? La liste suivante indique quelques-unes de ces difficultés que nous devons surmonter. · L'estimation de la taille est, intellectuellement, l'étape la plus difficile (mais non impossible) ; elle est souvent esquivée en passant directement à l'estimation des délais. Cependant, si vous ne vous interrogez pas sur l'objectif que l'on vous demande d'atteindre, vous n'aurez aucune base suffisante pour prévoir un délai ou évaluer les conséquences d'un changement de périmètre. · Souvent, les clients et les techniciens de logiciels, ne comprennent pas que le développement de logiciels est un processus de raffinement progressif et que les estimations faites en a mon du projet sont floues. Les bonnes estimations, elles-mêmes, ne sont que des paris, avec des hypothèses sur les risques inhérents ; cependant, on a quelquefois tendance à les considérer comme gravées dans le marbre ! Il est pertinent de présenter les estimations comme une plage de valeurs possibles, en exprimant, par exemple, que le projet prendra de 5 à 7 mois, au lieu d'affirmer qu'il sera achevé le 15 juin. Méfiez-vous d'une plage trop étroite qui reviendrait à donner une date précise ! Vous pouvez inclure l'incertitude sous forme d'une probabilité en disant, par exemple, qu'il est probable, à 80 %, que le projet soit achevé avant le 15 juin. · Souvent, l'Organisme ne recueille ni n'analyse les mesures des performances des projets terminés. L'utilisation de données historiques est cependant la meilleure manière pour élaborer des estimations d'un nouveau travail. Il est très important d'établir une liste de caractéristiques fondamentales que vous mesurerez dans chaque projet. · Il est souvent difficile d'obtenir un planning réaliste accepté par l'encadrement et les clients. Chacun préfère que les résultats soient disponibles au plus tôt, mais pour chaque projet, il y a un délai minimal qui vous permet d'intégrer toutes les fonctionnalités avec la qualité requise. Vous devez définir ce que vous pouvez faire dans un délai donné et expliquer à toutes les parties concernées ce qui est possible et ce qui ne l'est pas. Oui, il arrive, de temps en temps, que l'impossible se réalise ... mais c'est très rare et très coûteux. Espérer l'impossible relève d'une téméraire imprudence ! 6.5. Pourquoi de mauvaises estimation ? · les besoins sont vagues, et la qualité des résultats difficile à évaluer, · les « managers » sont trop optimistes et pensent que tout ira bien ; ils espèrent le succès parce qu'ils veulent le travail, · on ne tira pas assez expérience du passé, on utilise trop le « pif » ; il faut de l'expérience pour bien estimer · imprécision des notions d'homme-mois, de ligne de code source. 6.5.1. Pièges à éviter · faire trop précis. Ø travailler avec des marges d'erreur importantes. · Sous-estimer. Ø Etre exhaustif dans la liste chose à estimer. · Sur-estimer. Ø Ne pas intégrer systématiquement tous les coûts des aléas possibles. · Confondre objectif et estimation. Ø Résister à « il ne faut pas que ça coûte plus de ... ». · Vouloir tout estimer. Ø Savoir avouer son ignorance. 6.5.2. Quelques règles d'or pour l'estimation · Eviter de deviner : prendre le temps de réfléchir, ne jamais sans avoir étudié la situation calmement. · Prévoir de temps pour l'estimation et la planification. · Utiliser des données de projets précédents. · Prendre l'avis des développeurs qui vont effectivement effectuer le travail. · Estimer par consensus : consulter les différentes équipes, converger sur des dates au plus tôt et au plus tard. · Estimer par difficultés (facile, moyen, difficile). · Ne pas oublier les tâches récurrentes : documentation, préparation des démonstrations utilisateurs, formation utilisateurs et développeurs, intégration à l'existant, récupération des données, revues, réunions, maintenance de l'existant pendant le développement du nouveau produit, gestion qualité, absentéisme (congés, maladie, RTT). · Utiliser plusieurs techniques d'estimation. · Changer de méthodes d'estimation au fil de l'avancement du projet. · Prendre en compte les risques de gestion dans l'estimation. · Eviter de données une estimation qui s'appuie sur un chiffre unique. Mais recommandons plutôt d'encadrer les prédictions par une fourchette optimiste/pessimiste. Le tableau ci dessous (adapté de « Cost Models For Future Software Life Cycle Processes : COCOMO 2.0 », Bohem et Al.1995) donne une base d'estimation pour passer d'un chiffre unique à une fourchette grâce à des coefficients multiplicateurs. PhaseTaille Et EffortDurée OptimistePessimisteOptimistePessimisteAnalyse initiale des besoins0.254.000.601.60Définition approuvée des besoins0.502.000.801.25Spécification des besoins0.671.500.851.15Conception globale0.801.250.901.10Conception détaillée0.901.100.951.05 Tableau : coefficient multiplicateurs pour chaque phase du projet. Pour utiliser les facteurs multiplicatifs de ce tableau, il suffit de multiplier le point d'estimation unique par les coefficients appropriés de manière à obtenir une fourchette d'estimation dont on peut remarquer qu'elle se resserre au fur et à mesure que l'on avance dans les phase (0.90 à 1.10 en conception détaillée contre 0.25 à 4 en analyse initiale des besoins, donc au moment de réponse à l'appel d'offres !) plutôt que d'estimer la durée du projet dans son ensemble on peut le décompose et estimer chacun de ses composants. 6.5.3. Qualités de l'estimation · Rendue dans les délais. · Homogène en précision. · Honnête. · Complète. · Afficher les hypothèses. · Réaliste. · Proche du coût réel Best Estimate. 6.6. Exactitude et précision d'une estimation L'exactitude caractérise l'approche de la réalité, alors que la précision caractérise la finesse avec laquelle une grandeur est mesurée. Par exemple, une estimation de taille de 70 ou 80 kilo-instructions peut être à la fois la plus exacte et la plus précise que vous puissiez faire à la fin de la phase de spécifications des besoins d'un projet. Si vous simplifiez votre estimation en annonçant 75 000 instructions, celle-ci semble plus précise mais en réalité elle est moins exacte. Vous pouvez annoncer 75 281 avec une précision d'instruction, mais on ne pourra mesurer cette taille qu'à la fin de la phase de codage du projet, après décompte des instructions. Si vous donnez l'estimation de la taille sous forme d'une plage (intervalle entre une valeur minimale et une valeur maximale) plutôt qu'avec une simple valeur, toutes les valeurs ultérieurement calculées (charges, délais, coûts) seront également représentées par des plages. Si, lors du déroulement du projet, vous faites plusieurs estimations au fur et à mesure que les spécifications de l'ouvrage deviennent plus détaillées, l'intervalle peut se resserrer et votre estimation se rapprochera du coût réel de l'ouvrage que vous développez. (FigI. 6). Fig I.6 -*Graphe de convergence des estimations « Développement rapide* » (MCCONNELL1996) adapté de Modèles de coûts pour le cycle de vie (BOEHM 1995). Autres Facteurs : d'autres facteurs importants qui affectent l'exactitude de vos estimations : · l'exactitude de toutes vos données d'entrées des estimations (le vieil adage « flou en entrée, flou en sortie » reste vrai) ; · l'exactitude de tous les calculs (par exemple, la conversion des points de fonction ou des nombres d'instructions en charges, conserve une certaine marge d'erreur) ; · la façon dont vos données historiques ou les données classiques utilisées pour calibrer le modèle s'appliquent au projet en cours d'estimation ; · le respect du processus de développement préconisé par votre Organisme ; · les conditions de management du futur projet : rigueur de la planification, conduite et contrôle ; · l'absence d'incident majeur déclenchant des retards intempestifs. 6.7. L'importance de l'estimation Il est important de pouvoir mesurer la productivité des programmeurs et ce au moins pour deux raisons. La première c'est qu'elle est indispensable à la planification des projets. La seconde, c'est que la démonstration des avantages qu'il peut y avoir a utiliser des méthodes de programmation et de gestion de projet évoluées ne peut être faite qu'en montrant des gains de productivité sur l'ensemble du cycle de vie de logiciel. 6.8. les unités de mesure Des unités de nature différente ont été proposées pour mesurer la productivité des programmeurs par exemple : · Nombre de lignes de code source écrites, par programmeur et par mois. · Nombre d'instructions de code objet produites, par programmeur et par mois. · Nombre de pages de documentation écrites, par programmeur et par mois. · Nombre de tests écrits et exécutés, par programmeur et par mois. L'unité la plus utilisée est le nombre de ligne source écrites, par programmeur et par mois ou par homme-mois. 6.9. Les coûts d'un projet le coût d'un projet est directement proportionnel au nombre d'homme-mois nécessaire a la réalisation du projet. Il y a, bien sur d'autres couts concernant le matériel, les déplacements, la formation, etc.., mais ceux-ci sont moins difficiles a établir. Ils ne sont pas basés sur des impondérables tels que la productivité des programmeurs ou l'estimation de la taille du code source. 6.9.1. Les différents coûts d'un logiciel 6.9.1.1. Le coût de développement Le coût de développement d'un projet logiciel est une valeur numérique .Ainsi, l'ensemble des valeurs similaires au coût d'un projet logiciel dépend, en général, des spécificités et des contraintes de l'environnement impliqué. Le coût détermine l'effort jugé nécessaire pour réaliser le logiciel ; s'exprime en homme- année ou en homme -mois. 6.9.1.2. Le coût de maintenance** Les coûts de maintenance sont supérieurs aux coûts de développement, et leur est dramatique sous estimation .Par exemple, un produit livré à des premiers clients avant d'être complètement terminé, et dont la maintenance est assurée par l'équipe de développement principale, générée du coût de maintenance qui peuvent noyer l'équipe, retardant «AD VITAM AETERNAM » les échéances à venir. Il est donc rentable d'investir dés la conception sur la réduction de ces coûts, au moyen d'actions organisationnelles et de contrôle qualité .On peut agir ainsi sur : · Des facteurs non techniques : Ø Stabilité de l'équipe ; Ø Durée de vie du programme ; Ø Dépendance du programme vis à vis de l'extérieur ; Ø Stabilité du matériel. · Des facteurs techniques : Ø indépendance des modules ; Ø Langage de programmation ; Ø Style de programmation ; Ø Méthodes et outils de validation et de test Ø Documentation ; Ø Gestion de configuration. 6.10. Quelle méthode d'estimation choisir ? · Chaque méthode a ses avantages et ses inconvénients. · L'estimation du coût du logiciel doit se baser sur plusieurs méthodes. · Le fait que les résultats fournit par les différentes méthodes sont sensiblement différents montre qu'il y a un manque d'information. Dans ce cas, des actions doivent être entreprises pour obtenir plus d'information permettant d'améliorer la précision des estimations. · L'affectation du coût pour gagner est parfois la seule méthode possible. 7. CONCLUSION : Depuis sa naissance à la fin des années soixante, le génie logiciel a connue beaucoup de développement et d'évaluation. Les outils de développements, les méthodes et les techniques du génie logiciel évoluent rapidement et ont un cycle de vie très court. Du fait de l'importance de maîtrise des coûts de production qui sont souvent imprévisibles un certain nombre de méthodes et techniques permettant d'estimer le coût d'un produit logiciel ont été mises à la disposition des responsables de projet informatiques. Ces méthodes sont détaillées dans le chapitre suivant

Un atelier de genie logiciel dedié a l'estimation du cout logiciel

Introduction Au Génie Logiciel