Aucun titre de diapositive - Deptinfo

Page 1Estimation des projets SICMSL/B.Mesdon - Mars 2004

PRATIQUE DE L ’ESTIMATION DES COUTS DE PROJETS DE

SI

C E N T R E D E

M A I T R I S E D E S

S Y S T E M E S E T

D U L O G I C I E L


PLAN– STARTALERT : Projet moyen de

gestion– GESTMAT : Grand projet de

gestion– GROUPWORK : Très grand

projet d ’intégration

• Pratique de l ’estimation– Introduction– Typologie des projets– Cas des projets « agiles »– Démarche générale– Ratios de productivité– Charges additionnelles– Estimation et suivi des délais de

développement– Problématique du coût total de

possession• Etudes de cas

– Typologie à travers 3 cas– Récapitulatif des charges et

délais


PRATIQUE DE L ’ESTIMATION


Introduction• Les méthodes d ’estimation COCOMO et Points de fonction ont

été proposées en 1970-1980 pour les applications centralisées de l ’époque. Dans la pratique courante d ’aujourd’hui, la typologie des projets a beaucoup évolué. Néanmoins, moyennant quelques adaptations, ces méthodes sont encore globalement valables dans les environnements actuels.

• De toutes façons, l ’étalonnage à partir des cas connus et mesurés (en terme de typologie, taille, complexité, environnement, etc.) reste fondamental, quand à la fiabilité desrésultats.

⇒ L ’utilisation des méthodes d ’estimation font partie des « bonnes pratiques » de l ’AQL (Assurance Qualité Logiciel).


Typologie des projets (1/4)

• La typologie proposée comprend les trois classes suivantes :

– Développement d ’applications de gestion– Développement d ’infrastructures logicielles et applications

techniques– Intégration de systèmes

• Nota1 : Dans COCOMO-2, B.Boehm introduit une classe spécifique pour « End-User Programming ». Mais, les « end-user » n ’utilisant pas habituellement de méthodes d ’estimation, on négligera cette catégorie.

• Nota2 : Les « embedded systems » sont devenus une catégorie importante. Leur estimation peut s ’approcher par des méthodes dérivées des points de fonction (Full Fonction Points)


Typologie des projets (2/4)• Applications de gestion

– Ce sont les applications de gestion traditionnelle développées en méthodologie MERISE ou objet.

– Profil type :» Développement sous AGL orienté Gestion

• Delphi, PowerBuilder, Uniface• AGL HTML, XML, JAVA, etc.

» BD relationnelles» IHM graphiques et/ou « navigateur »» Mises à jour des BD en mode transactionnel» Environnements d ’exécution maîtrisés

• Centralisé (classique, client léger)• Client /Serveur (2-tier, n-tier, web, ..)

⇒ Méthode d ’estimation : Points de fonction (IFPUG, MKII)


Typologie des projets (3/4)• Projets d ’infrastructures logicielles et applications techniques

– Ce sont sont les développements chez les constructeurs (OS) et chez les éditeurs (middleware). On y rattache les applications techniques (CAO, DAO, etc.), ainsi que les logiciels embarqués.

– Profil type :» Développement sous AGL orienté système

• historiquement, développement en assembleur, puis C.• évolution vers C++, JAVA

» Prise en compte de contraintes de productisation : portabilité, interopérabilité, évolutivité, maintenabilité, etc.

» Environnement d ’exécution pouvant dépendre d ’aspects combinatoires, événementiels, sécuritaires, etc.

⇒ Méthode d ’estimation : COCOMO (ou FFP ?)


Typologie des projets (4/4)

• Intégration de systèmes– Ce sont les « grands projets complexes » des domaines

Défense, Avionique, Télécommunications, Energie, etc.– Profil type :

» Ces projets cumulent la contrainte d ’adéquation à des besoins spécifiques « métier » propres aux applications de gestion, avec la complexité d ’architecture des infrastructures logicielles.

» L ’ensemble implique une étude d ’architecture complexe, et une intégration d ’éléments hétérogènes (COTS, spécifiques, réutilisés).

» Méthodologies de gestion de projet « lourdes » avec contraintes rigoureuses de gestion de configuration.

⇒ Méthode d ’estimation bien adaptée : COCOMO + Points de fonction


Cas des projets « agiles »• Cycle classique

– Les méthodes d ’estimation ont été proposées pour estimer des projets à spécification fonctionnelle pré-définie et développés suivant un cycle plutôt séquentiel.

• Méthodes agiles– Les méthodes de développement dites « agiles » veulent

supporter une spécification évolutive. L ’estimation à partir de la spécification est donc impossible dans ces conditions.Concrètement, l ’agilité implique souvent de considérer le budget de développement et le calendrier comme des données de départ.

» Tout chef de projet confirmé sait de toutes façon que, même en méthode traditionnelle, les budgets et calendriers sont contraints.

– En fait, ces méthodes sont plutôt réservées aux projets exploratoires, et de toutes façon limités en taille.


Démarche générale (1/3)

• Généralités– La démarche d ’estimation des charges et coûts par le Chef

de Projet correspond à une phase de responsabilisation.– L ’état de l ’art en méthodes d ’estimation est loin d ’être

parfait. Une marge d ’erreur de + -20% est acceptable.– A 99,999%, l ’écart est dans le sens de l ’augmentation

» Syndrome de dérive des coûts/délai, avec pour cause fondamentale, la non stabilité de {F,Q}

⇒ La démarche d ’estimation est un bon préambule à l ’analyse des risques projet, et à l ’analyse de la valeur.



• Les 9 étapes de l ’estimation– 1 Cadrage général et identification de la classe de projet– 2 Modélisation fonctionnelle (découpage en fonctions)– 3 Estimation des charges de développement de chaque fonction

et/ou module– 4 Estimation de certaines charges additionnelles, si elles sont omises

dans la modélisation fonctionnelle.– 5 Cumul des charges pour obtenir la charge projet brute– 6 Application de facteurs correcteurs pour obtenir la charge projet nette– 7 Détermination des délais et calendriers de développement

– 8 Analyse des risques projet Recommandé– 9 Analyse de la valeur (nécessite l’estimation des charges et coûts

additionnels au développement proprement dit : infrastructure, déploiement, exploitation, formation, support, ..). Optionnel



• Remarques– Les étapes 1 à 7 constituent l ’estimation des charges et

délais de développement (les tâches MOE, de la conception à l ’intégration)

– L ’étape 8 est le plus souvent sous responsabilité conjointe MOA/MOE

– L ’étape 9 est toujours sous responsabilité MOA

⇒ L ’étape fondamentale est celle de modélisation (étape 2), car elle est complètement structurante pour l ’identification des modules à développer.


Ratios de productivité (1/4)• Généralités

– Une difficulté importante consiste à utiliser le bon ratio de productivité (étape 3 pour obtenir les h.j bruts). Ce ratio peutvarier dans un rapport de 1 à 15 (ou plus), et est décroissant par rapport à la taille et à la complexité.

– Dans le modèle COCOMO, l ’estimation de charge est donnée par :

effort = A (KLS)b , où A et B sont des « constantes »KLS = taille en K.lignes sourceA croit avec la complexitéB est un facteur d ’échelle (1,05-1,2)

⇒ Dans la pratique, on utilise des formule simplifiées linéaire dans une fourchette de taille et complexité connues


Ratios de productivité (2/4)Courbe de productivité

Productivité

Taille

Complexité


Ratios de productivité (3/4)

Type Rappel de ladéfinition

Productivitéen KLS par

an

Pourcentage deConception,

Codage + testsunitaires, Intégration

S Programme àspécification

connue

4 40/40/20

P Nature combinatoireet optimisations

spécifiques

2 40/30/30

E Gestiond’événements

1 45/20/35

FT Tolérance auxfautes

0,25 40/10/50

Ratios de productivité COCOMO


Ratios de productivité (4/4)

• Ratios de productivité pour points de fonctions– Les ratios de productivité utilisées dans les estimations en

points de fonctions sont souvent exprimées en PF/h.j– Dans la pratique on va de 0,2 PF/h.j (grands projets

complexes) à 3 PF/h.j (petits projets sur PC).

• Utilisation des facteurs d ’ajustement– Des facteurs d ’ajustement peuvent être utilisés avec

COCOMO (5 facteurs) ou les points de fonction (14 facteurs). Dans la pratique, on applique souvent un facteur d ’ajustement global à la charge nominale brute pour obtenir la charge nette.


Charges additionnelles

• Dans l ’estimation, on doit comptabiliser toutes les activités, mais ne les compter qu ’une seule fois.

• En particulier, le ratio de productivité inclut une valeur moyenne pour l ’activité de management projet MOE. Cependant dans certains cas, on considèrera des charge complémentaires, non incluses dans la productivité moyenne. Par exemple :

– Activités liées à l ’amélioration de la qualité (CMM, ..)– Activités d ’assistance à la MOA (support aux pilotes, support

au déploiement)

• Les charges MOA elles mêmes sont toujours comptées séparément. Elles ne sont pas négligeables (couramment supérieures à 20%).


Estimation et suivi des délais de développement (1/2)

• Estimation du délai nominal– Par référence au modèle COCOMO, on calcule souvent une

valeur du délai de développement dite « nominale », qui est plutôt interprétée comme le « minimum raisonnable ». Une formule couramment utilisée est :

Délai nominal = 2,5 (Effort)0,38

» Effort en h.mois» Délai en mois

• Délai planifié– Pour déterminer le délai planifié (et le calendrier), on tient

compte des contraintes du projet. Par exemples certaines activités doivent être sérialisées, ou ont une date butée.


Estimation et suivi des délais de développement (2/2)

• Phénomène de dérive du calendrier– Le phénomène de dérive du calendrier de développement

est parmi les plus fréquents problèmes de gestion de projet. Sa détection se fait à travers des outils de suivi du type « Tableau de bord »

– Le syndrome classiques :» Question : Quel est l ’état d ’avancement de l ’activité X ?» Réponse : Il est terminé à 80%» Même question 1, 2, 3 ..mois plus tard» Même réponse

– Comment éviter les dérive⇒ L ’analyse des risques projet permet d ’anticiper les

problèmes, et d ’apporter les mesures correctives, éliminant ainsi les causes de dérive.


Coût total de possession (1/4)• Durée de vie totale d ’un SI

– Après développement et mise en service du SI, celui ci va vivre, recevoir des nouvelles fonctions (maintenance applicative), recevoir des corrections d ’erreurs (maintenance corrective), être supporté (fonction support), et finalement après obsolescence, il sera « démonté » et retiré du service. Pour les systèmes actuels, malgré l ’accélération des introductions de nouvelles technologies, la durée de vie d ’un système est souvent d ’au moins 5 ans (durée amortissement comptable).

– Rappel du cycle de vie nominal (ISO 1207)

Développement Pilote

Déploiement

Utilisation

Maintenance Fin de vie

Expressionde besoins


Coût total de possession (2/4)• Pourquoi un coût total de possession

– Dans la plupart des projets de SI, on distingue les coûts de développement, qui sont dépensés de façon non-récurrente durant les phases de conception/développement/déploiement, des coûts de fonctionnement, qui sont de nature récurrente, durant la durée de vie du système. Pour comparer réellement des alternatives d ’architecture, il faut alors comparer les coûts totaux sur une période significative. On prend souvent 5 ans qui correspond aussi à la durée d ’amortissement comptable.

• Modèles d ’estimation des charges et coûts– Pour faire l ’estimation du coût total, on utilise en général les modèles

d ’estimation suivants:» Conception/Développement: COCOMO, Points de fonction» Déploiement: métrique basée sur le nombre de sites à déployer.

• Cas particulier des coûts de migration qui peuvent être très importants et/ou entachés d ’incertitude.

» Fonctionnement: métrique basée sur les utilisateurs (nombre), l ’architecture (nombre et nature des sites à administre), les volumétries (flux réseau en particulier).


Coût total de possession (3/4)• Exemples de postes de coûts de fonctionnement (récurrents)

– Maintenance applicative– Maintenance Systèmes– Support utilisateurs (1er et 2e niveau)– Exploitation (ou hébergement) et administration des systèmes – Télécommunications (abonnements et volumes transportés)

• Impact de l ’architecture sur les coûts– L ’architecture, en particulier s ’il s ’agit d ’architecture client/serveur, peut être

très structurante pour les coûts, y compris sur les coûts de fonctionnement (administration, réseaux).

– Dans l ’exemple réel suivant, des duplications journalières de référentiels de données vers des serveurs régionaux conduisent à des volumes transférés sur les lignes de télécommunication très importants, avec les coûts correspondants. Dans ce genre de situation, l ’architecture pourrait être revue pour diminuer les transferts (par exemple par gestion incrémentale des référentiels de données). Il s ’agit donc de procéder à une véritable ingénierie des coûts.


Coût total de possession (4/4)• Exemple de bilan économique d ’un projet avec serveurs

régionaux– Les chiffres suivants sont ceux d ’un projet réel de développement/déploiement d ’un

système d ’information sur 25 serveurs régionaux et 1000 postes de travail (architecture client/serveur).

Poste de coût Coût TotalMatériel 45 MFDéveloppement 30 MFDéploiement 5 MFTotal non récurrents 80 MFMaintenance sur 5 ans 15 MFSupport sur 5 ans 10 MFExploitation sur 5 ans 20 MFTélécom. Sur 5 ans 40 MFTotal récurrents sur 5 ans 85 MFGrand total 165 MF


ETUDES DE CAS


Typologie à travers 3 cas• Tableau des cas étudiés

Applications degestion

Applicationstechniques

Intégration desystèmes

Projet moyenEffort = 1-10h.ans

STARTALERTSupervision detrafic et diffusiond’alertes

Grand projetEffort = 10-100h.ans

GESTMATMaintenanced’équipementsmatériels

Très grandprojetEffort > 100h.ans

GROUPWORKSystème intégréde travailcoopératif surobjets complexes

Modèled’estimation

Points de fonction COCOMO Points de fonctions+ COCOMO


Récapitulatif des charges et délais

Projet étudié Caractéristiques projet Chargenette dedéveloppement

Délai dedéveloppement

Ratio deproductivité

STARTALERT Métho. ObjetJAVAArchi. N-tiers

68 h.mois Nominal : 10 moisProjet non lancé

PF :0,5 PF/h.j

GESTMAT Métho. MERISEAGL = UNIFACEArchi. Distribuée

321 h.mois Nominal : 1,7 ansPlanifié : 2 ansRéel après retard : 3ans

PF :0,4 PF/h.j

GROUPWORK Objets complexesIHM graphiques etcartographiquesGoupware/CORBAProgr. C++

150 h.ans Nominal : 2,6 ansPlanifié : 3 ansRéel : 3 ans

PF :0,255 PF/h.jCOCOMO :1,7 KLS/h.an


GESTMAT - Etape 1/Cadrage

• GESTMAT est un grand projet de gestion– GESTMAT concerne la base de données de référence et les

processus fondamentaux pour la maintenance des matériels fixes d ’une grande entreprise de transport.

– Le nombre maximum d ’utilisateurs est 2000 répartis en France, suivant une structure organisationnelle hiérarchisée : centrale, régionale, locale.

– Au moment où l ’estimation est faite (début de conception générale), l ’architecture distribuée cible n ’est pas encore arrêtée : le choix pourrait être entre client/serveur classique et client léger.

– Il existe une très forte contrainte de migration de bases de données et applications existantes.

– La réalisation est d ’emblée envisagée en plusieurs phases fonctionnelles.


GESTMAT - Etape 2/Modélisation• GESTMAT suit un cycle de vie de type MERISE

– L ’estimation par les points de fonction a été réalisée classiquement à partir du MCD (Modèle Conceptuel de Données) et du MOT (Modèle Organisationnel de Traitements).

– La représentation « Entités-Relations-Attributs » du MCD est bien adaptée à l ’identification des Groupes de Données internes et externes.

– Pour l ’identification et le comptage des traitements, le MOT donne le bon niveau de détails :

» Les entrées sont les transactions de mise à jour spécialisées (création, modification, suppression) pour chaque type d ’entité.

» Les sorties sont les états et visualisation avec calcul, ainsi que les interfaces en sortie

» Les Interrogations sont les transactions de consultation et les listes.


GESTMAT - Etape 3/Estimation (1/4 Données internes)

Groupe dedonnées

Poids Groupe dedonnées

Poids Groupe dedonnées

Poids

Coeur Simple Appareil designalisation

Simple Sous-station Simple

Découpage Simple Signal Simple Ouvrage d’art Complexe

Installationaffectée

Simple Fonction AS envoie

Simple PN Complexe

Comptages Simple Poste Simple Canton Simple

Point voie Simple CTV Simple Transfo Simple

Accès Simple Châssis Simple Câble Simple

Noeud T, X, Y Simple Constituant Simple Ouvrage en terre Complexe

Quai Simple Fonction sur 1châssis

Simple Cellule Simple

Requête Simple


GESTMAT - Etape 3/Estimation (2/4 Données externes)

Groupe de données Poids Groupe de données Poids

Ligne Complexe Spécialité Simple

Voie Complexe Installation générique Complexe

SAF Simple Structure de compétence Complexe

Installation Simple

Compétence Moyen

Segment de gestion Moyen


GESTMAT - Etape 3/Estimation (3/4 Traitements)

Poids notés x-y avec x=(Entrée, Sortie, Interrogation) et y=(Simple, Moyen, Complexe)

Traitements Poids Traitements Poids Traitements Poids

Gestion desinstallations

10x3 E-C Complémentsgestion desinstallations

8x3 E-C Complémentsgestion desinstallations

8x3 E-C

Gestion descoeurs

4 E-C Gestion des AS 4x E-C Complémentsinterrogationmono

35 I-M

IntégritéGESTGEO

E-C+ S-C

Complémentsinterrogationmono

40 I-M Complémentsinterrogation multi

7 I-C

Intégrité interne E-C+ S-C

Complémentsinterrogation multi

8 I-C Purge E-C

Interrogation« monoinstallation »

50 I-M

Interrogation« multiinstallations »

10 I-C

Gestion desrequêtes

3 E-S+ 2 I-S+ E-C+ S-C

Accès GESTGEO+autres accès

9 I-C


GESTMAT - Etape 3/Estimation (4/4 Récapitulatif)

Simple Moyen Complexe

Données internes 24x7 0x10 3x15 213

Données externes 3x5 2x7 4x10 69

Entrées 3x3 0x4 90x6 549

Sorties 0x4 0x5 3x7 21

Interrogations 2x3 125x4 34x6 710

Total 1562


GESTMAT - Etape 4/Charges additionnelles

• Développement d ’un prototype– Dans le cas de GESTMAT, le prototype sert à valider

l ’ergonomie générale. Sa charge de développement est estimée (par analogie avec d ’autres projets) à 40 h.jours.

• Outils de reprise et migration– Une stratégie de migration de type « BIGBANG » est

envisagée. La charge globale de développement des outils de reprise est estimée (par analogie avec d ’autres projets) à 500 PF.


GESTMAT - Etape 5/Estimation projet brute

• A ce niveau de l ’estimation, on obtient les comptages bruts suivants :

– Application GESTMAT : 1562 PF» Remarque : Le ratio PF données/PF total =(213+69)/1562=18%

est assez classique en gestion– Outils de reprise 500 PF– Prototype : 40 h.j


GESTMAT - Etape 6/Charge nette• Facteurs correcteurs

– Les 14 facteurs correcteurs théoriques ne sont pas utilisés. Néanmoins, par analogie avec d ’autres grands projets déjà réalisés, on admet une expansion fonctionnelle de 30% d ’ici la fin de réalisation.

• Facteur de productivité– Les autres projets réalisés du même type ont permis de

mesurer a posteriori un facteur de productivité de 0,40 PF/h.j. Ce chiffre est donc pris comme facteur de productivité.

• Charge nette– GESTMAT : (1562x1,3)/0,4 = 5075 h.j– Outils de reprise : (500x1,3)/0,4 = 1625 h.j– Prototype : 40 h.j– Soit un total de 5866/21 = 321 h.mois


GESTMAT - Etape 7/Délais• Délai nominal

– Les outils de reprise sont développés en parallèle. Le délai optimal est donc calculé comme : 2,5x(239)0,38 = 20 mois

• Délai planifié– Par ailleurs, l ’objectif de délai est de 24 mois. Le plan projet

est donc aligné sur ce chiffre.

• Délai réel– Voir étape 8


GESTMAT - Etape 8/Analyse de risques

• Conséquence d ’une non prise en compte des risques– Un risque élevé lié à l ’incertitude sur l ’architecture technique

cible avait été identifié très tôt. En fait, les aspects d ’architecture, de performance réseau, de volumétrie ont tardé à être abordés et les choix n ’ont pu être faits à temps. … En bref, un exemple classique de sous estimation des aspects non fonctionnels.

– Finalement, la prise en compte tardive de l ’architecture a fini par provoquer un retard de 6 mois sur le début de conception détaillée, puis une dérive permanente s ’est installée. Six mois ont de nouveau été perdus.

– Après stabilisation du retard et redémarrage du projet, le délai global s ’est finalement établi à 3 ans au lieu de 2.


GESTMAT - Etape 9/Analyse de la valeur• Une analyse du coût total de possession sur 5 ans a été effectuée

par le responsable maîtrise d ’ouvrage.– Les chiffres suivants font apparaître le poids relatif très important des coûts de

télécommunication du développement (40/165 = 25%) par rapport au coût total sur 5 ans.

Poste de coût Coût TotalMatériel 45 MFDéveloppement 30 MFDéploiement 5 MFTotal non récurrents 80 MFMaintenance sur 5 ans 15 MFSupport sur 5 ans 10 MFExploitation sur 5 ans 20 MFTélécom. Sur 5 ans 40 MFTotal récurrents sur 5 ans 85 MFGrand total 165 MF


STARTALERT - Etape 1/Cadrage

• STARTALERT est un système qui collecte des informations (y compris des alertes) de trafic maritime venant de plusieurs sources, les stocke, et les rediffuse vers des organisations abonnées.

• Certaines des informations se présentent comme des messages venant de messageries classiques, alors que d ’autres proviennent de collectes automatiques.

• L ’estimation est faite à partir d ’un cahier des charges d ’appel d ’offre (CCTP), en vue de produire une proposition commerciale de réalisation au forfait.

• La proposition a finalement été rejetée par le client, car jugée trop chère.


STARTALERT - Etape 2/Modelisation

• Le cahier des charges fonctionnel (CCTP) contient une description précise des messages à traiter.

• Dans la mesure, où dans la première phase du projet, il n ’y a pas de traduction de formats à faire, la modélisation se simplifie, car finalement, la complexité des données est portée directement dans la définition des « messages à plat » (messages POLREP, SITEREP …).

• Par compte, pour la complexité fonctionnelle des traitements (en gros un écran = un traitement), il faut faire une analyse fine pour les dériver à partir des descriptions plutôt conceptuelles du CCTP (concepts d ’émission, réception, transmission, notification,interrogation, consultation ..).


STARTALERT - Etape 3/Estimation(1/5 données internes)

Groupe de données internes Nombre de champs Complexité

Identification du contrôle 14 F

Port 7 F

Navire 11 F

Voyage 30 F

Matière Dangereuse (MD) 23 F

Situation (infos SITREP) 13 F

Inspection 9 F

Pollution 9 F

Déchet 9 F

Pedigree navire 8 F

Compte rendu 2 F

Total 11*F


STARTALERT - Etape 3/Estimation(2/5 données externes)

Donnée externe Nombre de champs Complexité

Base « Manifeste des matièresdangereuses »

Déjà comptéen GDI

Base Navire 24 F

Annuaire « autorité » 24 F

Total 2*F

Soit un total pour les données internes/externes de 13*F = 13*7 = 91 PFA ce niveau de granularité, on prend une marge de 20%^pour tenir compte des oublis.Soit 91*1.2 = 110 PF de données


STARTALERT - Etape 3/Estimation(3/5 traitements d ’entrée )

Les traitements d ’entrée sont essentiellement les messages en émission/réception tels que définis par le CCTP (questionnaires de saisie et traducteurs).On admet que les 40 messages de poids moyen suivants englobent les charges de développement d ’un éditeur et traducteur simples.

Acteurs Message Commentaire Complexité

Autorités MOUV M

MOUV INF Traduction automatiquepar IED

M

CROSS 6 messages dont certains àchamps optionnels.

Reserve pour 20messages potentiels

20*M

Procès Verbal M

CROSS

Ports

Prévision M

Départ

Arrivée

2*M

SafeSeaNet Réserve pour 14messages

14*M

Total 40*M


STARTALERT - Etape 3/Estimation(4/5 autres traitements )

SortiesAu sens des points de fonction, les sorties sont les messages de notification et certaines retransmission avec traduction.

Sans autres approfondissements, supposons une vingtaine de messages de notification de complexité moyenne.Soit 20*5 = 100 PF

Interrogationsles interrogations et consultations sont décrites dans le CCTP, avec des exigences spécifiques sur filtrages et fonctions du requêteur.

En première approximation, on suppose une complexité équivalente à une trentaine d ’interrogations complexes.Soit 30*6 = 180 PF

Administration/SupervisionL ’acteur principal pour ces traitements est l ’administrateur.On fait une hypothèse globale de 50 PF pour ces traitements

StatistiquesLes statistiques représentent une douzaine d ’états complexes.Soit 12*7 = 84 PF


STARTALERT - Etape 3/Estimation(5/5 Récapitulatif )

Domaine Poids en PF Commentaire

Données 110

Entrées 160

Sorties 100

Interrogations 180

Administration 134

Total 684 PF


STARTALERT - Etapes 4 - 5 - 6 - 7

• Etape 4 - Charges additionnelles– A priori pas de charges additionnelles détectées dans le CCTP

• Etape 5 - Estimation projet brute– On obtient donc le comptage brut de : 684 PF

• Etape 6 - Charge nette– Par analogies avec d ’autres projets développés par la même

équipe (méthodes objet, JAVA, développeurs expérimentés), on admet un facteur de productivité de 0,5 PF/h.j.

– Soit une charge de 684/0,5 = 1368 h.j = 68,4 h.m

• Etape 7 - Délai nominal– Le délai nominal sur la phase de développement sera donc :

» Dnom = 2,5*(68,4)0,33 = 10 mois


STARTALERT - Etape 8/Analyse de risques (1/2)

• Risques liés à l ’estimation en avant vente– Pour un projet en avant-vente, on pourrait distinguer deux

types d’analyse de risques. La première considère les risques de ne pas remporter l’affaire, alors que la deuxième considère l’affaire remportée, le projet lancé, et veut identifier et anticiper les risques durant la réalisation du projet.

– Les deux analyses sont complémentaires. En particulier, si on baisse le prix de la proposition à périmètre constant pour diminuer le risque de ne pas être sélectionné, on augmente le risque financier sur le projet de réalisation.

– De toutes manière, même en avant-vente, il est intéressant d’anticiper au maximum sur les risques du projet de réalisation de façon à négocier en vue de la meilleure contractualisation possible.


STARTALERT - Etape 8/Analyse de risques (2/2)

• Ce qui s ’est passé !!– Pour couvrir le risque de sous-estimation sur ce projet au

forfait, la proposition au client a été faite avec un coefficient de marge de 2 soit 140 h.mois …. Avec le même calendrier de 10 mois.

» Le risque était réel car les développements liés à la traductiondes messages (par exemple en XML) n ’étaient pas bien définis dans le CCTP

– Mais finalement, le client a confié le projet à une autre SSII, qui proposait un devis plus réduit.

» Les exigences clients ont semble-t-il été réduites ultérieurement, et le système réalisé a plutôt été un prototype qu ’un système complètement opérationnel.

Documents

Aucun titre de diapositive - Deptinfo