Calcolo della Dimensione Funzionale e della Produttività ...€¦ · di studio l’appliazione pratia del metodo è inframezzata da ampie parti do Àe il metodo iene dettagliato

Calcolo della Dimensione Funzionale e della Produttività con il metodo IFPUG (CPM 4.3.1)

L’esperienza DDway con WebRatio

Copyright © DDway s.r.l. Tutti i diritti sono riservati. Nessuna parte della presente pubblicazione può esser riprodotta od usata in qualunque forma e con qualsiasi mezzo (comprese le fotocopie, le registrazioni magnetiche od altro), senza il preventivo consenso scritto della società DDWAY.

Questo documento contiene materiale estratto dal manuale IFPUG sulle Regole di Conteggio. È stato riprodotto in questo documento con il permesso dell’IFPUG

Calcolo della Dimensione Funzionale e della Produttività con il metodo IFPUG (CPM 4.3.1) - L’esperienza DDway con WebRatio

Pagina 2 di 16

INDICE

1. Premessa ..................................................................................................................... 3

1.1 Obiettivo del documento ................................................................................................................ 4 1.2 Function Point Analysis (FPA) ......................................................................................................... 4 1.3 Struttura del documento ................................................................................................................ 4

2. Case Study di conteggio Function Point ...................................................................... 5 2.1 Descrizione dello scenario .............................................................................................................. 5

2.1.1 Determinare Scopo e Ambito del Conteggio ...................................................................................................... 5 2.1.2 Definire il Confine dell’applicazione .................................................................................................................. 5 2.1.3 Determinazione dei Requisiti Utente ................................................................................................................. 6

2.2 Misurazione della dimensione funzionale .......................................................................................... 7 2.2.1 Misurazione delle funzioni di tipo dati ............................................................................................................... 7 2.2.2 Misurazione delle funzioni di tipo transazionale ................................................................................................. 9

2.3 Conteggio in Function Point .......................................................................................................... 13

3. Determinazione della Produttività ............................................................................ 14 3.1 Individuazione del campione ........................................................................................................ 14 3.2 Calcolo della Produttività .............................................................................................................. 14

4. Benchmark ................................................................................................................ 15 4.1 Lo studio .................................................................................................................................... 15 4.2 Tabella comparativa .................................................................................................................... 15 4.3 Fonti .......................................................................................................................................... 15

Figura 1: Panoramica grafica del processo di conteggio dei function point ............................................ 5

Figura 2: Confine dell’applicazione .......................................................................................................... 6

Tabella 3: Complessità funzionale delle funzioni di tipo dati ................................................................... 8

Figura 4: Scenario di riferimento ............................................................................................................. 9

Tabella 5: Complessità funzionale delle funzioni di tipo transazionale .................................................. 11


Pagina 3 di 16

1. PREMESSA

L’ International Function Point Users’ Group (IFPUG) è un'organizzazione no-profit governata dai suoi membri. La missione di IFPUG è quella di essere un leader riconosciuto nel promuovere e incoraggiare la gestione efficace delle attività di sviluppo e manutenzione del software applicativo attraverso l'uso della Function Point Analysis (FPA) e altre tecniche di misura del software.

Il presente documento fa riferimento al Manuale delle Regole di Conteggio (CPM) di IFPUG nella versione 4.3.1, in particolare nella versione tradotta in lingua italiana (ISBN 978-0-9830330-1-1). Come da prassi in questo tipo di studio l’applicazione pratica del metodo è inframezzata da ampie parti dove il metodo viene dettagliato.

Per ulteriori informazioni su IFPUG, FPA e CPM si acceda a http://www.ifpug.org/

DDway S.r.l. è la società di System Integration e Consulenza di Dedagroup ICT Network, gruppo che opera nel mercato dell’ICT fornendo soluzioni software, competenze e servizi per banche e istituzioni finanziarie, pubblica amministrazione e industria.

DDway è certificata UNI EN ISO 9001:2008 nel Settore EA : 33 – 35.

Il proprio centro di competenza metodologico dispone di oltre 200 risorse con competenze di tipo metodologico e 160 certificazioni su circa 30 diversi framework per la gestione dei servizi IT e dei progetti informatici, come: PMI, ITIL, ISO/IEC, IFPUG, etc.

Ad oggi 14 risorse tra CFPS Fellow, CFPS e CFPP sono certificate IFPUG.

DDway s.r.l. in qualità di membro IFPUG può riprodurre parti del Manuale delle Regole di Conteggio all’interno dei propri manuali sulle regole di conteggio.

Per ulteriori informazioni su DDway s.r.l. si acceda a http://www.ddway.it/

WebRatio s.r.l. è un’azienda di sviluppo software nata nel 2001 con competenze nell’ottimizzazione e nell’aumento di produttività dei processi di sviluppo di applicazioni ed ha creato il linguaggio IFML (Interaction Flow Modeling Language) che permette di definire visualmente le applicazioni senza scrivere codice di programmazione ed è indipendente dalla tecnologia utilizzata.

WebRatio offre piattaforme di sviluppo Web e mobile, come WebRatio Web Platform, un ambiente (IDE) integrato nella piattaforma Eclipse che fa uso “intensivo” dello standard IFML per definire il flusso di interazione dell’utente con l'applicazione. WebRatio Platform genera applicazioni Web per l'esecuzione su qualsiasi Java Application Server. Il codice generato è aperto e basato su standard, senza l’utilizzo di alcun run-time proprietario, sia lato client che lato server.

Per ulteriori informazioni su WebRatio. si acceda a http://www.webratio.com/

DDway è partner WebRatio e possiede un Centro di Competenza WebRatio con risorse certificate IFML.

http://www.ifpug.org/

http://www.ddway.it/

http://www.webratio.com/


Pagina 4 di 16

1.1 OBIETTIVO DEL DOCUMENTO

Il presente documento ha l’obiettivo di determinare la produttività realizzata dal nostro Centro di Competenza utilizzando la piattaforma di sviluppo applicativo IFML WebRatio Web Platform. Si vuole usare questa informazione per valutare l’incremento di produttività rispetto ai benchmark di sviluppo su piattaforme tradizionali.

Per raggiungere questo obiettivo è necessario determinare la ‘dimensione’ di un tipico progetto, come esemplificativo di altri progetti di sviluppo e manutenzione evolutiva.

La dimensione funzionale dell’intervento è stata effettuata utilizzando la Function Point Analysis (FPA).

1.2 FUNCTION POINT ANALYSIS (FPA)

Il metodo di misurazione della dimensione funzionale IFPUG è conosciuto come analisi dei function point (FPA, Function Point Analysis) e le sue unità di misurazione prendono il nome di Function Point (FP). E’ uno standard internazionale per misurare la dimensione di prodotti software al fine di:

Supportare analisi di qualità e produttività;

Stimare costi e risorse necessari per lo sviluppo, miglioramento e manutenzione del software;

Fornire un fattore di normalizzazione per confrontare diversi software;

Determinare la dimensione di un pacchetto applicativo acquistato attraverso la quantificazione di tutte le funzionalità incluse nel pacchetto;

Assistere gli utenti nel determinare il beneficio di un pacchetto applicativo per le loro organizzazioni derivante dal dimensionamento funzionale che soddisfi specificatamente i loro requisiti.

Gli obiettivi della FPA sono

Misurare le funzionalità implementate nel software, che l’utente richiede e riceve;

Misurare le funzionalità impattate dallo sviluppo, manutenzione evolutiva e correttiva del software indipendentemente dalla tecnologia utilizzata per la realizzazione.

Tale modalità è aderente a quanto definito dall’ International Function Point Users Group (IFPUG) nel Manuale delle Regole di Conteggio (CPM) nella versione 4.3.1. Questo Standard internazionale è, al momento, l’ultima versione del ciclo di miglioramento continuo del metodo IFPUG che promuove l’interpretazione coerente della misurazione della dimensione funzionale in conformità con ISO/IEC 14143-1:2007.

1.3 STRUTTURA DEL DOCUMENTO

Il presente documento è suddiviso nelle seguenti parti:

Premessa

Descrizione dello Scenario: • Determinare scopo e ambito del conteggio • Definire il confine dell’applicazione • Identificare i requisiti utente funzionali

Misura della dimensione funzionale (Functional Size Measurement - FSM): • Identificare e misurare le funzioni di tipo dati • Identificare e misurare le funzioni di tipo transazionale • Calcolare la dimensione funzionale

Determinazione della produttività

Confronto con i benchmark


Pagina 5 di 16

2. CASE STUDY DI CONTEGGIO FUNCTION POINT

2.1 DESCRIZIONE DELLO SCENARIO

Per svolgere un conteggio in function point del progetto, si devono effettuare le seguenti attività per identificare e classificare le componenti funzionali di base (ILF, EIF, EI, EO, EQ) seguendo le prassi definite dall’IFPUG:

a. Raccolta della documentazione disponibile ed incontri di analisi con gli utenti funzionali (Functional User).

b. Determinazione dell’ambito del conteggio e del confine. c. Misurazione delle funzioni di tipo dati (ILF; EIF). d. Misurazione delle funzioni di tipo transazionali (EI; EO; EQ). e. Calcolo della dimensione funzionale in function point. f. Produzione della documentazione con il conteggio dei function point.

Figura 1: Panoramica grafica del processo di conteggio dei function point

2.1.1 Determinare Scopo e Ambito del Conteggio

Scopo del conteggio è determinare il livello di produttività raggiunto con una particolare piattaforma di sviluppo software dal nostro gruppo di lavoro.

Per raggiungere questo obiettivo è necessario determinare la ‘dimensione’ di un tipico progetto di manutenzione evolutiva, come esemplificativo di altri progetti di sviluppo e manutenzione evolutiva. Questo tipo di progetto si adatta meglio a definire un livello di produttività basato sull’uso dei Function Points in quanto quasi tutto il lavoro effettuato per eseguire l’intervento è strettamente correlato ai requisiti funzionali ed è quindi più semplice determinare l’effort di lavoro relativo.

Un progetto di manutenzione evolutiva è un progetto che ha l’obiettivo di sviluppare e rilasciare manutenzione adeguativa. Un progetto di manutenzione evolutiva può anche sviluppare e rilasciare manutenzioni di tipo correttivo e perfettivo, ma queste non forniscono un contributo alla dimensione funzionale del progetto di manutenzione evolutiva.

La dimensione funzionale di un progetto di manutenzione evolutiva misura le modifiche ad un’applicazione pre-esistente già installata, le quali aggiungono, modificano o cancellano funzioni utente. Le modifiche delle funzionalità potrebbero derivare da requisiti utente nuovi o rivisti, da cambiamenti nelle leggi/regolamenti o dai nuovi utenti.

2.1.2 Definire il Confine dell’applicazione

Il sistema “Pianificazione Lavori” ha l’obiettivo di gestire richieste di lavoro e di validarne la programmazione attraverso delibere.

Il sistema viene alimentato da un “Sistema di Anagrafica” centrale relativamente ai dati degli elementi su cui vengono effettuati i Lavori.


Pagina 6 di 16

Le Richieste di Lavoro dopo essere state approvate (deliberate) sono trasmesse al sistema esterno di “Esecuzione Lavori” per la fase esecutiva.

Nella figura seguente il confine dell’applicazione oggetto di misurazione.

Figura 2: Confine dell’applicazione

2.1.3 Determinazione dei Requisiti Utente

In sede di analisi con gli utenti funzionali è stato definito il perimetro dell’intervento identificando le funzionalità da modificare e/o da aggiungere alla applicazione pre-esistente.

L’oggetto dell’intervento nasce dalla necessità di integrare le funzionalità preesistenti del sistema con la possibilità di gestire i lavori per un particolare dettaglio dell’elemento in anagrafica centrale, un sub-elemento denominato Gruppo.

In particolare sono state richieste:

estrazione dei nuovi sub-elementi dal Sistema di Anagrafica

creazione della nuova anagrafica dei sub-elementi di tipo Gruppo mantenuta dall’applicazione

modifiche alle entità “Richiesta Lavoro”, “Lavoro” e “Delibera Lavoro”

modifiche al processo di creazione, aggiornamento, trasmissione, accettazione e delibera lavori (da interfaccia e batch) per gestione sub-elementi;

modifiche alle funzionalità di visualizzazione per il display dei nuovi dati;

nuove funzionalità di esportazione;

implementazione di nuovi controlli.

Utente

Pianificazione Lavori

Sistema di Anagrafica

Esecuzione Lavori


Pagina 7 di 16

2.2 MISURAZIONE DELLA DIMENSIONE FUNZIONALE

2.2.1 Misurazione delle funzioni di tipo dati

L’identificazione delle funzioni di tipo dato è stata eseguita sulla base delle seguenti regole:

1. Classificare come ILF, se il gruppo di dati è mantenuto dall’applicazione che si sta misurando. 2. Classificare come un EIF, se il gruppo di dati:

a. è referenziato, ma non manutenuto, dall’applicazione che si sta misurando b. è identificata come ILF in una o più ulteriori applicazioni

Le seguenti funzioni di tipo dato risultano aggiunte o modificate durante il progetto di manutenzione evolutiva:

Descrizione funzione di tipo dati Tipo

Anagrafica centrale sub-elementi EIF

Anagrafica sub-elementi ILF

Richiesta lavoro ILF

Lavoro ILF

Delibera Lavoro ILF

L’anagrafica centrale dei sub-elementi è un nuovo EIF referenziato ma non mantenuto dall’applicazione.

Per ogni ILF ed EIF sono stati contati il numero di RET e DET per determinare la complessità.

Per il conteggio dei DET sono state applicate le regole di conteggio:

1. Contare un DET per ciascun campo unico, riconoscibile dall’utente, non ripetuto, mantenuto nella o reperito dalla funzione di tipo dati attraverso l’esecuzione di un qualsiasi processo elementare nell’ambito del conteggio.

2. Quando due applicazioni mantengono e/o referenziano la stessa funzione di tipo dati, contare solo i DET effettivamente utilizzati dall’applicazione misurata.

3. Contare un DET per ogni singolo dato richiesto dall’utente per stabilire una relazione con un'altra funzione di tipo dati.

4. Riesaminare gli attributi correlati per determinare se questi sono raggruppati e conteggiati come un singolo DET oppure se sono conteggiati come DET multipli; il raggruppamento dipenderà da come i processi elementari utilizzano gli attributi nell’ambito dell’applicazione.

Per il conteggio dei RET sono stati identificati i sottogruppi in base alle regole di conteggio:

1. Contare un RET per ogni funzione di tipo dati (cioè, di default ogni funzione di tipo dati ha un sottogruppo di DET che deve essere conteggiato come un RET).

2. Contare un RET aggiuntivo per ognuno dei seguenti ulteriori sottogruppi logici di DET (nella funzione di tipo dati) che contiene più di un DET:

a. entità associativa con attributi non-chiave, b. entità sotto-tipo (ulteriore rispetto al primo dei sotto-tipi) c. entità attributiva, in una relazione 1-1 non obbligatoria.

L’anagrafica dei sub-elementi è un nuovo gruppo di dati mantenuto dall’applicazione.

I sub-elementi sono un sottotipo dell’elemento; il gruppo di dati non è quindi un nuovo ILF ma un RET aggiuntivo dell’anagrafica elementi.


Pagina 8 di 16

Nella seguente tabella sono riportati i RET ed i DET per ogni funzione di tipo dato che deve essere modificata durante il progetto di manutenzione evolutiva:

Descrizione Tipo

Intervento Tipo RET DET

Anagrafica centrale sub-elementi ADD EIF 1 16

Anagrafica elementi CHG ILF 2 30

Richiesta lavoro CHG ILF 1 45

Lavoro CHG ILF 1 70

Delibera Lavoro CHG ILF 1 47

Sulla base del numero di DET e di RET viene determinata la complessità funzionale degli ILF e degli EIF applicando le seguenti regole:

ILF/EIF DET

Tipo

1-19 20-50 >50

EIF ILF

RET

1 Bassa Bassa Media

Complessità Funzionale

Bassa 5 7

2-5 Bassa Media Alta

Media 7 10

>5 Media Alta Alta

Alta 10 15

Tabella 3: Complessità funzionale delle funzioni di tipo dati

Nella seguente tabella è riportato il conteggio in FP per ogni funzione di tipo dato che deve essere modificata durante il progetto di manutenzione evolutiva:

Descrizione Tipo RET DET Complessità Function

Points

Anagrafica centrale sub-elementi EIF 1 16 Bassa 5

Anagrafica elementi ILF 2 30 Media 10

Richiesta lavoro ILF 1 45 Bassa 7

Lavoro ILF 1 70 Media 10

Delibera Lavoro ILF 1 47 Bassa 7


Pagina 9 di 16

2.2.2 Misurazione delle funzioni di tipo transazionale

Nello scenario di riferimento gli ILF e gli EIF mantenuti all’interno dell’applicazione sono rappresentati insieme alle funzioni di tipo transazionale:

Figura 4: Scenario di riferimento

Sono state quindi analizzate le funzioni di tipo transazionale applicando le regole della FPA:

Identificare ogni Processo Elementare (PE) richiesto dall’utente

Determinare l’univocità del/dei PE

Classificare ogni PE in External Input (EI), External Output (EO), o External Inquiry (EQ)

Conteggiare i Tipi di File Referenziati (FTR) per ogni funzione di tipo transazionale

Conteggiare i Tipi di Elementi Dati (DET) per ogni funzione di tipo transazionale

Determinare la complessità funzionale per ogni funzione di tipo transazionale

Determinare la dimensione funzionale per ogni funzione di tipo transazionale

Le regole per definire se un processo è elementare sono:

1. Comporre e/o decomporre i Requisiti Funzionali Utente nella più piccola unità di attività, che soddisfa tutti i seguenti punti:

a. è significativa per l’utente. b. costituisce una transazione completa c. è autonoma d. lascia l’applicazione oggetto di conteggio in uno stato di coerenza funzionale

2. Per ogni unità di attività indentificata identificare un processo elementare che soddisfa tutti i criteri sopraindicati.

Una volta identificati, i PE sono stati classificati in EI, EO o EQ.

Anagrafica esterna

(EIF)

Anagrafica Elementi

(ILF)

Richiesta lavoro (ILF)

Lavoro (ILF)

Delibera lavoro (ILF)

Visualizza Richiesta Lavoro – EQEsporta Lista Richiesta Lavoro – EQ

Visualizza Delibera – EQEsporta Lista Delibere – EO

Visualizza lavori – EQEsporta lavori – EO

Popola sub-elemento in Anagrafica - EI

Accettazione Lavoro – EI

Delibera Lavoro – EI

Modifica Delibera – EI

Nuova Richiesta Lavoro – EIModifica Richiesta Lavoro – EI

ILF/EIF in lettura

ILF in scrittura o in lettura/scrittura


Pagina 10 di 16

Le regole di conteggio dell’EI sono:

1. Il suo intento primario è di: • mantenere uno o più ILF oppure • alterare il comportamento del sistema

2. Include processi logici per l’inserimento dei dati o informazioni di controllo che attraversano il confine dell’applicazione.

Le regole di conteggio dell’EO sono:

1. Ha l’intento primario di presentare informazioni all’utente e 2. Include almeno una delle seguenti forme di trattamento logico:

• vengono eseguiti calcoli matematici • sono mantenuti uno o più ILF • sono creati dati derivati • risulta alterato il comportamento del sistema

Le regole di conteggio dell’EQ sono:

1. Ha l’intento primario di presentare informazioni all’utente e • referenzia una funzione di tipo dati per reperire dati o informazioni di controllo e • non soddisfa i criteri per essere classificato come un EO

La baseline di progetto è composta dalle seguenti funzioni di tipo transazionale, modificate durante il progetto di manutenzione evolutiva.

Descrizione Tipo

Intervento Tipo

Nuova richiesta lavoro per sub-elemento ADD EI

Modifica richiesta lavoro per sub-elemento ADD EI

Visualizza richiesta lavoro CHG EQ

Esporta lista richieste ADD EQ

Accettazione lavori CHG EI

Visualizza lavoro CHG EQ

Esporta lista lavori ADD EO

Delibera Lavoro CHG EI

Modifica Delibera ADD EI

Visualizza Delibera CHG EQ

Esporta Delibere ADD EO

Popola sub-elemento in Anagrafica elementi ADD EI

L’implementazione dei nuovi controlli richiesti non è un nuovo processo elementare perché non è una attività autonoma.

Le nuove funzionalità richieste di esportazione Lavori e Delibere sono External Output in quanto sono presenti dati derivati.

Una volta identificati le funzioni di tipo transazionale sono stati contati i Tipi di File Referenziati (FTR) ed il numero di tipi di Elementi Dati (DET) secondo le seguenti regole:

1. Conta un FTR per ogni funzione dati unica alla quale la funzione transazionale accede (in lettura e/o scrittura)


Pagina 11 di 16

2. Conta un DET per ogni attributo riconoscibile dall’utente, non ripetuto, che entra o esce dal confine dell’applicazione durante l’esecuzione della funzione transazionale.

3. Conta un solo DET per la capacità di inviare un messaggio di risposta del sistema all’esterno del confine dell’applicazione anche nel caso di messaggi multipli

4. Conta un solo DET per la capacità di specificare un’azione da intraprendere, anche qualora vi siano molteplici modi per richiamare lo stesso trattamento logico.

5. Non contare i seguenti elementi come DET: • Costanti quali titoli dei report, identificativi delle schermate o dei pannelli, intestazione delle colonne

o descrizione degli attributi • Notazioni generate automaticamente dall’applicazione quali data e orario • Numeri di pagina variabili o informazioni riguardanti il posizionamento (ad esempio Righe da 37 a 54 di

211) • Aiuti navigazionali quali la possibilità di movimento all’interno di una lista usando “precedente”,

“prossimo”, “primo”, “ultimo” e oggetti grafici equivalenti. • Attributi generati all’interno del confine da una funzione transazionale e salvati all’interno di un ILF

che non escono dal confine stesso. • Attributi reperiti o referenziati da un ILF o EIF necessari alla elaborazione ma che non escono dal

confine.

Nella seguente tabella sono riportati gli FTR ed i DET conteggiati nella baseline del progetto per ciascuna funzione di tipo dato.

Descrizione Tipo FTR DET

Nuova richiesta lavoro per sub-elemento EI 2 40

Modifica richiesta lavoro per sub-elemento EI 2 41

Visualizza richiesta lavoro EQ 2 37

Esporta lista richieste EQ 2 28

Accettazione lavori EI 3 40

Visualizza lavoro EQ 2 54

Esporta lavori EO 2 32

Delibera Lavoro EI 3 58

Modifica Delibera EI 3 37

Visualizza Delibera EQ 2 18

Esporta Delibere EO 2 28

Popola sub-elemento in Anagrafica elementi EI 2 18

Sulla base del numero di FTR e di DET è stata determinata la complessità funzionale applicando le seguenti regole:

EI

DET

EO/EQ

DET

Tipo

1-4 5-15 >15 1-5 6-19 >19 EI EO EQ

FTR

0-1 Bassa Bassa Media

FTR

0-1 Bassa Bassa Media

Complessità Funzionale

Bassa 3 4 3

2 Bassa Media Alta 2-3 Bassa Media Alta Media 4 5 4

>2 Media Alta Alta >3 Media Alta Alta Alta 6 7 6

Tabella 5: Complessità funzionale delle funzioni di tipo transazionale


Pagina 12 di 16

Nella seguente tabella è riportato il conteggio in FP della baseline relativamente alle funzioni di tipo transazionale:

Descrizione Tipo FTR DET Complessità Function

Points

Nuova richiesta lavoro per sub-elemento EI 2 40 Alta 6

Modifica richiesta lavoro per sub-elemento EI 2 41 Alta 6

Visualizza richiesta lavoro EQ 2 37 Alta 6

Esporta lista richieste EQ 2 28 Alta 6

Accettazione lavori EI 3 40 Alta 6

Visualizza lavoro EQ 2 54 Alta 6

Esporta lavori EO 2 32 Alta 7

Delibera Lavoro EI 3 58 Alta 6

Modifica Delibera EI 3 37 Alta 6

Visualizza Delibera EQ 2 18 Alta 6

Esporta Delibere EO 2 28 Alta 7

Popola sub-elemento in Anagrafica elementi EI 2 18 Alta 6


Pagina 13 di 16

2.3 CONTEGGIO IN FUNCTION POINT

Il dimensionamento funzionale del progetto di manutenzione evolutiva è stato calcolato identificando le funzioni di tipo dati (ILF ed EIF) e di tipo transazionali (EI, EO e EQ) oggetto di modifica (indicate con CHG) insieme alle nuove funzionalità richieste (indicate con ADD).

Nella seguente tabella è riportato il dettaglio delle modifiche richieste.

Descrizione Tipo Mod

Tipo FTR/RET DET Complessità Function

Points

Anagrafica esterna sub-elementi ADD EIF 1 17 Bassa 5

Anagrafica elementi CHG ILF 2 24 Media 10

Richiesta lavoro CHG ILF 1 45 Bassa 7

Lavoro CHG ILF 1 70 Media 10

Delibera Lavoro CHG ILF 1 47 Bassa 7

Nuova richiesta lavoro per sub-elemento ADD EI 2 40 Alta 6

Modifica richiesta lavoro per sub-elemento ADD EI 2 41 Alta 6

Visualizza richiesta lavoro CHG EQ 2 37 Alta 6

Esporta lista richieste ADD EQ 2 28 Alta 6

Accettazione lavori CHG EI 3 40 Alta 6

Visualizza lavoro CHG EQ 2 54 Alta 6

Esporta lavori ADD EO 2 32 Alta 7

Delibera Lavoro CHG EI 3 58 Alta 6

Modifica Delibera ADD EI 3 37 Alta 6

Visualizza Delibera CHG EQ 2 18 Alta 6

Esporta Delibere ADD EO 2 28 Alta 7

Popola sub-elemento in Anagrafica elementi ADD EI 3 6 Alta 6

Totale ADD = 49 FP

Totale CHGA = 64 FP

La formula applicata al progetto di sviluppo per calcolare i FP dell’intervento è:

EFP = ADD + CHGA + CFP + DEL = (49 + 64 + 0 + 0) FP = 113 FP

dove :

• EFP è il è il numero di function point del progetto di manutenzione evolutiva (Enhancement Function Point),

• ADD è la dimensione delle funzioni che sono state aggiunte dal progetto di manutenzione evolutiva (ADDed Function Point),

• CHGA è la dimensione delle funzioni che sono state cambiate dal progetto di manutenzione evolutiva – come sono/saranno dopo l’implementazione (CHanGed Function Point After),

• CFP è la dimensione delle funzionalità di conversione (Conversion Function Point) che nel nostro scenario non sono presenti,

• DEL è la dimensione delle funzioni che sono state cancellate dal progetto di manutenzione evolutiva (DELeted Function Point) che nel nostro scenario non sono presenti.


Pagina 14 di 16

3. DETERMINAZIONE DELLA PRODUTTIVITÀ

3.1 INDIVIDUAZIONE DEL CAMPIONE

L’obiettivo del Case Study nel suo complesso è quello di determinare la produttività in Punti Funzione realizzata dal nostro Centro di Competenza utilizzando la piattaforma di sviluppo applicativo IFML WebRatio Web Platform.

Per raggiungere questo obiettivo è necessario determinare la ‘dimensione’ di un tipico progetto di manutenzione evolutiva, come esemplificativo di altri progetti di sviluppo e manutenzione evolutiva.

La significatività del/dei campione/i è un elemento essenziale al fine di ottenere misure realmente rappresentative della produttività. E’ stato quindi selezionato al capitolo precedente, tra gli interventi effettuati, come esemplificativo di altri analoghi interventi svolti negli ultimi tempi con WebRatio, uno tra quelli che per caratteristiche si prestava meglio di altri a valutarne la produttività in Punti Funzione.

Il tipo di intervento scelto per il calcolo riguarda l’implementazione di nuove funzionalità su una baseline consolidata. Si tratta in effetti di un caso particolare di un progetto di manutenzione evolutiva la cui dimensione funzionale va calcolata utilizzando la formula:

EFP = ADD + CHGA + CFP + DEL

dove nel nostro caso sono nulli i termini CFP e DEL e quindi:

EFP = ADD + CHGA

Questo tipo di intervento meglio si adatta a determinare un valore di produttività basato sull’uso dei Punti Funzione in quanto:

si evita di includere nella stima il lavoro necessario alla realizzazione delle componenti non funzionali che ricorrono in maniera ancora più significativa quando si realizza una nuova applicazione in un nuovo ambito e che sono invece generalmente meno presenti durante i progetti di manutenzione evolutiva;

si evita di misurare la produttività su attività di cancellazione di funzioni preesistenti per il calcolo della produttività; in questo caso infatti, secondo il metodo, la misura dei punti funzione di una funzione da cancellare è la stessa della sua creazione ex-novo.

3.2 CALCOLO DELLA PRODUTTIVITÀ

Nel case study il numero di FP è:

EFP = (49 + 64 + 0 + 0) FP = 113 FP

Il team coinvolto nell’intero ciclo di realizzazione (progettazione, sviluppo e test, collaudo e rilascio) era formato da due specialisti WebRatio allocati full-time per 8 giornate lavorative.

Per la realizzazione dell’intervento l’impegno è stato di 16 giornate lavorative con una produttività media di:

113 FP/16 giorni = 7,06 FP per giorno = 148 FP per mese (1)

= 1,13 Ore/FP

La produttività del campione qui selezionato è stata confrontata con quella di altri interventi di dimensione funzionale simile realizzati dal Gruppo di Lavoro con WebRatio, ottenendo sempre valori paragonabili e all’interno di un range del ±10%.

(1) Si utilizza ai fini statistici un fattore di conversione pari a 21 giorni per mese


Pagina 15 di 16

4. BENCHMARK

A seguire viene presentato un confronto del risultato dell’analisi svolta sull’efficienza produttiva calcolata in FP con la produttività di sviluppo in progetti creati con un approccio tradizionale.

4.1 LO STUDIO

ISBSG, centro di ricerca no-profit per la raccolta dei dati e l’analisi del settore IT, ha condotto uno studio su piu di 6000 progetti utilizzando la misura dei Function Point per determinare la complessità e le dimensioni dei progetti progetto. Grazie alla raccolta ed il confronto dei dati, ISBSG ha ottenuto una misura di produttività dei progetti, il PDR (Product Delivery Rate), che equivale al numero di ore per rilasciare un Function Point.

http://www.isbsg.org/ISBSGnew.nsf/WebPages/BC9AD66DEC719C2BCA25745D001A2256

4.2 TABELLA COMPARATIVA

Dall’analisi di ISBSG è risultato un valore medio di 11 ore per creare e rilasciare un Funtion Point, quindi una media di 16 Funtion Point al mese.

Una tabella comparativa riassume il numero di ore necessarie per FP e il numero di FP al mese.

Linguaggio Ore per FP FP al mese

ASP* 06.1 28

Visual Basic 08.5 20

Java 10.6 16

SQL 10.8 16

C++ 12.4 14

C 13.0 13

PL/1 14.2 12

C# 15.5 11

COBOL 16.8 10

ABAP 19.9 9

DDWay con WebRatio 1,13 148

(tratto dal sito http://www.drdobbs.com/ e riferito allo studio condotto dall’azienda ISBSG )

4.3 FONTI

Per la definizione di Produttività (Project Delivery Rate) tramite i Function Point: http://www.isbsg.org/ISBSGnew.nsf/WebPages/BC9AD66DEC719C2BCA25745D001A2256

Per lo studio condotto da ISBSG e per la tabella comparativa: http://www.drdobbs.com/jvm/the-comparative-productivity-of-programm/240005881


http://www.drdobbs.com/


http://www.drdobbs.com/jvm/the-comparative-productivity-of-programm/240005881

http://www.drdobbs.com/jvm/the-comparative-productivity-of-programm/240005881

DDway srl Sede legale: Via di Spini, 50 – 38121 Trento (TN) Tel.: +39 06 515061 – Fax: +39 06 51506302 - [email protected] CF/N° R.I. 07374190580 - P.IVA 11300260152 Cap. Soc. Euro 6.750.000 Soc. contr. art. 2497 C.C. da Dedagroup Spa (TN)

SEDI OPERATIVE

Assago (MI) Centro Direzionale Milanofiori Strada 3, Palazzo B1

20090 Assago (MI) T. +39 02 577751 - F. +39 02 89202077

Roma Via Paolo di Dono, 73

00142 Roma

T. +39 06 515061 - F. 06 51506302

Padova Via San Crispino, 28 35129 Padova

T. +39 049 69831 - F. +39 049 773873

Torino Strada Pianezza, 289

10151 Torino T. +39 011 49041 - F. +39 011 4904300

copyright © DDway S.r.l. | P.Iva 11300260152

Sede legale: Via di Spini, 50 – 38121 Trento (TN) – T. +39 06 515061 – F. +39 06 51506302 Email. [email protected]

mailto:[email protected]

mailto:[email protected]

Documents

Calcolo della Dimensione Funzionale e della Produttività ...€¦ · di studio l’appliazione pratia del metodo è inframezzata da ampie parti do Àe il metodo iene dettagliato