Archivi categoria: FUNCTION POINT

Serie di articoli dedicati alla metodologia dei function point con cui è possibile misurare la complessità di un software.

FUNCTION POINT TUTORIAL – 7 – DOCUMENTARE IL PUNTEGGIO

In questo articolo vedremo gli step da seguire per la produzione della documentazione a corredo del conteggio dei function point.

La documentazione deve prevedere le seguenti informazioni:

  1. scopo e tipo di conteggio
  2. scopo del conteggio e confini dell’applicazione
  3. la dta del conteggio
  4. la lista di tutte le data function individuate, specificando il tipo (ILF o ELF), la relativa complessità e gli FP assegnati
  5. la lista di tutte le transaction function individuate, specificando il tipo (EI, EQ o EO), la relativa complessità e gli FP assegnati
  6. il risultato del conteggio
  7. assunzioni fatte e issue risolte.

Come informazioni aggiuntive è possibile prevedere i seguenti step :

  1. identificazione della documentazione di riferimento
  2. identificazione dei partecipanti, relativi ruoli e qualifiche
  3. per ogni data function viene specificato il numero dei DET e RET
  4. per ogni transaction function viene specificato il numero di DET e FTR
  5. vengono specificate le relazioni tra data function e transaction function
  6. vengono specificate le relazioni tra data function e documentazione di riferimento
  7. vengono specificate le relazioni tra transaction function e documentazione di riferimento

Il livello di dettaglio sarà concordato di volta in volta con il cliente.

Infine il risultato dell’elaborazione sarà indicato nel formato

S FP (IFPUG–IS)

dove S è il numero individuato, FP è l’unità di misura e IS indica lo standard di riferimento.

Esempio 250 FP (IFPUG-ISO/IEC 20926:200x)

FUNCTION POINT TUTORIAL – 6 – CALCOLO FP

Definito il grado di complessità delle data function e delle transaction function è possibile effettuare il calcolo del punteggio dei function point.

La formula da utilizzare dipende dallo scopo del conteggio. Vediamo quali sono le formule da applicare in base ai vari casi.

  • Sviluppo di un progetto

DFP = ADD + CFP

dove ADD è la dimensione della funzioni da rilasciare e CFP indica la dimensione delle funzioni di conversioni.

  • Misura di un applicativo

DFP = ADD

  • Evolutiva di un progetto

EFP = ADD + CHGA + CFP + DEL

dove ADD indica la dimensione delle nuove funzioni aggiunte, CHGA la dimensione delle funzioni che hanno subito una modifica, CFP indica la dimensione delle funzioni di conversione e DEL indica la dimensioni delle funzioni da cancellare.

  • Misura dell’applicativo a seguito di un’evolutiva

AFPA = (AFPB + ADD + CHGA) – (CHGB + DEL)

dove AFPA indica la dimensione del progetto prima dell’evolutiva, AFPB è la dimensione del progetto dopo l’evolutiva, ADD indica la dimensione delle nuove funzioni, CHGA è la dimensione delle funzioni di conversioni prima dell’evolutiva, CHGB è la dimensioni delle funzioni di conversione dopo l’evolutiva e DEL è la dimensione delle funzioni cancellata con l’evolutiva.

FUNCTION POINT TUTORIAL – 5 – MISURARE LE TRANSACTION FUNCTION

Nell’articolo di oggi vedremo le fasi per la misurazione delle transaction function. Le transaction function sono i processi elementari che consentono all’utente di gestire i dati. Il processo di misurazione si svolge attraverso le seguenti fasi:

  • identificazione dei processi elementari secondo specifica
  • classificazione dei processi elementari individuati in External Input (EI), External Output (EO) o External Inquiry (EQ) secondo specifica
  • conteggio dei File Typed References per ogni processo individuato
  • conteggio dei Data Element Types per ogni processo individuato
  • individuazione della complessità funzionale di ogni processo
  • individuazione dei function point per ogni processo

Come prima azione occorre scomporre i requisiti funzionali in processi elementari. Per processo elementare si intende una transazione facilmente individuabile dall’utente e che lascia l’applicazione in uno stato consistente. Ad esempio un requisito funzionale relativo alla gestione di una rubrica è scomponibile dei processi elementari di creazione, cancellazione, modifica e lettura di un contatto.

Individuati i processi occorre catalogarli nelle 3 tipologia sopra menzionate.

  • Un EI è un processo elementare che riceve dati e informazioni di controllo dall’esterno e che modifica un ILF o cambia lo stato corrente della nostra applicazione.
  • Un EO è un processo elementare che mostra dati all’utente eseguendo delle elaborazioni, che spaziano dal calcolo di formule all’aggiornamento di ILF o dello stato corrente della nostra applicazione.
  • UN EQ è un processo elementare che mostra dati all’utente senza essere catalogabile come EO.

La seguente tabelle riassume le relazioni tra i processi elementari e lo scopo del processo:

Funzione EI EO EQ
alterare il comportamento dell’applicazione SI Possibile NO
aggiornare uno o più ILF SI Possibile NO
presentare dati all’utente Possibile SI SI

La specifica relaziona i processi elementari alle elaborazioni possibili:

Processo EI EO EQ
Validazione di Dati opzionale opzionale opzionale
Calcolo Matematico di valori opzionale obbligatorio per caratterizzare il processo non deve essere presente
Conversione di Valori opzionale opzionale opzionale
Selezione di Dati tramite filtri di ricerca opzionale opzionale opzionale
Analisi di condizioni opzionale opzionale opzionale
Aggiornamento di ILF obbligatorio per  caratterizzare il processo obbligatorio per caratterizzare il processo non deve essere presente
Referenziamento di ILF/ELF opzionale opzionale obbligatorio
Recupero di dati o informazioni di controlllo opzionale opzionale obbligatorio
creazione di dati derivati opzionale obbligatorio per caratterizzare il processo non deve essere presente
Comportamento dell’applicazione alterato obbligatorio per caratterizzare il processo obbligatorio per caratterizzare il processo non deve essere presente
Presentazione di Dati opzionale obbligatorio obbligatorio
Gestione dei Dati inseriti dall’utente obbligatorio opzionale opzionale
Ordinamento di dati opzionale opzionale opzionale

Si conta un FTR per ogni data function individuata coinvolta nel processo

Definiti i FTR si contano i DET secondo le seguenti regole:

  • analisi di ciò che attraversa i confini dell’applicativo
  • si conta un DET per ogni attributo riconoscibile dall’utente  che attraversa i confini dell’applicativo
  • si conta un solo DET per la capacità del processo di inviare messaggi di risposta all’utente
  • si conta un solo DET per la capacità di iniziare una determinata azione, anche se sono possibili diversi modi
  • non si considerano nel conteggio gli attributi usati dai processi ma che non attraversano i confini dell’applicativo, nè i pulsanti di navigazione o gli attributi tipici di una stampa come i numeri di pagina

Definiti FTR e DET è possibile stabilire la complessità delle transaction function tramite le seguenti tabelle:

Complessità degli EI

DETs
1-4 5-15 >15
FTRs 0-1 Bassa Bassa Media
2 Bassa Media Alta
>2 Media Alta Alta

Complessità degli EO/EQ

DETs
1-5 6-19 >19
FTRs 0-1 Bassa Bassa Media
2-3 Bassa Media Alta
>3 Media Alta Alta

Individuata la complessità è possibile assegnare un punteggio alla singola transaction function secondo questa tabella

TIPO
EI EO EQ
Complessità Bassa 3 4 3
Media 4 5 4
Alta 6 7 6

FUNCTION POINT TUTORIAL – 4 – MISURARE LE DATA FUNCTION

In questo articolo vediamo le fasi per la misurazione dei data function. I data function sono le funzioni che soddisfano i requisiti utente relativi la gestione dei dati. Il processo di misurazione prevede i seguenti step:

  • identificare e raggruppare i dati in data function
  • classificare i data function in ILF e ELF
  • per ogni data function individuare i DET
  • per ogni data function individuare i RET
  • determinare la complessità della singola data function
  • determinare il punteggio della singola data function

Nell’indentificazione dei data function consideriamo solo gruppi di dati riconosciuti dall’utente, mentre eventuali dati non espressamente richiesti non vengono considerati. Ad esempio i dati di audit se non espressamente richiesti da un requisito utenti non vengono considerati nel conteggio.

Nella distinzione tra ILF e ELF è importante stabilire l’applicativo che gestisce il data function individuato. Se la gestione è in carico al nostro applicativo si identifica come ILF, in caso contrario come ELF. Ad esempio nell’invocazione di un servizio esterno l’entità logica scambiata viene mappata come ELF.

Nel conteggio dei DET consideriamo solo gli attributi univoci riconoscibili dall’utente.

Nel conteggio dei RET consideriamo un RET per ogni data function individuato. Per ogni gruppo di DET individuato viene aggiunto un RET

Stabiliti il numero di DET e RET è possibile stabilire la complessità dei data function secondo la seguente tabella:

DETs
1-19 20-50 >50
RETs 1 Bassa Bassa Media
2-5 Bassa Media Alta
>5 Media Alta Alta

Individuata la complessità è possibile assegnare un punteggio alla singola data function secondo questa tabella

Tipo
ILF ELF
Complessità Bassa 7 5
Media 10 7
Alta 15 10

FUNCTION POINT TUTORIAL – 3 – MISURA DEGLI FP

Nell’articolo di oggi vedremo in cosa consiste il processo di misura, secondo le norme specificate dalla versione 4.3 della function point analysis. Esso si svolge nei seguenti step :

  • Raccogliere la documentazione disponibile
  • Determinare il tipo di conteggio, i confini del nostro sistema e identificare i requisiti utenti funzionali
  • misurare le data function, individuando ILF e ELF
  • misurare le transaction function, individuanto EI, EO e EQ
  • calcolare i function point
  • documentare i function point
  • restituire il risultato del punteggio secondo specifica

La documentazione disponibile deve permettere di definire tutte le nuove funzionalità richieste al software o le eventuali modifiche richieste per le funzionalià esistenti.

Raccolta la documentazione occorre stabilire quale è l’obiettivo del conteggio, perchè esso influenzerà le nostre valutazioni successive. Fondamentalmente sono 3 gli scenari che si prospettano:

  • Misurare la complessità dello sviluppo di un progetto
  • Misurare la complessità di una evolutiva
  • Misura la complessità di un’applicazione
Ogni scenario influenza il conteggio e verrà dettagliato in un articolo successivo. In questa fase definiamo i confini del nostro software e individuiamo solo i requisiti funzionali. I requisiti non funzionali verranno misurati adottando altre metriche.
A questo punto definiamo i data function. Ogni data function viene classificato in ILF o ELF e per ognuno stabiliamo la complessità in base ai RET e DET individuati.
Definiti i data function passiamo alla definizione delle transaction function. Ogni transaction function viene classificato in ED, EO o EQ eper ognuno stabiliamo la complessità in base ai DET e FTR individuati.
Individuata la complessità di tutti i BFC resta da calcolare la dimensione dei function point, in base al conteggio scelto.
Individuato il punteggio occorre documentare il processo e restituire il conteggio facendo riferimento allo standard rispettato, nel formato
S FP (IFPUG–IS)
dove S indica il numero di FP individuato e IS indica lo standard internazionale usato. Es. 250 FP (IFPUG-ISO/IEC 20926:200x)

FUNCTION POINT TUTORIAL – 2 – DEFINIZIONI

La function point analysis individua un insieme di definizioni, regole e step da seguire per procedere alla misura dei function point. Tali punti sono definiti all’interno dell’ISO/IEC 14143-1:2007.

In questo articolo ci limiteremo a vedere quelli propedeutici all’applicazione della metodologia:

  • Elementary Process – individuano la più piccola attività individuata dall’utente.
  • data function – individuano funzionalità che soddisfano un requisito di storage di entità interne o esterne al sistema
  • transactional function – sono dei processi elementari che permettono all’utente di processare i dati

I data function si distinguono in 2 categorie:

  • ILF – Internal Logical File – individuano un gruppo di dati o informazioni di controllo riconosciuti dall’utente, la cui gestione avviene all’interno del nostro software
  • EIF – External Interface File – individuano un gruppo di dati o informazioni di controllo riconosciuti dall’utente,utilizzati all’interno del nostro software ma la cui gestione è di competenza di un altro software.
Le transactional function di distinguono in 3 categorie:
  • EI – External Input – individuano dei processi che trattano dati o informazioni di controllo inviati dall’esterno dell’applicativo
  • EQ – External Inquiry – individuano dei processi che inviano dati o informazioni di controlli all’esterno dell’applicativo
  • EO – External Output – individuano dei processi che inviano dati o informazioni di controlli all’esterno dell’applicativo. tali processi presentano delle elaborazioni aggiuntive.

I componenti sinora visti ILF, EIF, EI, EQ e EO sono definiti BFC (Base Functional Component). Essi indicano gli elementi in cui è scomponibile un requisito funzionale. Ad esempio il requisito funzionale ‘gestione di un libro’ si scompone in requisisti più semplice: inserimento, visualizzazione e modifica del libro. Per maggiori dettaglia rimando alla specifica [ISO/IEC 14143-1:2007, definition 3.1], che definisce i BFC elementary unit of Functional User Requirements defined by and used by an FSM Method for measurement purposes

Nella definizione della complessità delle BFC un ruolo fondamentali assumono i seguenti elementi

  • DET – Data Element Type – individuano attributi unici, riconoscibili dall’utente e non ripetuti.
  • RET – Record Element Type – individuano un set di DET usati da una data function
  • FTR – File Type Referenced -individuano le data function lette o gestite da transactional function

Nel prossimo articolo vedremo come usare questi componenti per misurare il nostro software.

FUNCTION POINT TUTORIAL – 1 – INTRODUZIONE

L’analisi dei punti funzione (Function Point Analysis) è una metodologia che consente di misurare le funzionalità offerte da un software.

L’unità di misura function point è stata individuata per la prima volta da Allan Albrecht nel 1975, e la relativa metodologia per il suo calcolo ha subito nel tempo diverse evoluzioni fino all’ultima versione 4.3.1 ad opera di una associazione internazionaleIFPUG – International Function Point Users Group. IFPUG opera dal 1986 perseguendo come obiettivo il miglioramento continuo dell’analisi dei function point.

In Italia è presente la GUFPI-ISMA – GRUPPO UTENTI FUNCTION POINT ITALIA ITALIAN SOFTWARE METRICS ASSOCIATION – l’associazione italiana per la promozione, la diffusione e lo sviluppo delle tecniche quantitative di misurazione del software, inclusi i metodi di misurazione della dimensione funzionale Function Point COSMIC e IFPUG.

I vantaggi dell’adozione di una metrica per la misurazione della dimensione di un software sono diversi:

  • permette una stima dei costi e delle risorse necessarie per lo sviluppo software, valorizzazione e manutenzione;
  • fornisce un fattore di normalizzazione per il confronto di software diversi;
  • permette di determinare la dimensione di un software acquistato in base alle funzionalità offerte;
  • permette di valutare i vantaggi offerti da un software in base ai punti funzioni ad esso associato.

Va precisato che i Function Point misurano esclusivamente i requisiti funzionali e pertanto sono indipendenti dalla tecnologia utilizzata per lo sviluppo del software. Per i requisiti non funzionali, ad esempio requisiti prestazionali o implementativi, occorre utilizzare altre metriche.

Nei prossimi articoli vedremo le regole, le definizioni e gli step da seguire per applicare la metodologia.