40 Anni di Function Points: Passato, Presente, Futuro

By Luigi Buglione

Appena 40 anni fa nel mese di ottobre 1979, Dr. Allan Albrecht proposto per la prima volta una tecnica per il dimensionamento della funzionalità di un sistema software. La sua tecnica è stata adottata, è diventato uno standard internazionale, e ispirato diverse altre tecniche e molto altro ancora. Questo documento mostra passato, presente e (possibile) futuri contributi di analisi Function Point.

Il passato: origini, Motivazione e Razionale

Nel 1970, Righe di codice (LOC) sono stati impropriamente utilizzati per il dimensionamento di sistemi software (e sono ancora oggi in alcuni domini funzionali, come i sistemi automotive e militare in tempo reale e, solo per citarne alcuni) e ha portato a quello che Capers Jones etichettato il “paradosso della produttività” [1]: scrivere più LOC non significa necessariamente essere più produttivi ... lo stile di programmazione, l'espressività di un certo linguaggio di programmazione, la regola per il conteggio LOCs (fisica o logica, con / senza righe commentate ...) creato un enorme variabilità del progetto (sì, progetto!) stima. Perché in quel momento, abbiamo avuto solo mainframe, non PC o mini-computer. così, il (Software) lo sforzo prodotto per la distribuzione è stata la maggior parte delle funzionalità complessive dello sforzo di progetto e software sono stati concepiti come il risultato principale di un progetto software. Come conseguenza, per molti anni (e ancora in molti contratti), Function Points (PQ) erano (e sono) erroneamente inteso come la “dimensione del progetto”, mentre esprimono solo la dimensione funzionale del prodotto. Comunque, L'obiettivo di Albrecht è stato quello di superare il “paradosso della produttività” e trovare un modo per normalizzare i calcoli di produttività da una prospettiva di business [2]. La grande idea era quella di basare la sua tecnica su qualcosa di indipendente dalla tecnologia: processi e dati. così, un calcolo FP (e prodotti correlati dimensione funzionale) derivato dall'analisi di una serie di Requisiti Utente Funzionali (pellicceria) è lo stesso, nonostante la tecnologia e lo stile organizzativo adottato, mentre lo sforzo, durata e il costo / prezzo sono, ovviamente, variabile secondo tali elementi. L'esempio tipico proposto nel corso degli anni è stato a guardare FP metri quadrati come per misurare la “dimensione” di un appartamento: il numero di metri quadrati può essere la stessa per due appartamenti in due luoghi diversi, ma il tempo per la loro costruzione possono differire (es. TV può essere costruito con mattoni o essere prefabbricati), come pure i loro costi di produzione e valore commerciale (un appartamento a Manhattan, New York, è più costoso per metro quadrato di un altro in un altro luogo); costo non è un valore.

Il primo documento, datato 1979, basi poste per un tale obiettivo, come indicato nel titolo (“Produttività lo sviluppo di applicazioni di misura”). Rappresentava un big-bang per le stime, cercando di estratto ingressi / uscite / query e dati da un'analisi funzionale in particolare perché un nuovo numero così potrebbe essere derivato prima della programmazione e non più tardi, come ha fatto con un conteggio LOC. Dal momento che non è possibile prevedere con un certo grado di precisione il numero di LOC tua squadra produrrà domani ... troppa variabilità!

Ci sono molti vantaggi ma anche alcuni problemi aperti: la correlazione tra lo sforzo progetto (giornate / uomo) e la dimensione funzionale del prodotto (in FP) Non era così in alto, e un fattore di regolazione Valore (VAF) è stato introdotto al fine di migliorare tale rapporto e il valore R2 in un'analisi di regressione lineare. VAF è stato inizialmente calcolato sulla 10 Caratteristiche generali di sistema (GSCs) con una variabilità di ± 25% nel primo 1979 carta, allargata a 14 GSCs nella seconda ed ultima carta, datato 1983 [3], con una variabilità ± 35% del valore iniziale FP “aggiustata”. VAF era, perciò, il primo modo per indirettamente “taglia” il contributo dei requisiti non funzionali (NFRS), sia a livello di prodotto, così come il livello di progetto. Questa seconda ed ultima carta da Allan Albrecht affermato la struttura finale FPA, suddividere il MASTER tipo funzione DATA iniziale in ILF e EIF, e detto sistema di ponderazione finale (come ancora valida l'attuale versione di CPM IFPUG v4.3.1, datato 2010 [4]) da quel momento. così, è possibile confrontare -da un punto di vista funzionale dimensionamento- un prodotto software realizzato oggi con un altro rilasciato anni fa per fini di benchmarking.

Nel 1987, IFPUG è nato e tenuto nelle sue mani la gestione e l'evoluzione della tecnica di Albrecht. Negli anni successivi, diverse tecniche trasferiti fuori dalle idee di Albrecht, e solo alcuni sono diventati standard ISO, come mostrato in Fig. 1:

Figura. 1: ISO Standards FSM (con linee blu tratteggiate)

Figura. 1: ISO Standards FSM (con linee blu tratteggiate)

Loro sono (in ordine di apparizione): Mark-II (1988), Nesma FPA (1990), FISMA (199X) e COSMIC (1998), con un sacco di varianti minori (Qui [5] un elenco di alcuni di essi).

I primi usi di FPA sono stati per determinare la dimensione funzionale di prodotti software per scopi di stima e di benchmarking e -per semplificare- come unità contrattuale per il pagamento in un contratto ICT.

Nel 1998, ISO ha iniziato la creazione di una famiglia di standard sotto l'etichetta “14143”, con principi comuni per la cosiddetta misurazione funzionale Dimensionamento (FSM) metodi, indicando in modo chiaro che tali metodi dimensionati un prodotto (non un progetto) e solo quando si spostano da pellami prodotto, che escludeva le versioni ISO correlate che inizialmente comprendeva fattori di aggiustamento, come VAF [6]. La logica? Tali fattori “regolazione / calibrazione” venuto da NFRS, così, sono fuori portata per un metodo FSM. Come prova: ISO 20926:2003 era lo standard ISO per IFPUG CPM v4.1 “non aggiustati.” versioni 4.x -da 1999 sopra- raffinate definizioni di versione e concetti di base, in particolare “utente” e “di confine”. V4.3 Versione (2010) definitivamente caduto VAF dal testo normativo (anche in ISO / IEC 20926:2009) e mantenuto per scopi storici in Appendice C.

Nel frattempo, poiché pellicce e NFRS devono essere trattati in modo parallelo, Il processo di valutazione del software non-funzionale (SNAP) progetto è iniziato nel 2007, rilasciando v1.0 in 2011 [7], per una nuova, prima misurazione Dimensionamento non-funzionale (NFSM) metodo, che si muoveva dalla norma ISO sulla qualità del software del prodotto (9126 prima [8], ed evoluta in corrente 25010:2011 standard [9]) durante il tentativo di completare il dimensionamento funzionale quanto più possibile. Figura. 2 contribuisce a determinare la portata del progetto giusto, con tre tipi di requisiti:

Figura. 2: Tre tipi di requisiti (da schema del ‘ABC’)

Figura. 2: Tre tipi di requisiti (da schema del ‘ABC’)

L'informazione è stata scritta in modo diverso rispetto CPM v4.1. Ho detto chiaramente in un 2012 la carta che ho scritto per MetricViews [10], Schema Il ‘ABC’; tale tassonomia è stato utilizzato anche in una 2015 carta co-scritto da IFPUG / COSMIC per esprimere al meglio una tassonomia per NFRS [11]. Questa classificazione è fondamentale fin dall'inizio di qualsiasi progetto per analizzare correttamente e confrontandoli con una buona analisi di benchmarking. Figura. 3 sintetizza come un requisito utente potrebbe essere distribuito e divisa, nel caso più ampia, in tre pezzi: pELLICCE prodotto (UN), NFRS prodotto (B) e vincoli di progetto / requisiti (C).

Figura. 3: L'ABC schema [10]

Figura. 3: L'ABC schema [10]

Da esigenze degli utenti allo sforzo progetto complessivo finale e costi – Lo schema “ABC” [10] nel 1997 ISBSG (isbsg.org) è nato e tutti i più attivi Software Associazioni di misura (SMA) aderito a questa iniziativa di benchmarking. Il 2019 pubblicazione [12] comprende più di 9,000 progetti, soprattutto dimensionato utilizzando i metodi IFPUG e COSMIC FPA. Un'altra norma complementare era l'ISO / IEC 14143-5:2004 [13], che propone criteri per la definizione “domini funzionali” e permette un ragionevole confronto tra sistemi software con caratteristiche simili e distribuzione sforzo di tipi requisito (ABC). Non ha senso confrontare le mele con le arance ...

 

Il presente: Cosa sta succedendo?

metodi FSM sono diffusamente utilizzati in Information & Tecnologia della comunicazione (ICT) contratti, con una maggiore concentrazione in alcuni paesi (es. Italia, Brasile, Polonia, India), e rappresentano una base quantitativa per dimensionare la dimensione funzionale del prodotto e può aiutare in analisi comparativa per determinare quale potrebbe essere (circa) lo sforzo non funzionale in un progetto, come mostrato in Fig.4:

Figura. 4: Distribuzione sforzo per tipo requisito (ABC) per dominio funzionale: un esempio

Figura. 4: Distribuzione sforzo per tipo requisito (ABC) per dominio funzionale: un esempio

Un esempio di distribuzione sforzo per tipo requisito (ABC) per dominio funzionale è la divisione ciò che non è funzionale in base allo schema ABC. Un requisito di tipo B può essere realizzato e distribuito da uno specialista IT (es. un amministratore di database, esperto di usabilità ...) che in genere costa meno di un altro professionista (es. un progetto / responsabile del servizio, uno specialista di misura, una persona di garanzia della qualità ...) l'esecuzione di un requisito di tipo C, ma più di un professionista (es. un analista / programmatore) esecuzione di un requisito di tipo A. Figura. 5 mostra le due piramidi opposte per una tipica ripartizione degli sforzi del progetto per tipo di esigenza e costo per l'uomo / giorno per ogni tipo di professionista [14].

Figura. 5: Distribuzione sforzo per tipologia di esigenza e di costo / uomo-giorno (in base allo schema ABC)

Distribuzione sforzo per tipologia di esigenza e di costo / uomo-giorno (in base allo schema ABC). Ancora, lezioni apprese da 40 anni di esperienza hanno contribuito a definire meglio (e perfezionare) principi e le regole circa la portata di FPA di applicazione. Il ‘123’ schema è un'altra classificazione [15] per affermare che tipo di esigenza può essere presente in una certa fase di un progetto (1: dev, 2: Ops, 3: Svc, Manutenzione).

Figura. 6: Il ‘123’ dello schema in collaborazione con lo schema del ‘ABC’

così, nella fase OPS un programma viene utilizzato, non prodotti / cambiato, e genera un conteggio “zero FP”, così come quando una richiesta di modifica includerà solo i requisiti di tipo B (es. per una manutenzione correttiva / perfettiva, come indicato nella norma ISO / IEC 14764:2006 standard [16], anche citata CPM v4.3.1 – parte 3, capitolo 4, pagine 20-21). Anche se le definizioni e criteri su ciò che è stato creato FUR o NFR, spiegato e diffuso nel tempo, c'è ancora un debito culturale in pratiche contrattuali e alle imprese di utilizzare almeno un'unità di misura (UM) per il dimensionamento requisiti di tipo A (PQ, qualsiasi tipo) congiuntamente con la UM per il dimensionamento requisiti di tipo B (es. con punti IFPUG SNAP o misure da ISO / IEC 25023 [17], nonché le attività di tipo C che completano le possibilità di stimare l'intero sforzo necessario per scoping un progetto. Solo quando il dimensionamento tutti i requisiti per i tre (ABC) tipi, è possibile ridurre il “scope creep,”Mentre c'è ancora un equivoco storico su quello che una dimensione FP e ciò che non lo fa. Ma sarebbe sufficiente conoscere in un metodo FSM, quali sono le sue componenti funzionali di base (BFCS) per l'inclusione (o no) tale attività o di attività.

Ultimo, ma non per importanza, FP e automazione. Dr. Albrecht ha creato una “misura di progettazione” per consentire una stima nelle prime fasi del ciclo di vita. Alcuni strumenti di oggi, dopo 40 anni, deriverebbe PQ (qualsiasi tipo) parsing codice software o lavorare su alcune forme di notazioni FUR. Alcuni (buon senso) osservazioni e pensieri: automazione è utile se è rispettosa delle quattro criteri: Più veloce, più accurato, più tempestivo e più basso in termini di costi. Se abbiamo bisogno di una nuova dimensione FUR, un codice strumento di analisi (come affermato nella nuova norma ISO 19515 di serie su Automated FP [18]) sarebbe inutile e costosa. O, utilizzando uno strumento ipotizzando alcune notazioni UML come ingressi implicherebbero più ore-uomo (ei relativi costi) per la traduzione di una richiesta scritta umana basata in un formato metalinguaggio. Anche, un'organizzazione deve analizzare attentamente il ritorno sugli investimenti per tale scelta(S) secondo quattro criteri summenzionati. la realizzazione rapida di un progetto di base in cui il tempo e lo sforzo sono le risorse critiche potrebbero essere ok sotto le precondizioni che sia verificata da un CFPS umano e che l'UM sotto portata identici. Altrimenti, automazione potrebbe diventare rischioso o difficili da gestire.

 

Il futuro: Cosa possiamo aspettarci?

Come molte persone direbbero, il futuro è adesso ... ma cosa ci si può aspettare dalla FPA nel prossimo futuro? FPA ha basi forti ed è la tecnologia indipendente; ciò che abbiamo imparato dal passato è che i prossimi passi dovrebbero essere:

  • A Requisiti Utente migliori e più convenienti (UR) gestione, scoping e misurazione durante le prime fasi di un progetto: questo è l'obiettivo principale e primario che dovrebbe essere raggiunto.
  • Adozione di FPA alle nuove tecnologie, attraverso la corretta interpretazione delle regole di base da CQP 1979/84. Non possiamo ancora misurare e dimensioni attraverso FPA nuove tecnologie come il cloud computing [19], Internet delle cose (IoT) [20], intelligenza artificiale e qualsiasi nuova tecnologia i prossimi anni ci porterà.

La nostra scommessa migliore non è quello di inventare qualcosa di nuovo, ma per analizzare a fondo i nostri processi e dati attuali per stabilire nuovi e diversi modi per progettare un sistema software e ancora dimensionare una pelliccia con FPA!

Abbiamo intenzione di continuare a utilizzare e migliorare la funzione valore misurazione.” (Allan Albrecht, ottobre 1979)

 

Riferimenti

  1. Jones, C., Quali sono Function Points? sito web SPR, URL: http://tiny.cc/tgur7y
  2. Albrecht A. J., “Misurare la produttività lo sviluppo di applicazioni” Proc. SHARE comune, GUIDA, e sviluppo IBM Application , 1979, pp. 83-92. http://tiny.cc/2ywacz
  3. Albrecht A. J. & Gaffney J. E., “funzione software, linee di source di codice, e previsione sforzo di sviluppo: Una validazione scientifica del software,” IEEE Trans. Software Ing., vol. 9, no. 6, novembre 1983, pp. 639-647. http://tiny.cc/1zwacz
  4. IFPUG, Function Point Manuale di conteggio Practice (CPM), pubblicazione 4.3.1, gennaio 2010, URL: ifpug.org
  5. Lother M., Dumke R., Punti-Metrics: Confronti e analisi”, nel: Le attuali tendenze di misura Software, Shaker Publishing, 2001, pp.228-267
  6. ISO / IEC, Standard internazionale 14143-1 – Tecnologia dell'informazione – Measurement Software – Misura dimensione funzionale – Parte 1: definizione dei concetti, febbraio 2007
  7. IFPUG, Software Process Assessment non-funzionali (SNAP) Manuale Practice Assessment (APM), versione 1.0, settembre 2011, URL: ifpug.org
  8. ISO / IEC, È 9126-1:2001 – Ingegneria software – Qualità del prodotto – Parte 1: modello di qualità, Organizzazione internazionale per la standardizzazione, 2001
  9. ISO / IEC, È 25010:2011 -Sistemi e software di ingegneria-Systems e la qualità del software Requisiti e valutazione (Piazza)-modelli di qualità di sistema e software, Organizzazione internazionale per la standardizzazione, marzo 2011
  10. Buglione L., La prossima frontiera: Misurazione e valutazione della produttività non funzionali, MetricViews, agosto 2012, URL:https://www.ifpug.org/Metric%20Views/MVBuglione.pdf
  11. COSMIC / IFPUG, Glossario dei termini di requisiti non funzionali e requisiti di progetto utilizzato nella misurazione delle prestazioni dei progetti software, analisi comparativa e la stima, v1.0, settembre 2015
  12. ISBSG, D&E (Sviluppo & Aumento) deposito, R2019, URL:isbsg.org
  13. ISO / IEC, Rapporto tecnico 14143-5 – Tecnologia dell'informazione – Measurement Software – Misura dimensione funzionale – Parte 5: determinazione dei domini funzionali per l'utilizzo con misurazione della dimensione funzionale, 2004 (R2019)
  14. Buglione L., Come gestire progetti uniformi e misurabili: concentrarsi sui tipi e requisiti, ZeroUnoWeb, potrebbe 3 2019, URL: http://tiny.cc/y1tr7y
  15. Buglione L., Interpretare DevOps per misurare bene (e meglio) i progetti, PMExpo2017, Presentazione, ottobre 2017, URL:https://www.pmexpo.it/2017/programma/009tk
  16. ISO / IEC, Standard internazionale 14764:2006 - Processi Software Life Cycle - Software Engineering – Manutenzione, 2006
  17. ISO / IEC, Standard internazionale 25023:2016 – Sistemi e ingegneria del software – Sistemi e requisiti software di qualità e valutazione (Piazza) – Misurazione del sistema e la qualità del prodotto software, giugno 2016
  18. ISO / IEC, Standard internazionale 19515:2019 – Tecnologia dell'informazione – Object Management Group Automated Function Points (AFP), 1.0, potrebbe 2019
  19. Woodward S., Function Point Analysis chiarisce in un mondo nuvoloso, Metricas 2012, Sao Paulo (Brasile), novembre 28-29 2012, URL:http://www.bfpug.com.br/metricas2012/woodward.pdf
  20. Cagley T., Function Points e IOT, o come My Kitchen sta spiando su di me!, IFPUG ISMA17, Bangalore (India), marzo 8, 2019

Circa l'autore

Luigi Buglione è il direttore IFPUG per conferenze / Istruzione e Presidente della Funzione Gruppo Utenti Point Italia – Italiano Software Metrics Association (GUFPI-ISMA) (www.gufpi-isma.org). Lavora come processo di misurazione e miglioramento specialista in Ingegneria Ing. Inf. SpA a Roma, Italia e professore associato presso l'École de Technologie Supérieure (ETS) - Università del Quebec, Canada. Ha raggiunto diverse certificazioni, tra cui CFPS IFPUG, CSP, CSMS, e CCFL COSMIC su misura Software. E 'relatore regolarmente a conferenze internazionali sulla Sw / Misura Servizio, Process Improvement e qualità ed è attivamente parte della International e associazioni tecniche nazionali su tali questioni. Ha ricevuto un dottorato. in MIS e una cum laude laurea in Economia. Luigi può essere raggiunto a luigi.buglione@eng.it.

Potrebbe piacerti anche...