Sei sulla pagina 1di 172

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
3:
STEP
2
‐
Traccia ................................................................................................... 15


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


Figura
37:
Goal
1
‐
Box
Plot
2°
esperimento .............................................................140


Figura
38:
Goal
2
‐
Box
Plot
1°
esperimento .............................................................143


Figura
39:
Goal
2
‐
Box
Plot
2°
esperimento .............................................................145


Figura
40:
Goal
3
‐
Box
Plot
1°
esperimento .............................................................148



 6

Figura
41:
Goal
3
‐
Box
Plot
2°
esperimento .............................................................150


Figura
42:
Goal
3
‐
Box
Plot
2°
esperimento
‐
incidenza
sull'effort ................151


Figura
43:
Goal
4
‐
Box
Plot
1°
esperimento .............................................................154


Figura
44:
Goal
4
‐
Box
Plot
2°
esperimento .............................................................156


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à
 FSP­SPEM.
 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


public
«Document»
Class:
Il
documento
deve
contenere
i
risultati
semi‐strutturati

(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


Figura
3:
STEP
2
‐
Traccia


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


public
«ProcessRole»
Actor:

Uno
sviluppatore
con
competenze
in
tecniche
e
tool

per
 l’esecuzione
 esegue
 i
 casi
 di
 test
 e
 compila
 i
 report
 di
 esecuzione
 dei
 casi
 di

test.



Tagged
Values



• Competenze
=
Tecniche
e
tool
per
l'esecuzione.





 17

Sviluppatore
Pianificatore

public
«ProcessRole»
Actor:

Uno
sviluppatore
con
competenze
in
tecniche
e
tool

per
la
pianificazione
dei
casi
di
test
realizza
il
piano
dei
casi
di
test.



Tagged
Values


• Competenze
=
Tecniche
e
tool
per
la
pianificazione.





Manufatti


Manufatti::Codice_corretto


public
«WorkProduct»
Class:

Il
manufatto
deve
rappresentare
il
codice
che
può

essere
direttamente
eseguito
privo
degli
errori
rilevati.



Manufatti::Codice_Sorgente


public
«WorkProduct»
Class:

Il
manufatto
deve
essere
formato
dall'insieme
delle

righe
di
codice
che
componongono
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.



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.



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
seguire

lo
standard
UML.



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.




 18

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

(sotto
forma
tabellare
per
esempio)
dell'esecuzione
di
tutti
i
casi
di
test.



Manufatti::Report_di_debugging


public
«Document»
Class:
Il
documento
deve
contenere
i
risultati
semi‐strutturati

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




 19

Work
Flow
System



Figura
5:
STEP
2
‐
Test
e
Debugging


1.
Test
e
Debugging


public
«WorkDefinition»
Activity:
Attività
monolitica
per
il
test
e
debugging
di
un

prodotto
software.



 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


Figura
7:
STEP
3
‐
Traccia


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


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.



 24


Figura
8:
STEP
3
‐
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
nel
debugging.





Sviluppatore
Esecutore


public
«ProcessRole»
Actor:

Uno
sviluppatore
con
competenze
in
tecniche
e
tool

per
 l’esecuzione
 esegue
 i
 casi
 di
 test
 e
 compila
 i
 report
 di
 esecuzione
 dei
 casi
 di

test.



Tagged
Values



• Competenze
=
Tecniche
e
tool
nell'esecuzione.





Sviluppatore
Pianificatore


public
«ProcessRole»
Actor:

Uno
sviluppatore
con
competenze
in
tecniche
e
tool

per
la
pianificazione
dei
casi
di
test
realizza
il
piano
dei
casi
di
test.



Tagged
Values



 25

• Competenze
=
Tecniche
e
tool
nella
pianificazione.


Manufatti



Manufatti::Codice_corretto


public
«WorkProduct»
Class:

Il
manufatto
deve
rappresentare
il
codice
che
può

essere
direttamente
eseguito
privo
degli
errori
rilevati.



Manufatti::Codice_Sorgente


public
«WorkProduct»
Class:

Il
manufatto
deve
essere
formato
dall'insieme
delle

righe
di
codice
che
componongono
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.



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.



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
seguire

lo
standard
UML.



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


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



Questo
manufatto
è
una
delle
due
componenti
di
Piano_dei_casi_di_test.


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.



Report_di_debugging


public
«Document»
Class:

Il
documento
deve
contenere
i
risultati
semi‐strutturati

(in
forma
tabellare)
dell’esecuzione
del
debug.


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.




 28

Work
Flow
System



Figura
11:
STEP
3
‐
Test
e
Debugging


1.Test
e
Debugging


public
«WorkDefinition»
Activity:
Attività
monolitica
per
il
test
e
debugging
di
un

prodotto
software.



 29


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



 30

1.1
Piano
dei
casi
di
test


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.



Tagged
Values



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



Tagged
Values



• Scadenza
=
31/dic/2008.





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.




 33

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
riscontrati
in
precedenza.



1.4
Step
4


Figura
15:
STEP
4
‐
Traccia


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


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.


Figura
16:
STEP
4
‐
Attori



 35

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.





Sviluppatore
Esecutore


public
«ProcessRole»
Actor:

Uno
sviluppatore
con
competenze
in
tecniche
e
tool

per
 l’esecuzione
 esegue
 i
 casi
 di
 test
 e
 compila
 i
 report
 di
 esecuzione
 dei
 casi
 di

test.



Tagged
Values



• Competenze
=
Tecniche
e
tool
per
l'esecuzione.





Sviluppatore
Pianificatore


public
«ProcessRole»
Actor:

Uno
sviluppatore
con
competenze
in
tecniche
e
tool

per
la
pianificazione
dei
casi
di
test
realizza
il
piano
dei
casi
di
test.



Tagged
Values



• Competenze
=
Tecniche
e
tool
per
la
pianificazione.





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_corretto


public
«WorkProduct»
Class:

Il
manufatto
deve
rappresentare
il
codice
che
può

essere
direttamente
eseguito
privo
degli
errori
rilevati.



Manufatti::Codice_Eseguibile


public
 «WorkProduct»
 Class:
 
 Questo
 manufatto
 rappresenta
 il
 codice

direttamente
eseguibile
(compilato).



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.



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.



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
seguire

lo
standard
UML.



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.




 37

Manufatti::Piano_dei_casi_di_test


public
 «Document»
 Class:
 
 Il
 manufatto
 deve
 contenere
 la
 pianificazione
 dei

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à



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.



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.



Piano_dei_casi_di_test_d'unità


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
 unità.
 Piano_dei_casi_di_test_d'unità
 =
 Piano_dei_casi_di_test_white_box
 +

Piano_dei_casi_di_test_black_box




 38


Figura
18:
STEP
4
‐
Manufatti
"Piano_dei_casi_di_test_di_unità"


Piano_dei_casi_di_test_white_box


public
 «Document»
 Class:
 
 Il
 manufatto
 contiene
 tutti
 i
 casi
 di
 test
 da
 effettuare

con
la
tecnica
della
White
Box.



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.



Report_di_debugging


public
«Document»
Class:
Il
documento
deve
contenere
i
risultati
semi‐strutturati

(in
forma
tabellare)
dell’esecuzione
del
debug.


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.




 39

Work
Flow
System



Figura
19:
STEP
4
‐
Test
e
Debugging


1.Test
e
Debugging


public
«WorkDefinition»
Activity:






 40


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



 41

1.1
Piano
dei
casi
di
test


public
 «WorkDefinition»
 Activity:
 
 Attività
 di
 pianificazione
 dei
 casi
 di
 test.

L'attività
 deve
 essere
 eseguita
 da
 operatori
 che
 abbiamo
 competenze
 di

pianificazione.



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


1.1.1
Test
di
unità


public
 «Activity»
 Activity:
 
 Test
 di
 unità:
 deve
 verificare
 la
 correttezza
 di

frammenti
di
codice
sorgente.


Constraints



• Approved
Pre­condition
.
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
Post­condition
.
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

FSP­SPEM
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.


Tagged
Values



• 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

Tagged
Values



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

Tagged
Values



• 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


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.



Tagged
Values



• Scadenza
=
31/dic/2008.





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

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.


Figura
24:
STEP
5
‐
Attori


Sviluppatore
Debugger


public
«ProcessRole»
Actor:

Uno
sviluppatore
con
competenze
in
tecniche
e
tool

per
il
debugging
effettua
il
debugging.



Tagged
Values




 49

• Competenze
=
Tecniche
e
tool
per
il
debugging.





Sviluppatore
Esecutore


public
«ProcessRole»
Actor:

Uno
sviluppatore
con
competenze
in
tecniche
e
tool

per
 l’esecuzione
 esegue
 i
 casi
 di
 test
 e
 compila
 i
 report
 di
 esecuzione
 dei
 casi
 di

test.



Tagged
Values



• Competenze
=
Tecniche
e
tool
per
l'esecuzione.





Sviluppatore
Pianificatore


public
«ProcessRole»
Actor:

Uno
sviluppatore
con
competenze
in
tecniche
e
tool

per
la
pianificazione
dei
casi
di
test
realizza
il
piano
dei
casi
di
test.



Tagged
Values



• Competenze
=
Tecniche
e
tool
per
la
pianificazione.





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

Manufatti::Codice_corretto


public
«WorkProduct»
Class:

Il
manufatto
deve
rappresentare
il
codice
che
può

essere
direttamente
eseguito
privo
degli
errori
rilevati.



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.



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.



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.



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

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"


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.



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.



Piano_dei_casi_di_test_d'unità


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
 unità.
 Piano_dei_casi_di_test_d'unità
 =
 Piano_dei_casi_di_test_white_box
 +

Piano_dei_casi_di_test_black_box




 52


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


Piano_dei_casi_di_test_white_box


public
 «Document»
 Class:
 
 Il
 manufatto
 contiene
 tutti
 i
 casi
 di
 test
 da
 effettuare

con
la
tecnica
della
White
Box.



Report_Casi_di_Test_di_Integrazione


public
«Document»
Class:

Il
documento
deve
contenere
i
risultati
semi‐strutturati

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


public
«Document»
Class:

Il
documento
deve
contenere
i
risultati
semi‐strutturati

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


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.



 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.



Report_di_debugging


public
«Document»
Class:
Il
documento
deve
contenere
i
risultati
semi‐strutturati

(in
forma
tabellare)
dell’esecuzione
del
debug.



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.




 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

Work
Flow
System



Figura
28:
STEP
5
‐
Test
e
Debugging


1.Test
e
Debugging


public
«WorkDefinition»
Activity:
Attività
monolitica
per
il
test
e
debugging
di
un

prodotto
software.



 56


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



 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.


1.1
Piano
dei
casi
di
test


public
 «WorkDefinition»
 Activity:
 
 Attività
 di
 pianificazione
 dei
 casi
 di
 test.

L'attività
 deve
 essere
 eseguita
 da
 operatori
 che
 abbiamo
 competenze
 di

pianificazione.



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



 58

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

 



Tagged
Values



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

Tagged
Values



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

Tagged
Values



• Tool
=
MatrixJ.


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.



Tagged
Values



• Scadenza
=
31/dic/2008.





1.2
Esecuzione
dei
casi
di
test


public
«WorkDefinition»
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.



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.


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
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
decision­making
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

Allo
scopo
 di
valutarlo

Rispetto
 all’efficienza

Dal
punto
di
vista
 dello
sviluppatore

Nel
contesto
 del
Processo
di
Testing


GOAL
3

Analizzare
 il
processo
Esecuzione
dei
casi
di
Test
di
Unità

Allo
scopo
 di
valutarlo

Rispetto
 all’efficienza

Dal
punto
di
vista
 dello
sviluppatore

Nel
contesto
 del
Processo
di
Testing


GOAL
4

Analizzare
 il
processo
Esecuzione
dei
casi
di
Test
di
Integrazione

Allo
scopo
 di
valutarlo

Rispetto
 all’efficienza

Dal
punto
di
vista
 dello
sviluppatore

Nel
contesto
 del
Processo
di
Testing


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


Conformità
dell’uso
del
processo

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?


Conformità
ai
requisiti
del
processo

Q1.3
Qual
è
l’esperienza
del
team
nell’esecuzione
del
processo?

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?


Modello
Primario

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?


Modello
di
Conferma



 70


 Q2.8
In
che
quantità
si
sono
pianificati
i
casi
di
test
di
integrazione
in

progetti
simili?

Q2.9
Qual
è
secondo
lo
storico
di
dati
disponibili
lo
sforzo
richiesto
per

la
pianificazione
dei
test
di
integrazione?

Modello
di
Validità

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


Conformità
dell’uso
del
processo

Caratterizzazione
del


Q3.1
 Quali
 sono
 i
 tool
 di
 esecuzione
 dei
 test
 d’unità
 utilizzati
 nel

processo?

processo


Conformità
ai
requisiti
del
processo

Q1.3
Qual
è
l’esperienza
del
team
nell’esecuzione
del
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à?

Modello
Primario

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?

Modello
di
Conferma

Q3.7
 In
 che
 percentuale
 si
 sono
 eseguiti
 i
 casi
 di
 test
 di
 unità
 in

progetti
simili?

Q3.8
Qual
è
secondo
lo
storico
di
dati
disponibili
la
percentuale
di
casi

di
test
positivi
per
l’esecuzione
dei
test
di
unità?

Modello
di
Validità

Q3.9
Secondo
la
letteratura
quanto
deve
pesare
l’esecuzione
del
test
di



 71


 unità
sul
processo
di
esecuzione?


GOAL
4


Conformità
dell’uso
del
processo

Caratterizzazione
del


Q4.1
Quali
sono
i
tool
di
esecuzione
dei
test
d’integrazione
utilizzati
nel

processo?

processo


Conformità
ai
requisiti
del
processo

Q1.3
Qual
è
l’esperienza
del
team
nell’esecuzione
del
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?

Modello
Primario

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?

Modello
di
Conferma

Q4.7
In
che
percentuale
si
sono
eseguiti
i
casi
di
test
di
integrazione
in

progetti
simili?

Q4.8
Qual
è
secondo
lo
storico
di
dati
disponibili
la
percentuale
di
casi

di
test
positivi
per
l’esecuzione
dei
test
d’integrazione?

Modello
di
Validità

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à

Q1.8
 M1.7.1
 TPianCTU
 Ore/uomo
 per
 la
 pianificazione
 dei

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


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



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


Question
 Metric
 Etichetta
 Descrizione



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

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

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

esperte
del
dominio
applicativo

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

Q2.6
 M1.7.1
 TPianCTU
 Ore/uomo
 per
 la
 pianificazione
 dei

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



 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


Question
 Metric
 Etichetta
 Descrizione


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



test
di
unità



 77

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


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

test
di
unità


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



test
di
unità


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



test
di
unità


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


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



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


Question
 Metric
 Etichetta
 Descrizione



Q4.1
 M4.1.1
 ToolsEsecTestI
 Tool
 utilizzati
 per
 l’esecuzione
 dei

test
d’integrazione

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

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

integrazione
positivi

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)

Percentuale
di
persone
del
team

esperte
dei
tool
per
la
pianificazione

dei
test
di
unità
utilizzati

VF1.6
(%PersExpDomApp)

Percentuale
di
persone
del
team

esperte
del
dominio
applicativo

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)

BI1.4:
Aumentare
la
percentuale
di

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)

BI1.5:
Aumentare
la
percentuale
di

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à

(effort
assoluto)

BI1.6:
Aumentare
la
percentuale
di

persone
del
team
esperte
del
dominio

applicativo,
aumenta
il
numero

standardizzato
di
casi
di
test
di
unità

pianificati



GOAL
2


Oggetto
dello

Scopo
 Prospettiva
 Punto
di
vista
 Contesto

studio

processo
di

“Pianificazione
 Processo
di

valutarlo
 efficienza
 sviluppatore

dei
casi
di
Test
di
 Testing

Integrazione”

Quality
Focus
 Variation
Factors

[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)

Percentuale
di
persone
del
team

esperte
dei
tool
per
la
pianificazione

dei
test
d’integrazione
utilizzati

VF1.6
(%PersExpDomApp)

Percentuale
di
persone
del
team

esperte
del
dominio
applicativo

Baselines
Hypothesis

Baselines
Impacts

[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

standardizzato
di
ore
uomo
per

pianificare
un
caso
di
test
di

integrazione.
(effort
assoluto)

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

test
di
unità.
(effort
relativo)

BI2.4:
Aumentare
la
percentuale
di

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)

BI2.5:
Aumentare
la
percentuale
di

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



 85

d’integrazione
(effort
assoluto)

BI2.6:
Aumentare
la
percentuale
di

persone
del
team
esperte
del

dominio
applicativo,
aumenta
il

numero
standardizzato
di
casi
di
test

d’integrazione
pianificati


GOAL
3


Oggetto
dello

Scopo
 Prospettiva
 Punto
di
vista
 Contesto

studio

processo
di

“Esecuzione
 Processo
di

valutarlo
 efficienza
 sviluppatore

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


Baselines
Hypothesis

Baselines
Impacts

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

(effort
assoluto)

BI3.2:
Aumentare
la
percentuale
di



 86

persone
del
team
esperte
di
testing,

permette
di
bilanciare
l’effort
per

l’esecuzione
del
test
di
integrazione
con

l’effort
per
l’esecuzione
del
test
di
unità.

(effort
relativo)

BI3.3:
Aumentare
la
percentuale
di

persone
del
team
esperte
dei
tool

utilizzati,
diminuisce
il
numero

standardizzato
di
ore
uomo
per

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

valutarlo
 efficienza
 sviluppatore

di
Test
di
 Testing

Integrazione”

Quality
Focus
 Variation
Factors

[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

Baselines
Hypothesis

Baselines
Impacts

[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)

BI4.2:
Aumentare
la
percentuale
di

persone
del
team
esperte
di
testing,

permette
di
bilanciare
l’effort
per

l’esecuzione
del
test
di
integrazione

con
l’effort
per
l’esecuzione
del
test
di

unità.
(effort
relativo)

BI4.3:
Aumentare
la
percentuale
di

persone
del
team
esperte
dei
tool

utilizzati,
diminuisce
il
numero

standardizzato
di
ore
uomo
per

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

integrazione
positivi


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à

Tipo
Metrica:
Oggettiva


Tipo
Scala:
Assoluta

Linee
Guida
 Specifiche

• 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


Linee
Guida
 Specifiche

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

Tipo
Metrica:
Soggettiva


Tipo
Scala:
Ordinale


Linee
Guida
 Specifiche

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

Tipo
Metrica:
Soggettiva


Tipo
Scala:
Ordinale



 91

Linee
Guida
 Specifiche

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

Tipo
Metrica:
Soggettiva


Tipo
Scala:
Ordinale

Linee
Guida
 Specifiche

• 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
Metrica:
Oggettiva


Tipo
Scala:
Ratio


Linee
Guida
 Specifiche

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

Tipo
Metrica:
Oggettiva


Tipo
Scala:
Assoluta

Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
processo
 • Come
misura:
per
valutare
tale

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”

Tipo
Metrica:
Oggettiva



 93

Tipo
Scala:
Ratio

Linee
Guida
 Specifiche

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

Tipo
Metrica:
Oggettiva

Tipo
Scala:
Assoluta


Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
processo
 • Come
misura:
per
valutare
tale

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.

Tipo
Metrica:
Oggettiva

Tipo
Scala:
Assoluta


Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
processo
 • Come
misura:
per
valutare
tale



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

Tipo
Metrica:
Oggettiva


Tipo
Scala:
Ratio


Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
processo
 • Come
misura:
per
valutare
tale

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.

Tipo
Metrica:
Oggettiva

Tipo
Scala:
Ratio


Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
processo
 • Come
misura:
per
valutare
tale

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

Tipo
Metrica:
Oggettiva

Tipo
Scala:
Assoluta


Linee
Guida
 Specifiche

• 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


Linee
Guida
 Specifiche

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

Tipo
Metrica:
Soggettiva


Tipo
Scala:
Ordinale


Linee
Guida
 Specifiche

• 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

Definizione:
 La
 metrica
 conoscenza
 di
 un
 individuo
 del
 team
 circa
 i
 tool
 utilizzati

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.

Tipo
Metrica:
Soggettiva


Tipo
Scala:
Ordinale


Linee
Guida
 Specifiche

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

Tipo
Metrica:
Oggettiva


Tipo
Scala:
Assoluta


Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
processo
 • Come
misura:
per
valutare
tale

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.

Tipo
Metrica:
Oggettiva

Tipo
Scala:
Assoluta


Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
processo
 • Come
misura:
per
valutare
tale

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.

Tipo
Metrica:
Oggettiva


Tipo
Scala:
Ratio

Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
processo
 • Come
misura:
per
valutare
tale

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.

Tipo
Metrica:
Oggettiva


Tipo
Scala:
Ratio

Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
processo
 • Come
misura:
per
valutare
tale

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
integrazione

testing
 dopo
aver
preso
visione
della

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.

Tipo
Metrica:
Oggettiva

Tipo
Scala:
Assoluta


Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
processo
 • Come
misura:
per
valutare
tale

di
testing
 metrica
è
necessario
che
il
valutatore

• 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


Definizione:
 La
 metrica
 conoscenza
 di
 un
 individuo
 del
 team
 circa
 i
 tool
 utilizzati

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.

Tipo
Metrica:
Soggettiva


Tipo
Scala:
Ordinale

Linee
Guida
 Specifiche

• 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
 nei
 tool
 di

testing
 esecuzione
 dei
 test
 di
 unità,


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

Tipo
Metrica:
Oggettiva



 100

Tipo
Scala:
Ratio

Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
processo
 • Come
misura:
per
valutare
tale

di
testing
 metrica
è
necessario
che
il
valutatore

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

Tipo
Metrica:
Oggettiva


Tipo
Scala:
Assoluta


Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
processo
 • Come
misura:
per
valutare
tale

di
testing
 metrica
è
necessario
che
il
valutatore

• 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à”

Tipo
Metrica:
Oggettiva


Tipo
Scala:
Ratio

Linee
Guida
 Specifiche

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

Tipo
Metrica:
Oggettiva


Tipo
Scala:
Assoluta


Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
processo
 • Come
 misura:
 per
 valutare
 tale

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”

Tipo
Metrica:
Oggettiva


Tipo
Scala:
Ratio


Linee
Guida
 Specifiche

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

Tipo
Metrica:
Oggettiva


Tipo
Scala:
Assoluta

Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
 • Come
 misura:
 per
 valutare
 tale

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.

Tipo
Metrica:
Oggettiva


Tipo
Scala:
Ratio

Linee
Guida
 Specifiche

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

Tipo
Metrica:
Oggettiva



 103

Tipo
Scala:
Ratio

Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
 • Come
misura:
per
valutare
tale

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

Tipo
Metrica:
Oggettiva

Tipo
Scala:
Ratio


Linee
Guida
 Specifiche

• Chi
misura
:
valutatore
del
processo
 • Come
misura:
per
valutare
tale

di
testing
 metrica
è
necessario
che
il
valutatore

• Quando
misura:
Prima
 indichi
la
percentuale
di
sforzo
per
la

dell'esecuzione
del
processo
di
 esecuzione
dei
casi
di
test
d’unità

testing
 dopo
aver
preso
visione
della

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.

Tipo
Metrica:
Oggettiva


Tipo
Scala:
Assoluta

Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
processo
 • Come
misura:
per
valutare
tale

di
testing
 metrica
è
necessario
che
il
valutatore

• 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

Definizione:
 La
 metrica
 conoscenza
 di
 un
 individuo
 del
 team
 circa
 i
 tool
 utilizzati

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.

Tipo
Metrica:
Soggettiva

Tipo
Scala:
Ordinale


Linee
Guida
 Specifiche

• 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
 nei
 tool
 di

testing
 esecuzione
 dei
 test
 di
 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
 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.

Tipo
Metrica:
Oggettiva

Tipo
Scala:
Ratio


Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
processo
 • Come
misura:
per
valutare
tale



 105

di
testing
 metrica
è
necessario
che
il
valutatore

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

Tipo
Metrica:
Oggettiva


Tipo
Scala:
Assoluta


Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
processo
 • Come
misura:
per
valutare
tale

di
testing
 metrica
è
necessario
che
il
valutatore

• 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
Metrica:
Oggettiva

Tipo
Scal
:
Assoluta


Linee
Guida
 Specifiche

• 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

dei
casi
di
test.



 106

Tipo
Metrica:
Oggettiva

Tipo
Scala:
Assoluta


Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
 • Come
 misura:
 per
 valutare
 tale

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

dei
casi
di
test.

Tipo
Metrica:
Oggettiva

Tipo
Scala:
Ratio


Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
 • Come
misura:
per
valutare
tale

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


Definizione:
La
metrica
numero
standardizzato
di
ore
uomo
per
eseguire
un
caso
di

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.

Tipo
Metrica:
Oggettiva


Tipo
Scala:
Ratio

Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
 • Come
misura:
per
valutare
tale

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

Tipo
Metrica:
Oggettiva


Tipo
Scala:
Ratio


Linee
Guida
 Specifiche

• Chi
misura:
valutatore
del
processo
 • Come
misura:
per
valutare
tale

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.

Come
 calcolare:
 Il
 calcolo
 di
 questa
 metrica
 è
 effettuato
 a
 partire
 dai
 valori

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.

Come
 calcolare:
 Il
 calcolo
 di
 questa
 metrica
 è
 effettuato
 a
 partire
 dai
 valori

individuati
nella
metrica
ConTecUtilUi
per
ogni
individuo
del
team.

Per
ogni
i
 
{nessuna,
scarsa,
bassa,
media,
alta
}
la
distribuzione,
in
percentuale,

dei
valori
soggettivi
d’esperienza


%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

esperienza
Nessuna.

 
#ConTecUtilUs
=
numero
di
individui
del
team
che
hanno
come
valore
di

esperienza
Scarsa

 
#ConTecUtilUb
=
numero
di
individui
del
team
che
hanno
come
valore
di

esperienza
Bassa.

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

Come
 calcolare:
 Il
 calcolo
 di
 questa
 metrica
 è
 effettuato
 a
 partire
 dai
 valori

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

Definizione:
La
metrica
distribuzione
in
percentuale
dei
valori
della
conoscenza
del

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.

Come
 calcolare:
 Il
 calcolo
 di
 questa
 metrica
 è
 effettuato
 a
 partire
 dai
 valori

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

esperienza
Nessuna.

 #ConToolsUtilUb
=
numero
di
individui
del
team
che
hanno
come
valore
di

esperienza
Bassa.

 #ConToolsUtilUs
=
numero
di
individui
del
team
che
hanno
come
valore
di

esperienza
Sufficiente.

 #ConToolsUtilUb
=
numero
di
individui
del
team
che
hanno
come
valore
di

esperienza
Buona.


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.

Come
 calcolare:
 Il
 calcolo
 di
 questa
 metrica
 è
 effettuato
 a
 partire
 dai
 valori

individuati
nella
metrica
%DistrConToolsUtilUi



%PersExpToolsUtilU
=
%DistrConToolsUtilUb
+
%DistrConToolsUtilUs


con

 %DistrConToolsUtilUs
=
percentuale
di
individui
del
team
che
hanno
come

valore
di
esperienza
Sufficiente.

 %DistrConToolsUtilUb
=
percentuale
di
individui
del
team
che
hanno
come

valore
di
esperienza
Buona.


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.

Come
 calcolare:
 Il
 calcolo
 di
 questa
 metrica
 è
 effettuato
 a
 partire
 dai
 valori

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

di
esperienza
i.

 #ConDomAppli
=
numero
di
individui
del
team
che
hanno
come
valore
di

esperienza
i.

 #ConDomAppln
=
numero
di
individui
del
team
che
hanno
come
valore
di

esperienza
Nessuna.

 #ConDomApplba
=
numero
di
individui
del
team
che
hanno
come
valore
di

esperienza
Bassa.

 #ConDomApplbu
=
numero
di
individui
del
team
che
hanno
come
valore
di

esperienza
Buona.


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.

Come
 calcolare:
 Il
 calcolo
 di
 questa
 metrica
 è
 effettuato
 a
 partire
 dai
 valori

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

Come
calcolare:
Il
calcolo
di
questa
metrica
è
effettuato
facendo
un
rapporto
tra
le

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.

Come
calcolare:
Il
calcolo
di
questa
metrica
è
effettuato
facendo
un
rapporto
tra
le

metriche
NumCTU
e
NumClas:


StNumCTU
=
NumCTU
/
NumClas



M2.3.2
%DISTRCONTECUTILI

Definizione:
La
metrica
distribuzione
in
percentuale
dei
valori
della
conoscenza
del

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.

Come
 calcolare:
 Il
 calcolo
 di
 questa
 metrica
 è
 effettuato
 a
 partire
 dai
 valori

individuati
nella
metrica
ConTecUtilIi
per
ogni
individuo
del
team.

Per
ogni
i
 
{nessuna,
scarsa,
bassa,
media,
alta
}
la
distribuzione,
in
percentuale,

dei
valori
soggettivi
d’esperienza



 113


%DistrConTecUtilIi=( )*100



Con

 %DistrConTecUtilUi
=
percentuale
di
individui
del
team
che
ha
come
valore

di
esperienza
i.

 #ConTecUtilIi
=
numero
di
individui
del
team
che
hanno
come
valore
di

esperienza
i.

 #ConTecUtilIn
=
numero
di
individui
del
team
che
hanno
come
valore
di

esperienza
Nessuna.

 
#ConTecUtilIs
=
numero
di
individui
del
team
che
hanno
come
valore
di

esperienza
Scarsa

 
#ConTecUtilIb
=
numero
di
individui
del
team
che
hanno
come
valore
di

esperienza
Bassa.

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

Come
 calcolare:
 Il
 calcolo
 di
 questa
 metrica
 è
 effettuato
 a
 partire
 dai
 valori

individuati
nella
metrica
%DistrConTecUtilIi


%PersExpTecUtilI
=
%DistrConTecUtilIb
+
%DistrConTecUtilIs


con

 %DistrConTecUtilIs
=
percentuale
di
individui
del
team
che
hanno
come

valore
di
esperienza
Sufficiente.

 %DistrConTecUtilIb
=
percentuale
di
individui
del
team
che
hanno
come

valore
di
esperienza
Buona.


M2.4.2
%DISTRCONTOOLSUTILI

Definizione:
La
metrica
distribuzione
in
percentuale
dei
valori
della
conoscenza
del

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

Come
 calcolare:
 Il
 calcolo
 di
 questa
 metrica
 è
 effettuato
 a
 partire
 dai
 valori

individuati
nella
metrica
ConToolsUtilIi
per
ogni
individuo
del
team.

Per
ogni
i
 
{nessuna,
bassa,
sufficiente,
buona}
la
distribuzione,
in
percentuale,
dei

valori
soggettivi
d’esperienza


%DistrConToolsUtilI
=( )*100



con


 %DistrConToolsUtilIi
=
percentuale
di
individui
del
team
che
ha
come
valore

di
esperienza
i.

 #ConToolsUtilIi
=
numero
di
individui
del
team
che
hanno
come
valore
di

esperienza
i.

 #ConToolsUtilIn
=
numero
di
individui
del
team
che
hanno
come
valore
di

esperienza
Nessuna.

 #ConToolsUtilIb
=
numero
di
individui
del
team
che
hanno
come
valore
di

esperienza
Bassa.

 #ConToolsUtilIs
=
numero
di
individui
del
team
che
hanno
come
valore
di

esperienza
Sufficiente.

 #ConToolsUtilIb
=
numero
di
individui
del
team
che
hanno
come
valore
di

esperienza
Buona.


M2.4.3
%PERSEXPTOOLSUTILU

Definizione:
 La
 metrica
 percentuale
 di
 persone
 del
 team
 esperte
 dei
 tool
 utilizzati

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.

Come
 calcolare:
 Il
 calcolo
 di
 questa
 metrica
 è
 effettuato
 a
 partire
 dai
 valori

individuati
nella
metrica
%DistrConToolsUtilIi



%PersExpToolsUtilI
=
%DistrConToolsUtilIb
+
%DistrConToolsUtilIs


con

 %DistrConToolsUtilIs
=
percentuale
di
individui
del
team
che
hanno
come

valore
di
esperienza
Sufficiente.

 %DistrConToolsUtilIb
=
percentuale
di
individui
del
team
che
hanno
come

valore
di
esperienza
Buona.


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

Come
calcolare:
Il
calcolo
di
questa
metrica
è
effettuato
facendo
un
rapporto
tra
le

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.

Come
calcolare:
Il
calcolo
di
questa
metrica
è
effettuato
facendo
un
rapporto
tra
le

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.

Come
calcolare:
Il
calcolo
di
questa
metrica
è
effettuato
facendo
un
rapporto
tra
le

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.

Come
 calcolare:
 Il
 calcolo
 di
 questa
 metrica
 è
 effettuato
 a
 partire
 dai
 valori

individuati
nella
metrica
ConToolsUtilEsecTUi
per
ogni
individuo
del
team.

Per
ogni
i
 
{nessuna,
bassa,
sufficiente,
buona}
la
distribuzione,
in
percentuale,
dei

valori
soggettivi
d’esperienza


%DistrConToolsUtilEsecTU=( )*100



 116

 %
DistrConToolsUtilEsecTUi
=
percentuale
di
individui
del
team
che
ha
come

valore
di
esperienza
i.

 #ConToolsUtilEsecTUi
 =
 numero
 di
 individui
 del
 team
 che
 hanno
 come

valore
di
esperienza
i.

 #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

valore
di
esperienza
Sufficiente.

 #ConToolsUtilEsecTUb
 =
 numero
 di
 individui
 del
 team
 che
 hanno
 come

valore
di
esperienza
Buona.


M3.2.3
%PERSEXPTOOLSUTILESECTU

Definizione:
 La
 metrica
 percentuale
 di
 persone
 del
 team
 esperte
 dei
 tool
 utilizzati

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.

Come
 calcolare:
 Il
 calcolo
 di
 questa
 metrica
 è
 effettuato
 a
 partire
 dai
 valori

individuati
nella
metrica
%DistrConToolsUtilEsecTUi


%PersExpToolsUtilEsecTU
=
%DistrConToolsUtilEsecTUb
+

%DistrConToolsUtilEsecTUs


con

%DistrConToolsUtilEsecTUs
 =
 percentuale
 di
 individui
 del
 team
 che
 hanno
 come

valore
di
esperienza
Sufficiente.

%DistrConToolsUtilEsecTUb
 =
 percentuale
 di
 individui
 del
 team
 che
 hanno
 come

valore
di
esperienza
Buona.


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.

Come
calcolare:
Il
calcolo
di
questa
metrica
è
effettuato
facendo
un
rapporto
tra
le

metriche
LOCStubFitzU
e
NClasStubFitzU:


StLOCStubFitzU
=
LOCStubFitzU
/
NClasStubFitzU



M3.4.3
STTESECCTU



 117

Definizione:
La
metrica
numero
standardizzato
di
ore
uomo
per
eseguire
un
caso
di

test
 di
 unità
 riporta
 le
 ore
 uomo
 che,
 mediamente,
 sono
 state
 necessarie
 per

eseguire
un
caso
di
test
di
unità.

Come
calcolare:
Il
calcolo
di
questa
metrica
è
effettuato
facendo
un
rapporto
tra
le

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.

Come
calcolare:
Il
calcolo
di
questa
metrica
è
effettuato
facendo
un
rapporto
tra
le

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

Come
calcolare:
Il
calcolo
di
questa
metrica
è
effettuato
facendo
un
rapporto
tra
le

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

Definizione:
La
metrica
numero
standardizzato
di
ore
uomo
per
eseguire
un
caso
di

test
di
integrazione
riporta
le
ore
uomo
che,
mediamente,
sono
state
necessarie
per

eseguire
un
caso
di
test
di
integrazione.

Come
 calcolare:
 Il
 calcolo
 di
 questa
 metrica
 è
 effettuato
 facendo
 un
 rapporto
 tra
 le

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.

Come
 calcolare:
 Il
 calcolo
 di
 questa
 metrica
 è
 effettuato
 facendo
 un
 rapporto
 tra
 le

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

Come
 calcolare:
 Il
 calcolo
 di
 questa
 metrica
 è
 effettuato
 facendo
 un
 rapporto
 tra
 le

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


4.
Aumentare
la
percentuale
di
persone
del


 
 
 
 X
 X
 X
 X

team
esperte
delle
tecniche
di
test
utilizzate


5.
Aumentare
la
percentuale
di
persone
del


 
 
 
 X
 X
 X
 X

team
esperte
dei
tool
utilizzati


6.
Aumentare
la
percentuale
di
persone
del


 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
+

YES
 NO
 YES
 NO

10%


C)
M2.7.1
>=
M2.8.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



 121

team
esperte
di
testing


4.
Aumentare
la
percentuale
di
persone
del


 
 
 
 X
 X
 X
 X

team
esperte
delle
tecniche
di
test
utilizzate


5.
Aumentare
la
percentuale
di
persone
del


 
 
 
 X
 X
 X
 X

team
esperte
dei
tool
utilizzati


6.
Aumentare
la
percentuale
di
persone
del


 X
 
 X
 
 X
 
 X

team
esperte
del
dominio
applicativo


7.
Goal
soddisfatto
 X
 
 
 
 
 
 
 



 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
+

YES
 NO
 YES
 NO

10%


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


1.
Migliorare
i
tool
utilizzati
per
l’esecuzione


 
 
 
 X
 X
 X
 X

di
test


2.
Aumentare
la
percentuale
di
persone
del


 
 X
 X
 
 
 X
 X

team
esperte
di
testing



 122

3.
Aumentare
la
percentuale
di
persone
del


 
 
 
 X
 X
 X
 X

team
esperte
dei
tool
utilizzati


4.
Aumentare
la
dimensione
standardizzata


 X
 
 X
 
 X
 
 X

in
LOC
degli
stub
di
unità
fittizi
utilizzati


5.
Goal
soddisfatto
 X
 
 
 
 
 
 
 



 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
+

YES
 NO
 YES
 NO

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


2.
Aumentare
la
percentuale
di
persone
del


 
 X
 X
 
 
 X
 X

team
esperte
di
testing


3.
Aumentare
la
percentuale
di
persone
del


 
 
 
 X
 X
 X
 X

team
esperte
dei
tool
utilizzati


4.
Aumentare
la
dimensione
standardizzata


 X
 
 X
 
 X
 
 X

in
LOC
degli
stub
di
unità
fittizi
utilizzati


5.
Goal
soddisfatto
 X
 
 
 
 
 
 
 



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

YES
 NO
 YES
 NO

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

esperte
di
testing


5.
Aumentare
la

percentuale
di

persone
del
team


 
 
 
 
 
 
 
 
 
 
 
 X
 X
 X
 X

esperte
delle

tecniche
di
test

utilizzate


6.
Aumentare
la

percentuale
di


 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

persone
del
team

esperte
dei
tool



 124

utilizzati


7.
Aumentare
la

percentuale
di

persone
del
team


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

YES
 NO
 YES
 NO

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


 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

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

esperte
di
testing


5.
Aumentare
la

percentuale
di

persone
del
team


 
 
 
 
 
 
 
 
 
 
 
 X
 X
 X
 X

esperte
delle

tecniche
di
test

utilizzate


6.
Aumentare
la

percentuale
di

persone
del
team
 
 
 
 
 X
 X
 X
 X
 
 
 
 
 X
 X
 X
 X

esperte
dei
tool

utilizzati


7.
Aumentare
la

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

YES
 NO
 YES
 NO

M2.9.1


D)
M2.10.1
­
10%

<=
M2.6.1
<=
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO

M2.10.1
+
10%


E)
M2.7.1
>=

YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO

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

esperte
di
testing


5.
Aumentare
la

percentuale
di

persone
del
team


 
 
 
 
 
 
 
 
 
 
 
 X
 X
 X
 X

esperte
delle

tecniche
di
test

utilizzate


6.
Aumentare
la

percentuale
di

persone
del
team
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

esperte
dei
tool

utilizzati


7.
Aumentare
la

percentuale
di

persone
del
team


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

YES
 NO
 YES
 NO

M2.9.1


D)
M2.10.1
­
10%

<=
M2.6.1
<=
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO

M2.10.1
+
10%


E)
M2.7.1
>=

YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO

M2.8.1


1.
Goal
soddisfatto
 X
 
 
 
 
 
 
 
 X
 
 
 
 
 
 
 


2.
Migliorare
le


 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

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

esperte
di
testing


5.
Aumentare
la

percentuale
di

persone
del
team


 
 
 
 
 
 
 
 
 
 
 
 X
 X
 X
 X

esperte
delle

tecniche
di
test

utilizzate


6.
Aumentare
la

percentuale
di

persone
del
team
 
 
 
 
 X
 X
 X
 X
 
 
 
 
 X
 X
 X
 X

esperte
dei
tool

utilizzati


7.
Aumentare
la

percentuale
di

persone
del
team


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

YES
 NO
 YES
 NO

M3.8.1


C)
M3.9.1
­
10%

<=
M3.5.3
<=
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO

M3.9.1
+
10%


D)
M3.6.2
>=

YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO

M3.7.1


1.
Goal
soddisfatto
 X
 
 
 
 
 
 
 
 X
 
 
 
 
 
 
 


2.
Migliorare
i
tool

utilizzati
per
 
 
 
 
 X
 X
 X
 X
 
 
 
 
 
 
 
 

l’esecuzione
di
test


3.
Aumentare
la

percentuale
di


 
 X
 X
 
 
 X
 X
 
 
 X
 X
 
 
 X
 X

persone
del
team

esperte
di
testing


4.
Aumentare
la

percentuale
di

persone
del
team
 
 
 
 
 
 
 
 
 
 
 
 
 X
 X
 X
 X

esperte
dei
tools

utilizzati


5.
Aumentare
la

dimensione

standardizzata
in


 X
 
 X
 
 X
 
 X
 
 X
 
 X
 
 X
 
 X

LOC
degli
stub
di

integrazione
fittizi

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

YES
 NO
 YES
 NO

M4.8.1


C)
M4.9.1
­
10%

<=
M4.5.1
<=
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO

M4.9.1
+
10%


D)
M4.6.2
>=

YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO
 YES
 NO

M4.7.1


1.
Goal
soddisfatto
 X
 
 
 
 
 
 
 
 X
 
 
 
 
 
 
 


2.
Migliorare
i
tool

utilizzati
per
 
 
 
 
 X
 X
 X
 X
 
 
 
 
 
 
 
 

l’esecuzione
di
test



 128

3.
Aumentare
la

percentuale
di


 
 X
 X
 
 
 X
 X
 
 
 X
 X
 
 
 X
 X

persone
del
team

esperte
di
testing


4.
Aumentare
la

percentuale
di

persone
del
team
 
 
 
 
 
 
 
 
 
 
 
 
 X
 X
 X
 X

esperte
dei
tools

utilizzati


5.
Aumentare
la

dimensione

standardizzata
in


 X
 
 X
 
 X
 
 X
 
 X
 
 X
 
 X
 
 X

LOC
degli
stub
di

integrazione
fittizi

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


TecnTest
 Elenco


ToolUtil
 Elenco


%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


StEffAssolAtteso
 0,2


%EffortRelatAtteso
 0,5



 136

StNumCasiPianAtteso
 30


TERZA
OSSERVAZIONE


TecnTest
 Elenco


ToolUtil
 Elenco


%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


StEffAssolAtteso
 0,2


%EffortRelatAtteso
 0,5


StNumCasiPianAtteso
 30


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.


Fattori
 
 Variabile
dipendente

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.


PRIMA
OSSERVAZIONE


TecnTest
 Elenco


ToolUtil
 Elenco


%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


StEffAssolAtteso
 0,2


%EffortRelatAtteso
 0,5


StNumCasiPianAtteso
 30


SECONDA
OSSERVAZIONE


TecnTest
 Elenco


ToolUtil
 Elenco


%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


StEffAssolAtteso
 0,2


%EffortRelatAtteso
 0,5


StNumCasiPianAtteso
 30



 139

Test
delle
ipotesi

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


In
 un
 test
 di
 questo
 tipo,
 per
 stabilire
 l’esito
 conclusivo
 dell’indagine,
 devo

verificare
che
il
valore
p­level
sia
inferiore
a
0,005.


In
questo
caso
p‐level
=
0,820596.
Per
questa
ragione
accetto
H0.


Statistica
descrittiva


Figura
37:
Goal
1
‐
Box
Plot
2°
esperimento


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.


Fattori
 
 Variabile
dipendente


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.


PRIMA
OSSERVAZIONE


TecnTest
 Elenco


ToolUtil
 Elenco


%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


StEffAssolAtteso
 0,2


%EffortRelatAtteso
 0,5


StNumCasiPianAtteso
 30


SECONDA
OSSERVAZIONE


TecnTest
 Elenco


ToolUtil
 Elenco



 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


StEffAssolAtteso
 0,2


%EffortRelatAtteso
 0,5


StNumCasiPianAtteso
 30


TERZA
OSSERVAZIONE


TecnTest
 Elenco


ToolUtil
 Elenco


%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


StEffAssolAtteso
 0,2


%EffortRelatAtteso
 0,5


StNumCasiPianAtteso
 30


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.



 142

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
 =
 19,91251
 e
 Chi‐Quadro
 =
 16,33929.
 Per
 questa
 ragione



rigetto
H0.


Statistica
descrittiva


Figura
38:
Goal
2
‐
Box
Plot
1°
esperimento


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.


Fattori
 
 Variabile
dipendente

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.


PRIMA
OSSERVAZIONE


TecnTest
 Elenco


ToolUtil
 Elenco


%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


StEffAssolAtteso
 0,2


%EffortRelatAtteso
 0,5


StNumCasiPianAtteso
 30


SECONDA
OSSERVAZIONE


TecnTest
 Elenco


ToolUtil
 Elenco


%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


StEffAssolAtteso
 0,2


%EffortRelatAtteso
 0,5


StNumCasiPianAtteso
 30


Test
delle
ipotesi

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
 è:
 rigetto
 H0.
 C’è
 differenza
 statisticamente
 significativa
 tra
 le
 due

osservazioni
(per
i
due
trattamenti).


In
 un
 test
 di
 questo
 tipo,
 per
 stabilire
 l’esito
 conclusivo
 dell’indagine,
 devo

verificare
che
il
valore
p­level
sia
inferiore
a
0,005.


In
questo
caso
p‐level
=
0,000157.
Per
questa
ragione
rigetto
H0.


Statistica
descrittiva


Figura
39:
Goal
2
‐
Box
Plot
2°
esperimento



 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.


Fattori
 
 Variabile
dipendente


Conoscenza
dei
tool

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.


PRIMA
OSSERVAZIONE


ToolUtil
 Elenco


%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


StEffAssolAtteso
 0,2


%EffortRelatAtteso
 0,5


%CTPositiviAtteso
 0,6



 146

SECONDA
OSSERVAZIONE


ToolUtil
 Elenco


%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


StEffAssolAtteso
 0,2


%EffortRelatAtteso
 0,5


%CTPositiviAtteso
 0,6


TERZA
OSSERVAZIONE


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


StEffAssolAtteso
 0,2


%EffortRelatAtteso
 0,5


%CTPositiviAtteso
 0,6


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.



 147

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

verificare
il
valore
H
con
quello
Chi‐Quadro.
Se
H
>
Chi‐Quadro
posso
rigettare

l’ipotesi
nulla.


In
 questo
 caso
 H
 =
 19,67806
 e
 Chi‐Quadro
 =
 13,92857.
 Per
 questa
 ragione



rigetto
H0.


Statistica
descrittiva


Figura
40:
Goal
3
‐
Box
Plot
1°
esperimento


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.


Fattori
 
 Variabile
dipendente

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.


PRIMA
OSSERVAZIONE


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


StEffAssolAtteso
 0,2


%EffortRelatAtteso
 0,5


%CTPositiviAtteso
 0,6


SECONDA
OSSERVAZIONE


ToolUtil
 Elenco
aggiornato
(si
è
introdotta
innovazione)


%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


StEffAssolAtteso
 0,2


%EffortRelatAtteso
 0,5



 149

%CTPositiviAtteso
 0,6


Test
delle
ipotesi

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
 è:
 rigetto
 H0.
 C’è
 differenza
 statisticamente
 significativa
 tra
 le
 due

osservazioni
(per
i
due
trattamenti).


In
 un
 test
 di
 questo
 tipo,
 per
 stabilire
 l’esito
 conclusivo
 dell’indagine,
 devo

verificare
che
il
valore
p­level
sia
inferiore
a
0,005.


In
questo
caso
p‐level
=
0,000157.
Per
questa
ragione
rigetto
H0.


Statistica
descrittiva


Figura
41:
Goal
3
‐
Box
Plot
2°
esperimento


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

Fattori
 
 Variabile
dipendente


Conoscenza
dei
tool

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
integrazione?”.
Il
numero
di
osservazioni
è:
3.


PRIMA
OSSERVAZIONE


ToolUtil
 Elenco


%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


StEffAssolAtteso
 0,2


%EffortRelatAtteso
 0,5


%CTPositiviAtteso
 0,6


SECONDA
OSSERVAZIONE


ToolUtil
 Elenco


%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


StEffAssolAtteso
 0,2


%EffortRelatAtteso
 0,5


%CTPositiviAtteso
 0,6



 152

TERZA
OSSERVAZIONE


ToolUtil
 Elenco
aggiornato
(si
è
introdotta
innovazione)


%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


StEffAssolAtteso
 0,2


%EffortRelatAtteso
 0,5


%CTPositiviAtteso
 0,6


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
=
20,15244
e
Chi‐Quadro
=
15,20.
Per
questa
ragione
rigetto
H0.



 153

Statistica
descrittiva


Figura
43:
Goal
4
‐
Box
Plot
1°
esperimento


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.


Fattori
 
 Variabile
dipendente

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

PRIMA
OSSERVAZIONE


ToolUtil
 Elenco
aggiornato
(si
è
introdotta
innovazione)


%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


StEffAssolAtteso
 0,2


%EffortRelatAtteso
 0,5


%CTPositiviAtteso
 0,6


SECONDA
OSSERVAZIONE


ToolUtil
 Elenco
aggiornato
(si
è
introdotta
innovazione)


%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


StEffAssolAtteso
 0,2


%EffortRelatAtteso
 0,5


%CTPositiviAtteso
 0,6


Test
delle
ipotesi

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
 è:
 rigetto
 H0.
 C’è
 differenza
 statisticamente
 significativa
 tra
 le
 due

osservazioni
(per
i
due
trattamenti).



 155

In
 un
 test
 di
 questo
 tipo,
 per
 stabilire
 l’esito
 conclusivo
 dell’indagine,
 devo

verificare
che
il
valore
p­level
sia
inferiore
a
0,005.


In
questo
caso
p‐level
=
0,000670.
Per
questa
ragione
rigetto
H0.


Statistica
descrittiva


Figura
44:
Goal
4
‐
Box
Plot
2°
esperimento


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;


• Multi­piattaforma:
 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
FSP­SPEM
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
FSP­SPEM

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.


C.2.1
Vantaggi
e
svantaggi

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
web­application

è
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


C.3.1
Vantaggi
e
svantaggi

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