Annonce de nouvelles IFPUG
Maintenant que l'IFPUG a publié Citation #3, les utilisateurs de la méthode IFPUG ont désormais officiellement le feu vert pour utiliser des méthodes d'estimation de taille qui peuvent être utilisées plus tôt dans le cycle de vie du projet logiciel que le moment d'une conception fonctionnelle terminée. Dans uTip #3 les méthodes High Level FPA (Dans Nesma, souvent appelé « FPA global » ou « FPA estimé ») et le FPA indicatif sont décrits. Ce sont en effet des méthodes très utiles pour estimer la taille d'une application (ou projet) et de nombreuses organisations commerciales et gouvernements du monde entier utilisent ces méthodes depuis de nombreuses années. En réalité, dans la pratique, la documentation fonctionnelle est très rarement complète et suffisamment détaillée pour effectuer un FPA détaillé aussi tôt dans le cycle de vie du projet logiciel que nécessaire pour estimer le projet. C'est en fait un argument avancé par de nombreux chefs de projet pour ne pas utiliser FPA, car ils supposent à tort qu'une mesure FPA ne peut être effectuée que sur une conception fonctionnelle complète, qui est trop tard dans le cycle de vie du projet pour leur être utile à des fins d'estimation.
Surtout avec l'industrie qui s'éloigne des méthodologies de développement traditionnelles vers des méthodologies plus agiles, une documentation fonctionnelle suffisamment complète et détaillée pour réaliser un ACP détaillé devient de plus en plus rare, on n'a donc pas d'autre choix que d'adopter une méthode estimée pour pouvoir mesurer/estimer la taille fonctionnelle.
Bien sûr, avec toute estimation de quoi que ce soit… on devrait se demander quelle serait la précision de l'estimation et quelle est l'incertitude qui est introduite à cause de l'estimation. La bonne nouvelle est qu'il y a eu des études publiées dans lesquelles la précision de la méthode FPA de haut niveau et de la méthode indicative par rapport à une FPA détaillée a été étudiée.. Chez Sogeti Pays-Bas par exemple, le département, Estimation & Contrôler (SECONDE) présenté un papier sur le Software Measurement European Forum à Rome (Italie), en juin 2009, dans laquelle le la perte de précision et les économies d'effort sur l'utilisation du FPA de haut niveau et du FPA indicatif de 42 projets ont été étudiés par rapport aux mesures FPA détaillées.
Bien que la méthode Nesma ait été utilisée pour cette étude, les résultats de cette étude devraient également être comparables à la méthode IFPUG, comme il y a très peu de différences entre les deux méthodes en pratique de nos jours.
le papier, y compris les données de mesure, est disponible sur le Des articles page. Les principales conclusions de l'étude sont présentées dans le tableau ci-dessous:
| Méthode | Précision | Perte de précision | Effort | Gain d'effort |
|---|---|---|---|---|
| Moyenne | Moyenne | |||
| Détaillé | 100% | 100 heures normales | ||
| Haut niveau* | 98.5% | 1.5% | 67 heures normales | 33% |
| Indicatif | 83.5% | 16.5% | 18 heures normales | 82% |
* Le FPA de haut niveau est également appelé « FPA global » ou « FPA estimé » dans la méthode Nesma.
Il s'avère que l'utilisation de la méthode FPA de haut niveau n'entraîne en moyenne que 1,5% perte de précision, ce qui n'est généralement pas vraiment un gros problème au début du cycle de vie du projet logiciel. La méthode indicative est en moyenne un peu moins précise, mais comme cette méthode peut être utilisée encore plus tôt dans le cycle de vie du projet logiciel (lorsque seul le nombre de fichiers logiques est connu ou peut être déterminé), cette méthode est très utile pour créer un premier « ordre de grandeur approximatif » (ROM)’ estimation de la taille fonctionnelle attendue.
La colonne des heures d'effort affiche les heures normalisées au lieu des heures réelles. Cela signifie que la méthode estimée prend en moyenne 67% du temps de mesure par rapport à une mesure FPA détaillée. La méthode FPA indicative prend en moyenne 18% de l'effort d'une mesure FPA détaillée.
À propos des auteurs
Harold Heeringen, Edwin van Gorp et Theo Prins sont consultants en métriques logicielles / ingénieurs en coût logiciel pour Sogeti Nederland B.V.. Ils publient régulièrement dans des conférences internationales sur les aspects pratiques de la mesure logicielle. La plupart de leurs articles se trouvent sur Des articles page.
Quel pourcentage de vos analyses PF utilise la méthode détaillée? Faites-nous savoir sur le forum.
Harold et Théo: Merci d'avoir posté ceci.
J'utilise la méthode FPA légère depuis dix ans pour plusieurs raisons:
– Les premières estimations nécessitent une vue d'ensemble de la taille fonctionnelle. Une analyse fp détaillée conduirait à croire qu'il y a de la précision là où il ne peut y en avoir.
– Même dans une analyse de base, mes clients ne peuvent souvent pas donner un aperçu détaillé de la mise en œuvre d'attributs uniques. Manque de documentation, manque de connaissances, manque de rien…. les raisons sont multiples.
– Je propose généralement des devis à prix fixe, donc d'être rentable, l'analyse de haut niveau est le meilleur choix.
– Je ne veux pas ennuyer le public. Les clients sont assez satisfaits lorsque je termine une énorme application SAP dans 2 jours (“Nous avons toujours pensé que cela prendrait des semaines, … comment se fait-il que l'estimation ne prenne que 2 jours….”). Et ne voulons-nous pas tous des clients heureux?
Seulement à une occasion, j'ai presque commencé à transpirer: J'avais formé des personnes d'une grande entreprise de télécommunications à l'analyse light-FPA. Nous avions compté le volume des résultats de développement de l'organisation sur 12 mois. Après avoir rapporté les résultats fp, la direction n'a pas osé faire confiance ni à moi ni à son propre personnel, qui sait? Alors ils ont volé dans une autre société de métrique (ils les font toujours venir de loin, en espérant que cela le rende plus efficace) refaire toute l'analyse avec la méthode IFPUG détaillée.
Vous devinez ce qui s'est passé alors, n'est-ce pas? Ils ont trouvé moins de 1% écart entre notre analyse légère et leur analyse détaillée!
Je pense que le gain d'effort signalé est plutôt conservateur et peut dépendre de vos normes de déclaration. Dans sa comparaison (2 semaines contre 2 jours) Eva montre un gain d'effort de 80% pour une analyse de haut niveau. Mon expérience est similaire: une analyse de haut niveau est au moins 4 fois plus rapide qu'une analyse détaillée.
À la conférence sur la confiance en informatique (Tokyo, octobre 2014), Une présentation a été donnée par des chercheurs japonais qui ont attribué à la méthode Nesma High Level FPA la responsabilité de l'intérêt accru pour l'utilisation du dimensionnement fonctionnel dans l'industrie japonaise.. J'essaie d'avoir la présentation, mais il y a déjà un court article disponible, également via ISBSG slideshare: http://www.slideshare.net/ISBSG/matsumoto-towards-an-early-software-effort-estimation-based-on-the-nesma-method-estimated-fp
J'ai été très surpris d'apprendre que l'IFPUG a annoncé FPA uTIP # 3 'Early FPA'. Sur plus de 10 l'analyse estimée de NESMA’ (qui est identique à l'analyse de haut niveau) est une pratique courante sur la scène néerlandaise du conseil en métrique.
Les tableaux du blog montrent sans ambiguïté qu'il n'y a qu'une légère différence de taille entre l'analyse détaillée et l'analyse estimée. On peut donc en conclure que la précision du "haut niveau’ l'analyse est presque aussi bonne qu'une analyse détaillée, avec un gain d'effort considérable.
À mon avis, le véritable avantage est que le "haut niveau’ Le FPA peut être appliqué à des spécifications plus grossières, donc plus tôt dans le projet. Dans ma pratique, cela signifie qu'une estimation de taille et une estimation de projet assez précises peuvent être rapidement fournies à la fin de l'analyse des besoins. (et avant la conception détaillée). Je suis très curieux de l''estimation cohérente des coûts’ de l'IFPUG.
Merci pour ce message; c'est assez utile. Nous avons utilisé Quick FPA dans de nombreuses situations, et l'exactitude de l'estimation est toujours débattue. Cette analyse serait utile!