GPOI - Metriche di software, valutazione dei costi di un progetto informatico

Le metriche del software

Costi del SW → Generalmente maggiori dei costi HW!

Metriche software → Strumenti che forniscono misure quantitative e qualitative del prodotto e delle sue componenti (importanti per produttore e consumatore).

Servono a monitorare tutte le fasi del ciclo di sviluppo del software.

Si basano su:
-Dimensione (es: Line Of Code → LOC);
-Funzionalità (es: Function Points Analysis → FPA);
-Complessità (es: Numero Ciclomatico → consiste nel vedere un programma come un grafo che rappresenta tutte le condizioni if, while, for e analizza la sua complessità);

Le metriche sono usate per quantificare e qualificare:
-Prodotti: prodotti, codice, test ecc…;
-Processi: attività di analisi, progettazione, codifica ecc…;
-“Attori” del software: efficienza collaudatore, produttività progettista ecc…;

Le metriche sono di due tipi

1) Primitiva o diretta → misura di attributi direttamente osservabili (es: LOC);
2) Calcolata o indiretta → no misure dirette, ma parte da altre metriche;

Il primo passo per valutare i costi è stimare la quantità di lavoro.

Line Of Code - LOC

Consiste nel conteggio delle linee di codice di un programma, che però NON tiene conto del linguaggio utilizzato e dell’accavallamento di istruzioni sulla stessa riga.

Varianti

-NLOC (Non Comment LOC) → Senza spazi vuoti;
-NCNB (Non-Comment Non-Blank) → Senza spazi vuoti e commenti;
-CLOC (Comment LOC) → Solo commenti;

Function Points - FP

È una nuova metrica basata sull’idea di quantificare un software dal punto di vista di un utente → fornisce una misura oggettiva e comparativa che assiste nella valutazione e progettazione della produzione software, ma non tiene conto della difficoltà reale dell’ algoritmo.

Il processo per determinare la mole (quantità) di software è FPA (Function Points Analysis), costituito da due fasi:
Individuazione delle astrazioni significative per l’utente partendo dalle specifiche software;
Partendo da queste, calcolare un numero razionale (FP) che misura la mole;

Gli FP devono valutare il software indipendentemente dalla tecnologia per lo sviluppo (es: linguaggio, tools ecc…), misurando tutte le funzioni richieste.

Tipi di conteggio degli FP

Conteggio per un progetto di sviluppo;
Conteggio per un progetto di manutenzione;
Conteggio per un’applicazione;

Metodo standard IFPUG (International Function Points Users Group)

È il metodo standard per la misurazione dei FP. Il calcolo viene effettuato secondo uno schema composto da 7 fasi:
Pianificazione del conteggio degli FP e identificazione del tipo conteggio;
Raccolta della documentazione e identificazione del confine;
Inventario delle funzioni e calcolo degli FP non pesati;
Classificazione dei componenti;
Esaminazione delle 14 caratteristiche generali del sistema (GSC) e determinazione del valore del fattore di aggiustamento (VAF);
Tabulazione dei risultati;
Convalida dei risultati;

La valutazione dei costi di un progetto informatico

La stima dei costi del software si focalizza su:
Tempo di sviluppo;
Lavoro richiesto (anni-uomo MY o mesi-uomo MM);
Persone partecipanti;

Nei software, la stima dei costi è più complicata, perché viene calcolata in modo diverso dagli altri progetti ingegneristici, in cui vi è una semplice formula di costo.

Nei software, il costo di manutenzione è maggiore di quello di sviluppo.
A causa dei numerosi fattori che possono influenzare lo sviluppo di un software, non si è ancora giunti a un unico modello consolidato per la stima dei costi.

Stima dei costi

La stima dei costi è utile per:
Stipulare contratti di sviluppo sensati;
Prevedere tempi di sviluppo ragionevoli;
Dimensionare il team di sviluppo;

I fattori che influenzano lo sforzo per la realizzazione di un progetto software sono:
Dimensione del software;
Fattori Umani;
Complessità dell’applicazione;
Scalabilità dei requisiti;
Prestazioni e vincoli non funzionali richiesti all’applicazione: maggiori sono i vincoli, maggiori sono i costi;
Ambiente di sviluppo: organizzazione interna dell’azienda e del team;

Dimensioni del software

Due tipi di dimensione:
Interna (o strutturale) → Misurata in LOC;
Esterna (o funzionale) → Misurata in FP;

Metriche di dimensione interna.

Vantaggi

-Facilmente definibili;
-Facilmente misurabili;
-Facilmente interpretabili;
-Utilizzate in molti modelli esistenti;
-Presenti in tutti gli archivi storici di dati raccolti in passato;

Svantaggi

-Nessuna definizione standard per contare le LOC;
-Linguaggio e stile di programmaz. incidono sul numero di LOC;
-Non viene tenuto conto della diversa “potenza” delle istruzioni;
-Non vengono valutate le funzionalità delle LOC;
-Il valore delle LOC è difficile da stimare nelle fasi iniziali del ciclo;

Metriche di dimensione esterna.

Vantaggi

- Stessi vantaggi delle metriche di dimensione interna, ad eccezione che NON sono facilmente definibili.

Svantaggi

-Difficile definire in modo generale la funzionalità (non sempre condivisa);
-La determinazione degli FP è piuttosto soggettiva;
-Lo schema dei pesi usato per il calcolo di FP è soggettivo;
-Gli FP trovano la miglior applicazione per la stima dei Management Information System, ma non sono molto performante degli altri sistemi informatici;

I metodi basati su modelli generici si dividono in:
-Proprietari: i dettagli delle modalità di stima non sono pubblici, ma dell’organizzazione che ha utilizzato il metodo;
-Non proprietari: la metodologia è pubblica e può essere usata da tutti;

I metodi basati su modelli specifici si dividono in:
-Metodi data driven: vengono derivati a partire dai dati con tecniche statistiche
-Parametrici;
-Non parametrici;
-Metodi composti: sono realizzati in base all’opinione di esperti;

I metodi non basati su modelli si basano sull’esperienza di un esperto che effettua direttamente una stima. Lo sforzo ottenuto è soggettivo, ed è sempre necessario il confronto tra più specialisti.
Le tecniche utilizzate dagli esperti sono di tipo top down (scomposizione dei componenti) o bottom up (analizzando il sistema per attività).

Metodi basati su modelli proprietari

In questi modelli, l’algoritmo non è noto all’utente. I metodi basati su modelli proprietari hanno più difficoltà ad essere accettati.

la valutazione della qualità del software

Occorre identificare gli attributi del software e le specifiche funzionali di interesse per l’utente, e includere nei requisiti tutti gli aspetti di qualità ritenuti essenziali per l’applicazione.

Due tappe fondamentali per la definizione della qualità del software:
1) Modello di McCall-Boehm;
2) Norma ISO/IEC 9126;

Struttura del modello di McCall-Boehm

Prodotto software: programmi, regole pertinenti all’uso di un sistema informatico.
Qualità del software: insieme delle caratteristiche che incidono sulla capacità del prodotto di soddisfare requisiti.

I modelli di qualità del software sono generalmente strutturati a livelli. I modelli di McCall e Boehm hanno un’architettura a 3 livelli:
-Fattori → descrivono il SW dal punto di vista esterno;
-Criteri → elementi su cui agiscono gli sviluppatori per soddisfare i requisiti;
-Metriche → controllano che i criteri corrispondano ai fattori specificati;

Il modello di McCall, migliorato poi da Boehm, suggerisce una visione gerarchica e un approccio top-down alla sua definizione (parti alte visibili all’utente, parti basse visibili al produttore).

McCall trovò 11 fattori, suddivisi in 3 categorie:
1. Usabilità
-Correttezza;
-Affidabilità;
-Efficienza;
-Integrità;
-Soddisfazione;
2. Manutenibilità
-Manutenibilità;
-Flessibilità;
-Testabilità;
3. Portatilità
-Portatilità;
-Riusabilità;
-Interoperabilità;

La norma ISO/IEC 9126

La norma, scritta in collaborazione con la IEC (International Electrotechnical Commission), descrive un modello di riferimento per definire la qualità del software.
Definisce i seguenti punti:
-Il modello delle caratteristiche e sotto-caratteristiche di qualità del software;
-Tre tipologie di qualità del software:
->Esterna → valuta le prestazioni del prodotto dal punto di vista funzionale;
->Interna → viene misurata sul codice sorgente. Si ottiene la qualità interna
soddisfacendo i requisiti e le specifiche tecniche;
->In uso → quanto il software riesce a soddisfare l’utente;
-Per ciascuna delle caratteristiche sono riportate le sotto-caratteristiche;
-Per ciascuna sotto-caratteristica sono indicati i descrittori in base ai quali effettuare le misure;

Errori, difetti, malfunzionamenti

-Errore (error) → commesso da un essere umano;
-Difetto (fault o defect) → caratteristica fisica di un fattore del progetto;
-Malfunzionamento (failure) → la conseguenza di un difetto durante l’utilizzo;