40 Années de Points de fonction: Passé, Présent, Futur

Par Louis Bouillon

Juste 40 il y a des années en Octobre 1979, Dr. Allan Albrecht a proposé pour la première fois une technique de dimensionnement de la fonctionnalité d'un système logiciel. Sa technique a été adoptée, est devenu une norme internationale, et a inspiré plusieurs autres techniques et plus. Cet article montre le passé, présent et (possible) les contributions futures de l'analyse des points de fonction.

Le passé: origines, Motivation et justification

Dans les années 1970, Les lignes de code (LDC) ont été mal utilisés pour les systèmes logiciels de dimensionnement (et sont encore aujourd'hui dans certains domaines fonctionnels tels que les militaires et en temps réel et les systèmes automobiles, Juste pour en nommer quelques-uns) et il a conduit à ce que Capers Jones a qualifié le « paradoxe de la productivité » [1]: écrire plus ne veut pas dire les lettres de crédit être nécessairement plus productif ... le style de programmation, l'expressivité d'une certaine langue de programmation, la règle de comptage des lettres de crédit (physique ou logique, avec / sans lignes ... commentaires) créé une grande variabilité dans le projet (Oui, projet!) estimation. Parce qu'à ce moment-là, nous n'avions mainframes, pas des PC ou des mini-ordinateurs. Ainsi, la (Logiciel) effort de produit pour le déploiement était la plupart des fonctionnalités d'effort global du projet et de logiciels ont été conçus comme le principal résultat d'un projet de logiciel. En conséquence, pendant de nombreuses années (et encore dans de nombreux contrats), Points de fonction (médecins de famille) étaient (et sont) à tort comme prévu « la taille du projet », alors qu'ils expriment seulement le produit taille fonctionnelle. En tous cas, L'objectif de Albrecht était de surmonter la « paradoxe de la productivité » et trouver un moyen de normaliser les calculs de productivité dans une perspective d'affaires [2]. La grande idée était de fonder sa technique sur quelque chose indépendant de la technologie: les processus et les données. Ainsi, un calcul FP (et de produits connexes taille fonctionnelle) dérivé de l'analyse d'un ensemble des besoins des utilisateurs fonctionnels (FUR) est la même en dépit de la technologie et le style d'organisation adopté, tout effort, durée et coût / prix sont, bien sûr, variable selon l'une des éléments. L'exemple typique proposée au cours des années a été de regarder FP comme mètres carrés pour mesurer la « taille » d'un appartement: le nombre de mètres carrés peut être la même pour deux appartements à deux endroits différents, mais le temps pour les construire peut différer (par exemple. un appartement peut être construit avec des briques ou être préfabriqué), ainsi que leurs coûts de production et de la valeur commerciale (un appartement à Manhattan, New York, doit coûter plus cher par mètre carré qu'un autre dans un autre endroit); le coût est pas de valeur.

Le premier document, daté 1979, fondations posées pour un tel objectif, comme indiqué dans son titre (« Développement d'applications de mesure de la productivité »). Il représentait un big-bang pour les estimations, essayant d'entrées / sorties / extrait des requêtes et des données d'une analyse fonctionnelle en particulier parce qu'un tel nouveau numéro aurait pu être dérivé avant la programmation et au plus tard, comme l'a fait avec un nombre de LOC. Puisque vous ne pouvez pas prévoir avec un certain degré de précision le nombre de lettres de crédit de votre équipe produira demain ... trop grande variabilité!

Il y a de nombreux avantages, mais aussi quelques questions en suspens: la corrélation entre l'effort de projet (homme / jour) et le produit taille fonctionnelle (en FP) était pas si élevé, et un facteur d'ajustement de valeur (VAF) a été introduit dans le but d'améliorer une telle relation et la valeur R2 dans une analyse de régression linéaire. VAF a été initialement calculé sur 10 Caractéristiques générales du système (GSCs) avec une variabilité de ± 25% au premier 1979 papier, élargie à 14 CSS dans le document seconde et dernière, daté 1983 [3], avec une variabilité ± 35% sur la valeur FP « non ajustée » initiale. VAF était, donc, la première « taille » de façon indirecte, la contribution des exigences non fonctionnelles (NFR), tant au niveau du produit, ainsi que le niveau du projet. Ce deuxième et dernier d'Allan Albrecht a déclaré la structure finale FPA, diviser le MASTER initial type de fonction de données dans ILF et FEI, et a déclaré le système de pondération finale (comme toujours valide dans la version actuelle IFPUG CPM v4.3.1, daté 2010 [4]) depuis ce temps là. Ainsi, il est possible de comparer -De un point de vue fonctionnel de dimensionnement- un produit logiciel réalisé aujourd'hui avec un autre sorti il ​​y a quelques années à des fins d'analyse comparative.

Dans 1987, IFPUG est né et a tenu dans ses mains la gestion et l'évolution de la technique de Albrecht. Dans les années suivantes, plusieurs techniques se sont éloignés des idées de Albrecht, et quelques-uns sont devenus des normes ISO, comme représenté sur la figure. 1:

figue. 1: Les normes ISO EFM (avec des lignes bleues en pointillés)

figue. 1: Les normes ISO EFM (avec des lignes bleues en pointillés)

Elles sont (par ordre d'apparition): Mark-II (1988), NESMA FPA (1990), FISMA (199X) et COSMIC (1998), avec beaucoup de variantes mineures (ici [5] une liste de certains d'entre eux).

usages premiers de FPA étaient de déterminer la taille fonctionnelle des logiciels à des fins d'estimation et d'analyse comparative et -pour simplifier- comme une unité contractuelle de paiement dans un contrat de TIC.

Dans 1998, ISO a commencé la création d'une famille de normes sous le label « 14143 » avec des principes communs pour la mesure dite de dimensionnement fonctionnelle (États fédérés de Micronésie) méthodes, indiquant de façon claire que ces méthodes dimensionnées un produit (pas un projet) et que lors du déplacement à partir de peaux de produit, qui exclut les versions connexes ISO que les facteurs d'ajustement initialement inclus tels que VAF [6]. La justification? De tels facteurs « ajustement / étalonnage » provenaient de NFR, Ainsi, sont hors de portée d'un procédé EFM. Comme preuve: ISO 20926:2003 était la norme ISO pour IFPUG CPM v4.1 « non ajustés. » Versions 4.x -De 1999 sur- Définitions version raffinée et les concepts de base, en particulier « utilisateur » et « limite ». Version v4.3 (2010) définitivement abandonné VAF du texte normatif (également dans la norme ISO / CEI 20926:2009) et maintenu à des fins historiques à l'annexe C.

Pendant ce temps, depuis FUR et NFR doivent être traités de manière parallèle, le logiciel Processus d'évaluation non-fonctionnelle (CASSER) projet a démarré en 2007, v1.0 libération dans 2011 [7], pour une nouvelle, première mesure dimensionnement non fonctionnelle (NFSM) méthode, qui est passé de la norme ISO sur la qualité du logiciel produit (9126 avant [8], et a évolué dans le courant 25010:2011 la norme [9]) tout en essayant de compléter le dimensionnement fonctionnel autant que possible. figue. 2 aide à déterminer la portée du projet droit, avec trois types d'exigences:

figue. 2: Trois types d'exigences (à partir du schéma « ABC »)

figue. 2: Trois types d'exigences (à partir du schéma « ABC »)

L'information a été écrit de manière différente que CPM v4.1. J'ai clairement dit dans un 2012 papier j'ai écrit pour MetricViews [10], Le schéma « ABC »; cette taxonomie a également été utilisé dans un 2015 papier co-écrit par IFPUG / COSMIC pour mieux exprimer une taxonomie pour NFR [11]. Cette classification est essentielle dès le début de tout projet d'analyse correctement et de les comparer avec une bonne analyse comparative. figue. 3 résume la façon dont une exigence d'utilisateur peut être déployé et divisé, dans le cas plus large, en trois morceaux: Fourrures produit (UNE), NFR produits (B) et les contraintes du projet / exigences (C).

figue. 3: L'ABC du schéma [10]

figue. 3: L'ABC du schéma [10]

De besoins des utilisateurs à l'effort global final du projet et les coûts – Le schéma « ABC » [10] dans 1997 ISBSG (isbsg.org) est né et tous les plus actifs logiciels Associations de mesure (SMAs) adhéré à cette initiative d'analyse comparative. le 2019 Libération [12] comprend plus de 9,000 projets, la plupart du temps en utilisant les méthodes de taille et IFPUG FPA COSMIC. Une autre norme complémentaire était la norme ISO / CEI 14143-5:2004 [13], qui propose des critères pour la définition des « domaines fonctionnels » et permet une comparaison raisonnable entre les systèmes logiciels ayant des caractéristiques similaires et répartition de l'effort par types d'exigences (abc). Il n'a pas de sens de comparer des pommes avec des oranges ...

 

Le présent: Que se passe-t-il?

méthodes EFM sont utilisées dans l'information diffusément & Technologie de communication (TIC) contrats, avec une concentration plus élevée dans certains pays (par exemple. Italie, Brésil, Pologne, Inde), et représentent une base quantitative pour le calibrage du produit et la taille fonctionnelle peut aider à l'analyse comparative pour déterminer ce qui pourrait être (environ) l'effort non fonctionnel dans un projet, comme représenté sur la Fig.4:

figue. 4: Répartition de l'effort par type d'exigence (abc) par domaine fonctionnel: un exemple

figue. 4: Répartition de l'effort par type d'exigence (abc) par domaine fonctionnel: un exemple

Un exemple de répartition de l'effort par type d'exigence (abc) par domaine fonctionnel est divisant ce qui est non-fonctionnelle selon le schéma ABC. Une exigence de type B peut être réalisé et déployé par un spécialiste en informatique (par exemple. un administrateur de base de données, ergonome ...) qui coûte généralement moins d'un autre professionnel (par exemple. un projet / gestionnaire de services, un spécialiste de la mesure, une personne d'assurance qualité ...) la gestion d'une exigence de type C, mais plus d'un professionnel (par exemple. un analyste / programmeur) l'exécution d'une exigence de type A. figue. 5 montre les deux pyramides opposées pour une distribution typique de l'effort de projet par type d'exigence et le coût par homme / jour pour chaque type de professionnel [14].

figue. 5: Répartition de l'effort par type d'exigence et coût / homme-jour (selon le schéma ABC)

Répartition de l'effort par type d'exigence et coût / homme-jour (selon le schéma ABC). Encore, les enseignements tirés de 40 années d'expérience ont permis de mieux définir (et d'affiner) principes et règles concernant le champ d'application de FPA. Le schéma « 123 » est une autre classification [15] pour avoir déclaré quel type d'exigences peut être présent dans une certaine phase d'un projet (1: dev, 2: Ops, 3: svc, Entretien).

figue. 6: Le schéma « 123 » conjointement avec le schéma « ABC »

Ainsi, dans la phase de la FPO un logiciel est utilisé, pas produit / changé, et génère un nombre « zéro FP », ainsi que lorsqu'une demande de changement ne comprendra que les exigences de type B (par exemple. pour une maintenance corrective / perfective, comme indiqué dans la norme ISO / CEI 14764:2006 la norme [16], également cité dans CPM v4.3.1 – partie 3, chapitre 4, pages 20-21). Même si des définitions et des critères sur ce FUR ou NFR a été créé, expliqué et diffusé au fil du temps, il y a encore une dette culturelle dans les pratiques contractuelles et les entreprises à utiliser au moins une unité de mesure (UdM) pour le dimensionnement des exigences de type A (médecins de famille, quels qu'ils soient) en collaboration avec l'unité de mesure pour le dimensionnement des exigences de type B (par exemple. avec des points IFPUG SNAP ou des mesures de l'ISO / CEI 25023 [17], ainsi que les activités de type C qui complètent les possibilités d'estimer l'ensemble des efforts nécessaires à la portée d'un projet. Seulement lors du dimensionnement à toutes les exigences pour les trois (abc) les types, il est possible de réduire le « glissement de portée,» Alors qu'il ya encore une idée fausse historique sur ce qu'est une taille FP et ce qu'il ne. Mais il suffirait de savoir dans une méthode EFM, qui sont ses composantes de base fonctionnels (BFC) pour inclure (ou pas) une telle activité ou les activités.

Enfin et surtout, FP et de l'automatisation. Dr. Albrecht a créé une « mesure de conception » pour permettre une estimation dans les premières phases d'un cycle de vie. Certains outils aujourd'hui, après 40 années, dériverait médecins de famille (quels qu'ils soient) l'analyse syntaxique du code logiciel ou de travailler sur certaines formes de notations FOURRURE. Certains (bon sens) observations et réflexions: l'automatisation est utile si elle est respectueuse des quatre critères: plus rapide, plus précise, plus rapide et moins coûteux. Si nous avons besoin de la taille d'une nouvelle FOURRURE, un code d'analyse syntaxique de l'outil (comme indiqué dans la nouvelle norme ISO 19515 FP standard sur automatisé [18]) serait inutile et coûteuse. Ou, à l'aide d'un outil en supposant des notations UML comme entrées impliquerait plus d'heures (et les coûts connexes) pour traduire une exigence écrite sur la base humaine dans un format méta-langage. Également, une organisation doit analyser soigneusement le retour sur investissement pour un tel choix(s) selon les quatre critères mentionnés ci-dessus. créer rapidement un projet de base dans lequel le temps et l'effort sont des atouts essentiels pourraient être ok sous les conditions qu'il est vérifiée par un CFPS humain et que l'unité de mesure sous la portée sont les mêmes. Autrement, l'automatisation pourrait devenir risquée ou difficile à gérer.

 

L'avenir: Que pouvons-nous attendre?

Comme beaucoup de gens diraient, l'avenir est maintenant ... mais que peut-on attendre de FPA dans un proche avenir? FPA a des bases solides et il est indépendant de la technologie; ce que nous avons appris du passé est que les prochaines étapes devraient être:

  • Une meilleure qualité et plus abordables des besoins des utilisateurs (UR) la gestion, la portée et de la mesure au cours des premières phases d'un projet: tel est l'objectif principal et primaire qui devrait être atteint.
  • Adoption de FPA aux nouvelles technologies, grâce à l'interprétation correcte des règles de base de FPA 1979/84. Nous ne pouvons pas encore mesurer et la taille grâce à de nouvelles technologies FPA telles que le cloud computing [19], Internet des objets (IdO) [20], l'intelligence artificielle et toute nouvelle technologie les années à venir nous apporter.

Notre meilleur pari est de ne pas inventer quelque chose de nouveau, mais d'analyser en profondeur nos processus actuels et des données afin de déterminer des façons nouvelles et différentes de concevoir un système logiciel et la taille encore FUR avec FPA!

Nous avons l'intention de continuer à utiliser et à améliorer la fonction valeur la mesure.” (Allan Albrecht, octobre 1979)

 

Références

  1. Jones, C., Quels sont les points de fonction? site SPR, URL: http://tiny.cc/tgur7y
  2. Albrecht A. J., “la productivité du développement d'applications de mesure” dans Proc. joint SHARE, GUIDER, et le développement d'applications IBM , 1979, pp. 83-92. http://tiny.cc/2ywacz
  3. Albrecht A. J. & Gaffney J. E., “fonction logicielle, des lignes de source de code, et la prévision de l'effort de développement: Une validation scientifique du logiciel,” IEEE Trans. Software Eng., vol. 9, non. 6, novembre 1983, pp. 639-647. http://tiny.cc/1zwacz
  4. IFPUG, Fonction point Manuel pratique de comptage (CPM), Libération 4.3.1, janvier 2010, URL: ifpug.org
  5. Lother M., Dumke R., Points-Metrics: Les comparaisons et l'analyse », dans: Tendances actuelles dans la mesure du logiciel, Publication shaker, 2001, pp.228-267
  6. ISO / CEI, Standard international 14143-1 – Informatique – Mesure du logiciel – Mesure de la taille fonctionnelle – Partie 1: définition des concepts, février 2007
  7. IFPUG, Logiciel Processus d'évaluation non-fonctionnelle (CASSER) Manuel pratique d'évaluation (APM), version 1.0, septembre 2011, URL: ifpug.org
  8. ISO / CEI, EST 9126-1:2001 – Génie logiciel – La qualité des produits – Partie 1: Modèle de qualité, Organisation internationale de normalisation, 2001
  9. ISO / CEI, EST 25010:2011 -Systèmes et logiciels d'ingénierie-systèmes et des logiciels Exigences et évaluation de la qualité (Carré)-modèles de qualité système et logiciels, Organisation internationale de normalisation, Mars 2011
  10. Bouillon L., La prochaine étape: Mesure et évaluation de la productivité non fonctionnel, MetricViews, août 2012, URL:https://www.ifpug.org/Metric%20Views/MVBuglione.pdf
  11. COSMIC / IFPUG, Glossaire des termes pour les exigences non fonctionnelles et les exigences du projet utilisé pour la mesure du logiciel de performance du projet, l'étalonnage et l'estimation, v1.0, septembre 2015
  12. ISBSG, ré&E (Développement & Renforcement) dépôt, R2019, URL:isbsg.org
  13. ISO / CEI, Rapport technique 14143-5 – Informatique – Mesure du logiciel – Mesure de la taille fonctionnelle – Partie 5: détermination des domaines fonctionnels pour une utilisation avec une mesure de la taille fonctionnelle, 2004 (R2019)
  14. Bouillon L., Comment gérer des projets uniformes et mesurables: mettre l'accent sur les types et les exigences, ZeroUnoWeb, Peut 3 2019, URL: http://tiny.cc/y1tr7y
  15. Bouillon L., Interprétez DevOps pour mesurer le bien (et le meilleur) projets, PMExpo2017, Présentation, octobre 2017, URL:https://www.pmexpo.it/2017/programma/009tk
  16. ISO / CEI, Standard international 14764:2006 - Génie Logiciel - Logiciel Processus du cycle de vie – Entretien, 2006
  17. ISO / CEI, Standard international 25023:2016 – Ingénierie des systèmes et logiciels – Systèmes et logiciels Exigences de qualité et évaluation (Carré) – Mesure du système et la qualité des produits logiciels, juin 2016
  18. ISO / CEI, Standard international 19515:2019 – Informatique – Object Management Group Points de fonction automatisés (AFP), 1.0, Peut 2019
  19. Woodward S., Fonction point Analyse Précise dans un monde nuageux, Metricas 2012, Sao Paulo (Brésil), nov 28-29 2012, URL:http://www.bfpug.com.br/metricas2012/woodward.pdf
  20. Cagley T., Points de fonction et IOT, ou comment ma cuisine épie On Me!, IFPUG ISMA17, Bangalore (Inde), Mars 8, 2019

A propos de l'auteur

Luigi Buglione est le directeur IFPUG pour la conférence / Education et Président de la Gruppo Utenti Fonction point Italia – Association Metrics Software italien (GUFPI-ISMA) (www.gufpi-isma.org). Il travaille en tant que spécialiste de l'amélioration mesure et processus au génie Ing. Inf. SpA à Rome, Italy and Associate Professor at the École de Technologie Supérieure (ETS) – Université du Québec, Canada. Il a obtenu plusieurs certifications, y compris IFPUG CFPS, CSP, CSMS, et CCFL COSMIC au sujet du logiciel de mesure. Il est un conférencier régulier lors de conférences internationales sur Sw / Mesure de service, Amélioration des processus et de la qualité et est activement des associations techniques nationales et internationales sur ces questions. Il a reçu un doctorat. MIS et un cum laude degré en économie. Luigi peut être atteint à luigi.buglione@eng.it.

Tu pourrais aussi aimer...