Le Coût d’un logiciel Exposé sur : Présenté Par: Travail dirigé par: Université Mentouri de constantine Département informatique 3 licence -gl Exposé sur : Le Coût d’un logiciel Présenté Par: …………………………… …………………… Travail dirigé par: Mme BENABDELAZIZ

Plan: Introduction Qu’est-ce qu’un coût? Pour quoi calculer le coût? Les méthodes COCOMOs: COCOMO 81: COCOMO II : Avantages : Inconvénients: Autre méthode : Conclusion:

Introduction: L’informatique prend de l’ampleur dans notre vie quotidienne surtout sur le plan logiciel qui se développe à une vitesse fulgurante dans différents domaines. Pour la réalisation de ces logiciels, il faudrait commencer par un budget plus ou moins consistant. De ce fait, plusieurs mathématiciens et économistes ont mis en œuvre des méthodes (simulations) qui peuvent donner une estimation du coût à l’avance, pour éviter les problèmes de (sous/sur) estimation budgétaire

Qu’es qu’un coût? Le coût représente la meilleure approche possible en termes économiques de la valorisation d’un effort de transformation ente deux états (des matières brutes au produit fini). Dans notre cas d’une idée initial à un logiciel final. Ce coût (budget) peut être employé de plusieurs façons que ce soit pour l’achat des équipements qui seront utilisés pour la création d’un projet ou pour le payement de la main d’œuvre ou tout simplement pour la maintenance du produit.

Pourquoi calculer le coût? Sur un nombre de projets logiciels, on note 90% de taux d’échec dont : 1/3 d ’abandons: le projet et complètement abandonné pour divers raisons 3/4 en dépassement de budget (et/ou) délai, 1/2 n ’ayant pas atteint l ’objectif requis. Ainsi, pour un projet logiciel le coût est un paramètre essentiel et même vital pour la réussite du projet. Donc connaitre le budget à l’avance permet de bien réussir son projet et d’éviter les échecs. C’est pour cette raison, que des méthodes ont été mises en place pour estimer le coût. En voici quelques unes :

Les méthodes 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. Le premier modèle COCOMO date de 1981. IL a été développé par le Dr. Barry Boehm pour estimer le coût , en nombre de mois-homme (unité d’effort). 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.

modèle en Spirale : Ce modèle est adapté pour les gros projets complexes. Les risques sont sans cesse évalués à chaque cycle. Un cycle est décomposé en étapes. On distingue quatre phases dans le déroulement du cycle en spirale : * détermination des objectifs, des alternatives et des contraintes ; * analyse des risques, évaluation des alternatives ; * développement et vérification de la solution retenue ; * revue des résultats et vérification du cycle suivant.

Le modèle spirale:

COCOMO 81: (ou COCOMOI) Le modèle COCOMO 81 s'appuie sur une estimation de l'effort en homme*mois (HM) calculée par la Formule: Effort = C*M*taille**s C facteur de complexité M facteur multiplicateur Taille en milliers de lignes de code source livrées (KDSI) s proche de 1

COCOMO 81: (ou COCOMOI) Pour les projets basés sur une technologie traditionnelle, le modèle original de 1981 est encore valable, d'autant plus qu'il est maintenant rodé et bien documenté. COCOMO 81 est en fait constitué de trois modèles : 1/ Modèle de Base : Ce modèle estime l'effort en fonction du nombre de lignes de code, la productivité est un facteur d'échelle qui dépend du type de projet. Les 3 types de projet identifiés sont : organique: organisation simple de petites équipes expérimentées. (ex: système de notes dans une école) semi-détaché: un peu plus complexe que le premier (ex: système bancaire interactif) imbriqué: techniques innovantes, organisation complexe, couplage fort avec beaucoup d'interactions. (ex : système de contrôle aérospatial.)

COCOMO 81:(suite) 2/ 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.

1: Multiplicateurs d'attributs de projet 6c|Valeurs   TB B M E TE TTE FIAB 0,75 0,88 1,00 1,15 1,40 -- DONN 0,94 1,08 1,16 CPLX 0,70 0,85 1,30 1,65 TEMP 1,11 1,66 ESPA 1,06 1,21 1,56 VIRT 0,87 CSYS 1,07 1.15 APTA 1,46 1.19 0,86 0,71 EXPA 1,29 1,13 0,91 0,82 APTP 1,42 1,17 EXPV 1,10 0,90 EXPL 1,14 0,95 PMOD 1,24 OLOG 0,83 DREQ 1,23 1,04 1.10 Multiplicateurs d'attributs de projet

COCOMO 81:(suite) 3/ 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 terme d'une hiérarchie : module, sous système et système. Il permet une véritable gestion de projet, utile pour de grands projets.

COCOMO II: Le modèle COCOMO I a été revu et améléoré. Il a donné naissance au modèle COCOMO II en 1998 adapté a la réutilisation de composants logiciels II est constitué en fait de trois modèles : 1/ 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'. 2/ 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.

COCOMO II:(suite) 3/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. Les facteurs utilisés sont classés en : Facteurs d'échelle, Urgence, Flexibilité de développement, résolution d'architecture/Risque, Cohésion d'équipe et Maturité de Processus. COCOMO II peut être calibré pour mieux correspondre aux projets de l'entreprise.

Avantage & inconvénient : - COCOMO reste la référence en matière d'estimation détaillée des coûts et surtout de la ventilation de ces coûts suivant les phases des projets. - Les estimations de COCOMO sont d'autant plus fiables, que les paramètres du projet sont bien connus, c'est-à-dire que les projets précédents ont servi pour étalonner ces paramètres. - COCOMO à l'avantage d'être ouvert. Les données de calibrage, les formules et tous les détails des définitions sont disponibles. La participation à son développement est encouragée.

Avantage & inconvénient :(suite) Il 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.

Autres méthodes : CORADMO pour Construction Rapid Application Development Model COPROMO pour Constructive Productivity Improvement Model COSYSMO pour Constructive Systems Engineering Cost Model

Conclusion: COCOMO reste le plus connu des modèles d'estimation de coût de projets logiciels. Le modèle d' origine ne s’adresse pas aux projets utilisant les composants logiciel existants. COCOMO II répond à ce problème, mais il est encore récent, Le projet de recherche appelé COCOTS est à suivre pour les personnes désirant estimer un projet logiciel moderne. COCOMO reste la référence en matière d'estimation détaillée des coûts et surtout de la ventilation de ces coûts suivant les phases des projets. Les estimations de COCOMO sont d'autant plus fiables, tant 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.

Bibliographie: Boehm, Barry W., Software Engineering Economics, (1981) Cocomo dans toute sa profondeur, par l'auteur de Cocomo lui même. Boehm, Barry W., Software engineering economics, IEEE Trans. on Software Engineering.,(1984) Détails pour assigner les valeurs aux 15 facteurs de productivité. Shepperd, Martin, Fundation of Software Measurement, (1994) Le pourquoi et comment des différentes méthodes de mesure de logiciels. Katwijk, J. van, Inleiding software engineering, (1994) Pressman, Roger S., (adapted by Darrel Ince) Software engineering "A practitioner's approach", (1994)

Merci pour votre attention. Nous sommes prêt à répondre à toutes Merci pour votre attention. Nous sommes prêt à répondre à toutes vos questions Sauf Mr DIB 