BLOOM! frammenti di organizzazione
Pubblicato in data: 14/03/2005

PSU E METRICHE FUNZIONALI PER IL DIMENSIONAMENTO DEL SOFTWARE: CONCORRENTI O ALLEATI?

di Luigi Buglione (*)

11/02/2005, White paper  

Introduzione

In un precedente articolo apparso su Bloom! [BUGL03b] si è discusso sull’opportunità di utilizzare metriche per il dimensionamento anticipato dei progetti software, al fine di poter determinare l’effort necessario per sviluppare un progetto con il maggior anticipo e livello di confidenza possibile [BUGL03a]. Oltre a versioni early [MELI97] della Function Point Analysis (FPA) [IFPU04], si è proposta una metrica diversa – seppur muovendo dallo stesso approccio – denominata Project Size Unit (PSU), derivabile dagli oggetti tipici dei quali un Project Manager dispone nella fase di offerta, ovverosia requisiti di alto livello formulati dal Cliente, a valle della cui analisi deriva una WBS (Work Breakdown Structure) che esprimerà quindi un effort per ciascuno dei task previsti.

Attraverso  una classificazione dei requisiti di tipo funzionale ed una loro ponderazione è possibile, in modo analogo alla FPA (così come con altri FSMMFunctional Size Measurement Methods – quali COSMIC-FFP [ISO03], Mark II [ISO02] e NESMA FPA [ISO05], secondo i criteri dello standard ISO/IEC 14143 [ISO14143]) quindi derivare un valore dimensionale in un momento temporale in cui il dettaglio tecnico (numero di tabelle, input, output, …) non sempre può essere già definito o conosciuto ed eventualmente stabile. La seguente tabella riassume in modo comparativo i due metodi e gli elementi differenziali: 

Metodo \ Elementi

Entità

Complessità

Fattore di Aggiust.

Complessità

FPA (standard)

Dati (ILF, EIF) e Transazioni (EI, EO, EQ) relativi ai requisiti funzionali di un sistema software

3 livelli (A/M/B) per ciascuna tipologia di entità

14 caratteristiche generali di sistema (GSC)

Peso (0-5) per ciascuna delle 14 GSC, con un ±35% sul valore di FP unadjusted

PSU (anticipato)

UR funzionali di dettaglio e task derivati (regola: 1 task = max x gg/uomo) per le fasi tecniche del SLC

3 livelli (A/M/B) per ciascun UR di dettaglio rispetto al n. di task di dettaglio per UR (e quindi di gg/uomo, statisticamente determinati)

Ponderazione % per valutare l’ammontare di effort richiesto in proporzione per i task di tipo qualitativo e gestionale.

Tale percentuale è derivata dall’analisi del db storico dei dati di progetto, ed è proporzionale al numero di PSU unadjusted.

 

In ogni caso, considerando la colonna “Entità”, è possibile notare come l’oggetto di valutazione sia dato dall’analisi dei soli requisiti funzionali, al fine di poter stabilire – una volta disponibile un database storico dei progetti consistente (in numero e qualità dei dati raccolti) con conteggi dimensionali effettuati usando entrambe le tecniche – una correlazione tra le due. Obiettivo: poter approssimare il numero di Function Points (o di un’altra qualsivoglia FSM unit) già in fase alta (offerta), attraverso un’altra metrica (PSU), di più agevole determinazione – seppur con tutte le dovute limitazioni implicite in una valutazione temporalmente anticipata.

Per poter determinare il nuovo effort partendo dal numero di unità dimensionali storicizzati per tutti i progetti conclusi andrà quindi calcolata prima la dimensione del nuovo progetto con il FSMM scelto (ad esempio, IFPUG FPA), usando quindi un metodo di conteggio (pieno) e non di stima (anticipato), con le potenziali difficoltà nel poter disporre delle informazioni di dettaglio, come sopra accennato. Pertanto, indipendentemente dalla tecnica anticipata utilizzata, è necessario stabilire tale relazione ed utilizzarla per derivare l’effort, applicandola poi all’equazione precedentemente determinata.  

 

Quale effort misurano gli FSMM?

Uno degli aspetti apparentemente banali risiede in questa domanda: i Function Point, i COSMICfsu, o qualunque altra unità dimensionale derivata da un FSMM cosa misura? L’effort dell’intero progetto o solo una parte? A quale effort deve essere relazionato nel determinare un modello di stima?

Un FSMM, quale che sia, nel suo “titolo” indica che l’oggetto della misurazione risiede nei soli aspetti di natura funzionale di un progetto di sviluppo/manutenzione software. Lo standard ISO/IEC 14143-1:1998 [ISO98] classifica in questo modo i requisiti [1] :

·               Requisiti Funzionali (Functional User Requirements – FUR): “a sub-set of the user requirements. The Functional User Requirements represent the user practices and procedures that the software must perform to fulfil the users’ needs. They exclude Quality Requirements and any Technical Requirements

·               Requisiti di Qualità (Quality Requirements): “any requirements relating to software quality as defined in ISO 9126:1991

·               Requisiti Tecnici (Technical Requirements): “requirements relating to the technology and environment, for the development, maintenance, support and execution of the software  

Considerando  che proprio la prima caratteristica della ISO/IEC 9126 [ISO01] è la funzionalità, come indicato in [IFPU03], è possibile esprimere i tre gruppi come nella seguente figura, dove l’area del rettangolo esprime l’intero effort del progetto:  

Fig. 1 Tipologie di requisiti F/Q/T ed effort di progetto

In ogni caso, a parte alcuni lievi sovrapposizioni nelle classificazioni, è necessario riaffermare, qualora ve ne fosse bisogno, che l’effort derivato dal conteggio con un FSMM copre solo uno dei tre gruppi e non  l’intero progetto.  

Effort del progetto e requisiti funzionali

A questo punto, la domanda successiva di un bid manager sarebbe: ma allora come posso derivare l’effort da dichiarare relativamente all’intero progetto già in fase di offerta?

Sicuramente nel database storico dei progetti sarà necessaria la classificazione dei requisiti in queste tre categorie, con una relazione stretta all’effort generato (in fase di consuntivo). Ma ancora qui mancherebbe tutta la quota legata alla gestione in senso lato del progetto, che in ogni caso “cuba” per un dato numero di giorni/uomo. In Fig.2 si riporta un set di dati progetto di esempio, utile per chiarire quanto ora espresso:

Fig. 2 – Database di progetto: un esempio (n=8)  

Si considerino 8 progetti di sviluppo, di cui 5 misurati usando il metodo IFPUG e 3 usando il metodo COSMIC-FFP. Per ogni progetto viene censito l’effort legato allo sviluppo dei requisiti di tipo F/Q/T sia in valore assoluto (in gg/uu) che in percentuale, indicando nell’ultima colonna (“altro effort”) la quantità di tempo non strettamente riferibile allo sviluppo dei requisiti F/Q/T. In basso poi si sono riepilogati i valori massimi, medi (avg), mediani (med) e minimi per i vari campi, al fine di “delimitare” i confini di osservazione. Si sono poi considerati per omogeneità di analisi 2 sub-set di progetti secondo il metodo dimensionale utilizzato, ovverosia un set “A” con la IFPUG FPA (n=5):  

Fig. 3 – Progetti dimensionati in FP (n=5)

 

e un set “B” con i COSMIC-FFP (n=3):

 

Fig. 4 – Progetti dimensionati in Cfsu (n=3)

 

Per ciascun set si è provato a calcolare l’equazione della retta di regressione (relazione lineare) ponendo in relazione la metrica dimensionale sia all’effort dell’intero progetto (Fig.5a) che a quello strettamente riferibile allo sviluppo dei requisiti di tipo funzionale (F) (Fig.5b). Ecco gli esempi per la FPA (set A):

 

(a)

(b)

 

Fig. 5 – Rette di regressione FP vs Effort progetto (a) e vs Effort Req(F) (b)

 

e per i COSMIC-FFP (set B):

 

(a)

(b)

 

Fig. 6 – Rette di regressione Cfsu  vs Effort progetto (a) e vs Effort Req(F) (b)

 

Al di là dei valori inseriti a titolo di esempio, il delta di effort espresso nell’ultima colonna delle Figg.2, 3 e 4 può portare ad un potenziale peggioramento della stima, in funzione della percentuale di effort espresso dai requisiti di tipo non funzionale (-F) e delle attività gestionali del progetto. Nel caso del set A, questa differenza è riscontrabile anche in un indice di correlazione (R2) pari al 53.79%, in conseguenza di  un peso tra il 46 e 47% (rispettivamente media e mediana) dell’effort derivato dai requisiti di tipo funzionale che va a ridursi nel set B (R2=99.66%) anche in funzione di ulteriori fattori (innanzitutto la ridotta numerosità del campione osservato e comunque percentuali di medie e mediane per l’effort derivato dallo sviluppo dei requisiti funzionali superiore; c.a. il 53%).

Ritornando alla domanda iniziale (come poter migliorare la stima?), una prima risposta sicuramente è quella di isolare e dettagliare tali elementi di effort, anche solo per un uso “analogico” del database storico dei progetti.

 Una seconda risposta può essere quella di considerare una metrica la cui misurazione impatti sull’entità di livello superiore al requisito, ovverosia il progetto stesso.

 

Effort del progetto: nuove metriche?

Nell’ambito di una sperimentazione effettuata nel corso del biennio 2003-04 per l’applicazione dei PSU [BUGL03b], una delle attività svolte per poter effettuare un tuning progressivo dei pesi e per validare le regole di calcolo è stata quella di applicazione “backward” dei PSU partendo dai progetti già conclusi. In particolare, si è notato che l’applicazione dei PSU può essere agevolmente estesa all’entità “progetto” (PSUp)e quindi a progetti di diverse tipologie, come progetti di servizio (PSUs) senza dover modificare l’impianto di calcolo, ma solo eventualmente quello dei pesi, sempre in funzione dei dati che andranno ad alimentare il database storico.

 

PSUp: estensione all’entità progetto

Un’applicazione estensiva del metodo all’intero progetto è alquanto naturale, utilizzandosi la WBS di progetto quale documento-guida per le classificazioni delle entità di dettaglio (WBE) sulle quali effettuare il calcolo. Come già illustrato in precedenza, la relazione tra PSUp e un qualsivoglia FSMM sarebbe del seguente tipo:

Fig. 7 – PSU e FSMM: relazione

 

Quali considerazioni ne derivano? Se l’obiettivo finale di un estimatore è quello di derivare l’effort dell’intero progetto con il minor errore possibile, una metrica come i PSU che ne considera il tutto e non solo una parte offre maggiori probabilità – stante ovviamente una serie storica consolidata e robusta, pre-requisito indispensabile ed ineludibile per il successo di un’iniziativa del genere – di poter approssimare in modo via via migliore l’effort stimato rispetto a quello che si andrà poi a consuntivare.

Altri potenziali vantaggi risiedono nella comparabilità tra progetti aventi diverse nature (es: progetti di sviluppo software e di erogazione di servizi applicativi), non tanto nella stima in sé (in ogni caso i progetti di servizio andrebbero filtrati con un ulteriore campo nel database), quanto nella condivisione dei concetti comuni relativi al sizing all’intero di una data organizzazione.

Ciò non elimina assolutamente quanto indicato nell’introduzione, ovverosia che un uso congiunto e non concorrente di una tecnica anticipata con una “piena” permetta di ottimizzare nel tempo l’obiettivo di stime più puntuali, sia dal punto di vista tecnico che organizzativo (richiesta in taluni contratti dell’uso formale di un FSMM, come ad esempio della IFPUG FPA nella Pubblica Amministrazione).

 

 

PSU e FSMM: quale correlazione?

Si consideri nuovamente la base dati di Fig2 [2] , osservando al contempo i dati di PSU riferiti strettamente ai requisiti funzionali (indicati come PSUf) e quelli riferiti all’intero progetto (indicati come PSUp).

Come usare tali dati nella prossima stima in PSUp per derivare il numero presunto di FP già in fase di offerta (spesso parte delle risposte da offrire nel dettaglio tecnico per il Cliente)?

Innanzitutto è necessario rendere omogenei i valori di PSU rispetto alla percentuale di effort considerata. Nella colonna “PSUf” è considerato il numero di PSU relativi allo sviluppo funzionale per quel dato progetto (ad es: per il progetto p101 i PSUf sono 65, ossia il 42% dei 155 totali).

Scorrendo l’intero database, si considererà un fattore di omogeneizzazione (Omogenity FactorOF), pari alla mediana della percentuale di effort per requisiti di tipo funzionale (nell’esempio, OF=47%). Una volta omogeneizzati i fattori dimensionali (ovverosia riferendo sia i FP che i PSUf allo stesso effort, sempre nell’esempio 333.9 gg/uu), è possibile dalle due serie storiche derivare il fattore di conversione (Conversion FactorCF) dato dal rapporto dei valori mediani di PSUf e FP (nell’esempio rispettivamente pari a 65.10 e 257), al pari di quanto applicato nel “backfiring” per convertire i valori di LOC a FP [JONE96]. Nel nostro caso, il CF sarà pari a 0.2533.

A questo punto, conoscendo il numero di PSU per l’intero progetto (PSUp), è possibile determinare il numero presunto di FP in questo modo:

(1)

 

Supponendo un nuovo progetto la cui valutazione determini 224 PSUp, applicando la formula (1) otterremo allora:

(2)

 

Fig. 8 – PSUp e FP: fattori di omogeneizzazione (OF) e di conversione (CF)

 

Applicando le formule derivate in precedenza dall’analisi di regressione relazionando i PSUp  all’intero effort di progetto e i FP al solo effort di natura funzionale, otterremo:

Fig. 9 – PSUp e FP: effort stimati per il nuovo progetto

 

Includendo ora il sesto valore stimato e aggiornando il plot diagram, si otterrà:

Fig. 10 – FP: retta di regressione e R2 (n=6)

con un R2 migliorato del 2.23% rispetto al caso precedente per i FP, mentre per i PSUp:

Fig. 11 – PSUp: retta di regressione e R2 (n=6)

 

il vantaggio ottenuto negli aspetti funzionali si spalma sull’intero progetto, con un miglioramento dello 0.13% dell’indice di correlazione.

 

Conclusioni?

La discussione e le considerazioni ora illustrate sono state riferite all’analisi e alla trattazione dei soli valori di consuntivo di un progetto, quale primo passo per muovere da una stima di tipo esperienziale-analogica verso una che faccia uso sempre maggiore di un supporto di natura quantitativa. Il merito sulla bontà dei modelli di stima derivati dall’uso delle metriche scelte da un’Organizzazione esula dall’oggetto del presente articolo, sebbene di assoluto interesse, senza alcun dubbio.

In ogni caso, va ricordato che un FSMM ha delle regole di conteggio e numerose interpretazioni prodotte nell’arco di lustri – nel caso della IFPUG FPA parliamo di 25 anni dal primo articolo di Allan Albrecht nel 1979; un esempio Italiano di interpretazione delle regole di conteggio ufficiali è dato dalle Linee Guida Italiane (LGI) prodotte dal GUFPI-ISMA [3] . Un rischio potenziale potrebbe essere quello di voler comparare oggetti con nature differenti. Come evidenziato nella tabella iniziale, un metodo di conteggio – che può essere proficuamente applicato non prima di disporre dei documenti di analisi funzionale – non può essere comparato direttamente con un metodo di valutazione anticipato della dimensione, per quantità e qualità delle informazioni disponibili e per tempistica di attuazione.

I PSU partono dall’esigenza di essere innanzitutto un esercizio iterativo di Project Management tenendo conto le modalità usuali di lavoro di un PM, laddove il presupposto ineludibile, prima ancora di poter parlare di stima, è dato dalla storicizzazione dei dati di progetti conclusi in modo consistente e con una buona qualità delle informazioni storicizzate (la stessa ISBSG nelle ultime release del proprio benchmarking mondiale sulla misurazione funzionale ha introdotto una classificazione della qualità dei dati riportati per i progetti in Classe A, B, C e D [4] ).

Uno dei possibili punti di osservazione sui PSU sicuramente è che non potrebbero essere usati quali “metri” comparabili all’esterno di un’organizzazione, come avviene invece per un qualsiasi FSMM. L’affermazione è corretta, ma tale aspetto è insito nella natura di un metodo “aperto” quale quello dei PSU. La visione con cui sono stati espressamente pensati non è di uso esterno, ma strettamente interno, a supporto delle (eventuali) ulteriori modalità di stima vigenti in un’Organizzazione. Il sistema di pesatura deriva infatti da una revisione periodica effettuata in funzione della bontà di “gantizzare” in un modo consistente le attività tra tutti i progetti in termini di granularità. Per questo motivo i PSU rappresentano innanzitutto un esercizio iterativo di Project Management. La distribuzione dell’effort per fasi del ciclo di vita ugualmente non può dare riscontri utili per un nuovo progetto se i precedenti non hanno effettuato assegnazioni alle fasi in modo analogo l’un l’altro, così come la classificazione di un task all’una o all’altra tipologia, con effetto sui pesi. I PSU derivati nell’organizzazione “X” sicuramente differiranno da quelli calcolati nell’Organizzazione “Y”, poiché debbono rispondere e far metro sui progetti e sulla maniera di esprimerli nell’ambito di ogni singola Organizzazione.

Per questi motivi quelli che il PMBOK identifica essere i due “tool” principali nel processo 6.3 di Activity Duration Estimation, ovverosia l’expert judgement e l’analogous estimating non possono – né debbono - in alcun modo essere soppiantati dall’uso asettico di una tecnica o metodologia proposta nella letteratura o dal mercato, ma dovrebbero invece rinforzarsi ed essere sorrette da queste.

In ogni caso la validazione sulla bontà o meno di un modello di stima è facilmente verificabile da un punto di vista statistico; più difficile è invece poter correggere il tiro sui giusti driver se non si dispone di una buona quantità di dati storici.

   

Bibliografia

[BUGL03a]

Buglione L., Misurare il Software. Quantità, qualità, standard e miglioramento di processo nell’ICT, 2° edizione, Franco Angeli, FA724.20, ISBN 88-464-4634-8, Maggio 2003, URL: http://www.geocities.com/lbu_measure/libri/mis.htm

[BUGL03b]

Buglione L., Dimensionare il software: qual è il giusto metro? White Paper, 11/10/2003, Bloom!, URL: http://www.bloom.it/buglione1.htm

[IEEE90]

IEEE, Std 610.12-1990 - IEEE Standard Glossary of Software Engineering Terminology, Institute of Electrical and Electronics Engineers, September 1990

[IFPU03]

IFPUG, Framework for Functional Sizing, Version 1.0, September 2003), International Function Point User Group, Westerville, Ohio, January 2004, URL: http://www.ifpug.org

[IFPU04]

IFPUG, Function Points Counting Practices Manual (release 4.2), International Function Point User Group, Westerville, Ohio, January 2004, URL: http://www.ifpug.org

[ISO01]

ISO/IEC 9126-1:2001, Software Engineering-Product Quality-Part 1: Quality Model: ISO and IEC, 2001

[ISO02]

ISO/IEC 20968:2002, Software Engineering-MK II Function Point Analysis- Counting Practices Manual: ISO and IEC, 2002

[ISO03]

ISO/IEC 19761:2003, Software Engineering-Cosmic FPP-A functional Size Measurement Method: ISO and IEC, 2003

[ISO05]

ISO/IEC, IS 24570:2005 - Software engineering -- NESMA functional size measurement method version 2.1 -- Definitions and counting guidelines for the application of Function Point Analysis, International Organization for Standardization, 2005

[ISO14143]

ISO/IEC14143-x:1998, Information Technology-Software Measurement-Functional Size Measurement-Parts 1-5, International Organization for Standardization, 1998-2004

[ISO98]

ISO/IEC14143-1:1998, Information Technology-Software Measurement-Functional Size Measurement-Part 1: Definitions of Concepts: International Organization for Standardization, 1998

[JONE96]

Jones C., Applied Software Measurement: assuring productivity and quality, 2/e, McGraw-Hill, 1996, ISBN 0070328269

[MELI97]

Meli R., Punti Funzione Anticipati: un nuovo metodo di stima per i progetti software, Proceedings of the 8th ESCOM Conference, Berlin, May  26-28, 1997, URL: http://www.dpo.it

 

 

Appendice A: Metodi di stima “anticipati” e “standard” della dimensione del software

 

Metodi Anticipati (PSU)

Metodi Standard (FPA)

Fase SLC applicazione

Pianificazione (livello L-1)

Disegno (livello L-2)

Livello di accuratezza

Minore dei metodi standard (media)

Maggiore dei metodi anticipati (media)

Parametri controllo per accuratezza stime

In entrambi i casi, andranno confrontati MRE e Pred(0.25) di progetto sull’effort stimato attraverso il size e consuntivato al termine del progetto e il MMRE e il Pred(0.25) sull’intero set di progetti inclusi nel database storico utilizzato per il sistema previsionale

Livello informativo necessario

Documentazione dalla fase di Bid

Documentazione della fase di Analisi

Skill richiesti per stima

Project team

Contatore Function Points (preferibilmente certificato, CFPS)

Tempo richiesto per stima

0.5 m/d (per conteggi PSU)

1.5-2 m/d (per conteggi FPA)

Vantaggi

·  Rapidità nel calcolo

·  non richiesta conoscenza FPA

·  stima del progetto effettuabile prima di iniziare l’Analisi & Disegno

· Maggior accuratezza nel calcolo del size da usare per la stima

· Comparabilità esterna dei risultati

Svantaggi

· Minor accuratezza nel calcolo del size da usare per la stima, verifica livello di correlazione con la tecnica “standard”

· Comparabilità interna dei risultati

· Maggior lavoro per derivare il numero di FPs

· Richiesta conoscenza FPA

· stima del progetto effettuabile prima di iniziare la fase di Costruzione (codifica)

Annotazioni

Sperimentale ed interna, in corso di validazione.

 

Consolidata e diffusa, con regole di conteggio in costante monitoraggio da parte di organi internazionali

 

 


[1] In modo meno granulare di quanto faccia la IEEE [IEEE90] che ne prevede di 6 tipi (design, functional, implementation, interface, performance, physical) e che [IFPU03, p.6] pone in corrispondenza dei requisiti ISO di tipo tecnico, con la sola eccezione dei “functional” e di quelli di tipo “interface”, per la parte relativa agli aspetti transazionali.

[2] I valori sono puramente indicativi e funzionali alla trattazione.

[4] http://www.isbsg.org/html/R9%20Field%20Descriptions.doc

A) École de Technologie Supérieure - ETS
1100 Notre-Dame Ouest,
Montréal, Canada  H3C 1K3
E-mail: luigi.buglione@computer.org  

Pagina precedente

Indice dei contributi