esperienze, curiosità, immagini dal mondo dell'informatica

Le metriche consentono di dare concretezza ad aspetti del prodotto software, altrimenti contraddistinto da una grande astrattezza. Le metriche, con i loro algoritmi di calcolo ed i valori soglia, sono applicate durante le attività di misurazioni generando misure.

Si distinguono metriche di prodotto e di processo. Non esiste un elenco esaustivo di esse e per individuarle è utile riferirsi a modelli di qualità e a metodi come il GQM (Goal Question Metrics) ideato da Victor Basili dell'Università del Maryland. 

Per quanto riguarda le principali metriche del prodotto software queste possono essere individuate in connessione con le otto caratteristiche di qualità interna ed esterna del prodotto definite dallo standard ISO/IEC 25010: funzionalità, usabilità, manutenibilità, efficienza, affidabilità, portabilità, sicurezza, compatibilità. A queste si aggiungono le caratteristiche di qualità in uso: efficacia, produttività (dell'utente), safety, soddisfazione, copertura contestuale.

La qualità interna può essere misurata in fase di produzione. La qualità esterna durante la fase di test e tenendo conto degli elementi di sistema, mentre la qualità in uso è misurabile nell'ambiente reale dell'utente.

Analogamente le principali metriche che riguardano la qualità dei dati possono essere individuate con 15 caratteristiche, in connessione con le suddette caratteristiche, definite dal nuovo standard ISO/IEC 25012: consistenza (coerenza anche tra sistemi diversi), aggiornamento (tempestività), completezza, precisione, accuratezza (sintattica-semantica), sicurezza, disponibilità, ripristinabilità, efficienza, portabilità, tracciabilità, credibilità (della fonte), comprensibilità, accessibilità (anche ai disabili), conformità a regolamenti.

La funzionalità del software e la numerosità dei dati riflettono i processi elementari utili all'utente e i file logici del sistema. Essi sono quantificabili, nella loro dimensione, dalla metrica dei Function Point che approfondiamo di seguito.

Function Point in English

I Function Point sono una metrica della dimensione funzionale di un'applicazione, basata sul numero e tipo delle informazioni in entrata, in uscita e memorizzazione. 

Essi sono una pura misura della dimensione del software, non misurano aspetti qualitativi, né la produttività in sviluppo o manutenzione che risente di fattori tecnologici. Pertanto un loro buon uso dovrebbe prevedere l'affiancamento di livelli di servizio e produttività unitaria differenziata che tenga conto della tecnologia utilizzata, della qualità e complessità dell'applicazione, della difettosità tollerabile in esercizio.

Per applicazione s'intende una collezione coesa di procedure automatizzate e relativi dati che supportano un obiettivo di business. Ogni applicazione è separata dalle altre e dall'utente poiché è individuabile un confine che la contraddistingue. Il confine agisce come una "membrana" attraverso la quale passano i dati processati dalle transazioni di Input, Output e Inquiry. Il confine va visto da una prospettiva di business e non va basato su considerazioni tecniche o fisiche.

Per dimensione funzionale di un'applicazione s'intende una misura convenzionale standard indipendente dalla tecnologia utilizzata nella realizzazione del software. La dimensione funzionale è una delle variabili principali del prezzo del software, il quale risente però, come si accennerà, anche di altri fattori. I Function Point sono quindi di ausilio per stimare a priori l'impegno necessario per realizzare un progetto e a posteriori per calcolare il valore del prodotto e del patrimonio software.

La quantità di informazione racchiusa nel numero dei FP è garantita dal metodo utilizzato (es. IFPUG 4.1.1 al quale ci si riferisce in queste note: nell'ottobre 2009 è stato rilasciata la versione 4.3), dalla certificazione del personale che effettua il conteggio, dalla fase del ciclo di vita del software considerato, dalla documentazione.

Il relativo prezzo unitario medio è funzione di vari fattori: linguaggio, processo e tecnologia di sviluppo o manutenzione, complessità, variabilità dei requisiti, contesto d'uso, riuso, coinvolgimento dell'utente, qualità del prodotto, eventuali servizi indiretti.

La definizione dei concetti relativi alla misurazione della dimensione funzionale del software (FSM) e la descrizione dei principi per applicare un metodo teorico di FSM sono contenuti nello standard ISO/IEC 14143-1 del 1997 "Information Technology - Software measurement - Functional size measurement - Definition of concepts". Il metodo più diffuso IFPUG è divenuto standard ISO nel 2009 con il codice 20926.

Un metodo FSM dovrà avere le seguenti caratteristiche: 

• si basa su una rappresentazione dei requisiti utente vista da una prospettiva degli utenti; 

• può essere applicato tempestivamente appena i requisiti funzionali utente sono stati definiti e sono disponibili; 

• deriva la dimensione funzionale a partire da requisiti funzionali, indipendentemente dai requisiti tecnici e dalla qualità.

La dimensione funzionale è inoltre indipendente dall'effort necessario allo sviluppo o alla manutenzione, dalle metodologie impiegate, dai supporti fisici utilizzati e dalle componenti tecnologiche. Un metodo FSM dovrebbe indicare il grado di convertibilità con altri metodi dimensionali. Altre parti dello standard sono in produzione relativamente a: conformità, verifiche, modello di riferimento, domini software.

I Function Point si concretizzano in una serie di punteggi (pesi) assegnati secondo regole di conteggio a Input (EI), Interrogazioni (EQ), Output (EO), File logici interni (ILF), File logici esterni (EIF) evidenti dall'esame dell'applicazione e della sua documentazione.

Nel mondo dell'informatica la metrica dei Function Point si sostituisce gradualmente alle LOC (Linee di codice in passato chiamate schede, da schede perforate, lette da un particolare hardware). Le LOC variano, a parità di funzioni svolte, secondo il tipo di linguaggio utilizzato e sono più difficilmente quantificabili da quando si sono diffusi maggiormente linguaggi visuali avanzati per GUI e WEB rispetto ai linguaggi software tradizionali.

L'interesse verso i Function Point è iniziato in Italia negli anni '90, negli USA negli anni '80, anche se il metodo è stato definito in IBM da Allan Albrecht nella seconda metà degli anni '70. La misura più utilizzata di LOC era il numero delle linee al netto dei commenti, ma uno standard internazionale non è mai stato raggiunto. I Function Point, invece, grazie anche ad associazioni come l'IFPUG (International Function Point User Group) e l'ISO (International Organization for Standardization), sono una misura di dimensione standardizzata, utilizzata dalla gran parte delle industrie che usano metriche funzionali. Il GUFPI-ISMA (Gruppo Utenti Function Point Italia - Italian software metrics association) è anche un possibile riferimento degli utenti italiani dei Function Point per l'applicazione del metodo originario, ma non per le sue eventuali varianti o studi sperimentali. L'IFPUG 4.1 Unadjusted Function Point Method è stato approvato dall'ISO/IEC Joint Technical Committee 1 (JTC1) ed è divenuto PAS (Publicly Available Specification) nel 2001. La versione di conteggio più attuale 4.3 è stata pubblicata dall'ISO come ISO/IEC 29026 nel 2010. Gli International Standard emessi dal JTC1, al termine di una serie di votazioni, sono considerati i più autorevoli standard nel campo dell'Information Technology. Ogni variante locale di conteggio che si discosti dal metodo non risponde alle necessità di standardizzazione e di affidabilità delle metriche.

Un caso di localismo è la corrispondenza media che si verifica tra le LOC e i FP è chiamata, da Capers Jones, "backfire". Ad esempio, rispettivamente secondo tale autore e la David Consulting Group, 1 FP equivale a:
320 LOC Assembler  o 575
128 C o 225
107 Cobol o 220
91 Cobol II o 175
55 C++ o 80
35 Java e Visual Basic-4 o 80
15 HTML-3.

Come è evidente i valori variano da caso a caso e possono essere abbastanza stabili solo all'interno di un certo contesto. (B. Boehm fornisce per C++ e Java una corrispondenza di 53 LOC per 1 FP). Per i siti web di tipo publishing realizzati con molto testo scritto all'interno di istruzioni HTML, ci si può avvicinare alla corrispondenza media di 15 LOC per 1 FP, non considerando le LOC dei testi. E' opportuno verificare con apposito benchmarking i valori di "backfire" nei propri ambienti. L'applicazione del metodo è comunque da evitare o limitare e comunque, se applicato, da dichiarare esplicitamente.Soprattutto non produce alcun beneficio documentale.

In tutti i casi scostarsi dai metodi standard durante i conteggi, dopo che stime iniziali sono state effettuate sulla base di condizioni standardizzate, è un arbitrio metrico.

Il conteggio dei Function Point, applicato in modo "forward" (e non "reverse" con la tecnica del "backfire"), presuppone la conoscenza di regole precise ed è oggetto di nuove professioni (specialisti per il conteggio CFPS: Certified Function Point Specialist). Attraverso l'IFPUG è possibile essere certificati come specialista di conteggio. La certificazione garantisce la capacità di conteggio accurato dello specialista, che applica la metodologia originaria e il codice etico dell'IFPUG, ma non autorizza a certificare nuove persone, né a ideare varianti del metodo ritenute automaticamente certificate.

In effetti i Function Point rappresentano qualcosa di più di una tecnica di conteggio in quanto contribuiscono ad un approfondimento delle funzionalità, producendo un miglioramento della analisi dei requisiti e rendendone possibile una quantificazione, migliorano le stime, supportano il test di accettazione e migliorano la documentazione generale del software. Essi costituiscono inoltre un'ottima opportunità per effettuare diversi censimenti delle applicazioni esistenti nel sistema informativo.

I Function Point possono quindi essere usati per supportare il processo di sviluppo e consentono di gestire alcune principali attività chiave del livello 2 del CMM (Capability Maturity Model) del SEI (Software Engineering Institute della Carnegie Mellon University) pubblicato nel 1991, che si è evoluto dal 2000 verso il CMMI (Capability Maturity Model Integration) risultando più articolato e integrato con alcuni standard internazionali ISO e con documenti di associazioni e industrie. 
Il modello prevede 5 livelli di maturità del processo:

1. Iniziale (eseguito informalmente)

2. Ripetibile (gestito in termini di requisiti, pianificazione, controllo, misurazione, assicurazione qualità, dati e configurazione)

3. Definito (con piena considerazione dei requisiti utente, integrato, organizzato e gestito tenendo conto dei rischi)

4. Gestito (gestito quantitativamente in tutti gli aspetti di qualità e processo)

5. Ottimizzato (con analisi causali e risoluzioni dei problemi, fortemente innovativo)

Il metodo di conteggio, applicato con i dovuti criteri, risponde alle seguente caratteristiche:

- indipendenza dalla tecnologia utilizzata;
- ripetibilità;
- sensibilità alla grandezza percepita dall'utente attraverso il numero di processi elementari e alla complessità;
- comparabilità metrica con altri metodi;
- accuratezza;
- apprendibilità (con circa 1 mese di teoria e 2-3 di pratica);
- usabilità (un dimensionamento di una applicazione media richiede da poche ore a 2-3 giorni);
- documentabilità;
- condivisibilità con l'utente e trasparenza;
- certificabilità del personale da adibire al conteggio;
- manutenibilità e possibilità di supporto da parte di associazioni. 

Usando parole molto semplici si può dire che la tecnica fornisce una quantificazione delle informazioni, da un punto di vista logico, che entrano, escono e si memorizzano in un computer attraverso l'esecuzione di una applicazione software. Si precisa che i termini "interno" e "esterno" presuppongono di aver determinato un limite, un confine che distingua l'applicazione da quantificare dalle altre applicazioni del sistema. Gli elementi oggetto di conteggio sono in relazione tra loro. In sintesi i File interni (ILF) o esterni (EIF) all'applicazione sono referenziati in diverso modo dalle attività elementari di Input (EI), Interrogazione (EQ), Output (EO); di seguito si riportano i loro intenti primari che le attività elementari intendono svolgere. Ad esempio un Input avrà la finalità principale di inserire dati in un file, ma secondariamente potrà anche leggere informazioni su un altro file (tra parentesi sono indicati gli intenti non primari):

Un esempio di Input (EI) si verifica con l'acquisire dei dati, un esempio di Interrogazione (EQ) con il fornire una semplice risposta ad una domanda ed un esempio di Output (EO) con lo stampare dei dati calcolati; queste attività costituiscono processi elementari, cioè le più piccole unità di azione significative per l'utente.

Alcuni verbi che identificano i processi elementari per un EI, e connessi in genere con uno o più ILF, sono:
acquisire, inserire, aggiungere, inviare da parte dell'utente, impostare, importare, popolare, assegnare, pianificare, schedulare, cancellare, eliminare, modificare, aggiornare, alterare, accettare, variare, rivedere, controllare, validare, memorizzare, mantenere.

Alcuni verbi che identificano un EO, e che referenziano ILF o EIF, sono: calcolare e contabilizzare, oltre:
fornire (*), stampare (*), visualizzare (*), produrre (*), trasmettere (*), esportare (*), inviare da parte del computer(*), presentare (*), pubblicare (*), i quali possono essere anche EQ se non contengono calcoli.

Altri verbi che identificano un EQ se non ci sono dati derivati, e che referenziano ILF o EIF, sono (oltre quelli precedenti contrassegnati da *): interrogare, ricercare, decodificare, leggere, accedere, listare.

Punteggi funzionali ed esempio di calcolo