Metodi Sperimentali Per La Produzione Del Software
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Metodi Sperimentali Per La Produzione Del Software as PDF for free.
More details
- Words: 30,138
- Pages: 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à FSPSPEM. Il disegno verrà eseguito utilizzando un opportuno software di modellazione (vedi pagina 164). Nei successivi capitoli si presenteranno ulteriori altre attività che possono essere eseguite su di un modello di processo al fine di valutarlo e conseguentemente migliorarlo. Il disegno del modello di processo, che introduciamo, rappresenta il primo passo di questo caso di studio. Di seguito si presentano tutti gli Step di modellazione. Per ognuno di questi ho provveduto ad inserire la traccia così come ci è stata fornita durante le
9
esercitazioni ed il report automatico generato dal software di modellazione utilizzato. Sono stati inseriti dei commenti tecnici che hanno lo scopo di chiarire e migliorare la leggibilità del report (di per sé strutturato e poco discorsivo). La successione degli step è incrementale (il primo è costruito sul secondo, il secondo sul terzo etc…). Per questa ragione, di ogni step, verranno commentati solo gli aspetti caratteristici non trattati in precedenza. Ove presenti, i commenti tecnici sono stati evidenziati attraverso la seguente notazione: Quello che stai leggendo è un commento tecnico.
1.1 Step 1
Figura 1: STEP 1 ‐ Traccia
10
Lo Step 1 prevede la modellazione di un processo con pochi vincoli, pertanto molti gradi di libertà. La traccia fa riferimento ad un generico processo di TEST e DEBUGGING senza lasciar intendere quali possano essere le sue sotto‐attività. Il processo in questione si presenta nel livello massimo di generalità: le indicazioni potrebbero sembrare incomplete o troppo vaghe ma non è detto che lo siano senza una giusta motivazione: può capitare che al fine del contesto, il progettista non ritenga opportuno dettagliare ulteriormente l’attività. La situazione sopra descritta non è necessariamente sbagliata: un’attività non ha bisogno di essere dettagliata se il livello di granularità è sufficiente per rilevare le misure che si ritengono valide ai fini della valutazione della qualità del processo. In questo contesto, l’attività viene vista come un blocco monolitico. In generale, a maggiore generalità corrisponde un maggior numero di gradi di libertà. Nella descrizione vengono indicati i manufatti entranti e quelli uscenti da tale attività ed anche il ruolo dell’operatore incaricato a svolgerla. Considerando la generalità di tale processo e la presenza di una sola attività è ragionevole concludere che tutti i manufatti entranti ed uscenti verranno associati a quest’unica attività: TEST e DEBUGGING.
Attori Sviluppatore public «ProcessRole» Actor: Attore con competenze nello sviluppo software. Egli assolve responsabilità di carattere generale avendo una preparazione media in tutti i contesti dello sviluppo software. Lo stereotipo ProcessRole indica il ruolo (la figura professionale e non la persona fisica) dell’attore responsabile all’esecuzione di una particolare attività. In questo caso TEST e DEBUGGING.
11
Manufatti Manufatti::Codice_corretto public «WorkProduct» Class: Il manufatto deve rappresentare il codice che può essere direttamente eseguito privo degli errori rilevati. Lo stereotipo WorkProduct indica un particolare manufatto caratterizzato da una rigida e rigorosa strutturazione dei dati. In questa categoria rientrano tutti quei documenti prodotti con precise regole di produzione o in generale fortemente strutturati.
Manufatti::Codice_Sorgente public «WorkProduct» Class: Il manufatto deve essere formato dall'insieme delle righe di codice che compongono il sistema software.
Manufatti::Descrizione_dei_casi_d'uso public «Document» Class: Il manufatto contiene la descrizione in linguaggio naturale semi‐strutturato di ciascun caso d'uso. Lo stereotipo Document indica un particolare manufatto caratterizzato dall’assenza di una strutturazione dei dati contenuti. In questa categoria rientrano tutti quei documenti redatti in linguaggio naturale o debolmente strutturati.
Manufatti::Diagramma_dei_casi_d’uso public «UMLModel» Class: Questo manufatto deve contenere il diagramma dei casi d’uso del sistema software rilevati dall’analista. Il dettaglio del manufatto deve seguire lo standard UML. Lo stereotipo UML Model indica un particolare manufatto il cui contenuto è espresso in linguaggio UML.
Manufatti::Diagrammi_di_sequenza public «UMLModel» Class: Questo manufatto deve contenere per ogni caso d’uso la rappresentazione grafica dell’interazione tra le classi del sistema, focalizzandosi sulla sequenza temporale dei messaggi che si scambiano. Il dettaglio deve segueire lo standard UML.
12
Manufatti::Modello_delle_classi public «UMLModel» Class: Questo manufatto deve contenere la rappresentazione grafica del modello delle classi. Il dettaglio deve seguire lo standard UML.
Manufatti::Piano_dei_casi_di_test public «Document» Class: Il manufatto deve contenere la pianificazione dei differenti casi di test da eseguire.
Manufatti::Report_dei_casi_di_test public «Document» Class: Il documento deve contenere i risultati semi‐strutturati (in forma tabellare) dell'esecuzione di tutti i casi di test.
Manufatti::Report_di_debugging 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 Precondition . ISC.
42
Modello delle Classi disponibile AND Specifica delle Classi disponibile AND Diagramma dei Casi d'Uso disponibile AND Descrizione dei Casi d'Uso disponibile AND Codice Sorgente disponibile • Approved Postcondition . IEC. Piano dei Casi di Test di Unità Nell’attività 1.1.1 Test di unità sono stati inseriti dei vincoli che consistono in Pre‐condizioni e Post‐condizioni. In entrambi i casi si tratta di condizioni che devono essere vere per garantire la corretta esecuzione dell’attività (nel primo caso) e la corretta terminazione dell’attività (nel secondo caso). Nel linguaggio FSPSPEM le condizioni sono definite mediante l’utilizzo di espressioni booleane. In questo caso, l’attività 1.1.1 Test d’unità ha bisogno della disponibilità di cinque manufatti in input per poter essere eseguita. Circa la sua terminazione, ha bisogno che vi sia un solo manufatto in output per considerarsi terminata.
1.1.1 Test di unità Embedded Elements ELEMENT
TIPO
ANNOTAZIONI
Creazione casi di test Black Box
State
Creazione classi di equivalenza
State
Creazione dei cammini indipendenti
State
Creazione dei casi di test White Box
State
Creazione della lista delle classi
State
Creazione della matrice di cross
State
La tabella mostra l’insieme delle attività base che compongono l’attività elementare 1.1.1 Test di unità. Un’attività base è definita come un’attività che trasforma semplicemente un manufatto in input in uno di output. 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:
(<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_integrazione
Report_casi_di_test_di_unità
+
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 decisionmaking aziendale. Dopo aver disegnato i processi, nasce la necessità di valutarli. In letteratura esistono differenti metodologie operative per la valutazione di processi in termini di qualità. In questo caso quando si parla di qualità ci si riferisce alla “caratteristica desiderata” per un prodotto, processo o risorsa che soddisfi il committente e realizzi il ritorno economico. Quella che si presenta in questa sede è la metodologia Goal Question Metric. L’approccio GQM è basato sull’assunzione che un’organizzazione, per valutare in
65
maniera significativa deve: specificare gli obiettivi aziendali e quelli di progetto; tracciare questi obiettivi con i dati che li definiscono in termini operativi; fornire un ambiente per l’interpretazione dei dati concordemente agli obiettivi fissati. Il risultato dell’applicazione di questo paradigma è la specifica di modelli di misurazione mirati e un insieme di regole per l’interpretazione delle misure. Il modello che ne deriva è articolato su tre livelli: concettuale (Goal), operativo (Question), quantitativo (Metric).
Figura 33: Struttura gerarchica del modello GQM
Goal Un Goal è definito su un preciso oggetto, con differenti punti di vista, in merito a diversi obiettivi di qualità, relativamente ad un particolare contesto. Esso identifica ciò che vogliamo conseguire relativamente ad un prodotto, un processo o una risorsa. Di seguito si riportano i goal. GOAL 1 Analizzare
il processo Pianificazione dei casi di Test di Unità
66
Allo scopo
di valutarlo
Rispetto
all’efficienza
Dal punto di vista dello sviluppatore Nel contesto
del Processo di Testing
GOAL 2 Analizzare
il processo Pianificazione dei casi di Test di Integrazione
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:
Qualità di interes se
Caratterizzazione del processo
GOAL 1
Conformità dell’uso 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 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
Qualità di interesse
Caratterizzazione del processo
Conformità dell’uso 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 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.
Caratterizzazione del processo
GOAL 3 Conformità dell’uso del processo Q3.1 Quali sono i tool di esecuzione dei test d’unità utilizzati nel 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à?
Qualità di interesse
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 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?
Caratterizzazione del processo
GOAL 4 Conformità dell’uso del processo Q4.1 Quali sono i tool di esecuzione dei test d’integrazione utilizzati nel 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?
Qualità di Interesse
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 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
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 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
M1.4.1
ConTecUtilU
Conoscenza di un individuo del team circa le tecniche di pianificazione dei test di unità utilizzate
Q1.4
Q1.5
Etichetta
di
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
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
Q1.7
Q1.8
Q1.9
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
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à
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à
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
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
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
Q2.3
Etichetta
75
Q2.4
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
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
Q2.5
Q2.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
M1.8.1
TPianCTI
Ore/uomo per la pianificazione dei casi di test di integrazione
M2.5.1
NumCTI
Numero di casi di test di integrazione pianificati
M2.5.2
StTPianCTI
Numero standardizzato di ore uomo per pianificare un caso di test di integrazione
M1.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
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
Q2.7
Percentuale di tempo dedicata alla pianificazione dei test di integrazione
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 Q3.1
M3.1.1
Etichetta
Descrizione
ToolsEsecTest
Tool utilizzati per l’esecuzione dei test di unità
77
Q1.3
Q3.2
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
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
Q3.4
Q3.5
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
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à
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à
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
Q3.6
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
M4.2.1
ConToolsUtilEsecTI
Conoscenza di un individuo del team circa i tool utilizzati per l’esecuzione dei test di integrazione
Q4.2
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
M4.4.2
NumCTIEsec
M4.4.3
StTEsecCTI
Numero standardizzato di ore uomo per eseguire un caso di test di integrazione
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
M4.6.1
NumCTIPos
Numero di casi di integrazione positivi
test
di
M2.1.1
NumCTI
Numero di casi di integrazione pianificati
test
di
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
Q4.5
Q4.6
Ore/uomo per l’esecuzione dei casi di test di integrazione Numero di casi di integrazione eseguiti
test
di
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 studio
Scopo
Prospettiva
Punto di vista
Contesto
82
processo di “Pianificazione valutarlo dei casi di Test di Unità”
efficienza
Sviluppatore
Processo di Testing
Quality Focus [Q1.7 , Q1.8, Q1.9]
Variation Factors [Q1.1, Q1.2, Q1.3, Q1.4, Q1.5, Q1.6]
M1.7.3 (StTPianCTU) Numero standardizzato di ore uomo per pianificare un caso di test di unità M1.8.3 (%TPianCTU) Percentuale di tempo dedicata alla pianificazione dei test di unità M1.9.2 (StNumCTU) Numero standardizzato di casi di test di unità pianificati
VF1.1 (TecnTestU) Tecniche di testing per la pianificazione dei test di unità VF1.2 (ToolsUtilU) Tool utilizzati per la pianificazione dei test di unità VF1.3 (%PersExpTest) Percentuale di persone del team esperte di testing 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 [Q1.10, Q1.11, Q1.12] BH1.1: M1.9.2 ≥ M1.10.1 BH1.2: M1.7.3 ≤ M1.11.1 BH1.3: M1.12.1 ‐ 10% ≤ M1.8.3 ≤ M1.12.1 + 10%
Baselines Impacts BI1.1: Migliorare le tecniche utilizzate 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.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 studio
Scopo
Prospettiva
Punto di vista
Contesto
efficienza
sviluppatore
Processo di Testing
processo di “Pianificazione valutarlo dei casi di Test di Integrazione” Quality Focus [Q2.5, Q2.6, Q2.7]
Variation Factors [Q2.1, Q2.2, Q1.3, Q2.3, Q2.4, Q1.6]
M2.5.2 (StTPianCTI) Numero standardizzato di ore uomo per pianificare un caso di test di integrazione M2.6.1 (%TPianCTI) Percentuale di tempo dedicata alla pianificazione dei test d’integrazione M2.7.1 (StNumCTI) Numero standardizzato di casi di test d’integrazione pianificati
VF1.1 (TecnTestI) Tecniche di pianificazione dei test d’integrazione VF1.2 (ToolsUtilI) Tool utilizzati per la pianificazione dei test d’integrazione VF1.3 (%PersExpTest) Percentuale di persone del team esperte di testing VF1.4 (%PersExpTecUtilI) 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 [Q2.8, Q2.9, Q2.10] BH2.1: M2.7.1 ≥ M2.8.1 BH2.2: M2.5.2 ≤ M2.9.1 BH2.3: M2.10.1 ‐ 10% ≤ M2.6.1 ≤ M2.10.1 + 10%
Baselines Impacts BI2.1: Migliorare le tecniche utilizzate per la pianificazione dei test d’integrazione, diminuisce il 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 studio
Scopo
processo di “Esecuzione valutarlo casi di Test di Unità”
Prospettiva
Punto di vista
Contesto
efficienza
sviluppatore
Processo di Testing
Quality Focus [Q3.4 , Q3.5, Q3.6]
Variation Factors [Q3.1, Q1.3, Q3.2, Q3.3]
M3.4.3 (StTEsecCTU) Numero standardizzato di ore uomo per eseguire un caso di test di unità M3.5.3 (%TEsecCTU) Percentuale di tempo dedicata all’esecuzione dei test di unità M3.6.2 (%CTUPos) Percentuale di casi di test di unità positivi
VF3.1 (ToolsEsecTestU) Tool utilizzati per l’esecuzione test di unità VF1.3 (%PersExpTest) Percentuale di persone del team esperte di testing VF3.2 (%PersExpToolsUtilEsecTU) Percentuale di persone del team esperte dei tool utilizzati per l’esecuzione dei test di unità VF3.3 (StLOCStubFitzU) Dimensione standardizzata in LOC degli stub di unità fittizi utilizzati
Baselines Hypothesis [Q3.7, Q3.8, Q3.9] BH3.1: M3.6.2 ≥ M3.7.1 BH3.2: M3.4.3 ≤ M3.8.1 BH3.3: M3.9.1 ‐ 10% ≤ M3.5.3 ≤ M3.9.1 + 10%
Baselines Impacts BI3.1: Migliorare i tool utilizzati per l’esecuzione di test di unità, diminuisce il numero standardizzato di ore uomo 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 studio
Scopo
Prospettiva
Punto di vista
Contesto
efficienza
sviluppatore
Processo di Testing
processo di “Esecuzione casi valutarlo di Test di Integrazione” Quality Focus [Q4.4, Q4.5, Q4.6]
Variation Factors [Q4.1, Q1.3, Q4.2 Q4.3]
87
M4.4.3 (StTEsecCTI) Numero standardizzato di ore uomo per eseguire un caso di test di integrazione M4.5.1 (%TEsecCTI) Percentuale di tempo dedicata all’esecuzione dei test di integrazione M4.6.2 (%CTIPos) Percentuale di casi di test di integrazione positivi
Baselines Hypothesis [Q4.7, Q4.8, Q4.9] BH4.1: M4.6.2 ≥ M4.7.1 BH4.2: M4.4.3 ≤ M4.8.1 BH4.3: M4.9.1 ‐ 10% ≤ M4.5.1 ≤ M4.9.1 + 10%
VF3.1 (ToolsEsecTestI) Tool utilizzati per l’esecuzione dei test di unità VF1.3 (%PersExpTest) Percentuale di persone del team esperte di testing VF4.1 (%PersExpToolsUtilEsecTI) Percentuale di persone del team esperte dei tool utilizzati per l’esecuzione dei test di integrazione VF4.2 (StLOCStubFitzI) Dimensione standardizzata in LOC degli stub di integrazione fittizi utilizzati Baselines Impacts BI4.1: Migliorare i tool utilizzati per l’esecuzione di test di integrazione, diminuisce il numero standardizzato 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 • Come misura: osserva ed elenca quali sono • Chi misura: valutatore del le tecniche utilizzate nel processo di processo di testing pianificazione dei test di unità • Quando misura: prima 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 • Come misura: osserva ed elenca quali sono i • Chi misura: valutatore del tool utilizzati nel processo di pianificazione processo di testing dei test di unità definito • Quando misura: prima 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 • Chi misura: valutatore del processo di testing • Quando misura: prima dell'esecuzione del processo di testing
Specifiche • Come misura: per valutare tale metrica è necessario definire, per ogni persona coinvolta nell’esecuzione del processo, l’esperienza maturata rispetto all’esecuzione di un qualsiasi altro processo di test, scegliendo uno dei valori assegnati: nessuna: la persona non ha alcuna conoscenza di 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 pianificazione dei test di unità, scegliendo uno dei • Quando misura: valori assegnati: prima dell'esecuzione 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 pianificazione dei test di unità, scegliendo uno dei • Quando misura: valori assegnati: prima dell'esecuzione 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 processo, il livello di conoscenza del dominio • Quando misura: applicativo, scegliendo uno dei valori assegnati: prima dell'esecuzione Nessuna: l’individuo non ha lavorato a nessun del processo di testing 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 seguente procedura: il soggetto • Quando misura: prima addetto alla valutazione della metrica dell'esecuzione del processo di ritira, da ogni persona coinvolta nella testing 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 numero totale casi di test d’unità • Quando misura: prima esaminando il manufatto “Piano dei dell'esecuzione del processo di casi di Test d’Unità”. testing 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 seguente procedura: il soggetto • Quando misura: prima addetto alla valutazione della metrica dell'esecuzione del processo di ritira, da ogni persona coinvolta nella testing 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 numero totale delle classi del sistema • Quando misura: prima osservando il suo modello dell'esecuzione del processo di progettuale. testing 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 • Quando misura: prima dell'esecuzione del processo di testing
metrica è necessario rilevare, tramite indagini su web, il numero di casi di test di unità che, in processi analoghi, 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 letteratura, il numero riporta delle • Quando misura: prima ore uomo necessarie per pianificare dell'esecuzione del processo di un caso di test di unità. testing 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 indichi la percentuale di sforzo per la • Quando misura: prima pianificazione dei casi di test d’unità dell'esecuzione del processo di dopo aver preso visione della testing 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 quali sono le tecniche utilizzate nel di testing processo di pianificazione dei test • Quando misura: prima d’integrazione definito dell'esecuzione del processo di 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 quali sono i tool utilizzati nel di testing processo di pianificazione dei test • Quando misura: prima d’integrazione definito dell'esecuzione del processo di 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 ogni persona coinvolta nel processo, • Quando misura: prima il livello di esperienza nelle tecniche dell'esecuzione del processo di di testing, scegliendo uno dei valori testing 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 ogni persona coinvolta nel processo, • Quando misura: prima il livello di esperienza nei tool di dell'esecuzione del processo di pianificazione dei test d’integrazione, testing 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 numero totale casi di test • Quando misura: prima d’integrazione esaminando il dell'esecuzione del processo di manufatto “Piano dei casi di test testing 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 indagini su web, il numero di casi di • Quando misura: prima test di integrazione che, in processi dell'esecuzione del processo di analoghi, sono pianificati per una testing 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 letteratura, il numero riporta delle • Quando misura: prima ore uomo necessarie per pianificare dell'esecuzione del processo di un caso di test di integrazione. testing 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 indichi la percentuale di sforzo per la • Quando misura: prima pianificazione dei casi di integrazione dell'esecuzione del processo di dopo aver preso visione della testing 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 indichi quali tool sono stati utilizzati • Quando misura: durante durante l’esecuzione dei test di unità. dell'esecuzione del processo di 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 ogni persona coinvolta nel processo, • Quando misura: prima il livello di esperienza nei tool di dell'esecuzione del processo di esecuzione dei test di unità, testing 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 effettui il conteggio delle righe di • Quando misura: prima della fase di codice che costituiscono tutti gli stub esecuzione dei casi di test 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 effettui il conteggio degli stub di • Quando misura: prima della fase di unità fittizi utilizzati per l’esecuzione esecuzione dei casi di test 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 • Chi misura: valutatore del processo di testing • Quando misura: alla fine dell’esecuzione del processo di testing
Specifiche • Come misura: per valutare tale metrica è necessario eseguire la seguente procedura: il soggetto addetto alla valutazione della 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 numero totale casi di test d’unità • Quando misura: prima eseguiti esaminando il manufatto dell'esecuzione del processo di “Pianificazione dei casi di Test testing 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 • Chi misura: valutatore del processo di testing • Quando misura: alla fine dell’esecuzione del processo di testing
Specifiche • Come misura: per valutare tale metrica è necessario eseguire la seguente procedura: il soggetto addetto alla valutazione della 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 • Chi misura: valutatore del processo di testing • Quando misura: dopo l’esecuzione della fase “Esecuzione dei casi di test”
Specifiche • Come misura: per valutare tale metrica è necessario contare il numero totale casi di test d’unità positivi esaminando il manufatto “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 indagini su web, il numero • Quando misura: prima di percentuale di casi di test di unità iniziare ad eseguire il processo di positivi che, in processi analoghi, testing 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 • Chi misura: valutatore del processo di testing • Quando misura: prima di iniziare ad eseguire il processo.
Specifiche • Come misura: per valutare tale metrica è necessario rilevare dalla letteratura, il numero standardizzato 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 indichi la percentuale di sforzo per la • Quando misura: Prima esecuzione dei casi di test d’unità dell'esecuzione del processo di dopo aver preso visione della testing 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 indichi quali tool sono stati utilizzati • Quando misura: prima durante l’esecuzione dei test dell'esecuzione del processo di d’integrazione. testing 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 ogni persona coinvolta nel processo, • Quando misura: Prima il livello di esperienza nei tool di dell'esecuzione del processo di esecuzione dei test di integrazione, testing 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 • Quando misura: prima della fase di esecuzione dei casi di test.
metrica è necessario che il valutatore effettui il conteggio delle righe di 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 effettui il conteggio degli stub di • Quando misura: prima della fase di integrazione fittizi utilizzati per esecuzione dei casi di test. 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 numero totale casi di test di • Quando misura: Prima integrazione eseguiti esaminando il dell'esecuzione del processo di manufatto “Pianificazione dei casi di testing 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 • Chi misura: valutatore del processo di testing • Quando misura: dopo l’esecuzione della fase “Esecuzione dei casi di test”
Specifiche • Come misura: per valutare tale metrica è necessario contare il numero totale casi di test di integrazione positivi esaminando 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, tramite indagini su web, il • Quando misura: prima di numero di casi di test di iniziare ad eseguire il processo di integrazione positivi che, in testing 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 • Chi misura: valutatore del processo di testing • Quando misura: prima di
Specifiche • Come misura: per valutare tale metrica è necessario rilevare 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 valutatore indichi la percentuale • Quando misura: Prima di sforzo per la esecuzione dei dell'esecuzione del processo di casi di test di integrazione dopo testing 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
B) M1.12.1 10% <= M1.8.3 <= M1.12.1 + 10% C) M1.9.2 >= M1.10.1
NO
YES
NO
YES
NO
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 team esperte di testing
X
X
X
X
4. Aumentare la percentuale di persone del team esperte delle tecniche di test utilizzate
X
X
X
X
5. Aumentare la percentuale di persone del team esperte dei tool utilizzati
X
X
X
X
6. Aumentare la percentuale di persone del team esperte del dominio applicativo
X
X
X
X
7. Goal soddisfatto
X
1
2
3
4
5
6
7
8
GOAL 2 A) M2.5.2 <= M2.9.1
YES
B) M2.10.1 10% <= M2.6.1 <= M2.10.1 + 10% C) M2.7.1 >= M2.8.1
NO
YES
NO
YES
NO
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 team esperte delle tecniche di test utilizzate
X
X
X
X
5. Aumentare la percentuale di persone del team esperte dei tool utilizzati
X
X
X
X
6. Aumentare la percentuale di persone del team esperte del dominio applicativo
X
X
X
X
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
B) M3.9.1 10% <= M3.5.3 <= M3.9.1 + 10% C) M3.6.2 >= M3.7.1
NO
YES
NO
YES
NO
YES
NO
YES
NO
YES
NO
YES
NO
1. Migliorare i tool utilizzati per l’esecuzione di test
X
X
X
X
2. Aumentare la percentuale di persone del team esperte di testing
X
X
X
X
122
3. Aumentare la percentuale di persone del team esperte dei tool utilizzati
X
X
X
X
4. Aumentare la dimensione standardizzata in LOC degli stub di unità fittizi utilizzati
X
X
X
X
5. Goal soddisfatto
X
1
2
3
4
5
6
7
8
GOAL 4 A. M4.4.3 <= M4.8.1
YES
B. M4.9.1 10% <= M4.5.1 <= M4.9.1 + 10% C. M4.6.2 >= M4.7.1
NO
YES
NO
YES
NO
YES
NO
YES
NO
YES
NO
YES
NO
1. Migliorare i tool utilizzati per l’esecuzione di test
X
X
X
X
2. Aumentare la percentuale di persone del team esperte di testing
X
X
X
X
3. Aumentare la percentuale di persone del team esperte dei tool utilizzati
X
X
X
X
4. Aumentare la dimensione standardizzata in LOC degli stub di unità fittizi utilizzati
X
X
X
X
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
C. M1.7.3 <= M1.11.1
YES
D. M1.12.1 10% <= M1.8.3 <= M1.12.1 + 10% E. M1.9.2 >= M1.10.1
NO NO
YES
NO
YES
YES
NO
NO
YES
NO
YES
NO
YES NO YES NO YES NO YES NO YES NO YES NO YES NO YES NO
1. Goal soddisfatto
X
X
2. Migliorare le tecniche di testing
X
X
X
X
X
X
X
X
3. Migliorare i tool utilizzati
X
X
X
X
4. Aumentare la percentuale di persone del team esperte di testing
X
X
X
X
X
X
X
X
5. Aumentare la percentuale di persone del team esperte delle tecniche di test utilizzate
X
X
X
X
6. Aumentare la percentuale di persone del team esperte dei tool
124
utilizzati 7. Aumentare la percentuale di persone del team esperte del dominio applicativo
X
X
X
X
X
X
X
X
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
C) M1.7.3 <= M1.11.1
YES
D) M1.12.1 10% <= M1.8.3 <= M1.12.1 + 10% E) M1.9.2 >= M1.10.1
NO NO
YES
NO
YES
YES
NO
NO
YES
NO
YES
NO
YES NO YES NO YES NO YES NO YES NO YES NO YES NO YES NO
1. Goal soddisfatto
X
X
2. Migliorare le tecniche di testing
3. Migliorare i tool utilizzati
X
X
X
X
4. Aumentare la percentuale di persone del team esperte di testing
X
X
X
X
X
X
X
X
5. Aumentare la percentuale di persone del team esperte delle tecniche di test utilizzate
X
X
X
X
6. Aumentare la percentuale di persone del team esperte dei tool utilizzati
X
X
X
X
X
X
X
X
7. Aumentare la percentuale di persone del team esperte del dominio
X
X
X
X
X
X
X
X
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
C) M2.5.2 <= M2.9.1
YES
D) M2.10.1 10% <= M2.6.1 <= M2.10.1 + 10% E) M2.7.1 >= M2.8.1
NO NO
YES
NO
YES
YES
NO
NO
YES
NO
YES
NO
YES NO YES NO YES NO YES NO YES NO YES NO YES NO YES NO
1. Goal soddisfatto
X
X
2. Migliorare le tecniche di testing
X
X
X
X
X
X
X
X
3. Migliorare i tool utilizzati
X
X
X
X
4. Aumentare la percentuale di persone del team esperte di testing
X
X
X
X
X
X
X
X
5. Aumentare la percentuale di persone del team esperte delle tecniche di test utilizzate
X
X
X
X
6. Aumentare la percentuale di persone del team esperte dei tool utilizzati
7. Aumentare la percentuale di persone del team esperte del dominio applicativo
X
X
X
X
X
X
X
X
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
C) M2.5.2 <= M2.9.1
YES
D) M2.10.1 10% <= M2.6.1 <= M2.10.1 + 10% E) M2.7.1 >= M2.8.1
NO NO
YES
NO
YES
YES
NO
NO
YES
NO
YES
NO
YES NO YES NO YES NO YES NO YES NO YES NO YES NO YES NO
1. Goal soddisfatto
X
X
2. Migliorare le tecniche di testing
3. Migliorare i tool utilizzati
X
X
X
X
4. Aumentare la percentuale di persone del team esperte di testing
X
X
X
X
X
X
X
X
5. Aumentare la percentuale di persone del team esperte delle tecniche di test utilizzate
X
X
X
X
6. Aumentare la percentuale di persone del team esperte dei tool utilizzati
X
X
X
X
X
X
X
X
7. Aumentare la percentuale di persone del team esperte del dominio applicativo
X
X
X
X
X
X
X
X
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
GOAL 3 A) M3.2.3 >= 70%
YES
NO
127
B) M3.4.3 <= M3.8.1
YES
C) M3.9.1 10% <= M3.5.3 <= M3.9.1 + 10% D) M3.6.2 >= M3.7.1
NO
YES
NO
YES
YES
NO
NO
YES
NO
YES
NO
YES NO YES NO YES NO YES NO YES NO YES NO YES NO YES NO
1. Goal soddisfatto
X
X
2. Migliorare i tool utilizzati per l’esecuzione di test
X
X
X
X
3. Aumentare la percentuale di persone del team esperte di testing
X
X
X
X
X
X
X
X
4. Aumentare la percentuale di persone del team esperte dei tools utilizzati
X
X
X
X
5. Aumentare la dimensione standardizzata in LOC degli stub di integrazione fittizi utilizzati
X
X
X
X
X
X
X
X
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
GOAL 4 A) M4.2.3 >= 70%
YES
B) M4.4.3 <= M4.8.1
YES
C) M4.9.1 10% <= M4.5.1 <= M4.9.1 + 10% D) M4.6.2 >= M4.7.1
NO NO
YES
NO
YES
YES
NO
NO
YES
NO
YES
NO
YES NO YES NO YES NO YES NO YES NO YES NO YES NO YES NO
1. Goal soddisfatto
X
X
2. Migliorare i tool utilizzati per l’esecuzione di test
X
X
X
X
128
3. Aumentare la percentuale di persone del team esperte di testing
X
X
X
X
X
X
X
X
4. Aumentare la percentuale di persone del team esperte dei tools utilizzati
X
X
X
X
5. Aumentare la dimensione standardizzata in LOC degli stub di integrazione fittizi utilizzati
X
X
X
X
X
X
X
X
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 Conoscenza tecniche di testing
Variabile dipendente
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 Conoscenza del dominio applicativo
Variabile dipendente Numero standardizzato dei casi di 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 plevel 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 Conoscenza dei tool
Effort assoluto standardizzato
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 test di integrazione pianificati
Conoscenza del dominio applicativo
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 plevel 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 Insieme dei tool utilizzati
Effort assoluto standardizzato
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à positivi alla prima esecuzione
Grandezza degli stub
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 plevel 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 Insieme dei tool utilizzati
Effort assoluto standardizzato
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 Grandezza degli stub
Variabile dipendente Percentuale di casi di test di 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 plevel 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; • Multipiattaforma: il software è progettato per essere utilizzato su diversi sistemi operativi (Windows 2000/XP/Vista e Linux). Il tutor può utilizzare un particolare sistema operativo per la macchina server senza dover utilizzare lo stesso dei client e viceversa.
163
B.2 Svantaggi L’utilizzo dell’aula virtuale ha comportato alcuni svantaggi legati, in particolar modo, al software utilizzato ed alla capacità di traffico della rete. • Problemi del software: in alcuni casi il software ha presentato problemi di installazione: in modo particolare su quelli con sistema operativo Windows Vista. Altre volte, pur essendo installato correttamente, il software non aggiornava la schermata del computer selezionato dal tutor costringendo il tutor ad aprire e chiudere la relativa finestra; Nella maggior parte delle lezioni è capitato che si siano verificati problemi di riconoscimento dei computer connessi alla rete o connessi alla piattaforma ITALC; • Congestione della rete: la rete utilizzata durante le esercitazioni conta una media di 30 computer connessi. Ogni volta che il tutor condivideva un particolare documento, la rete non riusciva a gestire il traffico e di conseguenza i documenti non potevano essere scaricati.
C. Tools Durante le esercitazioni sono stati introdotti diversi tool a seconda delle diverse problematiche affrontate. I tool utilizzati sono: Enterprise Architect, TABULA e STATISTICA.
C.1 Enterprise Architect Enterprise Architect è un software di modellazione UML estremamente flessibile e completo. Durante le esercitazioni, in particolare, abbiamo utilizzato quest’applicazione per la modellazione di processi FSPSPEM based.
164
Figura 46: Schermata di Enterprise Architect 5.0
Lo strumento è estremamente efficace. A prima vista può apparire complesso e difficile da utilizzare ma dopo aver disegnato i primi modelli ed inserito i primi manufatti diventa facile e veloce.
C.1.1 Vantaggi e svantaggi Il principale vantaggio di Enterprise Architect è il set di diagrammi rappresentabili (forse troppi a tal punto da renderlo complesso) unitamente alla possibilità di inventarne di nuovi (come nel caso di FSP‐SPEM). Purtroppo il software non è gratuito e durante il corso abbiamo sperimentato, nostro malgrado, l’insufficienza del periodo di prova (30 giorni). Il tool per l’esportazione della documentazione in formato Microsoft Word è risultato poco flessibile in termini di layout del documento finale producendo documenti poco leggibili e mal formattati. La versione utilizzata è la 5, dal momento che le versioni più nuove (nel momento in cui scrivo è disponibile la 7) non supportano al meglio il template di FSPSPEM fornitoci dal tutor. Un difetto particolarmente sentito di questo software è la sua natura mono‐ piattaforma: esso può essere installato unicamente su Microsoft Windows XP/Vista.
165
C.2 TABULA TABULA è un’applicazione web a supporto della realizzazione, manutenzione e verifica di tavole di decisione realizzata dal SERLAB di Bari.
Figura 47: Schermata di TABULA
Oltre alla rappresentazione dell’insieme di regole che compongono una tavola, lo strumento in esame agevola (dovrebbe) l’utente nella fase di Verifica e Validazione della stessa. Supporta l’import/export in formato XML ed è multi‐utente: ciascun utente è registrato con credenziali univoche che gli consentono l’accesso esclusivo alla propria area di lavoro. Durante le esercitazioni abbiamo utilizzato questo strumento per la definizione delle tavole di decisione scaturite dalla progettazione del GQM. Ogni gruppo ha creato una propria area di lavoro, registrandosi all’applicazione, nella quale ha potuto procedere alla realizzazione delle tavole.
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 webapplication è utilizzabile da qualsiasi tipo di sistema operativo. Anche in questo caso, però, si sono riscontrati dei problemi di compatibilità con browser diversi da Mozilla Firefox: Microsoft Internet Explorer e Safari.
C.3 STATISTICA Per l’analisi statistica dei dati rilevati abbiamo utilizzato un tool statistico: STATISTICA. Il software presenta un’interfaccia chiara e minimalista in stile Foglio Elettronico all’interno della quale copiare le serie di valori rilevati ed ordinare il calcolo dei vari indicatori numerici e grafici.
167
Figura 48: Schermata di STATISTICA
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 Laboratorio
34
Trattasi di 11 lezioni frontali da 3 ore ciascuna. L’ultima di queste è durata 4 ore.
Studio
30
Per ogni lezione di laboratorio ho stimato
168
individuale
Redazione della documentazione
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 individuale dal momento che coinvolge concetti di teoria, lezioni di laboratorio e risoluzione di problemi legati all’uso dei tool.
58
Effort speso per i tool Di seguito riporto una tabella riepilogativa circa l’effort speso per ciascun tool utilizzato. ATTIVITA’
ORE
DESCRIZIONE
Enterprise Architect
0
Avevo già avuto modo di utilizzare il tool per la realizzazione di modelli di proceso (ed anche per produrre documentazione UML) nel corso di Modelli per la qualità del software.
TABULA
E’ un’applicazione molto facile da imparare ad usare 1* dal momento che dispone di pochissime funzionalità.
STATISTICA
1
Sebbene sia uno strumento estremamente versatile, 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
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à FSPSPEM. Il disegno verrà eseguito utilizzando un opportuno software di modellazione (vedi pagina 164). Nei successivi capitoli si presenteranno ulteriori altre attività che possono essere eseguite su di un modello di processo al fine di valutarlo e conseguentemente migliorarlo. Il disegno del modello di processo, che introduciamo, rappresenta il primo passo di questo caso di studio. Di seguito si presentano tutti gli Step di modellazione. Per ognuno di questi ho provveduto ad inserire la traccia così come ci è stata fornita durante le
9
esercitazioni ed il report automatico generato dal software di modellazione utilizzato. Sono stati inseriti dei commenti tecnici che hanno lo scopo di chiarire e migliorare la leggibilità del report (di per sé strutturato e poco discorsivo). La successione degli step è incrementale (il primo è costruito sul secondo, il secondo sul terzo etc…). Per questa ragione, di ogni step, verranno commentati solo gli aspetti caratteristici non trattati in precedenza. Ove presenti, i commenti tecnici sono stati evidenziati attraverso la seguente notazione: Quello che stai leggendo è un commento tecnico.
1.1 Step 1
Figura 1: STEP 1 ‐ Traccia
10
Lo Step 1 prevede la modellazione di un processo con pochi vincoli, pertanto molti gradi di libertà. La traccia fa riferimento ad un generico processo di TEST e DEBUGGING senza lasciar intendere quali possano essere le sue sotto‐attività. Il processo in questione si presenta nel livello massimo di generalità: le indicazioni potrebbero sembrare incomplete o troppo vaghe ma non è detto che lo siano senza una giusta motivazione: può capitare che al fine del contesto, il progettista non ritenga opportuno dettagliare ulteriormente l’attività. La situazione sopra descritta non è necessariamente sbagliata: un’attività non ha bisogno di essere dettagliata se il livello di granularità è sufficiente per rilevare le misure che si ritengono valide ai fini della valutazione della qualità del processo. In questo contesto, l’attività viene vista come un blocco monolitico. In generale, a maggiore generalità corrisponde un maggior numero di gradi di libertà. Nella descrizione vengono indicati i manufatti entranti e quelli uscenti da tale attività ed anche il ruolo dell’operatore incaricato a svolgerla. Considerando la generalità di tale processo e la presenza di una sola attività è ragionevole concludere che tutti i manufatti entranti ed uscenti verranno associati a quest’unica attività: TEST e DEBUGGING.
Attori Sviluppatore public «ProcessRole» Actor: Attore con competenze nello sviluppo software. Egli assolve responsabilità di carattere generale avendo una preparazione media in tutti i contesti dello sviluppo software. Lo stereotipo ProcessRole indica il ruolo (la figura professionale e non la persona fisica) dell’attore responsabile all’esecuzione di una particolare attività. In questo caso TEST e DEBUGGING.
11
Manufatti Manufatti::Codice_corretto public «WorkProduct» Class: Il manufatto deve rappresentare il codice che può essere direttamente eseguito privo degli errori rilevati. Lo stereotipo WorkProduct indica un particolare manufatto caratterizzato da una rigida e rigorosa strutturazione dei dati. In questa categoria rientrano tutti quei documenti prodotti con precise regole di produzione o in generale fortemente strutturati.
Manufatti::Codice_Sorgente public «WorkProduct» Class: Il manufatto deve essere formato dall'insieme delle righe di codice che compongono il sistema software.
Manufatti::Descrizione_dei_casi_d'uso public «Document» Class: Il manufatto contiene la descrizione in linguaggio naturale semi‐strutturato di ciascun caso d'uso. Lo stereotipo Document indica un particolare manufatto caratterizzato dall’assenza di una strutturazione dei dati contenuti. In questa categoria rientrano tutti quei documenti redatti in linguaggio naturale o debolmente strutturati.
Manufatti::Diagramma_dei_casi_d’uso public «UMLModel» Class: Questo manufatto deve contenere il diagramma dei casi d’uso del sistema software rilevati dall’analista. Il dettaglio del manufatto deve seguire lo standard UML. Lo stereotipo UML Model indica un particolare manufatto il cui contenuto è espresso in linguaggio UML.
Manufatti::Diagrammi_di_sequenza public «UMLModel» Class: Questo manufatto deve contenere per ogni caso d’uso la rappresentazione grafica dell’interazione tra le classi del sistema, focalizzandosi sulla sequenza temporale dei messaggi che si scambiano. Il dettaglio deve segueire lo standard UML.
12
Manufatti::Modello_delle_classi public «UMLModel» Class: Questo manufatto deve contenere la rappresentazione grafica del modello delle classi. Il dettaglio deve seguire lo standard UML.
Manufatti::Piano_dei_casi_di_test public «Document» Class: Il manufatto deve contenere la pianificazione dei differenti casi di test da eseguire.
Manufatti::Report_dei_casi_di_test public «Document» Class: Il documento deve contenere i risultati semi‐strutturati (in forma tabellare) dell'esecuzione di tutti i casi di test.
Manufatti::Report_di_debugging 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 Precondition . ISC.
42
Modello delle Classi disponibile AND Specifica delle Classi disponibile AND Diagramma dei Casi d'Uso disponibile AND Descrizione dei Casi d'Uso disponibile AND Codice Sorgente disponibile • Approved Postcondition . IEC. Piano dei Casi di Test di Unità Nell’attività 1.1.1 Test di unità sono stati inseriti dei vincoli che consistono in Pre‐condizioni e Post‐condizioni. In entrambi i casi si tratta di condizioni che devono essere vere per garantire la corretta esecuzione dell’attività (nel primo caso) e la corretta terminazione dell’attività (nel secondo caso). Nel linguaggio FSPSPEM le condizioni sono definite mediante l’utilizzo di espressioni booleane. In questo caso, l’attività 1.1.1 Test d’unità ha bisogno della disponibilità di cinque manufatti in input per poter essere eseguita. Circa la sua terminazione, ha bisogno che vi sia un solo manufatto in output per considerarsi terminata.
1.1.1 Test di unità Embedded Elements ELEMENT
TIPO
ANNOTAZIONI
Creazione casi di test Black Box
State
Creazione classi di equivalenza
State
Creazione dei cammini indipendenti
State
Creazione dei casi di test White Box
State
Creazione della lista delle classi
State
Creazione della matrice di cross
State
La tabella mostra l’insieme delle attività base che compongono l’attività elementare 1.1.1 Test di unità. Un’attività base è definita come un’attività che trasforma semplicemente un manufatto in input in uno di output. 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:
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_integrazione
Report_casi_di_test_di_unità
+
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 decisionmaking aziendale. Dopo aver disegnato i processi, nasce la necessità di valutarli. In letteratura esistono differenti metodologie operative per la valutazione di processi in termini di qualità. In questo caso quando si parla di qualità ci si riferisce alla “caratteristica desiderata” per un prodotto, processo o risorsa che soddisfi il committente e realizzi il ritorno economico. Quella che si presenta in questa sede è la metodologia Goal Question Metric. L’approccio GQM è basato sull’assunzione che un’organizzazione, per valutare in
65
maniera significativa deve: specificare gli obiettivi aziendali e quelli di progetto; tracciare questi obiettivi con i dati che li definiscono in termini operativi; fornire un ambiente per l’interpretazione dei dati concordemente agli obiettivi fissati. Il risultato dell’applicazione di questo paradigma è la specifica di modelli di misurazione mirati e un insieme di regole per l’interpretazione delle misure. Il modello che ne deriva è articolato su tre livelli: concettuale (Goal), operativo (Question), quantitativo (Metric).
Figura 33: Struttura gerarchica del modello GQM
Goal Un Goal è definito su un preciso oggetto, con differenti punti di vista, in merito a diversi obiettivi di qualità, relativamente ad un particolare contesto. Esso identifica ciò che vogliamo conseguire relativamente ad un prodotto, un processo o una risorsa. Di seguito si riportano i goal. GOAL 1 Analizzare
il processo Pianificazione dei casi di Test di Unità
66
Allo scopo
di valutarlo
Rispetto
all’efficienza
Dal punto di vista dello sviluppatore Nel contesto
del Processo di Testing
GOAL 2 Analizzare
il processo Pianificazione dei casi di Test di Integrazione
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:
Qualità di interes se
Caratterizzazione del processo
GOAL 1
Conformità dell’uso 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 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
Qualità di interesse
Caratterizzazione del processo
Conformità dell’uso 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 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.
Caratterizzazione del processo
GOAL 3 Conformità dell’uso del processo Q3.1 Quali sono i tool di esecuzione dei test d’unità utilizzati nel 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à?
Qualità di interesse
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 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?
Caratterizzazione del processo
GOAL 4 Conformità dell’uso del processo Q4.1 Quali sono i tool di esecuzione dei test d’integrazione utilizzati nel 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?
Qualità di Interesse
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 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
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 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
M1.4.1
ConTecUtilU
Conoscenza di un individuo del team circa le tecniche di pianificazione dei test di unità utilizzate
Q1.4
Q1.5
Etichetta
di
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
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
Q1.7
Q1.8
Q1.9
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
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à
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à
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
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
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
Q2.3
Etichetta
75
Q2.4
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
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
Q2.5
Q2.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
M1.8.1
TPianCTI
Ore/uomo per la pianificazione dei casi di test di integrazione
M2.5.1
NumCTI
Numero di casi di test di integrazione pianificati
M2.5.2
StTPianCTI
Numero standardizzato di ore uomo per pianificare un caso di test di integrazione
M1.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
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
Q2.7
Percentuale di tempo dedicata alla pianificazione dei test di integrazione
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 Q3.1
M3.1.1
Etichetta
Descrizione
ToolsEsecTest
Tool utilizzati per l’esecuzione dei test di unità
77
Q1.3
Q3.2
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
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
Q3.4
Q3.5
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
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à
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à
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
Q3.6
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
M4.2.1
ConToolsUtilEsecTI
Conoscenza di un individuo del team circa i tool utilizzati per l’esecuzione dei test di integrazione
Q4.2
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
M4.4.2
NumCTIEsec
M4.4.3
StTEsecCTI
Numero standardizzato di ore uomo per eseguire un caso di test di integrazione
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
M4.6.1
NumCTIPos
Numero di casi di integrazione positivi
test
di
M2.1.1
NumCTI
Numero di casi di integrazione pianificati
test
di
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
Q4.5
Q4.6
Ore/uomo per l’esecuzione dei casi di test di integrazione Numero di casi di integrazione eseguiti
test
di
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 studio
Scopo
Prospettiva
Punto di vista
Contesto
82
processo di “Pianificazione valutarlo dei casi di Test di Unità”
efficienza
Sviluppatore
Processo di Testing
Quality Focus [Q1.7 , Q1.8, Q1.9]
Variation Factors [Q1.1, Q1.2, Q1.3, Q1.4, Q1.5, Q1.6]
M1.7.3 (StTPianCTU) Numero standardizzato di ore uomo per pianificare un caso di test di unità M1.8.3 (%TPianCTU) Percentuale di tempo dedicata alla pianificazione dei test di unità M1.9.2 (StNumCTU) Numero standardizzato di casi di test di unità pianificati
VF1.1 (TecnTestU) Tecniche di testing per la pianificazione dei test di unità VF1.2 (ToolsUtilU) Tool utilizzati per la pianificazione dei test di unità VF1.3 (%PersExpTest) Percentuale di persone del team esperte di testing 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 [Q1.10, Q1.11, Q1.12] BH1.1: M1.9.2 ≥ M1.10.1 BH1.2: M1.7.3 ≤ M1.11.1 BH1.3: M1.12.1 ‐ 10% ≤ M1.8.3 ≤ M1.12.1 + 10%
Baselines Impacts BI1.1: Migliorare le tecniche utilizzate 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.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 studio
Scopo
Prospettiva
Punto di vista
Contesto
efficienza
sviluppatore
Processo di Testing
processo di “Pianificazione valutarlo dei casi di Test di Integrazione” Quality Focus [Q2.5, Q2.6, Q2.7]
Variation Factors [Q2.1, Q2.2, Q1.3, Q2.3, Q2.4, Q1.6]
M2.5.2 (StTPianCTI) Numero standardizzato di ore uomo per pianificare un caso di test di integrazione M2.6.1 (%TPianCTI) Percentuale di tempo dedicata alla pianificazione dei test d’integrazione M2.7.1 (StNumCTI) Numero standardizzato di casi di test d’integrazione pianificati
VF1.1 (TecnTestI) Tecniche di pianificazione dei test d’integrazione VF1.2 (ToolsUtilI) Tool utilizzati per la pianificazione dei test d’integrazione VF1.3 (%PersExpTest) Percentuale di persone del team esperte di testing VF1.4 (%PersExpTecUtilI) 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 [Q2.8, Q2.9, Q2.10] BH2.1: M2.7.1 ≥ M2.8.1 BH2.2: M2.5.2 ≤ M2.9.1 BH2.3: M2.10.1 ‐ 10% ≤ M2.6.1 ≤ M2.10.1 + 10%
Baselines Impacts BI2.1: Migliorare le tecniche utilizzate per la pianificazione dei test d’integrazione, diminuisce il 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 studio
Scopo
processo di “Esecuzione valutarlo casi di Test di Unità”
Prospettiva
Punto di vista
Contesto
efficienza
sviluppatore
Processo di Testing
Quality Focus [Q3.4 , Q3.5, Q3.6]
Variation Factors [Q3.1, Q1.3, Q3.2, Q3.3]
M3.4.3 (StTEsecCTU) Numero standardizzato di ore uomo per eseguire un caso di test di unità M3.5.3 (%TEsecCTU) Percentuale di tempo dedicata all’esecuzione dei test di unità M3.6.2 (%CTUPos) Percentuale di casi di test di unità positivi
VF3.1 (ToolsEsecTestU) Tool utilizzati per l’esecuzione test di unità VF1.3 (%PersExpTest) Percentuale di persone del team esperte di testing VF3.2 (%PersExpToolsUtilEsecTU) Percentuale di persone del team esperte dei tool utilizzati per l’esecuzione dei test di unità VF3.3 (StLOCStubFitzU) Dimensione standardizzata in LOC degli stub di unità fittizi utilizzati
Baselines Hypothesis [Q3.7, Q3.8, Q3.9] BH3.1: M3.6.2 ≥ M3.7.1 BH3.2: M3.4.3 ≤ M3.8.1 BH3.3: M3.9.1 ‐ 10% ≤ M3.5.3 ≤ M3.9.1 + 10%
Baselines Impacts BI3.1: Migliorare i tool utilizzati per l’esecuzione di test di unità, diminuisce il numero standardizzato di ore uomo 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 studio
Scopo
Prospettiva
Punto di vista
Contesto
efficienza
sviluppatore
Processo di Testing
processo di “Esecuzione casi valutarlo di Test di Integrazione” Quality Focus [Q4.4, Q4.5, Q4.6]
Variation Factors [Q4.1, Q1.3, Q4.2 Q4.3]
87
M4.4.3 (StTEsecCTI) Numero standardizzato di ore uomo per eseguire un caso di test di integrazione M4.5.1 (%TEsecCTI) Percentuale di tempo dedicata all’esecuzione dei test di integrazione M4.6.2 (%CTIPos) Percentuale di casi di test di integrazione positivi
Baselines Hypothesis [Q4.7, Q4.8, Q4.9] BH4.1: M4.6.2 ≥ M4.7.1 BH4.2: M4.4.3 ≤ M4.8.1 BH4.3: M4.9.1 ‐ 10% ≤ M4.5.1 ≤ M4.9.1 + 10%
VF3.1 (ToolsEsecTestI) Tool utilizzati per l’esecuzione dei test di unità VF1.3 (%PersExpTest) Percentuale di persone del team esperte di testing VF4.1 (%PersExpToolsUtilEsecTI) Percentuale di persone del team esperte dei tool utilizzati per l’esecuzione dei test di integrazione VF4.2 (StLOCStubFitzI) Dimensione standardizzata in LOC degli stub di integrazione fittizi utilizzati Baselines Impacts BI4.1: Migliorare i tool utilizzati per l’esecuzione di test di integrazione, diminuisce il numero standardizzato 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 • Come misura: osserva ed elenca quali sono • Chi misura: valutatore del le tecniche utilizzate nel processo di processo di testing pianificazione dei test di unità • Quando misura: prima 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 • Come misura: osserva ed elenca quali sono i • Chi misura: valutatore del tool utilizzati nel processo di pianificazione processo di testing dei test di unità definito • Quando misura: prima 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 • Chi misura: valutatore del processo di testing • Quando misura: prima dell'esecuzione del processo di testing
Specifiche • Come misura: per valutare tale metrica è necessario definire, per ogni persona coinvolta nell’esecuzione del processo, l’esperienza maturata rispetto all’esecuzione di un qualsiasi altro processo di test, scegliendo uno dei valori assegnati: nessuna: la persona non ha alcuna conoscenza di 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 pianificazione dei test di unità, scegliendo uno dei • Quando misura: valori assegnati: prima dell'esecuzione 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 pianificazione dei test di unità, scegliendo uno dei • Quando misura: valori assegnati: prima dell'esecuzione 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 processo, il livello di conoscenza del dominio • Quando misura: applicativo, scegliendo uno dei valori assegnati: prima dell'esecuzione Nessuna: l’individuo non ha lavorato a nessun del processo di testing 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 seguente procedura: il soggetto • Quando misura: prima addetto alla valutazione della metrica dell'esecuzione del processo di ritira, da ogni persona coinvolta nella testing 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 numero totale casi di test d’unità • Quando misura: prima esaminando il manufatto “Piano dei dell'esecuzione del processo di casi di Test d’Unità”. testing 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 seguente procedura: il soggetto • Quando misura: prima addetto alla valutazione della metrica dell'esecuzione del processo di ritira, da ogni persona coinvolta nella testing 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 numero totale delle classi del sistema • Quando misura: prima osservando il suo modello dell'esecuzione del processo di progettuale. testing 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 • Quando misura: prima dell'esecuzione del processo di testing
metrica è necessario rilevare, tramite indagini su web, il numero di casi di test di unità che, in processi analoghi, 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 letteratura, il numero riporta delle • Quando misura: prima ore uomo necessarie per pianificare dell'esecuzione del processo di un caso di test di unità. testing 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 indichi la percentuale di sforzo per la • Quando misura: prima pianificazione dei casi di test d’unità dell'esecuzione del processo di dopo aver preso visione della testing 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 quali sono le tecniche utilizzate nel di testing processo di pianificazione dei test • Quando misura: prima d’integrazione definito dell'esecuzione del processo di 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 quali sono i tool utilizzati nel di testing processo di pianificazione dei test • Quando misura: prima d’integrazione definito dell'esecuzione del processo di 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 ogni persona coinvolta nel processo, • Quando misura: prima il livello di esperienza nelle tecniche dell'esecuzione del processo di di testing, scegliendo uno dei valori testing 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 ogni persona coinvolta nel processo, • Quando misura: prima il livello di esperienza nei tool di dell'esecuzione del processo di pianificazione dei test d’integrazione, testing 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 numero totale casi di test • Quando misura: prima d’integrazione esaminando il dell'esecuzione del processo di manufatto “Piano dei casi di test testing 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 indagini su web, il numero di casi di • Quando misura: prima test di integrazione che, in processi dell'esecuzione del processo di analoghi, sono pianificati per una testing 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 letteratura, il numero riporta delle • Quando misura: prima ore uomo necessarie per pianificare dell'esecuzione del processo di un caso di test di integrazione. testing 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 indichi la percentuale di sforzo per la • Quando misura: prima pianificazione dei casi di integrazione dell'esecuzione del processo di dopo aver preso visione della testing 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 indichi quali tool sono stati utilizzati • Quando misura: durante durante l’esecuzione dei test di unità. dell'esecuzione del processo di 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 ogni persona coinvolta nel processo, • Quando misura: prima il livello di esperienza nei tool di dell'esecuzione del processo di esecuzione dei test di unità, testing 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 effettui il conteggio delle righe di • Quando misura: prima della fase di codice che costituiscono tutti gli stub esecuzione dei casi di test 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 effettui il conteggio degli stub di • Quando misura: prima della fase di unità fittizi utilizzati per l’esecuzione esecuzione dei casi di test 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 • Chi misura: valutatore del processo di testing • Quando misura: alla fine dell’esecuzione del processo di testing
Specifiche • Come misura: per valutare tale metrica è necessario eseguire la seguente procedura: il soggetto addetto alla valutazione della 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 numero totale casi di test d’unità • Quando misura: prima eseguiti esaminando il manufatto dell'esecuzione del processo di “Pianificazione dei casi di Test testing 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 • Chi misura: valutatore del processo di testing • Quando misura: alla fine dell’esecuzione del processo di testing
Specifiche • Come misura: per valutare tale metrica è necessario eseguire la seguente procedura: il soggetto addetto alla valutazione della 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 • Chi misura: valutatore del processo di testing • Quando misura: dopo l’esecuzione della fase “Esecuzione dei casi di test”
Specifiche • Come misura: per valutare tale metrica è necessario contare il numero totale casi di test d’unità positivi esaminando il manufatto “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 indagini su web, il numero • Quando misura: prima di percentuale di casi di test di unità iniziare ad eseguire il processo di positivi che, in processi analoghi, testing 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 • Chi misura: valutatore del processo di testing • Quando misura: prima di iniziare ad eseguire il processo.
Specifiche • Come misura: per valutare tale metrica è necessario rilevare dalla letteratura, il numero standardizzato 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 indichi la percentuale di sforzo per la • Quando misura: Prima esecuzione dei casi di test d’unità dell'esecuzione del processo di dopo aver preso visione della testing 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 indichi quali tool sono stati utilizzati • Quando misura: prima durante l’esecuzione dei test dell'esecuzione del processo di d’integrazione. testing 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 ogni persona coinvolta nel processo, • Quando misura: Prima il livello di esperienza nei tool di dell'esecuzione del processo di esecuzione dei test di integrazione, testing 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 • Quando misura: prima della fase di esecuzione dei casi di test.
metrica è necessario che il valutatore effettui il conteggio delle righe di 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 effettui il conteggio degli stub di • Quando misura: prima della fase di integrazione fittizi utilizzati per esecuzione dei casi di test. 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 numero totale casi di test di • Quando misura: Prima integrazione eseguiti esaminando il dell'esecuzione del processo di manufatto “Pianificazione dei casi di testing 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 • Chi misura: valutatore del processo di testing • Quando misura: dopo l’esecuzione della fase “Esecuzione dei casi di test”
Specifiche • Come misura: per valutare tale metrica è necessario contare il numero totale casi di test di integrazione positivi esaminando 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, tramite indagini su web, il • Quando misura: prima di numero di casi di test di iniziare ad eseguire il processo di integrazione positivi che, in testing 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 • Chi misura: valutatore del processo di testing • Quando misura: prima di
Specifiche • Come misura: per valutare tale metrica è necessario rilevare 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 valutatore indichi la percentuale • Quando misura: Prima di sforzo per la esecuzione dei dell'esecuzione del processo di casi di test di integrazione dopo testing 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
B) M1.12.1 10% <= M1.8.3 <= M1.12.1 + 10% C) M1.9.2 >= M1.10.1
NO
YES
NO
YES
NO
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 team esperte di testing
X
X
X
X
4. Aumentare la percentuale di persone del team esperte delle tecniche di test utilizzate
X
X
X
X
5. Aumentare la percentuale di persone del team esperte dei tool utilizzati
X
X
X
X
6. Aumentare la percentuale di persone del team esperte del dominio applicativo
X
X
X
X
7. Goal soddisfatto
X
1
2
3
4
5
6
7
8
GOAL 2 A) M2.5.2 <= M2.9.1
YES
B) M2.10.1 10% <= M2.6.1 <= M2.10.1 + 10% C) M2.7.1 >= M2.8.1
NO
YES
NO
YES
NO
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 team esperte delle tecniche di test utilizzate
X
X
X
X
5. Aumentare la percentuale di persone del team esperte dei tool utilizzati
X
X
X
X
6. Aumentare la percentuale di persone del team esperte del dominio applicativo
X
X
X
X
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
B) M3.9.1 10% <= M3.5.3 <= M3.9.1 + 10% C) M3.6.2 >= M3.7.1
NO
YES
NO
YES
NO
YES
NO
YES
NO
YES
NO
YES
NO
1. Migliorare i tool utilizzati per l’esecuzione di test
X
X
X
X
2. Aumentare la percentuale di persone del team esperte di testing
X
X
X
X
122
3. Aumentare la percentuale di persone del team esperte dei tool utilizzati
X
X
X
X
4. Aumentare la dimensione standardizzata in LOC degli stub di unità fittizi utilizzati
X
X
X
X
5. Goal soddisfatto
X
1
2
3
4
5
6
7
8
GOAL 4 A. M4.4.3 <= M4.8.1
YES
B. M4.9.1 10% <= M4.5.1 <= M4.9.1 + 10% C. M4.6.2 >= M4.7.1
NO
YES
NO
YES
NO
YES
NO
YES
NO
YES
NO
YES
NO
1. Migliorare i tool utilizzati per l’esecuzione di test
X
X
X
X
2. Aumentare la percentuale di persone del team esperte di testing
X
X
X
X
3. Aumentare la percentuale di persone del team esperte dei tool utilizzati
X
X
X
X
4. Aumentare la dimensione standardizzata in LOC degli stub di unità fittizi utilizzati
X
X
X
X
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
C. M1.7.3 <= M1.11.1
YES
D. M1.12.1 10% <= M1.8.3 <= M1.12.1 + 10% E. M1.9.2 >= M1.10.1
NO NO
YES
NO
YES
YES
NO
NO
YES
NO
YES
NO
YES NO YES NO YES NO YES NO YES NO YES NO YES NO YES NO
1. Goal soddisfatto
X
X
2. Migliorare le tecniche di testing
X
X
X
X
X
X
X
X
3. Migliorare i tool utilizzati
X
X
X
X
4. Aumentare la percentuale di persone del team esperte di testing
X
X
X
X
X
X
X
X
5. Aumentare la percentuale di persone del team esperte delle tecniche di test utilizzate
X
X
X
X
6. Aumentare la percentuale di persone del team esperte dei tool
124
utilizzati 7. Aumentare la percentuale di persone del team esperte del dominio applicativo
X
X
X
X
X
X
X
X
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
C) M1.7.3 <= M1.11.1
YES
D) M1.12.1 10% <= M1.8.3 <= M1.12.1 + 10% E) M1.9.2 >= M1.10.1
NO NO
YES
NO
YES
YES
NO
NO
YES
NO
YES
NO
YES NO YES NO YES NO YES NO YES NO YES NO YES NO YES NO
1. Goal soddisfatto
X
X
2. Migliorare le tecniche di testing
3. Migliorare i tool utilizzati
X
X
X
X
4. Aumentare la percentuale di persone del team esperte di testing
X
X
X
X
X
X
X
X
5. Aumentare la percentuale di persone del team esperte delle tecniche di test utilizzate
X
X
X
X
6. Aumentare la percentuale di persone del team esperte dei tool utilizzati
X
X
X
X
X
X
X
X
7. Aumentare la percentuale di persone del team esperte del dominio
X
X
X
X
X
X
X
X
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
C) M2.5.2 <= M2.9.1
YES
D) M2.10.1 10% <= M2.6.1 <= M2.10.1 + 10% E) M2.7.1 >= M2.8.1
NO NO
YES
NO
YES
YES
NO
NO
YES
NO
YES
NO
YES NO YES NO YES NO YES NO YES NO YES NO YES NO YES NO
1. Goal soddisfatto
X
X
2. Migliorare le tecniche di testing
X
X
X
X
X
X
X
X
3. Migliorare i tool utilizzati
X
X
X
X
4. Aumentare la percentuale di persone del team esperte di testing
X
X
X
X
X
X
X
X
5. Aumentare la percentuale di persone del team esperte delle tecniche di test utilizzate
X
X
X
X
6. Aumentare la percentuale di persone del team esperte dei tool utilizzati
7. Aumentare la percentuale di persone del team esperte del dominio applicativo
X
X
X
X
X
X
X
X
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
C) M2.5.2 <= M2.9.1
YES
D) M2.10.1 10% <= M2.6.1 <= M2.10.1 + 10% E) M2.7.1 >= M2.8.1
NO NO
YES
NO
YES
YES
NO
NO
YES
NO
YES
NO
YES NO YES NO YES NO YES NO YES NO YES NO YES NO YES NO
1. Goal soddisfatto
X
X
2. Migliorare le tecniche di testing
3. Migliorare i tool utilizzati
X
X
X
X
4. Aumentare la percentuale di persone del team esperte di testing
X
X
X
X
X
X
X
X
5. Aumentare la percentuale di persone del team esperte delle tecniche di test utilizzate
X
X
X
X
6. Aumentare la percentuale di persone del team esperte dei tool utilizzati
X
X
X
X
X
X
X
X
7. Aumentare la percentuale di persone del team esperte del dominio applicativo
X
X
X
X
X
X
X
X
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
GOAL 3 A) M3.2.3 >= 70%
YES
NO
127
B) M3.4.3 <= M3.8.1
YES
C) M3.9.1 10% <= M3.5.3 <= M3.9.1 + 10% D) M3.6.2 >= M3.7.1
NO
YES
NO
YES
YES
NO
NO
YES
NO
YES
NO
YES NO YES NO YES NO YES NO YES NO YES NO YES NO YES NO
1. Goal soddisfatto
X
X
2. Migliorare i tool utilizzati per l’esecuzione di test
X
X
X
X
3. Aumentare la percentuale di persone del team esperte di testing
X
X
X
X
X
X
X
X
4. Aumentare la percentuale di persone del team esperte dei tools utilizzati
X
X
X
X
5. Aumentare la dimensione standardizzata in LOC degli stub di integrazione fittizi utilizzati
X
X
X
X
X
X
X
X
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
GOAL 4 A) M4.2.3 >= 70%
YES
B) M4.4.3 <= M4.8.1
YES
C) M4.9.1 10% <= M4.5.1 <= M4.9.1 + 10% D) M4.6.2 >= M4.7.1
NO NO
YES
NO
YES
YES
NO
NO
YES
NO
YES
NO
YES NO YES NO YES NO YES NO YES NO YES NO YES NO YES NO
1. Goal soddisfatto
X
X
2. Migliorare i tool utilizzati per l’esecuzione di test
X
X
X
X
128
3. Aumentare la percentuale di persone del team esperte di testing
X
X
X
X
X
X
X
X
4. Aumentare la percentuale di persone del team esperte dei tools utilizzati
X
X
X
X
5. Aumentare la dimensione standardizzata in LOC degli stub di integrazione fittizi utilizzati
X
X
X
X
X
X
X
X
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 Conoscenza tecniche di testing
Variabile dipendente
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 Conoscenza del dominio applicativo
Variabile dipendente Numero standardizzato dei casi di 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 plevel 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 Conoscenza dei tool
Effort assoluto standardizzato
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 test di integrazione pianificati
Conoscenza del dominio applicativo
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 plevel 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 Insieme dei tool utilizzati
Effort assoluto standardizzato
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à positivi alla prima esecuzione
Grandezza degli stub
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 plevel 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 Insieme dei tool utilizzati
Effort assoluto standardizzato
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 Grandezza degli stub
Variabile dipendente Percentuale di casi di test di 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 plevel 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; • Multipiattaforma: il software è progettato per essere utilizzato su diversi sistemi operativi (Windows 2000/XP/Vista e Linux). Il tutor può utilizzare un particolare sistema operativo per la macchina server senza dover utilizzare lo stesso dei client e viceversa.
163
B.2 Svantaggi L’utilizzo dell’aula virtuale ha comportato alcuni svantaggi legati, in particolar modo, al software utilizzato ed alla capacità di traffico della rete. • Problemi del software: in alcuni casi il software ha presentato problemi di installazione: in modo particolare su quelli con sistema operativo Windows Vista. Altre volte, pur essendo installato correttamente, il software non aggiornava la schermata del computer selezionato dal tutor costringendo il tutor ad aprire e chiudere la relativa finestra; Nella maggior parte delle lezioni è capitato che si siano verificati problemi di riconoscimento dei computer connessi alla rete o connessi alla piattaforma ITALC; • Congestione della rete: la rete utilizzata durante le esercitazioni conta una media di 30 computer connessi. Ogni volta che il tutor condivideva un particolare documento, la rete non riusciva a gestire il traffico e di conseguenza i documenti non potevano essere scaricati.
C. Tools Durante le esercitazioni sono stati introdotti diversi tool a seconda delle diverse problematiche affrontate. I tool utilizzati sono: Enterprise Architect, TABULA e STATISTICA.
C.1 Enterprise Architect Enterprise Architect è un software di modellazione UML estremamente flessibile e completo. Durante le esercitazioni, in particolare, abbiamo utilizzato quest’applicazione per la modellazione di processi FSPSPEM based.
164
Figura 46: Schermata di Enterprise Architect 5.0
Lo strumento è estremamente efficace. A prima vista può apparire complesso e difficile da utilizzare ma dopo aver disegnato i primi modelli ed inserito i primi manufatti diventa facile e veloce.
C.1.1 Vantaggi e svantaggi Il principale vantaggio di Enterprise Architect è il set di diagrammi rappresentabili (forse troppi a tal punto da renderlo complesso) unitamente alla possibilità di inventarne di nuovi (come nel caso di FSP‐SPEM). Purtroppo il software non è gratuito e durante il corso abbiamo sperimentato, nostro malgrado, l’insufficienza del periodo di prova (30 giorni). Il tool per l’esportazione della documentazione in formato Microsoft Word è risultato poco flessibile in termini di layout del documento finale producendo documenti poco leggibili e mal formattati. La versione utilizzata è la 5, dal momento che le versioni più nuove (nel momento in cui scrivo è disponibile la 7) non supportano al meglio il template di FSPSPEM fornitoci dal tutor. Un difetto particolarmente sentito di questo software è la sua natura mono‐ piattaforma: esso può essere installato unicamente su Microsoft Windows XP/Vista.
165
C.2 TABULA TABULA è un’applicazione web a supporto della realizzazione, manutenzione e verifica di tavole di decisione realizzata dal SERLAB di Bari.
Figura 47: Schermata di TABULA
Oltre alla rappresentazione dell’insieme di regole che compongono una tavola, lo strumento in esame agevola (dovrebbe) l’utente nella fase di Verifica e Validazione della stessa. Supporta l’import/export in formato XML ed è multi‐utente: ciascun utente è registrato con credenziali univoche che gli consentono l’accesso esclusivo alla propria area di lavoro. Durante le esercitazioni abbiamo utilizzato questo strumento per la definizione delle tavole di decisione scaturite dalla progettazione del GQM. Ogni gruppo ha creato una propria area di lavoro, registrandosi all’applicazione, nella quale ha potuto procedere alla realizzazione delle tavole.
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 webapplication è utilizzabile da qualsiasi tipo di sistema operativo. Anche in questo caso, però, si sono riscontrati dei problemi di compatibilità con browser diversi da Mozilla Firefox: Microsoft Internet Explorer e Safari.
C.3 STATISTICA Per l’analisi statistica dei dati rilevati abbiamo utilizzato un tool statistico: STATISTICA. Il software presenta un’interfaccia chiara e minimalista in stile Foglio Elettronico all’interno della quale copiare le serie di valori rilevati ed ordinare il calcolo dei vari indicatori numerici e grafici.
167
Figura 48: Schermata di STATISTICA
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 Laboratorio
34
Trattasi di 11 lezioni frontali da 3 ore ciascuna. L’ultima di queste è durata 4 ore.
Studio
30
Per ogni lezione di laboratorio ho stimato
168
individuale
Redazione della documentazione
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 individuale dal momento che coinvolge concetti di teoria, lezioni di laboratorio e risoluzione di problemi legati all’uso dei tool.
58
Effort speso per i tool Di seguito riporto una tabella riepilogativa circa l’effort speso per ciascun tool utilizzato. ATTIVITA’
ORE
DESCRIZIONE
Enterprise Architect
0
Avevo già avuto modo di utilizzare il tool per la realizzazione di modelli di proceso (ed anche per produrre documentazione UML) nel corso di Modelli per la qualità del software.
TABULA
E’ un’applicazione molto facile da imparare ad usare 1* dal momento che dispone di pochissime funzionalità.
STATISTICA
1
Sebbene sia uno strumento estremamente versatile, 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
Related Documents
Note Per La Produzione
October 2019 14
Metodi Per Basso
July 2020 6
Metodi Per Vincere Parte 1
June 2020 6
Metodi Per Vincere Parte 2
June 2020 4