Metodi Sperimentali Per La Produzione Del Software

UNIVERSITÀ DEGLI STUDI DI BARI 
FACOLTÀ DI SCIENZE MM.FF.NN. 
 
Corso di Laurea Magistrale in Informatica 
Metodi sperimentali per la produzione del software 
 
 
 
 
CASO DI STUDIO 
MICHELE FILANNINO 
[Matricola: 552368] 
 
 
Anno accademico: 
2008/2009 
 
 
 
 
 
Gruppo di lavoro 18: 
Michele FILANNINO, Marco LUCARELLI
 
Indice 
Indice ................................................................................................................... 2 
Indice delle figure ........................................................................................... 5 
Capitolo 1: Evoluzione di una coreografia per un processo di test 9 
1.1 Step 1.............................................................................................................................. 10 
Attori...............................................................................................................................................................................11 
Manufatti .......................................................................................................................................................................12 
Work Flow System ....................................................................................................................................................14 
1.2 Step 2.............................................................................................................................. 15 
Attori...............................................................................................................................................................................16 
Manufatti .......................................................................................................................................................................18 
Work Flow System ....................................................................................................................................................20 
1.3 Step 3.............................................................................................................................. 23 
Attori...............................................................................................................................................................................24 
Manufatti .......................................................................................................................................................................26 
Work Flow System ....................................................................................................................................................29 
1.4 Step 4.............................................................................................................................. 34 
Attori...............................................................................................................................................................................35 
Manufatti .......................................................................................................................................................................36 
Work Flow System ....................................................................................................................................................40 
  2 
1.5 Step 5.............................................................................................................................. 48 
Attori...............................................................................................................................................................................49 
Manufatti .......................................................................................................................................................................50 
Work Flow System ....................................................................................................................................................56 
Capitolo 2: GQM per la valutazione un processo di test ...................65 
Goal ......................................................................................................................................... 66 

Question................................................................................................................................ 68 
Metric..................................................................................................................................... 71 
Fogli metrici.................................................................................................................................................................82 
Piano di misurazione ...............................................................................................................................................89 
Modello di calcolo...................................................................................................................................................108 
Tavole di decisione ................................................................................................................................................120 
Capitolo 3: Simulazione ed analisi dei dati rilevati ........................ 130 
Processo di sperimentazione ....................................................................................131 
Caso di studio ...................................................................................................................134 
Goal 1 ...........................................................................................................................................................................135 
Goal 2 ...........................................................................................................................................................................141 
Goal 3 ...........................................................................................................................................................................146 
Goal 4 ...........................................................................................................................................................................151 
Appendice ..................................................................................................... 158 
A. Metodologia di lavoro..............................................................................................159 
Introduzione ............................................................................................................................................................. 159 
Il Pair Programming..............................................................................................................................................159 
A.1 Vantaggi .............................................................................................................................................................. 160 
A.2 Svantaggi ............................................................................................................................................................ 161 
B. Aula virtuale ................................................................................................................162 
B.1 Vantaggi .............................................................................................................................................................. 163 
B.2 Svantaggi ............................................................................................................................................................ 164 
C. Tools................................................................................................................................164 
C.1 Enterprise Architect ......................................................................................................................................164 
C.2 TABULA ............................................................................................................................................................... 166 
  3 
C.3 STATISTICA ....................................................................................................................................................... 167 
D. Effort speso ..................................................................................................................168 
Effort speso in generale .......................................................................................................................................168 
Effort speso per i tool ...........................................................................................................................................168 
Bibliografia................................................................................................... 170 
Allegati ........................................................................................................... 171 
  4 
Indice delle figure 
Figura 1: STEP 1 ‐ Traccia ................................................................................................... 10 
Figura 2: STEP 1 ‐ Test e Debugging............................................................................... 14 
Figura 4: STEP 2 ‐ Attori ...................................................................................................... 17 
Figura 5: STEP 2 ‐ Test e Debugging............................................................................... 20 
Figura 6: STEP 2 ‐ Piano, Esecuzione e Debugging dei casi di test .................... 21 
Figura 8: STEP 3 ‐ Attori ...................................................................................................... 25 
Figura 9: STEP 3 ‐ Manufatti “Piano_dei_casi_di_test” ............................................ 27 
Figura 10: Esempio di errore di consistenza globale dei manufatti ................. 27 
Figura 11: STEP 3 ‐ Test e Debugging ............................................................................ 29 
Figura 12: STEP 3 ‐ Piano, Esecuzione e Debugging dei casi di test ................. 30 
Figura 13: Concettualizzazione di un Work Flow System..................................... 31 
Figura 14: STEP 3 ‐ Pianificazione test di unità e test d’integrazione.............. 32 
Figura 15: STEP 4 ‐ Traccia................................................................................................. 34 
Figura 16: STEP 4 ‐ Attori.................................................................................................... 35 
  5 
Figura 17: STEP 4 ‐ Manufatti "Piano_dei_casi_di_test" ......................................... 38 
Figura 18: STEP 4 ‐ Manufatti "Piano_dei_casi_di_test_di_unità"....................... 39 
Figura 21: STEP 4 ‐ Pianificazione test di unità e di integrazione ..................... 42 
Figura 22: STEP 4 ‐ Pianificazione test d'unità .......................................................... 44 
Figura 23: STEP 5 – Traccia................................................................................................ 48 
Figura 24: STEP 5 ‐ Attori.................................................................................................... 49 
Figura 25: STEP 5 ‐ Manufatti "Piano_dei_casi_di_test" ......................................... 52 
Figura 26: STEP 5 – Manufatti “Piano_dei_casi_di_test_d'unità” ........................ 53 
Figura 27: STEP 5 ‐ ManufattI "Report_dei_casi_di_test"....................................... 54 
Figura 30: STEP 5 ‐ Pianificazione test di unità e d’integrazione ...................... 58 
Figura 31: STEP 5 ‐ Pianificazione test di unità......................................................... 60 
Figura 32: STEP 5 ‐ Esecuzione dei casi di test .......................................................... 63 
Figura 33: Struttura gerarchica del modello GQM ................................................... 66 
Figura 34: Concettualizzazione di un esperimento come processo................132 
Figura 35: Esempio di box plot .......................................................................................133 
Figura 36: Goal 1 ‐ Box Plot 1° esperimento .............................................................138 
  6 
Figura 42: Goal 3 ‐ Box Plot 2° esperimento ‐ incidenza sull'effort ................151 
Figura 45: Goal 4 ‐ Box Plot 2° esperimento ‐ incidenza sull'effort ................157 
Figura 46: Schermata di Enterprise Architect 5.0 ..................................................165 
Figura 47: Schermata di TABULA ..................................................................................166 
Figura 48: Schermata di STATISTICA...........................................................................168 
   
  7 
 
  8 
Capitolo 1: 
Evoluzione di una coreografia per un 
processo di test 
Il seguente documento presenta una trattazione tecnica relativa alla modellazione 
di  un  processo  (inteso  come  l’insieme  delle  attività  eseguite  da  persone  e/o 
sistemi,  scatenate  da  un  evento  innescante  e  finalizzate  alla  realizzazione  di  un 
prodotto). 
Scopo  di  questa  trattazione  è  illustrare  metodologie,  tecniche  e  strumenti  propri 

della  sperimentazione  nell’ingegneria  del  software  astraendo  dalla  semantica  del 
dominio applicativo trattato. La scelta del processo di test software piuttosto che 
un’altra, l’ottica di questo documento, sono totalmente uguali. 
In questo capitolo, in particolare, verrà affrontata la modellazione di un processo 
di test software. Partendo dalle pratiche consolidate dell’ingegneria del software si 
procederà  a  descrivere  in  maniera  comprensibile,  corretta,  completa  e  non 
ambigua tutte le variabili del processo software.  
Il  linguaggio  utilizzato  per  la  rappresentazione  del  modello  sarà  FSPSPEM.  Il 
disegno  verrà  eseguito  utilizzando  un  opportuno  software  di  modellazione  (vedi 
pagina 164). 
Nei successivi capitoli si presenteranno ulteriori altre attività che possono essere 
eseguite  su  di  un  modello  di  processo  al  fine  di  valutarlo  e  conseguentemente 
migliorarlo.  Il  disegno  del  modello  di  processo,  che  introduciamo,  rappresenta  il 
primo passo di questo caso di studio. 
Di  seguito  si  presentano  tutti  gli  Step  di  modellazione.  Per  ognuno  di  questi  ho 
provveduto  ad  inserire  la  traccia  così  come  ci  è  stata  fornita  durante  le 
  9 
esercitazioni  ed  il  report  automatico  generato  dal  software  di  modellazione 
utilizzato. Sono stati inseriti dei commenti tecnici che hanno lo scopo di chiarire e 
migliorare  la  leggibilità  del  report  (di  per  sé  strutturato  e  poco  discorsivo).  La 
successione degli step è incrementale (il primo è costruito sul secondo, il secondo 
sul  terzo  etc…).  Per  questa  ragione,  di  ogni  step,  verranno  commentati  solo  gli 
aspetti caratteristici non trattati in precedenza. 
Ove  presenti,  i  commenti  tecnici  sono  stati  evidenziati  attraverso  la  seguente 
notazione: 
Quello che stai leggendo è un commento tecnico.  
1.1 Step 1 
Figura 1: STEP 1 ‐ Traccia 
  10 
Lo  Step  1  prevede  la  modellazione  di  un  processo  con  pochi  vincoli,  pertanto 
molti gradi di libertà. La traccia fa riferimento ad un generico processo di TEST e 
DEBUGGING senza lasciar intendere quali possano essere le sue sotto‐attività. 
Il  processo  in  questione  si  presenta  nel  livello  massimo  di  generalità:  le 
indicazioni potrebbero sembrare incomplete o troppo vaghe ma non è detto che 
lo  siano  senza  una  giusta  motivazione:  può  capitare  che  al  fine  del  contesto,  il 
progettista non ritenga opportuno dettagliare ulteriormente l’attività. 
La situazione sopra descritta non è necessariamente sbagliata: un’attività non ha 
bisogno di essere dettagliata se il livello di granularità è sufficiente per rilevare 
le  misure  che  si  ritengono  valide  ai  fini  della  valutazione  della  qualità  del 
processo. In questo contesto, l’attività viene vista come un blocco monolitico. In 
generale,  a  maggiore  generalità  corrisponde  un  maggior  numero  di  gradi  di 
libertà.  
Nella  descrizione  vengono  indicati  i  manufatti  entranti  e  quelli  uscenti  da  tale 
attività  ed  anche  il  ruolo  dell’operatore  incaricato  a  svolgerla.  Considerando  la 
generalità  di  tale  processo  e  la  presenza  di  una  sola  attività  è  ragionevole 
concludere  che  tutti  i  manufatti  entranti  ed  uscenti  verranno  associati  a 
quest’unica attività: TEST e DEBUGGING. 
Attori 
Sviluppatore  
public «ProcessRole» Actor: Attore con competenze nello sviluppo software. Egli 
assolve  responsabilità  di  carattere  generale  avendo  una  preparazione  media  in 
tutti i contesti dello sviluppo software. 
Lo stereotipo ProcessRole indica il ruolo (la figura professionale e non la persona 
fisica)  dell’attore  responsabile  all’esecuzione  di  una  particolare  attività.  In 
questo caso TEST e DEBUGGING. 
  11 
Manufatti  
Manufatti::Codice_corretto  
public  «WorkProduct»  Class:  Il  manufatto  deve  rappresentare  il  codice  che  può 
essere direttamente eseguito privo degli errori rilevati.  
Lo  stereotipo  WorkProduct  indica  un  particolare  manufatto  caratterizzato  da 

una rigida e rigorosa strutturazione dei dati. In questa categoria rientrano tutti 
quei  documenti  prodotti  con  precise  regole  di  produzione  o  in  generale 
fortemente strutturati. 
Manufatti::Codice_Sorgente  
public «WorkProduct» Class:  Il manufatto deve essere formato dall'insieme delle 
righe di codice che compongono il sistema software.  
Manufatti::Descrizione_dei_casi_d'uso  
public  «Document»  Class:    Il  manufatto  contiene  la  descrizione  in  linguaggio 
naturale semi‐strutturato di ciascun caso d'uso.  
Lo  stereotipo  Document  indica  un  particolare  manufatto  caratterizzato 

dall’assenza  di  una  strutturazione  dei  dati  contenuti.  In  questa  categoria 
rientrano  tutti  quei  documenti  redatti  in  linguaggio  naturale  o  debolmente 
strutturati. 
Manufatti::Diagramma_dei_casi_d’uso  
public  «UMLModel»  Class:  Questo  manufatto  deve  contenere  il  diagramma  dei 
casi d’uso del sistema software rilevati dall’analista. Il dettaglio del manufatto deve 
seguire lo standard UML.  
Lo  stereotipo  UML  Model  indica  un  particolare  manufatto  il  cui  contenuto  è 
espresso in linguaggio UML. 
Manufatti::Diagrammi_di_sequenza  
public «UMLModel» Class:  Questo manufatto deve contenere per ogni caso d’uso 
la rappresentazione grafica dell’interazione tra le classi del sistema, focalizzandosi 
sulla sequenza temporale dei messaggi che si scambiano. Il dettaglio deve segueire 
lo standard UML.  
  12 
Manufatti::Modello_delle_classi  
public «UMLModel» Class:  Questo manufatto deve contenere la rappresentazione 
grafica del modello delle classi. Il dettaglio deve seguire lo standard UML.  
Manufatti::Piano_dei_casi_di_test  
public  «Document»  Class:  Il  manufatto  deve  contenere  la  pianificazione  dei 
differenti casi di test da eseguire.   
Manufatti::Report_dei_casi_di_test  
public «Document» Class: Il documento deve contenere i risultati semi‐strutturati 
(in forma tabellare) dell'esecuzione di tutti i casi di test.  
Manufatti::Report_di_debugging  
(in forma tabellare) dell’esecuzione del debug. 
Manufatti::Specifiche_delle_classi  
public  «Document»  Class:  Questo  manufatto  deve  contenere  la  descrizione  delle 
interfacce  e  del  comportamento  (metodi)  delle  classi.  Per  ogni  classe  devono 
esistere le seguenti parti: classi che vengono istanziate, da quali classi è istanziata, 
nome  di  ogni  metodo,  tipo  di  visibilità  del  metodo  (pubblico,  privato,  etc...),  cosa 
restituisce ogni metodo (qualora il metodo ritorni un valore), nome formale di ogni 
parametro di un metodo e tipo al quale appartiene.  
  13 
Work Flow System 
Figura 2: STEP 1 ‐ Test e Debugging 
Le  frecce  entranti  nell’attività  indicano  che  il  manufatto  associato  viene 
utilizzato  dall’attività.  Le  frecce  uscenti,  al  contrario,  indicano  la  produzione  di 
questi da parte dell’attività. 
Es.  L’attività  TEST  e  DEBUGGING  utilizza,  tra  gli  altri,  il  manufatto 
Codice_Sorgente  e  produce,  al  termine  della  sua  esecuzione,  il  manufatto 
Codice_Corretto. 
  14 
1. Test e Debugging  
public  «Activity»  Activity:  Attività  monolitica  per  il  test  e  debugging  di  un 
prodotto software. 
1.2 Step 2 
Lo  Step  2  prevede,  a  partire  dallo  step  precedente,  l’introduzione  di  alcuni 
dettagli che lo rendono più organico. Fermo restando quanto scritto per lo step 
1, quella che era l’unica attività TEST e DEBUGGING si dettaglia ulteriormente in 
tre sotto attività. Ogni sotto attività avrà in input ed in output dei manufatti. 
L’attività  di  scomposizione  in  sotto  attività  è  stata  intrapresa,  non  per  una 
migliore  conoscenza  del  processo  applicativo,  quanto  per  un’effettiva  necessità 
strutturale:  tra  i  vincoli  e  le  specifiche  sono  stati  introdotti  tre  nuovi  ruoli 
operativi,  ognuno  dei  quali  è  responsabile  di  una  sotto‐attività  di  TEST  e 
DEBUGGING  invece  che  dell’intero  processo  (come  accadeva  per  Sviluppatore 
dello  step  1).  Nasce  così  l’esigenza  di  dettagliare  ulteriormente  il  modello 
  15 
precedente al fine di assegnare i giusti ruoli alle giuste sotto attività. Il livello di 
granularità del modello di processo diventa più alto. 
Per  ogni  ruolo  introdotto,  la  traccia  fornisce  il  suo  nome,  il  suo  dominio  di 
responsabilità ed il suo ruolo‐padre. I manufatti rimangono gli stessi. 
E’ doveroso enfatizzare che nella traccia non vi è alcun riferimento esplicito alla 
necessità  di  dettagliare  ulteriormente  l’attività  introdotta  in  precedenza,  così 
come accade nella realtà: il livello di dettaglio lo stabilisce il progettista in base 
alla sue esigenze. 
Attori  
Sviluppatore  
public  «ProcessPerformer»  Actor:  Attore  con  competenze  nello  sviluppo 
software.  Egli  assolve  responsabilità  di  carattere  generale  avendo  una 
preparazione media in tutti i contesti dello sviluppo software. 
Un  ProcessPerformer  è  uno  stereotipo  particolare  di  attore.  Un  attore  così 
stereotipato  ha  responsabilità  di  carattere  generico  e  può  essere  a  sua  volta 
specializzato  in  ruoli  diversi.  La  composizione  di  questi  ruoli  è  mostrata  nella 
figura sottostante. 
ProcessPerformer  e  ProcessRole  sono  diversi  poiché  si  pongono  a  livelli  della 

gerarchia  di  generalità  diversi.  Un  ProcessPerformer  è  il  frutto  della 
composizione di più ProcessRole. 
  16 
 
Figura 4: STEP 2 ‐ Attori 
Sviluppatore Debugger 
public «ProcessRole» Actor:  Uno sviluppatore con competenze in tecniche e tool 
per il debugging effettua il debugging.  
Tagged Values  
• Competenze = Tecniche e tool per il debugging. 
 
Un Tagged Value è una coppia attributo‐valore che caratterizza l’oggetto al quale 
esso  è  associato.  In  questo  esempio,  il  modellatore  ha  precisato  che  l’attore 
Sviluppatore Debugger è tale se possiede competenze nell’uso di Tecniche e tool 
per il debugging. 
Sviluppatore Esecutore  
per  l’esecuzione  esegue  i  casi  di  test  e  compila  i  report  di  esecuzione  dei  casi  di 
test.  
• Competenze = Tecniche e tool per l'esecuzione.   
  17 
Sviluppatore Pianificatore 
per la pianificazione dei casi di test realizza il piano dei casi di test.  
Tagged Values 
• Competenze = Tecniche e tool per la pianificazione.    
Manufatti 
public «WorkProduct» Class:  Il manufatto deve rappresentare il codice che può 
righe di codice che componongono il sistema software.  
public  «UMLModel»  Class:    Questo  manufatto  deve  contenere  il  diagramma  dei 
sulla sequenza temporale dei messaggi che si scambiano. Il dettaglio deve seguire 
  18 
public  «Document»  Class:    Il  manufatto  deve  contenere  la  pianificazione  dei 
differenti casi di test da eseguire.   
Manufatti::Report_dei_casi_di_test  
public «Document» Class:  Il documento deve contenere i risultati semi‐strutturati 
(sotto forma tabellare per esempio) dell'esecuzione di tutti i casi di test.  
Manufatti::Report_di_debugging  
Manufatti::Specifiche_delle_classi  
public «Document» Class:  Questo manufatto deve contenere la descrizione delle 
  19 
Work Flow System  
1. Test e Debugging  
public «WorkDefinition» Activity: Attività monolitica per il test e debugging di un 
  20 
 
Figura 6: STEP 2 ‐ Piano, Esecuzione e Debugging dei casi di test  
  21 
Il  diagramma,  di  cui  sopra,  è  la  rappresentazione  grafica  di  come  si  dettaglia 
l’attività  monolitica  TEST  e  DEBUGGING.  Diminuendo  il  livello  di  generalità  è 
evidente che cominciano ad affiorare maggiori dettagli. 
La prima cosa che è possibile notare è il set di manufatti entranti ed uscenti in 
tutte le sotto‐attività. Globalmente questi devono essere gli stessi del livello più 
generale. Quando un manufatto entra ad un livello generale, questo deve entrare 
anche in una o più d’una sotto attività. Quando questo non avviene si verifica un 
errore  di  consistenza  strutturale,  violando  la  regola  secondo  la  quale  “ogni 
attività  utilizza  tutti  e  solo  i  manufatti  della  fase  che  dettaglia  e  tutti  e  solo  gli 
output che sono generati dalla stessa fase”. 
I manufatti intermedi, che fanno da input ed output tra due sotto‐attività hanno 
ragione  di  esistere  soltanto  a  questo  livello  di  dettaglio.  L’esistenza  di  questi 
manufatti è uno dei dettagli che viene elicitato quando si diminuisce il livello di 
generalità  di  un  modello  di  processo.  Il  manufatto  Report_dei_casi_di_test  non  è 
menzionato nel diagramma più generale poiché esso è prodotto ed utilizzato da 
sotto‐attività (è un manufatto interno). 
1.1 Piano dei casi di test  
public «Activity» Activity:  Attività di pianificazione dei casi di test. L'attività deve 
essere eseguita da operatori che abbiano competenze di pianificazione.  
1.2 Esecuzione dei casi di test  
public  «Activity»  Activity:    Attività  di  esecuzione  dei  piani  di  test  prodotti  dalla 
fase  di  pianificazione.  L'attività  deve  essere  eseguita  da  operatori  che  abbiano 
competenze nella esecuzione di un piano di test.  
1.3 Debugging  
public  «Activity»  Activity:    Attività  di  debugging.  Una  volta  ottenuto  il  report  di 
esecuzione  dei  casi  di  test,  i  debugger  intervengono  nel  codice  sorgente  per 
privarlo dei vizi precedentemente riscontrati.  
  22 
1.3 Step 3 
Lo Step 3 rappresenta una estensione dello Step 2. A partire da quest’ultimo, la 
traccia si arricchisce di nuovi dettagli i quali devono trovare una corrispondenza 
all’interno del disegno del modello di processo. 
Tra i “Vincoli e Specifiche” gli ultimi due punti esprimono delle caratteristiche di 
alcune  attività  che  ancora  non  esistono.  Ancora  una  volta,  nasce  l’esigenza  di 
dettagliare ulteriormente un’attività. 
In  particolare,  il  quarto  punto  indica  che  una  determinata  tecnica,  se  usata, 
migliora  sensibilmente  la  sotto‐attività  di  Pianificazione  dei  test  di  unità.  Il 
massimo  livello  di  dettaglio  raggiunto  nello  step  precedente  arrivava  fino  alla 
definizione di una generica attività di pianificazione (e non specificatamente per 
il  test  di  unità).  Per  questo  motivo,  per  rappresentare  anche  questo  vincolo, 
dobbiamo  dettagliare  meglio  l’attività  di  Piano  dei  casi  di  test  che  per  le  nuove 
specifiche rimarrebbe troppo generica. 
  23 
Il quinto, ed ultimo, punto introduce una nuova sotto‐attività: Pianificazione del 
test  di  Integrazione.  Di  questa  nuova  sotto‐attività,  la  traccia  ci  fornisce  una 
informazione:  la  scadenza  (espressa  come  data).  Anche  in  questo  caso,  è 
necessario dettagliare ulteriormente. 
Si  noti  che  in  nessun  caso  visto  finora,  la  traccia  illustra  come  dettagliare.  La 
conoscenza profonda dei processi del contesto in esame è prerogativa unica del 
modellatore  del  processo.  In  altre  parole,  il  modellatore  deve  conoscere  i 
processi per ogni livello di granularità necessario. 
In  un  caso  di  studio  come  questo,  ho  attinto  la  conoscenza  necessaria  dagli 
insegnamenti  di  corsi  universitari  frequentati  in  precedenza:  Ingegneria  del 
software e Modelli per la qualità del software. Qualora il modello di processo vada 
disegnato per esigenze aziendali concrete (e non didattiche come in questo caso) 
allora  è  opportuno  che  il  modellatore  ricavi  la  conoscenza  direttamente  in 
azienda.  Tipicamente,  per  contesti    di  grandi  dimensioni  e  quindi  complessi, 
l’incaricato  al  disegno  dei  modelli  di  processo  lavora  all’interno  dell’azienda‐
cliente con l’obiettivo di elicitare il flusso di lavoro (la maggior parte del quale è 
quasi sempre tacito). 
Attori  
Sviluppatore  
  24 
 
Sviluppatore Debugger  
• Competenze = Tecniche e tool nel debugging.    
test.  
• Competenze = Tecniche e tool nell'esecuzione.    
Sviluppatore Pianificatore  
Tagged Values 
  25 
• Competenze = Tecniche e tool nella pianificazione. 
Manufatti  
righe di codice che componongono il sistema software.  
differenti  casi  di  test  da  eseguire.  Piano_dei_casi_di_test  = 
Piano_dei_casi_di_test_d'integrazione + Piano_dei_casi_di_test_d'unità 
  26 
 
Figura 9: STEP 3 ‐ Manufatti “Piano_dei_casi_di_test” 
Per  necessità  nel  disegno  del  modello  di  processo  (attività  1.1  Piano  dei  casi  di 
test)  è  stato  ulteriormente  dettagliato  anche  il  manufatto  uscente: 
Piano_dei_casi_di_test.  Il  manufatto  è  composto  di  due  sotto‐manufatti: 
Piano_dei_casi_di_test_d’unità e Piano_dei_casi_di_test_d’integrazione. 
La  consistenza  globale  dei  manufatti  è  verificata  poiché  non  vi  sono  strutture 
ricorrenti nella definizione di questo manufatto.  
 
Figura 10: Esempio di errore di consistenza globale dei manufatti 
  27 
Questa  definizione  di  consistenza  garantisce  che  lo  stesso  manufatto  non  sia 
presente in più livelli dell’albero di composizione del manufatto, impedendo, de 
facto, la definizione di manufatti a composizione ricorsiva (divergente).  
Piano_dei_casi_di_test_d'integrazione  
public  «Document»  Class:    Sottomanufatto  che  è  parte  del  Piano  dei  casi  di  test 
(completo).  In  particolare,  questo  manufatto  si  riferisce  esclusivamente  ai  casi  di 
test di integrazione. 
Questo manufatto è una delle due componenti di Piano_dei_casi_di_test. 
Piano_dei_casi_di_test_d'unità  
test di unità.  
Questo manufatto è una delle due componenti di Piano_dei_casi_di_test. 
Report_dei_casi_di_test  
Report_di_debugging  
Specifiche_delle_classi  
  28 
1.Test e Debugging  
  29 
 
Figura 12: STEP 3 ‐ Piano, Esecuzione e Debugging dei casi di test 
  30 
public  «WorkDefinition»  Activity:    Attività  di  pianificazione  dei  casi  di  test. 
L'attività  deve  essere  eseguita  da  operatori  che  abbiano  competenze  di 
pianificazione. 
Lo  stereotipo  WorkDefinition  esprime  il  concetto  di  Fase.  Una  fase  è  utilizzata 
per  descrivere  parti  complesse  di  lavoro  ulteriormente  dettagliabili.  Se 
immaginassimo un albero n‐ario avente come radice il processo monolitico (Step 
1) e come figli tutte le attività che lo dettagliano fino a quelle elementari, allora 
tutti  i  nodi  intermedi  sono  fasi  e  tutte  le  foglie  (frontiera)  sono  attività 
elementari. L’albero così costruito prende il nome di Work Flow System. 
 
Figura 13: Concettualizzazione di un Work Flow System 
La fase 1.1 Piano_dei_casi_di_test, nello step precedente, era contrassegnata dallo 
stereotipo  Activity  giacché  nel  precedente  contesto  era  un’attività  elementare 
(cioè non ulteriormente dettagliata). La stessa considerazione vale per l’attività 
Test e Debugging nel passaggio da Step 1 a Step 2. 
  31 
 
Figura 14: STEP 3 ‐ Pianificazione test di unità e test d’integrazione 
L’attività  1.1  Piano  dei  casi  di  test  è  stata  dettagliata  in  due  sotto‐attività:  1.1.1 
Test di unità e 1.1.2 Test di integrazione. Tutti i manufatti che entrano nell’attività 
padre  (1.1  Piano  dei  casi  di  test)  entrano,  globalmente  ed  opportunamente  (a 
seconda  del  reale  dominio  applicativo),  nelle  due  nuove  sotto‐attività.  Per 
quanto  concerne  i  manufatti  uscenti,  in  questo  caso,  invece  di  produrre 
globalmente  un  unico  manufatto,  se  ne  producono  due: 
Piano_dei_casi_di_test_d’unità e Piano_dei_casi_di_test_d’integrazione. 
Apparentemente  questo  può  sembrare  un  errore  di  Consistenza  Strutturale,  in 
realtà  non  lo  è  poiché  il  manufatto  Piano_dei_casi_di_test  è  ora  stato  definito 
come  composizione  dei  due  sopra  citati.  Grazie  a  questa  dichiarazione  di 
composizione, il diagramma non viola le regole di Consistenza Strutturale. 
  32 
1.1.1 Test di unità  
public  «Activity»  Activity:    Test  di  unità:  deve  verificare  la  correttezza  di 
frammenti di codice sorgente. Ha il livello di granularità più basso di tutti gli altri 
tipi.  
• Tecnica = CROSS REFERENCE CLASS VS CLASS. 
 
Alla  nuova  sotto‐attività  abbiamo  aggiunto  un  Tagged  Value  che  ha  come 
etichetta  “Tecnica”  e  come  valore  “CROSS  REFERENCE  CLASS  VS  CLASS”.  In 
accordo con quanto previsto dalla traccia. 
L’inserimento  del  Tagged  Value  stabilisce  un  vincolo  che  per  definizione 
diminuisce  i  gradi  di  libertà  del  modello.  L’attività  in  esame  è  stata  vincolata 
poiché è la traccia stessa a garantire un miglioramento in efficacia ed efficienza 
nel caso di adozione di tale tecnica. 
Quando  presenti,  gli  accorgimenti  migliorativi  (che  migliorano  il  processo) 

andrebbero  sempre  vincolati.  Nello  step  successivo  si  affronterà  un  esempio  di 
accorgimento  non  migliorativo  proposto  direttamente  dalla  traccia  ma  non 
introdotto nella rappresentazione del modello di processo. 
1.1.2 Test di integrazione 
public  «Activity»  Activity:    Test  di  integrazione:  deve  verificare  la  corretta 
integrazione  tra  i  vari  moduli/componenti  di  un  sistema.  Ha  un  livello  di 
granularità  più  grande  rispetto  a  quello  di  unità,  più  basso  rispetto  a  quello  di 
sistema.  
• Scadenza = 31/dic/2008.    
1.2 Esecuzione dei casi di test 
  33 
privarlo dei vizi riscontrati in precedenza.  
1.4 Step 4 
In questo step, la traccia introduce altri vincoli e specifiche: due nuovi tool che 
influiscono sull’efficienza di alcune attività elementari (Definizione della matrice 
di  cross,  Definizione  delle  classi  di  equivalenza  e  Definizione  dei  cammini 
indipendenti) non ancora introdotte dallo step precedente. 
E’ necessario, quindi, dettagliare ulteriormente l’attività di Pianificazione del test 
d’unità.  A  differenza  degli  step  precedenti,  le  sotto‐attività  che  andremo  ad 
introdurre  non  saranno  delle  attività  a  loro  volta  ulteriormente  dettagliabili, 
bensì delle attività elementari. 
  34 
La  traccia,  in  generale,  non  dice  esplicitamente  che  le  nuove  attività  non 
potranno essere ulteriormente dettagliate. La scelta ricade sul progettista: è lui a 
decidere quando bloccare il livello di dettaglio di una determinata attività. 
Lo scopo della traccia è anche quello di chiarire quando è opportuno indicare dei 
vincoli nel modello di processo e quando no. Nella traccia si citano i nomi di due 
tool;  uno  di  questi  supporta  ma  non  migliora  le  prestazioni  di  un’attività 
elementare.  In  questo  caso  non  è  opportuno  vincolare  l’attività  elementare 
all’utilizzo dello specifico tool poiché l’uso di quest’ultimo non è conveniente ma 
soltanto  possibile.  Il  tool  rappresenta  solo  uno  (supportato  e  non  migliorativo) 
tra tutti quelli possibili. 
Attori  
Sviluppatore  
  35 
• Competenze = Tecniche e tool per il debugging.    
test.  
• Competenze = Tecniche e tool per l'esecuzione.    
Manufatti  
Manufatti::Cammini_indipendenti 
public  «Document»  Class:  Il  manufatto  contiene  tutti  i  cammini  indipendenti 
individuati (manualmente o via software) all'interno del codice di un'applicazione 
da testare.  
Manufatti::Classi_di_equivalenza 
public  «Document»  Class:  Il  manufatto  contiene  l'elenco  di  tutte  le  le  classi  di 
equivalenza  individuate  rispetto  ad  una  determinata  funzionalità  software  da 
testare. 
Manufatti::Lista_delle_classi 
public «Document» Class: Il documento contiene l'elenco completo delle classi da 
testare. 
  36 
Manufatti::Matrice_di_cross 
public  «WorkProduct»  Class:  Il  manufatto  contiene  la  matrice  di  cross  definita 
come  struttura  di  dati  matriciale  necessaria  al  fine  di  verificare  l'impatto  che 
talune modifiche al codice hanno su altre porzioni di codice. 
Manufatti::Codice_Eseguibile  
public  «WorkProduct»  Class:    Questo  manufatto  rappresenta  il  codice 
direttamente eseguibile (compilato).  
  37 
Piano_dei_casi_di_test_d'integrazione + Piano_dei_casi_di_test_d'unità  
Figura 17: STEP 4 ‐ Manufatti "Piano_dei_casi_di_test" 
Piano_dei_casi_di_test_black_box  
public  «Document»  Class:    Il  manufatto  contiene  tutti  i  casi  di  test  da  effettuare 
con la tecnica della Black Box.  
test di integrazione.  
test  di  unità.  Piano_dei_casi_di_test_d'unità  =  Piano_dei_casi_di_test_white_box  + 
  38 
 
Figura 18: STEP 4 ‐ Manufatti "Piano_dei_casi_di_test_di_unità" 
Piano_dei_casi_di_test_white_box  
con la tecnica della White Box.  
  39 
public «WorkDefinition» Activity:    
  40 
 
  41 
L'attività  deve  essere  eseguita  da  operatori  che  abbiamo  competenze  di 
pianificazione.  
Figura 21: STEP 4 ‐ Pianificazione test di unità e di integrazione 
frammenti di codice sorgente. 
Constraints  
• Approved Precondition . ISC.  
  42 
Modello delle Classi disponibile AND Specifica delle Classi 
disponibile AND Diagramma dei Casi d'Uso disponibile AND 
Descrizione dei Casi d'Uso disponibile AND Codice Sorgente 
disponibile   
• Approved Postcondition . IEC.  
Piano dei Casi di Test di Unità 
 
Nell’attività  1.1.1  Test  di  unità  sono  stati  inseriti  dei  vincoli  che  consistono  in 
Pre‐condizioni e Post‐condizioni.  In  entrambi  i  casi  si  tratta  di  condizioni  che 
devono essere vere per garantire la corretta esecuzione dell’attività (nel primo 
caso)  e  la  corretta  terminazione  dell’attività  (nel  secondo  caso).  Nel  linguaggio 
FSPSPEM le condizioni sono definite mediante l’utilizzo di espressioni booleane. 
In questo caso, l’attività 1.1.1 Test d’unità ha bisogno della disponibilità di cinque 
manufatti  in  input  per  poter  essere  eseguita.  Circa  la  sua  terminazione,  ha 
bisogno che vi sia un solo manufatto in output per considerarsi terminata. 
1.1.1 Test di unità Embedded Elements  
ELEMENT  TIPO  ANNOTAZIONI 
Creazione casi di test Black Box   State     
Creazione classi di equivalenza   State     
Creazione dei cammini indipendenti   State     
Creazione dei casi di test White Box   State     
Creazione della lista delle classi  State   
Creazione della matrice di cross   State     
 
La  tabella  mostra  l’insieme  delle  attività  base  che  compongono  l’attività 
elementare  1.1.1  Test  di  unità.  Un’attività  base  è  definita  come  un’attività  che 
trasforma semplicemente un manufatto in input in uno di output. 
• Tecnica = CROSS REFERENCE CLASS VS CLASS.    
 
  43 
 
Figura 22: STEP 4 ‐ Pianificazione test d'unità 
Il  diagramma  di  cui  sopra  rappresenta  il  flusso  delle  attività  base  che 
compongono la pianificazione dei Test di unità. Un insieme di tali attività viene 
  44 
opportunamente  relazionato  attraverso  operatori  di  controllo  di  flusso  di  tipo: 
sequenziale, condizionale ed iterativo (tutti e tre presenti nel diagramma). 
Creazione casi di test Black Box  
public  «Step»  State:    Procedura  di  creazione  dei  casi  di  test  con  la  tecnica  Black 
Box. 
Scenarios  
PRODURRE Piano_casi_di_test_black_box USANDO

Classi_di_equivalenza {Alternate}.
Uno scenario descrive la modalità grazie alla quale viene prodotto un manufatto 
di  output  a  partire  da  quelli  in  input.  Le  attività  base  essendo  estremamente 
elementari  (come  detto  prima)  si  limitano  ad  operazioni  di 
trasformazione/manipolazione  di  manufatti  e  possono  essere  descritte  usando 
la  seguente  sintassi:  <verbo>  (<manufatto  output>)+  USANDO  (<manufatti 
output>)+. (ove + sta per “uno o più di uno”) 
In  questo  caso  l’attività  base,  utilizzando  il  manufatto  Classi_di_equivalenza 

produce il Piano_casi_di_test_black_box.  
Creazione classi di equivalenza  
public «Step» State: Procedura di rilevazione delle classi di equivalenza.  
Scenarios  
PRODURRE Classi_di_equivalenza USANDO

Specifiche_delle_classi {Alternate}.
Si  noti  che  non  è  stato  inserito  alcun  Tagged  Value  circa  il  tool  KUnit.  Questo 
perché esso non migliorava l’attività ma si limitava supportarla. 
Creazione dei cammini indipendenti  
public «Step» State: Procedura di rilevazione dei cammini indipendenti. 
Scenarios  
PRODURRE Cammini_indipendenti USANDO Codice_sorgente

{Alternate}.
  45 
• Tool = KUnit.    
Creazione dei casi di test White Box  
public  «Step»  State:  Procedura  di  creazione  dei  casi  di  test  con  la  tecnica  White 
Box. 
Scenarios  
PRODURRE Casi_di_test_white_box USANDO

(Cammini_indipendenti, Specifiche_delle_classi)
{Alternate}.
Creazione della lista delle classi  
public  «Step»  State:  Procedura  di  creazione  della  lista  delle  classi  coinvolte  nel 
test. 
Scenarios  
PRODURRE Lista_delle_classi USANDO Matrice_di_cross

{Alternate}.
La teoria prevede che partendo dalla matrice di cross si crei una lista di classi in 
cui per ogni classe è indicato se si effettua un test white box o black box. 
Creazione della matrice di cross  
public «Step» State: Procedura di creazione della matrice di cross. 
Scenarios  
PRODURRE Matrice_di_cross USANDO Modello_delle_Classi

{Alternate}.
• Tool = MatrixJ. 
 
La tecnica CROSS REFERENCE CLASS VS CLASS prevede che partendo dal modello 
delle classi si crei la matrice di cross. 
  46 
1.1.2 Test di integrazione  
sistema.  
• Scadenza = 31/dic/2008.    
privarlo dei vizi riscontrati in precedenza. 
  47 
1.5 Step 5 
Figura 23: STEP 5 – Traccia 
Lo step in esame, pur discendendo direttamente da quello precedente (come per 
tutti  gli  altri  risolti  finora)  non  nasce  da  una  traccia  scritta,  ma  dall’esigenza  di 
approfondimento sorta in seguito alla realizzazione del modello GQM. (vedi pag. 
65) 
Nella realizzazione del suddetto modello è sorta l’esigenza di valutare le attività 
di  Esecuzione  casi  di  test  di  unità  ed  Esecuzione  casi  di  test  di  integrazione,  che 
non  sono  ancora  presenti  nella  rappresentazione  del  modello  di  processo. 
Abbiamo  perciò  bisogno  di  dettagliare  ulteriormente  l’attività  elementare 
Esecuzione casi di test. 
Come  avrò  modo  di  ribadire  più  avanti,  questo  è  un  caso  nel  quale  il  livello  di 
dettaglio di un modello di processo viene condizionato dalle misure necessarie a 
valutarlo. Dopo aver realizzato il GQM ci siamo resi conto del fatto che il modello 
di processo disegnato non fosse opportunamente dettagliato e lo abbiamo esteso 
ulteriormente.  Nella  pratica,  chi  disegna  un  modello  di  processo,  nella  maggior 
parte  dei  casi,  conosce  bene  lo  studio  di  valutazione  e  miglioramento  che  si 
  48 
intende  portare  avanti  e  per  questo  motivo  è  raro  che  si  verifichino  ritorni 
all’indietro. 
La modifica del modello di processo viene operata, al più, come risultato ultimo 
dell’attività  di  miglioramento  del  modello  di  processo  ma  quasi  mai  in  seguito 
alla  realizzazione  di  un  GQM.  Tuttavia,  l’evento  non  è  impossibile  (come  in 
questo caso). 
Attori 
Sviluppatore 
  49 
• Competenze = Tecniche e tool per il debugging.    
test.  
• Competenze = Tecniche e tool per l'esecuzione.    
Manufatti 
Manufatti::Cammini_indipendenti 
public  «Document»  Class:  Il  manufatto  contiene  tutti  i  cammini  indipendenti 
individuati (manualmente o via software) all'interno del codice di un'applicazione 
da testare.  
Manufatti::Classi_di_equivalenza 
public  «Document»  Class:  Il  manufatto  contiene  l'elenco  di  tutte  le  le  classi  di 
equivalenza  individuate  rispetto  ad  una  determinata  funzionalità  software  da 
testare. 
Manufatti::Lista_delle_classi 
public «Document» Class: Il documento contiene l'elenco completo delle classi da 
testare. 
Manufatti::Matrice_di_cross 
public  «WorkProduct»  Class:  Il  manufatto  contiene  la  matrice  di  cross  definita 
come  struttura  di  dati  matriciale  necessaria  al  fine  di  verificare  l'impatto  che 
talune modifiche al codice hanno su altre porzioni di codice. 
  50 
sulla sequenza temporale dei messaggi che si scambiano. Il dettaglio deve segueire 
Piano_dei_casi_di_test_d'integrazione + Piano_dei_casi_di_test_d'unità  
  51 
 
Figura 25: STEP 5 ‐ Manufatti "Piano_dei_casi_di_test" 
con la tecnica della black box.  
test di integrazione.  
test  di  unità.  Piano_dei_casi_di_test_d'unità  =  Piano_dei_casi_di_test_white_box  + 
  52 
 
Figura 26: STEP 5 – Manufatti “Piano_dei_casi_di_test_d'unità” 
Piano_dei_casi_di_test_white_box  
con la tecnica della White Box.  
Report_Casi_di_Test_di_Integrazione  
(sotto  forma  tabellare  per  esempio)  dell'esecuzione  di  tutti  i  casi  di  test  di 
integrazione.  
Questo manufatto è una delle due componenti di Report_dei_casi_di_test. 
Report_Casi_di_Test_di_Unità  
(sotto forma tabellare per esempio) dell'esecuzione di tutti i casi di test di unità.  
Questo manufatto è una delle due componenti di Report_dei_casi_di_test. 
(sotto  forma  tabellare  per  esempio)  dell'esecuzione  di  tutti  i  casi  di  test. 
  53 
Report_dei_casi_di_test  =  Report_casi_di_test_di_unità  + 
Report_casi_di_test_di_integrazione 
Figura 27: STEP 5 ‐ ManufattI "Report_dei_casi_di_test" 
Il  manufatto  Report_dei_casi_di_test  è  stato  dettagliato.  Esso  è  prodotto  dalla 

composizione  di  due  manufatti:  Report_casi_di_test_di_integrazione  e 
Report_casi_di_test_di_unità. 
La  decomposizione  è  necessaria  al  fine  di  poter  rappresentare  in  maniera  più 
dettagliata l’attività di Esecuzione_dei_casi_di_test.  
(in forma tabellare) dell’esecuzione del debug.  
  54 
Stub_Test_di_Integrazione  
public «WorkProduct» Class:  Questo manufatto deve contenere il codice sorgente 
del modulo fittizio utilizzato per la classe sottoposta al test di Integrazione. 
Abbiamo  inserito  il  manufatto  Stub_Test_di_Integrazione  necessario  alla 

rappresentazione più dettagliata dell’attività di Esecuzione casi di test. 
Stub_Test_di_Unità  
public «WorkProduct» Class:  Questo manufatto deve contenere il codice sorgente 
del modulo fittizio utilizzato per la classe sottoposta al test di Unità. 
Abbiamo  inserito  il  manufatto  Stub_Test_di_Integrazione  necessario  alla 

rappresentazione più dettagliata dell’attività di Esecuzione casi di test. 
  55 
  56 
 
  57 
E’  importante  notare  che  avendo  dettagliato  ulteriormente  l’attività  di 
esecuzione  dei  casi  di  test,  questa  ha  cambiato  il  suo  stereotipo  da  Activity  in 
WorkDefinition. 
L'attività  deve  essere  eseguita  da  operatori  che  abbiamo  competenze  di 
pianificazione.  
Figura 30: STEP 5 ‐ Pianificazione test di unità e d’integrazione 
  58 
frammenti di codice sorgente. Ha il livello di granularità più bassa di tutti gli altri 
tipi.  
Constraints  
• Approved Invariant . ISC.  
Modello delle Classi disponibile AND Specifica delle Classi 
disponibile AND Diagramma dei Casi d'Uso disponibile AND 
Descrizione dei Casi d'Uso disponibile AND Codice Sorgente 
disponibile   
• Approved Invariant . IEC.  
Piano dei Casi di Test di Unità   
1.1.1 Test di unità Embedded Elements  
ELEMENT  TIPO  ANNOTAZIONI 
 Creazione casi di test black box   State     
 Creazione classi di equivalenza   State     
 Creazione dei cammini indipendenti   State     
 Creazione dei casi di test White Box   State     
 Creazione della lista delle classi   State     
 Creazione della matrice di Cross   State     
 
• Tecnica = CROSS REFERENCE CLASS VS CLASS.    
 
  59 
 
Figura 31: STEP 5 ‐ Pianificazione test di unità 
  60 
Creazione casi di test Black Box  
public  «Step»  State:    Procedura  di  creazione  dei  casi  di  test  con  la  tecnica  Black 
Box. 
Scenarios  
PRODURRE Piano_casi_di_test_black_box USANDO

Classi_di_equivalenza {Alternate}.
Creazione classi di equivalenza  
public «Step» State: Procedura di rilevazione delle classi di equivalenza.  
Scenarios  
PRODURRE Classi_di_equivalenza USANDO

Specifiche_delle_classi {Alternate}.
Creazione dei cammini indipendenti  
public «Step» State: Procedura di rilevazione dei cammini indipendenti. 
Scenarios  
PRODURRE Cammini_indipendenti USANDO Codice_sorgente

{Alternate}.
• Tool = KUnit.    
Creazione dei casi di test White Box  
public  «Step»  State:  Procedura  di  creazione  dei  casi  di  test  con  la  tecnica  White 
Box. 
Scenarios  
PRODURRE Casi_di_test_white_box USANDO

(Cammini_indipendenti, Specifiche_delle_classi)
{Alternate}.
Creazione della lista delle classi  
public  «Step»  State:  Procedura  di  creazione  della  lista  delle  classi  coinvolte  nel 
test. 
Scenarios  
  61 
PRODURRE Lista_delle_classi USANDO Matrice_di_cross
{Alternate}.
Creazione della matrice di cross  
public «Step» State: Procedura di creazione della matrice di cross. 
Scenarios  
PRODURRE Matrice_di_cross USANDO Modello_delle_Classi

{Alternate}.
• Tool = MatrixJ. 
1.1.2 Test di integrazione  
sistema.  
• Scadenza = 31/dic/2008.    
public «WorkDefinition» Activity:  Attività di esecuzione dei piani di test prodotti 
dalla fase di pianificazione. L'attività deve essere eseguita da operatori che abbiano 
L’attività  Esecuzione  dei  casi  di  test  perde  il  suo  stereotipo  Activity  in  favore  di 
WorkDefinition poiché la stiamo ulteriormente dettagliando. 
  62 
 
Figura 32: STEP 5 ‐ Esecuzione dei casi di test 
Il diagramma mostra il flusso di lavoro del processo di Esecuzione dei casi di test. 
Utilizzando  i  piani  dei  casi  di  test  e  le  specifiche  delle  classi  viene  avviata 
l’attività di Creazione degli stub. Questa attività produce gli stub sia per i test di 
  63 
integrazione  che  per  quelli  di  unità.  Questi  vengono  utilizzati  dalle  rispettive 
attività  di  esecuzione  unitamente  al  codice  sorgente,  per  produrre  i  rispettivi 
report. 
Notiamo  che  non  è  stato  inserito  alcun  manufatto  genitore  dei  due  tipi  di  stub 
(Stub_test).  Ciò  è  dovuto  al  fatto  che  l’attività  Creazione_degli_stub  è 
completamente  invisibile  all’esterno  del  modello  dettagliato.  Di  conseguenza  i 
manufatti prodotti vengono internamente utilizzati (ne beneficiano solo attività 
presenti allo stesso livello di dettaglio) senza che ve ne sia traccia all’esterno. 
In questo caso non c’è la necessità di inserire il manufatto genitore, se non per 
completezza. In generale, nel disegno di un modello di processo, si rappresenta 
lo “strettamente indispensabile”. 
1.2.1 Creazione degli stub  
public «Activity» Activity:  Procedura di creazione degli stub. 
1.2.2 Esecuzione Test di Unità 
public «Activity» Activity:   In questa attività, l’attore responsabile esegue il test di 
unità. 
1.2.3 Esecuzione Test di Integrazione  
public «Activity» Activity:   In questa attività, l’attore responsabile esegue il test di 
integrazione. 
privarlo dei vizi riscontrati in precedenza. 
  64 
Capitolo 2: 
GQM per la valutazione un processo 
di test 
“You cannot control what you cannot measure”

Tom DeMarco
 
Nel  capitolo  precedente  si  è  affrontata  la  problematica  relativa  alla 

rappresentazione  di  un  modello  di  processo,  intesa  come  abilità  di  disegnare 
formalmente (correttamente, precisamente) un processo aziendale composto da 
differenti  attività  dettaglianti,  con  diversi  gradi  di  libertà  (a  seconda  delle 
necessità). 
La  fase  di  disegno  è  soltanto  la  prima  parte  di  uno  studio  più  complesso  sui 
modelli di processo. L’obiettivo finale è la realizzazione di un ambiente formale 
che  rappresenti  i  processi  di  un’organizzazione  e  che  possa  essere  utilizzato  al 
fine di migliorare i processi rappresentati. Detto in soldoni, lo studio dei modelli 
di processo trova la sua massima utilità nell’area del decisionmaking aziendale. 
Dopo  aver  disegnato  i  processi,  nasce  la  necessità  di  valutarli.  In  letteratura 
esistono  differenti  metodologie  operative  per  la  valutazione  di  processi  in 
termini  di  qualità.  In  questo  caso  quando  si  parla  di  qualità  ci  si  riferisce  alla 
“caratteristica  desiderata”  per  un  prodotto,  processo  o  risorsa  che  soddisfi  il 
committente e realizzi il ritorno economico. 
Quella  che  si  presenta  in  questa  sede  è  la  metodologia  Goal  Question  Metric. 
L’approccio GQM è basato sull’assunzione che un’organizzazione, per valutare in 
  65 
maniera significativa deve: specificare gli obiettivi aziendali e quelli di progetto; 
tracciare questi obiettivi con i dati che li definiscono in termini operativi; fornire 
un ambiente per l’interpretazione dei dati concordemente agli obiettivi fissati. 
Il  risultato  dell’applicazione  di  questo  paradigma  è  la  specifica  di  modelli  di 
misurazione  mirati  e  un  insieme  di  regole  per  l’interpretazione  delle  misure.  Il 
modello  che  ne  deriva  è  articolato  su  tre  livelli:  concettuale  (Goal),  operativo 
(Question), quantitativo (Metric). 
 
Figura 33: Struttura gerarchica del modello GQM 
Goal 
Un Goal è definito su un preciso oggetto, con differenti punti di vista, in merito a 
diversi  obiettivi  di  qualità,  relativamente  ad  un  particolare  contesto.  Esso 
identifica  ciò  che  vogliamo  conseguire  relativamente  ad  un  prodotto,  un 
processo o una risorsa.  
Di seguito si riportano i goal. 
GOAL 1 
Analizzare  il processo Pianificazione dei casi di Test di Unità 
  66 
Allo scopo  di valutarlo 
Rispetto  all’efficienza 
Dal punto di vista  dello sviluppatore 
Nel contesto  del Processo di Testing 
GOAL 2 
Analizzare  il processo Pianificazione dei casi di Test di Integrazione 
 
GOAL 3 
Analizzare  il processo Esecuzione dei casi di Test di Unità 
 
GOAL 4 
Analizzare  il processo Esecuzione dei casi di Test di Integrazione 
 
In questa esercitazione abbiamo deciso di porci quattro obiettivi; tutti focalizzati 
alla  valutazione  dell’efficienza  del  processo  in  esame  nell’ottica  dello 
  67 
sviluppatore.  Come  è  facile  notare,  la  discriminante  per  ogni  obiettivo  è  il 
processo  analizzato:  Pianificazione  test  di  unità,  Pianificazione  test 
d’integrazione, Esecuzione test di unità ed Esecuzione test di integrazione. 
Come detto in precedenza, il modello GQM, essendo estremamente flessibile, si 
può applicare a prodotti o a risorse.  Per l’esercitazione si è deciso di concentrare 
l’attenzione  solo  sui  fattori  che  ci  avrebbero  consentito  di  effettuare  una 
valutazione sui processi disegnati e conseguentemente un miglioramento. 
Question 
Un insieme di Question è utilizzato per caratterizzare il criterio operativo con cui 
un  Goal  si  dice  raggiunto.  Esse  ci  aiutano  a  capire  come  soddisfare  un  preciso 
Goal ed indirizzano il contesto del problema di qualità da un particolare punto di 
vista. 
Di seguito si riportano le question relative ad ogni goal: 
GOAL 1 
Conformità dell’uso del processo 
Caratterizzazione del processo 
Q1.1  Quali  sono  le  tecniche  di  testing  utilizzate  nel  processo  di 
pianificazione dei test d’unità? 
Q1.2 Quali sono i tool utilizzati nel processo di pianificazione dei test 
d’unità? 
Conformità ai requisiti del processo 
Q1.3 Qual è l’esperienza del team nell’esecuzione del processo? 
Q1.4 Qual è la conoscenza del team delle tecniche per la pianificazione 
dei test d’unità? 
Q1.5  Qual  è  la  conoscenza  dei  tool  per  la  pianificazione  dei  test 
d’unità? 
Q1.6 Qual è la conoscenza del team del dominio applicativo? 
Modello Primario 
Qualità 
interes
se 
di 
Q1.7  Qual  è lo  sforzo  richiesto per la pianificazione  dei  casi  di  test  di 
unità? 
Q1.8 Qual è in percentuale lo sforzo richiesto per la pianificazione dei 
casi  di  test  di  unità  rispetto  a  quello  necessario  per  tutta  la  fase  di 
  68 
  pianificazione? 
Q1.9 In che quantità si sono pianificati i casi di test di unità? 
Modello di Conferma 
Q1.10  In  che  quantità  si  sono  pianificati  i  casi  di  test  di  unità  in 
progetti simili? 
Q1.11  Qual  è  secondo  lo  storico  di  dati  disponibili  lo  sforzo  richiesto 
per la pianificazione dei test di unità? 
Modello di Validità 
Q1.12 Secondo la letteratura quanto deve pesare la pianificazione del 
test di unità sul processo di pianificazione? 
 
Come si vede nelle tabelle, le Question non sono tutte uguali. Esse vengono divise 
in due macro categorie per ognuna delle quali vi è ancora una divisione interna. 
Le  due  grandi  categorie  sono:  Caratterizzazione  del  processo  e  Qualità  di 
interesse. 
Nel  primo  insieme  si  trovano  tutte  quelle  domande  che  hanno  l’obiettivo  di 
fotografare la situazione reale dell’organizzazione intesa come insieme di fattori 
sui quali può agire il management dell’organizzazione. In Conformità all’uso del 
processo  troviamo  informazioni  riguardanti  l’aderenza  del  processo  reale  a 
quello  ufficiale  in  termini  di  fattori  pregnanti:  il  personale,  gli  strumenti,  i 
metodi,  i  piani,  la  logistica  etc…  (Es.  Quali  sono  le  macchine  utilizzate  per  la 
produzione  della  tomaia?).  In  Conformità  ai  requisiti  del  processo,  invece,  le 
domande  si  riferiscono  agli  attributi  degli  oggetti  reali  presi  in  esame  nella 
categoria  precedente  (Es.  Qual  è  l’esperienza  dei  dipendenti  nell’utilizzo  delle 
macchine?). 
Nel secondo insieme si trovano tutte quelle domande che hanno essenzialmente 
due obiettivi: focalizzare l’attenzione sui fattori che interessano i nostri obiettivi 
di  qualità  e  ottenere  dei  termini  di  paragone  utilizzando  dati  interni 
all’organizzazione  oppure  dati  esterni  (tipicamente  letteratura).  Nel  Modello 
primario  si  inseriscono  tutte  le  domande  che  si  riferiscono  quantitativamente 
alle  qualità  di  interesse  (Es.  Quante  tomaie  vengono  prodotte?).  Nel  Modello  di 
conferma sono presenti tutte le domande che consentono di confrontare i dati (al 
fine  di  stabilire  la  bontà  degli  stessi)  derivanti  dal  Modello  primario  con  i  dati 
reali  ricavati  internamente  all’organizzazione:  storici,  esperienza  pregressa, 
progetti  simili  (Es.  Quante  tomaie  sono  state  prodotte  mediamente  lo  scorso 
anno?).  Nel  Modello  di  validità  vi  sono  tutte  le  domande  che  servono  a 
  69 
confrontare  i  dati  del  Modello  primario  con  quelli  esterni  all’organizzazione: 
letteratura, progetti uguali in altre aziende simili. 
Non è detto che vi siano domande sia nel Modello di validità che nel Modello di 
conferma sebbene sia essenziale che per ogni domanda nel Modello primario vi 
sia  almeno  una  domanda  abbinata  nel  Modello  di  conferma  o  nel  Modello  di 
validità.  In  altre  parole,  una  delle  due  sezioni  potrebbe  essere  vuota.  In  questo 
caso il modello di qualità utilizzerebbe dati di raffronto sempre esterni (esogeni) 
o sempre interni (endogeni). 
Per  agevolare  la  lettura  è  opportuno  numerare  le  Question.  Qualora  una  di 
queste  fosse  la  stessa  di  una  già  formulata  per  Goal  precedenti  (con  le  stesse 
misure che ne discendono), allora essa mantiene la numerazione originale. 
GOAL 2 
Caratterizzazione del processo 
Q2.1  Quali  sono  le  tecniche  di  testing  utilizzate  nel  processo  di 
pianificazione dei test d’integrazione? 
Q2.2 Quali sono i tool utilizzati nel processo di pianificazione dei test 
d’integrazione? 
Q2.3 Qual è la conoscenza del team delle tecniche per la pianificazione 
dei test d’integrazione? 
Q2.4  Qual  è  la  conoscenza  dei  tool  per  la  pianificazione  dei  test 
d’integrazione? 
Q1.6 Qual è la conoscenza del team del dominio applicativo? 
Qualità di interesse 
Q2.5  Qual  è lo  sforzo  richiesto per la pianificazione  dei  casi  di  test  di 
integrazione? 
Q2.6 Qual è in percentuale lo sforzo richiesto per la pianificazione dei 
casi di test di integrazione rispetto a quello necessario per tutta la fase 
di pianificazione? 
Q2.7 In che quantità si sono pianificati i casi di test di integrazione? 
  70 
  Q2.8 In che quantità si sono pianificati i casi di test di integrazione in 
Q2.9 Qual è secondo lo storico di dati disponibili lo sforzo richiesto per 
la pianificazione dei test di integrazione? 
Q2.10 Secondo la letteratura quanto deve pesare la pianificazione del 
test di integrazione sul processo di pianificazione? 
 
La  Question  Q1.3  è  un  esempio  di  riutilizzo  di  question  precedenti.  Essa  viene 
riscritta nella sua formulazione ma mantiene la numerazione originale. 
GOAL 3 
Caratterizzazione del 
Q3.1  Quali  sono  i  tool  di  esecuzione  dei  test  d’unità  utilizzati  nel 
processo? 
processo 
Q3.2  Qual  è  la  conoscenza  dei  tool  per  l’esecuzione  dei  casi  di  test  di 
unità? 
Q3.3 Qual è la dimensione degli stub di unità? 
Q3.4  Qual  è  lo  sforzo  richiesto  per  la  esecuzione  dei  casi  di  test  di 
unità? 
Q3.5 Qual è in percentuale lo sforzo richiesto per la esecuzione dei casi 
di  test  di  unità  rispetto  a  quello  necessario  per  tutta  la  fase  di 
Qualità di interesse 
esecuzione? 
Q3.6  Qual  è  la  percentuale  dei  casi  di  test  di  unità  positivi  dopo  la 
prima esecuzione? 
Q3.7  In  che  percentuale  si  sono  eseguiti  i  casi  di  test  di  unità  in 
Q3.8 Qual è secondo lo storico di dati disponibili la percentuale di casi 
di test positivi per l’esecuzione dei test di unità? 
Q3.9 Secondo la letteratura quanto deve pesare l’esecuzione del test di 
  71 
  unità sul processo di esecuzione? 
 
GOAL 4 
Caratterizzazione del 
Q4.1 Quali sono i tool di esecuzione dei test d’integrazione utilizzati nel 
processo? 
processo 
Q4.2  Qual  è  la  conoscenza  dei  tool  per  l’esecuzione  dei  casi  di  test  di 
integrazione? 
Q4.3 Qual è la dimensione degli stub d’integrazione? 
Q4.4  Qual  è  lo  sforzo  richiesto  per  l’esecuzione  dei  casi  di  test  di 
integrazione? 
Q4.5 Qual è in percentuale lo sforzo richiesto per l’esecuzione dei casi 
di  test  di  integrazione  rispetto  a  quello  necessario  per  tutta  la  fase  di 
Qualità di Interesse 
esecuzione? 
Q4.6 Qual è la percentuale dei casi di test di integrazione positivi dopo 
la prima esecuzione? 
Q4.7 In che percentuale si sono eseguiti i casi di test di integrazione in 
Q4.8 Qual è secondo lo storico di dati disponibili la percentuale di casi 
di test positivi per l’esecuzione dei test d’integrazione? 
Q4.9 Secondo la letteratura quanto deve pesare l’esecuzione del test di 
integrazione sul processo di esecuzione? 
Metric 
Ad ogni Question viene associato un insieme di Metric che rispondano in maniera 
quantitativa.  Si  tratta  dei  dati  operativi  che  devono  essere  raccolti  per 
  72 
rispondere ai quesiti e rappresentano la base quantitativa con la quale opera il 
management. 
In  questa  fase  viene  proposta  solo  la  tabella  riepilogativa  che  mette  in  luce 
l’associazione tra Goal, Question e Metric. 
Di  seguito  si  riportano  le  associazioni  di  tutte  le  Metric  necessarie  a  ciascuna 
Question di ciascun Goal. 
GOAL 1 
Question  Metric  Etichetta  Descrizione 
Q1.1  M1.1.1  TecnTestU  Tecniche  di  testing  utilizzate  per  il 

processo pianificazione test di unità 
Q1.2  M1.2.1  ToolsUtilU  Tool  utilizzati  nel  processo  di 
pianificazione dei test di unità 
Q1.3  M1.3.1  ExpTest  Esperienza  relativa  al  testing  di  un 
individuo del team 
M1.3.2  %DistrExpTest  Distribuzione in percentuale dei valori 
soggettivi  di  esperienza  del  team 
nell’esecuzione del processo 
M1.3.3  %PersExpTest  Percentuale  di  persone  del  team 
esperte di testing 
Q1.4  M1.4.1  ConTecUtilU  Conoscenza  di  un  individuo  del  team 
circa  le  tecniche  di  pianificazione  dei 
test di unità utilizzate 
M1.4.2  %DistrConTecUtilU  Distribuzione in percentuale dei valori 
della  conoscenza  del  team  circa  le 
tecniche  di  pianificazione  dei  test  di 
unità utilizzate 
M1.4.3  %PersExpTecUtilU  Percentuale  di  persone  del  team 
esperte  delle  tecniche  di 
pianificazione  dei  test  di  unità 
utilizzate 
Q1.5  M1.5.1  ConToolsUtilU  Conoscenza  di  un  individuo  del  team 
circa  i  tool  per  la  pianificazione  dei 
test di unità utilizzati 
  73 
  M1.5.2  %DistrConToolsUtilU  Distribuzione in percentuale dei valori 
della  conoscenza  del  team  circa  i  tool 
per  la  pianificazione  dei  test  di  unità 
utilizzati 
M1.5.3  %PersExpToolsUtilU  Percentuale  di  persone  del  team 
esperte  dei  tool  per  la  pianificazione 
dei test di unità utilizzati 
Q1.6  M1.6.1  ConDomAppl  Conoscenza  di  un  individuo  del  team 
del dominio applicativo 
M1.6.2  %DistrConDomAppl  Distribuzione in percentuale dei valori 
della conoscenza del team del dominio 
applicativo 
M1.6.3  %PersExpDomAppl  Percentuale  di  persone  del  team 
esperte del dominio applicativo 
Q1.7  M1.7.1  TPianCTU  Ore/uomo  per  la  pianificazione  dei 
casi di test di unità 
M1.7.2  NumCTU  Numero  di  casi  di  test  di  unità 
pianificati 
M1.7.3  StTPianCTU  Numero  standardizzato  di  ore  uomo 
per pianificare un caso di test di unità 
test di unità 
M1.8.1  TPianCTI  Ore/uomo  per  la  pianificazione  dei 
test di integrazione 
M1.8.2  TPianCT  Ore/uomo  per  la  pianificazione  dei 
casi di test 
M1.8.3  %TPianCTU  Percentuale  di  tempo  dedicata  alla 
pianificazione dei test di unità 
Q1.9  M1.9.1  NumClas  Numero di classi del sistema 

pianificati 
M1.9.2  StNumCTU  Numero  standardizzato  di  casi  di  test 
di unità pianificati 
  74 
Q1.10  M1.10.1  QuaCTUA  Quantità  di  casi  di  test  di  unità 
prodotti per classe in altri processi 
Q1.11  M1.11.1  StTPianCTUA  Ore/uomo  standardizzate  per 
pianificare  un  caso  di  test  di  unità  in 
processi analoghi 
Q1.12  M1.12.1  %TPianCTULett  Peso che in percentuale deve avere lo 
sforzo per la pianificazione dei casi di 
test d’unità secondo la letteratura 
 
In  queste  tabelle  sono  riportate  soltanto  alcune  delle  informazioni  relative  ad 
una metrica: l’etichetta (un nome breve e significativo) e la descrizione testuale 
che ne chiarisce la semantica. 
Per  le  informazioni  complete  circa  le  metriche  qui  presentate,  si  deve  fare 
riferimento al Modello di calcolo, nel caso in cui la metrica sia calcolata, oppure 
al Piano di misurazione nel caso essa sia osservata.  
GOAL 2 

Q2.1  M2.1.1  TecnTestI  Tecniche  di  testing  utilizzate  per  il 
processo  pianificazione  test 
d’integrazione 
Q2.2  M2.2.1  ToolsUtilI  Tool  utilizzati  nel  processo  di 
pianificazione dei test d’integrazione 
M1.3.2  %DistrExpTest  Distribuzione  in  percentuale  dei 
valori  soggettivi  di  esperienza  del 
team nell’esecuzione del processo 
Q2.3  M2.3.1  ConTecUtilI  Conoscenza  di  un  individuo  del  team 
circa  le  tecniche  di  pianificazione  dei 
test d’integrazione utilizzate 
M2.3.2  %DistrConTecUtilI  Distribuzione  in  percentuale  dei 
  75 
  valori della conoscenza del team circa 
le  tecniche  di  pianificazione  dei  test 
d’integrazione  
utilizzate 
M2.3.3  %PersExpTecUtilI  Percentuale  di  persone  del  team 
esperte  delle  tecniche  di 
pianificazione  dei  test  d’integrazione 
utilizzate 
Q2.4  M2.4.1  ConToolsUtilI  Conoscenza  di  un  individuo  del  team 
circa  i  tool  per  la  pianificazione  dei 
test d’integrazione utilizzati 
M2.4.2  %DistrConToolsUtilI  Distribuzione  in  percentuale  dei 
valori della conoscenza del team circa 
i  tool  per  la  pianificazione  dei  test 
d’integrazione utilizzati 
M2.4.3  %PersExpToolsUtilU Percentuale  di  persone  del  team 
I  esperte  dei  tool  per  la  pianificazione 
dei test d’integrazione utilizzati 
Q1.6  M1.6.1  ConDomAppl  Conoscenza  di  un  individuo  del  team 
del dominio applicativo 
M1.6.2  %DistrConDomAppl  Distribuzione  in  percentuale  dei 
valori  della  conoscenza  del  team  del 
dominio applicativo 
M1.6.3  %PersExpDomAppl  Percentuale  di  persone  del  team 
Q2.5  M1.8.1  TPianCTI  Ore/uomo  per  la  pianificazione  dei 
casi di test di integrazione 
M2.5.1  NumCTI  Numero di casi di test di integrazione 
pianificati 
M2.5.2  StTPianCTI  Numero  standardizzato  di  ore  uomo 
per  pianificare  un  caso  di  test  di 
integrazione 
M1.8.1  TPianCTI  Ore/uomo  per  la  pianificazione  dei 
test di integrazione 
M1.8.2  TPianCT  Ore  uomo  per  la  pianificazione  dei 
  76 
  casi di test 
M2.6.1  %TPianCTI  Percentuale  di  tempo  dedicata  alla 
pianificazione dei test di integrazione 
Q2.7  M1.9.1  NumClas  Numero di classi del sistema 
M2.5.1  NumCTI  Numero di casi di test di integrazione 
pianificati 
M2.7.1  StNumCTI  Numero  standardizzato  di  casi  di  test 
di integrazione pianificati 
Q2.8  M2.8.1  QuaCTIA  Quantità di casi di test di integrazione 
prodotti per classe in altri processi 
Q2.9  M2.8.1  StTPianCTIA  Ore/uomo  standardizzate  per 
pianificare  un  caso  di  test  di 
integrazione in processi analoghi 
Q2.10  M2.10.1  %TPianCTILett  Peso che in percentuale deve avere lo 
sforzo per la pianificazione dei casi di 
test  d’integrazione  secondo  la 
letteratura 
 
Quando  una  Question  viene  ereditata  da  un  Goal  precedente,  questa  eredita 
anche tutte le sue Metric. In questo esempio, la Q1.3 ha ereditato M1.3.1, M1.3.2 
e M.1.3.3. 
La  precisazione  è  importante  poiché  molto  spesso  la  formulazione  di  una 
Question  appare  sufficientemente  generica  da  poter  essere  richiamata  in  altri 
Goal. Arrivati all’associazione delle misure ci si rende conto che è stato un errore 
ereditarla.  Per  questa  ragione  è  opportuno  formulare  Question  molto  precise 
evitando così di riutilizzarle in modo improprio. 
GOAL 3 
Q3.1  M3.1.1  ToolsEsecTest  Tool  utilizzati  per  l’esecuzione  dei 

  77 


Q3.2  M3.2.1  ConToolsUtilEsecTU  Conoscenza  di  un  individuo  del  team 

circa  i  tool  utilizzati  per  l’esecuzione 
dei test di unità 
M3.2.2  %DistrConToolsUtilE Distribuzione  in  percentuale  dei 

secTU  valori della conoscenza del team circa 
i  tool  utilizzati  per  l’esecuzione  dei 
M3.2.3  %PersExpToolsUtilEs Percentuale  di  persone  del  team 

ecTU  esperte  dei  tool  utilizzati  per 
l’esecuzione dei test di unità 
Q3.3  M3.3.1  LOCStubFitzU  Dimensione in LOC degli stub di unità 

fittizi utilizzati 
M3.3.2  NClasStubFitzU  Numero  classi  simulate  da  stub  di 

unità fittizi 
M3.3.3  StLOCStubFitzU  Dimensione  standardizzata  in  LOC 

degli stub di unità fittizi utilizzati 
Q3.4  M3.4.1  TEsecCTU  Ore/uomo per l’esecuzione dei casi di 

M3.4.2  NumCTUEsec  Numero  di  casi  di  test  di  unità 

eseguiti 
M3.4.3  StTEsecCTU  Numero  standardizzato  di  ore  uomo 

per eseguire un caso di test di unità 
Q3.5  M3.4.1  TEsecCTU  Ore/uomo per l’esecuzione dei casi di 

M3.5.1  TEsecCTI  Ore/uomo per l’esecuzione dei casi di 
  78 
  test di integrazione 
M3.5.2  TEsecCT  Ore/uomo per l’esecuzione dei casi di 

test 
M3.5.3  %TEsecCTU  Percentuale  di  tempo  dedicata 

all’esecuzione dei test di unità 
Q3.6  M3.6.1  NumCTUPos  Numero di casi di test di unità positivi 

pianificati 
M3.6.2  %CTUPos  Percentuale  dei  casi  di  test  di  unità 

positivi 
Q3.7  M3.7.1  %CTUPosA  Percentuale  dei  casi  di  test  di  unità 
positivi in altri progetti simili 
Q3.8  M3.8.1  StTEsecCTUA  Ore/uomo  standardizzate  per 

eseguire  un  caso  di  test  di  unità  in 
processi analoghi 
Q3.9  M3.9.1  %TEsecCTULett  Peso che in percentuale deve avere lo 

sforzo per l’esecuzione dei casi di test 
di unità secondo la letteratura 
 
A  volte,  dopo  aver  completato  la  progettazione  di  un  GQM  può  capitare  di 
accorgersi  di  non  aver  dettagliato a sufficienza la rappresentazione  dei  modelli 
di processo che volevamo valutare. Quando ciò accade, è necessario correggere 
la rappresentazione, estendendola con ulteriori sotto‐attività. 
E’ questo il caso delle misure stabilite per il Goal 3. Ci si rende subito conto che 
tra  gli  elementi  coinvolti  appaiono  “termini”  (stub)  che  non  trovano  una 
corrispondenza nel modello di processo disegnato. Indicativamente è chiaro che 
stiamo  migliorando  la  qualità  del  processo  di  Esecuzione  del  test  di  unità  e  di 
integrazione  senza  che  questi  due  siano  minimamente  dettagliati  nella  nostra 
rappresentazione. Se nel caso della pianificazione, abbiamo un sufficiente livello 
di  dettaglio  sia  per  l’attività  di  Pianificazione_test_di_unità  che  per  quella  di 
Pianificazione_test_di_integrazione,  nel  caso  dell’esecuzione  non  abbiamo  la 
stessa situazione. 
  79 
In  definitiva,  anche  le  misurazioni  necessarie  al  modello  di  qualità  progettato 
concorrono  (un  po’  tardivamente  )  a  stabilire  il  livello  di  granularità  del 
modello di processo rappresentato.  
In  questo  contesto  si  è  voluto  mettere  in  risalto  proprio  questo  fattore  e  la 
carenza nel modello di processo è stata introdotta appositamente. 
GOAL 4 

Q4.1  M4.1.1  ToolsEsecTestI  Tool  utilizzati  per  l’esecuzione  dei 
test d’integrazione 
Q4.2  M4.2.1  ConToolsUtilEsecTI  Conoscenza  di  un  individuo  del 
team  circa  i  tool  utilizzati  per 
l’esecuzione dei test di integrazione 
M4.2.2  %DistrConToolsUtilEs Distribuzione  in  percentuale  dei 
ecTI  valori  della  conoscenza  del  team 
circa i tool utilizzati per l’esecuzione 
dei test di integrazione 
M4.2.3  %PersExpToolsUtilEse Percentuale  di  persone  del  team 
cTI  esperte  dei  tool  utilizzati  per 
l’esecuzione dei test di integrazione 
Q4.3  M4.3.1  LOCStubFitzI  Dimensione  in  LOC  degli  stub  di 
integrazione fittizi utilizzati 
M4.3.2  NClasStubFitzI  Numero  classi  simulate  da  stub  di 
integrazione fittizi 
M4.3.3  StLOCStubFitzI  Dimensione  standardizzata  in  LOC 
degli  stub  di  integrazione  fittizi 
utilizzati 
  80 
Q4.4  M3.5.1  TEsecCTI  Ore/uomo  per  l’esecuzione  dei  casi 
di test di integrazione 
M4.4.2  NumCTIEsec  Numero  di  casi  di  test  di 
integrazione eseguiti 
M4.4.3  StTEsecCTI  Numero standardizzato di ore uomo 
per  eseguire  un  caso  di  test  di 
integrazione 
Q4.5  M3.4.1  TEsecCTU  Ore/uomo  per  l’esecuzione  dei  casi 
di test di unità 
M3.5.1  TEsecCTI  Ore/uomo  per  l’esecuzione  dei  casi 
di test di integrazione 
M3.5.2  TEsecCT  Ore/uomo  per  l’esecuzione  dei  casi 
di test 
M4.5.1  %TEsecCTI  Percentuale  di  tempo  dedicata 
all’esecuzione  dei  test  di 
integrazione 
Q4.6  M4.6.1  NumCTIPos  Numero  di  casi  di  test  di 
integrazione positivi 
M2.1.1  NumCTI  Numero  di  casi  di  test  di 
integrazione pianificati 
M4.6.2  %CTIPos  Percentuale  di  casi  di  test  di 
Q4.7  M4.7.1  %CTIPosA  Percentuale  dei  casi  di  test  di 
integrazione positivi in altri progetti 
simili 
Q4.8  M4.8.1  StTEsecCTIA  Ore/uomo  standardizzate  per 
eseguire  un  caso  di  test  di 
integrazione in processi analoghi 
Q4.9  M4.9.1  %TEsecCTILett  Peso  che  in  percentuale  deve  avere 
lo sforzo per l’esecuzione dei casi di 
test  di  integrazione  secondo  la 
letteratura 
  81 
Fogli metrici 
I fogli metrici rappresentano il risultato sintetico del modello GQM e riuniscono 
in un unico diagramma tutti i punti salienti per ciascun Goal. 
La prima parte riepiloga le caratteristiche del Goal: oggetto, scopo, prospettiva, 
punto  di  vista  e  contesto.  La  seconda  parte  è  suddivisa  in  quattro  quadranti: 
Quality Focus, Variation Factor, Baseline Hypothesis e Baseline Impact. 
I  Quality  Focus  raccolgono  tutte  le  misure  finali  di  tutte  le  Question  dell’area 
Modello  primario.  Non  vengono  prese  tutte  le  misure  ma  soltanto  quelle 
significative/finali.  Non  si  prendono,  in  generale,  le  misure  assolute  (malgrado 
siano  state  dichiarate)  ma  possibilmente  quelle  relative  (molto  spesso  per 
agevolare  il  confronto  del  modello  con  misure  esterne).  Essi  rappresentano  le 
misure oggetto degli obiettivi di qualità da raggiungere. 
I Variation Factor raccolgono tutte le misure finali di tutte le Question dell’area 
Caratterizzazione del processo. Anche in questo caso non vengono prese tutte le 
metriche  ma  soltanto  quelle  significative  ai  fini  del  modello.  E’  importante 
sottolineare  che  questo  quadrante  contiene  i  fattori  sui  quali  il  management 
dell’organizzazione può agire per migliorare il processo. 
Le  Baseline  Hypothesis  contengono  l’espressione  delle  soglie  che  se  rispettate 
stabiliscono  il  raggiungimento  positivo  del  Goal.  L’espressione  algebrica  è 
definita  ponendo  in  relazione  le  metriche  del  quadrante  Quality  Focus  con  le 
metriche  contenute  nel  Modello  di  validità  e  Modello  di  confronto  del  Goal  in 
esame. 
Infine,  le  Baseline  Impact  contengono  una  descrizione  testuale  di  come  una 
modifica  ad  ogni  Variation  Factor  impatti  sui  Quality  Focus.  Essi  esprimono  la 
relazione  causa‐effetto  che  intercorre  tra  la  modifica  di  un  fattore  da  parte  del 
management e le misure delle metriche presenti nel quadrante Quality Focus. 
Riassumendo: gli Baseline Impact indicano i Variation Factor su cui può agire il 
management per migliorare i Quality Focus che non rispettano le soglie indicate 
nella Baseline Hypothesis. 
GOAL 1 
Oggetto dello 
Scopo  Prospettiva  Punto di vista  Contesto 
studio 
  82 
processo di 
“Pianificazione  Processo di 
valutarlo  efficienza  Sviluppatore 
dei casi di Test di  Testing 
Unità” 
Quality Focus  Variation Factors 
[Q1.7 , Q1.8, Q1.9]  [Q1.1, Q1.2, Q1.3, Q1.4, Q1.5, Q1.6] 
M1.7.3 (StTPianCTU) Numero  VF1.1 (TecnTestU) Tecniche di 
standardizzato di ore uomo per pianificare  testing per la pianificazione dei test 
un caso di test di unità  di unità 
M1.8.3 (%TPianCTU) Percentuale di tempo  VF1.2 (ToolsUtilU) Tool utilizzati per 
dedicata alla pianificazione dei test di unità  la pianificazione dei test di unità 
M1.9.2 (StNumCTU) Numero  VF1.3 (%PersExpTest) Percentuale 
standardizzato di casi di test di unità  di persone del team esperte di testing 
pianificati  VF1.4 (%PersExpTecUtilU) 
Percentuale di persone del team 
esperte delle tecniche di 
pianficazione dei test di unità 
utilizzate 
VF1.5 (%PersExpToolsUtilU) 
esperte dei tool per la pianificazione 
dei test di unità utilizzati 
VF1.6 (%PersExpDomApp) 
Baselines Hypothesis 
Baselines Impacts 
[Q1.10, Q1.11, Q1.12] 
BH1.1: M1.9.2 ≥ M1.10.1  BI1.1: Migliorare le tecniche 
BH1.2: M1.7.3 ≤ M1.11.1  utilizzate per la pianificazione dei 
BH1.3: M1.12.1 ‐ 10% ≤ M1.8.3 ≤ M1.12.1 +  test di unità, diminuisce il numero 
10%  standardizzato di ore uomo per 
pianificare un caso di test di unità 
(effort assoluto) 
BI1.2: Migliorare i tool utilizzati per 
la pianificazione dei test di unità, 
diminuisce il numero standardizzato 
di ore uomo per pianificare un caso di 
test di unità. (effort assoluto) 
BI1.3: Aumentare la percentuale di 
persone del team esperte di testing, 
permette di bilanciare l’effort per la 
pianificazione del test d’integrazione 
con l’effort per la pianificazione del 
  83 
test di unità. (effort relativo) 
persone del team esperte delle 
tecniche di pianificazione dei casi di 
testi di unità utilizzate, diminuisce il 
numero standardizzato di ore uomo 
per pianificare un caso di test di 
unità. (effort assoluto) 
persone del team esperte dei tool per 
la pianificazione dei casi di test 
utilizzati, diminuisce il numero 
standardizzato di ore uomo per 
pianificare un caso di test di unità 
persone del team esperte del dominio 
applicativo, aumenta il numero 
standardizzato di casi di test di unità 
pianificati  
 
GOAL 2 
Oggetto dello 
studio 
processo di 
“Pianificazione  Processo di 
valutarlo  efficienza  sviluppatore 
dei casi di Test di  Testing 
Integrazione” 
[Q2.5, Q2.6, Q2.7]  [Q2.1, Q2.2, Q1.3, Q2.3, Q2.4, Q1.6] 
M2.5.2 (StTPianCTI) Numero  VF1.1 (TecnTestI) Tecniche di 
standardizzato di ore uomo per pianificare  pianificazione dei test d’integrazione 
un caso di test di integrazione  VF1.2 (ToolsUtilI) Tool utilizzati per 
M2.6.1 (%TPianCTI) Percentuale di tempo  la pianificazione dei test 
dedicata alla pianificazione dei test  d’integrazione 
d’integrazione  VF1.3 (%PersExpTest) Percentuale 
M2.7.1 (StNumCTI) Numero  di persone del team esperte di testing 
standardizzato di casi di test d’integrazione  VF1.4 (%PersExpTecUtilI) 
pianificati  Percentuale di persone del team 
  84 
esperte delle tecniche per la 
pianificazione dei test d’integrazione 
utilizzate 
VF1.5 (%PersExpToolsUtilI) 
esperte dei tool per la pianificazione 
dei test d’integrazione utilizzati 
VF1.6 (%PersExpDomApp) 
[Q2.8, Q2.9, Q2.10] 
BH2.1: M2.7.1 ≥ M2.8.1  BI2.1: Migliorare le tecniche 
BH2.2: M2.5.2 ≤ M2.9.1  utilizzate per la pianificazione dei 
BH2.3: M2.10.1 ‐ 10% ≤ M2.6.1 ≤ M2.10.1 +  test d’integrazione, diminuisce il 
10%  numero standardizzato di ore uomo 
per pianificare un caso di test 
d’integrazione (effort assoluto) 
BI2.2: Migliorare i tool utilizzati per 
la pianificazione dei test 
d’integrazione, diminuisce il numero 
pianificare un caso di test di 
integrazione. (effort assoluto) 
permette di bilanciare l’effort per la 
pianificazione del test d’integrazione 
con l’effort per la pianificazione del 
test di unità. (effort relativo) 
persone del team esperte delle 
tecniche di pianificazione dei casi di 
testi d’integrazione utilizzate, 
diminuisce il numero standardizzato 
di ore uomo per pianificare un caso 
di test d’integrazione. (effort 
assoluto) 
persone del team esperte dei tool per 
la pianificazione dei casi di test 
pianificare un caso di test 
  85 
d’integrazione (effort assoluto) 
persone del team esperte del 
dominio applicativo, aumenta il 
numero standardizzato di casi di test 
d’integrazione pianificati 
 
GOAL 3 
Oggetto dello 
studio 
processo di 
“Esecuzione  Processo di 
casi di Test di  Testing 
Unità” 
Quality Focus   Variation Factors 
[Q3.4 , Q3.5, Q3.6]  [Q3.1, Q1.3, Q3.2, Q3.3] 
M3.4.3 (StTEsecCTU) Numero  VF3.1 (ToolsEsecTestU) Tool utilizzati 
standardizzato di ore uomo per eseguire  per l’esecuzione test di unità 
un caso di test di unità  VF1.3 (%PersExpTest) Percentuale di 
M3.5.3 (%TEsecCTU) Percentuale di  persone del team esperte di testing 
tempo dedicata all’esecuzione dei test di  VF3.2 (%PersExpToolsUtilEsecTU) 
unità  Percentuale di persone del team esperte 
M3.6.2 (%CTUPos) Percentuale di casi  dei tool utilizzati per l’esecuzione dei 
di test di unità positivi  test di unità 
VF3.3 (StLOCStubFitzU) Dimensione 
standardizzata in LOC degli stub di unità 
fittizi utilizzati 
[Q3.7, Q3.8, Q3.9] 
BH3.1: M3.6.2 ≥ M3.7.1  BI3.1: Migliorare i tool utilizzati per 
BH3.2: M3.4.3 ≤ M3.8.1  l’esecuzione di test di unità, diminuisce 
BH3.3: M3.9.1 ‐ 10% ≤ M3.5.3 ≤ M3.9.1  il numero standardizzato di ore uomo 
+ 10%  per eseguire un caso di test di unità. 
  86 
permette di bilanciare l’effort per 
l’esecuzione del test di integrazione con 
l’effort per l’esecuzione del test di unità. 
(effort relativo) 
persone del team esperte dei tool 
eseguire un caso di test di unità. (effort 
assoluto) 
BI3.4: Aumentare la dimensione 
standardizzata in LOC degli stub di unità 
fittizi utilizzati aumenta la percentuale 
di casi di test di unità positivi. 
 
Uno  stub  è  un  pezzo  di  codice  utilizzato  per  simulare  il  funzionamento  di  una 
classe non ancora realizzata. La realizzazione di uno stub, per definizione, deve 
essere  meno  onerosa  della  realizzazione  della  classe  da  costruire.  Esistono 
diversi  tipi  di  stub  che,  a  seconda  del  loro  livello  di  raffinamento,  simulano 
sempre meglio la classe da realizzare. 
A proposito del BI3.4, ai fini del test, operare con stub più raffinati, aumenta la 
percentuale di casi di test positivi, dal momento che più complesso sarà lo stub e 
meglio  simulerà  la  classe.  In  questo  caso  è  maggiore  la  probabilità  di  scovare 
errori, poiché si opera su un sistema molto simile a quello reale. 
GOAL 4 
Oggetto dello  Scopo  Prospettiva  Punto di vista  Contesto 

studio 
processo di 
“Esecuzione casi  Processo di 
di Test di  Testing 
Integrazione” 
[Q4.4, Q4.5, Q4.6]  [Q4.1, Q1.3, Q4.2 Q4.3] 
  87 
M4.4.3 (StTEsecCTI) Numero  VF3.1 (ToolsEsecTestI) Tool utilizzati 
standardizzato di ore uomo per eseguire  per l’esecuzione dei test di unità 
un caso di test di integrazione  VF1.3 (%PersExpTest) Percentuale di 
M4.5.1 (%TEsecCTI) Percentuale di  persone del team esperte di testing 
tempo dedicata all’esecuzione dei test di  VF4.1 (%PersExpToolsUtilEsecTI) 
integrazione  Percentuale di persone del team 
M4.6.2 (%CTIPos) Percentuale di casi di  esperte dei tool utilizzati per 
test di integrazione positivi  l’esecuzione dei test di integrazione 
VF4.2 (StLOCStubFitzI) Dimensione 
standardizzata in LOC degli stub di 
integrazione fittizi utilizzati 
[Q4.7, Q4.8, Q4.9] 
BH4.1: M4.6.2 ≥ M4.7.1  BI4.1: Migliorare i tool utilizzati per 
BH4.2: M4.4.3 ≤ M4.8.1  l’esecuzione di test di integrazione, 
BH4.3: M4.9.1 ‐ 10% ≤ M4.5.1 ≤ M4.9.1 +  diminuisce il numero standardizzato 
10%  di ore uomo per eseguire un caso di 
test di integrazione. (effort assoluto) 
permette di bilanciare l’effort per 
l’esecuzione del test di integrazione 
con l’effort per l’esecuzione del test di 
unità. (effort relativo) 
persone del team esperte dei tool 
eseguire un caso di test di 
integrazione. (effort assoluto) 
BI4.4: Aumentare la dimensione 
standardizzata in LOC degli stub di 
integrazione fittizi utilizzati aumenta 
la percentuale di casi di test di 
Piano di misurazione 
All’interno  del  Piano  di  misurazione  vi  sono  tutte  le  Metric  che  sono  osservate. 
Una metrica è osservata quando non è il frutto di un calcolo algebrico. La metrica 
Tecniche di testing, ad esempio, non è calcolata ma osservata. 
  88 
Per questo tipo di metriche è necessario specificare il tipo di misura (oggettiva o 
soggettiva), il tipo di scala (nominale, ordinale, intervallo o ratio), le linee guida 
(chi e quando si misura) e le specifiche (come si misura). 
Una  misura  è  oggettiva  quando  non  vi  sono  giudizi/valutazioni  nella 

misurazione  ed  essa  dipende  solo  dall’oggetto  che  si  sta  misurando  (Es. 
Numero_di_dipendenti).  La  misura  è  soggettiva  quando  il  valore  misurato 
dipende dall’oggetto e dal punto di vista del misuratore che esprime un giudizio 
o una valutazione. (Es. Esperienza_team_di_sviluppo). 
Una metrica è caratterizzata da una scala che esprime la semantica operazionale 
consentita  sul  risultato  della  misura.  I  tipi  di  scala  sono  cinque:  nominale, 
ordinale,  intervallo,  ratio  ed  assoluta.  La  scala  nominale  si  limita  ad  elencare 
elementi  e  su  di  essa  nessuna  operazione  mantiene  la  propria  semantica  (Es. 
Tecniche di test). La scala ordinale, è costruita partendo da quella nominale con 
l’aggiunta di una relazione d’ordine sugli elementi (Es. Gradi_di_complessità). La 
scala intervallo, rispetto all’ordinale, si usa quando sottraendo ed addizionando 
le  misure,  queste  continuano  ad  avere  senso  (mantengono  valido  il  significato 
del valore ottenuto) (Es. Temperatura_Fahrenheit). Quando la metrica ammette 
come misura anche uno zero “significativo” allora è possibile usare la scala ratio. 
Questa scala preserva la semantica operazionale di moltiplicazione e divisione (e 
delle  altre  fin  qui  descritte).  La  scala  assoluta  consiste  nel  numero  di  elementi 
appartenenti  ad  un  insieme  osservabile.  Questa  scala  ha  un’unica  misura 
rilevabile. (Es. Numero_impiegati) 
In  generale  un’analisi  è  qualitativa  quando  la  maggior  parte  delle  metriche 
coinvolte  adottano  una  scala  nominale  e/o  ordinale.  L’analisi  è  quantitativa 
quando si utilizzano prevalentemente scale di tipo intervallo e/o ratio. 
Le  metriche  che  seguono  sono  state  importate  a  partire  da  un  documento 
fornitoci  dal  tutor  durante  le  esercitazioni  e  corretto  laddove  si  è  ritenuto 
opportuno.  
M1.1.1 TECNTESTU 
Definizione: Tecniche di testing utilizzate nel processo di pianificazione dei test di 
unità 
Tipo Metrica: Oggettiva 
  89 
Tipo Scala: Assoluta 
Linee Guida  Specifiche 
• Chi misura: valutatore del  • Come misura: osserva ed elenca quali sono 
processo di testing  le tecniche utilizzate nel processo di 
• Quando misura: prima  pianificazione dei test di unità 
dell'esecuzione del processo 
di testing 
 
M1.2.1 TOOLSUTILU 
Definizione: Tool utilizzati nel processo di pianificazione dei test di unità 
• Chi misura: valutatore del  • Come misura: osserva ed elenca quali sono i 
processo di testing  tool utilizzati nel processo di pianificazione 
• Quando misura: prima  dei test di unità definito 
dell'esecuzione del processo 
di testing 
 
M1.3.1 EXPTEST 
Definizione:  La  metrica  esperienza  relativa  al  testing  di  un  individuo  del  team 
riporta il livello di esperienza, relativamente all’esecuzione in un processo di test, 
di un individuo del team. 
Tipo Metrica: Soggettiva 
Tipo Scala: Ordinale 
• Chi misura:  • Come misura: per valutare tale metrica è necessario 
valutatore del  definire, per ogni persona coinvolta nell’esecuzione 
processo di testing  del processo, l’esperienza maturata rispetto 
• Quando misura:  all’esecuzione di un qualsiasi altro processo di test,  
prima  scegliendo uno dei valori assegnati: 
dell'esecuzione del   nessuna: la persona non ha alcuna conoscenza di 
processo di testing  un processo di test; 
 mediocre: la persona ha ricevuto una formazione 
sul processo, ma non ha mai partecipato 
all’esecuzione di un processo;  
 sufficiente: la persona ha ricevuto una formazione  
  90 
sul processo e ha partecipato ad almeno un 
progetto; 
 buona: la persona ha ricevuto una formazione sul 
processo e ha partecipato a molti progetti. 
 
M1.4.1 CONTECUTILU 
Definizione:  La  metrica  conoscenza  di  un  individuo  del  team  circa  le  tecniche  di 
pianificazione  dei  dei  test  di  unità  utilizzate  riporta  il  livello  di  conoscenza, 
relativamente  alle  tecniche  di  pianificazione  dei  test  di  unità,  di  un  individuo  del 
team. 
• Chi misura:  • Come  misura:  per  valutare  tale  metrica  è 
valutatore del  necessario  definire  per  ogni  persona  coinvolta  nel 
processo di testing  processo,  il  livello  di  esperienza  nelle  tecniche  di 
• Quando misura:  pianificazione  dei  test  di  unità,    scegliendo  uno  dei 
prima dell'esecuzione  valori assegnati: 
del processo di  • Nessuna:  l’individuo  non  ha  nessuna  conoscenza 
testing  nelle  tecniche  e  quindi  non  ha  nessuna 
esperienza; 
• Scarsa: l’individuo ha solamente letto dei manuali, 
circa le tecniche; 
• Bassa: l’individuo ha solamente avuto un corso di 
addestramento sulle tecniche utilizzate nel nostro 
processo; 
• Media:  l’individuo  ha  partecipato  ad  uno/due 
progetti  precedenti  nei  quali  si  utilizzavano  le 
tecniche del nostro processo; 
• Alta:  l’individuo  ha  partecipato  a  più  di  due 
progetti  precedenti  nei  quali  si  utilizzavano  le 
tecniche del nostro processo. 
 
M1.5.1 CONTOOLUTILU 
Definizione:  La  metrica  conoscenza  di  un  individuo  del  team  circa  i  tool  utilizzati 
per  il  processo  di  pianificazione  dei  test  di  unità  riporta  il  livello  di  conoscenza, 
relativamente ai tool di pianificazione dei test di unità, di un individuo del team. 
  91 
• Chi misura:  • Come  misura:  per  valutare  tale  metrica  è 
valutatore del  necessario  definire  per  ogni  persona  coinvolta  nel 
processo di testing  processo,  il  livello  di  esperienza  nei  tool  di 
• Quando misura:  pianificazione  dei  test  di  unità,    scegliendo  uno  dei 
prima dell'esecuzione  valori assegnati: 
del processo di testing  • Nessuna:  l’individuo  non  ha  nessuna  conoscenza 
dei tool e quindi non ha nessuna esperienza; 
• Scarsa:  l’individuo  ha  solamente  letto  dei 
manuali, circa i tool; 
• Bassa: l’individuo ha solamente avuto un corso di 
addestramento  sui  tool  utilizzati  nel  nostro 
processo; 
• Media:  l’individuo  ha  partecipato  ad  uno/due 
progetti precedenti nei quali si utilizzavano i tool 
del nostro processo; 
• Alta:  l’individuo  ha  partecipato  a  più  di  due 
progetti precedenti nei quali si utilizzavano i tool 
del nostro processo. 
 
M1.6.1 CONDOMAPPL 
Definizione:  La  metrica  conoscenza  di  un  individuo  del  team  del  dominio 
applicativo riporta il livello di conoscenza di un individuo del team, relativamente 
al dominio applicativo del sistema software da testare. 
• Chi misura: valutatore  • Come misura: per valutare tale metrica è 
del processo di testing  necessario definire per ogni persona coinvolta nel 
• Quando misura:  processo, il livello di conoscenza del dominio 
prima dell'esecuzione  applicativo, scegliendo uno dei valori assegnati: 
del processo di testing   Nessuna: l’individuo non ha lavorato a nessun 
progetto con simile dominio applicativo; 
 Bassa: l’individuo ha lavorato solamente ad uno 
o due progetti con simile dominio applicativo; 
 Buona: l’individuo ha lavorato a più di due 
progetti con simile dominio applicativo. 
 
M1.7.1TPIANCTU 
Definizione: La metrica costo ore/uomo speso “pianificazione test d'unità” riporta il 
  92 
tempo espresso in ore uomo dedicato all’esecuzione della fase “Pianificazione test 
d’unità” 
Tipo Scala: Ratio 
• Chi misura: valutatore del processo  • Come misura: per valutare tale 
di testing  metrica è necessario eseguire la 
• Quando misura: prima  seguente procedura: il soggetto 
dell'esecuzione del processo di  addetto alla valutazione della metrica 
testing  ritira, da ogni persona coinvolta nella 
fase di pianificazione, il modulo 
“RegistroTempoImpiegato” (indicato 
in appendice) e calcola il tempo 
totale in ore uomo impiegato per 
eseguire la suddetta fase. Tale calcolo 
consiste nella somma del tempo 
utilizzato per la pianificazione dei 
test d’unità (PTU) riportato in ogni 
modulo. 
 
M1.7.2NUMCTU 
Definizione: La metrica numero di casi di test d’unità riporta il numero di casi di 
test d’unità prodotti durante la fase di pianificazione dei casi di test. 
di testing  metrica è necessario contare il 
• Quando misura: prima  numero totale casi di test d’unità 
dell'esecuzione del processo di  esaminando il manufatto “Piano dei 
testing  casi di Test d’Unità”. 
 
M1.8.1TPIANCTI 
Definizione:  La  metrica  costo  ore/uomo  speso  “pianificazione  test  d’integrazione” 

riporta  il  tempo  espresso  in  ore  uomo  dedicato  all’esecuzione  della  fase 
“Pianificazione test d’integrazione” 
  93 
di testing  metrica è necessario eseguire la 
• Quando misura: prima  seguente procedura: il soggetto 
dell'esecuzione del processo di  addetto alla valutazione della metrica 
testing  ritira, da ogni persona coinvolta nella 
fase di pianificazione, il modulo 
“RegistroTempoImpiegato” (indicato 
in appendice) e calcola il tempo 
totale in ore uomo impiegato per 
eseguire la suddetta fase. Tale calcolo 
consiste nella somma del tempo 
utilizzato per la pianificazione dei 
test d’integrazione (PTI) riportato in 
ogni modulo. 
 
M1.9.1 NUMCLAS 
Definizione:  La  metrica  numero  classi  del  sistema  riporta  il  numero  di  classi  che 
compongono il sistema software da testare. 
di testing  metrica è necessario rilevare il 
• Quando misura: prima  numero totale delle classi del sistema 
dell'esecuzione del processo di  osservando il suo modello 
testing  progettuale. 
 
M1.10.1 QUACTUA 
Definizione:  La  metrica  quantità  di  casi  di  test  di  unità  prodotti  per  le  classi  del 
sistema  in  altri  processi  riporta  un  valore  che  indica  il  numero  di  casi  di  test  di 
unità che, in processi analoghi, sono pianificati per una classe del sistema. 
  94 
di testing  metrica è necessario rilevare, tramite 
• Quando misura: prima  indagini su web, il numero di casi di 
dell'esecuzione del processo di  test di unità che, in processi analoghi, 
testing  sono pianificati   per una classe del 
sistema. 
 
M1.11.1 STPIANCTUA 
Definizione: La metrica ore uomo standardizzate per pianificare un caso di test di 
unità  in  altri  processi  riporta  le  ore  uomo  che,  secondo  la  letteratura  sono 
necessarie per pianificare un caso di test di unità. 
di testing  metrica è necessario rilevare dalla 
• Quando misura: prima  letteratura, il numero riporta delle 
dell'esecuzione del processo di  ore uomo necessarie per pianificare 
testing  un caso di test di unità. 
 
M1.12.1 %TPIANCTULETT 
Definizione:  La  metrica  peso  che  in  percentuale  deve  avere  lo  sforzo  per  la 
pianificazione  dei  casi  di  Test  d’unità  secondo  la  letteratura  riporta  il  valore 
percentuale  dello  sforzo  per  la  pianificazione  dei  casi  di  test  d’unità  rispetto  alla 
letteratura disponibile. 
di testing  metrica è necessario che il valutatore 
• Quando misura: prima  indichi la percentuale di sforzo per la 
dell'esecuzione del processo di  pianificazione dei casi di test d’unità 
testing  dopo aver preso visione della 
letteratura. 
 
M2.1.1 TECNTESTI 
Definizione: Tecniche di testing per la pianificazione dei test d’integrazione 
  95 
• Chi misura: valutatore del processo  • Come misura: osserva ed elenca 
di testing  quali sono le tecniche utilizzate nel 
• Quando misura: prima  processo di pianificazione dei test 
dell'esecuzione del processo di  d’integrazione definito 
testing 
 
M2.2.1 TOOLSUTILI 
Definizione: Tool utilizzati nel processo di pianificazione dei test d’integrazione 
Tipo Metrica: Assoluta 
Tipo Scala: Nominale 
• Chi misura: valutatore del processo  • Come misura: osserva ed elenca 
di testing  quali sono i tool utilizzati nel 
• Quando misura: prima  processo di pianificazione dei test 
dell'esecuzione del processo di  d’integrazione definito 
testing 
 
M2.3.1 CONTECUTILI 
Definizione:  La  metrica  conoscenza  di  un  individuo  del  team  circa  le  tecniche  di 
testing  utilizzate  riporta  il  livello  di  conoscenza,  relativamente  alle  tecniche  di 
testing, di un individuo del team. 
• Chi misura: valutatore del processo  • Come  misura:  per  valutare  tale 
di testing  metrica  è  necessario  definire  per 
• Quando misura: prima  ogni  persona  coinvolta  nel  processo, 
dell'esecuzione del processo di  il  livello  di  esperienza  nelle  tecniche 
testing  di  testing,    scegliendo  uno  dei  valori 
assegnati: 
• Nessuna:  l’individuo  non  ha 
nessuna  conoscenza  nelle  tecniche 
e  quindi  non  ha  nessuna 
esperienza; 
  96 
• Scarsa:  l’individuo  ha  solamente 
letto  dei  manuali,  circa  le  tecniche 
di testing; 
• Bassa:  l’individuo  ha  solamente 
avuto  un  corso  di  addestramento 
sulle  tecniche  utilizzate  nel  nostro 
processo; 
• Media:  l’individuo  ha  partecipato 
ad uno/due progetti precedenti nei 
quali  si  utilizzavano  le  tecniche  di 
testing del nostro processo; 
• Alta:  l’individuo  ha  partecipato  a 
più  di  due  progetti  precedenti  nei 
quali  si  utilizzavano  le  tecniche  di 
testing del nostro processo. 
 
M2.4.1 CONTOOLUTILI 
per  il  processo  di  pianificazione  dei  test  d’integrazione  riporta  il  livello  di 
conoscenza,  relativamente  ai  tool  pianificazione  dei  test  d’integrazione,  di  un 
individuo del team. 
dell'esecuzione del processo di  il  livello  di  esperienza  nei  tool  di 
testing  pianificazione dei test d’integrazione,  
scegliendo uno dei valori assegnati: 
• Nessuna:  l’individuo  non  ha 
nessuna  conoscenza  dei  tool  e 
quindi non ha nessuna esperienza; 
• Scarsa:  l’individuo  ha  solamente 
letto dei manuali, circa i tool; 
• Bassa:  l’individuo  ha  solamente 
avuto  un  corso  di  addestramento 
sui  tool  utilizzati  nel  nostro 
processo; 
• Media:  l’individuo  ha  partecipato 
ad uno/due progetti precedenti nei 
  97 
quali  si  utilizzavano  i  tool  del 
nostro processo; 
• Alta:  l’individuo  ha  partecipato  a 
più  di  due  progetti  precedenti  nei 
quali  si  utilizzavano  i  tool  del 
nostro processo. 
 
M2.5.1 NUMCTI 
Definizione: La metrica numero di casi di test d’integrazione riporta il numero di 
casi di test d’integrazione prodotti durante la fase di pianificazione dei casi di test. 
di testing  metrica è necessario contare il 
• Quando misura: prima  numero totale casi di test 
dell'esecuzione del processo di  d’integrazione esaminando il 
testing  manufatto “Piano dei casi di test 
d’integrazione”. 
 
M2.8.1 QUACTIA 
Definizione: La metrica quantità di casi di test di integrazione prodotti per le classi 
del sistema in altri processi riporta un valore che indica il numero di casi di test di 
integrazione che, in processi analoghi, sono pianificati per una classe del sistema. 
di testing  metrica è necessario rilevare, tramite 
• Quando misura: prima  indagini su web, il numero di casi di 
dell'esecuzione del processo di  test di integrazione che, in processi 
testing  analoghi, sono pianificati   per una 
classe del sistema. 
 
M2.9.1 STPIANCTIA 
Definizione: La metrica ore uomo standardizzate per pianificare un caso di test di 
integrazione  in  altri  processi  riporta  le  ore  uomo  che,  secondo  la  letteratura  sono 
  98 
necessarie per pianificare un caso di test di integrazione. 
di testing  metrica è necessario rilevare dalla 
• Quando misura: prima  letteratura, il numero riporta delle 
dell'esecuzione del processo di  ore uomo necessarie per pianificare 
testing  un caso di test di integrazione. 
 
M2.10.1 %TPIANCTILETT 
Definizione:  La  metrica  peso  che  in  percentuale  deve  avere  lo  sforzo  per  la 
pianificazione dei casi di test d’integrazione secondo la letteratura riporta il valore 
percentuale dello sforzo per la pianificazione dei casi di test d’integrazione rispetto 
alla letteratura disponibile. 
• Quando misura: prima  indichi la percentuale di sforzo per la 
dell'esecuzione del processo di  pianificazione dei casi di integrazione 
letteratura. 
 
M3.1.1 TOOLSESECTESTU 
Definizione: La metrica Utilizzo di Tool per eseguire test di unità indica se durante 
l’esecuzione dei test di unità sono stati utilizzati particolari strumenti. 
• Quando misura: durante  indichi quali tool sono stati utilizzati 
dell'esecuzione del processo di  durante l’esecuzione dei test di unità. 
testing 
  99 
 
M3.2.1 CONTOOLSUTILESECTU 
per  l’esecuzione  dei  test  di  unità  riporta  il  livello  di  conoscenza,  relativamente  ai 
tool per l’esecuzione dei test di unità, di un individuo del team. 
testing  esecuzione  dei  test  di  unità,  
 Nessuna:  l’individuo  non  ha 
nessuna conoscenza dei tool e 
quindi  non  ha  nessuna 
esperienza; 
 Scarsa:  l’individuo  ha 
solamente  letto  dei  manuali, 
circa i tool di test di unità; 
 Bassa:  l’individuo  ha 
solamente  avuto  un  corso  di 
addestramento  sui  tool 
utilizzati nel nostro processo; 
 Media:  l’individuo  ha 
partecipato  ad  uno/due 
progetti  precedenti  nei  quali 
si  utilizzavano  i  tool  di  test  di 
unità del nostro processo; 
 Alta:  l’individuo  ha 
partecipato  a  più  di  due 
progetti  precedenti  nei  quali 
si  utilizzavano  i  tool  di  test  di 
unità del nostro processo. 
 
M3.3.1 LOCSTUBFITZU 
Definizione: La metrica Dimensione in LOC degli Stub di unità fittizi utilizzati indica 
il numero di linee di codice prodotte per gli stub di unità fittizi. 
  100 
• Quando misura: prima della fase di  effettui il conteggio delle righe di 
esecuzione dei casi di test  codice che costituiscono tutti gli stub 
di unità fittizi utilizzati durante 
l’esecuzione dei casi di test. 
 
M3.3.2 NCLASSTUBFITZU 
Definizione:  La  metrica  Numero  classi  simulate  da  Stub  di  unità  fittizi  indica  il 
numero  di  classi  che,  durante  l’esecuzione  dei  casi  di  test  di  unità,  sono  state 
simulate da stub di unità fittizi. 
• Quando misura: prima della fase di  effettui il conteggio degli stub di 
esecuzione dei casi di test  unità fittizi utilizzati per l’esecuzione 
di ogni caso di test. 
 
M3.4.1 TESECCTU 
Definizione:  La  metrica  costo  ore/uomo  speso  “esecuzione  test  d’unità”  riporta  il 
tempo  espresso  in  ore  uomo  dedicato  all’esecuzione  della  fase  “Esecuzione  test 
d’unità” 
• Chi misura: valutatore del  • Come  misura:  per  valutare  tale 
processo di testing  metrica  è  necessario  eseguire  la 
• Quando misura: alla fine  seguente  procedura:  il  soggetto 
dell’esecuzione del processo di  addetto  alla  valutazione  della 
testing  metrica  ritira,  da  ogni  persona 
coinvolta  nel  processo,  il  modulo 
“RegistroTempoImpiegato” 
(indicato  in  appendice)  e  calcola  il 
tempo totale in ore uomo impiegato 
  101 
per  eseguire  la  suddetta  sotto‐fase 
della  pianificazione.  Tale  calcolo 
consiste  nella  somma  del  tempo 
utilizzato  per  l’esecuzione  dei  test 
di  unità  (ETU)  riportato  in  ogni 
modulo. 
 
M3.4.2 NUMCTUESEC 
Definizione: La metrica numero di casi di test d’unità eseguiti riporta il numero di 
casi di test d’unità eseguiti durante la fase di esecuzione dei casi di test. 
di testing  metrica  è  necessario  contare  il 
• Quando misura: prima  numero  totale  casi  di  test  d’unità 
dell'esecuzione del processo di  eseguiti  esaminando  il  manufatto 
testing  “Pianificazione  dei  casi  di  Test 
d’Unità”. 
 
M3.5.1 TESECCTI 
Definizione:  La  metrica  costo  ore/uomo  speso  “esecuzione  test  di  integrazione” 
riporta  il  tempo  espresso  in  ore  uomo  dedicato  all’esecuzione  della  fase 
“Esecuzione test di integrazione” 
processo di testing  metrica  è  necessario  eseguire  la 
• Quando misura: alla fine  seguente  procedura:  il  soggetto 
dell’esecuzione del processo di  addetto  alla  valutazione  della 
testing  metrica  ritira,  da  ogni  persona 
coinvolta  nel  processo,  il  modulo 
“RegistroTempoImpiegato”  (indicato 
in  appendice)  e  calcola  il  tempo 
totale  in  ore  uomo  impiegato  per 
eseguire  la  suddetta  sotto‐fase  della 
pianificazione.  Tale  calcolo  consiste 
  102 
nella somma del tempo utilizzato per 
l’esecuzione  dei  test  di  integrazione 
(ETI) riportato in ogni modulo. 
 
M3.6.1 NUMCTUPOS 
Definizione: La metrica numero di casi di test d’unità positivi riporta il numero di 
casi di test d’unità positivi rilevati durante la fase di esecuzione dei casi di test. 
processo di testing  metrica  è  necessario  contare  il 
• Quando misura: dopo  numero  totale  casi  di  test  d’unità 
l’esecuzione della fase  positivi    esaminando  il  manufatto 
“Esecuzione dei casi di test”  “Report Casi di Test d’Unità positivi”. 
 
M3.7.1 %CTUPOSA 
Definizione: La metrica percentuale di casi di test di unità positivi in altri progetti 
simili riporta un valore che indica il numero in percentuale di casi di test di unità 
positivi  che,  in  processi  analoghi,  sono  stati  rilevati  durante  la  fase  di  esecuzione 
dei casi di test. 
• Chi misura: valutatore del  • Come misura: per valutare tale 
processo di testing  metrica è necessario rilevare, tramite 
• Quando misura: prima di  indagini su web, il numero 
iniziare ad eseguire il processo di  percentuale di casi di test di unità 
testing  positivi che, in processi analoghi, 
sono stati rilevati. 
 
M3.8.1 STTESECCTUA 
Definizione: La metrica numero standardizzato di ore uomo per eseguire un caso di 
test di unità in altri processi riporta un valore che indica il numero standardizzato 
di ore uomo per eseguire un caso di test di unità, in processi analoghi. 
  103 
processo di testing  metrica è necessario rilevare dalla 
• Quando misura: prima di  letteratura, il numero standardizzato 
iniziare ad eseguire il processo.  delle ore uomo necessarie per 
eseguire un caso di test di unità. 
 
M3.9.1 %TESECCTULETT 
Definizione: La metrica peso che in percentuale deve avere lo sforzo per l’esecuzione 
dei  casi  di  Test  d’unità  secondo  la  letteratura  riporta  il  valore  percentuale  dello 
sforzo per l’esecuzione dei casi di test d’unità rispetto alla letteratura disponibile 
• Chi misura : valutatore del processo  • Come misura: per valutare tale 
• Quando misura: Prima  indichi la percentuale di sforzo per la 
dell'esecuzione del processo di  esecuzione dei casi di test d’unità 
letteratura. 
 
M4.1.1 TOOLSESECTESTI 
Definizione:  La  metrica  Utilizzo  di  Tool  per  eseguire  test  d’integrazione  indica  se 
durante  l’esecuzione  dei  test  d’integrazione  sono  stati  utilizzati  particolari 
strumenti. 
• Quando misura: prima  indichi quali tool sono stati utilizzati 
dell'esecuzione del processo di  durante l’esecuzione dei test 
testing  d’integrazione. 
 
M4.2.1 CONTOOLSUTILESECTI 
  104 
per  l’esecuzione  dei  test  di  integrazione  riporta  il  livello  di  conoscenza, 
relativamente ai tool per l’esecuzione dei test di integrazione, di un individuo del 
team. 
• Quando misura: Prima  ogni  persona  coinvolta  nel  processo, 
testing  esecuzione  dei  test  di  integrazione, 
• Nessuna:  l’individuo  non  ha  nessuna 
conoscenza  dei  tool  e  quindi  non  ha 
nessuna esperienza; 
• Scarsa: l’individuo ha solamente letto 
dei  manuali,  circa  i  tool  di  test  di 
integrazione; 
• Bassa: l’individuo ha solamente avuto 
un  corso  di  addestramento  sui  tool 
utilizzati nel nostro processo; 
• Media:  l’individuo  ha  partecipato  ad 
uno/due  progetti  precedenti  nei 
quali  si  utilizzavano  i  tool  di  test  di 
integrazione del nostro processo; 
• Alta:  l’individuo  ha  partecipato  a  più 
di due progetti precedenti nei quali si 
utilizzavano  i  tool  di  test  di 
integrazione del nostro processo. 
 
M4.3.1 LOCSTUBFITZI 
Definizione:  La  metrica  Dimensione  in  LOC  degli  Stub  di  integrazione  fittizi 
utilizzati  indica  il  numero  di  linee  di  codice  prodotte  per  gli  stub  di  integrazione 
fittizi. 
  105 
• Quando misura: prima della fase di  effettui il conteggio delle righe di 
esecuzione dei casi di test.  codice che costituiscono tutti gli stub 
di integrazione fittizi utilizzati 
durante l’esecuzione dei casi di test. 
 
M4.3.2 NCLASSTUBFITZI 
Definizione: La metrica Numero classi simulate da Stub di integrazione fittizi indica 
il  numero  di  classi  che,  durante  l’esecuzione  dei  casi  di  test  di  integrazione,  sono 
state simulate da stub di integrazione fittizi. 
• Quando misura: prima della fase di  effettui il conteggio degli stub di 
esecuzione dei casi di test.  integrazione fittizi utilizzati per 
l’esecuzione di ogni caso di test. 
 
M4.4.2 NUMCTIESEC 
Definizione:  La  metrica  numero  di  casi  di  test  di  integrazione  eseguiti  riporta  il 
numero di casi di test di integrazione eseguiti durante la fase di esecuzione dei casi 
di test. 
Tipo Scal : Assoluta 
• Chi misura: valutatore del processo  • Come  misura:  Per  valutare  tale 
di testing  metrica  è  necessario  contare  il 
• Quando misura: Prima  numero  totale  casi  di  test  di 
dell'esecuzione del processo di  integrazione  eseguiti  esaminando  il 
testing  manufatto  “Pianificazione  dei  casi  di 
Test di integrazione”. 
 
M4.6.1 NUMCTIPOS 
Definizione:  La  metrica  numero  di  casi  di  test  di  integrazione  positivi  riporta  il 
numero di casi di test di integrazione positivi rilevati durante la fase di esecuzione 
  106 
processo di testing  metrica  è  necessario  contare  il 
• Quando misura: dopo  numero  totale  casi  di  test  di 
l’esecuzione della fase  integrazione positivi  esaminando 
“Esecuzione dei casi di test”  il  manufatto  “Report  Casi  di  Test 
di integrazione positivi”. 
 
M4.7.1 %CTIPOSA 
Definizione:  La  metrica  percentuale  di  casi  di  test  di  integrazione  positivi  in  altri 
progetti simili riporta un valore che indica il numero di casi di test di integrazione 
positivi  che,  in  processi  analoghi,  sono  stati  rilevati  durante  la  fase  di  esecuzione 
processo di testing  metrica è necessario rilevare, 
• Quando misura: prima di  tramite indagini su web, il 
iniziare ad eseguire il processo di  numero di casi di test di 
testing  integrazione positivi che, in 
processi analoghi, sono stati 
rilevati. 
 
M4.8.1 STTESECCTIA 
test  di  integrazione  in  altri  processi  riporta  un  valore  che  indica  il  numero 
standardizzato di ore uomo per eseguire un caso di test di integrazione, in processi 
analoghi. 
processo di testing  metrica è necessario rilevare 
• Quando misura: prima di  dalla letteratura, il numero 
  107 
iniziare ad eseguire il processo.  standardizzato delle ore uomo 
necessarie per eseguire un caso 
di test di integrazione. 
 
M4.9.1 %TESECCTILETT 
Definizione:  La  metrica  peso  che  in  percentuale  deve  avere  lo  sforzo  per 
l’esecuzione dei casi di Test di integrazione secondo la letteratura riporta il valore 
percentuale  dello  sforzo  per  l’esecuzione  dei  casi  di  test  di  integrazione  rispetto 
alla letteratura disponibile 
di testing  metrica è necessario che il 
• Quando misura: Prima  valutatore indichi la percentuale 
dell'esecuzione del processo di  di sforzo per la esecuzione dei 
testing  casi di test di integrazione dopo 
aver preso visione della 
letteratura. 
Modello di calcolo 
M1.3.2 %DISTREXPTEST 
Definizione:  La  metrica  distribuzione,  in  percentuale,  dei  valori  soggettivi 
d'esperienza del team nell'esecuzione del processo riporta la distribuzione del livello 
di esperienza, relativamente all’esecuzione in un processo di test, del team. 
Come  calcolare:  Il  calcolo  di  questa  metrica  è  effettuato  a  partire  dai  valori 
individuati nella metrica ExpTest per ogni individuo del team. 
per ogni i   {nessuna, mediocre, sufficiente, buona} la distribuzione, in percentuale, 
dei valori soggettivi d’esperienza 
 
#ExpTest i
%DistrExpTest= ( )*100 
#ExpTest b + ... + #ExpTest n
 
con  
  108 
 %DistrExpTesti = percentuale di individui del team che ha come valore di 
esperienza i. 
  #ExpTesti = numero di individui del team che hanno come valore di 
esperienza i. 
 #ExpTestn = numero di individui del team che hanno come valore di 
esperienza Nessuna. 
 #ExpTestb = numero di individui del team che hanno come valore di 
esperienza Bassa. 
 #ExpTests = numero di individui del team che hanno come valore di 
esperienza Sufficiente. 
 #ExpTestb = numero di individui del team che hanno come valore di 
esperienza Buona. 
 
M1.3.3 %PERSEXPTEST 
Definizione: La metrica percentuale di persone esperte del team nell’esecuzione del 
processo di test riporta le persone esperte nell’esecuzione in un processo di test in 
relazione all’intero team. 
individuati nella metrica %DistrExpTesti 
 
%PersExpTest = %DistrExpTestb + %DistrExpTests 
 
con 
 %DistrExpTests = percentuale di individui del team che hanno come valore 
di esperienza Sufficiente. 
 %DistrExpTestb = percentuale di individui del team che hanno come valore 
di esperienza Buona. 
 
M1.4.2 %DISTRCONTECUTILU 
Definizione: La metrica distribuzione in percentuale dei valori della conoscenza del 
team,  circa  le  tecniche  di  pianificazione  dei  test  di  unità  utilizzate  riporta  la 
distribuzione del livello di conoscenza del team delle tecniche di pianificazione dei 
test di unità utilizzate nel processo. 
individuati nella metrica ConTecUtilUi per ogni individuo del team. 
Per ogni i   {nessuna, scarsa, bassa, media, alta } la distribuzione, in percentuale, 
 
%DistrConTecUtilUi=( )*100 
  109 
Con 
 %DistrConTecUtilUi = percentuale di individui del team che ha come valore 
di esperienza i. 
 #ConTecUtilUi = numero di individui del team che hanno come valore di 
esperienza i. 
 #ConTecUtilUn = numero di individui del team che hanno come valore di 
  #ConTecUtilUs = numero di individui del team che hanno come valore di 
esperienza Scarsa 
  #ConTecUtilUb = numero di individui del team che hanno come valore di 
  #ConTecUtilUm= numero di individui del team che hanno come valore di 
esperienza Media. 
  #ConTecUtilUa = numero di individui del team che hanno come valore di 
esperienza Alta. 
 
M1.4.3 %PERSEXPTECUTILU 
Definizione:  La  metrica  percentuale  di  persone  del  team  esperte  delle  tecnologie 
utilizzate  nel  processori  pianificazione  dei  test  di  unità  riporta  le  persone  esperte 
delle  tecnologie  utilizzate  in  un  processo  di  pianificazione  dei  test  di  unità  in 
relazione all’intero team. 
individuati nella metrica %DistrConTecUtilUi 
 
%PersExpTecUtilU = %DistrConTecUtilUb + %DistrConTecUtilUs 
 
con 
 %DistrConTecUtilUs = percentuale di individui del team che hanno come 
valore di esperienza Sufficiente. 
 %DistrConTecUtilUb = percentuale di individui del team che hanno come 
valore di esperienza Buona. 
 
M1.5.2 %DISTRCONTOOLSUTILU 
team circa i tool di pianificazione dei test di unità utilizzati  riporta la distribuzione 
del  livello  di  conoscenza  del  team  dei  tool  di  pianificazione  dei  test  di  unità 
utilizzati nel processo. 
individuati nella metrica ConToolsUtilUi per ogni individuo del team. 
Per ogni i   {nessuna, bassa, sufficiente, buona} la distribuzione, in percentuale, dei 
valori soggettivi d’esperienza 
  110 
 
%DistrConToolsUtilU =( )*100 
 
con  
 %DistrConToolsUtilUi = percentuale di individui del team che ha come 
valore di esperienza i. 
 #ConToolsUtilUi = numero di individui del team che hanno come valore di 
esperienza i. 
 #ConToolsUtilUn = numero di individui del team che hanno come valore di 
 #ConToolsUtilUb = numero di individui del team che hanno come valore di 
 #ConToolsUtilUs = numero di individui del team che hanno come valore di 
 #ConToolsUtilUb = numero di individui del team che hanno come valore di 
 
M1.5.3 %PERSEXPTOOLSUTILU 
Definizione:  La  metrica  percentuale  di  persone  del  team  esperte  dei  tool  utilizzati 
nel  processo  di  pianificazione  dei  test  di  unità  riporta  le  persone  esperte  dei  tool 
utilizzati  in  un  processo  di  pianificazione  dei  test  di  unità  in  relazione  all’intero 
team. 
individuati nella metrica %DistrConToolsUtilUi  
 
%PersExpToolsUtilU = %DistrConToolsUtilUb + %DistrConToolsUtilUs 
 
con 
 %DistrConToolsUtilUs = percentuale di individui del team che hanno come 
 %DistrConToolsUtilUb = percentuale di individui del team che hanno come 
 
M1.6.2 %DISTRCONDOMAPPL 
Definizione:  La  metrica  distribuzione  in  percentuale  della  conoscenza  del  team, 
circa  il  dominio  applicativo  riporta  la  distribuzione  del  livello  di  conoscenza  del 
team del dominio applicativo del sistema software da testare. 
individuati nella metrica ConDomAppli per ogni individuo del team. 
Per  ogni  i    {nessuna,  bassa,  buona}  la  distribuzione,  in  percentuale,  dei  valori 
  111 
soggettivi d’esperienza 
 
%DistrConDomAppl=( )*100 
 
con  
 %DistrConDomAppli = percentuale di individui del team che ha come valore 
 #ConDomAppli = numero di individui del team che hanno come valore di 
esperienza i. 
 #ConDomAppln = numero di individui del team che hanno come valore di 
 #ConDomApplba = numero di individui del team che hanno come valore di 
 #ConDomApplbu = numero di individui del team che hanno come valore di 
 
M1.6.3 %PERSEXPDOMAPPL 
Definizione:  La  metrica  percentuale  di  persone  del  team  esperte  del  dominio 
applicativo  del  processo  di  test  riporta  le  persone  esperte  del  dominio  applicativo 
del processo di test in relazione all’intero team. 
individuati nella metrica %DistrConDomAppli  
 
%PersExpDomAppl = %DistrConDomApplbu 
 
con  
 %DistrConDomAppli = percentuale di individui del team che ha come valore 
di esperienza buona. 
 
M1.7.3 STTPIANCTU 
Definizione: La metrica numero standardizzato di ore uomo per pianificare un caso 
di  test  di  unità  riporta  le  ore  uomo  che,  mediamente,  sono  state  necessarie  per 
pianificare un caso di test di unità. 
Come calcolare: Il calcolo di questa metrica è effettuato facendo un rapporto tra le 
metriche TPianCTU e NumCTU: 
 
StTPianCTU = TPianCTU/NumCTU 
 
 
  112 
M1.8.2 TPIANCT 
Definizione:  La  metrica  ore  uomo  per  la  pianificazione  dei  casi  di  test  riporta  il 
numero di ore impiegate dall’impresa per pianificare i casi di test.. 
Come  calcolare:  Il  calcolo  di  questa  metrica  è  effettuato  sommando  i  valori 
individuati nella metriche TPianCTU e TPianCTI: 
 
TPianCT= TPianCTU + TPianCTI 
 
 
M1.8.3 %TPIANCTU 
Definizione:  La  metrica  percentuale  di  tempo  dedicata  alla  pianificazione  dei  test 
d'unità riporta una percentuale che indica il tempo impiegato nella pianificazione, 
per la pianificazione dei test d’unità. 
metriche TPianCTU e TPianCT moltiplicato per cento: 
 
%TPianCTU = ( TPianCTU / TPianCT ) * 100 
 
 
M1.9.2 STNUMCTU 
Definizione:  La  metrica  numero  standardizzato  di  casi  di  test  di  unità  pianificati 
riporta un valore che indica il numero di casi di test di unità che, mediamente, sono 
stati pianificati per una classe del sistema. 
metriche NumCTU e NumClas: 
 
StNumCTU = NumCTU / NumClas 
 
 
M2.3.2 %DISTRCONTECUTILI 
team,  circa  le  tecniche  di  pianificazione  dei  test  d’integrazione  utilizzate  riporta  la 
distribuzione del livello di conoscenza del team delle tecniche di pianificazione dei 
test d’integrazione utilizzate nel processo. 
individuati nella metrica ConTecUtilIi per ogni individuo del team. 
Per ogni i   {nessuna, scarsa, bassa, media, alta } la distribuzione, in percentuale, 
  113 
 
%DistrConTecUtilIi=( )*100 
 
Con 
 %DistrConTecUtilUi = percentuale di individui del team che ha come valore 
 #ConTecUtilIi = numero di individui del team che hanno come valore di 
esperienza i. 
 #ConTecUtilIn = numero di individui del team che hanno come valore di 
  #ConTecUtilIs = numero di individui del team che hanno come valore di 
esperienza Scarsa 
  #ConTecUtilIb = numero di individui del team che hanno come valore di 
  #ConTecUtilIm= numero di individui del team che hanno come valore di 
esperienza Media. 
  #ConTecUtilIa = numero di individui del team che hanno come valore di 
esperienza Alta. 
 
M2.3.3 %PERSEXPTECUTILI 
Definizione:  La  metrica  percentuale  di  persone  del  team  esperte  delle  tecnologie 
utilizzate  nel  processori  pianificazione  dei  test  d’integrazione  riporta  le  persone 
esperte  delle  tecnologie  utilizzate  in  un  processo  di  pianificazione  dei  test 
d’integrazione in relazione all’intero team. 
individuati nella metrica %DistrConTecUtilIi 
 
%PersExpTecUtilI = %DistrConTecUtilIb + %DistrConTecUtilIs 
 
con 
 %DistrConTecUtilIs = percentuale di individui del team che hanno come 
 %DistrConTecUtilIb = percentuale di individui del team che hanno come 
 
M2.4.2 %DISTRCONTOOLSUTILI 
team  circa  i  tool  di  pianificazione  dei  test  d’integrazione  utilizzati    riporta  la 
distribuzione  del  livello  di  conoscenza  del  team  dei  tool  di  pianificazione  dei  test 
d’integrazione utilizzati nel processo. 
  114 
individuati nella metrica ConToolsUtilIi per ogni individuo del team. 
 
%DistrConToolsUtilI =( )*100 
 
con  
 %DistrConToolsUtilIi = percentuale di individui del team che ha come valore 
 #ConToolsUtilIi = numero di individui del team che hanno come valore di 
esperienza i. 
 #ConToolsUtilIn = numero di individui del team che hanno come valore di 
 #ConToolsUtilIb = numero di individui del team che hanno come valore di 
 #ConToolsUtilIs = numero di individui del team che hanno come valore di 
 #ConToolsUtilIb = numero di individui del team che hanno come valore di 
 
M2.4.3 %PERSEXPTOOLSUTILU 
nel processo di pianificazione dei test d’integrazione riporta le persone esperte dei 
tool  utilizzati  in  un  processo  di  pianificazione  dei  test  d’integrazione  in  relazione 
all’intero team. 
individuati nella metrica %DistrConToolsUtilIi  
 
%PersExpToolsUtilI = %DistrConToolsUtilIb + %DistrConToolsUtilIs 
 
con 
 %DistrConToolsUtilIs = percentuale di individui del team che hanno come 
 %DistrConToolsUtilIb = percentuale di individui del team che hanno come 
 
M2.5.2 STTPIANCTI 
Definizione: La metrica numero standardizzato di ore uomo per pianificare un caso 
di test di integrazione riporta le ore uomo che, mediamente, sono state necessarie 
per pianificare un caso di test di integrazione. 
  115 
metriche TPianCTI e NumCTI: 
 
StTPianCTI = TPianCTI/NumCTI 
 
 
M2.6.1 %TPIANCTI 
Definizione:  La  metrica  percentuale  di  tempo  dedicata  alla  pianificazione  dei  test 
d’integrazione  riporta  una  percentuale  che  indica  il  tempo  impiegato  nella 
pianificazione, per la pianificazione dei test d’integrazione. 
metriche TPianCTI e TPianCT moltiplicato per cento: 
 
%TPianCTI = ( TPianCTI / TPianCT ) * 100 
 
 
M2.7.1 STNUMCTI 
Definizione:  La  metrica  numero  standardizzato  di  casi  di  test  di  integrazione 
pianificati riporta un valore che indica il numero di casi di test di integrazione che, 
mediamente, sono stati pianificati per una classe del sistema. 
metriche NumCTI e NumClas: 
 
StNumCTI = NumCTI / NumClas 
 
 
M3.2.2 %DISTRCONTOOLSUTILESECTU 
Definizione:  La  metrica  distribuzione  in  percentuale  dei  valori  della  conoscenza 
del team, circa i tool di esecuzione di test di unità utilizzati  riporta la distribuzione 
del  livello  di  conoscenza  del  team  dei  tool  di  esecuzione  di  test  di  unità  utilizzati 
nel processo. 
individuati nella metrica ConToolsUtilEsecTUi per ogni individuo del team. 
 
%DistrConToolsUtilEsecTU=( )*100 
  116 
 % DistrConToolsUtilEsecTUi = percentuale di individui del team che ha come 
 #ConToolsUtilEsecTUi  =  numero  di  individui  del  team  che  hanno  come 
 #ConToolsUtilEsecTUn  =  numero  di  individui  del  team  che  hanno  come 
valore di esperienza Nessuna. 
 #ConToolsUtilEsecTUb  =  numero  di  individui  del  team  che  hanno  come 
valore di esperienza Bassa. 
 #ConToolsUtilEsecTUs  =  numero  di  individui  del  team  che  hanno  come 
 #ConToolsUtilEsecTUb  =  numero  di  individui  del  team  che  hanno  come 
 
M3.2.3 %PERSEXPTOOLSUTILESECTU 
nel  processo  di  esecuzione  dei  test  di  unità  riporta  le  persone  esperte  dei  tool 
utilizzati nell’esecuzione di test di unità in relazione all’intero team. 
individuati nella metrica %DistrConToolsUtilEsecTUi 
 
%PersExpToolsUtilEsecTU = %DistrConToolsUtilEsecTUb + 
%DistrConToolsUtilEsecTUs 
 
con 
%DistrConToolsUtilEsecTUs  =  percentuale  di  individui  del  team  che  hanno  come 
%DistrConToolsUtilEsecTUb  =  percentuale  di  individui  del  team  che  hanno  come 
 
M3.3.3 STLOCSTUBFITZU 
Definizione: La metrica Dimensione standardizzata in LOC degli Stub di unità fittizi 
utilizzati  riporta  la  il  numero  standardizzato  (rispetto  al  numero  delle  classi 
simulate dagli stub di unità) di linee di codice di uno stub di unità fittizio. 
metriche LOCStubFitzU e NClasStubFitzU: 
 
StLOCStubFitzU = LOCStubFitzU / NClasStubFitzU 
 
 
M3.4.3 STTESECCTU 
  117 
test  di  unità  riporta  le  ore  uomo  che,  mediamente,  sono  state  necessarie  per 
eseguire un caso di test di unità. 
metriche TEsecCTU e NumCTUEsec: 
 
StTEsecCTU = TEsecCTU / NumCTUEsec 
 
 
M3.5.2 TESECCT 
Definizione: La metrica Costo ore/uomo speso “Esecuzione dei casi di Test” riporta 
il numero di ore impiegate dall’impresa per eseguire i casi di test. 
Come  calcolare:  Il  calcolo  di  questa  metrica  è  effettuato  sommando  i  valori 
individuati nella metriche EsecCTU, TEsecCTI: 
 
TEsecCT = TEsecCTU + TEsecCTI 
 
 
M3.5.3 %TESECCTU 
Definizione: La metrica percentuale costo ore/uomo speso “esecuzione test d’unità” 
riporta la percentuale di tempo dedicata all’esecuzione della fase “Esecuzione test 
d’unità”, in relazione al totale del tempo impiegato per l’esecuzione dei test. 
metriche TEsecCTU e TEsecCT: 
 
%TEsecCTU = (TEsecCTU / TEsecCT) * 100 
 
 
M3.5.3 %CTUPOS 
Definizione:  La  metrica  percentuale  casi  di  test  di  unità  positivi  riporta  la 
percentuale di casi di test di unità risultati positivi dopo la fase di “Esecuzione test 
d’unità”. 
metriche NumCTUPos e NumCTU: 
 
%CTUPos = (NumCTUPos / NumCTU) * 100 
 
 
  118 
M4.3.3 STLOCSTUBFITZI 
Definizione:  La  metrica  dimensione  standardizzata  in  LOC  degli  Stub  di 
integrazione fittizi utilizzati riporta la il numero standardizzato (rispetto al numero 
delle  classi  simulate  dagli  stub  di  integrazione)  di  linee  di  codice  di  uno  stub  di 
integrazione fittizio. 
Come  calcolare:  Il  calcolo  di  questa  metrica  è  effettuato  facendo  un  rapporto  tra  le 
metriche LOCStubFitzI e NClasStubFitzI: 
 
StLOCStubFitzI = LOCStubFitzI / NClasStubFitzI 
 
 
M4.3.3 STTESECCTI 
test di integrazione riporta le ore uomo che, mediamente, sono state necessarie per 
eseguire un caso di test di integrazione. 
metriche TEsecCTI e NumCTIEsec: 
 
StTEsecCTI = TEsecCTI / NumCTIEsec 
 
 
M4.5.1 %TESECCTI 
Definizione:  La  metrica  percentuale  costo  ore/uomo  speso  “esecuzione  test  di 
integrazione”  riporta  la  percentuale  di  tempo  dedicata  all’esecuzione  della  fase 
“Esecuzione  test  di  integrazione”,  in  relazione  al  totale  del  tempo  impiegato  per 
l’esecuzione dei test. 
metriche TEsecCTI e TEsecCT: 
 
%TEsecCTI = (TEsecCTI / TEsecCT) * 100 
 
 
M4.6.2 %CTIPOS 
Definizione:  La  metrica  percentuale  casi  di  test  di  integrazione  positivi  riporta  la 
percentuale  di  casi  di  test  di  integrazione  risultati  positivi  dopo  la  fase  di 
“Esecuzione test di integrazione”. 
metriche NumCTIPos e NumCTI: 
  119 
 
%CTIPos = (NumCTIPos / NumCTI) * 100 
 
Tavole di decisione 
Come  si  è  più  volte  ripetuto,  uno  degli  scopi  di  questo  caso    di  studio  è  la 
valutazione di un modello di processo in base ad alcuni criteri di qualità. Per far 
ciò  è  indispensabile  rilevare  le  misure  necessarie  ed  essere  in  grado  di 
interpretarle per intraprendere le attività di miglioramento. 
In  un  contesto  reale,  tutte  le  metriche  dichiarate  all’interno  del  modello  di 
qualità  dovrebbero  essere  misurate  in  maniera  opportuna  (rispetto  a  quanto 
dichiarato nel piano di misurazione/modello di calcolo). 
Per agevolare la consultazione del modello di qualità da parte del management 
dell’organizzazione (che ne è il principale utilizzatore) si costruiscono le Tavole 
di decisione. 
Le  tavole  di  decisione  sono  delle  tabelle  riepilogative  di  facile  consultazione 
necessarie a stabilire quali azioni intraprendere a seconda delle misure ottenute. 
Ad ogni foglio metrico ne corrisponde una ed una sola. 
Una  tavola  di  decisione  consiste  di  quattro  quadranti:  condizioni,  stati 
condizionali,  attività  di  miglioramento  e  regole  di  decisione.  Nel  quadrante  in 
alto a sinistra vengono poste le condizioni: tutte le soglie presenti nelle Baseline 
Hypothesis. Le soglie stabiliscono quando i risultati sono positivi rispetto al Goal 
e quando non lo sono. Gli stati condizionali, corrispondono all’insieme di tutti i 
possibili  valori  associati  alle  condizioni  (tipicamente  affermativo  e  negativo) 
opportunamente disposti. In basso a sinistra troviamo l’elenco di tutte le attività 
di miglioramento che sono estratte direttamente dagli Baseline Impact. Infine, in 
basso  a  destra  troviamo  una  serie  di  crocette  che  rappresentano  le  regole  di 
decisione.  La  crocetta  indica  la  necessità  di  eseguire,  in  un  preciso  stato 
condizionale, una precisa attività di miglioramento. 
Quando il management utilizza una tavola di decisione per prima cosa conosce i 
valori  di  tutte  le  condizioni  e  perciò  individua  il  percorso  esatto  di  condizioni 
(Es. YES, NO, NO). Dopo aver individuato il percorso, osserva le crocette relative 
ed individua tutte le azioni di miglioramento che dovrebbe eseguire. 
  120 
Naturalmente, il management non è obbligato ad eseguirle tutte. Utilizzando altri 
strumenti (che esulano da questa trattazione) potrebbe decidere di eseguire solo 
una parte di quelle rilevate nella tavola di decisione. 
Quando  ad  ogni  stato  condizionale,  corrispondono  molte  azioni  di 

miglioramento, allora è opportuno inserire ulteriori condizioni che agiscano da 
discriminante  tra  attività  di  miglioramento  specifiche.  Questo  caso  lo  vedremo 
più avanti (vedi sezione successiva). 
GOAL 1 
A) M1.7.3 <= M1.11.1  YES  NO 
B) M1.12.1  10% <= M1.8.3 <= M1.12.1 + 
YES  NO  YES  NO 
10% 
C) M1.9.2 >= M1.10.1  YES  NO  YES  NO  YES  NO  YES  NO 
1. Migliorare le tecniche di testing          X  X  X  X 
2. Migliorare i tool utilizzati          X  X  X  X 
3. Aumentare la percentuale di persone del 
    X  X      X  X 
team esperte di testing 
        X  X  X  X 
team esperte delle tecniche di test utilizzate 
        X  X  X  X 
team esperte dei tool utilizzati 
  X    X    X    X 
team esperte del dominio applicativo 
7. Goal soddisfatto  X               
  1  2  3  4  5  6  7  8 
GOAL 2 
A) M2.5.2 <= M2.9.1  YES  NO 
B) M2.10.1  10% <= M2.6.1 <= M2.10.1 + 
10% 
1. Migliorare le tecniche di testing          X  X  X  X 
2. Migliorare i tool utilizzati          X  X  X  X 
3. Aumentare la percentuale di persone del      X  X      X  X 
  121 
        X  X  X  X 
team esperte delle tecniche di test utilizzate 
        X  X  X  X 
  X    X    X    X 
team esperte del dominio applicativo 
  1  2  3  4  5  6  7  8 
Nella tavola di decisione del Goal 1 e del Goal 2 è evidente come quattro attività 
di miglioramento (1, 2, 4 e 5) siano indistintamente associate ai medesimi stati 
condizionali (A = NO). 
In altre parole, quando si deve eseguire un’attività a caso tra queste quattro, si 
devono operare sempre anche le rimenanti tre. E’ evidente che siamo di fronte 
ad  un  caso  “anomalo”.  Paradossalmente  la  soluzione  potrebbe  risolversi 
accorpando  sotto  un’unica  attività  di  miglioramento,  le  quattro  interessate 
(giacché sono contemporanee). 
Tuttavia,  analizzando  la  semantica  di  ciascuna  operazione,  ci  si  rende 
immediatamente conto di come siano profondamente diverse. Il fatto che siano 
contemporanee, a maggior ragione, pare inesatto. 
Per ovviare a questo problema, si introdurranno due soglie discriminanti che ci 
consentiranno di capire quando migliorare i tool piuttosto che la conoscenza dei 
tool e quando migliorare le tecniche piuttosto che la conoscenza delle tecniche. 
GOAL 3 
A) M3.4.3 <= M3.8.1  YES  NO 
B) M3.9.1  10% <= M3.5.3 <= M3.9.1 + 
10% 
1. Migliorare i tool utilizzati per l’esecuzione 
        X  X  X  X 
di test 
    X  X      X  X 
  122 
        X  X  X  X 
4. Aumentare la dimensione standardizzata 
  X    X    X    X 
in LOC degli stub di unità fittizi utilizzati 
  1  2  3  4  5  6  7  8 
GOAL 4 
A. M4.4.3 <= M4.8.1  YES  NO 
B. M4.9.1  10% <= M4.5.1 <= M4.9.1 + 
10% 
C. M4.6.2 >= M4.7.1  YES  NO  YES  NO  YES  NO  YES  NO 
1. Migliorare i tool utilizzati per l’esecuzione 
        X  X  X  X 
di test 
    X  X      X  X 
        X  X  X  X 
4. Aumentare la dimensione standardizzata 
  X    X    X    X 
in LOC degli stub di unità fittizi utilizzati 
  1  2  3  4  5  6  7  8 
Anche  per  il  Goal  3  ed  il  Goal  4  si  pone  lo  stesso  problema  solleva 
precedentemente.  Due  attività  di  miglioramento  (1  e  3)  sono  eseguite  (per  A  = 
NO) sempre insieme. 
Anche  in  questo  caso  è  opportuno  inserire  una  soglia  che  discrimini  l’uso 
dell’una piuttosto che dell’altra attività.  
Condizioni aggiuntive 
Alla  luce  delle  considerazioni  precedenti  si  sono  inserite  nel  Goal  1  e  2,  due 
soglie  discriminanti:  Percentuale  di  esperti  nei  tool  del  team  (M1.5.3)  >  70%  e 
Percentuale di esperti nelle tecniche del team (M1.4.3) > 70%. 
  123 
In questo modo otteniamo un fattore che ci consenta di scegliere se agire sui tool 
o  sull’esperienza  del  personale  nell’uso  dei  tool.  Alla  stessa  stregua  per  le 
tecniche,  avremo  un  fattore  che  ci  consente  di  scegliere  se  agire  sulle  tecniche 
oppure sull’esperienza del personale nell’uso delle tecniche. 
Il  ragionamento  alla  base  è  che  se  la  condizione  è  verificata,  allora  il  team  ha 
sufficiente  esperienza  del  tool/tecnica.  Se  vogliamo  migliorare  il  processo  è 
inutile  aumentare  ulteriormente  l’esperienza  del  team  sul  tool/tecnica: 
dobbiamo  agire  direttamente  sul  tool/tecnica  introducendone  di  nuovi  e 
migliori.  Se  la  condizione  non  è  verificata  allora  agiremo 
sull’esperienza/conoscenza  del  tool/tecnica  prima di  acquisire  un nuovo tool  o 
una nuova tecnica. 
GOAL 1 (PRIMA PARTE) 
A. M1.5.3 >=  70%  YES 
B. M1.4.3 >= 70%  YES  NO 
C. M1.7.3 <= 
M1.11.1 
D. M1.12.1  10% 
<= M1.8.3 <=  YES  NO  YES  NO  YES  NO  YES  NO 
M1.12.1 + 10% 
E. M1.9.2 >= 
YES  NO  YES  NO  YES  NO  YES  NO  YES  NO  YES  NO  YES  NO  YES  NO 
M1.10.1 
1. Goal soddisfatto  X                X               
2. Migliorare le 
        X  X  X  X          X  X  X  X 
tecniche di testing 
3. Migliorare i tool 
        X  X  X  X                 
utilizzati 
4. Aumentare la 
percentuale di 
    X  X      X  X      X  X      X  X 
persone del team 
percentuale di 
                        X  X  X  X 
esperte delle 
tecniche di test 
utilizzate 
percentuale di 
                               
esperte dei tool 
  124 
utilizzati 
percentuale di 
  X    X    X    X    X    X    X    X 
esperte del 
dominio 
applicativo  
   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16 
GOAL 1 (SECONDA PARTE) 
A) M1.5.3 >= 70%  NO 
B) M1.4.3 >= 70%  YES  NO 
C) M1.7.3 <= 
M1.11.1 
D) M1.12.1  10% 
M1.12.1 + 10% 
E) M1.9.2 >= 
M1.10.1 
                               
        X  X  X  X                 
utilizzati 
percentuale di 
    X  X      X  X      X  X      X  X 
percentuale di 
                        X  X  X  X 
esperte delle 
utilizzate 
percentuale di 
persone del team          X  X  X  X          X  X  X  X 
utilizzati 
percentuale di 
persone del team    X    X    X    X    X    X    X    X 
esperte del 
dominio 
  125 
applicativo  
   17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32 
GOAL 2 (PRIMA PARTE) 
A) M2.4.3 >= 70%  YES 
B) M2.3.3 >= 70%  YES  NO 
C) M2.5.2 <= 
M2.9.1 
D) M2.10.1  10% 
M2.10.1 + 10% 
E) M2.7.1 >= 
M2.8.1 
        X  X  X  X          X  X  X  X 
        X  X  X  X                 
utilizzati 
percentuale di 
    X  X      X  X      X  X      X  X 
percentuale di 
                        X  X  X  X 
esperte delle 
utilizzate 
percentuale di 
persone del team                                 
utilizzati 
percentuale di 
  X    X    X    X    X    X    X    X 
esperte del 
dominio 
applicativo  
   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16 
  126 
GOAL 2 (SECONDA PARTE) 
A) M2.4.3 >= 70%  NO 
B) M2.3.3 >= 70%  YES  NO 
C) M2.5.2 <= 
M2.9.1 
D) M2.10.1  10% 
M2.10.1 + 10% 
E) M2.7.1 >= 
M2.8.1 
                               
        X  X  X  X                 
utilizzati 
percentuale di 
    X  X      X  X      X  X      X  X 
percentuale di 
                        X  X  X  X 
esperte delle 
utilizzate 
percentuale di 
persone del team          X  X  X  X          X  X  X  X 
utilizzati 
percentuale di 
  X    X    X    X    X    X    X    X 
esperte del 
dominio 
applicativo  
   17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32 
GOAL 3 
A) M3.2.3 >= 70%  YES  NO 
  127 
B) M3.4.3 <= 
M3.8.1 
C) M3.9.1  10% 
M3.9.1 + 10% 
D) M3.6.2 >= 
M3.7.1 
utilizzati per          X  X  X  X                 
l’esecuzione di test 
percentuale di 
    X  X      X  X      X  X      X  X 
percentuale di 
persone del team                          X  X  X  X 
esperte dei tools 
utilizzati 
dimensione 
standardizzata in 
  X    X    X    X    X    X    X    X 
LOC degli stub di 
utilizzati  
   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16 
GOAL 4 
A) M4.2.3 >= 70%  YES  NO 
B) M4.4.3 <= 
M4.8.1 
C) M4.9.1  10% 
M4.9.1 + 10% 
D) M4.6.2 >= 
M4.7.1 
utilizzati per          X  X  X  X                 
l’esecuzione di test 
  128 
percentuale di 
    X  X      X  X      X  X      X  X 
percentuale di 
persone del team                          X  X  X  X 
esperte dei tools 
utilizzati 
dimensione 
standardizzata in 
  X    X    X    X    X    X    X    X 
LOC degli stub di 
utilizzati  
   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16 
  129 
Capitolo 3: 
Simulazione ed analisi dei dati 
rilevati 
Lo scopo di questo capitolo è quello di effettuare indagine empirica sul processo di 
test fin qui analizzato. La ragione più importante per avviare uno studio empirico è 
l’opportunità  di  ottenere  risultati  oggettivi  e  statisticamente  significativi  circa  la 
comprensione,  il  controllo,  la  predizione  ed  il  miglioramento  di  un  determinato 
processo. 
I risultati degli studi empirici costituiscono una base importante a supporto delle 
decisioni di business all’interno di una grande organizzazione. 
L’indagine  empirica  è  una  disciplina  estremamente  vasta  ed  articolata  che  può 
essere analizzata sotto vari punti di vista. Uno di questi è sicuramente il contesto 
all’interno  del  quale    è  condotta  l’indagine  stessa.  Nell’ingegneria  del  software,  lo 
studio empirico si divide in 3 grandi categorie: 
• desktop:  il  cambiamento  proposto  è  valutato  off‐line  senza  eseguire  il 

processo migliorato. Il livello di rischio è molto basso (a volte nullo); 
• laboratory:  il  cambiamento  proposto  è  valutato  in  un  ambiente  di 

laboratorio  (off‐line)  dove  viene  condotto  l’esperimento.  Dopo,  una  parte 
limitata del processo viene eseguita in modo controllato. Il livello di rischio 
è medio; 
• developtment  project:  il  cambiamento  proposto  è  valutato  in  un  contesto 

reale di sviluppo software, all’interno del quale è spesso troppo dispendioso 
  130 
condurre  esperimenti  controllati,  quindi  sovente  si  progettano  casi  di 
studio (aziendali). Il livello di rischio è molto alto. 
Un esperimento è caratterizzato da un ampio livello di controllo e lo scopo è quello 
di manipolare una o più variabili e controllarne altre a livelli fissati. L’effetto della 
manipolazione è misurato e dunque analizzabile con strumenti statistici. 
Un esempio di esperimento nell’ingegneria del software potrebbe essere quello 
di  comparare  due  differenti  metodologie  di  ispezione.  Per  questo  tipo  di  studi 
viene  utilizzata  la  statistica  inferenziale  con  lo  scopo  di  dimostrare,  con 
significatività statistica, che un metodo è migliore dell’altro. 
In un esperimento ci sono due tipi di variabili: indipendenti e dipendenti. Lo scopo 
della  nostra  analisi  è  quello  di  studiare  come  gli  effetti  dei  cambiamenti  sulle 
variabili  indipendenti  si  ripercuotano  sulle  variabili  dipendenti.  Le  variabili 
indipendenti  che  andremo  a  manipolare  nel  corso  dell’esperimento  prendono  il 
nome  di  fattori.  Tutte  le  altre  variabili  indipendenti  che  non  manipoliamo 
direttamente  vengono  tenute  a  livelli  fissati.  Un  trattamento  è  un  particolare 
valore che diamo ad un fattore. 
I  trattamenti  sono  applicati  ad  una  combinazione  di  oggetti  e  soggetti 

sperimentali.  
Ad  esempio,  l’oggetto  potrebbe  essere  un  documento  da  revisionare  con  due 
tecniche diverse, mentre il soggetto è la persona fisica che applica il trattamento.  
Un  esperimento  consiste  in  una  serie  di  prove  (test)  per  ogni  combinazione  di 
trattamento, oggetto e soggetto. L’ambiente all’interno del quale si eseguono tutte 
queste prove è proprio il processo. 
Processo di sperimentazione 
Realizzare  un  esperimento  significa  adempiere  ad  una  serie  di  attività  che  lo 
caratterizzano: 
1. definizione: in questa fase si definiscono gli obiettivi di qualità; 
2. pianificazione:  durante  la  quale  si  definisce  il  contesto,  si  formulano  le 
ipotesi, si selezionano le variabili ed i soggetti sperimentali; 
  131 
3. messa  in  opera:  in  questa  fase  si  esegue  l’esperimento  e  si  validano  i  dati 
ottenuti; 
4. analisi ed interpretazione: utilizzando la statistica descrittiva si interpretano 
i dati e si testano le ipotesi iniziali mediante il test delle ipotesi; 
5. presentazione  ed  impacchettamento:  si  produce  documentazione  e 

reportistica che supporti la presentazione dei risultati all’esterno. 
Figura 34: Concettualizzazione di un esperimento come processo 
Il  processo  in  figura,  in  realtà,  non  è  un  vero  modello  a  cascata;  un’attività  non 
necessariamente  deve  terminare  prima  che  la  successiva  parta.  Il  modello 
rappresenta  la  successione  di  partenza  delle  fasi  che  possono  essere  iterate, 
eccezion fatta per la fase di messa in opera (una volta avviata non è più possibile 
tornare indietro).  
Dopo  aver  raccolto  i  dati  nella  fase  di  messa  in  opera,  vogliamo  estrarre  delle 
conclusioni significative. Per interpretare i dati della sperimentazione utilizzeremo 
degli  strumenti  di  analisi  quantitativa  messi  a  disposizione  dalla  statistica 
descrittiva  e  per  validare  la  significatività  delle  interpretazioni  utilizzeremo  i  test 
delle ipotesi. 
  132 
La  statistica  descrittiva  è  un  ottimo  strumento  di  analisi  quantitativa  che  viene 
usata  per  descrivere  e  presentare  graficamente  una  collezione  di  dati 
enfatizzandone taluni aspetti interessanti. 
L’obiettivo della statistica descrittiva è quello di iniziare a prendere contatto con la 
distribuzione dei dati e scovare dati anomali o falsi (detti outlier). Il miglior modo 
per  studiare  la  distribuzione  dei  dati  è  quello  di  rappresentarli  graficamente.  In 
letteratura  esistono  diverse  modalità  di  rappresentazione  grafica,  quella  che 
utilizzeremo in questo caso di studio è quella Box Plot. 
Il Box Plot è un ottimo strumento per visualizzare la dispersione e l’asimmetria di 
distribuzione di un campione. E’ costruito visualizzando i percentili come in figura. 
Figura 35: Esempio di box plot 
L’individuazione  degli  outlier  è  semplice  poiché,  tali  punti  escono  dai  baffi 
(dall’inglese  whisker)  superiore  ed  inferiore.  Esistono  diverse  tecniche  per  il 
calcolo della lunghezza dei baffi. Quella utilizzata in questo corso è quella di Fenton 
che propone di utilizzare una lunghezza pari all’ampiezza della gabbia (differenza 
tra  primo  e  terzo  quartile)  moltiplicata  per  un  coefficiente  costante  pari  a  1,5. 
Questa  lunghezza  teorica  viene  troncata  ai  valori  più  vicini  presenti  nella 
collezione di dati, al fine di evitare valori negativi o privi di significato. 
Sebbene la statistica descrittiva ci dia l’illusione di fornirci conclusioni esatte, ogni 
considerazione  deve  essere  “statisticamente  significativa”  e  per  questa  ragione 
utilizzeremo i test delle ipotesi.  
L’obiettivo del test delle ipotesi è di provare se è possibile rigettare l’ipotesi nulla, 
H0  (ipotesi  che  nega  la  tesi),  basandosi  su  un  campione  la  cui  distribuzione  sia 
approssimabile ad una nota.  
Gli  strumenti  statistici  in  nostro  soccorso  sono  diversi  e  per  questo  è  necessario 
saper  scegliere  opportunamente  lo  strumento  giusto  per  ciascun  contesto.  La 
scelta  dello  strumento  più  adatto  viene  operata  analizzando  diversi  fattori 
dell’esperimento. 
  133 
Una prima distinzione viene operata tra i test parametrici e quelli non parametrici. 
Un test si dice parametrico quando la distribuzione del campione è approssimabile 
a quella normale. Questo, per la legge dei grandi numeri, inizia ad essere vero per 
qualsiasi campione che contenga più di 30 elementi. I test parametrici si applicano 
su campioni di cui è nota la distribuzione a priori oppure aventi un piccolo numero 
di elementi (< 30). Un’altra caratteristica discriminatoria è costituita dal numero di 
campioni  da  comparare  (due  o  più).  L’ultima  classificazione  si  opera  in  base  alla 
natura dei campioni: dipendenti o indipendenti. 
Dopo aver scelto il test opportuno, e dopo averlo utilizzato, lo sperimentatore è in 
grado  di  avallare  la  tesi  di  partenza  e  può  essere  sicuro  del  fatto  che  la  sua  tesi 
abbia un fondamento empirico (oppure no ). 
L’ultima  fase,  Presentazione  ed  impacchettamento,  non  è  stata  trattata  durante  il 
corso (). 
Caso di studio 
Di seguito si contestualizza il caso di studio in esame rispetto ai parametri teorici 
introdotti nella sezione precedente. 
Definizione 
Per “definizione di un esperimento” s’intende quella serie di attività che hanno lo 
scopo  di  chiarire  gli  obiettivi  di  qualità  che  vogliamo  raggiungere  sul  processo. 
L’espressione più compatta dell’obiettivo di qualità da raggiungere è il quesito di 
ricerca che sarà specificato di volta in volta per ogni esperimento condotto. 
Pianificazione 
Il  soggetto,  un  team  di  sviluppo,  disponeva  di  un  sistema  software  che  è  stato 
suddiviso (di volta in volta) in 10 componenti (oggetto) sulle quali ha agito in base 
ai  fattori  dell’esperimento  condotto.  E’  importante  porre  l’accento  sul  fatto  che  il 
team  si  sviluppo  fosse  sempre  lo  stesso,  unitamente  al  sistema  software  ed  alla 
modalità di partizionamento. Questa scelta è stata operata unicamente per evitare 
di introdurre rumore che avrebbe potuto inficiare l’esito dei differenti esperimenti. 
Circa  il  contesto  dell’esperimento,  esso  è  di  tipo  Development  Project.  In  questo 
caso, la classificazione non è propriamente netta. Su alcune variabili, beneficiamo 
di  un  forte  controllo  che  ci  potrebbe  far  pensare  ad  un  contesto  Laboratory  (e 
conseguenti tecniche “in vitro”). Tuttavia il coinvolgimento dei medesimi soggetti 
  134 
sperimentali  in  tutte  le  osservazioni  (un  unico  team  di  sviluppo  che  sperimenta 
tutti i trattamenti) è indice di un ambiente più orientato al Development Project (e 
conseguenti tecniche “in vivo”).  
L’ipotesi nulla, H0, si dichiara come negazione della teoria che si vuole dimostrare. 
Quando  si  rigetta  l’ipotesi  nulla,  lo  sperimentatore  ha  individuato  evidenza 
statistica  a  favore  della  sua  teoria  iniziale.  In  caso  contrario,  lo  sperimentatore 
accetta  H0  ammettendo  che  non  vi  sono  evidenze  statisticamente  significative  a 
sostegno  della  sua  teoria.  Nelle  prossime  sezioni  non  verrà  menzionata  affatto  la 
definizione testuale dell’ipotesi nulla, dal momento che è banale. Essa infatti è del 
tipo:  “Non  esiste  differenza  statisticamente  significativa  tra  il  trattamento  A  ed  il 
trattamento B”. 
Messa in opera 
Per  ogni  goal  sono  stati  portati  a  termine  due  esperimenti:  il  primo  con  tre 
osservazioni  ed  il  secondo  con  due.  Ogni  osservazione  è  il  frutto  di  dieci 
rilevamenti. Tutti questi dati sono stati archiviati all’interno di un foglio di calcolo 
elettronico che il tutor ha provveduto a fornirci. 
Analisi ed interpretazione 
Per  ogni  esperimento  di  ogni  goal,  sono  stati  riportati  i  risultati  del  test  delle 
ipotesi  ed  i  grafici  descrittivi  dei  dati  raccolti  al  fine  di  completare  la  valutazione 
dei singoli trattamenti. 
Presentazione ed impacchettamento 
L’argomento non è stato trattato in questo corso. () 
Goal 1 
Esperimento 1 
I  fattori  scelti  per  la  conduzione  dell’esperimento  sono:  la  conoscenza  delle 
tecniche  di  testing  e  la  conoscenza  dei  tool.  Le  rimanenti  variabili  indipendenti 
vengono  fissate  a  priori  su  livelli  noti.  La  variabile  dipendente  che  si  vuole 
osservare e studiare è: l’Effort assoluto standardizzato. 
Fattori    Variabile dipendente 
Conoscenza tecniche di testing  Effort assoluto standardizzato 
 
  135 
Conoscenza dei tool 
 
Il  quesito  di  ricerca  è:  “Nel  processo  eseguito,  la  conoscenza  delle  tecniche  e  dei 
tool migliora il trend dell’Effort assoluto impiegato per la pianificazione dei test di 
unità?”. Il numero di osservazioni è: 3. 
PRIMA OSSERVAZIONE 
TecnTest  Elenco 
ToolUtil  Elenco 
%exp  0,8 
%conTecn  0,4 
%conTools  0,4 
%domAppl  0,3 
StEffAssol  0,400  0,300  0,200  0,400  0,476  0,583  0,308  0,333  0,400  0,480 
%EffortRelat  0,500  0,429  0,333  0,510  0,553  0,538  0,444  0,444  0,500  0,600 
StNumCasiPian  20,000  20,000  30,000  15,000  21,000  24,000  26,000  30,000  25,000  25,000 
StEffAssolAtteso  0,2 
%EffortRelatAtteso  0,5 
StNumCasiPianAtteso  30 
SECONDA OSSERVAZIONE 
%exp  0,8 
%conTecn  0,4 
%conTools  0,9 
%domAppl  0,3 
StEffAssol  0,400  0,462  0,357  0,250  0,364  0,417  0,381  0,364  0,273  0,357 
%EffortRelat  0,513  0,548  0,472  0,405  0,486  0,470  0,504  0,467  0,460  0,466 
StNumCasiPian  20,000  26,000  28,000  24,000  22,000  24,000  21,000  22,000  22,000  28,000 
  136 
TERZA OSSERVAZIONE 
%exp  0,8 
%conTecn  0,9 
%conTools  0,4 
%domAppl  0,3 
StEffAssol  0,200  0,200  0,105  0,200  0,211  0,250  0,222  0,200  0,200  0,211 
%EffortRelat  0,500  0,500  0,467  0,636  0,607  0,508  0,526  0,500  0,545  0,663 
StNumCasiPian  24,000  26,000  22,000  24,000  22,000  20,000  21,000  28,000  22,000  28,000 
Test delle ipotesi 
L’esperimento  presenta  le  seguenti  caratteristiche:  non  parametrico,  più  di  due 
campioni indipendenti da confrontare. 
Alla  luce  di  queste  considerazioni,  il  test  delle  ipotesi  da  utilizzare  è:  Kruskal  – 
Wallis. 
Il  risultato  è:  rigetto  H0.  C’è  differenza  statisticamente  significativa  tra  le  tre 
osservazioni (per i tre trattamenti). Per conoscere quale dei trattamenti osservati 
offre i risultati attesi, utilizzo la statistica descrittiva (vedi sezione successiva). 
In  un  test  di  questo  tipo,  per  stabilire  l’esito  conclusivo  dell’indagine,  devo 
confrontare il valore H con quello Chi‐Quadro. Se H > Chi‐Quadro posso rigettare 
l’ipotesi nulla. 
In questo caso H = 17,00342 e Chi‐Quadro = 15,20. Per questa ragione rigetto H0. 
  137 
Statistica descrittiva 
Figura 36: Goal 1 ‐ Box Plot 1° esperimento 
Nella  figura  vengono  mostrati  3  box  plot  che  rappresentano  graficamente  la 
distribuzione  della  variabile  dipendente  (effort  assoluto  standardizzato).  La 
prima  osservazione  appare  uniforme  e  simmetrica.  Nella  seconda  osservazione 
(dopo aver agito sulla conoscenza dei tool) la mediana si abbassa leggermente, 
sono  presenti  due  outlier,  ma  si  è  ancora  troppo  lontani  dall’obiettivo  (valore 
atteso = 0,2). Nella terza osservazione (agendo sulla conoscenza delle tecniche) 
riusciamo ad ottenere risultati molto migliori. La mediana è in linea con il valore 
atteso,  anche  se  la  distribuzione  generale  è  di  poco  superiore.  Graficamente 
parlando, l’effetto del 3 trattamento è migliore rispetto al secondo. 
Esperimento 2 
Il  fattore  scelto  per  la  conduzione  dell’esperimento  è:  la  conoscenza  del  dominio 
applicativo.  Le  rimanenti  variabili  indipendenti  vengono  fissate  a  priori  su  livelli 
noti.  La  variabile  dipendente  che  si  vuole  osservare  e  studiare  è:  il  Numero 
standardizzato dei casi di test di unità pianificati. 
Numero standardizzato dei casi di 
Conoscenza del dominio applicativo 
  test di unità pianificati 
 
  138 
Il  quesito  di  ricerca  è:  “Nel  processo  eseguito,  la  conoscenza  del  dominio 
applicativo  influenza  il  trend  del  Numero  standardizzato  dei  casi  di  test  di  unità 
pianificati?”. Il numero di osservazioni è: 2. 
%exp  0,8 
%conTecn  0,9 
%conTools  0,4 
%domAppl  0,3 
StEffAssol  0,200  0,200  0,105  0,200  0,211  0,250  0,222  0,200  0,200  0,211 
%EffortRelat  0,500  0,500  0,467  0,636  0,607  0,508  0,526  0,500  0,545  0,663 
StNumCasiPian  24,000  26,000  22,000  24,000  22,000  20,000  21,000  28,000  22,000  28,000 
%exp  0,8 
%conTecn  0,9 
%conTools  0,4 
%domAppl  0,8 
StEffAssol  0,211  0,200  0,105  0,200  0,211  0,190  0,180  0,200  0,200  0,231 
%EffortRelat  0,513  0,500  0,467  0,636  0,607  0,439  0,474  0,500  0,545  0,683 
StNumCasiPian  23,000  27,000  20,000  22,000  24,000  22,000  25,000  24,000  24,000  26,000 
  139 
L’esperimento presenta le seguenti caratteristiche: non parametrico, due campioni 
indipendenti da confrontare. 
Alla  luce  di  queste  considerazioni,  il  test  delle  ipotesi  da  utilizzare  è:  Mann  – 
Whitney. 
Il risultato è: accetto H0. Non c’è differenza statisticamente significativa tra le due 
osservazioni (per i due trattamenti). 
verificare che il valore plevel sia inferiore a 0,005. 
In questo caso p‐level = 0,820596. Per questa ragione accetto H0. 
Pur  agendo  sulla  conoscenza  del  dominio  applicativo,  non  si  attestano  grandi 
differenze tra la prima e la seconda osservazione, in termini di numero di casi di 
test  di  unità  pianificati.  La  mediana  aumenta  leggermente  ma  rimane  molto 
lontana dall’obiettivo (valore atteso = 30). 
  140 
Goal 2 
Esperimento 1 
I  fattori  scelti  per  la  conduzione  dell’esperimento  sono:  la  conoscenza  delle 
tecniche  di  testing  e  la  conoscenza  dei  tool.  Le  rimanenti  variabili  indipendenti 
vengono  fissate  a  priori  su  livelli  noti.  La  variabile  dipendente  che  si  vuole 
osservare e studiare è: l’Effort assoluto standardizzato. 
Conoscenza tecniche di testing 
Effort assoluto standardizzato 
Conoscenza dei tool   
 
Il  quesito  di  ricerca  è:  “Nel  processo  eseguito,  la  conoscenza  delle  tecniche  e  dei 
tool migliora il trend dell’Effort assoluto impiegato per la pianificazione dei test di 
integrazione?”. Il numero di osservazioni è: 3. 
%exp  0,8 
%conTecn  0,4 
%conTools  0,4 
%domAppl  0,3 
StEffAssol  0,400  0,400  0,400  0,385  0,385  0,500  0,385  0,417  0,400  0,320 
%EffortRelat  0,500  0,571  0,667  0,490  0,447  0,462  0,556  0,556  0,500  0,400 
StNumCasiPian  20,000  20,000  20,000  26,000  26,000  20,000  26,000  24,000  25,000  25,000 
  141 
%exp  0,8 
%conTecn  0,4 
%conTools  0,9 
%domAppl  0,3 
StEffAssol  0,380  0,380  0,400  0,368  0,385  0,470  0,375  0,416  0,320  0,410 
%EffortRelat  0,487  0,452  0,528  0,595  0,514  0,530  0,496  0,533  0,540  0,534 
StNumCasiPian  25,000  25,000  21,000  21,000  24,000  23,000  23,000  20,000  29,000  26,000 
%exp  0,8 
%conTecn  0,9 
%conTools  0,4 
%domAppl  0,3 
StEffAssol  0,200  0,200  0,120  0,114  0,136  0,242  0,200  0,200  0,167  0,107 
%EffortRelat  0,500  0,500  0,533  0,364  0,393  0,492  0,474  0,500  0,455  0,337 
StNumCasiPian  21,000  22,000  25,000  26,000  21,000  22,000  27,000  27,000  24,000  23,000 
Wallis. 
  142 
In  questo  caso  H  =  19,91251  e  Chi‐Quadro  =  16,33929.  Per  questa  ragione 

rigetto H0. 
Nella  seconda  osservazione,  pur  avendo  agito  sulla  conoscenza  dei  tool,  l’effort 
assoluto  standardizzato  non  sembra  averne  subito  grandi  trasformazioni 
(outlier  inclusi).  Nella  terza  osservazione,  invece,  abbiamo  agito  sulla 
conoscenza  delle  tecniche  ed  il  risultato  è  significativo:  siamo  addirittura  al  di 
sotto  della  soglia  desiderata  (valore  atteso  =  0,20).  Possiamo  concludere  che  il 
terzo trattamento ha sortito gli effetti desiderati. 
Esperimento 2 
Il  fattore  scelto  per  la  conduzione  dell’esperimento  è:  la  conoscenza  del  dominio 
applicativo.  Le  rimanenti  variabili  indipendenti  vengono  fissate  a  priori  su  livelli 
  143 
noti.  La  variabile  dipendente  che  si  vuole  osservare  e  studiare  è:  il  Numero 
standardizzato dei casi di test di integrazione pianificati. 
Numero standardizzato dei casi di 
Conoscenza del dominio applicativo 
  test di integrazione pianificati 
 
Il  quesito  di  ricerca  è:  “Nel  processo  eseguito,  la  conoscenza  del  dominio 
applicativo  influenza  il  trend  del  Numero  standardizzato  dei  casi  di  test  di 
integrazione pianificati?”. Il numero di osservazioni è: 2. 
%exp  0,8 
%conTecn  0,9 
%conTools  0,4 
%domAppl  0,3 
StEffAssol  0,200  0,200  0,120  0,114  0,136  0,242  0,200  0,200  0,167  0,107 
%EffortRelat  0,500  0,500  0,533  0,364  0,393  0,492  0,474  0,500  0,455  0,337 
StNumCasiPian  21,000  22,000  25,000  26,000  21,000  22,000  27,000  27,000  24,000  23,000 
%exp  0,8 
%conTecn  0,9 
%conTools  0,4 
%domAppl  0,8 
StEffAssol  0,200  0,200  0,120  0,114  0,136  0,242  0,200  0,200  0,167  0,107 
  144 
%EffortRelat  0,487  0,500  0,533  0,364  0,393  0,561  0,526  0,500  0,455  0,317 
StNumCasiPian  40,000  35,000  50,000  35,000  44,000  33,000  40,000  40,000  36,000  56,000 
Whitney. 
Il  risultato  è:  rigetto  H0.  C’è  differenza  statisticamente  significativa  tra  le  due 
In questo caso p‐level = 0,000157. Per questa ragione rigetto H0. 
  145 
Aumentare la conoscenza del dominio applicativo, in questo caso ha aumentato 
significativamente il numero di casi di test di integrazione pianificati. Il risultato 
è  ottimo  dal  momento  che  la  mediana  si  attesta  su  un  valore  pari  a  40, 
nettamente al di sopra del nostro obiettivo (valore atteso = 30). 
Goal 3 
Esperimento 1 
I  fattori  scelti  per  la  conduzione  dell’esperimento  sono:  la  conoscenza  dei  tool  e 
l’insieme  dei  tool  utilizzati.  Le  rimanenti  variabili  indipendenti  vengono  fissate  a 
priori su livelli noti. La variabile dipendente che si vuole osservare e studiare è: 
l’Effort assoluto standardizzato. 
Insieme dei tool utilizzati   
 
Il quesito di ricerca è: “Nel processo eseguito, migliorare la conoscenza dei tool o 
l’insieme  dei  tool  utilizzati  migliora  il  trend  dell’Effort  assoluto  impiegato  per 
l’esecuzione dei test di unità?”. Il numero di osservazioni è: 3. 
%exp  0,8 
%conTools  0,5 
LOCStub  50 
StEffAssol  0,400  0,500  0,455  0,600  0,480  0,480  0,400  0,500  0,600  0,600 
%EffortRelat  0,500  0,500  0,500  0,500  0,500  0,500  0,500  0,500  0,500  0,500 
%CTPositivi  0,200  0,150  0,136  0,300  0,200  0,400  0,320  0,400  0,400  0,500 
%CTPositiviAtteso  0,6 
  146 
%exp  0,8 
%conTools  0,9 
LOCStub  50 
StEffAssol  0,420  0,500  0,600  0,600  0,420  0,400  0,433  0,500  0,393  0,600 
%EffortRelat  0,512  0,556  0,581  0,545  0,478  0,444  0,500  0,556  0,440  0,500 
%CTPositivi  0,136  0,300  0,200  0,336  0,320  0,150  0,136  0,300  0,500  0,400 
ToolUtil  Elenco aggiornato (si è introdotta innovazione) 
%exp  0,8 
%conTools  0,9 
LOCStub  50 
StEffAssol  0,190  0,167  0,214  0,143  0,192  0,190  0,196  0,150  0,190  0,150 
%EffortRelat  0,487  0,478  0,541  0,417  0,490  0,571  0,439  0,474  0,487  0,429 
%CTPositivi  0,400  0,320  0,400  0,400  0,500  0,136  0,300  0,200  0,336  0,320 
Wallis. 
  147 
verificare il valore H con quello Chi‐Quadro. Se H > Chi‐Quadro posso rigettare 
In  questo  caso  H  =  19,67806  e  Chi‐Quadro  =  13,92857.  Per  questa  ragione 

rigetto H0. 
Il secondo trattamento (aumentare la conoscenza dei tool) non ci restituisce una 
diminuzione  significativa  dell’effort  assoluto  standardizzato.  Al  contrario,  nel 
terzo trattamento (aumentando i tool utilizzati) riusciamo ad ottenere un’ottima 
distribuzione  dei  valori  che  si  attestano  mediamente  sotto  il  nostro  obiettivo 
(valore atteso = 0,2). 
Esperimento 2 
Il  fattore  scelto  per  la  conduzione  dell’esperimento  è:  la  grandezza  degli  stub.  Le 
rimanenti  variabili  indipendenti  vengono  fissate  a  priori  su  livelli  noti.  La 
  148 
variabile dipendente che si vuole osservare e studiare è: la Percentuale di casi di 
test di unità positivi alla prima esecuzione. 
Percentuale di casi di test di unità 
Grandezza degli stub 
  positivi alla prima esecuzione 
 
Il  quesito  di  ricerca  è:  “Nel  processo  eseguito,  la  grandezza  degli  stub  influisce 
sulla percentuale di casi di test di unità positivi alla prima esecuzione?”. Il numero 
di osservazioni è: 2. 
%exp  0,8 
%conTools  0,9 
LOCStub  50 
StEffAssol  0,190  0,167  0,214  0,143  0,192  0,190  0,196  0,150  0,190  0,150 
%EffortRelat  0,487  0,478  0,541  0,417  0,490  0,571  0,439  0,474  0,487  0,429 
%CTPositivi  0,400  0,320  0,400  0,400  0,500  0,136  0,300  0,200  0,336  0,320 
%exp  0,8 
%conTools  0,9 
LOCStub  70 
StEffAssol  0,200  0,197  0,204  0,193  0,192  0,200  0,206  0,200  0,200  0,200 
%EffortRelat  0,488  0,411  0,529  0,479  0,478  0,406  0,452  0,429  0,488  0,488 
%CTPositivi  0,700  0,625  0,643  0,714  0,769  0,733  0,706  0,667  0,686  0,700 
  149 
Whitney. 
La  seconda  osservazione  (dopo  aver  aumentato  la  grandezza  degli  stub) 
presenta  una  distribuzione  omogenea  dei  dati,  mediamente  al  di  sopra  delle 
aspettative.  La  mediana  si  attesta  sul  valore  di  0,7:  ottimo  rispetto  al  nostro 
obiettivo (valore atteso = 0,6). 
  150 
Il  fatto  che  l’obiettivo  del  singolo  esperimento  sia  raggiunto,  non  significa  che  la 
situazione  sia  globalmente  vantaggiosa.  Come  detto  anche  nel  GQM  (Baseline 
Impact)  del  Goal  3,  aumentare  la  dimensione  degli  stub  comporta  l’aumento 
dell’effort.  Ciò  significa  che  pur  avendo  ottenuto  un  buon  risultato  su  un  fattore, 
potremmo  sempre  registrare  risultati  non  buoni  per  altre  variabili.  La  situazione 
che si verifica in questo caso è mostrata in figura. 
Figura 42: Goal 3 ‐ Box Plot 2° esperimento ‐ incidenza sull'effort 
Il  risultato  dell’aumento  della  grandezza  degli  stub  di  unità  ha  provocato  un 
aumento dell’effort assoluto standardizzato medio. Così facendo, quest’ultimo va 
oltre  la  soglia  prevista  (valore  atteso  =  0,2).  In  questo  caso  il  management 
dell’organizzazione,  dovrà  ponderare  una  scelta:  conviene  aumentare  la 
percentuale di test positivi a scapito dell’aumento dell’effort?  
Goal 4 
Esperimento 1 
I  fattori  scelti  per  la  conduzione  dell’esperimento  sono:  la  conoscenza  dei  tool  e 
l’insieme  dei  tool  utilizzati.  Le  rimanenti  variabili  indipendenti  vengono  fissate  a 
priori su livelli noti. La variabile dipendente che si vuole osservare e studiare è: 
l’Effort assoluto standardizzato. 
  151 
Insieme dei tool utilizzati   
 
Il quesito di ricerca è: “Nel processo eseguito, migliorare la conoscenza dei tool o 
l’insieme  dei  tool  utilizzati  migliora  il  trend  dell’Effort  assoluto  impiegato  per 
l’esecuzione dei test di integrazione?”. Il numero di osservazioni è: 3. 
%exp  0,8 
%conTools  0,5 
LOCStub  50 
StEffAssol  0,400  0,500  0,455  0,600  0,480  0,480  0,400  0,500  0,600  0,600 
%EffortRelat  0,500  0,500  0,500  0,500  0,500  0,500  0,500  0,500  0,500  0,500 
%CTPositivi  0,200  0,150  0,136  0,300  0,200  0,400  0,320  0,400  0,400  0,500 
%exp  0,8 
%conTools  0,9 
LOCStub  50 
StEffAssol  0,400  0,400  0,433  0,500  0,458  0,500  0,433  0,400  0,500  0,600 
%EffortRelat  0,488  0,444  0,419  0,455  0,522  0,556  0,500  0,444  0,560  0,500 
%CTPositivi  0,200  0,150  0,136  0,300  0,200  0,400  0,320  0,400  0,400  0,500 
  152 
%exp  0,8 
%conTools  0,9 
LOCStub  50 
StEffAssol  0,200  0,182  0,182  0,200  0,200  0,143  0,250  0,167  0,200  0,200 
%EffortRelat  0,513  0,522  0,459  0,583  0,510  0,429  0,561  0,526  0,513  0,571 
%CTPositivi  0,300  0,200  0,336  0,320  0,269  0,200  0,300  0,250  0,250  0,700 
Wallis. 
In questo caso H = 20,15244 e Chi‐Quadro = 15,20. Per questa ragione rigetto H0. 
  153 
Il  secondo  trattamento  (aumentare  la  conoscenza  dei  tool)  non  restituisce  una 
diminuzione  significativa  dell’effort  assoluto  standardizzato.  Al  contrario,  nel 
terzo trattamento (aumentando i tool utilizzati) riusciamo ad ottenere un’ottima 
distribuzione dei valori che sono in linea con il nostro obiettivo (valore atteso = 
0,2). 
Esperimento 2 
Il  fattore  scelto  per  la  conduzione  dell’esperimento  è:  la  grandezza  degli  stub.  Le 
rimanenti  variabili  indipendenti  vengono  fissate  a  priori  su  livelli  noti.  La 
variabile dipendente che si vuole osservare e studiare è: la Percentuale di casi di 
test di integrazione positivi alla prima esecuzione. 
Percentuale di casi di test di 
Grandezza degli stub  integrazione positivi alla prima 
  esecuzione 
 
Il  quesito  di  ricerca  è:  “Nel  processo  eseguito,  la  grandezza  degli  stub  influisce 
sulla  percentuale  di  casi  di  test  di  integrazione  positivi  alla  prima  esecuzione?”.  Il 
numero di osservazioni è: 2. 
  154 
%exp  0,8 
%conTools  0,9 
LOCStub  50 
StEffAssol  0,200  0,182  0,182  0,200  0,200  0,143  0,250  0,167  0,200  0,200 
%EffortRelat  0,513  0,522  0,459  0,583  0,510  0,429  0,561  0,526  0,513  0,571 
%CTPositivi  0,300  0,200  0,336  0,320  0,269  0,200  0,300  0,250  0,250  0,700 
%exp  0,8 
%conTools  0,9 
LOCStub  70 
StEffAssol  0,210  0,282  0,182  0,210  0,210  0,293  0,250  0,267  0,210  0,210 
%EffortRelat  0,512  0,589  0,471  0,521  0,522  0,594  0,548  0,571  0,512  0,512 
%CTPositivi  0,800  0,591  0,727  0,750  0,600  0,643  0,667  0,667  0,743  0,733 
Whitney. 
  155 
Nella  seconda  osservazione  i  dati  sono  perfettamente  simmetrici  ed 

omogeneamente  distribuiti.  Aumentare  la  grandezza  degli  stub  di  integrazione 
ha  migliorato  notevolmente  la  percentuale  dei  casi  di  test  di  integrazione 
positivi.  Il  livello  raggiunto  è  migliore  di  quello  preventivato  (valore  atteso  = 
0,6). 
Ricontrolliamo l’impatto che il miglioramento della percentuale dei casi di test di 
integrazione positivi ha avuto sull’effort assoluto standardizzato. 
  156 
 
Figura 45: Goal 4 ‐ Box Plot 2° esperimento ‐ incidenza sull'effort 
In questo caso, diversamente dal goal precedente, il risultato dell’aumento della 
grandezza  degli  stub  di  integrazione  ha  provocato  un  aumento  accettabile 
dell’effort  assoluto  standardizzato  medio.  In  questo  caso  il  management 
dell’organizzazione, non dovrà ponderare alcuna scelta. 
  157 
Appendice 
  158 
 
A. Metodologia di lavoro 
Introduzione 
La  disciplina  dell’ingegneria  del  software  annovera  differenti  metodi  e  modelli  di 
sviluppo. In generale si suole suddividerli in 3 grandi aree: 
• metodologie pesanti (modello a cascata); 
• metodologie iterative (modello a spirale); 
• metodologie agili. 
Delle  tre  sopra  citate,  le  metodologie  agili  stanno  riscuotendo  sempre  maggiore 
successo. E’ doveroso affermare, tuttavia, che la scelta della metodologia non è del 
tutto  arbitraria:  esistono  casi  che  si  prestano  ad  essere  risolti  meglio  con  una 
metodologia  piuttosto  che  con  un’altra.  Un  buon  ingegnere  del  software  deve 
essere  in  grado  di  scegliere  quella  più  consona  al  proprio  problema.  Una  delle 
pratiche agili più utilizzate e note è proprio quella del Pair Programming. 
Il Pair Programming 
Il  Pair  Programming  prevede  che  lo  sviluppo  di  un  progetto  venga  affrontato  da 
due attori: uno accanto all’altro lavorando sulla stessa macchina. Il primo soggetto 
prende il controllo dell’elaboratore ed inizia lo sviluppo vero e proprio, il secondo 
si concentra su attività che mirano ad obiettivi più lontani del mero sviluppo. Con 
una frequenza prefissata (solitamente 1 ora) gli attori invertono i propri ruoli. 
Chi  scrive,  solitamente  è  chiamato  driver,  mentre  l’altro  è  chiamato  navigator.  In 
italiano è più corretto parlare, rispettivamente, di tattico e strategico. Rende più il 
senso.  In  realtà  l’obiettivo  di  chi  scrive  (driver)  è  quello  di  risolvere  problemi 
intermedi  adoperando  una  serie  di  strumenti  concreti.  L’obiettivo  della  seconda 
figura  (navigator)  è  più  lontano  e  viene  perseguito  utilizzando  la  propria 
esperienza. 
  159 
Facciamo  un  esempio.  Nel  momento  in  cui  il  mio  collega  prendeva  possesso  del 
computer,  il  suo  obiettivo  era  la  realizzazione  del  modello  di  processo  con 
Enterprise  Architect  piuttosto  che  la  compilazione  di  un  GQM  tramite  Microsoft 
Word.  Obiettivi  intermedi  (il  modello  di  processo  è  solo  una  parte 
dell’esercitazione)  perseguiti  con  strumenti  concreti  (i  diversi  tool).  Il  mio 
obiettivo,  come  navigator,  era  quello  di  guardare  oltre,  consultando  le  successive 
slide, ascoltando il tutor alla ricerca di indizi ed informazioni che mi consentissero 
di “correggere il tiro” del mio driver. 
Anche se apparentemente sembra che due persone risolvano nello stesso tempo la 
metà  dei  problemi,  in  realtà  lo  scopo  di  questa  metodologia  non  è  quello  di 
raddoppiare  l’efficienza  dei  due  operatori,  bensì  quello  di  dimezzare  la  loro 
inefficienza. 
Cosa significa?  Molto spesso, lavorando in autonomia si è esposti ad una serie di 
rischi:  vicoli  ciechi,  ostinazione  nell’utilizzo  di  alcuni  tecnicismi  di  sterile 
produttività ed anche incapacità di riuscire a vedere la soluzione a portata di mano 
per  distrazione  o  stanchezza.  Lavorare  in  coppia  riduce  la  probabilità  che  uno  di 
questi fattori si manifesti e di conseguenza aumenta la solidità del progetto. 
Un  miglioramento  in  termini  di  solidità,  diminuisce  sempre  il  tempo  speso  nella 
fase  di  debugging  che  è  un’attività  estremamente  costosa.  Il  Pair  Programming 
consente di concentrarsi meglio sullo sviluppo. 
Tutto  il  lavoro  svolto  in  aula  è  stato  quasi  completamente  eseguito  utilizzando  la 
suddetta  metodologia.  Per  questa  ragione,  avendola  provata  in  prima  persona, 
seguirò nell’indicazione dei vantaggi e degli svantaggi che tale approccio comporta. 
A.1 Vantaggi 
Di seguito riporto i benefici che ho apprezzato utilizzando tale tecnica. 
• Facilitazione  nell’apprendimento:  lavorare  in  due  facilita  lo  scambio  (e 

l’acquisizione)  di  conoscenza.  Il  vincolo  di  permutazione  dei  ruoli  ne 
garantisce l’efficacia.  
• Risoluzione  più  veloce  dei  problemi:  sovente  capita  che  il  problema 
insormontabile per il driver sia di facile risoluzione per il navigator. 
  160 
• Aumento  del  coinvolgimento  emotivo:  il  driver  nutre  maggiore  fiducia  nei 
confronti  del  suo  operato.  Il  navigator  percepisce  la  sicurezza  del  driver 
come una conferma alla sua capacità di supervisione. 
• Diminuzione  della  propensione  ad  interrompere  il  lavoro:  la  probabilità  che 
in autonomia si scelga di fermarsi per una pausa è più alta che in gruppi di 
due persone. Il coinvolgimento emotivo di uno dei due, sprona a continuare 
anche l’altro attore. 
Quelli  che  seguono  sono  altri  vantaggi  che  non  ho  avuto  modo  di  sperimentare 
durante le lezioni: ritengo che possano essere d’interesse per fini aziendali più che 
per fini didattici. 
• Diminuzione  dei  costi  di  debugging:  l’individuazione  dei  bug  è  un’attività 

costosa che  viene considerevolmente ridotta; 
• Diminuzione  dei  rischi  di  gestione:  nel  caso  in  cui  un  attore  abbandoni  il 
progetto,  la  conoscenza  fin  lì  acquisita  non  viene  persa  poiché 
precedentemente condivisa con l’altra parte del team; 
• Diminuzione del numero di workstation richieste: se i due attori utilizzassero 
la  stessa  workstation,  il  numero  di  computer  richiesti  diverrebbe  pari  alla 
metà. 
A.2 Svantaggi 
Come  ogni  metodologia  di  lavoro,  il  Pair  Programming  presenta  una  serie  di 
inconvenienti prevalentemente ascrivibili alla sfera dei rapporti sociali. 
• Frustrazione dell’attore esperto: solitamente si affianca un attore capace ad 
uno  che  lo  è  un  po’  meno.  L’esperto  non  avverte  nuovi  stimoli  e  tende  ad 
annoiarsi. 
• Conflitti  generati  dal  contraddittorio:  non  tutti  i  soggetti  sono  inclini  ad 
essere  contraddetti.  Questa  tecnica  non  preserva  dal  rischio  di  conflitti 
personali  visto  che  è  essenziale  il  confronto.  A  volte  capita  che  la 
personalità  più  forte  tenda  ad  imporre  la  propria  idea  a  prescindere  dal 
fatto che essa sia giusta o meno; 
  161 
• Intimidazione:  l’attore  meno  esperto  tende  ad  accettare  passivamente  le 
decisioni  dell’attore  più  esperto.  E’  opportuno,  comporre  team  nei  quali  la 
disparità di conoscenza non sia eccessivamente grande; 
• Costi:  pur  essendo  dimezzato  il  numero  di  workstation  da  acquistare  è 
doppio quello del personale da pagare. Fino a che l’efficacia del metodo non 
diventa doppia rispetto al lavoro in autonomia, l’azienda ci rimette; 
• Un  solo  computer  può  non  bastare:  è  molto  più  conveniente  che  anche  il 
navigator  disponga  di  una  propria  postazione  (magari  meno  performante 
della  workstation).  Il  vantaggio  è  quello  di  poter  ricercare  informazioni  in 
tempi ridotti. Dopo le prime esercitazioni, io ed il mio collega, sentivamo il 
bisogno di due computer (anche solo per leggere le slide di esercitazione). Il 
computer di lavoro è rimasto unico, ma abbiamo aggiunto un computer che 
ci garantisse le funzionalità basilari di ufficio (leggere e scrivere documenti, 
visualizzare grafici ed immagini): un portatile in più. 
B. Aula virtuale 
Durante  le  esercitazioni  abbiamo  utilizzato  uno  strumento  per  la  creazione  e 
gestione di un’aula didattica virtuale: ITALC. I computer di ciascun team sono stati 
collegati assieme in una rete LAN e su ciascuno di essi è stato installato il software 
in  versione  client,  mentre  sulla  postazione  del  tutor  è  stata  installata  la  versione 
server. 
Grazie a questa applicazione, il tutor ha potuto tenere sotto controllo tutti i nostri 
computer.  Egli,  infatti,  ha  avuto  la  possibilità  di  visualizzare  in  una  finestra  tutto 
quello che visualizzavano i nostri display. 
Le possibilità del software sono vaste. Oltre al controllo delle postazioni, il tutor ha 
potuto  decidere  di  condividere  con  gli  altri  (attraverso  l’uso  di  un  proiettore)  la 
schermata di un computer in particolare. Questo strumento si è rivelato utile per 
condividere con l’aula comportamenti positivi e negativi. 
Il  tutor,  dalla  sua  postazione,  osserva  come  i  diversi  team  procedono  nello 
svolgimento di un esercizio e quando lo ritiene opportuno condivide il display con 
l’intera aula, commentando il modo di procedere del team. 
Il  commento  didattico  può  essere  positivo  o  negativo.  Nel  primo  caso  il  tutor 
richiama  l’attenzione  dell’aula  per  mostrare  a  tutti  come  svolgere  correttamente 
  162 
un  esercizio  o  anche  un  singolo  passaggio.  Nel  secondo  caso  il  tutor  pone 
all’attenzione di tutta la classe, un errore diffuso, agevolando ed incoraggiando gli 
studenti a non ricommetterlo. 
B.1 Vantaggi 
L’aula virtuale presenta una serie di vantaggi indiscutibili. 
• Mantiene alto il livello di attenzione degli studenti: utilizzare l’aula virtuale è 
divertente.  Lo  studente  è  al  centro  della  lezione  in  ogni  momento.  Il  fatto 
che  venga  monitorato/seguito  lo  rende  sicuro  e  motivato.  Molto  spesso, 
durante  le  esercitazioni,  gli  studenti  chiedevano  al  tutor  di  condividere  il 
proprio monitor per porre delle domande; 
• Agevola  l’attività  didattica  del  tutor:  il  tutor  ha  la  possibilità  di  fondere 
assieme  teoria  e  pratica  in  maniera  semplice  ed  immediata. 
L’apprendimento  è  in  primo  luogo  pratico,  pur  stimolando  gli  studenti  a 
domande e curiosità che implicano, molto spesso, una spiegazione teorica. A 
quel  punto  il  tutor  può  decidere  di  mostrare  diapositive  sull’argomento 
oppure fornire dei documenti digitali alle postazioni; 
• Pone  lo  studente  al  centro  dell’esercitazione:  il  tutor  può  decidere  di  far 
eseguire  un  esercizio  ad  un  team  in  particolare  limitandosi  a  commentare 
errori  o  comportamenti  positivi. Nelle  nostre  esercitazioni,  sovente  veniva 
utilizzata  questa  tecnica.  Il  risultato  è  ottimo  didatticamente  perché 
consente al docente di porre immediatamente rimedio agli errori “classici” 
(quelli più diffusi e copiosi). 
In particolare, il software utilizzato presenta altri interessanti pregi. 
• Open  Source:  è  un  software  libero  e  per  questa  ragione  non  è  necessario 
pagare  licenze  per  il  suo  utilizzo.  Il  codice  sorgente  è  liberamente 
disponibile ed è pertanto possibile modificarlo e migliorarlo in totale libertà 
rispettando i termini di licenza GNU GPL; 
• Multipiattaforma:  il  software  è  progettato  per  essere  utilizzato  su  diversi 

sistemi operativi (Windows 2000/XP/Vista e Linux). Il tutor può utilizzare 
un  particolare  sistema  operativo  per  la  macchina  server  senza  dover 
utilizzare lo stesso dei client e viceversa. 
  163 
B.2 Svantaggi 
L’utilizzo  dell’aula  virtuale  ha  comportato  alcuni  svantaggi  legati,  in  particolar 
modo, al software utilizzato ed alla capacità di traffico della rete. 
• Problemi  del  software:  in  alcuni  casi  il  software  ha  presentato  problemi  di 
installazione: in modo particolare su quelli con sistema operativo Windows 
Vista.  Altre  volte,  pur  essendo  installato  correttamente,  il  software  non 
aggiornava la schermata del computer selezionato dal tutor costringendo il 
tutor  ad  aprire  e  chiudere  la  relativa  finestra;  Nella  maggior  parte  delle 
lezioni  è  capitato  che  si  siano  verificati  problemi  di  riconoscimento  dei 
computer connessi alla rete o connessi alla piattaforma ITALC; 
• Congestione  della  rete:  la  rete  utilizzata  durante  le  esercitazioni  conta  una 
media  di  30  computer  connessi.  Ogni  volta  che  il  tutor  condivideva  un 
particolare  documento,  la  rete  non  riusciva  a  gestire  il  traffico  e  di 
conseguenza i documenti non potevano essere scaricati. 
C. Tools 
Durante  le  esercitazioni  sono  stati  introdotti  diversi  tool  a  seconda  delle  diverse 
problematiche  affrontate.  I  tool  utilizzati  sono:  Enterprise  Architect,  TABULA  e 
STATISTICA. 
C.1 Enterprise Architect 
Enterprise Architect è un software di modellazione UML estremamente flessibile e 
completo.  Durante  le  esercitazioni,  in  particolare,  abbiamo  utilizzato 
quest’applicazione per la modellazione di processi FSPSPEM based. 
  164 
 
Figura 46: Schermata di Enterprise Architect 5.0 
Lo  strumento  è  estremamente  efficace.  A  prima  vista  può  apparire  complesso  e 

difficile  da  utilizzare  ma  dopo  aver  disegnato  i  primi  modelli  ed  inserito  i  primi 
manufatti diventa facile e veloce. 
C.1.1 Vantaggi e svantaggi 
Il principale vantaggio di Enterprise Architect è il set di diagrammi rappresentabili 
(forse  troppi  a  tal  punto  da  renderlo  complesso)  unitamente  alla  possibilità  di 
inventarne  di  nuovi  (come  nel  caso  di  FSP‐SPEM).  Purtroppo  il  software  non  è 
gratuito e durante il corso abbiamo sperimentato, nostro malgrado, l’insufficienza 
del periodo di prova (30 giorni). Il tool per l’esportazione della documentazione in 
formato  Microsoft  Word  è  risultato  poco  flessibile  in  termini  di  layout  del 
documento finale producendo documenti poco leggibili e mal formattati. 
La versione utilizzata è la 5, dal momento che le versioni più nuove (nel momento 
in cui scrivo è disponibile la 7) non supportano al meglio il template di FSPSPEM 
fornitoci dal tutor. 
Un  difetto  particolarmente  sentito  di  questo  software  è  la  sua  natura  mono‐
piattaforma: esso può essere installato unicamente su Microsoft Windows XP/Vista. 
  165 
C.2 TABULA 
TABULA  è  un’applicazione  web  a  supporto  della  realizzazione,  manutenzione  e 

verifica di tavole di decisione realizzata dal SERLAB di Bari. 
Figura 47: Schermata di TABULA 
Oltre  alla  rappresentazione  dell’insieme  di  regole  che  compongono  una  tavola,  lo 
strumento in esame agevola (dovrebbe) l’utente nella fase di Verifica e Validazione 
della  stessa.  Supporta  l’import/export  in  formato  XML  ed  è  multi‐utente:  ciascun 
utente è registrato con credenziali univoche che gli consentono l’accesso esclusivo 
alla propria area di lavoro. 
Durante  le  esercitazioni  abbiamo  utilizzato  questo  strumento  per  la  definizione 
delle  tavole  di  decisione  scaturite  dalla  progettazione  del  GQM.  Ogni  gruppo  ha 
creato  una  propria  area  di  lavoro,  registrandosi  all’applicazione,  nella  quale  ha 
potuto procedere alla realizzazione delle tavole. 
TABULA  è  uno  strumento  poco  maturo.  Sebbene,  nelle  intenzioni,  faccia 
risparmiare  molto  tempo  rispetto  alla  realizzazione  manuale  delle  tavole,  nel 
nostro caso non ci ha fornito il vantaggio atteso. Alcune funzionalità sono ancora in 
fase  di  sviluppo  (esportazione  delle  tabelle  in  formato  .xls)  e  durante  le 
  166 
esercitazioni  molti  gruppi  hanno  perso  il  loro  lavoro  a  causa  della  procedura  di 
esportazione in formato XML.  
L’interfaccia  grafica  è  minimalista  ed  avida  di  indicazioni  testuali.  Le  icone 
associate a molti pulsanti non rendono l’idea della funzionalità che rappresentano. 
Attualmente  non  è  presente  la  funzionalità  più  importante:  l’esportazione  di 
ciascuna tabella sotto forma di immagine digitale. La mancanza di questa feature ci 
ha costretti a copiare ed incollare i dati in un foglio elettronico Microsoft Excel ed 
impazzire con le formattazioni grafiche del documento finale. 
Il software, nell’esecuzione di operazioni banali quali la modifica di una condizione 
piuttosto  che  di  una  regola,  si  aggiorna  all’interno  di  una  piccola  porzione  di 
interfaccia. Questo problema determina un errore a livello server che ci costringe 
ad  effettuare  ogni  volta  l’accesso  con  password.  Le  prime  volte,  diversi  gruppi 
hanno anche perso il loro lavoro e sono stati costretti a ripartire da zero. 
Una caratteristica indubbiamente positiva è che trattandosi di una webapplication 
è utilizzabile da qualsiasi tipo di sistema operativo. Anche in questo caso, però, si 
sono  riscontrati  dei  problemi  di  compatibilità  con  browser  diversi  da  Mozilla 
Firefox: Microsoft Internet Explorer e Safari. 
C.3 STATISTICA 
Per  l’analisi  statistica  dei  dati  rilevati  abbiamo  utilizzato  un  tool  statistico: 
STATISTICA. Il software presenta un’interfaccia chiara e minimalista in stile Foglio 
Elettronico  all’interno  della  quale  copiare  le  serie  di  valori  rilevati  ed  ordinare  il 
calcolo dei vari indicatori numerici e grafici. 
  167 
 
Figura 48: Schermata di STATISTICA 
Il  tool  non  ha  presentato  problemi  di  nessun  tipo  e  si  è  dimostrato  efficace  ed 
efficiente.  Utilizzare  un  software  piuttosto  che  carta  e  penna  si  è  rivelato  facile  e 
veloce.  In  poco  tempo  siamo  stati  in  grado  di  produrre  tutti  i  rapporti  di  cui 
necessitavamo. 
D. Effort speso 
Effort speso in generale 
Di  seguito  riporto  una  breve  tabella  riepilogativa  che  illustra  il  tempo  speso 
individualmente nella differenti attività necessarie alla consegna del caso di studio. 
ATTIVITA’  ORE  DESCRIZIONE 
Lezioni  Trattasi di 11 lezioni frontali da 3 ore ciascuna. 
34 
Laboratorio  L’ultima di queste è durata 4 ore.  
Studio  30  Per ogni lezione di laboratorio ho stimato 
  168 
individuale  un’ora di studio individuale. Si tratta di una 
stima. Nel primo periodo si sono trattate 
tematiche a me già note e per questo motivo il 
tempo speso individualmente è stato 
sensibilmente inferiore. 
La redazione del seguente documento ha 
occupato la maggior parte dell’impegno 
Redazione della 
58  individuale dal momento che coinvolge 
documentazione 
concetti di teoria, lezioni di laboratorio e 
risoluzione di problemi legati all’uso dei tool. 
 
Effort speso per i tool 
Di  seguito  riporto  una  tabella  riepilogativa  circa  l’effort  speso  per  ciascun  tool 
utilizzato. 
ATTIVITA’  ORE  DESCRIZIONE 
Avevo già avuto modo di utilizzare il tool per la 
realizzazione di modelli di proceso (ed anche per 
Enterprise Architect  0 
produrre documentazione UML) nel corso di Modelli 
per la qualità del software. 
E’ un’applicazione molto facile da imparare ad usare 
TABULA  1*  dal momento che dispone di pochissime 
funzionalità. 
Sebbene sia uno strumento estremamente versatile, 
STATISTICA  1  ho impiegato poco ad impararne le funzionalità a 
me utili.  
iTALC  0  Dopo averlo installato, non c’è nulla da apprendere. 
 
* L’instabilità dell’applicazione ha determinato un consumo di tempo maggiore del 
previsto  per  la  costruzione  delle  tavole  di  decisione.  Andrebbe  sostituito  o 
migliorato al più presto. 
  169 
Bibliografia 
(2009). "Pair Programming ‐ Wikipedia, the free encyclopedia." from 
http://en.wikipedia.org/wiki/Pair_programming. 
(2009). "Medodologia Agile ‐ Wikipedia." from 
http://it.wikipedia.org/wiki/Metodologia_agile#Pratiche. 
(2009). "GQM ‐ Wikipedia, the free encyclopedia." from 
http://en.wikipedia.org/wiki/GQM. 
C.Wohlin, P. R., M.Höst, M.C.Ohlsson, B.Regnell, A.Wesslén (2000). Experimentation 
in software engineering: An Introduction, Kluwer Academic Publishers. 
N.Fenton, S. L. P. (1996). Software Metrics: A rigorous & practical approach, 
International Thomson Computer Press. 
R. van Solingen, E. B. (1999). The Goal/Question/Metric Method: a practical guide 
for quality improvement and software development, McGraw‐Hill International. 
Romei, J. (2008). "Solidi ma agili con il pair programming." from 
http://www.sviluppoagile.it/solidi‐agili‐con‐pair‐programming. 
S.K.Kachigan (1986). Statistical analysis: an interdisciplinary introduction to 
unvariate & multivariate methods. New York, Radius Press. 
T.DeMarco (1982). Controlling software projects. New York, Yourdon Press. 
V.R.Basili, G. C., H.D.Rombach (1994). Goal Question Metrics Paradigm. Wiley. I: 
528‐532. 
William Laurie, K. R. (2003). Pair Programming Illuminated, Addison‐Wesley. 
  170 
Allegati 
Alla documentazione si allega: 
• CD  contenente  i  file  di  progetto  dei  diversi  software  utilizzati  per  la 
realizzazione di questa trattazione. 
  171 
 

Metodi Sperimentali Per La Produzione Del Software

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Metodi Sperimentali Per La Produzione Del Software

Caricato da

Copyright:

Formati disponibili

UNIVERSITÀ DEGLI STUDI DI BARI

Goal ......................................................................................................................................... 66

Capitolo 3: Simulazione ed analisi dei dati rilevati ........................ 130

Appendice ..................................................................................................... 158

Allegati ........................................................................................................... 171

Figura 1: STEP 1 ‐ Traccia ................................................................................................... 10

Figura 3: STEP 2 ‐ Traccia ................................................................................................... 15

Figura 4: STEP 2 ‐ Attori ...................................................................................................... 17

Figura 6: STEP 2 ‐ Piano, Esecuzione e Debugging dei casi di test .................... 21

Figura 7: STEP 3 ‐ Traccia ................................................................................................... 23

Figura 8: STEP 3 ‐ Attori ...................................................................................................... 25

Figura 9: STEP 3 ‐ Manufatti “Piano_dei_casi_di_test” ............................................ 27

Figura 10: Esempio di errore di consistenza globale dei manufatti ................. 27

Figura 11: STEP 3 ‐ Test e Debugging ............................................................................ 29

Figura 12: STEP 3 ‐ Piano, Esecuzione e Debugging dei casi di test ................. 30

Figura 19: STEP 4 ‐ Test e Debugging ............................................................................ 40

Figura 20: STEP 4 ‐ Piano, Esecuzione e Debugging dei casi di test ................. 41

Figura 21: STEP 4 ‐ Pianificazione test di unità e di integrazione ..................... 42

Figura 22: STEP 4 ‐ Pianificazione test d'unità .......................................................... 44

Figura 25: STEP 5 ‐ Manufatti "Piano_dei_casi_di_test" ......................................... 52

Figura 26: STEP 5 – Manufatti “Piano_dei_casi_di_test_d'unità” ........................ 53

Figura 28: STEP 5 ‐ Test e Debugging ............................................................................ 56

Figura 29: STEP 5 ‐ Piano, Esecuzione e Debugging dei casi di test ................. 57

Figura 30: STEP 5 ‐ Pianificazione test di unità e d’integrazione ...................... 58

Figura 32: STEP 5 ‐ Esecuzione dei casi di test .......................................................... 63

Figura 33: Struttura gerarchica del modello GQM ................................................... 66

Scopo di questa trattazione è illustrare metodologie, tecniche e strumenti propri

Lo stereotipo WorkProduct indica un particolare manufatto caratterizzato da

Lo stereotipo Document indica un particolare manufatto caratterizzato

ProcessPerformer e ProcessRole sono diversi poiché si pongono a livelli della

Quando presenti, gli accorgimenti migliorativi (che migliorano il processo)

PRODURRE Piano_casi_di_test_black_box USANDO

In questo caso l’attività base, utilizzando il manufatto Classi_di_equivalenza

PRODURRE Classi_di_equivalenza USANDO

PRODURRE Cammini_indipendenti USANDO Codice_sorgente

PRODURRE Casi_di_test_white_box USANDO

PRODURRE Lista_delle_classi USANDO Matrice_di_cross

PRODURRE Matrice_di_cross USANDO Modello_delle_Classi

Il manufatto Report_dei_casi_di_test è stato dettagliato. Esso è prodotto dalla

Abbiamo inserito il manufatto Stub_Test_di_Integrazione necessario alla

Abbiamo inserito il manufatto Stub_Test_di_Integrazione necessario alla

PRODURRE Piano_casi_di_test_black_box USANDO

PRODURRE Classi_di_equivalenza USANDO

PRODURRE Cammini_indipendenti USANDO Codice_sorgente

PRODURRE Casi_di_test_white_box USANDO

PRODURRE Matrice_di_cross USANDO Modello_delle_Classi

“You cannot control what you cannot measure”

Nel capitolo precedente si è affrontata la problematica relativa alla

Question Metric Etichetta Descrizione

Q1.1 M1.1.1 TecnTestU Tecniche di testing utilizzate per il

M1.7.2 NumCTU Numero di casi di test di unità

Question Metric Etichetta Descrizione

Question Metric Etichetta Descrizione

Q3.1 M3.1.1 ToolsEsecTest Tool utilizzati per l’esecuzione dei

M1.3.2 %DistrExpTest Distribuzione in percentuale dei

M1.3.3 %PersExpTest Percentuale di persone del team

Q3.2 M3.2.1 ConToolsUtilEsecTU Conoscenza di un individuo del team

M3.2.2 %DistrConToolsUtilE Distribuzione in percentuale dei

M3.2.3 %PersExpToolsUtilEs Percentuale di persone del team

Q3.3 M3.3.1 LOCStubFitzU Dimensione in LOC degli stub di unità

M3.3.2 NClasStubFitzU Numero classi simulate da stub di

M3.3.3 StLOCStubFitzU Dimensione standardizzata in LOC

Q3.4 M3.4.1 TEsecCTU Ore/uomo per l’esecuzione dei casi di

UNIVERSITÀ DEGLI STUDI DI BARI 

Goal ......................................................................................................................................... 66 

Capitolo 3: Simulazione ed analisi dei dati rilevati ........................ 130 

Appendice ..................................................................................................... 158 

Allegati ........................................................................................................... 171 

Figura 1: STEP 1 ‐ Traccia ................................................................................................... 10 

Figura 3: STEP 2 ‐ Traccia ................................................................................................... 15 

Figura 4: STEP 2 ‐ Attori ...................................................................................................... 17 

Figura 6: STEP 2 ‐ Piano, Esecuzione e Debugging dei casi di test .................... 21 

Figura 7: STEP 3 ‐ Traccia ................................................................................................... 23 

Figura 8: STEP 3 ‐ Attori ...................................................................................................... 25 

Figura 9: STEP 3 ‐ Manufatti “Piano_dei_casi_di_test” ............................................ 27 

Figura 10: Esempio di errore di consistenza globale dei manufatti ................. 27 

Figura 11: STEP 3 ‐ Test e Debugging ............................................................................ 29 

Figura 12: STEP 3 ‐ Piano, Esecuzione e Debugging dei casi di test ................. 30 

Figura 19: STEP 4 ‐ Test e Debugging ............................................................................ 40 

Figura 20: STEP 4 ‐ Piano, Esecuzione e Debugging dei casi di test ................. 41 

Figura 21: STEP 4 ‐ Pianificazione test di unità e di integrazione ..................... 42 

Figura 22: STEP 4 ‐ Pianificazione test d'unità .......................................................... 44 

Figura 25: STEP 5 ‐ Manufatti "Piano_dei_casi_di_test" ......................................... 52 

Figura 26: STEP 5 – Manufatti “Piano_dei_casi_di_test_d'unità” ........................ 53 

Figura 28: STEP 5 ‐ Test e Debugging ............................................................................ 56 

Figura 29: STEP 5 ‐ Piano, Esecuzione e Debugging dei casi di test ................. 57 

Figura 30: STEP 5 ‐ Pianificazione test di unità e d’integrazione ...................... 58 

Figura 32: STEP 5 ‐ Esecuzione dei casi di test .......................................................... 63 

Figura 33: Struttura gerarchica del modello GQM ................................................... 66 

Scopo  di  questa  trattazione  è  illustrare  metodologie,  tecniche  e  strumenti  propri 

Lo  stereotipo  WorkProduct  indica  un  particolare  manufatto  caratterizzato  da 

Lo  stereotipo  Document  indica  un  particolare  manufatto  caratterizzato 

ProcessPerformer  e  ProcessRole  sono  diversi  poiché  si  pongono  a  livelli  della 

Quando  presenti,  gli  accorgimenti  migliorativi  (che  migliorano  il  processo) 

In  questo  caso  l’attività  base,  utilizzando  il  manufatto  Classi_di_equivalenza 

Il  manufatto  Report_dei_casi_di_test  è  stato  dettagliato.  Esso  è  prodotto  dalla 

Abbiamo  inserito  il  manufatto  Stub_Test_di_Integrazione  necessario  alla 

Abbiamo  inserito  il  manufatto  Stub_Test_di_Integrazione  necessario  alla 

Nel  capitolo  precedente  si  è  affrontata  la  problematica  relativa  alla 

Question  Metric  Etichetta  Descrizione 

Q1.1  M1.1.1  TecnTestU  Tecniche  di  testing  utilizzate  per  il 

M1.7.2  NumCTU  Numero  di  casi  di  test  di  unità 

Question  Metric  Etichetta  Descrizione 

Question  Metric  Etichetta  Descrizione 

Q3.1  M3.1.1  ToolsEsecTest  Tool  utilizzati  per  l’esecuzione  dei 

M1.3.2  %DistrExpTest  Distribuzione  in  percentuale  dei 

M1.3.3  %PersExpTest  Percentuale  di  persone  del  team 

Q3.2  M3.2.1  ConToolsUtilEsecTU  Conoscenza  di  un  individuo  del  team 

M3.2.2  %DistrConToolsUtilE Distribuzione  in  percentuale  dei 

M3.2.3  %PersExpToolsUtilEs Percentuale  di  persone  del  team 

Q3.3  M3.3.1  LOCStubFitzU  Dimensione in LOC degli stub di unità 

M3.3.2  NClasStubFitzU  Numero  classi  simulate  da  stub  di 

M3.3.3  StLOCStubFitzU  Dimensione  standardizzata  in  LOC 

Q3.4  M3.4.1  TEsecCTU  Ore/uomo per l’esecuzione dei casi di 

M3.4.2  NumCTUEsec  Numero  di  casi  di  test  di  unità 

M3.4.3  StTEsecCTU  Numero  standardizzato  di  ore  uomo 

Q3.5  M3.4.1  TEsecCTU  Ore/uomo per l’esecuzione dei casi di 

M3.5.1  TEsecCTI  Ore/uomo per l’esecuzione dei casi di 

M3.5.2  TEsecCT  Ore/uomo per l’esecuzione dei casi di 

M3.5.3  %TEsecCTU  Percentuale  di  tempo  dedicata 

Q3.6  M3.6.1  NumCTUPos  Numero di casi di test di unità positivi 

M1.7.2  NumCTU  Numero  di  casi  di  test  di  unità 

M3.6.2  %CTUPos  Percentuale  dei  casi  di  test  di  unità 

Q3.8  M3.8.1  StTEsecCTUA  Ore/uomo  standardizzate  per 

Q3.9  M3.9.1  %TEsecCTULett  Peso che in percentuale deve avere lo 

Question  Metric  Etichetta  Descrizione 

Oggetto dello  Scopo  Prospettiva  Punto di vista  Contesto 

Una  misura  è  oggettiva  quando  non  vi  sono  giudizi/valutazioni  nella 

Definizione:  La  metrica  costo  ore/uomo  speso  “pianificazione  test  d’integrazione” 

Quando  ad  ogni  stato  condizionale,  corrispondono  molte  azioni  di 

A) M1.7.3 <= M1.11.1  YES  NO 

C) M1.9.2 >= M1.10.1  YES  NO  YES  NO  YES  NO  YES  NO 

A) M2.5.2 <= M2.9.1  YES  NO 

C) M2.7.1 >= M2.8.1  YES  NO  YES  NO  YES  NO  YES  NO 

A) M3.4.3 <= M3.8.1  YES  NO 

C) M3.6.2 >= M3.7.1  YES  NO  YES  NO  YES  NO  YES  NO 

A. M4.4.3 <= M4.8.1  YES  NO 

C. M4.6.2 >= M4.7.1  YES  NO  YES  NO  YES  NO  YES  NO 

B. M1.4.3 >= 70%  YES  NO 

   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16 

B) M1.4.3 >= 70%  YES  NO 

B) M2.3.3 >= 70%  YES  NO 

   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16 