Le Coût d’un logiciel Exposé sur : Présenté Par: Travail dirigé par:

Slides:



Advertisements
Présentations similaires
PLASMIONIQUE RÔLE DE PMEs DANS LE TRANSFERT TECHNOLOGIQUE
Advertisements

Le projet HEI 3 – Décembre 2005.
Eléments de Génie Logiciel
Les points ECVET Outil de communication conçu à partir des documents développés pour l’organisation des réunions du projet.
LYCEE CORMONTAIGNE LE 22 Mars 2007
Page : 1 / 8 Conduite de projet Examen du 3 juin 1988 Durée : 4 heures Le support de cours est toléré La notation tiendra compte très significativement.
Page : 1 / 7 Conduite de projet Examen du 17 mai 2000 Durée : 3 heures Le support de cours et les notes sont nécessaires La notation tiendra compte très.
Page : 1 / 5 Conduite de projet Examen du 22 mai 1997 Durée : 4 heures Le support de cours est toléré La notation tiendra compte très significativement.
_____________ II. Estimation des projets logiciels Frédéric FICHOT
Les démarches de développement
Tests et Validation du logiciel
Rational Unified Process (RUP)
Safae LAQRICHI, Didier Gourc, François Marmier {safae
Les Ateliers de Génie Logiciel
Notre produit notre service
Présentation: NGOK Emmanuel Expert en comptabilité nationale AFRISTAT
BTS SIO SLAM 5 Introduction à la gestion de projet
en management de projet
MRP, MRP II, ERP : Finalités et particularités de chacun.
MIAGE MASTER 1 Cours de gestion de projet
SIMULATION WATERFALL & INSPECTION
Cycle de vie dun logiciel Origine des erreurs La spécification 50% 40% 10% Le design Le codage.
COCOMO Intermediaire: Systemes Heterogenes LFI2, Automne 2008, Gestion de Projets.
Marketing Mix.
La comptabilité par activités
Etude globale de système.
IGL301 - Spécification et vérification des exgiences 1 Chapitre 1 Introduction (ref : Bray chapitre 1)
Project Scope Management
© Petko ValtchevUniversité de Montréal Janvier IFT 2251 Génie Logiciel Notions de Base Hiver 2002 Petko Valtchev.
La gestion par activités (ABM)
Conception des Réalisé par : Nassim TIGUENITINE.
La résolution de problèmes grâce à la technologie de l'information
Les étapes du cycle de développement du génie logiciel
Information et Système d’Information
Ingénierie Système en SysML appliquée à la rédaction du cahier des charges Y. Le Gallou Séminaire académique STI2D - Calais – 1er avril 2014.
Patrons de conceptions de créations
GESTION DE PROJET Ce que dit la norme ….
Le Cycle de conception Processus à suivre pour toute production Documenter le processus dans le carnet de réalisation.
Cycle de vie: « Waterfall » GEF492A Automne 2014 [HvV § 3.1]
Supports de formation au SQ Unifié
Institut Supérieur des Sciences Appliquées et de Technologie Sousse
Conduite de projets informatiques
GENIE LOGICIEL
Définitions Gestion Exemple
GESTION DE PROJET
Suivi de projet Architecture de l’information par l’équipe en charge du projet A Mille 2013.
Vérification dans le cycle de vie GEF492A 2014 Référence: [HvV §14.2, 14.9] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et.
Estimer la distribution en personnel GEF492A 2014 Référence: [HvV §7.3] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie.
2003 (revisé 2008)SEG Chapitre 11 Chapitre 1 “The Systems Engineering Context” Le contexte du génie de systèmes.
Le système informatique et le système d’information
Introduction au Génie Logiciel
Réalisé par: BOUMSISS Hassnae OUED Zahra TABIT Youssef EZZIANI Hamza
COCOMO II GEF492A 2013 Référence: [HvV §7.1.2, & Boehm]
Extrait du Referentiel BTS Systèmes numériques Options : Informatique et réseaux et Électronique et communication S1 à S9 Définition des savoirs et savoir-faire.
ESTIMATION / CHIFFRAGE
Le marketing : Cours d’introduction
Initiation à la conception des systèmes d'informations
Présentation février 2002 Relations Visiblement Meilleures.
Année 2006 – 2007 ENSEA © Emeric Rollin
Révision mi-session GEF492A 2014 Vincent Roberge Automne 2014.
Soutenance Phase 1 Bibliographie et Analyse des besoins
TIJARIATE Méthodes Orientées Objets Unified Process (UP) - Groupe A
LE BTS ASSISTANT DE GESTION PME/PMI POURQUOI ? Créée à l ’initiative de la CGPME (confédération générale des petites et moyennes entreprises), cette.
CONSEIL NATIONAL DE RECHERCHES CANADA PROGRAMME D’AIDE À LA RECHERCHE INDUSTRIELLE Accélérer la croissance des PME grâce à l'innovation et à la technologie.
Conduite de projet Estimation COCOMO
Modèles de cycle de vie et processus de génie
LES OUTILS DE GESTION DE PROJET
SIO Gestion de projets, applications SIO Hager Khechine, MBA, PhD. Séance 3 : L’estimation des charges.
Logiciel d’estimation pour fabricants de structures d’acier et métaux ouvrés.
Transcription de la présentation:

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 