UNIVERSITÀ DEGLI STUDI DELL INSUBRIA

Transcript

1 UNIVERSITÀ DEGLI STUDI DELL INSUBRIA Facoltà Di Scienze Matematiche, Fisiche e Naturali Sede di Como Laurea Triennale in Scienze e Tecnologie dell Informazione I FUNCTION POINT E LE METRICHE FUNZIONALI: UN CASO DI STUDIO REALE Relatore: Prof. DAVIDE TAIBI Relatore Esterno: Dott. VIERI DEL BIANCO Laureando: Simone BERNASCONI matricola Anno Accademico

2 INDICE 2

3 RINGRAZIAMENTI Un sincero ringraziamento va a tutti coloro che, in momenti diversi e in vari modi, mi hanno prestato il loro aiuto e la loro assistenza nella realizzazione di questo lavoro. Ringrazio i miei genitori per avermi dato la possibilità di compiere questo ciclo di studi e per aver sempre avuto fiducia nelle mie capacità. Ringrazio i miei nonni per essere stati i primi ad aver sempre creduto in me. Ringrazio Arianna per avermi sopportato durante questo corso di studi ed essermi sempre stata vicina condividendo con me gioie e difficoltà. Ringrazio i miei colleghi di studi con cui ho condiviso preoccupazioni e speranze. In particolare Daniele, Marco e Gianni con i quali sono certo di continuare la forte e sincera amicizia che ci lega. Ringrazio l Università degli Studi dell Insubria, il Dipartimento di Scienze Matematiche e Fisiche di Como e tutti i Professori dei corsi di studio che ho seguito. Ringrazio il mio relatore Dott. Davide Taibi ed il mio correlatore Dott. Vieri Del Bianco per la disponibilità dimostrata nello sviluppo di questo lavoro. Ringrazio me stesso per avercela fatta. 3

4 Capitolo 1 1. INTRODUZIONE La misurazione permette ad ogni attività della nostra vita, dalla determinazione dei prezzi del sistema economico, alle rilevazioni mediche, allo scandire del tempo, non esiste attività che non richieda l utilizzo della misurazione. È possibile definire la misurazione come il processo di assegnazione di simboli, normalmente numeri, per rappresentare un attributo dell entità di interesse, secondo le regole definite. Per entità si intende l oggetto sul quale va effettuata l indagine, per attributo dell entità si intende l oggetto puntuale ed ultimo dell attività di misurazione. La forma usata per rappresentare l attributo è normalmente numerica e le regole sono necessarie per arrivare a determinare il valore dell attributo, la misura. Si esegue una misurazione per ottenere ulteriori informazioni relative alla realtà di interesse e poter agire con lo scopo di: Valutazione e miglioramento Previsione 4

5 1.1 MISURARE IL SOFTWARE Così, come per molte altre cose, anche per il software venne il momento di introdurre un unità di misura che permettesse di valutare il lavoro dei programmatori e di quantificare anche economicamente gli sforzi profusi da team di sviluppo e ingegneri del software. Inizialmente si pensò di utilizzare il calcolo delle LOC ( Lines Of Code) per la misurazione e la valutazione di un software ma questa unità di misura risultò avere numerose imperfezioni e impedimenti: basti pensare al fatto che si avevano numerose difficoltà a spostare le valutazioni da un linguaggio di programmazione all altro rendendo difficoltoso e talvolta impossibile, far confronti diretti tra software simili. Così nel corso degli anni si è sviluppato un nuovo modo di valutare il software, il Function Point. 1.2 OBBIETIVO DELLA TESI Scopo di questa tesi è analizzare le principali metriche di misurazione della dimensione funzionale del software. Verranno analizzati nel dettaglio il calcolo dei Function Point con il metodo IFPUG e con il metodo COSMIC, approfondendone analogie e differenze. Successivamente verrà analizzato un caso di studio reale, confrontando i dati ottenuti tramite l applicazione della metodologia IFPUG con i risultati ottenuti tramite l applicazione della metodologia COSMIC. 5

6 1.3 STRUTTURA DELLA TESI Nel primo capitolo sono state chiarite le motivazioni per le quali viene svolto il lavoro di tesi ponendo particolare attenzione sulle difficoltà che si possono incontrare nella misurazione del software. Nel secondo capitolo vengono analizzate le caratteristiche di qualità del sofware descritte dalla ISO 9126 e vengono introdotte le metriche di misurazione a partire dalle linee di codice, per poi analizzare la complessità ciclomatica ed infine arrivare alle metriche funzionali. Nel terzo capitolo vengono descritte nel dettaglio la IFPUG Function Points Analysis e la COSMIC Function Points Analysis, partendo dalle origini storiche fino ad approfondire ogni singolo aspetto necessario al calcolo della complessità funzionale. Il quarto capitolo è dedicato all analisi del caso di studio reale, ovvero al calcolo della complessità funzionale del software dedicato al calcolo dei function points. L ultimo capitolo è dedicato alle conclusioni. 6

7 Capitolo 2 2. METRICHE E QUALITÁ DEL SOFTWARE P er qualità si intende qualsiasi caratteristica, proprietà o condizione di una persona o di una cosa che serva a determinarne la natura e a distinguerla dalle altre. Nell ambito dell ingegneria del software, la qualità del software è qualsiasi caratteristica, proprietà o condizione di un prodotto o processo di sviluppo che serva a determinarne la natura e a distinguerlo da altri prodotti software. In generale non tutte le qualità possono essere misurate in modo semplice e assoluto. Possono invece dipendere da fattori esterni quali il contesto d uso o da valutazioni soggettive che fa l attore che esegue la misurazione. Le qualità del software si possono classificare a seconda della percezione che ne hanno gli utenti (qualità esterne) o gli sviluppatori (qualità interne). Le varie qualità possono comunque essere interrelate e mostrare contemporaneamente aspetti esterni ed interni. 7

8 Negli anni sono stati definiti molti modelli della qualità del software. Le norme ISO 9126 [Figura 1] descrivono un modello di qualità del software, definiscono le caratteristiche che la determinano e propongono metriche per la misurazione. Il modello definisce sei caratteristiche, suddivise a loro volta in sotto-caratteristiche, come mostrato nella figura seguente. Figura 1:Il modello di qualità ISO-IEC 9126 FUNZIONALITÀ La funzionalità rappresenta la capacità di fornire funzioni tali da soddisfare, in determinate condizioni, requisiti funzionali espliciti o impliciti. Gli attributi del software richiesti da questa caratteristica sono: Adeguatezza: presenza di funzioni appropriate per compiti specifici; Accuratezza: capacità di fornire risultati od effetti in accordo con i requisiti; Interoperabilità: capacità di interagire con altri sistemi; 8

9 Sicurezza: capacità di evitare accessi non autorizzati a programmi e dati; Aderenza alla funzionalità: capacità di aderire a standard e convenzioni relative alla funzionalità. AFFIDABILITÀ Per affidabilità si intende la capacità di mantenere le prestazioni stabilite nelle condizioni e nei tempi stabiliti. Le sotto-caratteristiche sono: Maturità: capacità di evitare che si verifichino errori o siano prodotti risultati incorretti in fase di esecuzione; Tolleranza ai guasti: capacità di mantenere livelli di prestazioni predeterminati in caso di fallimenti o di violazione delle regole di interfacciamento; Recuperabilità: capacità di ripristinare livelli di prestazione predeterminati e di recuperare I dati a seguito di errori; Aderenza all affidabilità: capacità di aderire a standard e convenzioni relative all affidabilità. USABILITÀ L usabilità è la capacità del software di essere compreso ed usato con soddisfazione dall utente in determinate condizioni d uso. Gli attributi del software richiesti da questa caratteristica sono: Comprensibilità: impegno richiesto agli utenti per capire il funzionamento del software; Apprendibilità: impegno richiesto agli utenti per imparare ad usare il software; 9

10 Operabilità: impegno richiesto agli utenti per imparare ad usare il software; Attrattività: capacità del software di risultare attraente per l utente. Aderenza all usabilità: capacità di aderire a standard e convenzioni relative all usabilità. EFFICIENZA Per efficienza si intende il rapporto fra prestazioni e quantità di risorse utilizzate, in condizioni normali di funzionamento. Le sotto-caratteristiche sono: Comportamento rispetto al tempo: capacità di fornire appropriati tempi di risposta, tempi di elaborazione e quantità di lavoro eseguendo le funzionalità previste sotto determinate condizioni di utilizzo; Utilizzo delle risorse: quantità e tipo di risorse usate per eseguire le funzioni richieste in determinate condizioni: Aderenza all efficienza: capacità di aderire a standard e convenzioni relative all efficienza. MANUTENIBILITÀ La manutenibilità è la capacità del software di essere modificato con un impegno contenuto. Le sotto-caratteristiche sono: Analizzabilità: capacità di poter effettuare la diagnosi sul software ed individuare le cause di errori o malfunzionamenti; Modificabilità: impegno richiesto per modificare, rimuovere errori o sostituire componenti; 10

11 Stabilità: capacità di ridurre il rischio di comportamenti inaspettati a seguito di modifiche; Provabilità: impegno richiesto per validare le modifiche apportate al software; Aderenza alla manutenibilità: capacità di aderire a standard e convenzioni relative alla manutenibilità. PORTABILITÀ Per portabilità si intende la facilita con cui il software può essere trasferito da un ambiente operativo ad un altro. Gli attributi del software richiesti da questa caratteristica sono: Adattabilità: capacità di essere adattato a differenti ambienti senza richiedere azioni specifiche diverse da quelle previste dal software per tali attività; Installabilità: impegno richiesto per installare il software in un particolare ambiente; Coesistenza: capacità di coesistere con altre applicazioni indipendenti in ambienti comuni e di condividere le risorse; Sostituibilità: capacità di sostituire un altro software specifico indipendente, per lo stesso scopo e nello stesso ambiente; Aderenza alla portabilità: capacità di aderire a standard e convenzioni relative alla portabilità. 11

12 2.1 ORIGINI DELLA MISURAZIONE DEL SOFTWARE Così, come per molte altre cose, anche per il software venne il momento di introdurre un unità di misura che permettesse di valutare il lavoro dei programmatori e di quantificare anche economicamente gli sforzi profusi da team di sviluppo e ingegneri del software. La prima occasione ufficiale di discussione sulla misurazione del software, fu la prima conferenza NATO sul Software Engineering nel La prima, misura del software è storicamente rappresentata dal numero di linee di codice (LOC, Lines Of Code); il primo tentativo di calcolo della produttività dei programmatori in termini di numero di LOC per mese-persona risale al Dagli anni 70 sono nate proposte specifiche per la misurazione della dimensione tecnica e della complessità del software quali il coefficiente ciclomatico di McCabe (1976) e la software science di Halstead (1977). Tra la fine degli anni 70 e la prima metà degli anni 80 sono dunque sorte varie proposte di misura funzionale, intesa come misura indipendente dal linguaggio di programmazione e da altri aspetti tecnico-implementativi come la misura FFP (Files, Flows, Processes) nel 1983 e la prima versione dei Function Point nel Nel corso di un ventennio la Function Point Analysis, standardizzata dall IFPUG a partire dal 1986, è evoluta generando molte varianti e proposte di miglioramento, più o meno diffuse. Nel 1998 è nato il Common Software Measurement Consortium Group, da cui venne pubblicato il metodo dei COSMIC Full Function Point. 12

13 2.2 LINEE DI CODICE Le Linee di Codice, (LOC) sono una metrica del software che viene utilizzata per misurare la grandezza di un programma tramite il conteggio del numero di line di codice sorgente. Uno dei principali inconvenienti nell utilizzo di questo metodo riguarda l usabilità in particolari situazioni: è infatti molto difficile confrontare software con un numero di line di codice diverso tra loro. La misura delle LOC si divide in due tipi: Physical LOC: si contano tutte le righe di testo del codice sorgente includendo anche i commenti e le linee bianche se la loro percentuale non supera il 25% delle linee. Logical LOC: si contano gli "statements", ovvero le effettive istruzioni Un aspetto controverso è legato all utilizzo di questo metodo di misurazione e i programmi che va a valutare: il metodo si utile per misurare con efficienza il costo per la realizzazione di un software ma non tiene conto di una variabile importante: l abilità dello sviluppatore. 2.3 COMPLESSITÀ CICLOMATICA La Complessità Ciclomatica è una metrica software utilizzata per valutare la complessità di un algoritmo in un metodo, ed è basata unicamente sulla struttura del grafo che rappresenta l algoritmo. È calcolata utilizzando il grafo di controllo di flusso del programma in cui I nodi corrispondono a gruppi indivisibili di istruzioni, mentre gli archi connettono due nodi se il secondo gruppo di istruzioni può essere eseguito immediatamente dopo il primo gruppo. 13

14 Può essere definita come il numero di casi di test necessari per testare esaurientemente il metodo. Riferendosi ad un grafo che rappresenta l algoritmo e posti: v(g) = numero ciclomatico relativo al grafo G e = numero di archi nel grafo n = numero di nodi del grafo si ha: p = numero dei componenti connesse v(g) = e n + 2p In un grafo G fortemente connesso, il numero ciclomatico v(g) è uguale al numero di percorsi linearmente indipendenti. In generale sono presenti tanti If loop e quindi saranno presenti tante scelte che generano dei percorsi multipli, ad ognuno dei quali è associato un caso di test. Generalmente viene ritenuto migliore un metodo con complessità ciclomatica bassa, sebbene a volte questo non è dovuto ad una bassa complessità del metodo bensì al fatto che il metodo differisce le decisioni inviando un messaggio. 14

15 A causa dell eredità non può essere usata per misurare la complessità di una classe; tuttavia la complessità di una classe può essere valutata usando la complessità di un singolo metodo combinata con altre metriche. 2.4 MISURAZIONE FUNZIONALE Il metodo di misurazione della dimensione funzionale (FSM) misura la visione logica esterna del software dal punto di vista degli utenti, valutando la quantità di funzionalità da consegnare. La capacità di quantificare in maniera precisa le dimensioni del software, sia nella fase iniziale che in quella finale del ciclo di vita evolutivo del software, è determinante per chi gestisce i progetti di software e deve assicurare una valutazione dei rischi, lo sviluppo delle stime (per esempio, impegno lavorativo, costo del progetto) e la possibilità di disporre anticipatamente degli indicatori del progetto (es. produttività). Il metodo di misurazione della dimensione funzionale più usato è quello noto come IFPUG Analisi dei Function Point (IFPUG FPA) che si basa su un metodo proposto da Alan Albrecht. Questo metodo può essere considerato il precursore dei metodi FSM. Questa tecnica venne messa a punto per misurare la quantità di dati a cui accede una singola funzione come indicatore della dimensione funzionale. Sebbene l IFPUG, Analisi dei Function Point, abbia ottenuto una fama crescente nell industria, la mancata applicabilità a tutti i tipi di software e la rapida evoluzione dei paradigmi di sviluppo hanno portato alla nascita di numerose variazioni in questo metodo. Per superare queste diversità il COSMIC- FFP ha introdotto la seconda generazione di metodi FSM, applicabile a diversi domini di software, ai moderni concetti di ingegneria di software. Nel prossimo capitolo verranno descritte in modo approfondito le modalità di misurazione funzionale più diffuse. 15

16 Capitolo 3 3. FUNCTION POINT I Function Point sono un unità di misura utilizzata nell ambito dell ingegneria del software utilizzata per definire le dimensioni del prodotto in termini di funzionalità fornite dall utilizzatore e basata sul numero e tipo delle informazioni in entrata, in uscita e in memorizzazione. L idea di misurare le funzionalità di un applicazione software solo dal punto di vista dell utente finale, senza tener conto degli aspetti tecnici e implementativi, appare affascinante a chiunque abbia avuto a che fare con lo sviluppo di software. Questa metrica è stata introdotta a partire dal 1975 presso IBM da Allan Albrecht, il quale ha pubblicato per la prima volta le sue idee nel 1979, quando i computers erano ancora considerati macchine misteriose. Albrecht suggeriva di misurare un applicazione solo sulla base delle funzionalità visibili dall esterno, come se fosse una black box. 16

17 I principali motivi che hanno spinto Albrecht a creare questo nuovo approccio di misurazione, e che spingono attualmente i programmatori ad utilizzare i Function Point, sono: Stima Il Function Point consente di fare confronti tra tecnologie diverse e quindi di poter fare valutazioni chiare e precise su quale tecnologia è preferibile impiegare nella realizzazione di un progetto e cosa fare per poter migliorare la qualità del lavoro. E importante considerare le risorse umane per stimare il costo in termini di forza lavoro e non solamente in termini di fattori fisici e tecnologici da impiegare nello sviluppo. Predizione Il Function Point consente di effettuare previsioni sulle tempistiche e quindi sui costi necessari allo sviluppo del progetto. Questo motivo è utile sia per effettuare previsioni interne all azienda sia per effettuare preventivi. Pianificazione Dopo aver stimato le dimensioni del progetto e aver definito le tempistiche e l impiego delle risorse è necessario pianificare il lavoro per evitare problemi relativi a ritardi sui tempi di consegna e in fase di sviluppo tra coloro che sviluppano il progetto. Controllo L ultimo punto consiste nel verificare il rispetto dei tempi di consegna, dei tempi previsti per la realizzazione delle variefasi del progetto e permette di valutare quanto la pianificazione, la stima e le previsioni fossero accurate. Le idee di Allan Albrecht furono prese in considerazione da alcuni gruppi di utenti che fondarono nel 1986 l IFPUG (International Function Point Users Group). Alcune delle idee iniziali di Albrecht sono state migliorate, altre abbandonate e col passare degli anni sono state sviluppate varianti del metodo 17

18 originario tra cui la variante COSMIC, sviluppata dal Common Software Measurement International Consortium. 18

19 3.1 IFPUG FUNCTION POINT EVOLUZIONE Come precedentemente accennato, l International Function Point Users Group (IFPUG) ha sviluppato le idee iniziali di Allan Albrecht e sono stati pubblicati vari documenti tra cui il Manuale di Conteggio (Counting Practices Manual, CPM), il quale ha raggiunto nel 2004 la versione 4.2. La soluzione che inizialmente ideò Albrecht per risolvere i problemi comportati dall uso delle LOC (Line Of Code) nel calcolo della produttività e stima dell effort di progetto, teneva conto di quattro componenti funzionali suddivisi in due tipologie: Dati: espressi dalla componente originariamente denominata Master File (MF); Transazioni: espressi da tre diverse tipologie di componenti: o External Input (EI): un processo elementare nel quale i dati attraversano il confine dall esterno verso l interno; o External Output (EO): un processo elementare nel quale dati derivati passano attraverso il confine dall interno verso l esterno; o External InQuiry (EQ): un processo elementare con entrambe le componenti di input e output, il quale a fronte di un interrogazione dell utente al sistema restituisce il risultato della query. Ogni componente veniva soppesato con l attribuzione di un numero di punti funzionali (UFP Unadjusted Function Point) ottenendo un valore che poteva essere corretto in base a 10 fattori detti GSC (General System Characteristics), ognuno con un peso pari a +- 5%, con un aggiustamento pari al 50% sugli UFP. 19

20 La somma delle GSC prende il nome di VAF (Value Adjustement Factor). 10 VAF = DI i i=1 FP = UFP * VAF Dove DI sta per Grado di Influenza dei singoli fattori, valutati su una scala 0-5 dove 0 indica nessuna influenza e 5 indica influenza massima. L evoluzione del metodo, nel 1984, ha comportato ad un allargamento da 4 a 5 componenti suddividendo la voce Master File in: Internal Logical File (ILF): gruppo di dati o di informazioni di controllo che vengono mantenuti all interno del confine applicativo; External Interface File (EIF): gruppo di dati o di informazioni di controllo che vengono mantenuti all esterno del confine applicativo. Un altra modifica al modello del 1979 consiste nella ponderazione dei singoli componenti assegnando un livello di complessità (bassa, media e alta) e l allargamento da 10 a 14 fattori correttivi che permettono una modifica della precedente formula: 20

21 14 VAF = DI i i=1 Nel 1990 venne costituito in Italia il Gruppo Utenti Function Point Italia (GUFPI) il quale si dedicò alla pubblicazione di documenti interpretativi e alla traduzione delle versioni del Manuale di Conteggio a partire dalla versione 4.0. Proprio la versione 4.0, pubblicata nel 1994, viene considerata una svolta storica rispetto alle precedenti e le pubblicazioni successive, le versioni e 4.2 variano solamente per alcuni dettagli. Uno degli elementi che il CPM dell IFPUG ha formalizzato è stata la procedura di conteggio con la lista di sette passi necessari per giungere a determinare il numero di Adjusted Function Point. La versione venne pubblicata nell anno 2000 ed è molto simile alla versione attuale. In seguito alla pubblicazione di tale documento, l IFPUG si è resa conto di alcune imprecisioni nelle definizioni di ILF e EIF ed è stato diffuso nel settembre 2001 un aggiornamento (Addendum) del manuale. La versione 4.2 è semplicemente la versione integrata con l Addendum, e le definizione fornite in tale documento sono talmente precise da poter essere formalizzate. 21

22 3.1.2 PROCEDURA DI MISURAZIONE Come precedentemente accennato esistono varie fasi per arrivare a determinare il numero di Function Point di un progetto software. Determinare il tipo di conteggio Il primo passo consiste nell identificare il tipo di conteggio tra tre tipi di progetto misurabili con la Function Point Analysis: Development: misura le funzionalità di un nuovo progetto quando questo è ultimato. Enhancement: misura le funzionalità aggiunte, cancellate o modificate da un progetto esistente. Application: misura le funzionalità di un applicazione già installata che viene indicata quale baseline per i conteggi successivi. 22

23 Individuare l ambito del conteggio e il confine applicativo Identificare l ambito del conteggio significa individuare le funzionalità che devono essere considerate nel conteggio. Per confine applicativo si intende la linea di separazione tra le applicazioniche si stanno misurando e le applicazioni esterne o l utente. Contare le funzioni di tipo dati In questa fase si procede all identificazione del numero di funzioni di tipo dati. Esistono due tipi di file: File Interni Logici ILF File Esterni di Interfaccia EIF Internal Logic File Un Internal Logic File è un gruppo di dati logicamente collegati o di informazioni di controllo che vengono mantenuti all interno del confine applicativo. L intento primario di un File Interno Logico è contenere dati mantenuti da uno o più processi elementari dell applicazione sottoposta al conteggio. Regole per identificare un ILF Devono essere verificate le seguenti regole per far si che un gruppo di dati o informazioni di controllo possa essere considerato un File Interno Logico: Il gruppo di dati o informazioni di controllo deve poter essere identificabile dall utente. Il gruppo di dati o informazioni di controllo è mantenuto all interno del confine applicativo. 23

24 External Interface File Un External Interface File è un gruppo di dati logicamente collegati che vengono mantenuti all esterno del confine applicativo. L intento primario di un File Esterno d Interfaccia è contenere dati referenziati da uno o più processi elementari situati nei confini dell applicazione sottoposta al conteggio. Un EIF rappresenta un ILF in un altra applicazione. Regole per identificare un EIF Devono essere verificate le seguenti regole per far si che un gruppo di dati o informazioni di controllo possa essere considerato un File Esterno di Interfaccia: Il gruppo di dati o informazioni di controllo deve poter essere identificabile dall utente. Il gruppo di dati o informazioni di controllo è referenziato dall applicazione che si sta misurando ed è ad essa esterno. Il gruppo di dati o informazioni di controllo non è mantenuto all interno del confine applicativo. Il gruppo di dati o informazioni di controllo è mantenuto in un ILF di un altra applicazione. Per determinare la complessità funzionale, e di conseguenza il numero di Unadjusted Function Point, è necessario considerare il numero di elementi di tipo dati (DET) ed elementi di tipo record (RET) associati. Data Element Type Un DET (Data Element Type) è definito come un campo unico riconoscibile dall utente, non ricorsivo. 24

25 Regole di conteggio DET Viene conteggiato un DET per ogni campo unico riconoscibile dall utente, non ricorsivo che viene mantenuto o recuperato da un ILF o da un EIF. Quando due applicazioni prendono in considerazione lo stesso ILF/EIF ma mantengono o referenziano DET separati, vengono conteggiati solamente i DET utilizzati da ciascuna applicazione. Viene conteggiato un DET per ogni dato richiesto dall utente per stabilire una relazione con un altro ILF o EIF. E importante considerare il progetto logico dei dati perché è necessario considerare anche le chiavi esterne come DET. Record Element Type Un RET (Record Element Type) viene definito come un sottogruppo di elementi dati in un ILF o EIF, riconoscibile dall utente. Regole di Conteggio dei RET Viene conteggiato un obbligatorio) di un ILF o EIF. RET per ciascun sottogruppo (opzionale o Se non ci sono sottogruppi, viene conteggiato come RET il ILF o EIF. Complessità ILF-EIF La valutazione del livello di complessità per un ILF o un EIF si basa sul numero di RET e DET. Di seguito è riportata la tabella per la valutazione del grado di complessità. 25

26 1-19 DET DET 51 + DET 1 RET BASSA BASSA MEDIA 2 5 RET BASSA MEDIA ALTA 6 + RET MEDIA ALTA ALTA Contare le funzioni di tipo transizionale In questa fase si procede all identificazione del numero di funzioni di tipo transizionale. Esistono tre tipi di file: External Input (Input Esterni) External Output (Output Esterni) ExternalInQuiry (Interrogazioni Esterne) External Input Un Input Esterno è un processo elementare che permette di elaborare dati o informazioni di controllo provenienti dall esterno del confine dell applicazione. L intento primario di un Input Esterno è quello di manutenere uno o più ILF oppure alterare il comportamento del sistema. Regole di conteggio EI I dati devono essere ricevuti dall esterno del confine applicativo. Deve essere mantenuto almeno un ILF attraverso un processo elementare dell applicazione. Il processo deve essere autonomo e lasciare l applicazione in uno stato consistente. 26

27 Deve essere verificata una delle seguenti affermazioni: o Il processo logico è lo stesso di altri processi logici eseguiti da altri EI. o Il gruppo di dati identificati deve essere diverso da quelli di altri EI. o Gli ILF o EIF referenziati sono differenti dai file referenziati da altri EI. External Output Un Output Esterno è un processo elementare che genera dati o informazioni di controllo, le quali vengono inviate all esterno del confine dell applicazione. L intento primario di un Output Esterno è quello di presentare all utente l informazione attraverso una logica elaborativa differente. Regole di conteggio EO I dati devono uscire dal confine applicativo. Il processo deve essere autonomo e lasciare l applicazione in uno stato consistente. Deve essere verificata una delle seguenti affermazioni: o Il processo logico è lo stesso di altri processi logici eseguiti da altri EO. o Il gruppo di dati identificati deve essere diverso da quelli di altri EO. o Gli ILF o EIF referenziati sono differenti dai file referenziati da altri EO. 27

28 External InQuiry Per ExternalInQuirysi intende un processo elementare composto da una combinazione di input ed output che manda dati o informazioni di controllo all esterno del confine di applicazione. L intento primario di un Interrogazione Esterna è quello di presentare all utente l informazione attraverso il recupero dati o informazioni di controllo. Regole di conteggio EQ I dati devono uscire dal confine applicativo. Il processo deve essere autonomoe lasciare l applicazione in uno stato consistente. I dati devono essere prelevati da uno o più ILF/EIF. Il processo non deve manutenere un ILF. Deve essere verificata una delle seguenti affermazioni: o Il processo logico è lo stesso di altri processi logici eseguiti da altri EQ. o Il gruppo di dati identificati deve essere diverso da quelli di altri EQ. o Gli ILF o EIF referenziati sono differenti dai file referenziati da altri EQ. Complessità transazionale Per determinare la complessità funzionale, e di conseguenza il numero di Unadjusted Function Point, è necessario considerare il numero di tipi di file referenziati (FTR) ed elementi di tipo dati (DET) associati. 28

29 File Type Referenced Un FTR (File Type Referenced) è un ILF o EIF letto o mantenuto da una funzione di tipo transazionale. Quindi un FTR può assumere due forme: Un ILF letto o mantenuto da una funzione di tipo transazione. Un EIF letto da una funzione di tipo transazione. Regole FTR per EI Viene conteggiato un FTR per ogni ILF mantenuto. Viene conteggiato un FTR per ogni ILF o EIF letto. Viene conteggiato solo un FTR per ogni ILF sia letto che mantenuto. Regole FTR per EO Viene conteggiato un FTR per ogni ILF mantenuto. Viene conteggiato un FTR per ogni ILF o EIF letto. Viene conteggiato solo un FTR per ogni ILF sia letto che mantenuto. Regole FTR per EQ Viene conteggiato un FTR per ogni ILF o EIF letto. Data ElementType Un DET (Data ElementType) è definito come un campo unico riconoscibile dall utente, non ricorsivo. 29