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

Transcript

1 Calcolo della Dimensione Funzionale e della Produttività con il metodo IFPUG (CPM 4.3.1) Questo documento contiene materiale estratto dal manuale IFPUG sulle Regole di Conteggio. È stato riprodotto in questo documento con il permesso dell IFPUG 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.

2 INDICE 1. Premessa Obiettivo del documento Function Point Analysis (FPA) Struttura del documento Case Study di conteggio Function Point Descrizione dello scenario Determinare Scopo e Ambito del Conteggio Definire il Confine dell applicazione Determinazione dei Requisiti Utente Misurazione della dimensione funzionale Misurazione delle funzioni di tipo dati Misurazione delle funzioni di tipo transazionale Conteggio in Function Point Determinazione della Produttività Individuazione del campione Calcolo della Produttività Benchmark Lo studio Tabella comparativa Fonti 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 Pagina 2 di 16

3 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 ). 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 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 : 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 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 runtime proprietario, sia lato client che lato server. Per ulteriori informazioni su WebRatio. si acceda a DDway è partner WebRatio e possiede un Centro di Competenza WebRatio con risorse certificate IFML. Pagina 3 di 16

4 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 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 : 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 4 di 16

5 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 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 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 5 di 16

6 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. Utente Sistema di Anagrafica Pianificazione Lavori Esecuzione Lavori Figura 2: Confine dell applicazione 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. Pagina 6 di 16

7 2.2 MISURAZIONE DELLA DIMENSIONE FUNZIONALE 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 Anagrafica centrale sub-elementi Anagrafica sub-elementi Richiesta lavoro Lavoro Delibera Lavoro Tipo EIF ILF ILF ILF 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 7 di 16

8 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 >50 EIF ILF Tipo RET 1 Bassa Bassa Media Bassa Bassa Media Alta Complessità Funzionale Media 7 10 >5 Media Alta Alta Alta 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à 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 Function Points Pagina 8 di 16

9 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: Anagrafica esterna (EIF) Nuova Richiesta Lavoro EI Modifica Richiesta Lavoro EI Visualizza Richiesta Lavoro EQ Esporta Lista Richiesta Lavoro EQ Richiesta lavoro (ILF) Accettazione Lavoro EI Popola sub-elemento in Anagrafica - EI Visualizza lavori EQ Esporta lavori EO Lavoro (ILF) Delibera Lavoro EI Anagrafica Elementi (ILF) Visualizza Delibera EQ Esporta Lista Delibere EO Delibera lavoro (ILF) ILF/EIF in lettura ILF in scrittura o in lettura/scrittura Modifica Delibera EI 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. Pagina 9 di 16

10 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 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 Tipo 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 10 di 16

11 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 DET Tipo EO/EQ > >19 EI EO EQ FTR 0-1 Bassa Bassa Media 0-1 Bassa Bassa Media Bassa Bassa Media Alta FTR 2-3 Bassa Media Alta Complessità Funzionale Media >2 Media Alta Alta >3 Media Alta Alta Alta Tabella 5: Complessità funzionale delle funzioni di tipo transazionale Pagina 11 di 16

12 Nella seguente tabella è riportato il conteggio in FP della baseline relativamente alle funzioni di tipo transazionale: Descrizione Tipo FTR DET Complessità 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 Function Points Pagina 12 di 16

13 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à 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 Function Points 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 = ( ) 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 13 di 16

14 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 = ( ) 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 14 di 16

15 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 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* Visual Basic Java SQL C C PL/ C# COBOL ABAP DDWay con WebRatio 1, (tratto dal sito e riferito allo studio condotto dall azienda ISBSG ) 4.3 FONTI Per la definizione di Produttività (Project Delivery Rate) tramite i Function Point: Per lo studio condotto da ISBSG e per la tabella comparativa: Pagina 15 di 16

16 DDway srl Sede legale: Via di Spini, Trento (TN) Tel.: Fax: info@ddway.it CF/N R.I P.IVA Cap. Soc. Euro Soc. contr. art C.C. da Dedagroup Spa (TN) SEDI OPERATIVE Assago (MI) Centro Direzionale Milanofiori Strada 3, Palazzo B Assago (MI) T F Roma Via Paolo di Dono, Roma T F Padova Via San Crispino, Padova T F Torino Strada Pianezza, Torino T F copyright DDway S.r.l. P.Iva Sede legale: Via di Spini, Trento (TN) T F info@ddway.it