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

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.

Tipi di metriche 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…;

1) Primitiva o diretta → misura di attributi direttamente osservabili (es: LOC);

2) Calcolata o indiretta → no misure dirette, ma parte da altre metriche;

Valutazione dei costi del software

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

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.

-NLOC (Non Comment LOC) → Senza spazi vuoti;

-NCNB (Non-Comment Non-Blank) → Senza spazi vuoti e commenti;

-CLOC (Comment LOC) → Solo commenti;

Function Points Analysis (FPA)

È 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.

Conteggio per un progetto di sviluppo;

Conteggio per un progetto di manutenzione;

Conteggio per un’applicazione;

È 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;

Stima dei costi e fattori influenti

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.

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 interne ed esterne

Due tipi di dimensione:

Interna (o strutturale) → Misurata in LOC;

Esterna (o funzionale) → Misurata in FP;

Metriche di dimensione interna.

-Facilmente definibili;

-Facilmente misurabili;

-Facilmente interpretabili;

-Utilizzate in molti modelli esistenti;

-Presenti in tutti gli archivi storici di dati raccolti in passato;

-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.

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

-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;

Modelli di stima dei costi

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à).

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

Qualità del software e modelli

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;
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à;

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;

-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;