Analisi delle tecniche IFPUG e COSMIC per la stima della dimensione delle funzionalità di un prodotto software

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Ingegneria del software Analisi delle tecniche IFPUG e COSMIC per la stima della dimensione delle funzionalità di un prodotto software Anno Accademico Candidato: Gianluigi Renzi matr. N

2 Se insisti e resisti raggiungi e conquisti. Ω Carlo Alberto Salustri (in arte Trilussa)

3 Ai miei genitori che mi hanno sempre supportato senza mai mettermi pressione. A mio nonno che sarebbe molto fiero di me. Ai miei amici, quelli di sempre. Ai miei compagni di avventura di questi tre anni e mezzo. A Valeria per il suo supporto nei momenti di difficoltà e per la condivisione dei momenti di gioia.... ii

4 Indice List of Figures v 1 Introduzione 1 2 FPA (Function Point Analysis) Stima dei costi Definizione FP Dal calcolo degli FP ad una stima dei costi effettiva IFPUG Il metodo Tipo di conteggio Confine applicativo Conteggio UFP Fattori correttivi Calcolo FP SNAP Esempio di utilizzo Testo esempio Tipo di conteggio e confine applicativo Calcolo UFP Calcolo FP Numero di linee di codice stimato COSMIC Il metodo Strategia di misurazione Fase di Mappatura Fase di misurazione Esempio di utilizzo: ACME Car Hire Strategia di misurazione Fase di mappatura Fase di mappatura Analogie e differenze standard IFPUG e COSMIC Analogie iii

5 iv 5.2 Differenze Esempio di confronto tra risultati Conversione tra i risultati dei due metodi Conclusioni Il metodo migliore? A Approfondimenti 23 A.1 Perchè il metodo COSMIC è indicato per i sistemi real-time A.2 Altri standard ISO Bibliografia 25 iv

6 Elenco delle figure 3.1 Tabella calcolo UFP Il metodo COSMIC Esempio divisione in strati Processo funzionale ed evento di innesco Fase di misurazione Tabella usata per la misurazione Interfacce utente del sistema d esempio ACME Car Hire parte Interfacce utente del sistema d esempio ACME Car Hire parte Interfacce utente del sistema d esempio ACME Car Hire parte Tabella calcolo CFP v

7 Capitolo 1 Introduzione Verso la fine degli anni 50 iniziarono ad essere sviluppati i primi linguaggi di alto livello e con essi nacque la figura professionale del programmatore; durante gli anni 60 vi fu lo sviluppo dei primi progetti di programmazione molto complessi i quali coinvolgevano un vasto numero di figure professionali. Le difficoltà riscontrate furono innumerevoli in quanto quasi sempre il budget non era rispettato e il tempo di conclusione del progetto andava oltre la consegna prestabilita. Queste problematiche aprirono le porte ad un periodo definito come Software crisis. Le conferenze e i dibattiti tra programmatori, che si tennero a cavallo tra gli anni 60 e 70, furono molteplici, tutte volte a trovare una soluzione a questi innumerevoli problemi legati allo sviluppo di prodotti software complessi. Da questi dibattiti nacque la necessità di applicare un metodo ingegneristico allo sviluppo software, metodo che sarebbe andato a sostituire il cosiddetto approccio Code and fix, il quale aveva caratterizzato la programmazione fino a quel momento. Nasce così l ingegneria del software ossia la disciplina che si occupa dello studio dei processi produttivi e della definizione di metodi e tecniche utili allo sviluppo del prodotto software. Con l avvento di questo metodo ingegneristico l approccio al prodotto software da parte dei programmatori cambia radicalmente. Allo stesso modo cambia radicalmente anche la visione del software, dato che il prodotto viene gestito in maniera differente durante il suo ciclo di vita (dalla concezione alla manutenzione passando per analisi dei requisiti progettazione e rilascio). Durante ogni fase viene progettata una determinata parte del prodotto software con relativa documentazione. Per quanto concerne lo sviluppo di software complessi, le novità introdotte con l avvento dell ingegneria del software ovviarono a molti problemi in quanto permisero una adeguata e strutturata suddivisione dei lavori tra i programmatori coinvolti nel progetto [1] [2]. 1

8 Capitolo 2 FPA (Function Point Analysis) 2.1 Stima dei costi L introduzione della figura dell ingegnere del software fu fondamentale per risolvere i problemi di sforamento di budget che si ebbero durante lo sviluppo dei primi prodotti software complessi. Fu proprio da tali errori che si comprese la fondamentale importanza legata alla pianificazione dei costi di produzione al fine di valutarne: i vantaggi dell investimento, il numero di progettisti e le future (possibili) applicazioni correttive. A differenza di altre discipline ingegneristiche nelle quali il costo totale del prodotto dipende molto dal costo dei materiali, nel caso del software tutto dipende da una stima del numero di progettisti che occorrono a completare lo sviluppo in un tempo stabilito. Affinché ciò sia possibile, occorre fare un attenta analisi della misura della produttività del personale coinvolto oltre che dell effettiva complessità del prodotto software da sviluppare. Occorre, inoltre, effettuare nuove stime e valutazioni in corso d opera, volte a operare azioni correttive laddove necessarie. La stima di costo preliminare può avvenire attraverso lo studio di precedenti prodotti simili a quello da sviluppare oppure attraverso l utilizzo di apposite metriche basate sull analisi dei requisiti. Le metriche sono uno strumento attraverso il quale l ingegnere valuta gli aspetti di processo, di gestione delle risorse e di prodotto. Tra le metriche software più utilizzate per la stima dei costi di produzione troviamo: la metrica dimensionale basata sul numero di righe di codice (LOC): una metrica molto semplice anche se spesso poco significativa dato che dipende molto dal linguaggio di programmazione utilizzato. Tramite il numero LOC è possibile effettuare stime di produttività rapportando LOC al numero di mesi/uomo 2

9 3 utili alla stesura del codice e stime di qualità rapportando LOC al numero di errori rilevati. È opportuno precisare come attraverso questa metrica non si ha un indicatore della complessità del codice ma solo della sua lunghezza. La metrica basata sui punti funzione (FP): verrà descritta nel prossimo paragrafo e dalla quale sarà possibile avere una buona stima del numero di righe di codice. 2.2 Definizione FP I punti funzione sono una metrica per la stima dei costi di un software. Essa è applicabile durante le fasi di analisi dei requisiti e non necessita della conoscenza della tecnologia che verrà utilizzata in fase di sviluppo; il metodo è stato inventato da Alan Albrecht, a cavallo tra gli anni 70 e 80, il quale sosteneva che era possibile predire le caratteristiche di un software contando gli oggetti che lo compongono. Lo scopo della Function Point Analysis è quello di introdurre una metrica volta allo studio delle funzionalità di un software basandosi sui requisiti dettati dal cliente. Grazie a vari studi è stato possibile quantificare la potenza dei vari linguaggi di programmazione calcolando quante linee di codice occorrono per codificare un singolo punto funzione (ad esempio Java e C++ 6 righe, Assembler 128 righe). Dunque tramite il calcolo di un punto funzione (che cambia in base alla standardizzazione, vedi dopo) è possibile misurare la produttività dei programmatori (FP per unità di tempo), costo del progetto e dimensione in linee di codice. Attualmente sono presenti varie standardizzazioni del metodo, ognuna delle quali utilizza riferimenti diversi per il conteggio ed il peso dei vari elementi che compongono il codice sorgente. Tra le standardizzazioni più importanti ed utilizzate troviamo COSMIC ed IFPUG che verranno trattate dettagliatamente nei prossimi paragrafi. 2.3 Dal calcolo degli FP ad una stima dei costi effettiva Come accennato in precedenza, nell ambito dello sviluppo software il costo è stimato in base al numero di progettisti coinvolti e al tempo che occorre per il completamento del progetto. Dal calcolo degli FP non si ha una quantificazione precisa riguardo al costo, ragion per cui una volta calcolato il valore FP (indipendentemente dallo standard utilizzato) è possibile effettuare una stima dei costi misurata in mesi-uomo (people-month-pm) attraverso il modello matematico COCOMO II (Costructive Cost Model) in cui: PM=A*SIZE B M 3

10 4 A è una costante in genere uguale a 2.94; SIZE è il numero di linee di codice stimato attraverso FP; B è una costante indicativa dello sforzo richiesto; M insieme di moltiplicatori legati alle caratteristiche del progetto. 4

11 Capitolo 3 IFPUG International Function Point Users Group (IFPUG) è un organizzazione no-profit statunitense fondata nel Il metodo di calcolo dei function point fornito da IFPUG è stato standardizzato dall ISO nel 2009 (standard 20296:2009) [3][4]. Il metodo è illustrato in questo capitolo. 3.1 Il metodo Tipo di conteggio L analisi funzionale con il metodo dei function point può essere utilizzata per: a) Development project: misura le funzionalità che verranno fornite all utente alla prima istallazione del sistema. b) Manutenzione evolutiva: misura le funzionalità che verranno fornite all utente in seguito all aggiunta di nuove funzioni oppure alla cancellazione/modifica di vecchie. È applicabile su software pre esistenti. c) Conteggio applicativo: misura un applicazione già istallata Confine applicativo Il confine applicativo indica la divisione che deve essere posta tra il prodotto software da misurare ed altre applicazioni e tra il prodotto e l utente finale, per far ciò occorre guardare il sistema dal punto di vista dell utente

12 6 Nel metodo IFPUG vi sono delle regole specifiche le quali affermano che ogni considerazione sul confine applicativo si focalizza sull ambito di interesse specificato nei requisiti e non basandosi su considerazioni tecnologiche o su altri aspetti che potrebbero risultare non comprensibili all utente finale Conteggio UFP Gli Unadjusted Function Point (UFP) sono dei prototipi di punti funzione conteggiati solo sulla base dei componenti richiesti dall utente. Questi ultimi vengono divisi in dati e transazioni. I dati sono, a loro volta, divisi in: a) Internal Logical File (ILF): insiemi logici di dati gestiti all interno del sistema come ad esempio tabelle di database. b) External Interface File (EIF): aggregati di dati scambiati con altre applicazioni. È facile affermare come un EIF per un applicazione risulterà un ILF per un altra. Le transazioni si dividono in: 1) External Input (EI): numero di elementi che l utente deve fornire al sistema andando a modificare un ILF. 2) External Output (EO): numero di output che il sistema restituisce all utente come risultato delle sue elaborazioni come ad esempio documenti di vario tipo con calcoli. 3) External Inquiry (EQ): numero di interrogazioni che comportano una risposta immediata del sistema. Una volta effettuato il conteggio delle suddette componenti, indicando con V1, V2, V3, V4, V5 il numero rispettivamenti di ILF, EIF, EI, EO ed EQ e con P1, P2, P3, P4, P5 i rispettivi pesi assegnati secondo la tabella in figura 3.1 [5]. Figura 3.1: Tabella calcolo UFP 6

13 Fattori correttivi Il valore di UFP può essere raffinato attraverso 14 fattori correttivi quali: comunicazione dati, distribuzione elaborazione, prestazioni, utilizzo intensivo, configurazione, frequenza di transazioni, inserimento dati interattivo, efficienze per l utente finale, aggiornamento interattivo, complessità elaborativa, riusabilità, facilità installazione, facilità gestione, molteplicità di siti e facilità di modifica. Ad ogni fattore va corrisposto un valore da 0 a 5, dove 0 sta per ininfluente e 5 per incidenza essenziale. Ad esempio, per il fattore correttivo riusabilità il valore 0 corrisponde a codice non riusabile, il valore 5 corrisponde ad applicazione generalizzata e riusabile per diversi contesti Calcolo FP Calcolato UFP e valutati i rispettivi fattori correttivi, è possibile calcolare il valore finale del conteggio FP: F P = UF P ( N k=1 F k) dove N=14 e Fk è il valore attribuito al k-esimo fattore correttivo. 3.2 SNAP SNAP (Software Non-Functional Assessment Process) è un modello ideato dal gruppo IFPUG complementare al metodo della function point analysis. Il modello SNAP si occupa della misura dei requisiti non funzionali (manutenibilità, riusabilità, uso delle risorse, tempi di risposta ecc...). È composto da 4 categorie e 14 sotto-categorie con cui viene misurato un requisito non funzionale. La misura di tale requisito sarà data dalla somma dei valori di ogni sottocategoria (la dimensione è attribuita secondo un valore di complessità). La dimensione finale della parte non-funzionale di un software è data dalla somma delle dimensioni dei singoli requisiti non funzionali. La tecnica SNAP rappresenta un grande vantaggio del gruppo IFPUG rispetto alla concorrenza in quanto essa è complementare al metodo dell FPA [6]. 7

14 8 3.3 Esempio di utilizzo Testo esempio Calcolare il numero degli UFP per un applicazione per il conteggio degli stipendi. L applicazione legge un file di impiegati e un file di informazioni riguardanti il mese corrente e stampa gli assegni per i dipendenti. Il file di impiegati è fornito dall utente, mentre quello del mese è gestito direttamente dall applicazione. I parametri per il calcolo dello stipendio sono memorizzati in un database esterno all applicazione. L applicazione è in grado di gestire comando interattivo in seguito alla richiesta di stampa di un assegno per una singola persona [5] Tipo di conteggio e confine applicativo Dal testo si evince come il tipo di conteggio sarà di tipo conteggio applicativo in quanto l obbiettivo è misurare la dimensione delle funzionalità di un prodotto software già esistente. Il confine applicativo è abbastanza esplicito all interno del testo Calcolo UFP Dal testo si possono identificare le seguenti funzioni dati: ILF: tabella impiegati; EIF: database dei parametri; e le seguenti funzioni transazionali: 1. EI: inserimento file impiegati; 2. EO: stampa assegni dipendenti; 3. EQ: comando interattivo. Supponendo che il peso degli ILF, ILF e degli EQ sia semplice, il peso degli EI sia medio e il peso degli EO sia complesso si può procedere al conteggio finale: UFP = 3*1 + 4*1 + 4*2 + 15*1 + 5*1 = 35 8

15 Calcolo FP Fattori correttivi (i valori sono attribuiti secondo le direttive riportate dal manuale [3]): comunicazione dati = 1; distrubuzione elaborazione = 3; prestazioni = 0; utilizzo intensivo configurazione = 1; frequenza delle transazioni = 0; inserimento dati interattivo = 5; efficienza per l utente finale = 1; aggiornamento interattivo = 3; complessità elaborativa = 1; riusabilità = 0; facilità installazione = 0; facilità gestione = 0; molteplicità di siti = 0; facilità di modifica = 2. La somma dei valori fattori correttivi è: =17 Ora è possibile calcolare il valore FP come: FP = 35*( *17) = Numero di linee di codice stimato Supponendo di voler sviluppare l applicazione in Java si avrà un numero di linee di codice pari a: FP*6 = 28.7*6 = (circa)

16 Capitolo 4 COSMIC Il metodo nasce dall omonima organizzazione no-profit canadese COSMIC (COmmon Software Measurement International Consortium 1 ), con l intento di sopperire alle carenze del metodo FPA in ambito di sistemi real-time, ma si è dimostrato successivamente un ottimo standard di misurazione per ogni tipo di progetto software. È divenuto standard internazionale ISO nel Il metodo Il metodo COSMIC [7] è illustrato in figura 4.1 Figura 4.1: Il metodo COSMIC Lo scopo ultimo è quello di ricavare un valore numerico indicativo della dimensione delle funzionalità del software mediante l applicazione di modelli e procedure ai Requisiti Utente Funzionali (FUR)

17 Strategia di misurazione Prima di procedere con la misurazione occorre che siano chiari: Lo scopo della misurazione: occorre identificare l ambito di misurazione al fine di comprendere quali sono i manufatti che occorrono, il momento del ciclo di vita del software in cui occorre effettuare la misurazione e l accuratezza con il quale dovrà essere effettuata. L ambito del software da misurare: una volta individuato lo scopo, sarà necessario identificare l insieme dei requisiti funzionali che verranno presi in considerazione durante la misurazione. È durante questa fase che il misuratore deve riconoscere i vari strati che compongono l architettura software in questione. Uno strato è una partizione risultante dalla divisione funzionale di un architettura, essi sono organizzati in maniera gerarchica. Sempre in questa fase occorre distinguere le componenti alla pari, esse sono definite dal manuale del metodo COSMIC come Una partizione risultante dalla divisione funzionale dei FUR di una porzione di software contenuta in uno strato in un insieme mutualmente cooperante tale che ciascuna partizione esegue una specifica porzione dei FUR di tale porzione di software [7]. Utenti funzionali di ogni porzione del software: per identificare gli utenti funzionali occorre esaminare i flussi di dati stabiliti dai FUR, gli utenti saranno o i mittenti o i destinatari di tali dati. Livello di granularità misurazione: occorre indicare il livello di dettaglio con cui verranno descritti i requisiti funzionali. L immagine 4.2 (riprodotta dal riferimento [7]) è introdotta al fine di chiarire il concetto di strato introdotto durante l individuazione dell ambito del software. Figura 4.2: Esempio divisione in strati 11

18 Fase di Mappatura La fase di mappatura si divide in 3 sottofasi: 1. Identificazione dei processi funzionali: dove un processo funzionale è una componente elementare di un insieme di Requisiti Utente Funzionali ed è innescato da un movimento di dati (un Entry) proveniente da un utente che ha percepito un evento di innesco. Il concetto è riassunto in figura 4.3 [7]. Figura 4.3: Processo funzionale ed evento di innesco 2. Identificare i gruppi dati: occorre riconoscere gli oggetti di interesse ed i loro attributi per riconoscere un gruppo di dati (un insieme distinto di attributi dei dati che descrivono gli oggetti di interesse). Un gruppo di dati può assumere molte forme diverse quali ad esempio un file, una tabella, una struttura dati allocata dinamicamente o anche un report stampato. 3. Identificare gli attributi dei dati: dove un attributo dei dati è la più piccola porzione di informazione contenente un significato dal punto di vista dei FUR. 12

19 Fase di misurazione Le attività nella terza e ultima fase del metodo COSMIC sono illustrate in figura 4.4 [7]. Figura 4.4: Fase di misurazione Quest ultima fase è divisa in tre sottofasi: 1. Identificare tipi di dati: consiste nell identificare i movimenti di dati di Read, Write, Entry ed Exit indicandoli rispettivamente con R, W, E e X all interno di una tabella come quella in figura 4.5 [7] ed indicando sulla destra il totale di occorrenze per ogni tipo di movimento dati. 2. Applicare la funzione di misurazione: ad ogni movimento dati è assegnato un CFP (COSMIC function point) così che la dimensione di un processo funzionale non è altro che la somma aritmetica dei movimenti dati che lo compongono. 3. Aggregazione: la dimensione delle funzionalità di una porzione software si ottiene sommando le dimensioni di ogni singolo processo funzionale che la compone a patto che essi siano stati calcolati tutti allo stesso livello di granularità. 13

20 14 Figura 4.5: Tabella usata per la misurazione 4.2 Esempio di utilizzo: ACME Car Hire Strategia di misurazione Allo scopo di illustrare il calcolo dei function point con il metodo COSMIC, si consideri un ipotetico sistema di prenotazione auto per la ditta ACME ( ACME Car Hire System ). Le figure 4.6, 4.7 e 4.8 [8] mostrano i prototipi delle interfacce utente del sistema, allo scopo di illustrarne le funzionalità che si desidera esso offra all utente. 14

21 15 Figura 4.6: Interfacce utente del sistema d esempio ACME Car Hire parte 1 Figura 4.7: Interfacce utente del sistema d esempio ACME Car Hire parte 2 Figura 4.8: Interfacce utente del sistema d esempio ACME Car Hire parte 3 15

22 Fase di mappatura Dallo studio delle schermate è possibile risalire ai seguenti eventi innesco ed ai corrispettivi processi funzionali innescati: 1. Evento innesco: verifica della presenza del nome del cliente nel sistema. Processo funzionale: lista clienti. 2. Evento innesco: mostrare i dati per l abilitazione dell utente alla selezione di un cliente. Processo funzionale: sommario clienti. 3. Evento innesco: vista dei dettagli del cliente selezionato. Processo funzionale: richiesta di vista dettagli clienti. 4. Evento innesco: mostrare i dettagli del cliente prima della modifica. Processo funzionale: vista cliente pre-modifica. 5. Evento innesco: modifica dati cliente selezionato. Processo funzionale: modifica dettagli cliente. 6. Evento innesco: mostrare anteprima di stampa della fattura. Processo funzionale: anteprima fattura. 7. Evento innesco: inserimento dati nuovo cliente. Processo funzionale: creazione nuovo cliente. 8. Evento innesco: mostrare prenotazioni. Processo funzionale: anteprima dettagli prenotazioni. Esaminando i suddetti processi funzionali sarà poi possibile riconoscere i seguenti gruppi di dati: Nome cliente; Dettagli cliente; Seleziona dati cliente; ID cliente; Dati sommario cliente; Dati fattura cliente; Dettagli prenotazioni; 16

23 17 Prenotazione corrente; Dati fatture prenotazioni; Messaggi di errore Fase di mappatura Inserendo processi funzionali e gruppi di dati in una tabella, si procederà ora a riconoscere i movimenti di dati per ogni gruppo; ricordando che ad ogni movimento dati corrisponde un CFP, si giunge al risultato in figura 4.9 [8]: Figura 4.9: Tabella calcolo CFP 17

24 Capitolo 5 Analogie e differenze standard IFPUG e COSMIC 5.1 Analogie Sia il metodo IFPUG che il metodo COSMIC sono utilizzati nell ambito della Function Point Analysis (FPA) allo scopo di ottenere una realistica stima della dimensione delle funzionalità di un prodotto software e, di conseguenza, una stima dei costi che occorrerebbero per la produzione. Sia IFPUG che COSMIC sono divenuti standard ISO seppur ad alcuni anni di distanza. Entrambi gli standard vedono i processi elementari come unità funzionali da misurare. Ogni movimento di dati in entrata o in uscita contribuisce alla misura funzionale. Ogni accesso a dati persistenti contribuisce alla misura funzionale. Nessuno dei due metodi misura algoritmi, calcoli e processi logici. Entrambi i metodi sono esplicitati da rispettivi manuali di utilizzo scaricabili dai siti ufficiali dei gruppi IFPUG e COSMIC. 18

25 Differenze Il metodo COSMIC è molto utile per l analisi della dimensione delle funzionalità di un software real-time infatti inizialmente nacque per estendere l analisi IFPUG per tali tipi di software. Il metodo COSMIC ha esplicite regole per i software multistrato a differenza del metodo IFPUG. Il metodo IFPUG si basa sulla vista di un utente esterno, mentre il metodo COSMIC utilizza diversi punti di vista [9]. Il metodo IFPUG presenta regole diverse per ogni tipo di processo mentre il metodo COSMIC presenta le medesime per ogni processo [9]. Il metodo COSMIC è dimostrato essere più efficace per la stima di applicazioni web [10]. Determinati studi hanno dimostrato come il metodo COSMIC è poco adatto a progetti piccoli. Il metodo IFPUG con l ausilio della tecnica SNAP permette un accurata analisi dei requisiti non funzionali, cosa che il metodo COSMIC non permette. Come si evince dal punto precedente il metodo IFPUG permette una manutenzione più efficace ed efficiente del metodo COSMIC. 19

26 Esempio di confronto tra risultati Riprendendo l esempio riportato nel paragrafo 4.2, verrà applicato ad esso il metodo IFPUG per poi confrontare i risultati con quelli ottenuti dall applicazione del metodo COSMIC. Applicando un conteggio applicativo si avranno i seguenti risultati: ILF: lista clienti, dettagli cliente, tabella prenotazioni; EI: aggiornamento lista clienti e dettagli cliente; EO: messaggio errore ed anteprima stampa fattura; EQ: verifica della presenza del nome del cliente nel sistema. Da cui: NILF = 3, NEI = 2, NEO = 2, NEQ = 1. Ai vari dati e transazioni è assegnato il seguente peso: NILF = MEDIO = 4; NEI = MEDIO = 4; NEO = SEMPLICE = 7; NEQ = SEMPLICE = 5. Procedendo al calcolo di UFP: UFP = 4*3 + 4*2 + 7*2 + 5*1 = 39 Per procedere al calcolo degli FP occorre applicare i fattori correttivi (i valori sono attribuiti secondo le direttive riportate dal manuale [3]): 1. comunicazione dati = 0; 2. distrubuzione elaborazione = 2; 3. prestazioni = 0; 4. utilizzo intensivo configurazione = 0; 5. frequenza delle transazioni = 0; 6. inserimento dati interattivo = 5; 7. efficienza per l utente finale = 4; 20

27 21 8. aggiornamento interattivo = 1; 9. complessità elaborativa = 2; 10. riusabilità = 0; 11. facilità installazione = 0; 12. facilità gestione = 2; 13. molteplicità di siti = 0; 14. facilità di modifica = 3. La somma dei valori dei fattori correttivi è 19. É possibile calcolare gli FP come: FP = 39*( *19) = Dunque la misurazione con il metodo IFPUG ha portato ad un risultato di FP, la misurazione COSMIC aveva portato ad un risultato di 33 CFP. I risultati delle due misurazioni differiscono dello 0.73% circa. 5.4 Conversione tra i risultati dei due metodi Dato che ogni metodo comporta i suoi vantaggi ed i suoi svantaggi molto spesso determinate aziende sono state costrette ad abbandonare uno dei due metodi a favore dell altro; ciò però comporta sempre un costo molto elevato e spesso non sostenibile. Negli ultimi anni si è cercato di studiare una relazione matematica tra i risultati dei metodi IFPUG e COSMIC al fine di convertire i risultati senza dover effettuare una nuova misurazione [11] [12]. 21

28 Capitolo 6 Conclusioni 6.1 Il metodo migliore? Nei precedenti capitoli sono stati trattati gli standard IFPUG e COSMIC nell ambito della stima della dimensione delle funzionalità di un software. Dopo una breve introduzione è stato trattato nel dettaglio il metodo IFPUG e successivamente il metodo COSMIC con relativi esempi. Dopo aver trattato i vantaggi e gli svantaggi di entrambi viene spontaneo chiedersi dove tende l ago della bilancia ossia Quale metodo è più conveniente? La risposta a questa domanda, come per gran parte dei quesiti ingegneristici, è dipende. Dipende da: Tipo di software (MIS, Real time ecc...); Dimensione del software (per progetti piccoli non conviene usare COSMIC); Quantità di vincoli (dunque di requisiti non funzionali); Stratificazione del software. Inoltre come definito nel paragrafo 5.3 la ricerca nei metodi di conversione avanza giorno dopo giorno. Ciò permetterà di usare in maniera equivalente uno dei due metodi (in caso sia possibile la conversione [12]). 22

29 Appendice A Approfondimenti A.1 Perchè il metodo COSMIC è indicato per i sistemi real-time Nei capitoli precedenti è stato affermato come il metodo di misurazione COSMIC è più indicato per la misurazione di software real-time. All interno di questo paragrafo vedremo alcune delle motivazioni per cui è valida tale affermazione [13]. Le applicazioni real-time presentano dei processi multi-scopo i quali non risultano misurabili attraverso il metodo IFPUG poichè è possibile riconoscere il tipo di dato (EI, EO, EQ) solo conoscendo lo scopo preciso di tale dato (main purpose). I sistemi real-time sono in genere composti da vari strati, alcuni dei quali sono al di fuori del punti di vista dell utente (come ad esempio il sistema operativo); ragion per cui le apposite regole del metodo COSMIC risultano molto utili a tali misurazioni. La presenza di transazioni con molteplici dispositivi sarebbe valutata con un unico complesso EI in caso di misurazione IFPUG, mentre con una misurazione COSMIC si tengono in considerazione tutti i movimenti di dati che avvengono. 23

30 24 A.2 Altri standard ISO Oltre al già citati IFPUG e COSMIC nel corso degli anni sono stati standardizzati altri metodi per la misurazione della dimensione delle funzionalità del software attraverso la function point analysis e sono i seguenti [14]: FiSMA: ISO/IEC 29881: ; Mark-II: ISO/IEC 20968: ; NESMA: ISO/IEC 24570: II F P A

31 Bibliografia [1] C. Ghezzi, M. Jazayeri, D. Mandrioli. Ingegneria del Software, fondamenti e principi. [2] Ingegneria del Software.. URL del_software. [3] T. Barbieri. Function Point Analysis (IFPUG 4.1.1). September URL http: //users.libero.it/thimoty/function_point_411.pdf. [4] Sistemi Informativi, Function point analysis. URL 0ahUKEwjun-qprrTZAhVMbhQKHfqxDoYQFggvMAA&url=http%3A%2F%2Fstudenti. di3.units.it%2fsistemi%2520informativi%2520i%2fingegneria% 2520del%2520Software%2520-%2520Function%2520Point.pdf&usg= AOvVaw30H22nXRMrb9HpLjU3cw3s. [5] S.Russo. Slide 23-stima dei costi. URL /professor/ e4f f e / materiale_didattico/ [6] About SNAP. URL it. [7] Manuale di misurazione (Guida Implementativa COSMIC a ISO/IEC 19761:2003). September URL overview/. [8] ACME car hire case study. April URL publications/acme-car-hire-case-study-v1-0/. [9] Cosmic Versus IFPUG, similarities and differences. September URL COSMIC-Versus-IFPUG-Similarities-and-Differences.pdf. 25

32 Bibliography 26 [10] S. Di Martino, F. Ferrucci, C. Gravino, F. Sarro. Web Effort Estimation: Function Point Analysis vs COSMIC. Information and software tecnologhy, pages , URL [11] F. Ferrucci, C. Gravino, F. Sarro. A case study on the conversion of Function Points into COSMIC. Software Engineering and Advanced Applications (SEAA), URL CameraReady.pdf. [12] J. J. Cuadrado Gallego, F. Machado Piriz, J. Aroba Paez. On the conversion between IFPUG and COSMIC software functional size units: A theoretical and empirical study. Journal of System and Software, May URL sciencedirect.com/science/article/pii/s [13] L. Lavazza, S. Morasca. Measuring the Functional Size of Real-Time and Embedded Software: a Comparison of Function Point Analysis and COSMIC. The Eighth International Conference on Software Engineering Advances, [14] Function Point.. URL 26