UDA

Categoria: Unità didattiche

UDA 19 - Ciclo di vita e modelli di sviluppo del software - 19.5 Valutazione del software e stima dei costi

24 Novembre 2014

19.5 Valutazione del software e stima dei costi

Negli anni '80 Tom De Marco, padre dell'analisi strutturata, affermava: "non puoi controllare ciò che non sai misurare"; per misurare la complessità del software o per stimare le risorse necessarie alla sua produzione e alla sua manutenzione sono utilizzate le metriche software. Una metrica software è uno standard per la misura di alcune proprietà del software o delle sue specifiche. I principali casi in cui vengono utilizzate le metriche software sono i seguenti:

• la stima del budget necessario per un'attività di codifica del software;
• la stima della produttività (individuale o di progetto);
• la stima della qualità del software prodotto;
• la stima dell’impegno di lavoro richiesto per altre attività legate al software.

Il limite per le metriche software è che esse forniscono generalmente solo una “stima” di “quanto” software è presente in un programma ma non un valore esatto. Questo limite ha spinto chi si occupa dimetodologie di gestione a concentrarsi maggiormente sulle metriche di monitoraggio e controllo del processo di produzione del software, esempi di metriche di questo tipo sono:

• numero di volte in cui è fallita la ricompilazione del programma;
• numero di bug introdotti per ore di sviluppo;
• numero di cambiamenti richiesti;
• quantità di ore disponibili di un programmatore al mese;
• numero di release di patch richieste nel tempo al primo prodotto sviluppato.

Di seguito è riportata una descrizione sintetica delle metriche software più comunemente adottate.

Source Lines Of Code (SLOC)

SLOC è una metrica software basata sul conteggio del numero di linee di codice sorgente. L'idea alla base di questa metrica è che un software è tanto più complesso quanto maggiore è il numero delle sue linee di codice, ovviamente questo non è vero in assoluto perché è noto che il numero delle linee di codice sorgente può fornire solo un ordine di grandezza del software misurato. La misurazione delle SLOC nacque con i linguaggi tradizionali line-oriented (Fortran, Assembler, C) in un contesto in cui era legittimo supporre che la misura delle linee di codice potesse fornire una fotografia abbastanza veritiera della complessità del software. Oggi, con gli attuali paradigmi a oggetti, ciò non è altrettanto valido, ma, a causa della sua estrema semplicità, tale metrica è ancora largamente adottata. Usualmente si distingue fra:

• Physical SLOC: 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 totali.
• Logical SLOC: si contano gli statement, ovvero le effettive istruzioni (ad esempio in C si considera SLOC ogni istruzione terminante con “;”).

Esempio

for(i=0; i<100;++i)printf("hello");/* quante linee di codice ci sono? */

• 1 Physical Lines of Code
• 2 Logical Lines of Code (unfore unaprintf)

for(i=0; i<100;++i)

{

printf("hello");

}/* Ora quante linee di codice ci sono? */

• 4 Physical Lines of Code
• 2 Logical Lines of Code

Complessità ciclomatica

Questa metrica tenta di cogliere la complessità del software contando il numero di cammini linearmente indipendenti all'interno del grafo di flusso. La complessità può riguardare singole funzioni, moduli, metodi o classi di un programma. Dire che un grafo di flusso ha una complessità ciclomatica pari a n, equivale a dire che in quel grafo n è il massimo numero di cammini fra ingresso e uscita tra loro indipendenti e ogni altro cammino possibile sul grafo si può costruire a partire da uno di quegli n cammini. Ad esempio, se il codice sorgente non contiene punti decisionali come IF o cicli FOR, allora la complessità ciclomatica sarà pari a 1, poiché esisterà un solo cammino nel grafo di flusso. Se, invece, il codice ha un singolo IF contenente una singola condizione, allora ci saranno due cammini possibili: il primo se l'IF viene valutato a TRUE e un secondo se l'IF viene valutato a FALSE. In generale, esistono formule matematiche che, a seconda dei casi, consentono di calcolare agevolmente la complessità ciclomatica anche partendo direttamente dal codice. La misura della complessità ciclomatica riveste particolare importanza in fase di valutazione dei test, in un grafo di flusso si può verificare che ogni cammino rappresenta una possibile sequenza di eventi e di conseguenza un potenziale test. Ne deriva che per testare in modo esaustivo un certo modulo software devono essere analizzati tutti i possibili cammini presenti in esso. Questo sistema di test, nei moduli particolarmente strutturati, implica una complessità molto elevata, invece, calcolando la complessità ciclomatica, possono essere individuati i cammini indipendenti del grafo di flusso e si possono condurre i test unicamente sui cammini indipendenti, sicuri di aver esperito tutte le possibili prove. Per tale motivo, il calcolo della complessità ciclomatica viene spesso impiegato per determinare a priori il numero di test a "scatola bianca" che sono richiesti per ottenere un’affidabilità sufficiente per un certo modulo software.

Function point e costi del software

Il Function Point(FP) è un'unità di misura utilizzata nell'ambito dell'Ingegneria del Software per quantificare il numero di "funzionalità" fornite da un prodotto software. A differenza di altre metriche l’analisi dei Function Point prescinde dal codice e si concentra sugli aspetti funzionali dell'applicativo. Obiettivi dell'analisi dei function point sono:

• misurare le funzionalità che l'utente richiede e riceve;
• misurare i risultati dello sviluppo e/o la manutenzione del software indipendentemente dalla tecnologia utilizzata;
• fornire una misura che sia coerente tra progetti e produttori differenti.

La definizione dei concetti relativi alla misurazione della dimensione funzionale del software (FSM) e la descrizione dei principi per applicare un metodo FSM sono contenuti nello standard ISO/IEC 14143-1 del 1997 Information Technology - Software measurement - Functional size measurement - Definition of concepts.

In base a tali prescrizioni, un metodo di misurazione funzionale deve avere le seguenti caratteristiche:

• si basa su una rappresentazione dei requisiti utente vista dalla prospettiva dell'utente;
• può essere applicato tempestivamente appena i requisiti funzionali utente sono stati definiti e sono disponibili;
• la dimensione funzionale deriva da requisiti funzionali, indipendentemente dai requisiti tecnici e dalla qualità;
• la dimensione funzionale è indipendente dall'effort necessario allo sviluppo o alla manutenzione, dalle metodologie impiegate, dai supporti fisici utilizzati e dalle componenti tecnologiche.

In effetti i Function Point rappresentano qualcosa di più di una semplice tecnica di conteggio, in quanto:

• contribuiscono a un approfondimento delle funzionalità;
• producono un miglioramento dell’analisi dei requisiti;
• rendono possibile una quantificazione delle funzionalità;
• migliorano le stime del software;
• supportano il test di accettazione del software;
• migliorano la documentazione generale del software.

Essi costituiscono inoltre un'ottima opportunità per effettuare diversi censimenti delle applicazioni esistenti nel sistema informativo. Ma la cosa più rilevante è che i Function Point possono essere messi in relazione con altre variabili quali:

• il costo di un progetto di sviluppo;
• il costo di un progetto di manutenzione evolutiva;
• l'impegno in ore di lavoro previste;
• lo staff necessario;
• la durata di lavorazione.

I Function Point sono in definitiva una misura di prodotto. 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. Si è stimato che 1 FP equivale a 320 LOC Assembler o 128 LOC C o 107 LOC Cobol. I Function Point, anche grazie ad associazioni come l'IFPUG (International Functional Point User Group) e l'ISO (International Organization for Standardization), sono divenuti uno standard di misura di dimensione del software, utilizzata dalla gran parte delle industrie che usano metriche funzionali. Lo standard definisce i Function Point (FP) come: una metrica della dimensione funzionale di un'applicazione, basata sul numero e sul tipo delle informazioni in entrata, in uscita e memorizzazione. 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 funzionale 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ò anche di altri fattori. I Function Point sono 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, dalla certificazione del personale che effettua il conteggio, dalla fase del ciclo di vita del software considerato, dalla documentazione. I Function Point si concretizzano in una serie di punteggi (o 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. In termini molto semplici si può dire che la tecnica dei FP fornisce una quantificazione delle informazioni che, da un punto di vista logico, entrano, escono e si memorizzano in un computer attraverso l'esecuzione di una applicazione software. Per poter quantificare e certificare i FP occorre acquisire una certificazione IFPUG di Certified Function Point Specialist/Certified Function Point Pratictioner (CFPS/CFPP).

Altre metriche

Vi sono inoltre metriche basate su altri criteri come:

• il conteggio degli errori per linee di codice;
• la copertura di codice; questa metrica è stata creata specificamente per verificare l'efficacia del collaudo perché conta quante volte è stata eseguita ogni istruzione nel codice durante il collaudo.Le istruzioni eseguite almeno una volta sono dette "coperte"; l'obiettivo di un collaudo èovviamente quello di coprire il maggior numero possibile di istruzioni;
• conteggio del numero di linee richieste dal cliente;
• conteggio del numero di classi e interfacce.

• < Prec
• Succ >