Séance Estimation des charges

1. Séance Estimation des charges MASTER IPI-NT Le 08/01/2014 Laurent DESCAMPS

2. Estimation des charges 1 – Les notions de base 2 – Pourquoi estimer les charges 3 – Les méthodes … parlons en ! 4 – Un cas pratique … Y’a que ça de vrai

3. 1 - Les notions de base • La charge : c’est une quantité de travailnécessaire à la réalisation d’une tâche (indépendante du nb de personnes) • permet d’obtenir un cout prévisionnel, • s’exprime en jours/homme, mois/homme, année/homme, • permet de définir la taille d’un projet, < 100 jours / homme : petit projet > 1000 mois / homme : grand projet • La durée : c’est une notion de tempsnécessaire à la réalisation du projet. Cette durée dépend du nombre de personnes affectées au projet avec des limites : • une tache de 100 j/h ne peut être réalisée en 1 j par 100 hommes, • La durée dépend du fait que les tâches soient partitionnables ou pas, • La durée dépend également du lien que les différentes taches d’un projet ont entre elles,

4. 1 - Les notions de base

5. 1 - Les notions de base

6. 1 - Les notions de base • La loi de parkinson  • « le travaille se dilate jusqu’à remplir le temps disponible » • « les développements informatiques sont comme les gaz parfaits : ils prennent toute la place qu’on leur donne » • Si l’on donne à une équipe un projet estimé à 50j/h à faire en leur proposant une estimation de 100j/h, le projet sera fait en 100j/h • La loi du marché : la charge correspond au prix à proposer pour remporter l’appel d’offre • Tailler le projet en fonction de ce qu’attend le client, • Ajuster la taille du projet en fonction des offres concurrentes, • Une formule de base permet de définir un délai moyen en fonction de la charge : • Délai en mois = 2,5 * (charge en mois) 1/3 • Cette formule est à adapter en fonction du contexte du projet : le coefficient peut donc varier de 2,0 à 4,0

7. 2 – Pourquoi estimer les charges • Les méthodes d’évaluation des charges aident les responsables métier à apprécier non seulement la charge, mais aussi la quantité de temps nécessaire à la réalisation ainsi que la taille de l’équipe. • En tant que SSII : La charge estimée correspondra au prix à proposer pour remporter l’appel d’offre • En tant que société utilisatrice : La charge estimée correspondra au budget qui vous sera alloué

8. 2 – Quand estimer les charges 1) La fin de l’analyse de faisabilité : on effectue une « pré-estimation » : C’est un moment stratégique puisque que l’estimation sera un des principaux éléments entrant dans la décision de lancer effectivement le projet ou pas. La difficulté d’effectuer une estimation de charges vient du fait qu’on est très en amont dans la vie du projet et les techniques d’estimation basées sur une connaissance fine de la solution seront difficilement applicables. L’utilisation de méthodes fines est à ce moment assez difficile à mettre en œuvre. 2) La finalisation de l’architecture fonctionnelle et technique : on effectue « l’estimation initiale » C’est encore un moment important et où l’on peut grâce à vue cohérente de l’ensemble de la solution ajuster la « pré estimation » et le planning. A partir de ce moment l’utilisation de méthodes plus fines comme les « points de fonctions » devient possible.

9. 2 – Quand estimer les charges 3) La réalisation des spécifications détaillées : on effectue « l’estimation détaillée » C’est le moment où l’on connait le mieux ce que l’on va faire en terme de production (configuration, paramétrage, développement) sans avoir encore engagé une bonne partie de la dépense. C’est un moment idéal dans le cas de travail en mode Centre de service / Centre de développement, pour cadrer le budget et les délais des demandes de travaux. 4) En conclusion Il faut construire une méthode d’estimation suffisamment souple pour être utilisée dès l’analyse de faisabilité sur un niveau d’information encore très général.

10. 2b – Quand estimer les charges

11. 3 – Les méthodes • Estimer les charges, c’est très simple :

12. 3 – Les méthodes • Quelque soit la méthode, on retrouve une démarche générale commune : • S’appuyer sur la base de connaissance de l’entreprise rassemblant l’expertise des projets antérieurs (d’où l’importance des bilans de projets), • Faire une 1ère estimation de la taille du projet à l’aide d’une unité de mesure, • Ajuster les différents ratios (pour définir la taille ou la charge) en fonction de la spécificité du projet • Exemples avec beaucoup de devpt et peu de spécification et peu de recette, • Exemples avec très peu de devpt pour beaucoup de recette et de conception, • Extrapoler et répartir la charge entre les différentes étapes du projet,

13. 3 – Les méthodes

14. 3.1 – La méthode analytique S ’appuie sur la typologie des programmes à développer Affecte un poids par type de programme et niveau de difficulté dans l ’environnement (UNITÉ : jour/homme) La charge obtenue est celle de réalisation Pour les test d ’enchaînement : 10% charge Pour l ’encadrement : 20% charge

15. 3.1 – La méthode analytique

16. 3.1 – La méthode analytique • Charge de réalisation = somme (pi*ti ) • Où p est le poids et t nombre de programmes du type i • Charge globale = 1,3 * Charge de réalisation / 22 (en mois/h) • Pour les projets dont la charge globale est comprise entre 3 et 30 on a une durée incompressible qui peut être définie par : • Durée = 2,5 (Charge globale en mois/h))1/3 en mois

17. 3.2 – La méthode DELPHI • Elaborée en 1948 par la Rand Corporation (une institution américaine à but non lucratif qui a pour objectif d'améliorer la politique et le processus décisionnel par la recherche et l'analyse) • La méthode Delphi consiste à organiser la consultation d’experts, soumis à des vagues successives de questionnement sur un sujet précis pour mettre en évidence les convergences et les consensus (en se basant sur les projets antérieurs). • C’est une technique de facilitation majeure, qui part du principe que l’intelligence du groupe est supérieure à la somme des intelligences individuelles. On affine au fur et à mesure les jugements postés par les différents experts jusqu’à obtention d’une convergence.

18. 3.2 – La méthode DELPHI • La méthode Delphi s’exécute généralement sur 1 ou 2 tours en respectant les étapes suivantes : • Étape 1 : Le modérateur prépare une courte présentation du projet ou demande à un client, un analyste, un chef de produit de présenter sa problématique / son besoin, • Étape 2 : Le modérateur demande les estimations individuelles à 3 experts, • Étape 3 : Chaque expert fait son estimation dans son coin, comme il le souhaite, • Étape 4 : Le modérateur collecte les résultats (anonymes) et calcule la moyenne, • Étape 5 : Le modérateur informe les experts de cette moyenne. Chacun peut alors évaluer sa propre estimation par rapport à cette moyenne. On échange sur les résultats, on argumente … Fin du 1er tour • Étape 6 : Le modérateur demande à nouveau les estimations individuelles aux experts qui livrent encore leur estimation • Étape 7 : Le modérateur collecte à nouveau les résultats et calcule la moyenne • Étape 8 : Le modérateur informe les experts de cette moyenne. Il y a de nouveau discussion … Fin du 2ème tour … • Les consensus s’obtiennent généralement à ce stade… Mais si rien ne se décide, on peut : • soit faire un 3ème tour … • soit appliquer une formule du genre : Estimation finale = (Estimation Optimiste + 4 Estimation Intermédiaire + Estimation Pessimiste) / 6

19. 3.3 – La méthode proportionnelle • 3 types d’utilisation : • Estimer globalement le projet que l’on cherche à répartir dans le temps  démarchedescendante, • Evaluer une étape du projet au moyen d’une autre méthode et généraliser  démarcheascendante, • Pendant le projet : le temps consommé sur les tâches terminées redéfinit les tâches à venir  démarchedynamique, • On applique un ratio sur chaque étape du projet sur la base des charges estimées précédemment • Ces ratios sont issus une fois de plus de l’expérience. Ce sont des recommandations

20. 3.3 – La méthode proportionnelle • Exemple pour des petits projets :

21. 3.3 – La méthode proportionnelle • Exemple pour des projets plus importants :

22. 3.3 – La méthode proportionnelle • Exemple d’une calculette projet

23. 3.4 – La méthode COCOMO • Constructive Cost Model (COCOMO) Boehm 1981 • Deux hypothèses : • Un informaticien évalue mieux la taille du logiciel à développer que la quantité de travail nécessaire, • Il faut toujours le même effort pour écrire un nombre donné de lignes de programme, quel que soit le langage, • L ’unité : l ’instruction source • Le modèle permet d ’obtenir la charge de réalisation en mois/homme et le délai normal recommandé • Formules de calcul : • Charge en mois/homme = a (Kisl)b • Kisl = kilo instruction source testée • Durée normale en mois = c(charge)d

24. 3.4 – La méthode COCOMO • Les paramètres a, b, c et d dépendent de la catégorie du projet. Soit X la taille du logiciel. • Projet simple si : X < 50 Kisl (spécifications stables, petite équipe) • Projet moyen si : 50 Kisl <= X < 300 Kisl (spécifications stables, grande équipe) • Projet complexe : si X > 300 Kisl (spécifications instables, grande équipe)

25. 3.4 – La méthode COCOMO • Il faut tenir compte de facteurs correcteurs : • Les exigences attendues du logiciel (fiabilité, quantité de données manipulées, complexité des algorithmes, temps d’exécution…) • Les caractéristiques de l’environnement technique (stabilité de l’environnement, contrainte de délai … ), • Les caractéristiques de l’équipe projet, • L’environnement du projet lui-même,  Et appliquer les ratios nécessaires • La Démarche en cinq étapes: • Estimation du nombre d ’instructions source, • Calcul de la charge « brute », • Sélection des facteurs correcteurs, • Calcul de la charge nette, • Evaluation de la durée sur la charge nette,

26. 3.4 – La méthode COCOMO Un exemple : • Charge = 3,2 (40)1,05 = 154 mois/homme • Durée normale = 2,5 (154)0,38 = 17 mois • Ce qui donne une taille moyenne de l ’équipe = 154 / 17 = 9 personnes. • Soit un projet visant à développer un logiciel de 40 000 instructions source • C ’est un petit projet par la taille du logiciel.

27. 3.5 – La méthode des points de fonction • La méthode des Points de Fonctions est une méthode destinée à évaluer la taille d’un projet, et ce, indépendamment de la technologie utilisée pour le réaliser. • Son avantage réside principalement dans le fait qu’il est possible d’effectuer une évaluation grâce à cette méthode très en amont dans le projet (en même temps que les spécifications fonctionnelles). • On s'affranchit, de plus, du comptage de lignes de code (comme pour la méthode COCOMO), qui devient d'une fiabilité tout à fait relative en fonction du langage utilisé.

28. 3.5 – La méthode des points de fonction • Les points de fonctions reposaient, à l’origine, sur un calcul basé sur quatre entités (entrée, sortie, interrogation, fichiers), et ce, sans catégorisation de complexité. (Albrecht, 1979) • Depuis le milieu des années 80, avec la normalisation AFNOR, le comptage des points de fonctions se fait sur 5 entités dont on évalue la complexité : • Données internes (GDI) • Relatif à l'aspect statique du Système d'Information. • Groupe de données logiquement liées, ou de groupe de paramètres de contrôle, et identifiables par l'utilisateur. Ces données sont mises à jour et utilisés à l'intérieur de la frontière de l'application. • Données externes (GDE) • Relatif à l'aspect statique du Système d'Information. • Groupe de données logiquement liées, ou groupe de paramètre de contrôle, et identifiables par l'utilisateur. Ces données sont utilisés par l'application, mais mises à jour par une autre application. Le GDE est un GDI dans un autre domaine.

29. 3.5 – La méthode des points de fonction • Entrées (ENT) • Relatif à l'aspect dynamique du Système d'Information. • Ce sont les données, ou les paramètres de contrôle, qui entrent dans l'application considérée. Ces entrées maintiennent un ou plusieurs GDI, initialisent ou contrôlent un traitement, et font l'objet d'un traitement unique. Une Entrée correspond donc à un écran de saisie, ou à une réception de données. Il est à noter qu'à chaque GDI doit correspondre au moins une entrée, permettant sa mise à jour. • Sorties (SOR) • Relatif à l'aspect dynamique du Système d'Information. • Ce sont les données, ou les paramètres de contrôle qui sortent de l'application. Ces sorties sont le résultat d'un traitement unique. (Ce traitement unique doit être différent d'une simple extraction de données). Ce peut être un écran de visualisation, ou un message vers une autre application. • Interrogations (INT) • Relatif à l'aspect dynamique du Système d'Information. • Ce sont des données élémentaires qui correspondent à une extraction de données. • L'INT ne met à jour aucun GDI.

30. 3.5 – La méthode des points de fonction • Tableau de correspondance entre la complexité, le type du composant et le poids : • PFB = Nb de point de fonction brut après calcul

31. 3.5 – La méthode des points de fonction • Le PFB est ensuite ajusté par une appréciation des spécificités du projet. • On défini n facteurs d’ajustement : à chaque facteur est attribué une note de 0 à 5 en fonction du degré d ’influence. • On calcule ensuite le PFA ou nombre ajusté de points de fonction : • PFA = (0,65 * (SOMME (Notei pour i allant de 1 à n)/100) * PFB • Le PFA permet alors de donner le nombre d’instructions source utile pour COCOMO avec la formule : • ISL (lprocédural) = 118, 7 * PFA - 6490. • Dans l’exemple, si PFA = PFB alors ISL = 20811. • Charge = 3,2 (20,8) 1,05 = 77,5 mois/h • Durée = 2,5 (77,5) 0,38 = 13 mois

32. 3.5 – La méthode des points de fonction • Mais on calcule la charge en général en convertissant directement les points. • En fin d ’étude préalable : • 3 j/h par PF (projet moyen) • 2 j/h par PF si petit projet • 4 j/h par PF si grand projet • En fin d ’étude détaillée : 1 à 2 j/h par PF selon l ’environnement • Avec un L4G : 1j/h pour 10 PF en réalisation. • En RAD (productivité élevée) : 0,5 j/h par PF

33. 4 – Un cas pratique