Predizione dei costi nei progetti software mediante l'analisi dei punti funzione e dei casi d'uso

Introduzione 
______________________________________________________________________ 
Per chiarire meglio questi concetti facciamo un breve esempio. Supponiamo di disporre 
di rilevazioni atmosferiche rilevate durante l’arco di tutta la giornata. Ogni singola 
rilevazione rappresenta la temperatura esterna a una determinata ora del giorno, ossia 
la misura; ma una sola rilevazione non restituisce nessuna informazione, rappresenta 
solo un dato storico. 
Se si prende in considerazione la serie di rilevazioni effettuate nell’arco della giornata, si 
potrà notare il trend delle temperature, e quindi si esprimerà una metrica. In questo 
caso però manca un termine di confronto che è fondamentale per lo svolgimento di 
attività decisionali. 
Rilevazioni Giornaliere
0
2
4
6
8
10
12
14
16
18
20
0 5 10 15 20 25 30
Rilevazioni Giornaliere
 
 Dunque è l‘indicatore che fornisce l’informazioni necessarie affinché si possano 
prendere decisioni più opportune al caso in esame. 
0
2
4
6
8
10
12
14
16
18
20
0 5 10 15 20 25 30
Rivelazione Giornaliere
Media Stagionale
 
Il concetto di misurazione può essere applicato anche al software, la sua utilità si 
concretizza essenzialmente nella quantificazione dei suoi attributi e nella possibilità di 
 6
Introduzione 
______________________________________________________________________ 
stimare e pianificare lo sforzo produttivo necessario per la realizzazione di progetti 
futuri.  
 
Questo lavoro di tesi si basa proprio sul concetto della misurazione del software.  
Il primo obiettivo di questo progetto è di prendere confidenza con alcune metriche, 
come punti funzione, utilizzate per misurare lo sforzo produttivo necessario per lo 
sviluppo di software. 
Successivamente si è presentata la possibilità di costruire un modello statistico basato 
sulle misure tenute con l’analisi dei punti funzione e su alcune misure fornite 
dall’azienda informatica AreaIT di Sansepolcro, presso la quale il progetto di tesi è stato 
svolto. Questo modello statistico ha lo scopo di facilitare la pianificazione e la stima 
dello sforzo produttivo necessario per lo sviluppo di progetti futuri. 
A supporto dell’attività di stima, è stato sviluppato anche un applicazione per poter 
creare in maniera abbastanza veloce report di riepilogo delle stime. 
 
 
 
 
 7
Capitolo 1                                                                                      Cenni di Modelli Qualità 
______________________________________________________________________ 
 
 
 
 
Capitolo 1  
Cenni di Modelli Qualità  
8 
Capitolo 1                                                                                      Cenni di Modelli Qualità 
______________________________________________________________________ 
Introduzione 
A partire dalla fine degli anni ’70 la crescente attenzione rivolta alla qualità di prodotto a 
portato alla formulazione dei cosiddetti Quality Model, definiti come “il set di 
caratteristiche e rispettive relazioni che fornisce la base per specificare requisiti di 
qualità e valutare la qualità” [1.1], o come “un set organizzato di proprietà richieste per 
un oggetto di una classe per soddisfare obiettivi definiti” [1.2]. 
L’utilità di questi modelli risiede nel fatto che vengono espresse le caratteristiche, le 
sottocaratteristiche e le misure di un oggetto in corso di valutazione, e questi possono 
essere utilizzati sia per la previsione, che per l’assicurazione, che per la verifica del 
raggiungimento di un determinato obiettivo, riguardante l’oggetto sia prima che durante 
che dopo la sua progettazione. 
I vari modelli di qualità possono essere classificati in base al numero di layers: 
1. Modelli a due layers: si ha un lista di caratteristiche suddivisa in  due livelli. 
Questo porta  ad una descrizione più vicina al punto di vista dell’utente; 
2. Modelli a tre layers:  si aggiunge un ulteriore livello di dettaglio per descrivere le 
singole misure di sottocaratteristica, naturalmente più vicino ad una prospettiva 
tecnica. 
Si può fare un’ulteriore classificazione dei modelli di qualità, in base al numero di 
relazioni che abbiamo tra i primi due layers: 
1. Relazioni 1:n – ogni caratteristica possiede un proprio set di sottocaratteristiche; 
2. Relazioni n:m – ogni sottocaratteristica può essere collegata a più categorie. 
I modelli di qualità più conosciuti sono sicuramente il modello derivato dallo standard 
ISO 9126, il modello Goal Question Metric proposto da V.R. Basili, G.Caldiera e H.D. 
Rombaci e il Capability Maturity Model sviluppato da Software Engineering Institute. 
1. Norma ISO 9126 
Il norma ISO 9126 [1.3], pubblicata nel 1991, definisce il modello dei requisiti qualitativi 
del prodotto software. Secondo questo modello si possono definire tre aspetti della 
qualità del software:  
1. Qualità interna: la totalità degli attributi di un prodotto che determinano l’abilità di 
soddisfacimento dei bisogni sotto determinate condizioni; 
 9
Capitolo 1                                                                                      Cenni di Modelli Qualità 
______________________________________________________________________ 
2. Qualità esterna: il livello di soddisfacimento del cliente quando utilizzo il prodotto 
sotto determinate condizioni; 
3. Qualità in uso: la capacità di un prodotto software che consente agli utenti di 
raggiungere specifici obiettivi con efficacia, produttività, sicurezza e 
soddisfazione sotto determinate condizioni.  
Nella Figura 1.1 verranno riportate le relazioni tra i tre diversi aspetti di qualità del 
prodotto software. 
 
Dipende daDipende da
Influenza
Influenza
 
Qualità 
Interna 
Qualità 
Esterna 
Qualità 
In Uso 
Figura 1.1 – Relazione fra i diversi aspetti di qualità 
Ora andiamo ad analizzare le varie caratteristiche attraverso le quali si possono 
valutare i tre aspetti della qualità. 
Iniziamo con la qualità interna ed esterna. Per questi due aspetti si possono distinguere 
6 categorie principali e 21 categorie secondarie. In Figura 1.2 viene riportata la struttura 
gerarchica di queste categorie. 
 
Qualità Interna 
ed Esterna 
Functional Reliability Usability Maintainbility Efficiency Portability 
Suitability 
Accuracy 
Interoperability 
Compliance 
Security 
Maturity 
Fault tolerance 
Recoverability 
 
Understandability 
Learnability 
Operability 
Time behavior 
Resource behavior 
Analysability 
Changeability 
Stability 
Testability 
 
Adaptability 
Installability 
Conformance 
Replaceability 
 
Figura 1.2 – Classificazione caratteristiche per la qualità interna ed esterna nella ISO 9126 
Di seguito verranno illustrate le varie categorie e sottocategorie. 
• Functionality: un software è considerato funzionale nella misura in cui le 
procedure in esso contenute coincidono con le funzioni richieste. 
 10
Capitolo 1                                                                                      Cenni di Modelli Qualità 
______________________________________________________________________ 
⇒ Suitability: attributi che influenzano la presenza e l'appropriatezza 
dell'insieme di funzioni per uno specifico obiettivo; 
⇒ Accuracy: attributi che riguardano la generazione di risultati o azioni 
corrette e accurate; 
⇒ Interoperability: attributi che influenzano la capacità di interagire con 
specifici sistemi; 
⇒ Compliance: attributi che rendono il software aderente agli standard, 
convenzioni o regolamenti legislativi applicabili all'applicativo; 
⇒ Security: attributi che permettono di prevenire accessi non autorizzati, 
siano essi accidentali o deliberati, ai dati o ai programmi. 
• Reliability: un software è ritenuto affidabile quando è in grado di mantenere il 
livello di prestazioni sotto determinate condizioni e per un determinato periodo di 
tempo. 
⇒ Maturity: attributi che influenzano la frequenza dei fallimenti dovuti a errori 
nel software;  
⇒ Fault Tolerance: attributi che permettono al software di mantenere uno 
specificato livello di prestazioni in caso di errore del software; 
⇒ Recoverability: attributi che consentono di ristabilire il suo livello di 
prestazioni e di ricuperare i dati persi in occasione di errori; 
• Usability: un software è considerato usabile in proporzione alla facilità con cui gli 
utenti operano per sfruttare appieno le funzionalità che esso realizza. 
⇒ Understandability: attributi che influenzano lo sforzo compiuto dall'utente 
nel riconoscere i concetti logici e la loro applicabilità all'interno del 
software; 
⇒ Learnability: attributi che influenzano lo sforzo compiuto dall'utente 
nell'imparare ad usare l'applicativo, come per esempio le operazioni di 
controllo, di input o di output; 
⇒ Operability: attributi che influenzano lo sforzo compiuto dall'utente nel 
controllo delle capacità del software. 
• Efficiency: l'efficienza di un software è proporzionale al rapporto tra il livello 
generale di prestazioni e l'ammontare delle risorse necessarie al suo 
funzionamento.  
 11
Capitolo 1                                                                                      Cenni di Modelli Qualità 
______________________________________________________________________ 
⇒ Time behavior: attributi che influenzano i tempi di risposta e di esecuzione 
delle funzionalità del software; 
⇒ Resource behavior: attributi che influenzano l'ammontare e l'utilizzo nel 
tempo delle risorse, durante l'esecuzione delle funzionalità del software. 
• Maintainbility: è l'attitudine del software ad essere modificato a costi accessibili 
ed in tempi rapidi. 
⇒ Analysability: attributi che influenzano lo sforzo compiuto per le fasi di 
diagnostica delle cause degli errori e per l'identificazione delle parti di 
software da modificare; 
⇒ Changeability: attributi che influenzano lo sforzo necessario per le 
modifiche, la rimozione degli errori o per i cambi ambientali; 
⇒ Stability: attributi che influenzano i rischi legati ad eventi inaspettati o 
modifiche; 
⇒ Testability: attributi che influenzano lo sforzo necessario alla validazione di 
un software modificato. 
• Portability: un software è considerato portabile quando è possibile trasferirlo in 
modo sufficientemente veloce da un ambiente (hardware, sistema operativo, 
etc.) ad un altro. 
⇒ Adaptability: attributi che influenzano la possibilità di adattamento a 
differenti ambienti senza ricorrere ad altre azioni che quelle previste per il 
software considerato; 
⇒ Installability: attributi che influenzano lo sforzo necessario per installazione 
del software in uno specifico ambiente; 
⇒ Conformance: attributi che rendono il software aderente agli standard o 
alle convenzioni relative alla portabilità; 
⇒ Replaceability: attributi relativi alla possibilità di sostituire altri specifici 
software all'interno del loro ambiente. 
Invece per valutare la qualità in uso si fa riferimento a quattro caratteristiche.  
 
 12
Capitolo 1                                                                                      Cenni di Modelli Qualità 
______________________________________________________________________ 
Qualità in Uso 
Efficacia Produttività Sicurezza Soddisfazione 
 
Figura 1.3 – Classificazione caratteristiche per la qualità in uso nella ISO 9126 
Di seguito verranno illustrate le quattro categorie della qualità in uso. 
• Efficacia: capacità del software di raggiungere obiettivi specificati con 
accuratezza e completezza; 
• Produttività: la capacità del software di impiegare le risorse in relazione alle 
effettive richieste; 
• Sicurezza: la capacità del software di raggiungere un livello di rischio 
accettabile; 
• Soddisfazione: la capacità del software di soddisfare gli usi in particolari 
condizioni. 
La norma definisce anche possibili metriche con cui misurare ognuna delle 
sottocaratteristiche, con indicazione precisa della formula di misura, delle modalità di 
calcolo e dei criteri di interpretazione dei risultati delle prove. Viene così meglio definito 
il processo di raccolta dei requisiti di un prodotto Software, che può essere guidato e 
valutato con riferimento alla norma ISO 9126.  
2. Goal Question Metric (GQM) Model 
Il Modello Goal Question Metric [1.4] fu inizialmente sviluppato per valutare gli errori nei 
progetti della NASA, successivamente si capì che poteva essere applicato anche ad 
altri tipi di progetti e così fu generalizzato.  
Per poter applicare questo modello si devo seguire alcuni passi: 
• Si devono analizzare e comprendere bene gli obiettivi del progetto o 
dell’organizzazione; 
• Per ogni obiettivo si devono definire delle domande a cui dare una risposta per 
capire se l’obiettivo è stato raggiunto o meno; 
• Si deve definire quali attributi misurare per dare risposta alle varie domande. 
 13
Capitolo 1                                                                                      Cenni di Modelli Qualità 
______________________________________________________________________ 
Questo paradigma riconosce come fondamentale la definizione degli obiettivi che una 
certa organizzazione intende perseguire con un programma di misura e, a partire da 
questi e dallo stato corrente dell’azienda, fornisce un modo per individuare quali misure 
potrebbero essere utilizzate. La misura è posta in un contesto e sviluppata per punti di 
vista ben definiti, così che ne risulta facilitata la verifica dell'utilità prima, l'interpretazione 
e l'utilizzo poi. 
Il risultato che otteniamo applicando il paradigma GQM è un modello gerarchico a tre 
livelli: 
• Livello Concettuale (Goal): in questo livello troviamo la definizione del problema 
che si vuole risolvere. Nella definizione del problema si devono identificare lo 
scopo, gli attributi, le entità, il punto di vista e il contesto. 
• Livello Operativo (Question): a partire dalle informazioni specificate al livello 
precedente, si devono formulare domande che mi individuano meglio il problema 
e mi delimitano le modalità con cui raggiungere l’obiettivo. 
• Livello Qualitativo (Metric): in questo livello vengono identificati i modelli 
necessari per dare risposte empiricamente fondate alle domande individuate al 
livello precedente. 
In Figura 1.4 viene riportato uno schema per descrivere graficamente il modello GQM. 
Goal 1 Goal 2 Goal n 
Quality Focus 3 Quality Focus 1 Quality Focus 3 Quality Focus p
Question 1 Question 2 Question m 
Metric 1 Metric w Metric k 
…….
…….
…….
…….…….
 
Figura 1.4 – Schema dell’architettura del paradigma Goal Questions Metrics 
Per meglio comprendere questo paradigma in Figura 1.5 verrà riportato un esempio. 
 14
Capitolo 1                                                                                      Cenni di Modelli Qualità 
______________________________________________________________________ 
Goal: Valutare l’efficacia di scrivere un codice secondo standard 
Chi Sta Usando 
Standard? 
Cos’è la produttività 
dei programmatori? 
Cos’è la qualità del 
codice? 
Questions:  
Metrics:  Proporzione dei “coders” 
- che standard usano 
- che linguaggio usano 
Esperienza dei “coders” 
-  con standard 
- con linguaggio 
Code size 
- LOC 
- FP 
Effort        Errors
 
Figura 1.5 – Esempio del paradigma Goal Questions Metrics 
3. Capability Maturity Model  
Il Capability Maturity Model for Software [1.5] fu sviluppato a partire dagli anni ’80, lo 
scopo iniziale era quello di identificare il livello di maturità dei fornitori di software del 
dipartimento della difesa Statunitense tramite un questionario [1.6], che classifica il 
risultato in una scala ordinale a 5 livelli. 
Prima di continuare diamo la definizione di Maturity Level. Questo rappresenta “il grado 
di bontà dei processi raggiunto su un insieme di aree di processo nelle quali gli obiettivi 
imposti sono stati raggiunti”. 
Generalmente ci riferiamo a 5 livelli di maturità, come già accennato prima: 
Processi in continuo miglioramento
Processi Prevedibili
Processi Consistenti, Standard 
Processi Disciplinati 
1 - Iniziale 
2 - Ripetibile 
3 - Definito 
4 - Gestito 
5 - Ottimizzato 
 
Figura 1.6 – Livelli di Maturità del Capability Maturity Model 
 però sono stati introdotti anche livelli inferiori per caratterizzare delle situazioni di 
carenza ancora più accentuata. 
Partiamo dal livello più basso per dare una breve descrizione di ogni livello: 
 15
Capitolo 1                                                                                      Cenni di Modelli Qualità 
______________________________________________________________________ 
Livello -3 Indebolito: Negazione totale delle proprie politiche. Sono ricompensati il 
fallimento e le scarse performance; 
Livello -2 Altezzoso: Mancanza di attenzione istituzionalizzata per le buone pratiche di 
sviluppo software. Separazione totale tra attività di sviluppo e di miglioramento dei 
processi. Assenza totale di un programma di formazione. 
Livello -1 Ostruzionista: I processo sono definiti rigidamente ed è enfatizzata 
l’aderenza alla forma. La gestione collettiva preclude l’assegnazione delle 
responsabilità. Lo status quo è al di sopra di tutto. 
Livello 0 Trascurato: Caratterizzato dall’indifferenza. Tutti i problemi sono percepiti 
essere di natura tecnica. Le attività di gestione e quality assurance sono considerate 
superflue per il processo di sviluppo del software. 
Livello 1 Iniziale: Il processo software è posizionato ad uno stadio organizzativo 
iniziale, spesso caotico, con pochi processi definiti, dove il successo dipende 
dall’impegno individuale. 
Livello 2 Ripetibile: Sono implementati i processi minimi di project management per 
monitorare costi, schedulazioni e funzionalità, ponendo le basi per ottenere processi 
consistenti e robusti. 
Livello 3 Definito: Sono documentati, standardizzati ed integrati i processi delle attività 
manageriali e tecniche, rendendo possibili attività di previsione. 
Livello 4 Gestito: Sono collezionate misure dettagliate del processo software e della 
qualità del prodotto. Processi e prodotti sono quindi controllati e gestiti attraverso l’uso 
di tecniche quantitative. 
Livello 5 Ottimizzato: E’ attivato un miglioramento continuo dei processi basato su 
feedback quantitativi di processo e da idee e tecnologie innovative introdotte 
nell’organizzazione. 
Ogni livello di maturità è composto da Key Process Areas (KPA), ossia un cluster di 
attività che, se eseguite congiuntamente, permettono il raggiungimento degli obiettivi 
connessi a quel dato livello di maturità. Nella versione del CMM 1.1 troviamo 18 KPA 
che sono ripartite tra il livello 2 e il livello 5. A sua volta ogni KPA è organizzata in 
Common Features (CFs), ossia attributi che indicano se l’implementazione e 
l’istituzionalizzazione di una KPA sia effettiva, ripetibile o durevole. Infine le CFs 
raggruppano le Key Practices (KPs), ossia il “cosa” deve essere fatto in ognuna delle 
categorie possibili. 
 16