Estimation par analyse de points de fonctions GEF492A 2014 Référence: [ HvV § 7.1.4 ]

1. Estimation par analyse de points de fonctions GEF492A 2014Référence: [HvV§7.1.4] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie informatique Vincent.roberge@rmc.ca roberge.segfaults.net PPL10-APF.pdf

2. Aperçu • Le paradoxe de la productivité (revisité) • Mesurer en comptant les points de fonctions • Identifier les différents types de fonctions d’affaires • Facteurs de complexité • Le retour de feu • Autres systèmes de comptage à point de fonction GEF492

3. Comment est-ce qu’on peut mesurer le code? • Considérons les lignes de code (LDC) comme mesure • Productivité: • "Le nombre d’articles produit par unité de travail ou de dépense" • Est-ce que l’utilisation d’un langage de programmation de niveau plus élevé augmente la productivité? GEF492

4. Examinez cette estimation: ACTIVITÉ CAS A CAS B ASSEMBLER FORTRAN (10,000 LDC) (3,000 LDC) DIFFÉRENCE -------------- -------------- -------------- Besoins 2 Mois 2 Mois 0 Conception 3 Mois 3 Mois 0 Codage 10 Mois 3 Mois - 7 Intégration/Testage 5 Mois 3 Mois - 2 Documentation 2 Mois 2 Mois 0 Gestion et soutien 3 Mois 2 Mois - 1 -------------- -------------- -------------- Total 25 Mois 15 Mois - 10 -------------- -------------- -------------- Prix total 125,000 $ 75,000 $ - 50,000 $ Prix par ligne de code 12.50 $ 25.00 $ + 12.50 $ Lignes par Personne par mois 400 200 - 200 GEF492

5. Le paradoxe de productivité du logiciel • Le logiciel comprend un bon nombre d’activités qui se comportent comme des coûts inélastiques (fixes) qui ne sont pas associés au codage • analyse de besoins • rédaction de spécifications (analyse / design) • création de documents pour utilisateurs • planification et gestion de projets • gestion de la configuration / contrôle des changements • Augmenter l’efficacité de la génération de code augmente le coût par ligne de code! GEF492

6. Une autre mesure • En 1976 A.J. Albrecht de IBM stipule que la mesure de grandeur d’un logiciel doit être valide pour n’importe quel projet et n’importe quel langage de programmation — et que cette mesure doit représenter un sujet d’intérêt à l’utilisateur du logiciel. • On mesure donc la fonctionnalité du logiciel en considérant • les aspects externes qui sont visibles aux utilisateurs • la fonctionnalité demandée par les utilisateurs GEF492

7. Fonctions d’affaires • Les aspects de la fonctionnalité (aspects externes) visibles aux utilisateurs sont • les entrées au programme d’application (entrée) • les sorties du programme d’application (sortie) • les demandes de renseignements faites par les utilisateurs (demande) • les fichiers de données qui sont mis à jour par le programme d’application (fichiers) • les interfaces aux autres programmes d’application (interfaces) GEF492

8. Pondération des fonctions d'affaires • On a trouvé une pondération relative des cinq types de fonctions d'affaires • Par exemple, si on établit une fonction de chaque type: POINTS DE PONDÉRATION FONCTION 1 ENTRÉE X 4 = 4 1 SORTIE X 5 = 5 1 DEMANDE X 4 = 4 1 FICHIER X 10 = 10 1 INTERFACE X 7 = 7 ---- TOTAL NON CORRIGE 30 INDICE DE COMPLEXITÉ - POINTS DE FONCTION CORRIGÉS 30 GEF492

9. Examinez cette estimation ACTIVITÉ CASE A CASE B ASSEMBLER FORTRAN (30 PDF) (30 PDF) DIFFÉRENCE -------------- -------------- -------------- Besoins 2 Mois 2 Mois 0 Conception 3 Mois 3 Mois 0 Codage 10 Mois 3 Mois - 7 Intégration/Testage 5 Mois 3 Mois - 2 Documentation 2 Mois 2 Mois 0 Gestion et soutien 3 Mois 2 Mois - 1 -------------- -------------- -------------- Total 25 Mois 15 Mois - 10 -------------- -------------- -------------- Prix total 125,000 $ 75,000 $ - 50,000 $ Prix par PDF 4,167 $ 2,500 $ - 1,667 $ PDF/personne par mois 1.2 2.0 + 0.8 GEF492

10. On compte seulement les fonctions d'affaires "approuvées" avantageuses pour les utilisateurs On ne compte pas les fonctions internes du système les fichiers temporaires les caractéristiques venant d’une conception particulière Comment trouver les fonctions d’affaires GEF492

11. Entrées (Inputs) - ITs Sorties (Outputs) - OTs Demandes (Inquiries) - QTs Fichiers internes (InternalFiles) - FTs Interfaces externes (External Interfaces) - ETs Les 5 types de fonctions GEF492

12. Comptez les fonctions d’affaires identifiez les fonctions d’affaires classifiez les fonctions identifiées Corrigez le total brut en considérant les caractéristiques d’application Comment compter GEF492

13. Chaque donnée utilisateur ou sortie de contrôle unique c.’est à dire, les données qui sortent du système "unique" veut dire que la donnée à un format différent des autres, ou a le même format, mais requière traitement différent Exemple 1: pour un rapport qui doit être fait chaque jour, chaque semaine, et chaque mois, avec une version GUI et une version imprimée, on compte six sorties différentes Exemple 2: présenter un tableau de données sur un écran et un sommaire du tableau au bas de l’écran représente deux sorties différentes Par exemple: identifier les sorties (OT) GEF492

14. Identifier les autres types de fonctions • Entrées (IT) • entrées uniques de l'utilisateur qui changent les structures de données du système • mêmes règles de compte que pour OT • Demandes (QT) • entrées uniques de l'utilisateur qui contrôle l'exécution du programme, sans changer les structures de données • Fichier interne (FT) • Fichier de données interne généré par le système, et maintenu par celui-ci • n'inclue pas les fichiers temporaires • Interfaces externes (ET) • données en entrée, sortie ou partagée avec autres applications GEF492

15. Comment trouver les fonctions d'affaires utilisateur Transactions Entrée Sortie Demande Application A Application B Interface Interface A Fichier B Fichiers Interface partagée Sortie Transactions Entrée Transactions Demande GEF492

16. Règles de compte pour UFP • UFP = 4IT + 5OT + 4QT + 10FT + 7ET est applicable en situations nominales • les poids peuvent être ajustés selon la complexité des types de filières GEF492 Exemple

17. Complexité – Eg. Règles pour IT • Chaque type d'entrée a 0 ou plus d'éléments de données, et fait référence à 0 ou plus fichiers (File Type Referenced) • La complexité augmente avec le nombre d'éléments de données et le nombre de types référencés GEF492 Exemple

18. Complexité – Eg. Règles pour OT/QT • Chaque type d'entrée a 0 ou plus d'éléments de données, et fait référence à 0 ou plus d'autres types (FTR) • La complexité augmente avec le nombre d'éléments de données et le nombre de types référencés GEF492 Exemple

19. Complexité – Eg. Règles pour FT/ET • Pour les fichiers internes (FT) et les interfaces externes (ET), on compte le nombre de groupements de données distincts (Record Element Types) Exemple GEF492

20. Points de Fonction Brut (non-corrigé) • Le compte de points de fonction brut mesure la fonctionnalité requise par le système • c’est-à-dire la "grandeur" du système en matière de fonctionnalité • Ce n’est pas une mesure directe de l’effort nécessaire à l’élaboration du système • mais l’effort est un facteur important pour déterminer la grandeur • Le compte ne considère pas qui va élaborer le système ou les conditions d’élaboration GEF492

21. Les points de fonction corrigés • Si l'on imagine qu’on travaille toujours avec une équipe nominale sous conditions nominales, les points de fonction peuvent servir comme mesure d’effort. • Mais les équipes et les projets sont rarement nominaux • On peut donc corriger le compte des points de fonction pour prendre en considération les conditions uniques de nos projets GEF492

22. Les caractéristiques d’application • Facteurs de production environnementaux • Communication de données • Données et traitement distribué • Objectifs de performance • Configuration à grand usage • Taux transactionnel • Entrée de donnée en ligne • Efficacité de l’utilisateur • Mise à jour en ligne • Traitement complexe • Réutilisation • Facilité de conversion et d’installation • Facilité d’opération • Utilisation à site multiple • Rends les changements faciles GEF492

23. Caractéristiques générales d’application • On ne compte que les facteurs spécifiquement approuvés par l’utilisateur • On ne compte que les facteurs qui influencent significativement le design, le développement, l’implémentation ou le support à l’application • Chaque facteur reçoit un quotte de 0-5 • Degré d’influence total (DIT): 0-70 • DIT normal: 35 GEF492

24. Utilisation du facteur d’ajustement • Utilisez la formule suivante: fpadj= fpraw (0.65 + .01 TDI) • où fpraw est le nombre de points de fonction bruts • et fpadj est le nombre de points de fonction corrigés • Les points de fonction corrigés sont une mesure de l’effort équivalent pour un projet spécifique • c.-à-d. que les points de fonction corrigés ne donnent pas nécessairement la grandeur du projet GEF492

25. Quand peut-on compter? • Dans la planification initiale du projet? • Pendant la spécification des besoins? • Après la spécification des besoins? • Après le design? • Après livraison? GEF492

26. Avis de non-responsabilité • Les systèmes de compte de points de fonction véritables sont compliqués • Ils requièrent des guides de points de fonctions et des techniques bien définies • Pour un véritable système de comptable de points de fonction référez-vous à • The International Function Points Users Group (www.ifpug.org) GEF492

27. Quelle est donc la grandeur de notre projet en LDC?? • Des tables furent créées pour indiquer combien d’énoncés de code sont requis pour implémenter un point de fonction • Il va sans dire que ce chiffre varie selon le langage • Est-ce une bonne idée? • Certains praticiens croient qu’il n’est jamais bonne idée d’utiliser les LDC et décourage cette traduction • Pouvoir estimer la grandeur du projet en LDC peut parfois être utile tout de même GEF492

28. Traduction de LDC à PF GEF492

29. Retour de flamme • Il devrait être possible de deviner combien de points de fonction sont implémentés selon le nombre de lignes de code • En anglais, on utilise le terme Back Firing • Par exemple, si une application contient 105,000 lignes de COBOL, ces tableaux vous porteraient à croire que le système contient 1,000 points de fonction • Mais… cette approche peut impliquer qu’une conception implémentée avec du code superflu ressemble à un produit riche en fonctionnalité • Est-ce que l'estimation obtenue par retour de flamme est brute ou ajustée? Difficile à dire sans connaître les facteurs d'équipes. GEF492

30. Autres systèmes de comptage • Points d’éléments (Feature Points) • contrôle de processus en temps réel, optimisation mathématique et systèmes embarqués • ajoutent une fonction d’affaires algorithmique au modèle de base et modifient les poids • Mk II Function Points • 3D Function Points • Real Function Points • Object Points GEF492

31. Références supplémentaires • Alexander,How to DetermineYour Software Application Size usingFunction Point Analysis,http://www.devdaily.com/FunctionPoints/ • Boehm, Ray, Function Point FAQ, Software Composition Technologies, Inc., 1997,http://www.royceedwards.com/floating_function_point_faq/resources.htm • Introduction To Function Point Analysis http://www.softwaremetrics.com/fpafund.htm GEF492

32. Prochaine séance: L’estimation de l’effort avec COCOMO II GEF492