40 Jaren van Functiepunten: Verleden, Aanwezig, Toekomst

Door Louis Bouillon

Net 40 jaar geleden in oktober 1979, Dr. Allan Albrecht voorgesteld voor de eerste keer een techniek voor de dimensionering van de functionaliteit van een softwaresysteem. Zijn techniek is aangenomen, werd een internationale standaard, geïnspireerd en diverse andere technieken en. Dit document toont het verleden, heden en (mogelijk) future contributions of Function Point Analysis.

Het verleden: Origins, Motivatie en Achtergrond

In de jaren zeventig, Lines of Code (LOC) werden onjuist gebruikt voor de dimensionering van softwaresystemen (en nog steeds zijn vandaag in een aantal functionele domeinen, zoals de militaire en real-time en autosystemen, om er een paar te noemen) en het leidde tot wat Capers Jones bestempeld als de “productiviteit paradox” ^[1]: het schrijven van meer LOC betekent niet per se productiever te zijn ... de programmering stijl, de expressiviteit van een bepaalde programmeertaal, de regels voor het tellen van LOC (fysieke of logische, met / zonder commentaar regels ...) creëerde een enorme variatie in project (Ja, project!) schatting. Omdat op dat moment, we hadden alleen mainframes, geen PC's of mini-computers. Dus, de (software) product inspanning voor de implementatie was het grootste deel van het totale project inspanning en software functionaliteiten waren bedoeld als de belangrijkste te leveren van een software project. Bijgevolg, voor vele jaren (en nog steeds in veel contracten), Function Points (KP) waren (en zijn) ten onrechte bedoeld als de “omvang van de projecten”, terwijl ze alleen maar het product functionele omvang te uiten. Hoe dan ook, Albrecht's doel was om de “productiviteit paradox” te overwinnen en een manier vinden om de productiviteit berekeningen vanuit een zakelijk perspectief te normaliseren ^[2]. Het grote idee was om zijn techniek op iets baseren technologie-onafhankelijke: alsmede gegevens. Dus, FP berekening (en aanverwante producten functionele omvang) afgeleid uit de analyse van een set van Functional User Requirements (FURS) is hetzelfde, ondanks de technologische en organisatorische stijl goedgekeurd, terwijl inspanning, duur en de kosten / prijs zijn, natuurlijk, variabel afhankelijk van dergelijke elementen. De afgelopen jaren voorgestelde voorbeeld was om te kijken naar KP vierkante meter voor het meten van de “grootte” van een vlakke: Het aantal vierkante meters kunnen dezelfde twee flats op twee verschillende plaatsen, maar de tijd om ze te bouwen kunnen verschillen (bv. een vlak kan worden gebouwd met stenen of geprefabriceerd), evenals hun productiekosten en commerciële waarde (een flat in Manhattan, New York, zullen meer per vierkante meter kosten dan een ander in een andere plaats); cost is not value.

De eerste paper, verouderd 1979, poseerde basis voor een dergelijk doel, zoals vermeld in de titel (“Het meten van applicatie-ontwikkeling van de productiviteit”). Het vertegenwoordigde een big-bang voor schattingen, proberen fragment in- / uitgangen / vragen en gegevens van een functionele analyse met name omdat zij een nieuw nummer kon worden afgeleid voor programmering en uiterlijk, net als met een LOC count. Omdat je niet kan voorzien met een zekere mate van precisie het aantal LOC zal uw team morgen produceren ... te veel variabiliteit!

Er zijn veel voordelen, maar ook een aantal openstaande punten: de correlatie tussen het project inspanning (man dagen) en het product functionele omvang (in FP) was niet zo hoog, en een Value Factor Adjustment (VAF) werd geïntroduceerd om dergelijke relatie en R2 waarde in een lineaire regressieanalyse verbeteren. VAF werd aanvankelijk berekend op 10 Algemene systeemkenmerken (GSCs) met een variatie van ± 25% in het eerste 1979 papier, uitvergroot 14 GSC in de tweede en scriptie, verouderd 1983 ^[3], met een ± 35% variatie van de oorspronkelijke “gecorrigeerde” FP value. VAF was, daarom, De eerste manier om indirect “grootte” van de bijdrage van niet-functionele vereisten (NFRs), zowel op het product, alsmede het niveau van projecten. Deze tweede en laatste papier uit Allan Albrecht aldus de uiteindelijke structuur FPA, splitsen van de oorspronkelijke MASTER DATA functietype in ILF en EIF, en verklaarde het uiteindelijke gewichtenregeling (als nog steeds geldig in de huidige IFPUG CPM v4.3.1 versie, verouderd 2010 ^[4]) vanaf dat moment. Dus, is het mogelijk om te vergelijken -van een functioneel sizing gezichtspunt- a software product realized today with another one released years ago for benchmarking purposes.

In 1987, IFPUG werd geboren en hield in zijn handen het beheer en de ontwikkeling van de techniek Albrecht's. In de komende jaren, verschillende technieken afgestapt van ideeën Albrecht's, en slechts een paar werd ISO-normen, zoals getoond in Fig. 1:

vijg. 1: ISO FSM Standards (met gestippelde lijnen blauwe)

Zij zijn (in volgorde van verschijning): Mark-II (1988), NESMA FPA (1990), FISMA (199X) en kosmische (1998), met veel kleine varianten (hier ^[5] een lijst van enkele van hen).

Eerste gebruiken van FPA waren aan de functionele omvang van software producten te bepalen voor de raming en benchmarking doeleinden en -to vereenvoudigen- as a contractual unit for payment in an ICT contract.

In 1998, ISO begonnen met de oprichting van een familie van normen in het kader van de “14143” label met gemeenschappelijke beginselen voor de zogenaamde Functional Sizing Meten (FSM) methoden, waarin op een duidelijke manier, dat dergelijke methoden een product formaat (geen project) en pas bij de overgang van product FURS, die gerelateerd ISO versies die in eerste instantie opgenomen aanpassing factoren zoals VAF uitgesloten ^[6]. de grondgedachte? Dergelijke “instelling / kalibratie” factoren kwam uit NFRs, dus, zijn buiten het bereik van een FSM methode. Als bewijs: ISO 20926:2003 was de ISO-norm voor IFPUG CPM v4.1 “ongecorrigeerde.” Versies 4.x -vanaf 1999 op- verfijnde versie definities en basisbegrippen, met name “gebruiker” en “grens”. Version v4.3 (2010) definitief wordt beëindigd VAF van de normtekst (Ook in ISO / IEC 20926:2009) and maintained it for historical purposes in Appendix C.

In de tussentijd, aangezien bont en NFRs nodig parallel wijze worden behandeld, de Software Non-Functional Assessment Process (SNAP) project gestart in 2007, vrijgeven v1.0 in 2011 ^[7], voor een nieuw, eerste niet-functionele Sizing Measurement (NFSM) methode, die verplaatst van de ISO-norm inzake product kwaliteit van de software (9126 voor ^[8], en uitgegroeid tot de huidige 25010:2011 standaard- ^[9]) terwijl het proberen om de functionele sizing zo veel mogelijk aan te vullen. vijg. 2 helpt om de juiste omvang van het project te bepalen, met drie soorten eisen:

vijg. 2: Drie soorten eisen (van de ‘ABC’ schema)

De informatie werd op verschillende wijze dan CPM v4.1 geschreven. Ik duidelijk vermeld in een 2012 papier ik schreef voor MetricViews ^[10], De ‘ABC’ Schema; zoals taxonomie werd ook gebruikt in een 2015 papier mede-geschreven door IFPUG / COSMIC voor een betere expressie van een taxonomie voor NFRs ^[11]. Deze classificatie is van cruciaal belang vanaf het begin van een project voor de juiste wijze te analyseren en te vergelijken met een goede benchmarking analyse. vijg. 3 geeft een overzicht van hoe een gebruiker eis kunnen worden ingezet en split, in het geval bredere, in drie stukken: product FURS (EEN), product NFRs (B) en project beperkingen / vereisten (C).

vijg. 3: De ABC-schema [10]

Van behoeften van de gebruikers tot de uiteindelijke totale project en -kosten – De “ABC” schema ^[10] in 1997 ISBSG (isbsg.org) is geboren en al van de meest actieve Software Measurement Verenigingen (SMA) gehandeld op grond van deze benchmarking initiatief. De 2019 vrijlating ^[12] omvat meer dan 9,000 projecten, vooral bemeten middels de IFPUG en kosmische FPA methoden. Een andere aanvullende norm was de ISO / IEC 14143-5:2004 ^[13], welke criteria stelt voor de definitie van “functionele domeinen” en zorgt voor een redelijke vergelijking tussen software en systemen met vergelijkbare kenmerken en distributie inspanning van eis types (abc). Het heeft geen zin om te vergelijken appels met peren ...

de huidige: Wat gebeurd er?

FSM methoden worden diffuus gebruikt in Information & Communicatietechnologie (ICT) contracten, met een hogere concentratie in sommige landen (bv. Italië, Brazilië, Polen, Indië), en vormen een kwantitatieve basis voor de dimensionering van het product functionele omvang en kan helpen bij benchmarking analyse om te bepalen die zouden kunnen worden (ongeveer) de niet-functionele inspanning in een project, zoals weergegeven in Fig.4:

vijg. 4: Inspanning verdeling per soort eis (abc) per functioneel domein: Een voorbeeld

Een voorbeeld van verdeling inspanning van vereiste soort (abc) per functioneel domein wordt het splitsen van wat niet-functioneel is volgens de ABC schema. Een B-type eis kan worden gerealiseerd en ingezet door een IT-specialist (bv. een database administrator, usability expert ...) die typisch kost minder dan een andere professional (bv. een project / dienst manager, een meting specialist, een kwaliteitsgarantie persoon ...) het runnen van een C-type vereiste, maar meer dan een professional (bv. analist / programmeur) een A-type vereiste. vijg. 5 toont de twee tegengestelde piramides voor een typische verdeling van het project inspanning van het type eis en de kosten per man / dag voor elke vorm van professionele ^[14].

vijg. 5: Inspanning verdeling naar type eis en kosten / mandag (volgens het schema ABC)

Inspanning verdeling naar type eis en kosten / mandag (volgens het schema ABC). Nog een keer, lessen uit 40 jarenlange ervaring geholpen om beter te definiëren (en verfijnen) beginselen en regels over het toepassingsgebied van FPA's. De ‘123’ schema is een andere indeling ^[15] voor het verklaren van welk soort eisen kan aanwezig zijn in een bepaalde fase van een project (1: dev, 2: Ops, 3: Svc, Onderhoud).

vijg. 6: De ‘123’ schema samen met de ‘ABC’ schema

Dus, in OPS fase software wordt gebruikt, niet geproduceerd / gewijzigd, en genereert een “zero FP” count, evenals wanneer er een verandering verzoek zal alleen B-type-eisen (bv. voor een correctief / perfectief onderhoud, zoals vermeld in ISO / IEC 14764:2006 standaard- ^[16], ook aangehaald in CPM v4.3.1 – een deel 3, hoofdstuk 4, pagina's 20-21). Zelfs als definities en criteria over wat FUR of NFR is gemaakt, uitgelegd en verspreid in de tijd, er is nog steeds een culturele schuld in contractuele praktijken en het bedrijfsleven om ten minste een maateenheid gebruiken (UoM) voor de dimensionering A-type vereisten (KP, ongeacht de aard) samen met de UoM voor de dimensionering B-type vereisten (bv. met IFPUG SNAP punten of maatregelen van ISO / IEC 25023 ^[17], en het C-type activiteiten die het toepassingsgebied voltooien voor het schatten van de gehele inspanning voor het scopingproces een project. Alleen bij de dimensionering van alle vereisten voor de drie (abc) types, is het mogelijk om de “scope creep verminderen,”Terwijl er nog een historische misvatting over wat een FP maten en wat het niet doet. Maar het zou voldoende zijn om te weten in een FSM methode, die zijn Base functionele componenten zijn (BFCs) voor het opnemen van (of niet) such an activity or activities.

Tenslotte, FP en automatisering. Dr. Albrecht creëerde een “ontwerp maatregel” voor het toestaan ​​van een raming van de vroege fasen van de levenscyclus. Sommige gereedschappen vandaag, na 40 jaar, KP zou leiden (ongeacht de aard) parsing software code of werken op sommige vormen van FUR notaties. Sommige (gezond verstand) observaties en gedachten: automatisering is handig als het respect van de vier criteria: sneller, accurater, meer tijdige en lager in kosten. Als we nodig hebben om de grootte van een nieuwe FUR, een hulpmiddel parseercode (zoals vermeld in de nieuwe ISO 19515 standaard op Automated FP ^[18]) nutteloos en duur zou zijn. Of, met behulp van gereedschap veronderstelling aantal UML notaties als grondstof meer manuren zou betekenen (en aanverwante kosten) voor het vertalen van een door de mens op basis van schriftelijke eis in een meta-taal-formaat. Ook, een organisatie moet zorgvuldig analyseren van de return on investment van die keuze(s) volgens de vier bovengenoemde criteria. Het snel creëren van een ontwerp-basislijn waarin tijd en moeite zijn kritisch vermogen kon worden ok onder de voorwaarden dat het wordt gecontroleerd door een menselijke CFPS en dat de UoM onder scope zijn hetzelfde. Anders, automation could become risky or difficult to manage.

De toekomst: Wat kunnen we verwachten?

Zoals veel mensen zouden zeggen, de toekomst is nu ... maar wat kunnen we verwachten van FPA in de nabije toekomst? FPA heeft sterke fundamenten en het is de technologie onafhankelijk; wat we hebben geleerd van het verleden is dat de volgende stappen moeten zijn:

• Een betere en meer betaalbare User Requirements (UR) beheer, scoping en meting tijdens de vroege fasen van een project: this is the main and primary goal that should be achieved.
• Vaststelling van FPA naar nieuwe technologieën, door de juiste interpretatie van de FPA basisregels van 1979/84. We kunnen nog niet te meten en de grootte door middel van FPA nieuwe technologieën zoals cloud computing ^[19], internet van dingen (ivd) ^[20], artificial intelligence and any new tech the upcoming years will bring us.

Onze beste inzet is niet om iets nieuws te verzinnen, maar om diepgaand te analyseren en onze huidige processen en gegevens aan nieuwe en andere manieren om een ​​software systeem engineer te bepalen en Stlstnd een FUR met FPA!

“Wij zijn van plan te blijven gebruiken en het verbeteren van de functie waarde meting.” (Allan Albrecht, oktober 1979)

Referenties

1. Jones, C., Wat zijn Functiepunten? SPR website, URL: http://tiny.cc/tgur7y
2. Albrecht A. J., “Het meten van applicatie ontwikkeling van de productiviteit” in Proc. joint SHARE, GIDS, en IBM Application Development , 1979, pp. 83-92. http://tiny.cc/2ywacz
3. Albrecht A. J. & Gaffney J. E., “software-functie, source regels code, en ontwikkelingsinspanning voorspelling: Een software wetenschap validatie,” IEEE Trans. Software Eng., vol. 9, Nee. 6, november 1983, pp. 639-647. http://tiny.cc/1zwacz
4. IFPUG, Function Point Counting Practice Manual (CPM), vrijlating 4.3.1, januari- 2010, URL: ifpug.org
5. Lother M., Dumke R., Points-Metrics: Vergelijkingen en Analysis”, in: Huidige Trends in Software Measurement, Shaker Publishing, 2001, pp.228-267
6. ISO / IEC, Internationale standaard 14143-1 – Informatie Technologie – software Measurement – Functional Size Measurement – Een deel 1: Afbakening van begrippen, February 2007
7. IFPUG, Software Non-functionele Assessment Process (SNAP) Assessment: een praktische handleiding (APM), versie 1.0, september 2011, URL: ifpug.org
8. ISO / IEC, IS 9126-1:2001 – software engineering – Productkwaliteit – Een deel 1: Quality Model, Internationale Organisatie voor Standaardisatie, 2001
9. ISO / IEC, IS 25010:2011 -Systemen en software engineering-systemen en software kwaliteitseisen en Evaluatie (Plein)-Systeem en software kwaliteitsmodellen, Internationale Organisatie voor Standaardisatie, March 2011
10. Bouillon L., The Next Frontier: Het meten en evalueren van de niet-functionele Productivity, MetricViews, augustus 2012, URL:https://www.ifpug.org/Metric%20Views/MVBuglione.pdf
11. COSMIC / IFPUG, Verklarende woordenlijst voor niet-functionele eisen en eisen van het project gebruikt in de software project prestatiemeting, benchmarking en het schatten, v1.0, September 2015
12. ISBSG, D&E (Ontwikkeling & Enhancement) bewaarplaats, R2019, URL:isbsg.org
13. ISO / IEC, Technisch rapport 14143-5 – Informatie Technologie – software Measurement – Functional Size Measurement – Een deel 5: bepaling van functionele domeinen voor functionele groottemeting, 2004 (R2019)
14. Bouillon L., Hoe omgaan met een uniforme en meetbare projecten: focus op types en eisen, ZeroUnoWeb, mei 3 2019, URL: http://tiny.cc/y1tr7y
15. Bouillon L., Interpreteer DevOps om goed te meten (en het beste) projecten, PMExpo2017, Presentatie, oktober 2017, URL:https://www.pmexpo.it/2017/programma/009tk
16. ISO / IEC, Internationale standaard 14764:2006 - Software Engineering - Software Life Cycle Processen – Onderhoud, 2006
17. ISO / IEC, Internationale standaard 25023:2016 – Systemen en software engineering – Systems en vereisten software Kwaliteit en Evaluatie (Plein) – Meting van het systeem en de kwaliteit van de software product, June 2016
18. ISO / IEC, Internationale standaard 19515:2019 – Informatie Technologie – Object Management Group Automated Functiepunten (AFP), 1.0, May 2019
19. Woodward S., Functie Punt Analyse verduidelijkt in een Bewolkte wereld, Metricas 2012, Sao Paulo (Brazilië), november 28-29 2012, URL:http://www.bfpug.com.br/metricas2012/woodward.pdf
20. Cagley T., Function Points en IOT, of hoe My Kitchen Spioneren On Me!, IFPUG ISMA17, Bangalore (Indië), maart 8, 2019

Over de auteur

Luigi Buglione is de IFPUG Director voor conferentie / Onderwijs en voorzitter van de Gruppo Utenti Function Point Italia – Italiaanse Software Metrics Association (GUFPI-ISMA) (www.gufpi-isma.org). Hij werkt als een Meet- en Process Improvement Specialist in engineering Ing. Inf. SpA in Rome, Italië en Associate Professor aan de École de Technologie Supérieure (ETS) - Universiteit van Quebec, Canada. Hij behaalde verschillende certificeringen, waaronder IFPUG CFPS, CSP, CSMS, en kosmische CCFL over Software Measurement. Hij is regelmatig spreker op internationale conferenties over Sw / Dienst Measurement, Process Improvement en Kwaliteit en is actief deel uit van de internationale en nationale technische verenigingen over dergelijke kwesties. Hij kreeg een Ph.D. in MIS en een diploma cum laude in economie. Luigi is te bereiken op luigi.buglione@eng.it.