CNAM- 13 Juin 2001 Processus d ’estimation de projet

© 2001 IMRglobal Corp. All rights reserved.

Dimensionner une application ou un projet?

François de Verdière Directeur IMRglobal

Dimensionner une application ou un projet?Dimensionner une application ou un projet?

François de Verdière Directeur IMRglobalFrançois de Verdière Directeur IMRglobal

CNAM- 13 Juin 2001

Processus d ’estimationde projet logiciels

dans les domaines de Systèmes d ’Information

CNAM- 13 Juin 2001

Processus d ’estimationde projet logiciels

dans les domaines de Systèmes d ’Information


!! PréambulePréambule! Peu ou pas de projets dans les délais et les côuts !!

! Et chez vous, soyez franc (mais restez discret..)

! Sommes nous d �incorrigibles optimistes ?

! Peux t-on en guérir, docteur?

! « Sizing or Estimating » ou comment les anglo saxons sont plus précis

! Une réflexion sur le passé

! Mais ce qu �il faut faire n �est pas si compliqué


!! Dimensionner : Taille et EstimationDimensionner : Taille et Estimation– « Sizing or Estimating »– Causes d �estimations erronnées– Modèles de dimensionnement classiques et leur problèmes– Dimensionnement et cycle de vie– Le modèle de dimensionnement Edifice d �IMRglobal– Le processus de dimensionnement


!! DéfinitionsDéfinitions! Tailler (sizing) une application, c’est :

– Estimer le nombre d �objets fonctionnels (et techniques?) :" tables, écrans , procédures, interfaces," classes, méthodes" et éventuellement de lignes de code (LDC)" nécessaires pour satisfaire les besoins « exprimés » par les utilisateurs

! Estimer un projet : Dimensionner– Déterminer les ressources nécessaires à la fabrication du produit prévu

" Charge de travail (j*h, m*h, a*h)" Durée (jour, semaine, mois, année)" Compétences (profil, nombre)" Budget (FF, intégrant les locaux, postes, outils, …)

En tenant compte des contraintes (durée, coût, �)


!! Causes d'estimations erronéesCauses d'estimations erronées

Source : Caper Jones, Software Productivity Research, Inc.

Connaissance du projet

Précision de l’estimation,

si processus « défini » (3)

+-50% +-30% +-20% +-10%

10% 25% 40% 60% 80% 90% 100%

Initialisation Analyse Conception Implémentation Tests


!! Causes d'estimations erronées (suite)Causes d'estimations erronées (suite)

0

100

200

300

400

500

600

10 100 500 1000

Effort réelEstim. basse

Source : Stuart Madnick, Sloan management review

KLOC

Années*homme


!! Causes n°1 : PérimètreCauses n°1 : Périmètre! Les besoins sont mal (pas) exprimés et donc la taille est inconnue�

! Par définition les besoins ne sont pas totalement exprimés avant la finsatisfaisante d�un projet !!

! L �appel d �offres dans un périmètre peu défini est un appel au meurtre...

! Au cours du projet, la gestion du périmètre est le plus souvent mal (peu) faite


!! Causes n°2 : Absence de métriquesCauses n°2 : Absence de métriques! Les bases de métriques sont inexistantes ou non relevantes au moment de

l �estimation– soit pour une population de ressources données– soit parce que la technologie est récente– le plus souvent pour les deux raisons,�– on confond souvent taille et dimensionnement

! Les conditions de début et de fin ne sont jamais correctement définies ...– degré de maîtrise du sujet par une maîtrise d �ouvrage– les besoins et spécifications implicites– degré de fiabilité, de performance ou de robustesse d �un système– ergonomie d �un système– maintenabilité d �un système

! les hypothèses de recueil des métriques ne sont pas correctementdocumentées

– conditions de début et de fin– qualité et expérience des ressources


!! Causes n°3 : Variance de productivitéCauses n°3 : Variance de productivité! les équipes découvrent le domaine fonctionnel

! les équipes découvrent la technologie

! les équipes sont trop inexpérimentées dans le processus logiciel

! le processus logiciel n �est ni répétable ni défini

! la variance de productivité est très large– La productivité varie de 1 à 5 au minimum!– Quel autre exemple d �une industrie aussi peu prévisible?

! Beaucoup plus rarement le rythme ou les outils en sont la cause :

! Les informaticiens sont mal formés, mal entraînés par leur management ettravaillent souvent comme des b�ufs pour réussir comme des ânes...


!! Causes n°4 : Quelle industrie ??Causes n°4 : Quelle industrie ??peut développer un savoir faire

! quand tout le monde veut être « chef de � » et ne plus développer au bout dedeux ans

! quand tout le monde veut surfer sur des vagues technologiques éphémèresqui ne portent pas plus de deux ans...

! Comment construire un patrimoine d �expériences sur des bases aussimouvantes?


!! Modèles classiquesModèles classiques– « Sizing or Estimating »– Causes d �estimations erronnées– Modèles de dimensionnement classiques et leur problèmes– Dimensionnement et cycle de vie– Le modèle de dimensionnement Edifice d �IMRglobal– Le processus de dimensionnement


!! Le modèle des Points de FonctionLe modèle des Points de Fonction! L'analyse des points de fonction (APF) est une mesure des fonctions fournies par une

application informatique (telle que perçues par un utilisateur)

! La méthode est suivie par l'IFPUG (International Function Points User Group),

! APF classifie et compte les points de fonctions par catégorie– Nombre et complexité des Entrées– Nombre et complexité des Sorties– Nombre et complexité des Tables (ensemble de données)– Nombre et complexité des Interrogations– Nombre et complexité des Interfaces à d�autres applications

! La pondération se fait par un critère simple de comptage de variables, entrées, etc...

! De plus un coefficient d'ajustement dû à l�environnement technique ou du projetpermet d�ajuster le nombre de PF en plus ou en moins


!! Le modèle des Points de FonctionLe modèle des Points de Fonction! On comptabilise d'abord les fonctionnalités par catégorie

Application Entrées (E) Sorties (S) Tables (T) Interfaces (I) Interrogations (Q)Simple Moyen ComplexeSimple Moyen ComplexeSimple Moyen Complexe Simple Moyen Complexe Simple Moyen Complexe

3 4 6 4 5 7 7 10 15 5 7 10 3 4 6Application A 40 45 25 25 40 69 50 50 50 30 30 20 20Application B 10 10 10 10 10 100 100 30 10 10 20Application C 10 15 10 10 10 10 20 50


!! Le modèle des Points de FonctionLe modèle des Points de Fonction! On applique ensuite un coefficient d'ajustement dépendant d'un certain

nombre de critères caractérisant l'application– Communication– Traitements distribués– Performances– Taux d'utilisation / transactions– Taux d' interactivité de l'application– Efficacité des utilisateurs– Complexité des traitements– Réutilisabilité– Facilité d'installation– Nombre de sites

! Chaque critère varie de 1 à 5! Le coefficient d'ajustement peut varier de 0,65 à 1,35


!! Le modèle des Points de FonctionLe modèle des Points de Fonction! Avantages :

– Il existe!– Il est relativement facile à apprendre– Il donne un bon résultat dans la mesure du périmètre ( vous savez : pour répondre à votre utilisateur qui vient juste de vous demander

d �ajouter 3 à 4 « écrans » un mois avant le début de la recette)

! Inconvénients– Il est assez subjectif dans ses coefficients d �environnement

" et mélange alors taille et estimation : par exemple, ambiguïté de la réutilisation" ou mélange architecture et application : par exemple, robustesse et fonctionnalités

– il faut l �appliquer dans ses moindres détails et ne peut se concevoir qu �àl �issue du projets ou de spécifications très détaillées


!! Le modèle COCOMOLe modèle COCOMO

Source : Software Estimates Barry BOEHM

! C�est un modèle d �analyse de régression– c�est le modèle d�estimation le plus connu– il est déterminé par la taille supposée de l�application (en KLDC hors définitions

et commentaires)– il est basé sur une analyse de régression de données historiques sur des milliers

de projets en environnement classiques L3G (Cobol, C, etc..)

L'effort Effort (m*h) = 2,4 (KLDC)1,05

La durée Durée (mois) = 2,5 (Effort)0,38

Exemples 50 KLDC 145m*h en 16 mois

500 KLDC 1637m*h en 41 mois


!! Le modèle COCOMOLe modèle COCOMO

Source : Software Estimates Barry BOEHM

! Avantages– c�est le modèle d�estimation le plus connu– il est déterminé par la taille supposée de l�application à construire (en KLDC hors

définitions et commentaires)– il est basé sur une analyse de régression de données historiques sur des milliers

de projets en environnement classiques L3G (Cobol, C, etc..)– il est excellent en analogie

! Inconvénients– il ne dit pas comment trouver la taille!– Il ne représente que le passé que l �on a mesuré, en grand nombre mais de façon

peu ciblée et donc peu représentative de votre contexte– les « nouvelles » techno et méthodes ne sont pas couvertes


!! ModèleModèle Edifice Edifice d ’IMR d ’IMR– « Sizing or Estimating »– Causes d �estimations erronnées– Modèles de dimensionnement classiques et leur problèmes– Dimensionnement et cycle de vie– Le modèle de dimensionnement Edifice d �IMRglobal– Le processus de dimensionnement


!! Principes de la démarchePrincipes de la démarche Edifice Edifice! Pour construire le SI de l'entreprise

– L'architecture commune– Les projets applicatifs

! Favorisant la réutilisation– Approche composants– Outillage et Processus

! Adaptée aux cycles de vie plusitératifs quand il est impossible detout définir en amont

– Forte réactivité– Engagement des utilisateurs

! Introduisant des métriques

! Dans des architectures Objet Intra/Internet

Traditionnelle Avec réutilisation

Processus 1=

Applicatif 1

Composants techniqueset middleware

Objets métier

Processus 1=

Applicatif 1Processus 2

=Applicatif 2

Processus 3=

Applicatif 3

Processus 2=

Applicatif 2

Processus 3=

Applicatif 3


!! Nouvelles métriquesNouvelles métriques! Ces modèles de développement nécessitaient de nouvelles méthodes

d'estimation– Une part des fonctionnalités requises existe dans le référentiel de composants– Une réutilisation significative autorise une nouvelle manière, plus pratique, pour

estimer

! Pas seulement utilisé pour l'estimation de la première version– Utilisé dans les différentes itérations et versions– Applicable durant toute l'évolution du système

! 1ère étape : collecter ses propres résultats de projets

! 2ème étape : bâtir les métriques de taille et d �estimation

! 3ème étape : les utiliser, et les amender sur plusieurs années d'expérience(tout spécialement en cas de changement technologique)


Fabrication

!! Dimensionnement et cycle de vieDimensionnement et cycle de vie Edifice Edifice

Pilotage

Itération 1

Analyse préalable

Planification globale du projet Planification détaillé de chaque itération

Itération 2 Itération 3

A l’issue de l’analyse préalable,définition du nombre d’itérations

et du contenu de chaqueitération

A l’issue de l’analyse préalable,définition du nombre d’itérations

et du contenu de chaqueitération

Au début de chaque itération, définitiondu planning détaillé de l’itération

Affectation des tâches

Au début de chaque itération, définitiondu planning détaillé de l’itération

Affectation des tâches


!! Le modèle de taille et dimensionnement EDIFICELe modèle de taille et dimensionnement EDIFICE! Il repose principalement sur une catégorisation de la complexité des

classes et des processus– Critères d'évaluation de la complexité d'une �stock� métier :

" Nombre d’attributs" Nombre de méthodes ou services" Nombre de liens (je suis composé de, …)" Réutilisation (j'hérite de)" Difficulté de conception

– Critères d'évaluation de la complexité d'un processus métier:" Nombre et complexité des classes utilisées" Traitement distribués" Transactions simples ou complexes (en lecture seulement, en mise à jour)" Nombre d’écrans" Classes non persistantes à implémenter" Complexité de l’ergonomie" Utilisation de composants hétérogènes" Complexité de conception


!! Le modèle EDIFICE (suite)Le modèle EDIFICE (suite)! Prend également en compte les batches et éditions ...

– Critères d'évaluation de la complexité d'un batch :" Nombre de requêtes" Lecture séquentielle, parallèle ou mécanisme de lotissement" Nombre de classes ou de tables" Niveau de complexité des classes mises en jeu" Nombre classes (tables) mise à jours" Présence d’algorithmes ou de calculs complexes

– Critères d'évaluation de la complexité d'une édition :" Nombre de requêtes" Nombre de classes ou de tables" Niveau de complexité des classes mises en jeu" Présence d’algorithmes ou de calculs complexes" Complexité de formatage de l’état (ruptures multiples, tableaux croisés, …)


!! Le modèle EDIFICELe modèle EDIFICE! � Ainsi que les interfaces avec les systèmes externes

– Critères d'évaluation de la complexité d'une interface :" Niveau de complexité de la classe ou de l'interface (cf. modèle de complexité des classes)" Ecriture ou non de classe équivalente (Concept métier identique mais attributs ou services

manquants)" Nombre de services utilisés" Complexité de réutilisation" Nombre d'écrans à représenter" Nombre de services complémentaires à implémenter


!! DimensionnerDimensionner– Définitions– Modèles de dimensionnement– Le modèle de dimensionnement Edifice– Le processus de dimensionnement– Dimensionnement et cycle de vie Edifice


!! LeLe modèle modèle Edifice Edifice! Principe

– La complexité générale d�une application dépend bien sûr de la complexité desclasses de stocks qui la composent, mais aussi et surtout des du nombre et de lacomplexité des processus qui vont les manipuler (les processus vont eux-mêmesnécessiter la création de classes)

➭ On évalue d�abord la complexité des classes de stocks, sans se préoccuper deleur utilisation dans les processus

➭ On évalue ensuite la complexité des processus (interactifs), des batches, deséditions et des interfaces avec les systèmes externes

Classe = classe métier (classe de stock), conteneur des informations et de la logique de premierniveau (contrôles simples liées à la classe elle-même)Processus = fonctionnalité, point d’entrée de l’application - à ne pas confondre avec processusmétier de l’entreprise (1 processus = N fonctionnalités de l’application)Interface = composant logiciel développé pour assurer la coexistence d’une application avecd’autres applications du SI ou des applications externes au SI


!! Sur quellesSur quelles bases bases évalue évalue-t-on ?-t-on ?

Le résultat de l�étape Analyse préalable / définition des besoins (cahier descharges) :

– Glossaire ou modèle de classes défini lors de la première définition des besoins(cahier des charges)

– Modèle de use cases / Processus– Dossier d�urbanisme (interfaces)


!! LeLe modèle modèle Edifice Edifice! Qu�évalue-t-on ?

– Les charges de fabrication (Analyse, Conception, Développement et Tests unitaires)sont évaluées en fonction des modèles de complexité

– Un taux de pondération est appliqué en fonction du contexte– Les charges transverses sont évaluées par application d�un pourcentage sur la

charge obtenue précédemment (les pourcentages appliqués varient en fonctiondu contexte du projet)

" Charges de pilotage, qualité, gestion des changements" Charges d’intégration et de gestion de configuration" Charges de support : gestion de l’environnement de développement, développement /

adaptation de composants, …Note : ces charges sont externalisées vers les équipes d’architecture dans le cas où leprojet se trouve dans une organisation de type Edifice

" Charges de tests fonctionnels (tests d’intégration)" Charges de prise en compte des retours (corrections) lors des tests


!! Pré-requis, hypothèses du dimensionnementPré-requis, hypothèses du dimensionnement! Le chef de Projet Utilisateurs (CPU) et les représentants utilisateurs sont

identifiés, disponibles et mandatés (pouvoir de décision)

! Les documents d�expression des besoins sont assez détaillés pour pouvoirestimer la complexité des classes et processus

! Une architecture technique et un environnement de développement (outils deconception, développement, composants de base et gestion de configuration,�) sont disponibles, maîtrisées et réutilisables

! les équipes sont formées en totalité et pour la moitié de l �effectif bienexpérimentées


!! Le processus de dimensionnementLe processus de dimensionnement! Calculer la charge de fabrication (Analyse, Conception, Développement,

Tests unitaires) en fonction de la complexitéNotes : on a ajouté un niveau de complexité « très simple » (classes de type « tables de code »)Les charges sont exprimées en jxhLa répartition se fait généralement de manière à peu près égale entre Analyse + conception et Développement + Tests unitaires

Très simple Simple Moyen Complexe Très ComplexeClasses 1 2 4 8 15Processus 1 3 6 12 20Batches 2 5 10 20 30Editions 1 2 5 10 20Interfaces 1 2 4 8 15


!! PondérationPondération! Appliquer les coefficients de pondération sur la charge de fabrication

– Expérience des intervenants– Efficacité de l'outil de développement

" La métrique est valable avec l’utilisation d’un outil de développement intégré genre Forte" Environnement J2EE (HTML, JSP, Java), affecter 1,1 à 1,2

– Nombre de sites de développement" La métrique est valable pour un seul site de développement" Pour 2 à 3 sites de développememt : affecter un coefficient de 1,5

– Taux de réutilisation, maturité des composants" La métrique vaut pour une réutilisation de composants techniques et métier génériques" Si fabrication de composants métier génériques : affecter un coefficient de 1,2 à 1, 3" Si réutilisation de composants métier : affecter un coefficient de 0,9

– Exigences qualité et documentation" On peut être amené à ajouter de 5 à 15 % de charges liées à la constitution de documentations techniques accompagnant

le logiciel livré


!! Charges transversesCharges transverses

! Pilotage, qualité, gestion des changements :

Varie en fonction du contexte : exigences de qualité, relations MOE - MOA, �! Intégration technique, gestion de configuration :

Varie en fonction du contexte : complexité technique, nombre d�interfaces avec lessystèmes externes, �

! Support et architecture technique (éventuellement externalisé à un autre projet) :Varie en fonction de l�architecture disponible, des exigences non fonctionnelles(performances, ergonomie, �)

! Tests fonctionnels (Préparation et exécution) :! Prise en compte des retours (corrections d�anomalies) sur tests fonctionnels, recette et

site pilote


!! Comparaison des techniques de dimensionnementComparaison des techniques de dimensionnement

! Evaluer les points de fonction à partir du nombre de lignes de code (LDC)On soustrait le nombre de lignes de commentaires (environ 30 %)– Cobol : PF = nombre de LDC / 106– C/C++ : PF = nombre de LDC /60– Outil de développement (Forte) : PF = nombre de LDC / 35– SQL : PF = nombre de LDC / 35

! Equivalence Points de Fonction avec Métrique Edifice– Chaque classe métier comprend environ 60 PF si le taux de réutilisation est de 70%

! Equivalence Métrique Edifice et Points de Fonction– Productivité = 2 à 3 PF par jour et par personne


!! ConclusionsConclusions! Privilégier un process itératif normé et supporté par une approche de

réutilisation, çà marche.

! Mettre en place une métrique de projets : on ne progresse que quand onmesure (Lord Kelvin)

– 1ère étape : collecter ses propres résultats de projets– 2ème étape : bâtir les métriques sur vos chiffres

! Privilégier la qualité de vos ressources de projet

! Gérer le périmètre

! Utiliser vos métriques et les amender sur plusieurs années d'expérience (toutspécialement en cas de changement technologique)

Documents

CNAM- 13 Juin 2001 Processus d ’estimation de projet