Progettazione di un cruscotto di analisi dei difetti dei componenti in

Transcript

Scuola Politecnica e delle Scienze di Base
Corso di Laurea Magistrale in Ingegneria Informatica
Tesi di Laurea Magistrale in
Progettazione di un cruscotto di analisi
dei difetti dei componenti in sistemi
software large scale
Anno Accademico 2013/2014
relatore
Ch.mo Prof. Stefano Russo
correlatore
Ch.mo prof. Roberto Pietrantuono
Ing. Gabriella Carrozza, SESM
candidato
Giovanni Labanca
matr. M63/000281
Alla mia famiglia e a Roberta
Indice
Introduzione .............................................................................................................................. 9
Capitolo 1. L’analisi dei difetti nei sistemi mission-critical ................................................... 12
1.1 Qualità del Software ........................................................................................................ 12
1.2 Processo di sviluppo software e defect analysis................................................................ 13
1.3 Metodi di analisi dei difetti .............................................................................................. 24
.3.1 IEEE 1044
24
1.3.2 ODC - Orthogonal Defect Classification ....................................................................... 25
1.3.3 HP- Schema di classificazione dei difetti ...................................................................... 31
1.3.3 FST- Faults Slip Through ............................................................................................. 32
1.4 Analisi dei difetti in sistemi Mission Critical ................................................................... 35
1.4.1 Processo di sviluppo Selex ES
35
1.4.2 Ciclo di vita dei difetti
38
Capitolo 2. Strumenti per la gestione e analisi dei difetti ...................................................... 40
2.1 MantisBT ........................................................................................................................ 41
2.2 Atalassian JIRA ............................................................................................................... 48
2.3 Bugzilla ........................................................................................................................... 53
2.4 Buzgero ........................................................................................................................... 60
2.5 Redmine .......................................................................................................................... 61
2.6 Trackstudio...................................................................................................................... 66
2.7 Polarion ........................................................................................................................... 70
2.8 Serena – Issue and Defect Management ........................................................................... 74
2.9 IBM- Rational Quality Manager ...................................................................................... 79
2.10 Tabelle comparative....................................................................................................... 88
2.11 Mantis e Jira a confronto................................................................................................ 91
Capitolo 3. Progettazione di uno strumento di defect analysis .............................................. 97
3.1 Requisiti .......................................................................................................................... 99
3.2 Descrizione.................................................................................................................... 100
3.3 Tecnologie utilizzate...................................................................................................... 101
3.4 Database utilizzato......................................................................................................... 110
Capitolo 4. Esempi di utilizzo ............................................................................................... 116
4.1 Dataset utilizzato ........................................................................................................... 116
4.2 Scenari di utilizzo .......................................................................................................... 117
4.2.1 Panoramica Generale
118
4.2.2 Issues Report
123
III
4.2.4 Component Summary Issues
4.2.5 Assess Debugging Process
4.2.6 Assess Product Quality
130
134
141
Conclusioni e sviluppi futuri ................................................................................................. 142
Code Snippets ........................................................................................................................ 144
Web Service -All Issues
144
Issues Java
145
Issues Service
149
Issues Dao
150
Script per esportare tabelle in file .xls
151
Script per esportare tabelle in file .csv
152
Bibliografia ............................................................................................................................ 154
IV
Elenco delle figure
Figura 1.1 Iron Triangle ................................................................................................................ 13
Figura 1.2 Defect management process ......................................................................................... 18
Figura 1.3 Baseline ....................................................................................................................... 20
Figura 1.4 Reporting ..................................................................................................................... 22
Figura 1.5 Piramide di Anthony e processo di defect management ................................................ 24
Figura 1.6 ODC relazione causa-effetto......................................................................................... 28
Figura 1.7 Associazioni ODC Defect Type - stage del processo .................................................... 30
Figura 1.8 HP schema di classificazione ........................................................................................ 32
Figura 1.9 Modello a V adottato da Selex[20] ............................................................................... 36
Figura 1.10 Ciclo di vita dei difetti in Selex .................................................................................. 39
Figura 2.1 Mantis - Inserimento nuova issue ................................................................................. 42
Figura 2.2 Esempio workflow Mantis ............................................................................................ 47
Figura 2.3 Config_inc.php Mantis ................................................................................................. 47
Figura 2.4 Elementi base Jira ........................................................................................................ 49
Figura 2.5 Workflow built-in Jira .................................................................................................. 51
Figura 2.6 Bugzilla Lifecycle ........................................................................................................ 56
Figura 2.7 Redmine - nuovo tracker .............................................................................................. 62
Figura 2. 8 Redmine - Inserimento nuova issue ............................................................................. 64
Figura 2.9 Aggiornamento issue .................................................................................................... 64
Figura 2.10 Redmine workflow ..................................................................................................... 65
Figura 2.11 Polarion ALM ............................................................................................................ 73
Figura 2.12 Serena issue routing.................................................................................................... 75
Figura 2.13 Serena notifications .................................................................................................... 75
Figura 2.14 Serena form role based ............................................................................................... 76
Figura 2.15 Serena form design .................................................................................................... 77
Figura 2.16 Serena process design ................................................................................................. 77
Figura 2.17 Serena Compliance e Audit ........................................................................................ 78
Figura 2.18 Architettura RQM ...................................................................................................... 81
Figura 2.19 RQM Ruoli ................................................................................................................ 84
Figura 2. 20 RQM-Interfaccia utente ............................................................................................. 85
Figura 2.21 Workflow usato per il confronto ................................................................................. 91
Figura 2.22 Mantis - Categoria csv_imported ................................................................................ 92
Figura 2.23 Mantis - gestione workflow ........................................................................................ 93
Figura 2.24 Jira - workflow grafico ............................................................................................... 94
Figura 2.25 Jira - workflow testuale .............................................................................................. 94
Figura 3.1 Tecnologie usate in effecT! ........................................................................................ 101
Figura 3.2 Esempio path completo risorsa ................................................................................... 107
Figura 3.3 Esempio DTD Hibernate ............................................................................................ 109
Figura 3.4 Database effecT! ........................................................................................................ 111
Figura 3.5 Tabella issue effecT! .................................................................................................. 113
Figura 3.6 Mantis_bug_table e Jiraissue table.............................................................................. 114
Figura 4.1 Form Login e sezioni effecT! ..................................................................................... 117
Figura 4.2 Sezione KPIs .............................................................................................................. 118
Figura 4.3 Requirements Analysis KPIs ...................................................................................... 119
V
Figura 4.4 Sezione Implentation effecT! ..................................................................................... 120
Figura 4.5 Global View ............................................................................................................... 121
Figura 4.6 Global View file .xls .................................................................................................. 121
Figura 4.7 Global View file .csv .................................................................................................. 122
Figura 4.8 Nuovo progetto .......................................................................................................... 122
Figura 4.9 Issues Report .............................................................................................................. 123
Figura 4.10 Distribuzione livelli di Severity di tutti i componenti ................................................ 124
Figura 4.11 Distribuzione livelli di priority di tutti i componenti ................................................. 125
Figura 4.12 Distribuzione livelli di reproducibility di tutti i componenti ...................................... 126
Figura 4.13 Distribuzione livelli di status di tutti i componenti .................................................... 127
Figura 4.14 Distribuzione livelli di resolution di tutti i componenti ............................................. 128
Figura 4.15 Component Level View ............................................................................................ 129
Figura 4.16 Component1-Issues For Resolution .......................................................................... 130
Figura 4.17 Summary Component - Menu ................................................................................... 131
Figura 4.18 Summary Component Reproducibility ...................................................................... 132
Figura 4.19 Summary Component -Severity ................................................................................ 133
Figura 4.20 Summary Component ............................................................................................... 134
Figura 4. 21 Menu Viste .............................................................................................................. 135
Figura 4.22 Assess Debugging Process ....................................................................................... 136
Figura 4.23 Day - All component ................................................................................................ 137
Figura 4.24 Week - All component.............................................................................................. 137
Figura 4.25 Month - All component ............................................................................................ 138
Figura 4.26 Year - All component ............................................................................................... 138
Figura 4.27 Day - component1 .................................................................................................... 139
Figura 4.28 Week - component1.................................................................................................. 139
Figura 4.29 Month - component1 ................................................................................................ 140
Figura 4.30 Year - component1 ................................................................................................... 140
Figura 4.31 Assess Product Quality ............................................................................................. 141
VI
Elenco delle tabelle
Tabella 1.1 IEEE 1044 attributi di classificazione ......................................................................... 25
Tabella 1.2 ODC defect-type ......................................................................................................... 29
Tabella 1.3 ODC defect-trigger ..................................................................................................... 29
Tabella 1.4 Attributi di classificazione .......................................................................................... 31
Tabella 1.5 FST matrice di esempio .............................................................................................. 33
Tabella 1.6 Esempio di calcolo del miglioramento con FST .......................................................... 34
Tabella 1.7 FST fault type e ODC class ......................................................................................... 34
Tabella 2.1 Confronto Tools (1/3) ................................................................................................. 89
Tabella 3. 1 Mapping operazioni CRUD - HTTP......................................................................... 104
Tabella 3. 2 JAX-RS Annotation ................................................................................................. 107
VII
ACRONYM
ATC
ATM
Captcha
CBSE
CoQ
COTS
CSCI
CSS
CUPRIMD
DM
DTD
FST
HATEOS
ICD
IDD
IRS
KPI
LDPA
NLTM
ODC
RQM
RUP
SCM
SITD
SITR
SDD
SPRs
SRA
SRGM
SRS
SSDD
SSS
STD
STP
TCO
VTMSI
V&V
DEFINITION
Air Traffic Control
Air Traffic Management
Completely automated public Turing test to tell computers and
humans apart
Component-based software engineering
Cost of Quality
Commercial off the shelf
Computer Software Configuration Item
Cascading Style Sheets
Capability, Usability, Performance, Reliability, Installability,
Maintainability e Documentation
Defect Management
Document Type Definition
Faults Slip Through
Hypermedia As The Engine Of Application State
Interface Control Document
Interface Design Document
Interface Requirements Specification
Key Performance Indicators
Lightweight Directory Access Protocol
Network Lan Manager-suite di protocolli di sicurezza di Windows
per l’atenticazione
Orthogonal Defect Classification
Rational Quality Manager
Rational Unified Process
Source Code Management
Software Integration Test Description
Software Integration Test Report
Software Design Description
Software Problem Reports
Software Requirement Analysis
Software Reliability Grow Model
Software Requirement Specification
System/Subsystem Design Description
System/Subsystem Specification
Software Test Description
Software Test plan
Total Cost of Ownership
Vessel Traffic Management Information System
Verification and Validation
VIII
Progettazione di un cruscotto di analisi dei difetti
dei componenti di sistemi software large-scale
Introduzione
Il contesto applicativo di questo lavoro di tesi è l’analisi dei difetti nei sistemi
mission-critical. Questa tipologia di sistemi rappresenta una delle tre categorie
previste dalla classificazione di Sommerville ([1]) e trova applicazione in diversi
settori: controllo del traffico areo, ferroviario, navale e difesa.
Un sistema critico deve rispettare rigidamente i requisiti su cui si fonda perché una
possibile interruzione di servizio o un funzionamento in condizione degradate
potrebbe originare danni gravi, in certi casi anche catastrofici, a persone, cose e
ambiente. Questo si riflette sulla progettazione di tali sistemi che risulta essere
particolarmente onerosa per diverse ragioni. Infatti al fine di soddisfare requisiti di
reattività e affidabilità devono essere rispettati standard imposti dai domini di
applicazione, la notevole dimensione in termini di linee di codice a cui si aggiungono
i requisiti di qualità dovuti alle attività di Verifica e Validazione sono tutti fattori che
provocano un aumento di complessità e che si riverbera sui costi totali del processo
di sviluppo.
L’analisi dei difetti, applicata a questi sistemi, sfrutta come patrimonio informativo i
bug rilevati durante le varie fasi, mettendo a punto un vero e proprio processo di
assessment per migliorare la qualità del processo di sviluppo , cercando di contenere
quanto più è possibile i costi.
Questo rappresenta il requisito su cui si basa il lavoro di tesi: realizzare uno
strumento di analisi a supporto del processo decisionale aziendale, per la valutazione
9
dei processi software fattibili a partire dai difetti e dai corrispondenti campi di
caratterizzazione. Concretamente il processo rappresenta un supporto alle decisioni
di manager/ingegneri che lavorano ad un alto livello di astrazione, in cui ogni analisi
è inquadrata sotto i tre fattori: qualità, costo e tempo. Lo strumento si pone
l’obiettivo di contribuire al miglioramento di uno dei tre fattori o il trade-off tra di
essi. Nonostante siano presenti sul mercato, numerosi software e/o sistemi di
bug/issues tracking diverse sono le motivazioni che giustificano la realizzazione di
questo strumento.
In primis, possiamo evidenziare la necessità di “trattare” i vari bug con uno schema
di classificazione personalizzato che riflette al meglio le esigenze del contesto
aziendale in cui sarà utilizzato. Questo permette di ovviare al problema che i dati
possano provenire da diverse sorgenti di informazioni e rappresentati in diversi
formati. Inoltre lo strumento che è stato realizzato, verrà utilizzato da tutti i reparti
aziendali, in modo da non creare discordanze nella gestione dei difetti e garantire
dunque una certa universalità sia in termini di utilizzo che in termini di informazioni
fornite. A questi si aggiunge l’esigenza di realizzare uno strumento che supporti un
processo di valutazione dei componenti e quindi indirettamente dei diversi fornitori
responsabili della loro realizzazione, cosa che nella realtà aziendale a cui ci
rivolgiamo non è ancora presente. Infine, la reportistica generata e le informazioni
fruibili da questo strumento, sono state realizzate in relazione alle necessità e al
processo si assessment delineati dalla realtà aziendale considerata in questo lavoro.
Lo studio sarà condotto su un dataset di difetti reali, raccolti su un insieme di
componenti software di sistemi mission-critical, large scale, realizzati da SESM.
I risultati dello studio, permettono di mettere in luce le caratteristiche dei singoli
componenti considerati, in relazione a diversi attributi previsti per la loro
classificazione e consentono di evidenziarne le anomalie rispetto ai processi previsti
di detection e fixing. Queste informazioni sono necessarie per il processo decisionale
e per il raggiungimento del trade-off tra i tre parametri: qualità, tempo e costo.
10
Roadmap
Capitolo 1
Ha lo scopo di fare una panoramica sulla qualità del software e dei principali aspetti
ad essa collegati. Presenta dettagliatamente l’analisi dei difetti e le sue finalità
evidenziandone i vantaggi. Contiene cenni alle tecniche di gestione dei difetti (ODC,
HP e IEEE 1044) per poi concludere con la presentazione dei sistemi missioncritical, contesto di questa attività di tesi.
Capitolo 2
Viene proposto uno scouting di tools per la gestione dei difetti con esempi di
funzionamento, che pongono l’accento sulle caratteristiche più importanti ( livello di
customizzazione e criteri per la classificazione/gestione dei bug) per poi concludere
con un quadro riassuntivo per mettere a confronto i vari tools analizzati.
Capitolo 3
Si descrivono scelte progettuali ed implementative fatte per la realizzazione di un
cruscotto di analisi dei difetti nel quadro delle attività di valutazione della qualità del
software in un contesto industriale di produzione di sistemi complessi missioncritical.
Capitolo 4
Contiene esempi di utilizzo dello strumento realizzato e data set utilizzato.
11
Capitolo 1. L’analisi dei difetti nei sistemi mission-critical
1.1 Qualità del Software
Il processo di Defect Analysis si articola in una serie di fasi che si specializzano in
relazione al contesto in cui vengono applicate , con la finalità di offrire supporto sia
al processo di sviluppo ma anche ai livelli superiori della piramide gerarchica
aziendale. Questo perché si mira a realizzare un prodotto che sia conforme a
determinati requisiti di qualità. La definizione della qualità del software è data
tipicamente considerando due livelli:
1. La qualità intrinseca del prodotto.
2. La qualità del prodotto rispetto alle aspettative/soddisfazioni del cliente([2]).
Esistono diversi approcci per la qualità intrinseca del prodotto, che possono essere
distinti in: approcci sulla gestione dei difetti e approcci sulla qualità degli attributi.
I primi focalizzano l’attenzione sulla gestione dei difetti, mentre i secondi mirano a
valutare la qualità del software considerando fattori qualitativi (per esempio:
usability, interoperability, reliability ecc.). A prescindere dalla tipologia di modello
adottato per lo sviluppo, la gestione di un progetto di sviluppo software deve tenere
in considerazione due concetti: CoQ (Cost of Quality) e Iron Triangle ([3],[4]).
Il CoQ tenta di misurare il costo collegato al raggiungimento di risultati di qualità
nei progetti o in generale in ogni attività di sviluppo/produzione. In breve esso
afferma che, per ottenere qualità, è necessario investire prima nel senso che tutte le
fasi del processo realizzativo devono essere svolte secondo precisi criteri per
12
assicurare che abbiano determinati livelli qualitativi.
Il secondo concetto, l’Iron Triangle (Figura 1.1 Iron Triangle), permette di
relazionare le tre grandezze, qualità, tempo e costo in relazione ai cambiamenti che
vengono apportati al progetto e alla gestione delle risorse. Infatti da esso sarà
possibile osservare come un determinato cambiamento, ad esempio sul budget, possa
riflettersi sulla qualità attesa o sui tempi di realizzazione di un prodotto.
Figura 1.1 Iron Triangle
1.2 Processo di sviluppo software e defect analysis
Possiamo definire il processo software come l’insieme delle attività che
caratterizzano la produzione di sistemi software. Queste attività possono essere
rivolte allo sviluppo di un sistema ex novo, oppure all’integrazione di componenti
già esistenti (off-the-shelf ) per accelerare il processo di sviluppo. L’ingegneria del
software è un campo complesso, molto ampio e creativo che non impone l’adozione
di un determinato modello ma la scelta può essere determinata dalle caratteristiche
del sistema che si deve realizzare e/o dalla tipologia dall’ambiente operativo.
Tuttavia esistono quattro attività che devono essere svolte a prescindere dal tipo di
modello:
13
1. Specifica del software. La definizione dei vincoli e delle funzionalità del
software.
2. Progettazione ed implementazione. Come viene progettato il software per
essere conforme alle specifiche.
3. Validazione del software. Verifica del funzionamento nel rispetto delle
specifiche richieste.
4. Evoluzione del software. Adattamento del software ad eventuali cambiamenti
delle esigenze del cliente.
I modelli più adottati nell’ingegneria del software sono:
 Modello a cascata (Waterfall Model). Formato da sette fasi (Studio di
fattibilità, Analisi dei requisiti, Progetto, Codifica, Collaudo, Integrazione e
Manutenzione) si fonda sull’idea che il risultato di ogni fase fornisca l’input
per la fase successiva, dunque, implica la definizione in modo chiaro e
immutabile di tutti i requisiti del sistema (in realtà pochissimi sistemi hanno
questa caratteristica). Questo rappresenta un grande limite in termini di
flessibilità del modello, dal momento che lo sviluppo software è sempre più
orientato a seguire i feedback provenienti dalle singole fasi e adattarne il
processo di sviluppo. E’ un modello lineare, molto rigido.
 V-Model. E’ un evoluzione del modello a cascata, da cui ne eredita la
sequenzialità dei passi da compiere ma prevede lo sviluppo di procedure di
verifica e di validazione nell’ambito di ogni fase del processo che precede la
codifica.
 Sviluppi evolutivi. Prevedono il rilascio di una versione base da presentare al
cliente, esplorarla e rifinirla in base alle richieste. Sono previste due modalità:
Sviluppo Esplorativo e Prototipo Usa e Getta, entrambi possono essere
applicati a progetti di piccole dimensioni.
 Ingegneria basata sui componenti (CBSE). Sviluppo basato sul riuso
sistematico, integrando componenti esistenti o interi sistemi COTS. Fasi del
14
Processo: Specifica dei requisiti, Analisi dei componenti, Modifica dei
Requisiti (specificando i componenti disponibili), Progettazione con riuso,
Sviluppo e Integrazione. Questo approccio viene sempre più usato grazie
all’affermarsi di appositi standard per la specifica di componenti.
 RUP (Rational Unified Process). E’ un moderno modello di processo software
derivato da UML e dal relativo processo. Prevede sei pratiche fondamentali:
sviluppare il software ciclicamente, gestire i requisiti, usare architetture basate
sui componenti, creare modelli visivi del software, verificare la qualità del
software e controllare le modifiche al software. Si articola in quattro fasi:
Avvio, Elaborazione, Costruzione e Transizione. La fase di avvio, permette di
stabilire gli obiettivi di business (con relativi limiti, fattibilità e giustificazioni
economiche) per il sistema e organizzare le risorse necessarie alla sua
soluzione. Elaborazione, permette di ottenere una comprensione del dominio
del problema (specificare i requisiti), stabilire una struttura architetturale ed il
piano di progetto. Costruzione, prevede di progettare, programmare e testare il
sistema incrementalmente. Infine la fase di Transizione è finalizzata a
trasferire il sistema nel suo ambiente operativo.
 Metodi agili. Si concentrano sul codice piuttosto che sulla progettazione e si
basano su un approccio iterativo allo sviluppo software. Sono pensati per
rilasciare software funzionante rapidamente e per farlo evolvere rapidamente
per soddisfare nuove esigenze. Propongono di coinvolgere il cliente il più
possibile nel processo di sviluppo e sono più adatti per sistemi aziendali di
piccole/medie dimensioni o a prodotti per PC. Esempio di metodi agili sono
l’Extreme Programming.
Attività molto importanti che si svolgono parallelamente alle fasi di sviluppo e di
progettazione, sono la verifica e validazione (V&V). Queste attività costituiscono
una parte fondamentale dei processi e incidono su più del 50% dei costi totali di un
progetto. La verifica è un’attività che guida il processo attraverso la costruzione di
15
un prodotto che soddisfa i requisiti, controllando la qualità dello stato intermedio e
del prodotto finale. La validazione, invece, è un’attività che certifica la
corrispondenza tra artefatti intermedi, prodotto finale e i requisiti attesi dal cliente.
Gli approcci comunemente utilizzati dalla V&V sono:
 Analisi statica: processo di valutazione di un sistema o di un suo componente
basato sulla sua forma, struttura, contenuto, documentazione esterna e senza
che esso sia eseguito.
 Analisi dinamica: prevede l’esecuzione di un sistema software o di un suo
componente.
Una delle principali attività di analisi dinamica è il testing. Il testing, coinvolge
l’esecuzione del software sottoponendolo a casi di test, al fine di verificare che
l’output e il comportamento del software siano conformi a quanto stabilito nelle
specifiche e a quanto richiesto dal cliente. Ulteriori tecniche di analisi dinamica, sono
quelle che mirano ad identificare problemi che potrebbero emergere durante
l’esecuzione del software, come ad esempio i race condition, memory leaks ecc.
Nell’ambito dei processi di sviluppo e manutenzione, il testing, è eseguito a diversi
livelli di granularità. I quattro livelli principali indipendenti dal modello di processo
software sono:
 Unit testing. Le unità o i componenti del software sono testate
individualmente. Lo scopo è validare ogni unità rispetto a come è stata
progettata.
 Integration testing. Le unità o i componenti sono combinati tra loro e testati
insieme. Lo scopo è individuare difetti che emergono dalla loro interazione.
 System testing. E’ eseguito sul sistema che ha superato il processo di
integrazione. L’obiettivo è valutare che il sistema sia aderente ai requisiti
specificati.
 Acceptance testing. Il sistema è testato con dati forniti dal cliente del sistema;
esso può rilevare errori e omissioni nella definizione dei requisiti di sistema.
16
A supporto di queste attività, si sta affiancando da alcuni anni l’analisi dei difetti,
grazie alla quale si cerca di migliorare qualitativamente l’intero processo di
produzione del software, considerando come informazioni i difetti rilevati nelle
precedenti versioni o durante lo sviluppo. Questi difetti rappresentano una fonte
importantissima di informazione per la valutazione e il miglioramento del processo,
tanto che il loro monitoraggio è considerato una pratica raccomandata
dai più
importanti standard di processo software. Queste tecniche si fondano sull’idea che
non ci sono software o pezzi di codice immuni da difetti o almeno che non possono
essere rilevati tramite testing, pertanto alcuni di essi, possono essere evitati o rilevati
per poi risalirne alle cause e cercare di minimizzarne l’impatto sul sistema. Tra gli
obiettivi che portano alla definizione di un processo di defect management abbiamo:
 il controllo e miglioramento del processo software, che prevede un tracking
per la fase di implementazione, rilevamento e fixing per migliorare il processo
in ogni singola fase.
 la costruzione di una base per la conoscenza da poter sfruttare in future analisi
e processi di miglioramento.
I requisiti su cui si deve fondare un processo di defect management sono :
 Bassa intrusività. I tools e le tecniche utilizzate non devono interferire con
l’operativa del sistema.
 Basso costo. Le politiche aziendali non prevedono budget, almeno per il
momento, per attività di defect analysis quindi i costi ad esse associate non
devono essere particolarmente esosi. Inoltre le attività di raccolta dei dati,
filtering e analisi devo essere svolte se è possibile in maniera automatizzata.
 Basso impatto sulle pratiche di sviluppo attuale. Ridurre al mimino le
modifiche alla vita quotidiana degli sviluppatori per ragioni pratiche e
filosofiche. Lo sforzo richiesto ai lavoratori per la raccolta dei dati di analisi,
deve essere minimo così da evitare l’introduzione di stress aggiuntivi.
Un esempio di processo di defect management è mostrato in Figura 1.2. E’ bene
17
ricordare che il processo di defect management non è generale, ma può essere
customizzato in relazione alla realtà aziendale a cui si deve applicare, cosa che può
comportare l’aggiunta/rimozione di altre fasi.
Figura 1.2 Defect management process
Analizziamo le singole fasi che compongono il processo.
Defect Prevention. La prevenzione dei difetti dovrebbe iniziare con una valutazione
dei rischi critici associati al sistema. Questa valutazione, permette di conoscere quali
sono i tipi di difetti che si manifesteranno e la loro severità, sviluppando strategie
apposite per la loro risoluzione. La fase di defect prevention, prevede i seguenti
passi: identificazione dei rischi critici, stima dell’impatto sul sistema e
minimizzazione dell’impatto. Per quanto riguarda l’identificazione dei rischi critici
(sono quelli che compromettono l’intero sviluppo/esercizio del sistema ), bisogna
18
tener conto che variano da un progetto all’altro a seconda del tipo di sistema,
hardware, utenti ecc. ragion per cui possono essere diversi.
E’ bene ricordare che questa analisi è volta solo ad identificare i difetti critici, ovvero
quelli che compromettono il funzionamento corretto o lo sviluppo dell’intero
sistema. Segue all’identificazione la fase di valutazione in termini di impatto
finanziario che ogni rischio può avere sul sistema. Questo potrebbe essere fatto
valutando l’impatto in dollari/euro (I) se il rischio non diventa un problema
combinato con la probabilità (P) che il rischio diventi un problema. L’impatto atteso
può essere indicato con E =P*I. Una volta determinato l’impatto di ogni singolo
rischio, è buona norma caratterizzare tali rischi assegnando loro un valore di priorità.
Uno dei metodi per stimare l’impatto atteso di un rischio è la formula di perdita di
aspettativa annuale (ALE), secondo la quale il verificarsi di un rischio può essere
definito da un evento. Un danno per ogni evento, può essere definito come la perdita
media per un campione di ogni evento. La formula afferma che l’ALE è uguale al
danno per ogni evento moltiplicata per il numero di eventi. (Ad esempio, se il rischio
è che il sistema software termina anormalmente, allora il costo medio di correggere
un’interruzione anomala viene calcolato moltiplicando il numero atteso di
terminazioni anomale associate a questo rischio[8]). Infine vi è la fase di
minimizzazione dell’impatto, che prevede l’applicazione congiunta delle tre strategie
seguenti: eliminazione dei rischi, riduzione della probabilità che il rischio diventi un
problema e riduzione dell’impatto qualora si dovesse verificare un problema (disaster
recovery e piani di emergenza ne sono un esempio). Esistono una serie di tecniche
che ci permettono di minimizzare l’impatto dei difetti agendo sulla fase di
progettazione: Quality Assurance, Formazione ed istruzione del personale, Adozione
di Metodologie e Standards, Progettazione difensiva, Codice Difensivo (anche se non
molto utilizzato).
Deliverable Baseline. In questo modello, un difetto è definito come un’istanza di
uno o più componenti del prodotto “baselined” non rispondenti ad un insieme di
19
requisiti dati. Quindi un componente diventa baseline quando sono stati identificati e
corretti i difetti, cosa che permette al componente di passare allo stadio successivo
del processo di sviluppo e quindi di avere impatto in termini di errori sul prodotto
finale o su altri componenti su cui stanno lavorando altri sviluppatori. Un deliverable
è soggetto alla gestione della configurazione (controllo dei cambiamenti) una volta
che è diventato baseline. In relazione a questo modello, gli errori rilevati prima che
un deliverable diventi baseline, non vengono considerati tali. Ad esempio, se
consideriamo il caso in cui un programmatore è responsabile sia dello sviluppo che
del test di un componente, quest’ultimo non può essere considerato baseline fino a
quando non viene testato. Questo significa che un bug scoperto durante lo unit-test,
non sarebbe considerato un difetto. Se invece l’organizzazione decide di separare le
due attività potrebbe decidere, dopo lo sviluppo, di dichiarare il componente come
baseline cosa che comporterebbe durante la fase di test la classificazione di eventuali
bug come difetti.
Figura 1.3 Baseline
Deliverable baselined comporta due principali attività ([9]):
 Identificazione dei prodotti chiave, quelli che diventeranno baseline dopo
determinate fasi del processo di sviluppo
 Definire degli standard per ogni deliverable, impostare dei requisiti e dei
criteri da rispettare da ognuno di essi prima che diventino baseline.
20
Defect Discovery. Dato che è importante ridurre al minimo il tempo che intercorre
tra l’origine del difetto e la sua manifestazione/identificazione, sono previste una
serie di strategie che devono essere attuate per scoprire il difetto e facilitarne il
reporting. Alla base di questo, vi è una preventiva classificazione dei difetti in classi,
articolata in tre sotto-fasi: Ricerca, Report e Acknowledge. La ricerca può essere
svolta tramite tecniche statiche (senza eseguire il codice), tecniche dinamiche
(eseguendo i moduli codice) e infine tramite tecniche operazionali che prevedono di
identificare i difetti al momento della verifica di un fallimento. La fase di Report,
prevede che i difetti trovati siano comunicati agli sviluppatori. Al crescere delle
dimensioni del software questi meccanismi devono essere molto dettagliati, per
consentire ai vari sviluppatori di avere una visione più dettagliata grazie ad una
granularità più fine delle informazioni. Infine, la fase di Acknowledge, prevede che
lo sviluppatore decida se i difetti trovati sono da classificarsi come tali o possono
essere considerati eventi occasionali. Ritardi in questa fase possono avere dei
riverberi a livello economico. Una delle principali cause di ritardo è correlata
all’incapacità di riprodurre i difetti. Purtroppo difetti irriproducibili si manifestano
sempre più di frequente e pertanto, gli sviluppatori sono chiamati a mettere a punto o
ad adottare tecniche che permettano di riuscire a valutare la natura dei difetti, in
tempi brevi per contenere i costi.
Defect Resolution. Il processo ha inizio una volta che gli sviluppatori hanno
riconosciuto un difetto valido. Esso comprende tre fasi: Prioritize Risk, Schedule Fix
and Detect Fix, Report Resolution. La fase di Prioritize Risk, è tipicamente basata su
una combinazione di gravità dell’impatto sull’utente, sforzo relativo di risoluzione e
su un confronto con altri difetti aperti. A seconda delle dimensioni e della struttura
dell’organizzazione, l’ordine di priorità è spesso gestito da un consiglio formale di
controllo delle modifiche. La priorità deve essere determinata con il cliente e il team
di progetto per poter identificare le criticità del sistema. Una volta fissata la priorità
del difetto, esso sarà assegnato ad uno sviluppatore (o a un team) che provvederà alla
21
sua risoluzione. Risolto il difetto verrà applicata la soluzione nell’ambiente
(componente/modulo software) in cui il difetto è stato rilevato. Seguono le fasi di
Verifica e di Chiusura.
A seconda dell’ambiente in cui è stato trovato il difetto e dalla correzione che è stata
applicata, la squadra test del software o cliente verifica che il difetto sia stato
effettivamente risolto. Una volta che un difetto è stato risolto e verificato, il difetto
sarà contrassegnato come chiuso.
Naturalmente i difetti, vengono analizzati e risolti in relazione alla loro severità e alla
loro priorità, poiché difetti critici (quelli che ad esempio causano l’interruzione del
servizio, blocco del sistema ecc.) anche se presenti in numero ridotto avranno
sicuramente una priorità maggiore rispetto ad altri a cui sono collegati eventi di
minore rilevanza. E’ buona norma condurre e concludere il fixing con la redazione di
report in cui si riporta il workflow eseguito per la risoluzione dei difetti e buona parte
delle informazioni collegate al difetto (es. modulo in cui è stato riscontrato,
caratteristiche, data di detection, data di fixing, team o sviluppatore da cui è stato
preso in carica ecc.). Questo perché il processo di defect management tende ad essere
un processo automatizzato, grazie all’ausilio di tools che ne consentono un approccio
distribuito, in modo da soddisfare le esigenze di grandi aziende che spesso sono
dislocate in regioni o stati differenti.
Figura 1.4 Reporting
22
Process Improvement. I difetti raccolti, indipendentemente dalla loro natura,
saranno utilizzati per la costruzione di una base di conoscenza da utilizzare per
migliorare tutto il processo di sviluppo. Infatti a partire dai dati raccolti si dovrebbe
tornare indietro ad analizzare le parti del processo che contengono o che hanno
originato il difetto. Questo dovrebbe essere fatto sia per difetti più importanti e sia
per difetti che apparentemente sembrano avere una scarsa rilevanza, poiché ad essi
potrebbero essere connessi potenzialmente dei grandi fallimenti che però non sono
stati analizzati. In definitiva ogni difetto, indipendentemente dalla sua natura, è
un’occasione per apprendere e migliorare il processo di sviluppo.
Management reporting. Le informazioni raccolte hanno lo scopo di segnalare lo
stato dei singoli difetti e fornire informazioni tecniche e metriche per aiutare la
gestione del progetto a prendere decisioni più dettagliate, come ad esempio la
riprogettazione dei moduli affetti da errore e la necessità di ulteriori test o la
comprensione delle aree in cui il processo potrebbe essere migliorato per impedire il
sorgere di difetti o ridurne al minimo il loro impatto. La segnalazione è un aspetto
necessario e di fondamentale importanza del processo di gestione dei difetti, ma è
anche importante farne un uso mirato e non eccessivo, in modo tale da garantire che
le informazioni che si producono hanno uno scopo preciso e rappresentano realmente
un valore aggiunto al processo di gestione dei difetti.
E’ bene ricordare che i dati raccolti sono alla base del processo di gestione dei difetti,
rappresentando una fonte preziosa di informazione per tutte le figure presenti in un
contesto aziendale. Questo perché si differenziano nel livello di dettaglio,
permettendo di soddisfare le esigenze in relazione al loro livello gerarchico.
La figura 1.5 mostra il processo di defect management in relazione alla piramide
aziendale.
23
Figura 1.5 Piramide di Anthony e processo di defect management
1.3 Metodi di analisi dei difetti
I metodi o schemi di classificazione dei difetti, definiscono un insieme di attributi e
un insieme di valori per tali attributi, dove ognuno di essi ha lo scopo di evidenziare
un aspetto specifico del difetto come ad esempio sintomi, tipo e meccanismo di
iniezione. Gli schemi di maggiore riferimento in letteratura possono essere
classificati in due categorie in base alla loro origine: standard e industrial.
1.3.1 IEEE 1044
Rilasciato da IEEE nel 1993, rappresenta uno degli standard più importanti per la
classificazione dei difetti software. Lo standard fornisce un approccio uniforme per
la classificazione dei difetti, senza considerare in quale progetto siano stati rilevati,
come si siano manifestati e senza riferimento al software life-cycle. Questo
conferisce allo standard una grande generalità, cosa che ne permette l’adozione e
l’utilizzo per scopi differenti: project management, defect casual analysis e software
process improvement (ad esempio, per ridurre la probabilità di inserimento difetto
e/o per aumentare la probabilità di diagnosi precoce difetto [10]). La tabella 1.1
24
mostra gli attributi dei difetti proposti da questo schema di classificazione.
Tabella 1.1 IEEE 1044 attributi di classificazione
Attribute
Definition
Defect ID
Description
Status
Asset
Artefact
Version detected
Version corrected
Priority
Unique identifier for the defect.
Description of what is missing, wrong, or unnecessary.
Current state within defect report life cycle.
The software asset (product, component, module, etc.) containing the defect.
The specific software work product containing the defect.
Identification of the software version in which the defect was detected.
Identification of the software version in which the defect was corrected.
Ranking for processing assigned by the organization responsible for the evaluation,
resolution, and closure of the defect relative to other reported defects.
The highest failure impact that the defect could (or did) cause, as determined by
(from the perspective of) the organization responsible for software engineering.
Probability of recurring failure caused by this defect.
The class of requirement that is impacted by a failure caused by a defect.
A categorization based on the class of code within which the defect is found or the
work product within which the defect is found.
A categorization based on whether the defect is due to incorrect implementation
or representation, the addition of something that is not needed, or an omission.
The activity during which the defect was injected/inserted (i.e., during which the
upport containing the originated defect).
The activity during which the defect was detected (i.e., inspection or testing).
Identifier of the failure(s) caused by the defect.
Identifier of the corrective change request initiated to correct the defect.
Final disposition of defect report upon closure.
Severity
Probability
Effect
Type
Mode
Insertion activity
Detection activity
Failure reference(s)
Change reference
Disposition
Esistono altri schemi di classificazione dei difetti, adottati dalle industrie che non
considerano l’approccio concettuale. Tra essi possiamo annoverare ODC e HP.
1.3.2 ODC - Orthogonal Defect Classification
La tecnica ODC è stata introdotta da Ram Chillarege ([11]), ricercatore presso IBM.
Può essere considerata il risultato di un insieme di studi precedenti sulla relazione tra
la semantica dei fallimenti e il processo di sviluppo software, affermandosi come un
potente strumento per la raccolta di informazioni legate al processo di sviluppo.
E’ una tecnica che mira a migliorare la qualità del software inserendo il processo di
sviluppo in un modello basato su analisi e misure statistiche. La tecnica ODC cerca
di collocarsi al centro dei due estremi, analisi quantitativa e analisi qualitativa
cercando di sfruttare al meglio i vantaggi offerti da queste due tecniche.
25
L’analisi quantitativa (Statistical Defect Model) ha lo scopo di verificare il grado di
reliability del software e viene praticata al termine del processo di sviluppo. I
parametri stimati in questo caso sono per esempio: numero di difetti rilevati, il tasso
di fallimento del prodotto, il tasso di rilevazione dei difetti. Sebbene questo possa
essere considerato un buon report, risulta di scarsa utilità allo sviluppatore dal
momento che non produce alcun feedback da poter utilizzare per migliorare il
processo di sviluppo. L’analisi qualitativa (Casual Analisys) invece, ha lo scopo di
identificare la causa del difetto e di determinare le azioni che devono essere
intraprese per poterli eliminare. Questa analisi viene chiamata qualitativa perché
viene collegata all’investigazione umana; in IBM è stato appurato che la Defect
Prevention basata su analisi qualitativa, riesce a fornire feedback agli sviluppatori
che possono così migliorare il processo di sviluppo e conferire al prodotto software
maggiore qualità, ma purtroppo le risorse richieste per poter attuare tale tipo di
analisi sono significative. La tecnica ODC rappresenta un ponte tra le due tecniche e
si basa sull’idea di fornire una metodologia di misurazione per estrarre le
informazioni chiave dai difetti e determinare (misurare) le relazioni causa-effetto. La
difficoltà insita in metodi e tecniche per colmare il divario tra teoria e pratica in
misure in-process nasce da un problema fondamentale: la mancanza di ben definite
relazioni causa-effetto che vengono convalidati nel corso tempo. Senza una buona
relazione di causa ed effetto, è molto difficile sviluppare metodi che forniscono un
buon feedback ad uno sviluppatore . ODC è una tecnica che si fonda sull’idea di base
che un buon sistema di misurazione, permetta di imparare dalle esperienze passate e
fornisca un metodo per poter trasmettere la conoscenza ai progetti in corso di
sviluppo. Deve avere tre requisiti fondamentali :
 Ortogonalità tra classi: distinte e mutamente esclusive (serve a garantire errori
in fase di classificazione).
 Consistenza tra le fasi: le attività all’interno di un processo di sviluppo sono
spesso portate avanti da persone e talvolta da organizzazioni diverse; lo
26
schema di classificazione deve quindi essere consistente attraverso le diverse
attività.
 Uniformità attraverso i prodotti: la classificazione deve essere indipendente
dal particolare prodotto che si sta sviluppando.
Al fine di fornire una misura reale sul processo, lo schema deve soddisfare due
condizioni:
 Condizione Necessaria. La distribuzione dei guasti attraverso le classi, subisce
dei cambiamenti in relazione allo stadio di avanzamento del prodotto nel
processo software.
 Condizione Sufficiente. L’insieme di tutte le classi costituisce un insieme che
copre tutte le fasi del processo.
Perché la necessità di queste due condizioni? La condizione necessaria assicura che
ci sia una precisa relazione tra la distribuzione dei guasti attraverso le classi e le fasi
del processo: ogni classe è associata ad una o più fasi in cui si prevede un picco; se la
distribuzione per una classe ha un picco in uno stadio differente allora significa che
si sono verificati molti faults/bug e pertanto è necessaria una revisione di quella fase.
La condizione sufficiente garantisce che il numero di classi sia adeguato per poter
fare inferenze su tutte le fasi del processo. ODC rispetta i tre requisiti
precedentemente elencati
ed introduce un tipo di classificazione dei bug che
consente di correlare ad un insieme di attributi causa, degli effetti nel processo o nel
prodotto (condizione necessaria di ODC).
Le principali informazioni oggetto di misurazione sono mostrate in figura 1.5 e
appartengono a tre gruppi fondamentali.
27
Figura 1.6 ODC relazione causa-effetto
Il gruppo delle cause è composto dagli attributi ortogonali defect-type e defecttrigger che indicano rispettivamente il tipo di correzione necessaria al bug fixing e
l’azione che ha agito da catalizzatore, mettendo in evidenza il guasto.
Gli effetti invece, possono essere misurati con l’attributo Severity, un’indicazione
dell’impatto sul sistema del bug, secondo una scala di valori crescenti, ad esempio
una scala da 1 a 4, oppure con una classificazione IBM chiamata CUPRIMD
(Capability, Usability, Performance, Reliability, Installability, Maintainability e
Documentation). Altri esempi di misure di effetto sono la defect density, la crescita
della Reliability e l’effort da allocare per la risoluzione del bug. Il terzo gruppo, ha
l’obiettivo di identificare sotto-popolazioni di interesse e tipicamente è formato da
attributi che caratterizzano particolari progetti, persone, processi, tool.
L’attributo defect-type può assumere i valori mostrati in tabella 1.
I defect-type vengono scelti in modo tale da essere abbastanza generali e quindi
essere applicabili a qualsiasi tipo di prodotto software indipendentemente dalle sue
caratteristiche. L’attributo defect-type permette di cogliere la natura del fixing
associata a quel difetto. E’ stato infatti dimostrato che esiste una correlazione tra
questo tipo di informazione e la fase di sviluppo che è responsabile del difetto.
28
Tabella 1.2 ODC defect-type
Con l’attributo defect-trigger si mette in evidenza la causa che ha fatto manifestare il
difetto. In tabella 1.3 sono riportati i valori che questo attributo può assumere divisi
in tre categorie.
Tabella 1.3 ODC defect-trigger
29
Come si evince dalle immagini in figura 1.6 l’attributo defect-type può portare
feedback al processo di sviluppo, mentre l’attributo defect-trigger al processo di
verifica. Nella parte sinistra della figura sono illustrate le principali associazioni tra i
defect-type e gli stadi dei processi di sviluppo, ed in quella a destra è riportato un
esempio di inference-tree per l’attributo function.
Figura 1.7 Associazioni ODC Defect Type - stage del processo
L’albero che permette l’inferenza sul processo è costituito in questo modo:
 La radice è formata dalla prima fase di verifica del processo, maggiormente
associata all’attributo function, nella fattispecie l’ispezione del design di alto
livello;
 I nodi dei livelli successivi dell’albero sono formati dai rimanenti stage
maggiormente associati a function, più uno immediatamente successivo
all’ultimo, nella fattispecie system-testing.
 I rami dell’albero indicano, ove contrassegnati con una H, che il nodo di
livello superiore ha messo in luce più guasti di quelli attesi, mentre una L sta
ad indicare che il nodo di livello superiore ha messo in luce meno guasti di
quelli attesi. La sequenza HLH ad esempio, indica che probabilmente la fase di
design va rivista, come il function verification test che non è stato efficace,
lasciando i bug non trovati al test di sistema.
30
1.3.3 HP- Schema di classificazione dei difetti
Questa tecnica di classificazione ha origine nel 1996 ad opera di HP’s Software
Metric Council. La finalità di questa tecnica è quella di definire una terminologia
standard per i difetti a supporto dei differenti progetti e laboratori HP come mezzo
per la segnalazione, l’analisi e la determinazione dell’effort necessario alla
risoluzione dei difetti, concentrandosi sull’eliminazione delle cause principali ([12]).
In questa tecnica un difetto viene classificato in riferimento a tre attributi riportati in
tabella 1.2.
Tabella 1.4 Attributi di classificazione
Attribute
Description
Origin
The origin is the source of the defect (i.e. specifications/requirements,
design, code, environmental support, documentation, other).
A coarse-grained categorization of what is wrong. It is dependent on the
value chosen for the Origin attribute.
It can be one of missing, unclear, wrong, changed and better way.
Type
Mode
In questo schema di classificazione la tipologia dell’attributo, dipende dal valore
scelto per l’attributo Origin. Questo richiederà un’analisi per capire quando il difetto
è stato iniettato nel sistema, prima di poterne stabilire il tipo, quindi avrà una
struttura semi-ortogonale. Lo schema di classificazione HP non esplicita come le
informazioni sui difetti sono stati raccolte. Inoltre non esiste un attributo disponibile
per poter identificare quali meccanismi sono efficaci per identificare determinate
tipologie di difetti e indagare come difetti gravi possono essere identificati ([13]).
31
Figura 1.8 HP schema di classificazione
1.3.3 FST- Faults Slip Through
FST è una tecnica di analisi dei difetti proposta da Damm et al. nel 2004 ([14]). Si
basa anch’essa su una classificazione dei difetti che viene relazionata a due fasi del
processo di sviluppo software:
 la fase in cui un difetto avrebbe dovuto essere scoperto
 la fase in cui un difetto è effettivamente scoperto.
Alla classificazione segue il calcolo di un miglioramento potenziale nel trovare i bug
nelle fasi corrette; esso è ottenuto moltiplicando la distribuzione FST con una
metrica di beneficio nel trovare un particolare difetto in una fase precedente. Alla
32
base di questo concetto vi sono i risultati di alcuni studi, i quali affermano che il
costo per rilevare e correggere un difetto aumenta vertiginosamente in relazione al
periodo di tempo in cui restano latenti nel software. La tabella 1.3 riporta un esempio
di FST applicato ad arbitrarie fasi di un ipotetico processo di sviluppo. Le righe
rappresentano la fase in cui il difetto doveva essere trovato (Phase Belonging PB),
mentre le colonne indicano la fase in cui un difetto è stato effettivamente trovato
(PF). Ad esempio, se 25 difetti trovati nella fase di functional test, avrebbero dovuto
essere rilevati durante l’implementazione (ad esempio attraverso ispezione o unit
test).
Tabella 1.5 FST matrice di esempio
Una volta classificati i bug, il passo successivo è quello di determinare il costo
dell’attività di detection in una determinata fase; i costi possono essere ottenuti
grazie a dei report temporali o da questionari che coinvolgono gli sviluppatori ed i
tester. L’ultima fase del metodo consiste nel calcolo delle differenze dei costi tra le
condizioni reali, riferendoci alla condizione FST con una condizione fittizia che vede
annullati gli FST (in tabella 1.4 è mostrato un esempio). Dalla tabella di esempio
emerge che l’implementazione costa alle fasi successive, supponendo un criterio di
costo in ore, un overhead di 710 ore causato dall’inadeguatezza delle relative
tecniche di testing nel trovare i difetti. La fase che risente maggiormente
dell’inadeguatezza delle fasi a monte, è la fase di system test.
33
Tabella 1.6 Esempio di calcolo del miglioramento con FST
ODC e FST
Un anno dopo, nel 2005, lo studio è stato ripreso da due degli autori (Damm
Lundberg) che hanno combinato le tecniche ODC (in particolare i defect trigger) e
FST, ([15]) per dar vita ad un nuovo framework di analisi dei difetti.
L’innovazione rispetto al semplice FST consiste nel fatto che adottando anche la
classificazione ODC, si possono avere feedback anche sulle particolari attività (il
trigger) che mettono in luce i difetti. Le relazioni generate dall’incontro di queste due
tecniche vengono riportate in tabella 1.7
Tabella 1.7 FST fault type e ODC class
34
1.4 Analisi dei difetti in sistemi Mission Critical
Nonostante la presenza di modelli comprovati per l’analisi dei difetti (ODC e HP),
l’applicazione di un processo di defect management in uno scenario industriale di
tipo mission critical e software intensive, viene condizionata fortemente dal contesto
che impone i soggetti e i vincoli alla base dell’analisi. Sistemi che rientrano in
questa categoria sono i sistemi di controllo e gestione del traffico aereo (ATC/ATM)
e marittimo (VTMSI). Sistemi di questo genere sono caratterizzati da grandi
dimensioni e spesso sono formati da componenti realizzati e forniti da terze parti che
devono essere integrati. Questa fase è molto delicata, poiché si devono integrare i
componenti garantendone l’interoperabilità con gli altri già presenti nel sistema.
L’analisi dei difetti in questo scenario deve trovare un compromesso tra l’obiettivo
dell’analisi, i suoi potenziali risultati, la sua applicazione ai diversi aspetti del
processo e il costo necessario alla sua applicazione. Per esempio gli SRGM
(Software Reliability Grow Model ) sono facili da implementare, poiché richiedono
come input il tempo di rilevamento dei difetti che può essere rilevato, con poco
sforzo, facendo uso di un numero limitato di risorse del personale, tuttavia fornisce
spunti limitati del processo. Basare invece l’analisi su modelli come ODC o HP,
comporterebbe la produzione di una quantità elevata di informazioni nei singoli stadi
del processo comportando una maggiore intrusività e spese più elevate. Infatti la loro
applicazione in ambienti industriali veri e propri risulta difficile a causa di una serie
di problematiche dovute per esempio ai costi di avvio, di formazione del personale e
di non immediato guadagno visibile a cui si aggiunge anche la riluttanza del
personale a dover cambiare il loro lavoro di routine ([16],[17],[18]).
1.4.1 Processo di sviluppo Selex ES
Il processo di sviluppo di Selex ES ed in generale dei settori software critici, si basa
su delle personalizzazioni del modello a V, descritto dallo standard MIL-948 ([19]).
Questo modello prevede un approccio basato fortemente sui componenti, indotto
principalmente dalle dimensioni, dalla complessità dei sistemi di base e dai vincoli
35
stringenti di time to market e di qualità. Ogni componente è noto come CSCI
(Computer Software Configuration Item) che rappresenta in realtà un prodotto di per
se fortemente disaccoppiato dagli altri, distribuibile e configurabile autonomamente.
Questi componenti dunque rappresentano le unità di base del processo di sviluppo.
Ognuno di essi viene sviluppato da un determinato team di sviluppo o da aziende
esterne con cui si hanno rapporti di fornitura. Questo rappresenta un importante
aspetto del modello adottato da Selex (riportato in figura 1.9)
che prevede la
partecipazione dei fornitori. Il team incaricato dello sviluppo di un determinato CSCI
ne cura tutti gli aspetti che riguardano l’implementazione e il testing pre-release.
Dopo lo sviluppo, il CSCI viene sottoposto ad un test iterativo. I difetti rilevati
vengono presi in considerazione dal team responsabile dello sviluppo, che
provvederà ad effettuarne il fixing e al rilascio di nuove versioni. In seguito al
rilascio, il CSCI sarà sottoposto a test di integrazione. Seguono a questa fase, il
testing del sistema e di accettazione prima del rilascio della release finale.
Figura 1.9 Modello a V adottato da Selex[20]
36
Analizzando il modello si evince che l’attività di sviluppo è caratterizzata da alcune
fasi principali, ognuna delle quali produce degli artefatti di progetto. Una delle
peculiarità del modello di sviluppo a V è quella di associare ad ogni fase di sviluppo
(ramo sinistro) una fase di testing (ramo destro). Per questa ragione, le attività di
pianificazione del testing sono eseguite al termine di ciascuna fase di sviluppo
corrispondente, prima di passare al livello successivo della V. Le fasi principali fasi
di sviluppo e i relativi artefatti, del modello sono:
 System
Requirements
analysis.
Produce
un
documento
chiamato
System/Subsystem Specification (SSS), contenente le specifiche dei requisiti
del sistema, raggruppati per sottoinsiemi di dominio identificati da funzioni di
alto livello; questo artefatto viene completato da Interface Requirements
Specification (IRS) che descrive le interfacce esterne del sistema e i relativi
data-model.
 System Design. Partendo dai requisiti contenuti nel SSS, produce una
descrizione relativa al design del sistema/sottosistemi (SSDD) contente la
soluzione relativa ad un’architettura di alto livello e la ripartizione dei requisiti
ai sottosistemi.
 Software Requirement Analysis and architectural design. Produce una
specifica dei requisiti software (SRS) per ogni CSCI. Ogni SRS è completato
da un documento di controllo dell’interfaccia (ICD) che specifica le interfacce
CSCI e il modello dati correlato.
 CSCI Design. Produce una descrizione del componente dal punto di vista della
sua realizzazione interna (SDD) e all’assegnazione di requisiti software alle
sue sotto-componenti interne. Viene prodotto un SDD per ogni CSCI e ognuno
di essi è accompagnato da un documento relativo al design dell’interfaccia
(IDD) che specifica le interfacce interne dei CSCI e i dati scambiati.
 Coding. E’ la fase in cui produce il codice dei relativi CSCI, le cui dimensioni
variano da diverse decine di Kloc.
37
 System and Acceptance Testing. Viene eseguito quanto descritto nel piano del
testing di accettazione (ATP) producendo dei report (SAT o report FAT) a
seconda delle locazioni in cui vengono eseguiti i test.
1.4.2 Ciclo di vita dei difetti
Il processo basato sui CSCI comporta una gestione condivisa dei difetti tra i fornitori
e i team di testing. Per questa ragione i difetti devono essere caratterizzati in modo
tale da poter essere a tutti comprensibili, fruibili attraverso dei sistemi di issue/bug
tracking e caratterizzati da un preciso ciclo di vita (figura 1.10). In questo caso il
ciclo di vita dei difetti viene descritto attraverso due variabili: stato e risoluzione.
La variabile stato può assumere i seguenti valori: New, Assigned, Feedback,
Acknowledge, Confirmed, Resolved, Closed.
La variabile risoluzione, indica lo stato del processo di fixing e può assumere i
seguenti valori: Open, Fixed, Reopened, Unable to reproduce, Not fixable, Duplicate,
No change required, Won’t fix. Ogni issue presente nel sistema sarà caratterizzata
dalle seguenti informazioni:
 ID. Identificativo univoco associato alla Issues
 ComponentId. Identificativo univoco associato al componente
 Summary. Descrizione testuale del problema manifestato
 Priority. Priorità associata al difetto (Immediate, High, Low, Urgent, None)
 Severity. Indica quanto grave è il difetto. I possibili livelli in ordine
decrescente di severità sono: Block, Crash, Major, Minor, Tweak, Text,
Trivial, Feature.
 Reproducibility. Indica le condizioni di attivazione e riproducibilità della
issue. Può essere Not-always reproducible, Always-Reproducible e Notavailable.
 Detection date. Data in cui la issue è stata rilevata.
 Fixing date. Data per cui è stato prevista la risoluzione della issue.
38
 Test Case Number. Il test case in cui la issue si è manifestata.
Figura 1.10 Ciclo di vita dei difetti in Selex
Queste sono le informazioni con cui saranno classificati i difetti del data set che sarà
utilizzato nel nostro scenario applicativo e verranno riconsiderate durante la
progettazione dello strumento per l’analisi dei difetti, obiettivo di questo lavoro di
tesi.
39
Capitolo 2. Strumenti per la gestione e analisi dei difetti
Un tool di defect management è un strumento software che lavorando
congiuntamente a quanto previsto nel processo di defect management, permette di
gestire i difetti rilevati nel software, stabilirne il ciclo di vita e definire il workflow
per scandirne le varie fasi dalla rilevazione fino al fixing del difetto. Le
caratteristiche generali che questi strumenti devono presentare sono:
 Fornire un repository centralizzato in cui tenere traccia dei difetti riscontrati
nei vari progetti
 Fornire automaticamente delle notifiche inseguito all’assegnazione di risorse
 Possibilità di fornire lo stato di risoluzione del difetto al fine di utilizzarlo
come feedback per il processo di Management Reporting.
 Possibilità di raggruppare i difetti per vari criteri, severità e priorità.
Altre caratteristiche che possiamo considerare opzionali, ma che comunque incidono
sulla scelta dello strumento sono:
 capacità del tool di riuscire a ricevere suggerimenti dai clienti sui questioni
relative ai progetti.
 capacità di supportare team interni e esterni all’organizzazione
 apertura/interoperabilità
 facilità d’uso
 costo licenze, lingua in cui è disponibile
Viene ora proposto uno “scouting” di alcuni dei principali tool di defect management
presenti sul mercato. Verranno presentati sia tool open source e tool proprietari.
40
2.1 MantisBT
MantisBT è un sistema di bug tracking free, web-based di tipo client-server che ha
iniziato a diffondersi nel 2000 ([21]). Nel corso degli anni ha maturato e guadagnato
grande consenso, divenendo così uno dei tool più popolari per la gestione dei difetti.
E’ un sistema rilasciato sotto i termini della GNU General Public Licence e può
essere modificato e ridistribuito a patto che si rispettino i termini della GPL.
Il concetto fondamentale in Mantis è la Issue, un ticket che permette di monitorare e
tracciare il ciclo di vita di un bug segnalato. Al momento della creazione di un ticket
un reporter compila in una pagina appositamente predisposta i seguenti campi:
 Categoria. Informazione personalizzata da progetto a progetto che può
indicare un modulo in cui un reporter ritiene sia localizzato il bug. Questo
campo potrebbe anche fornire un’indicazione circa la fase del processo in cui è
stato riportato il bug, ad esempio in fase di Integration Testing
 Riproducibilità. Fornisce un’indicazione sulla complessità di attivazione di un
bug che prima poi scatena un fallimento.
 Severità. Rappresenta una scala di valori che indica il tipo di impatto che
l’anomalia avrebbe sul sistema.
 Priorità. Scala di valori assegnati da un reporter in base alle scadenze fissate o
a eventuali rallentamenti sul testing che l’anomalia comporterebbe nel caso
non venisse risolta.
 Riassunto. Una breve stringa che identifica il problema.
 Descrizione. Una spiegazione dettagliata del bug sollevato.
 Passi per la riproduzione dell’anomalia. Indica l’elenco di azioni compiute
dal reporter che hanno messo in luce il bug.
 Versione. Indica la release del software in cui è stato rilevato il bug.
41
Figura 2.1 Mantis - Inserimento nuova issue
All’atto della creazione, il sistema associa ad una nuova issue un ID univoco e una
data (il tempo del server). Una funzionalità che non è stata ancora implementata in
Mantis è l’inserimento manuale della data di detection da parte del reporter. Questo
permetterebbe di inserire guasti rilevati e non inseriti nel sistema a causa di una
momentanea indisponibilità del server. A causa di questo problema, i tempi di
apertura dei ticket sono da considerarsi approssimazioni dei tempi veri e propri di
detection. Ogni difetto possiede due variabili di stato, Status e Resolution che
permettono di tenere traccia del suo ciclo di vita. Status permette di monitorare
l’effettivo stato in cui la issue si trova (new, assigned, feedback, acknowledged,
confirmed, resolved, closed) e Resolution indica il punto in cui si trova il processo di
Fixing (può assumere i valori open, closed, reopened, unable to reproduce, not
fixable, duplicate, no change required, won’t fix). MantisBT è sviluppato in PHP,
con il supporto a molteplici database tra cui MySQL, MS SQL, PostgreSQL e DB2.
42
Le principali tabelle in Mantis che tengono traccia dei progetti hanno il prefisso
“mantis_project_” e tra le principali ricordiamo:
 mantis_project_table. Indica la tabella principale, contiene un ID univoco del
progetto, una descrizione testuale (description) ed ulteriori informazioni
relative al progetto.

mantis_project_version_table. Tiene traccia delle versioni degli artefatti
rilasciati nel tempo, associando ad ognuno di essi un ID, un nome di versione
(version), una descrizione (description) e un timestamp in formato Unix
(date_order).
 mantis_project_hierarchy_table. E’ utile a ricostruire gerarchie di progetti in
cui i figli (child_id) possono ereditare o meno dai genitori (parent_id) delle
proprietà cumuni (inherit_parent).
Le tabelle che tengono traccia dei bug hanno invece il prefisso “mantis_bug_”.
Alcune delle più importanti sono:
 mantis_bug_table. E’ la tabella che contiene le informazioni relative ad un
singolo bug inserito (Id relativo al progetto (projcet_id), dell’utente che
segnala il bug (reporter_id), dell’utente che in un certo istante è responsabile
del bug (handler_id)). Contiene inoltre le informazioni relative a Priority,
severity, reproducibility, version, summary, date_submitted. Contiene la
“resolution” proprietà della issue, settata dallo sviluppatore a valle della fase
di correzione; specifica se il bug è stato corretto o meno e infine la
fixed_in_version che indica il primo rilascio in cui il bug fixing ha avuto
effetto.
 mantis_bug_history_table. Indica la tabella che tiene traccia di ogni variazione
di stato che subisce un ticket . I campi principali sono l’id univoco dell’utente
che ha apportato la variazione (user_id), l’id del bug (bug_id), il nome del
campo che ha subito una variazione, il vecchio e il nuovo valore, il timestamp
della variazione in formato UNIX.
43
Mantis come un qualsiasi script PHP, può essere eseguito su un qualsiasi sistema che
supporti quest’ultimo e abbia un DBMS installato. Può essere installato su Windows,
Mac OS X, Linux e su una grande varietà di sistemi UNIX. Come si è appena
accennato, Mantis oltre ad essere un prodotto free, gode di altre importanti
caratteristiche che vanno dalla gestione dei progetti in maniera differenziata
(progetti, sotto-progetti e categorie) alla personalizzazione degli accessi dei singoli
utenti
(Osservatore,
Segnalatore,
Aggiornatore,
Sviluppatore,
Manager
e
Amministratore) sui singoli progetti. Inoltre offre un alto livello di personalizzazione
per quanto riguarda issue, workflow, autenticazione.
Prevede il supporto a diversi tipologie di DBMS e la possibilità di integrazione di un
servizio di chat. Per quanto riguarda l’autenticazione sono previste diverse
possibilità: Default Mantis Autenthication (raccomandata), LDPA (protocollo
standard per la gestione e la modifica di servizi di directory ), HTTP supporto di
autentificazione di base e Active Directory Integration. Mantis non mette limite al
numero massimo di utenti, progetti e issues. Prevede la possibilità di inviare
messaggi ad altri utenti in riferimento ad una specifica issue rilevata. I progetti
possono essere divisi in pubblici e privati così come anche le note alle quali è
concesso l’accesso in accordo a permessi specifici. Mantis prevede un accesso
anonimo e un servizio di registrazione basato su Captcha (completely automated
public Turing test to tell computers and humans a part) ed e-mail di conferma. Offre
un servizio di supporto per l’eventuale reset della password e permette la
segnalazione di problemi via e-mail o in alternativa tramite un modulo personalizzato
sul proprio sito web (Anonymantis).
E’ possibile un’integrazione con WIKI come servizio opzionale ed permette
l’applicazione di “azioni di gruppo” ovvero applicabili allo stesso gruppo di
progetti/difetti. Naturalmente oltre a poter fornire un rapporto sulle varie issues è
prevista la possibilità di effettuarne rappresentazioni/confronti grafici. Le interfacce
di input previste sono: web, e-mail, soap, mylyn (sottosistema eclipse per la gestione
44
dei task-scritto in java e cross-platform) e infine offre la disponibilità
dell’applicazione MantisWap per Andorid, Blackberry o Iphone. Infine molto
semplice è la generazione di collegamenti ipertestuali ai difetti (es . il collegamento
#123 si riferisce al problema #123) e la consultazione degli ultimi (in numero
personalizzabile) problemi più recentemente visitati. Mantis offre un’interfaccia ai
web service (SOAP() chiamata MantisConnect, questa rappresenta un servizio web
soap implementato in PHP che può essere usato da qualsiasi altro linguaggio che
supporta i SOAP Web Services (.Net Client Library, Java Clien Library, Cocoa
Client Library). Mantis permette di importare issues da Jira e da Trac.
Ciclo di vita delle issues e workflow
Il ciclo di vita di una issue ha origine con la sua creazione che può avvenire in
differenti modi:
 MantisBT Web Interface. Un utente, dopo essersi loggato a MantisBT, riporta
una nuova issue.
 SOAP API. L’applicazione riporta automaticamente una issue in MantisBT
usando SOAP API web Service .
 E-mail. Non è supportata di default ma esistono delle patch che permettono di
ricevere le e-mail da determinati indirizzi e di effettuarne la memorizzazione
nel database Mantis.
 Altri modi come script PHP o script che permettono di iniettare direttamente le
issues nel MantisBt database.
Stato delle issues
La conoscenza dello stato delle issues aiuta nella loro gestione ed è di fondamentale
importanza per il processo di risoluzione. In Mantis una issues può assumere i
seguenti stati:
 New. Questo è lo stato di partenza (subito dopo la creazione) in cui la issue
45
permane fino a quando non sarà marcata come assigned, acknowlegde,
confirmed o resolved.
 Acknowlegde. Stato in cui l’issue viene riconosciuto dal team e classificato in
relazione alle caratteristiche indicate dal reporter
 Confirmed. Stato che viene assegnato dagli sviluppatori una volta che hanno
ricevuto la segnalazione della issue e ne hanno riconosciuto le caratteristiche
indicate dal reporter.
 Assigned. La issue viene assegnata ad un team o ad un membro di esso ed è in
attesa di essere risolta.
 Resolved. Issue risolta.
 Closed. Indica che la issues è stata completamente chiusa e non sono richieste
ulteriori azioni su di esso.
Dopo aver presentato i modi con cui è possibile sottoporre issues al sistema e gli stati
che esse possono assumere, non ci resta che presentare il workflow. Questo
rappresenta l’insieme di operazioni che il manager o il team di sviluppo decidono di
applicare alle issues per il processo di fixing. Queste azioni sono direttamente legate
agli stati che sono stati previsti, i quali possono essere personalizzati in relazione alle
esigenze dei team che dovranno lavorare con le issues. In figura 2.2 viene mostrato
un esempio di workflow (è quello che implementa mantis di default) inserito in un
diagramma UML ibrido, casi d’uso/diagramma di sequenza per mostrare il
comportamento in relazione agli stati definiti. Questo può essere gestito dagli utenti
che sono in possesso dei privilegi di amministratore ai quali è concesso l’accesso alla
pagina di “Manage-Configuration>Workflow Transition” che consente di effettuare
diverse operazioni come: definire gli stati validi e stati prossimi per ogni stato,
definire il livello minimo di permessi per poter accedere ad ogni stato, definire lo
stato di default per ogni issue appena creato, lo stato in cui una issue può considerarsi
risolta, lo stato per le issues che vengono re-opened e definire il livello di accesso per
apportare cambi al workflow. Il workflow globale può essere definito solo nel file
46
config_inc.php come mostrato in figura 2.3.
Figura 2.2 Esempio workflow Mantis
Figura 2.3 Config_inc.php Mantis
In riferimento al file config_inc.php la prima voce in ogni lista indica il valore di
default per lo stato a cui si riferisce . Gli utenti amministratori hanno i permessi per
poter settare le azioni (Workflow Threashold ) grazie alla pagina appositamente
predisposta “manage>manage configuration>workflow threshold”. Alcune delle
azioni sono le seguenti : riportare e aggiornare una issue, concedere il permesso per
risolvere o chiudere una issue, monitorare, gestire, assegnare, cancellare ed tante
altre azioni riguardanti sempre la gestione e la notifica delle issues compresi i
meccanismi per informare gestori e utenti.
47
2.2 Atalassian JIRA
E’ un sistema di issue tracker proprietario di Atlassian che nasce nel 2003 ([22]).
Implementato in java, supporta diversi DBMS come MySQL, PostgreSQL, Oracle,
SQL Server. E’ semplice da installare ed essendo l’amministrazione web based, evita
la necessità di modificare innumerevoli file di configurazione o di apportare
modifiche al codice sorgente. Dispone di interfacce chiare e user-friendly che
permettono una rapida consultazione e consentono di lavorare in maniera rapida ed
intuitiva. Jira prevede dashboard completi con supporto alla segnalazione tramite
widget e tramite word, excel e grafici personalizzabili, permettendo l’integrazione
dei piani di test. E’ prevista, inoltre, la personalizzazione dei campi e del workflow e
il supporto alla codifica UNICODE. Il prodotto rispetta i requisiti di SLA, è possibile
estenderlo tramite plug-in e dispone di una serie di API messe a disposizioni di utenti
utilizzatori/amministratori appunto per poter apportare delle personalizzazioni. Jira
consente la gestione multi-progetto e offre la possibilità di effettuare ricerche
completamente testuali o indicizzate nei vari progetti/file. Svariate sono le interfacce
previste per l’input: Web, E-mail, CLI, GUI, REST, SOAP, Visual Studio, Eclipse. I
meccanismi di notifica previsti sono: e-mail, RSS (Rich Site Summary) o XMPP. Per
quanto riguarda l’autenticazione è previsto un meccanismo form-based basato su
OpenId o su Oauth (complementare a openId). Infine per quanto riguarda l’aspetto
relativo al controllo di revisione distribuito, vengono adottati i software GIT (è un
software di controllo di revisione distribuita del sistema di gestione del codice
sorgente) e Mercurial (strumento di controllo cross-platform per il controllo di
revisione distribuita). Jira viene utilizzato da team di sviluppo e sistemi di help-desk.
La sua applicazione dai team di sviluppo per finalità di QA è ampiamente motivata
dal fatto che ha ottime potenzialità in termini di bug tracking e offre un completo
monitoraggio in termini di documentazione in termini di progetto. Jira si basa su tre
elementi fondamentali: Issue, Project (component e version), Workflow mostrati
figura 2.4
48
Figura 2.4 Elementi base Jira
Project. E’ una collezione di elementi da monitorare (può essere progetto di sviluppo
software, una campagna di marketing ecc.). Ogni progetto è caratterizzato da una
chiave univoca.
Component. E’ un raggruppamento logico di issues all’interno di un progetto.
Version. Per molti progetti software è prevista la presenza di diverse versioni, alle
quali è possibile collegare determinate issues. Il collegamento delle issues alle
versioni, avviene grazie a due campi
presenti nella caratterizzazione: Affects
Version(s), Fix Version(s) che indicano rispettivamente le versioni interessate da
quella tipologia di issues e le versioni in cui esse sono stati risolte.
Workflow. Indica l’insieme di stati che una issue attraversa durante il suo life-cycle.
L’immagine in figura 2.5 mostra un workflow built-in Jira.
Issue. Rappresenta tutto ciò che viene creato per poter essere monitorato con Jira può
essere considerato una issue. In Jira una issues è caratterizzato da un insieme di
campi (naturalmente personalizzati dall’amministratore) che descrivono la issue in
tutte le sue caratteristiche. I campi sono i seguenti:
 Project. Indica il progetto al quale la issue appartiene.
 Key. E’ un identificativo univoco che permette di caratterizzare il progetto e la
relativa issues (es Web-203 ).
49
 Summary. Breve descrizione della issue.
 Type. Indica la tipologia della issues e può essere: Bug, Improvement, New
feature, Task e Custom Issue.
 State. E’ lo stato in cui si trova la issue. Può essere: Open, In Progress,
Resolved (da qui possono essere riaperti o chiusi), Reopened, Closed (quando
la issue viene rimosso).
 Priority. Indica la priorità della issue e può essere di diverso tipo (sono
elencate in ordine di importanza): Blocker, Critical, Major, Minor e Trivial.
 Resolution. E’ un record che indica se il problema è stato risolto e chiuso.
 Affects Version(s) (se applicato).Versioni affette da una determinata issue.
 Fix Version(s) (se applicato). Versioni in cui una determinata issue è stata
risolta.
 Component(s) (se applicato). Componente del progetto che ha manifestato la
issue.
 Labels(s) (Se applicato). Etichetta associata ad una issue.
 Environment. Ambiente hardware/software in cui si è manifestata la issue.
 Description. Descrizione dettagliata.
 Links. E’ una lista di link alle relative issues.
 Assignee. Indica la persona a cui è stata assegnata la issue.
 Reporter. Chi ha segnalato la issue.
 Votes. Per esprimere la preferenza per risolvere la issue.
 Watchers. Quante persone hanno visto il manifestarsi della issue.
 Due (Se applicato). Indica la data entro la quale il problema deve essere
risolto.
 Created. Data e ora in cui la issue è immessa in Jira .
 Updated. Data e ora dell’ultimo aggiornamento della issue.
 Resolved. Data e ora in cui la issue è stata risolta.
50
 Estimate . La quantità di tempo necessaria a risolvere il problema da quando è
stato aperto.
 Logged. La somma dei singoli tempi di lavoro registrati per la risoluzione del
prolema.
 Development. Se si utilizza Bitbucket o Stash per gestire i repository di codice,
è possibile creare salti di codice negli strumenti di sviluppo di codice
direttamente dalle issues.
Figura 2.5 Workflow built-in Jira
Ricerca delle issues
Tra le innumerevoli funzionalità offerte da Jira, non si può non fare un cenno ad una
delle sue più performanti: la ricerca. E’ possibile ricercare le issues tra vari progetti,
definire nuovi criteri di ricerca su campi personalizzati e una volta creati possono
essere riutilizzati in ricerche future. La ricerca, infatti, può essere salvata come un
filtro in Jira che può essere comodamente richiamato successivamente. Vengono ora
presentati i passi fondamentali per eseguire una ricerca. Il primo di questi passi
51
consiste nella scelta del criterio di ricerca: quick, based o advanced. Il metodo quick
è quello più veloce e semplice da usare ma proprio per la sua semplicità ha una
minore precisione, nel senso che non sempre riesce a fornire i risultati che si
ottengono con l’applicazione degli altri due metodi. Il metodo viene rappresentato
dalla barra di navigazione presente in Jira. Il metodo based è molto più preciso del
quick e al tempo stesso più facile da usare rispetto a quello advanced. Fornisce
un’interfaccia molto user-friendly e supporta la costruzione di query più complesse
utilizzando JQL. Il metodo Advanced è quello più completo e complesso, supporta la
creazione di query strutturate le quali non sono supportate dalle altre due
metodologie. Una volta ottenuti i risultati, indipendentemente dalla tipologia di
ricerca utilizzata è possibile salvarli e/o condividerli in differenti formati o
semplicemente visualizzarli sul dashboard come liste di caratteri.
Generazione dei report
Jira fornisce la possibilità di mostrare le statistiche relative ad un determinato
progetto, versione, issues o campi delle issues accedendo direttamente dalla finestra
del progetto di cui vogliamo ottenere informazioni. I report disponibili sono i
seguenti:
Avarage Age Report.Età media (in giorni ) delle issues non risolti.
Created vs Resolved Issues Report. Mostra il numero delle issues create rispetto a
quelle risolti in un dato periodo di tempo.
Pie Chart Report. Mostra un Pie chart report di una determinata ricerca in base ad
una precisa statistica.
Resolution Time Report. Mostra il tempo medio per la risoluzione di una issue.
Recently Created Issues Report. Mostra il rate al quale le issues vengono create.
Single Level Group By Report. Mostra il risultato di un “issues filter” raggruppato in
relazione ad un determinato campo scelto.
Time Since Issues Report. Mostra un insieme delle issues per le quali è stato
impostato il campo data.
52
Time Tracking Report. Mostra il Time Tracking (stimato, rimanente e attuale) di una
determinata issue.
User Workload Report*. Mostra il carico di lavoro assegnato da un utente e il tempo
che dovrebbe richiedere .
Version Time Tracking Report*. Mostra i progressi fatti verso il completamento di
una determinata versione basata su stime di lavoro e tempi.
Version Workload Report*. Mostra il lavoro rimanente prima di una versione
completa del report.
Workload Pie Chart Report*. Grafico relativo al rapporto carico di lavoro/
assegnatari.
Le funzionalità con asterisco sono disponibili solo se l’amministratore ha attivato la
funzionalità di Time-Tracking. Un aspetto molto importante di questo bug-tracker è
la possibilità di importare le issues (grazie a dei plug-in) da altri bug-tracker come
Bugzilla, FogBugz, MantisBt, Pivotal-tracker, Trac, Redmine, Bitbucket. Jira è
disponibile anche in versione mobile e come versione Agile che permette il supporto
a team di sviluppo che adottano strategia Agile. Oggi, Jira, si sta affermando nel
mondo delle industrie come uno standard de facto ma non essendo open source
questo ne penalizza la scelta e orienta una fetta dei potenziali clienti all’adozione di
soluzioni differenti.
2.3 Bugzilla
Bugzilla è un “Defect Tracking System” o anche “Bug-Tracking System” web-based
client-server sviluppato dalla Bugzilla.org ovvero gli stessi sviluppatori di Mozilla
lanciato nel 1998 ([23]). Il tool è stato sviluppato inizialmente in TLC
successivamente si è fatto un porting in Perl in quanto essendo più popolare avrebbe
permesso a più sviluppatori di avvicinarsi ad esso e a fornire il loro contributo. Offre
il supporto a diversi back-end di database come MySQL, Oracle, PostgreSQL,
SQLite. La rapida diffusione di Bugzilla ha richiesto una maggiore semplicità in
termini di installazione e interoperabilità con diverse piattaforme e database in modo
53
tale da riuscire ad abilitare e disabilitare funzionalità al momento opportuno e quindi
renderlo personalizzabile. L’idea di base su cui è stato concepito lo sviluppo di
Bugzilla è quella di realizzare un sistema di bug tracking anche se vi è un trend che
cerca di trasformare Bugzilla in un sistema di ticket di supporto tecnico, strumento di
gestione delle attività del progetto quindi un vero e proprio sistema di project
management. Per quanto riguarda gli utenti che vogliono cercare di estenderne le
funzionalità, si dovrebbero seguire in fase di sviluppo alcuni principi di
progettazione. Ad esempio Bugzilla deve essere eseguito facilmente su strumenti
open source. Il supporto alla integrazione di Bugzilla dovrebbe essere ampliato per
supportare i database commerciali, strumenti e sistemi operativi ma non a scapito di
quelli open source. Uno dei principali motivi di attrazione verso Bugzilla è la sua
attenzione alla leggerezza e velocità. Ridurre al minimo le chiamate al database
quando possibile, non prendere più dati del necessario ecc. rendono il prodotto molto
snello e particolarmente efficiente.
Anatomia del Bug in Bugzilla
Vengono di seguito elencate le caratteristiche di un bug Bugzilla.
Product e Component. I prodotti hanno la caratteristica di inglobare al loro interno
più componenti. Ad esempio bugzilla.mozilla.org’s prodotto “Bugzilla” è formato da
diversi componenti (User Intefarce, Administration, E-mail, Documentation,
Installation ecc.)
Status e Resolution. Definisce in quale stato si trova o sta attraversando un
determinato Bug.
Assign To. La persona, il team a cui il bug è stato assegnato.
QA Contact (opzionale). La persona responsabile per la QA del bug.
URL (opzionale). Possibilità di associare una url al bug.
Summary. Una frase per riassumere il problema.
Status Whiteboard (opzionale a.k.a. Whiteboard). Indica una free-text area in cui
scrivere alcune note e tag relativi al bug.
54
Keywords (opzionale). L’amministratore può definire parole chiave per indicare tag e
categorie di bug.
Platform and OS. Indicano il sistema operativo e la piattaforma su cui il bug si è
manifestato.
Version. E’ utilizzata qualora vengano rilasciate più release dello stesso prodotto e
grazie a questo campo si può collegare il bug alla release in cui si è manifestato e
quelle in cui è stato risolto.
Priority. Serve a caratterizzare i bug e a schedularli per la loro risoluzione.
Severity. Serve ad indicare la serietà del problema (va da Blocker a Trivial).
Target (a.k.a. Target Milestone). E’ la versione in cui un determinato bug è stato
risolto.
Reporter. Colui che ha riportato/segnalato il bug.
CC list. Una lista di persone a cui vengono inviate le e-mail qualora ci sono dei
cambiamenti di un determinato bug.
Time tracking (opzionale). Può essere utilizzato per il monitoraggio del tempo. Al
fine di utilizzare questa funzionalità bisogna essere membri del gruppo
timetrackingroup. I parametri attraverso i quali è possibile fare il monitoraggio sono:
Origin Estimated Time, Current Estimated Time (calcolato da Hours works a Hours
Left), Hours Worked, Hours Left, %Complete, Gain(numero di ore che lo stato di
risoluzione del bug mostra in avanti rispetto al Or time), Deadline.
Attachement. Si possono allegare file al bug (come per esempio test-case o patches).
Dependencies (opzionale). Sono delle registrazioni che vengono effettuate qualora il
bug non dovesse essere risolto.
Additional Comments. Commenti aggiuntivi per fornire informazioni relative al bug
con maggiore livello di dettaglio.
Anche Bugzilla offre la possibilità come altri bug/issues tracker, di personalizzare il
ciclo di vita del bug al fine di adattarlo quanto più possibile alle esigenze
dell’organizzazione. Viene riportato in figura 2.6 un esempio di bugzilla lifecycle
55
Figura 2.6 Bugzilla Lifecycle
Ricerca dei bug
Bugzilla offre per la ricerca dei bug una interfaccia (Bugzilla Search Page )
attraverso la quale è possibile ottenere i valori associati a tutti i campi che
caratterizzano un bug e che corrispondono ai campi selezionati. Per effettuare
ricerche basate su criteri più raffinati si possono utilizzare gli operatori booleani. In
questo caso, sono tre campi: Field (la voce che si sta cercando), Operator, Value (il
valore con cui il campo deve essere comparato). E’ prevista, anche, una ricerca
veloce identificata da un box a piè pagina corredato da una breve descrizione che
permette di illustrarne il funzionamento. Le query realizzate in Bugzilla sono caseinsensitive e accent-insensitive se si utilizzano database come MySQL e Oracle
Database. Se invece usiamo Bugzilla con backend PostgreSQL alcune query sono
56
case-sensitive. Dopo aver lanciato una ricerca viene ritornata una lista di bugs il cui
formato è personalizzabile. Alcune delle caratteristiche utili relativi alla lista sono le
seguenti: Long Format, XML (per ottenere la bug list in formato xml), CSV (buglist
separata da punti, per poter importare in un foglio di calcolo), Feed (per avere
informazioni circa i bug che si desidera seguire), I-calendar, Invia e-mail
all’assegnatario del bug, Scrivere e Memorizzare i criteri di ricerca. Bugzilla offre
inoltre la possibilità di aggiungere/rimuovere tags ai bug per poterne facilitare la
gestione. Questi sono peer-user ossia visibili e modificabili solo dagli utenti che gli
hanno definiti e possono essere utilizzati nei criteri di ricerca (esempio nella ricerca
basic si può scrivere
“tag: my_tag_name” ). Questa funzionalità risulta essere
particolarmente utile quando si desidera tenere traccia di diversi bug perché invece di
“mescolare ” tutte le modalità è possibile memorizzare i bug in liste separate create
in base alle ragioni per cui si monitorano. Bugzilla prevede la possibilità di clonare
un bug operazione per poterne osservare il comportamento in uno scenario
differente.
Vantaggi lato Utente
 Alta capacità di ricerca grazie a due metodologie: semplice e complessa. La
ricerca semplice è molto Google-like e cerca il testo integrale di un bug. La
ricerca complessa offre la possibilità di creare criteri di ricerca più raffinati
realizzati con l’applicazione di vari criteri.
 Notifiche di posta elettronica controllate dalle preferenze richieste dagli
utenti.
 Possibilità di presentare/esportare i bug in differenti formati (Html, CSV,
XML e iCalendar).
 Report (Giornalieri, Settimanali, Mensili ecc.) questo permette di comunicare
ad un utente o un gruppo di utenti il risultato di un particolare evento che si
vuole monitorare.
57
 Possibilità di creare grafici e tabelle per controllare/paragonare i risultati
ottenuti nel tempo dall’azione di rilevamento dei bug. E’ inoltre prevista la
possibilità di esportare i dati in formato CSV per poter lavorarci con un foglio
di calcolo. Sono inoltre disponibili differenti tipologie di grafici(istogrammi,
grafici a linee, a torta ecc.)
 Rilevamento automatico dei bug duplicati: non appena si indentifica un bug
mentre si sta per scrivere una sua descrizione, il sistema controlla se in
precedenza sono stati rilevati altri bug simili al fine di poterli raggruppare
evitandone così una duplicazione.
 Modifiche a File/Bug possono essere comunicate per e-mail.
 Time tracking. E’ possibile stimare il tempo necessario alla riparazione di un
bug. Per applicazioni che non richiedono questo requisito è possibile
disattivare tale funzionalità.
 Request System. E’ un metodo per chiedere ad altri utenti di fare qualcosa con
un determinato bug. Questo strumento è molto utile perché si può utilizzare
per vari scopi (ad esempio richiedere la revisione del codice, richiedere
informazioni ad un utente specifico oppure ottenere un sign-off da un
gestore).
 Possibilità di inserire commenti che rimarranno privati al gruppo.
 Completamento automatico nome utente o di elenchi a discesa.
 “Guarda gli altri utenti”. E’ una modalità di Bugzilla che prevede l’inoltro dei
messaggi destinati ad un determinato utente/sviluppatore verso un numero di
utenti predefiniti per poter ad esempio continuare il lavoro anche in assenza
dell’utente primario, ossia il primo destinatario.
 Spostare i bug tra differenti installazioni
 Salvare e condividere ricerche.
Esiste una macchina chiamata Landfill, sulla quale sono state installate diverse
versioni di bugzilla pronte per essere utilizzate. Naturalmente non tutte le versioni
58
prevedono il supporto di tutte le caratteristiche perché alcune di esse devono essere
opportunamente attivate. Landfill rappresenta un ottimo strumento per poter fare un
“giro di prova” con Bugzilla.
Vantaggi Lato Amministratore
 Elevata Sicurezza. Immunità da cross-side scripting, fuga di informazioni e
spam.
 Alto livello di personalizzazione sia per quanto riguarda l’interfaccia grafica e
sia per quanto riguarda task più complessi. Per la prima è possibile
personalizzarla modificando i template, mentre per i secondi si può attingere
sia da una lista di estensioni già disponibili e pronte per l’installazione e sia
optare per una soluzione ancora personalizzata che prevede la scrittura di una
propria estensione seguendo naturalmente le linee guida dell’organizzazione.
 Customizzazione sia dei campi e sia del workflow. Supporto completo alla
codifica UNICODE.
 Localizzazione. Gli amministratori possono configurare Bugzilla, con le lingue
supportate dai loro impianti ed automaticamente inviate dai server,
localizzando gli utenti sulla base del HTTP ‘Accept-Language’ intestazione
inviata dal browser degli utenti stessi.
 Bugzilla può essere eseguito sotto Apache’s mod-perl ottenendo così il
massimo delle prestazioni in termini di tempo di caricamento delle pagine,
oppure essere eseguito sotto un ‘ambiente non mod-perl come per esempio
Apache’s normal mode CGI.
 Interfaccia web service accessibile e modificabile tramite XML-RPC o JSON
RPC per garantire la scrittura di strumenti esterni che possono interagire con
Bugzilla.
59
 Controllo visibilità/editing dei bug. L’amministratore di bugzilla può
effettuare qualsiasi altro ruolo, cosa che può risultare molto utile in diverse
situazioni.
 Autenticazione. Sono previste forse di autenticazione sia sul proprio database
o su un server LDAP.
 Controllo (Sanity-Check). Serve a rilevare eventuali incongruenze, risolverle
automaticamente o offrire una possibile soluzione di risoluzione.
2.4 Buzgero
Bugzero è un’applicazione software di bug tracking web-based client-server,
proprietario di websina la cui prima versione è stata rilasciata nel 2001([24]). E’ un
sistema facile, intuitivo la cui semplicità ne ha permesso l’adozione anche in
ambienti professionali. Questo prodotto può essere utilizzato dagli sviluppatori
software e tester per il bug tracking ma anche come strumento di monitoraggio delle
vendite e come sistema di help-desk. Si può dire che esso rappresenta più di un
semplice bug-tracker in quanto consente la gestione dei requisiti, dei casi d’uso e dei
casi di test. La sua realizzazione è basata su tecnologie standard, web-based, robuste,
leggere e scalabili. E’ scritto interamente in Java e questo gli conferisce la
caratteristica di essere cross-platform. Supporta SQL standard. Non soffre di
problematiche di accessibilità legate a firewall e infatti esso può essere fruibile da
qualsiasi parte attraverso HTTP, HTTPs o SMTP. La configurazione di Bugzero non
richiede particolari skills di programmazione così come anche i meccanismi di
aggiunta di dati, infatti è previsto il supporto a circa 100 tipi differenti di dati inclusi:
data time, URL, cross-project link ecc. Permette come altri bug-tracker la possibilità
di definire regole di accesso e controllo di permessi e un flusso di lavoro flessibile in
maniera tale da poter essere adattato con semplicità al proprio progetto. Supporta
relazioni bidirezionali tra i progetti, per esempio è possibile collegare un bug report
ad un test case e offre meccanismi di notifica basati su e-mail e su interfaccia web.
Bugzero é stato oggetto di revisioni di sicurezza effettuate da varie aziende, alle quali
60
ha risposto egregiamente e ciò ha permesso di etichettarlo come un prodotto sicuro.
E’ conforme alle norme ISO/IEC 2000 standard per la gestione dei servizi IT. Dopo
questa descrizione possiamo elencare altre caratteristiche di questo prodotto.
 Layout di pagina personalizzabile.
 Supporto multilingue. In particolare sono supportate tutte le lingue che usano
UTF -8, tra cui cinese, giapponese e coreano.
 Supporto
multi-progetto, controllo di accesso configurabili e auto-
registrazione.
 Configurazione bug-assegnazione automatica e manuale.
 Allegati (può allegare più file e qualsiasi tipo di file alla volta).
 Assegnamento del bug a gruppi di utenti.
 Supporto cattura dello schermo.
 E-mail di notifica, conferma e posta cc.
 Trigger configurabili. Mail di notifica (per progetto, per utente).
 L’integrazione del controllo di versione sorgente CVS, Subversion e Perforce
tramite e-mail.
 Rapporti e Metriche. Ricerca avanzata e le query memorizzate sono
riutilizzabili.
 Calendario per la selezione della data. File di esportazione CSV e supporto
lingue asiatiche in Unicode.
 Supporto LDAP / autenticazione dell’utente Active Directory (disponibile
come add –on ).
 E-mail promemoria personalizzati, escalation e possibilità di attivare azioni
(disponibile come add-on).
 Facilità di backup e ripristino in caso di crash hardware o software
2.5 Redmine
Redmine è un software di project management e bug tracking open-source e web
based. La sua prima versione è stata rilasciata nel 2006 ([25]), implementato
61
utilizzando il framework Ruby on Rails offre, dunque, la possibilità di essere crossplatform e cross-browser. E’ disponibile in trentaquattro lingue e può supportare
DBMS come MySQL, PostgreSQL e Sqlite. Essendo un software di projectmanagement offre la possibilità di gestire progetti in relazione ai permessi concessi
ai vari utenti e vari meccanismi relativi all’archiviazione, copia e cancellazione. In
questo modo ogni utente avrà accesso a determinati progetti in cui rivestirà un
determinato ruolo. Ogni progetto può essere dichiarato pubblico o privato a seconda
della visibilità che si intende conferire. Per quanto riguarda la gestione utenti è
prevista la presenza di una user-list che permette di visualizzare tutte le informazioni
(Login, First name, Last name, Administrator, Created, Last Connection) relative agli
utenti e il loro stato (active, locked e registred). Ogni progetto è organizzato in
moduli (es. wiki, repository, issues tracking ) che possono essere abilitati o
disabilitati. Focalizziamo ora l’attenzione sull’oggetto di nostro interesse, ovvero il
sistema di issue tracking. Può essere definito tracker in questo sistema una qualsiasi
issue o bug che sarà oggetto di analisi. Per ogni tracker si dovrà definire (come in
figura 2.7 ) il nome e specificare se i problemi legati al quel bug dovranno essere
mostrati durante l’analisi o se devono essere “merged” qualora appartengano a
differenti workflows.
Figura 2.7 Redmine - nuovo tracker
Issues Tracking
La ricerca delle issues è uno degli aspetti fondamentali di Redmine. Questa, può
rivolgersi a progetti che appartengono a determinati proprietari o team e che possono
62
essere legati a versioni differenti. Una issue può assumere differenti stati che possono
essere configurati liberamente ma ognuno di essi dovrà disporre di una delle due
opzioni configurabili: Closed e Default. Rispettivamente indicano che la issue è
considerata chiusa mentre il secondo indica lo stato da applicare appena la issue
viene creata. Esiste un pagina apposita, accessibile direttamente dall’interfaccia di
Redmine che consente di vedere lo stato attuale delle issues, in relazione alla loro
risoluzione e ai tempi. A questa pagina gli sviluppatori possono accedere per fornire
segnalazioni e fare in modo che issues correlate vengano notificate e gestite così da
evitare la creazione di duplicati o per semplificare il workflow di un altro team di
sviluppo. E’ possibile collegare issues basate su differenti tipi di rapporti grazie a
diverse opzioni. L’opzione related to viene usata solo per segnalare a chi è relativa
la issue. L’opzione duplicates collega la issue a qualche altra molto simile.
Duplicates by è il reciproco di duplicates (es. la chiusura di B lascia aperta A, la
chiusura di A chiuderà automaticamente B). Blocked collega issues la cui chiusura
può essere bloccata da qualche altra ancora aperta. Blocked by reciproco di blocked.
Precedes, permette di ordinare i collegamenti alle issues ad esempio in base alla data
per cui è prevista la risoluzione. Infine l’opzione follows che corrisponde al reciproco
di precedes.
Sottomissione nuova issue
In figura 2.8 viene riportato il form per la sottomissione di una nuova issue al
sistema, con la relativa descrizione, stato, priorità e assegnatario. Inoltre è possibile
specificare la data di inizio (sottomissione), la scadenza, il tempo stimato per la
risoluzione e la percentuale che è stata completata. E’ stato aggiunto un osservatore
della issue, “Giacomo Verde” che ha il ruolo di utente sviluppatore.
63
In Redmine si definiscono Watcher tutti i membri di un determinato progetto che
monitorano un determinato issue. Il sistema, a seguito di una qualsiasi modifica,
prevede un istantaneo meccanismo di notificata a tutti i watcher.
Figura 2. 8 Redmine - Inserimento nuova issue
La modifica di una issue può avvenire grazie all’interfaccia grafica la quale mette a
disposizione uno strumento molto comodo (figura 2.9) attraverso il quale è possibile
accedere agevolmente ai campi della issue che si intende modificare.
Figura 2.9 Aggiornamento issue
Naturalmente i permessi sulla modifica dipendono dal ruolo dell’utente che la
richiede e dai privilegi che gli sono stati concessi. E’ presente una issue Summary
organizzato in tre blocchi dove vengono mostrati il numero di issues aperti, chiusi e
il totale.
64
Workflow
La definizione del workflow consente di definire una serie di transizioni di stati che i
vari membri del progetto devono seguire, stabiliti in base alla tipologia degli issue.
La creazione del workflow avviene sempre grazie all’interfaccia grafica, con la quale
si dovrà selezionare il ruolo e il tracker per il quale si decide di creare/modificare il
workflow e sarà possibile selezionare le transizioni autorizzate in base al ruolo scelto
e tracker. Si può notare (in figura 2.10) la presenza di due colonne: Current State e
New State allowed. Esse rispettivamente indicano lo stato attuale (stato di partenza) e
il prossimo stato che può essere raggiunto a seguito di una transizione.
Figura 2.10 Redmine workflow
Ulteriori Caratteristiche
Oltre al supporto multi-progetto, Redmine fornisce il supporto alla generazione
dinamica della documentazione, integrazione con wiki, blog integrati e forum di
discussione interni. Supporta la creazione delle issues via e-mail e la notifica su
eventuali variazioni apportate, sia via e-mail che Atom feed. Inoltre dispone della
possibilità di programmare le operazioni tramite calendario e la possibilità di
esportare file in PDF, Excel/CVS e grafici Gnatt. E’ possibile l’integrazione e la
personalizzazione dei piani di test. Supporta la codifica unicode e la
personalizzazione di molti campi relativi a progetti, issues e di un set di API per
permettere agli sviluppatori di estendere alcune delle sue funzionalità. Per quanto
riguarda le interfacce di input abbiamo e-mail, web, MyLyn (sottosistema eclipse per
65
il task management). I meccanismi di notifica previsti sono e-mail, feed RSS e Atom
e twitter. Per quanto riguarda l’integrazione con strumenti di SCM (software
configuration management) e quindi gli aspetti relativi alla Revision control sono
supportate diverse soluzioni: Git, Mercurial, Baazar, Darcs, CVS e Subversion.
Infine, per l’aspetto dell’autenticazione si possono avere soluzioni che vanno da
Form- based, OpenId e LDPA.
2.6 Trackstudio
Trackstudio è un sistema di issue-tracking, proprietario e web-based ([26]). Supporta
un workflow engine e un sistema di gestione dei documenti che può essere utilizzato
per tenere traccia dei bug rilevati e della loro gestione, dei requisiti raccolti, della
gestione ed organizzazione di progetti. Implementato in java è un issue tracking
generico il quale è stato progettato per la gestione di un elevato numero di tasks,
difetti e cambiamenti di requisiti. Il suo servizio si basa su cinque aspetti
fondamentali:
1. Possibilità di gestire/organizzare gerarchicamente un grande numero di attività.
Questo permette di organizzare in maniera più efficiente la complessità crescente dei
tasks dividendoli in sottotask così da permetterne un’analisi semplice e al tempo
stesso più accurata. Questa caratteristica non viene offerta da tutti i sistemi perchè
comporta dei meccanismi di gestione piuttosto onerosi.
2. Possibilità di gestire in maniera gerarchica grandi gruppi di utenti, compreso staff
e client.
3. Permette di mantenere gli standard di project management unificati pur tenendo
conto delle peculiarità dei singoli progetti. Consente ereditarietà di strutture di
progetto e offre la possibilità di personalizzarle per soddisfare le esigenze particolari
dei singoli gruppi e dipartimenti.
4. Consente di ridurre i costi di manutenzione e di ridurre al minimo i rischi per la
sicurezza.
66
5. Interoperabilità e possibilità di lavorare con diverse piattaforme hardware.
Analizziamo ora le caratteristiche di questo issue tracker con maggiore livello di
dettaglio.
User Interface. Essendo un sistema web based, sfrutta la potenza di internet per la
diffusione della conoscenza e per garantire un accesso al sistema da qualsiasi parte
del mondo. Questa interfaccia è stata realizzata in modo cross-browser ossia supporta
quasi tutti i browser presenti sul mercato e consente una personalizzazione dello stile,
dei temi e della lingua. Prevede dei form javascript based per la validazione.
Task Management. E’ prevista la possibilità di organizzare il proprio database in
progetti e sotto progetti rendendo dunque la gestione più semplice. C’è la possibilità
di correlare dati affini di più progetti in unico report, consentendo così la formazione
di informazioni più accurate e dettagliate che permetteranno di dare vita ad un
processo di monitoring condiviso da tutta l’organizzazione. I task possono essere
classificati con un nome, una priorità, uno stato, campi di risoluzione e una possibile
deadline di risoluzione. Ai task va associata una categoria, che servirà per
sottometterli al workflow. I tempi stimati di elaborazione vengono conservati nel
database e si possono cambiare i valori appena presentati grazie ad un editing tool
appositamente predisposto. Si possono infine dividere i vari bug in diversi “sottobug” mantenendo però sempre il riferimento al bug principale.
Filtering. Si possono creare filtri per ricercare task con criteri più complessi. Oltre al
supporto delle operazioni logiche di AND, OR, NOT è prevista la possibilità di
classificare i filtri in pubblici e privati, per progetti, per singoli campi o per campi
relativi ai vari messaggi.
Campi Personalizzati. Possono essere aggiunti ai task in numero non limitato ed
essere utilizzati per cogliere informazioni specifiche sui singoli task. E’ prevista la
possibilità di ereditarietà dei singoli campi e il supporto a campi come int, string,
float, double, list, multilist, task link, user link e URL .
67
E-Mail Notification. Notifica automatica e altamente personalizzabile assicura che
tutti i membri del team che sono legati a quel problema sono costantemente informati
sulle relative modifiche grazie all’invio di e-mail. Anche in questo caso l’invio delle
e-mail può essere personalizzato in base a differenti parametri che caratterizzano i
singoli task, in base alla diverse figure del team di sviluppo a cui devono essere
inviate e ad altri criteri di classificazione come gruppi di progetti.
E-Mail Submission. Il sistema offre la possibilità di elaborare automaticamente le email che rispondo a determinati requisiti aggiungendoli ad esso oppure decidere di
eliminarli qualora non soddisfino i requisiti specificati.
Workflow. E’ previsto un workflow basato sugli stati (state-based) che consente di
specificare e di applicare il meccanismo di tracking tramite l’osservazione della
transizione degli stati. Per ogni stato sono previsti requisiti di sicurezza che devono
essere rispettati per garantire che il database sia sempre aggiornato e in maniera
corretta. Il workflow può essere personalizzato in stati, transizioni e può essere
soggetto a cambiamenti senza interrompere il lavoro. Possono essere creati un
numero indefinito di workflow, ci possono essere categorie di task che appartengono
a più worflow ed è prevista inoltre l’ereditarietà dei workflow. Altre operazioni
possibili sono: mostrare un numero limitato di stati o di transizioni per un dato stato
verso un altro, copiare l’intero workflow in un altro e l’integrazione tra workflow e
e-mail notification service.
Reporting. Meccanismo utilizzato per gestire le risorse coinvolte nel progetto e
analizzare cosa è stato fatto e cosa manca (stato di avanzamento del processo).
Security. Si possono impostare diversi livelli di sicurezza per proteggere le proprie
informazioni da intrusioni. Si possono inserire restrizioni sia per quanto riguarda
l’accesso ai singoli bug sia per quanto riguarda intere aree di tracking. Viene offerto:
supporto LPDA, Active Directory, NTLM, Security police support e SSL encryption.
Possibilità di configurare regole di auto-registrazione di utenti esterni. E’ possibile
specificare chi sarà il responsabile del gruppo di utenti appena creato. Vengono
68
memorizzati gli hash associati alle singole chiavi le quali possono essere assegnati
con criteri personalizzati. Sicurezza anche per quanto riguarda accessi, permessi
relativi a singoli utenti, gruppi o amministratori.
Integration. Trackstudio prevede di utilizzare SOAP API per poter essere integrato
facilmente con il proprio call-center, front-office o un altro third-party software.
Questo lo delinea come un’architettura estensibile grazie al supporto delle SOAP
API (java e .Net compatibili ). Inoltre è possibile un integrazione/supporto diversi
software e protocolli: Microsoft Outlook, Microsoft Project, Microsoft Word,
Microsoft Excel, CVS Subversion, IIS LDAP, NTLM, Active Directory, Eclipse,
IntelliJ IDEA, Borland Jbuilder.
Easy Deployment. Grazie al supporto di un’opportuna guida è possibile configurare
l’applicazione in maniera tale da poter lavorare con qualsiasi tipo di server e DBMS.
Non è necessario installare software di terze parti (plug-in) per poter garantire la
compatibilità.
Server Manager. Per la configurazione è richiesto il settaggio della porta e protocollo
(HTPP/ HTPPs), codifica caratteri, connessioni DBMS, connessione POP3,
connessione SMPT, connessione POP3, connessione LDAP, connessione di Active
Directory, di NTLM, di SCM. Tutti questi collegamenti possono essere testati prima
della messa in esercizio. Si possono cambiare le proprietà elencate in qualsiasi
momento ed è previsto il supporto di trasferimento dati tra DBMS grazie a
import/export XML.
Scalabilità. Trackstudio supporta la più ampia gamma di server di applicazioni
commerciali e open source, DBMS e può essere eseguito su qualsiasi piattaforma.
Fornisce supporto al multithreading e sottosistema cache a tre livelli ottimizzato per
l’elaborazione gerarchica. Supporta OS come Microsoft Windows, Sun Solaris, IBM
AIX, Hewlett Packard HP-UX. Supporta DMBS Oracle, IBM DB2, MS SQL,
Interbase, Firebird, PostgreSQL e HSQLDB e server web come BEA Weblogic,
Apache Tomcat, Jboss, Gettata, Caucho resina.
69
2.7 Polarion
Polarion rappresenta una piattaforma collaborativa web based in grado di rispondere
alle diverse esigenze di gestione applicativa ([27]). La sua offerta si differenzia in tre
prodotti: Polarion Requirement, Polarion QA, Polarion ALM. Adotta un sistema
nativo basato su clustering utilizzando server multipli (fisici e virtuali) per garantire
load balancing e implementare strategie di fail-over.
Polarion Requirement
Polarion Requirement è una soluzione browser-web progettata al fine di supportare
in maniera altamente efficiente la collaborazione tra contesti differenti (interni ed
esterni) tra team diversi team di sviluppo. Le caratteristiche più importanti di questa
soluzione vengono di seguito presentate.
1. Completa possibilità di personalizzazione del workflow in modo da poterlo
adattare a processi esistenti (supporta metodologie agile, Waterfall, Regulatory e
Hybrid) e ambienti personalizzati come ad esempio RUP, Scrum, FDD, Kanban ecc.
Dispone di project-templates pre-configurati e comunque personalizzabili in modo da
poter rispettare a pieno di tutti i componenti del progetto. Infine automatizza il
workflow in modo tale da ridurre gli errori.
2. Permette l’import di file word, excel, pdf che contengono casi di test, difetti ecc.
disponendo della possibilità di visualizzare un’anteprima per essere certi del file che
si vuole importare e se confermato importare il documento in modo esattamente
corrispondente al documento originale. Polarion permette anche l’operazione
inversa, ossia modifiche apportate all’esterno di Polarion possono essere importate
mantenendo la formattazione originale.
3. Diversi formati per esprimere i requisiti e possibilità di creare ogni genere di
diagramma.
70
4. Supporto di UML-Flow-charting e BPMN (Business Processing Modeling e
Notation) e possibilità di esportare i diagrammi grazie a LiveDocs in Word e
Documenti PDF.
5. Collaborazione real-time tra tool e team grazie alla possibilità di un servizio di
sincronizzazione delle informazioni scambiate tra i vari team; questo viene reso
possibile grazie al fatto che Polarion è una soluzione 100% web based.
In modo automatico viene costruita una history di come sono state prese le decisioni.
E’ prevista elettronic sign-off, dove le firme elettroniche sono conformi a CFR 21
Part 11.
6. Supporto Nativo alla ReqIf (Requirements Interchange Format) e garantita
Tracciabilità tra molti tools e documenti.
7. Test Management centralizzato possibilità di gestire diversi casi di test su di un
unica piattaforma. Si possono importare casi di test da diversi Third-party, gestirli
con qualsiasi tipo di browser. Vengono creati automaticamente report su bug e task
per agli sviluppatori basati sui fallimenti.
8. Possibilità di riuso dei documenti grazie a Live branch senza dover effettuare
copia-incolla.
9. Tracciabilità. In ogni momento è possibile conoscere “chi, cosa, quando e perchè”
relativi ad ogni cambiamento. Questo grazie al fatto che viene creato un link per ogni
componente dalla sua creazione fino al rilascio, il collegamento tra i vari moduli può
essere uno a molti o molti a uno compreso quello tra i progetti. E’ possibile grazie
alla funzionalità “Visual Dif” confrontare i vecchi documenti con quelli nuovi per
vedere i cambiamenti salienti ed è possibile risalire a qualsiasi dato storico grazie a
“Time Machine”. Infine è provata la conformità a molti standard di controllo di
qualità e di processo: FDA, FAA, ISO, SPICE, CMMI, IEC, CPI.
71
Polarion QA
Polarion QA rappresenta una soluzione nata per gestire il rispetto delle norme vigenti
sulla Quality Assurance e fornire supporto all’attività di testing. Condivide gran parte
degli aspetti di Polarion Requirement introducendo piccole differenze per quanto
riguarda il reporting che in questo caso prevede la possibilità di controllare lo stato
attuale del progetto anche con dispositivi mobili. Infine molto importante è
possibilità di integrare Polarion con differenti soluzioni third-party proposte per la
QA e altro come per esempio: HP Quality Center (software testing and test
management), Atlassian JIRA (defect tracking and Agile project management),
MATLAB Simulink (hardware design and modeling), Sparx Enterprise Architect
(UML modeling, model-driven design) Etc. Si possono creare le proprie estensioni
utilizzando java e Web Service APIs oppure rivolgersi a Polarion per poter creare, su
richiesta un “connettore” a qualsiasi tipo di servizio esterno.
Polarion ALE – Application Lifecycle Management
Rappresenta la soluzione più completa offerta da Polarion in quanto riesce a coprire
tutti gli aspetti relativi al ciclo di vita di un progetto (figura 2.10), dalla trasparenza al
supporto ai team di sviluppo in maniera rapida ed efficiente all’eventuale variazione
dei requisiti e delle esigenze dei clienti, inglobando sia le caratteristiche di Polarion
Requirement e Polarion QA.
72
Figura 2.11 Polarion ALM
Analizziamo i singoli aspetti coperti da Polarion ALM.
Requirements Management. Possibilità di importare dati e documenti sia da Excel,
Word e PDF per poter essere poi agevolmente modificati. Collaborazione on-line
sugli stessi o off-line tramite il servizio Polarion Round-Trip. ReqIf integrato che
consente scambio di requisiti tra clienti e fornitori senza alcuna perdita.
Test & Quality Assurance. Polarion offre sia uno strumento di test e sia di QA in
modo da poter ridurre i costi e migliorare la qualità complessiva. Una volta progettati
i casi di test si possono creare esecuzioni programmate e riportare i risultati alle parti
interessate.
Issues e Defect Management. Sono previsti modelli built-in per gestire rischi
potenziali o con un approccio basato su analisi FMEA (Failure Mode standard Effect
73
Analys), oppure utilizzando un approccio basato su workflow personalizzato in base
alle proprie esigenze.
Change Configuration. Possibilità di personalizzare l’ambiente in base alle proprie
necessità (funzionali e non).
Audits, Metrics e Reports. Permettono di gestire rischi e problemi, in modo più
efficiente grazie al fatto che le potenziali minacce vengono rilevati nelle prime fasi
del lifecycle.
Resource Management, Build & Release e Variant Management. Sono realizzati
grazie a workflow flessibili e personalizzabili che consentono di adattare le
modifiche su risorse, release e variazioni nelle decisioni possano essere subito rese
esecutive con il minimo impatto in termini di tempi e costi. Per quanto riguarda la
build & release è prevista l’integrazione con tools leader come Hudson, Ant e Maven
2.8 Serena – Issue and Defect Management
Serena “Issue and defect Management” è una piattaforma che nasce al fine di fornire
un servizio automatizzato a supporto dei team di sviluppo IT per quanto riguarda la
cattura, il routing, la collaborazione e la risoluzione nella gestione dei difetti ([28]).
Questa piattaforma, ampiamente diffusa, si prefigge di gestire le issues in maniera
rapida ed efficiente così da contenere costi e tempi, supportare le attività di sviluppo
tra i vari team in maniera automatica e sicura ed assicurare che tutti gli attori
coinvolti nel processo di sviluppo abbiamo le informazioni di cui necessitano al
tempo giusto. Serena è altamente configurabile, cosa che permette di adattare la
piattaforma alle nostre esigenze di progetto. Offre un interfaccia utente web-based,
user-friendly che permette di gestire e monitorare il processo di sviluppo sia con
team interni all’organizzazione e sia con team dislocati in altri luoghi. Dispone di
servizi di reporting, notifica, supporti grafici e gode di ottima interoperabilità con
altri sistemi. Vediamo alcune caratteristiche di questo prodotto.
74
Issue Capture. La sottomissione delle issues al sistema può avvenire sia tramite
appositi moduli web configurabili, messaggi e-mail o altri sistemi come service desk.
I campi da “catturare” relativi alle issues, sono selezionabili in base alle informazioni
che vogliamo analizzare.
Issues Routing. Una volta catturate, le issues vengono inserite in un processo che
segna varie tappe (es. figura ) fino alla loro risoluzione. Ogni issue viene assegnata
ad un determinato processo evitando così che qualcuno venga non considerato.
Figura 2.12 Serena issue routing
Notifications. Serena mette a disposizione un servizio di notifica (figura 2.13)
configurabile in modo tale che tutti gli interessati ad una determinata issue vengano
informati al momento di un avvenuto cambiamento. Sono previste delle regole di
escalation grazie alle quali si possono fissare delle soglie per verificare se c’è
bisogno di maggiore attenzione circa determinati problemi.
Figura 2.13 Serena notifications
75
Web based End-user Client. Interfacce leggere basate su browser sono facilmente
accessibili e permettono a chiunque e in ogni momento la fruizione delle
informazioni di cui si ha bisogno.
Reporting. Report incorporati sono facilmente personalizzabili per visualizzare i
trend, lo stato e la data prevista per il completamento. Informazioni critiche come
Trova / Fix tempi e trend backlog sono sempre a portata di mano. Con l’utilizzo di
questi rapporti è possibile tenere traccia dello stato dei progetti ed evidenziarne
eventuali rischi. Inoltre, i rapporti sono URL indirizzabili, rendendo più semplice la
condivisione delle informazioni con altri.
Advanced Process Capabilities. Il motore di processo alla base del sistema è
utilizzato da migliaia di aziende su centinaia di processi, Issues e Defect
Management offrono la possibilità di fornire ai processi capacità avanzate in grado di
far crescere il sistema in relazione alla crescita delle proprie necessità.
Used and Role Based Configuration. Gli utenti possono creare dashboard
personalizzate, viste e report. Alcuni form sono role based, in modo tale da poter far
vedere solo agli utenti solo le informazioni previste per il loro profilo (figura 2.14).
Nella gestione delle issues abbiamo tre possibili ruoli: IDM Administrator, IDM
Manager, IDM Team.
Figura 2.14 Serena form role based
76
Form Design. Utilizzando un WYSIWIG drag-and-drop form design sarà possibile
progettare i propri form (figura 2.15) per catturare le informazioni e visualizzarle.
Differenti informazioni possono essere visualizzate in varie fasi del processo di
issues management.
Figura 2.15 Serena form design
Process Design. La creazione o modifica di processi è semplice utilizzando la
finestra di progettazione (figura 2.16) di processo drag-and-drop che permette di
modificare e pubblicare i cambiamenti apportati al processo di gestione degli issues.
Figura 2.16 Serena process design
Data Design. La raccolta di nuove informazioni utili al processo di gestione degli
issues viene semplicemente realizzata grazie all’operazione di draggin-and-dropping
di un nuovo campo in un form.
77
Compliance e Audit. Supporto alle firme elettroniche e registri dettagliati di controllo
danno la possibilità di vedere ogni cambiamento ( quando accade e perché, figura
2.17 ), nel rispetto di mandati di conformità come Sabernas-Oxley, HIPAA o 21CFR.
Figura 2.17 Serena Compliance e Audit
Security and Administration. Diversi livelli di privilegi permettono di garantire
elevata sicurezza. Funzioni di amministrazione di classe enterprise, inclusi i privilegi
granulari e il supporto per i server di directory, lo rendono facile da amministrare
anche per più grandi implementazioni.
Integration. Serena issues e defect management è integrato con molti degli strumenti
di sviluppo più diffusi, tra cui HP Quality Center e Serena Dimension. Inoltre è
disponibile un ampio set di API, di servizi web e funzionalità di orchestrazione visivi
che ne aumentano il livello di integrazione.
Rich interface mashup. Grazie a questa capacità sarà possibile avere le giuste
informazioni sempre a portata di mano. Ad esempio è possibile disporre
contemporaneamente delle informazioni relative allo sviluppo che ad esempio si
trovano nel Wiki e di quelle relative alla issue management, agevolando così il
processo decisionale ed evitando di fare “salti” da una finestra all’altra.
Process Mashup. Grazie alla presenza di un drag-and-drop orchestrator designer è
possibile collegare un processo ad altri processi o sistemi tramite web services.
78
Serena rende facile ed efficace la gestione delle issues e di tutti gli aspetti alla base
del processo di defect management. Serena Defect Management è offerto sia come
servizio on demand e tradizionale (on-premise) sotto distribuzione. Serena On
Demand si basa su un’architettura multi-tenanted nella quale i dati di ogni
organizzazione vengono associati a namespace differenti in maniera tale da essere
indipendenti da quelli di altre organizzazioni che sfruttano la stessa architettura.
Questo ambiente on-demand è una forma di cluod SaaS, che garantisce tolleranza ai
guasti, sfrutta tecniche di clustering, di scaling verticale e bilanciamento del carico
per ottimizzare la gestione dei dati utente. Benefici tangibili per le organizzazioni che
ne adottano questa soluzione sono: riduzione dei costi di gestione e di manutenzione,
infrastruttura scalabile e flessibile e costi prevedibili.
2.9 IBM- Rational Quality Manager
IBM Rational Quality Manager è un tool che appartiene alla categoria di soluzioni
ALM (Application lifecycle management) la quale permette di gestire il flusso di
utenti, processi, informazioni in un ciclo iterativo di attività di rilascio del software
offrendo le basi per un miglioramento in termini di scalabilità, reporting,
automazione e collaborazione tra i team. L’offerta ALM di IBM è molto ampia,
infatti sono previste soluzioni che forniscono supporto per: Architettura e
Progettazione, Gestione dei Requisiti, Gestione dell’erogazione e dei requisiti del
portfolio, Gestione dei test e della qualità, Software change & Configuration
Management, Sviluppo Applicativo, Sviluppo e Implementazione. Le soluzioni
Rational di IBM permettono la riduzione dei costi e dei rischi che caratterizzano il
processo di sviluppo del software, grazie alla possibilità di unificare l’infrastruttura
con un’unica piattaforma Jazz, aperta, aggiornabile ed integrabile con l’intero ciclo
di vita di fornitura del software offrendo la possibilità agli stakeholder di poter
beneficiare di trasparenza e collaborazione in tempo reale. I vantaggi offerti da
questo tipo di soluzioni sono di seguito elencati.
79
1. Rispondere alle esigenze specifiche dei domini dei professionisti competenti,
consentendo un flusso di idee e informazioni in tempo reale all’interno del
team.
2. Migliorare la collaborazione tra i team, geograficamente distribuiti, sistemi,
discipline e organizzazioni.
3. Ridurre il TCO attraverso gestione, sicurezza e implementazione semplificate
e pronte per le aziende.
4. Ridurre i costi globali, unificando l’infrastruttura in un’unica piattaforma.
5. Rispettare i requisiti di conformità tramite workflow approvati e tracciabilità
degli asset.
6. Fornire un’infrastruttura per un miglioramento continuo delle funzionalità
tramite l’applicazione di processi flessibili, basati sulle regole, reporting in
tempo reale e best practice integrate.
7. Ottenere “l’agility at scale”, scalando le procedure consolidate ai team di
qualsiasi dimensione o configurazione
RQM è uno strumento collaborativo, web-based che offre la possibilità di
pianificazione, creazione di test e gestione di asset di test durante l’intero ciclo di
sviluppo software. Questa soluzione, sostituisce IBM Rational Manual Tester, IBM
Rational ClearQuest Test Manager e Rational TestManager. Rational Quality
Manager si basa sulla piattaforma Jazz (figura 2.18), da cui ne eredita molte
caratteristiche. E’ stato progettato per poter essere utilizzato da team di test di diverse
dimensioni ed offre la possibilità di diversi ruoli utente (amministratore di repository
e server, amministratore progetto, test manager, architetto di test, test leader, tester e
test lab manager) con il supporto altresì di ruoli esterni all’organizzazione.
80
Figura 2.18 Architettura RQM
Pianificazione di test
Il piano di test è visto in Rational Quality Manager come un contratto di qualità che
definisce gli obiettivi. Di conseguenza è gestito per essere dinamico ed evolvere con
il progetto. In questo contratto di qualità vengono descritti in modo chiaro gli
obiettivi del progetto e le priorità, permettendo ad ogni membro del team di
conoscere tali obiettivi e di svolgere il proprio lavoro in linea con essi relativamente
al ruolo rivestito nel progetto. È possibile utilizzare il piano di test per completare le
seguenti attività:
 Definire obiettivi aziendali e di test.
 Stabilire un processo di revisione e approvazione per il piano di test e per i
singoli scenari di test.
 Gestire requisiti di progetto e scenari di test, quindi stabilire le interdipendenze
tra i due.
 Stimare la dimensione dello sforzo di test.
 Definire la pianificazione per ogni interazione del test e tenere traccia delle
date di altre attività di test importanti.
81
 Visualizzare i vari ambienti da testare e generare configurazioni di test.
 Creare un’istantanea di sola lettura del piano di test in un determinato punto.
 Definire obiettivi di qualità, criteri di entrata e criteri di uscita.
 Creare e gestire scenari di test.
Inoltre IBM Rational Quality Manager comprende una tecnologia concepita per
identificare e selezionare automaticamente, il minimo numero di test necessari per un
determinato livello di copertura. Ciò permette ai tester di potere ottimizzare la
copertura della configurazione nell’osservanza dei rispettivi vincoli di tempo o di
risorse. I test asset possono essere esportati in pdf.
Creazione, esecuzione e riutilizzo di script di test
IBM RQM fornisce un editor di test manuale ricco di funzioni ed offre la possibilità
di importare gli script di test manuali da Rational Manual Tester. Sono previste
funzioni di riutilizzo e automazione ai test manuali utilizzando le parole chiave. Si
possono inoltre importare soluzioni risorse utente di test da soluzioni di gestione test
esterne, come Rational Clearquest Test Manager e Rational TestManager.
Analisi e report di test
È disponibile un’ampia varietà di report formali e personalizzabili, che possono
raccogliere informazioni a vari livelli di granularità, per permettere a tutti i
componenti del team di accedere alle informazioni di cui hanno bisogno. I report
sono disponibili durante tutte le fasi del processo di test e quelli offerti di default
sono: Difetti, Esecuzione, Gestione Lab, Requisiti, Scheda di valutazione, Riepilogo,
Sistema, Scenario di Test. È possibile anche installare lo strumento Rational Quality
Manager Custom Reporting per creare report personalizzati che utilizzano la
tecnologia avanzata di creazione report di Cognos grazie allo strumento Report
Studio. Si possono, inoltre, creare nuovi report personalizzati e gestire la
segnalazione dei difetti. Una volta cerato un report è possibile esportare i risultati in
82
applicazioni esterne in vari formati (Excel, Word, PDF, Postscript, PowerPoint). I
report personalizzati possono essere esportati solo in formato pdf.
Collaborazione del team
Rational Quality Manager consente di condividere le informazioni con altri membri
del proprio team. Il sistema di elementi di lavoro basati su Jazz consente ai membri
del team di assegnare attività e difetti, nonché di visualizzare lo stato di ognuno. Gli
autori dei piani di test e i designer degli scenari di test possono distribuire il loro
lavoro perché sia effettuata una revisione e per tenere traccia dello stato di ogni
revisore. I requisiti nuovi e modificati sono visibili al team, che può anche
visualizzare gli scenari di test necessari per soddisfare quei requisiti. I membri del
team possono visualizzare quali utenti sono collegati e su cosa stanno lavorando. Ai
membri del team può essere inviata automaticamente una notifica relativa alle
modifiche, agli input e ai punti cardine che influenzano il loro lavoro. Inoltre, gli
autori di piani di test, di scenari di test e di script di test possono inserire un blocco
sulle risorse utente, in modo che altri non le possano modificare.
Gestione Lab
Rational Quality Manager fornisce funzioni di gestione lab che consentono di creare
richieste per gli ambienti di test specificati nel piano di test. È possibile lavorare
insieme al lab manager per essere certi che le risorse lab e gli ambienti di test siano
disponibili quando necessario. I lab manager possono tenere traccia di tutte le risorse
lab da un repository di risorse centralizzato e delle richieste di servizi da altri team di
test.
RQM permette la gestione personalizzata dei ruoli degli utenti che partecipano al
processo di sviluppo e fornisce un insieme di ruoli predefiniti. In figura 2.19 viene
mostrato un possibile workflow nel caso in cui si decida di utilizzare i ruoli proposti
da R.Q.M, non obbligatorio ma sicuramente valido. Anche se il diagramma presenta
le attività in maniera sequenziale, nella realtà alcuni di questi vengono effettuate in
parallelo. Un primo utente è il Test manager che si occupa delle attività iniziali per
83
l’esecuzione dei test, infatti questo crea il piano di test e ne definisce gli obiettivi ed
assegna le attività da svolgere ai Test leader. Questi si occupano della creazione dei
casi di test e la loro associazione con i requisiti, pianificano l’esecuzione dei test
gestendo le risorse del laboratorio (assieme ai Lab manager) e assegnano le attività di
test e di verifica dei piani di test ai Tester. Questi ultimi si dedicano alla creazione
degli script di test, alla loro esecuzione e segnalazione dei difetti, oltre che della loro
risoluzione.
Figura 2.19 RQM Ruoli
Interfaccia Utente
Viene mostrata in figura 2.20 una screen capture che rappresenta una pagina di
esempio di Rational Quality Manager. I numeri presenti nell’immagine indicano la
presenza di diverse sezioni che verranno di seguito analizzate.
84
Figura 2. 20 RQM-Interfaccia utente
1. Banner Applicazione. Nella parte superiore della pagina è presente il nome del
prodotto. L’ID della persona collegata è visualizzato sul lato destro del banner con
un link predisposto per il log out. In basso sempre nel lato destro del banner sono
presenti informazioni sulla versione.
2. Barra delle attività globali. Contiene le opzioni di menu direttamente sotto al
banner dell’applicazione sul lato destro. Le opzioni sono Cerca, Gestione, Preferenze
e Guida. Per effettuare una ricerca globale di una risorsa utente in Rational Quality
Manager, immettere il nome della risorsa nel campo Cerca e fare clic sull’icona
Cerca.
3. Navigazione verticale. La barra laterale sinistra rappresenta un’area in cui sono
visualizzate le icone dei menu nella vista della pagina predefinita. Ogni icona apre un
elenco di opzioni di gestione test correlate. La prima icona permette
di utilizzare Rational Quality Manager per gestire i requisiti del progetto e di
85
importare i requisiti definiti in Rational RequisitePro. La seconda permette di
definire l’intero processo di test attraverso la creazione di un piano di test.
Questo individua le
caratteristiche
e ambienti
di test da
utilizzare,
i criteri
di ingresso e di uscita dei test, gli obiettivi di qualità e molto altro. La terza icona
Rational Quality Manager offre un editor integrato per creare un nuovo script di test
manuale,
oppure è
possibile
importare gli
script di
test manuale da
Rational Manual Tester. Gli script di test vengono poi associati a scenari di test che
possono essere anche raggruppati in suite di test più complesse. Con la quarta icona
si ha accesso alla gestione del laboratorio. La funzionalità aiuta a gestire le risorse
dei laboratori, fornendo un modo per tenere traccia delle risorse e gestire
prenotazioni di risorse di laboratorio e richieste. Tramite la quinta icona è
possibile utilizzare Rational Quality Manager per gestire l’esecuzione dei test sulle
build prodotte con Rational Team Concert, per ottimizzare la verifica della qualità.
La sesta icona offre una gestione completa dell’esecuzione dei test. La settima
permette l’accesso ai report, strumenti indispensabili per la gestione del progetto in
tutte le sue fasi. Infine la settima icona serve a gestire e visualizzare i difetti rilevati
durante l’esecuzione dei test (possibilità di integrazione con Rational ClearQuest
grazie a ClearQuest Connector).
4. Indice. Elenco delle sezioni disponibili nella pagina aperta. Facendo clic sui titoli
delle sezioni nell’indice si può passare direttamente a tale sezione.
5. Area del contenuto della pagina. E’ rappresentata dall’area al centro della pagina.
In questa area sono visualizzati gli editor delle applicazioni e le viste. Questo è il
punto in cui sono eseguite le attività che vengono aperte facendo clic sulle opzioni
dei menu di Rational Quality Manager.
6. Informazioni correlate. Vengono riportate nel riquadro sul lato destro della pagina.
Questa area contiene i collegamenti ai feed RSS e altre informazioni rilevanti. È
possibile ridurre a icona o eliminare questo riquadro in modo da ingrandire l’area del
contenuto della pagina.
86
RQM- Panoramica sui difetti
IBM Rational Quality Manager fornisce una serie di funzioni avanzate per l’inoltro,
la traccia e la gestione di difetti. È possibile gestire i difetti all’interno dello
strumento stesso oppure è possibile eseguire l’integrazione con altri strumenti, come
ad esempio IBM Rational Team Concert o IBM Rational ClearQuest. È possibile
inoltrare, tenere traccia e gestire i difetti a diversi stadi del processo di test,
eseguendo al tempo stesso varie funzioni di test.
In qualsiasi momento, è possibile puntare all’icona Difetti
e crearne uno nuovo
facendo click su di essa. In questo modo verrà visualizzato il modulo dell’elemento
di lavoro Difetto per qualsiasi sistema di gestione difetti configurato (Rational Team
Concert, Rational ClearQuest, Rational Quality Manager).
È possibile dichiarare un difetto come bloccante durante la visualizzazione dei record
di esecuzione test facendo clic su Gestisci difetti che bloccano
. Si può specificare
che un difetto esistente sia bloccante oppure crearne uno nuovo. In entrambi i casi, il
difetto bloccante viene definito selezionando il livello di sicurezza Bloccante nel
modulo del difetto. È prevista la possibilità di inoltrare un difetto durante uno
qualsiasi dei passi nel processo di esecuzione test manuale oppure inoltrare e gestire
un difetto durante la visualizzazione dei risultati di esecuzione.
Infine si possono inoltrare i difetti a Rational Quality Manager direttamente da un
report in Rational AppScan Tester Edition. I difetti contengono informazioni sui
problemi di sicurezza come ad esempio consigli e suggerimenti di fix, in modo che
gli sviluppatori possano risolvere i problemi prima di passare alla fase di produzione.
Estensione delle funzionalità del prodotto
È possibile estendere la funzionalità di Rational Quality Manager mediante l’utilizzo
di strumenti per creare, modificare, importare ed esportare asset di test.
Sono disponibili differenti approcci:
1. Rational Quality Manager Application Programming Interface (API) è il
meccanismo utilizzato da varie integrazioni per estendere la definizione e le funzioni
87
di Rational Quality Manager. Consente di eseguire diverse operazioni in maniera
programmatica con i dati nel repository, utilizzando un qualsiasi programma di utilità
in grado di eseguire operazioni HTTP.
2. Rational Quality Manager Copy Utility è un’applicazione Java autonoma, opensource, utilizzata per copiare asset di test Rational Quality Manager, ad esempio
piani di test, scenari di test e risorse lab. È possibile copiare asset di test nella stessa
area progetto, in un’area differente nello stesso repository Rational Quality Manager
o in un repository e server differenti insieme, rendendo possibile condividere risorse
utente comuni tra progetti e team. Questo strumento non viene inteso come
programma di utilità di backup.
3. Rational Quality Manager URL Utility è un’applicazione della riga comando Java,
autonoma, di esempio, in cui è possibile utilizzare l’API REST per caricare, scaricare
o eliminare asset di test su/dal server Rational Quality Manager. Questo strumento è
compatibile con Rational Quality Manager 2.0 o versione successiva
4. Rational Quality Manager Excel and Word Importers consentono alle applicazioni
Excel e Word di esportare asset di test in Rational Quality Manager tramite HTTP.
Grazie a questo programma di utilità, queste applicazioni possono esportare
direttamente asset di test in un formato XML ben definito. Il contenuto XML può
essere importato su un server Rational Quality Manager mediante protocolli HTTP
standard.
2.10 Tabelle comparative
Vengono di seguito riportate tre tabella comparative dei tools analizzati, che
riportano in sintesi le caratteristiche dei vari tools, permettendone di evidenziarne le
differenze. Quasi tutti i tools presentati, eccetto qualcuno, presentano le stesse
caratteristiche in termini di personalizzazione e gestione delle attività (divisibile in
progetti, sotto-progetti, permessi e gruppi). Tra questi quelli che sono stati provati
sono: Mantis, Jira, Bugzilla, ReadMine e RQM che risultano essere molto userfriendly ed offrono un alto grado di customizzazione. Questo fa si che si hanno delle
88
differenze proprio per quanto riguarda gli aspetti cardini della gestione delle issue
come ad esempio wokflow, ciclo di vita prodotto/progetto e comprensione da parte
degli utenti. Ad esempio Bugzilla presenta delle restrizioni per quanto riguarda la
possibilità di personalizzare il workflow e non offre tutte le funzionalità di cui
dispongono gli altri tre che sono stati provati (in termini di gestione di progetti, sottoprogetti e utenti). Presenta per altro, problemi per quanto riguarda l’integrazione con
altri sistemi e componenti cosa che ne penalizza un pò l’adozione in ambiti
industriali. Naturalmente prodotti come Jira, Polarion, Serena, TrackStudio
rappresentano soluzione altamente efficienti e personalizzabili che offrono un
supporto completo in termini di project management ma sono a pagamento. Per
quanto riguarda le soluzioni open-source un buon compromesso è offerto da
MantisBt e da Redmine.
Tabella 2.1 Confronto Tools (1/3)
89
90
2.11 Mantis e Jira a confronto
Per valutare le potenzialità in termini di customizzazione si è deciso di realizzare lo
stesso workflow per gestire un insieme di difetti acquisiti tramite importazione da un
file .cvs in due tool presenti nello scuoting: Mantis e Jira. Il workflow realizzato
prevede cinque stati e viene presentato in figura 2.21.
Figura 2.21 Workflow usato per il confronto
Il workflow considerato ha puramente lo scopo di mettere in relazione gli strumenti
messi a disposizione dai due tools. Non verrà focalizzata l’attenzione sui particolari
che riguardano la gestione in modo più dettagliato delle issues, cosa che porterebbe
sicuramente alla costruzione di workflow più complessi.
Nel workflow proposto è stato inserito lo stato “Risolta” dal quale solo il
manager/amministratore del progetto può decidere se riaprire l’anomalia e transitare
nuovamente in “Da_Discutere” (nel caso il processo di fixing non sia stato eseguito
conformemente alle indicazioni date) o ritenere che il fixing sia riuscito con successo
cosa che decreta la chiusura dell’anomalia.
La realizzazione in Mantis è stata ottenuta sfruttando i campi messi a disposizione
dal sistema, modificando solo il valore delle transizioni ed evitando di utilizzare altri
stati presenti che non sono necessari alla realizzazione del workflow preso in esame.
Lo schema dati relativo alle issues gestite è stato realizzato effettuando delle
91
customizzazioni sui campi, cosa che ha permesso l’aggiunta di informazioni, non
presenti nativamente in Mantis (e nemmeno in Jira) potendo così effettuarne un
mapping con i campi presenti nelle issue importate nei due sistemi di bug tracking.
Workflow in Mantis
Segue una prima immagine dove vengono mostrati i difetti acquisiti in Mantis da
importazione tramite file csv. In questo caso il tool crea una categoria denominata
csv-imported come mostrato in figura 2.22.
Figura 2.22 Mantis - Categoria csv_imported
Nella parte bassa della figura 2.22 è presente in maniera molto elementare il
workflow con il quale saranno gestite le issue acquisite. Naturalmente da qui non si
possono vedere le transizioni che ne determineranno l’evoluzione, ma serve solo a
fornire un’idea su quali stati compongono il workflow.
In figura 2.23 viene invece riportata l’interfaccia messa a disposizione da Mantis per
la personalizzazione del workflow. Da questa interfaccia sarà possibile definire le
transizioni in ingresso/uscita dai vari stati. E’ importante notare che da questa
interfaccia non è possibile aggiungere o rimuovere nuovi stati e quindi è possibile
92
lavorare solo con quelli built-in del tool (cosa che risulta essere un po’ limitante). Per
poter ignorare stati non necessari in un workflow, è necessario non definire nessuna
transizione verso di essi.
Figura 2.23 Mantis - gestione workflow
Workflow in Jira
Lo stesso workflow è stato implementato anche in Jira utilizzando lo stesso file .csv
da cui sono stati presi i difetti da importare formattati secondo lo stesso schema di
dati. Jira dispone (se configurato opportunamente) della funzionalità che permette di
importare direttamente i dati da un sistema Mantis, indicandone indirizzo IP del
server, porto (per Mantis 4001) e il tipo di database utilizzato da Mantis come
Backend. Questa funzionalità è prevista anche per altri sistemi come redmine,
fozbuz, track e risulta molto utile quando non si dispone dei file da importare o
quando il numero di difetti da importare è particolarmente elevato.
Nella figura 2.24 viene mostrato il workflow che è stato implementato
precedentemente in Mantis, denominato in questo caso WorkflowCopia con le stesse
transizioni e gli stessi stati. Jira dispone anche della visualizzazione in modalità
testuale come mostrato in figura 2.25.
93
Figura 2.24 Jira - workflow grafico
Figura 2.25 Jira - workflow testuale
94
Confronto
Sia Mantis che Jira offrono un alto livello di personalizzazione sia in termini di
workflow e sia in termini di schema di dati. Infatti in entrambi i tools si è rivelato
molto semplice l’aggiunta di campi personalizzati per poter mappare le issues nel
sistema in modo da essere coerenti al formato di acquisizione. Per quanto riguarda
l’importazione del file .csv, Mantis necessita dell’aggiunta di un plug-in che occorre
scaricare e collocare nella cartella plug-in della directory principale Mantis. Dopo
questa operazione, nell’interfaccia grafica è possibile visualizzare l’opzione “importa
da csv”. Jira supporta l’importazione dei .csv nativamente, senza l’aggiunta di nessun
plug-in. Per quanto riguarda il workflow Mantis si presenta leggermente più rigido e
meno flessibile rispetto a Jira. Questa rigidità risiede nel fatto che per poter
aggiungere nuovi stati al workflow occorre agire sui file di configurazione, in
particolare sui file: custom_constants_inc.php (per registrare il nuovo stato),
config_inc.php (per aggiungerlo allo schema del workflow in modo da renderlo
disponibile sull’interfaccia grafica). L’aggiunta di un nuovo stato prevede anche altre
operazioni come ad esempio la definizione del colore, la traduzione del nome nella
lingua in cui si utilizza Mantis e l’aggiunta del progetto a cui dovrà essere applicato.
Tutte queste operazioni richiedono una certa familiarità con il tool (e non solo) e
possono portare a commettere errori che possono compromettere l’operatività del
tool se non svolte con una certa cautela. Jira offre la possibilità di definire il
workflow in due modi differenti: testuale e grafico. Graficamente è semplicissimo
definire un workflow, aggiungere nuovi stati, transizioni e una volta realizzato
aggiungerlo al progetto di interesse poiché il tutto avviene grazie a semplici
operazioni di drag & drop. Per quanto riguarda la gestione delle issues entrambi sono
strumenti molto user-friendly che offrono un alto livello di customizzazione con la
possibilità di esportare i risultati in differenti formati (excel, .csv). Una funzionalità
che non è stata ancora implementata in Mantis è l’inserimento manuale della data di
95
detection da parte del reporter. Questo permetterebbe di inserire guasti rilevati e non
inseriti nel sistema a causa di una momentanea indisponibilità del server. In Jira tale
funzionalità è presente. Per quanto riguarda la reportistica, Jira mette a disposizione
un’ampia varietà di grafici e dashboard personalizzabili in relazione alle
informazioni che si vogliono visualizzare. Mantis non fornisce supporti grafici
nativamente, occorre anche in questo caso scaricare dei plugin oppure esportare i dati
e realizzare i grafici con altri strumenti.
In conclusione volendo esprimere una preferenza, relativamente a questa “prova” Jira
si è mostrato molto più semplice, flessibile e potente di Mantis il quale però al tempo
stesso, in ottica open source è sicuramente uno strumento completo e versatile.
96
Capitolo 3. Progettazione di uno strumento di defect analysis
Dopo essere venuti a conoscenza delle tecniche di analisi dei difetti valutandone per
ognuna di esse vantaggi e svantaggi (capitolo 1), sono stati presentati alcuni
strumenti per la gestione e analisi dei difetti (capitolo 2). Lo scouting proposto nel
capitolo 2 ci ha permesso di venire a conoscenza delle funzionalità alla base dei
sistemi di issue/bug tracking per poterne cogliere gli aspetti fondamentali e cercare di
identificare funzionalità che potrebbero essere aggiunte e/o migliorate. Questa fase è
servita per gettare le fondamenta su cui costruire la struttura del lavoro alla base di
questa tesi: la realizzazione di un tool web-based per l’analisi dei difetti nei sistemi
Selex.
In particolare questo lavoro si concentra sulla realizzazione di un cruscotto
(dashboard) di analisi per la valutazione dei processi software fattibili a partire dai
difetti e dai corrispondenti campi. Concretamente, il processo definito è basato sul
“supporto alle decisioni” per i manager/ingegneri che lavorano ad un alto livello di
astrazione, in cui ogni analisi va inquadrata sotto i tre fattori alla base dell’Iron
Triangle: qualità, costo e tempo. La realizzazione di questo strumento ha l’obiettivo
di contribuire al miglioramento di uno dei tre fattori o il trade-off tra di essi e
fornire le giuste informazioni in relazione alla tipologia di utente utilizzatore.
Tra le motivazioni cardini che hanno fatto emergere l’esigenza di progettare un tool
per la gestione dei difetti, si può sicuramente annoverare la diversità che ne
caratterizza la registrazione e dunque la gestione all’interno di una stessa azienda e/o
97
tra i diversi reparti che la compongono. Infatti i difetti potrebbero provenire da
sorgenti differenti e trattati con tool diversi (per motivi collegati alle conoscenze del
personale o perché l’azienda non ha dato indicazioni specifiche a riguardo). Questo
potrebbe causare l’insorgere di problematiche di comunicazione tra i tools adottati e
scarsa generalità sullo schema di classificazione utilizzato. Per questo motivo e
soprattutto per far fronte a problemi di eterogeneità dovuta agli strumenti software
usati, si è scelto di implementare questo tool basato su un’unica classificazione dei
difetti, che può essere utilizzato dai diversi comparti aziendali permettendo di
superare gli oneri legati alla realizzazione dell’interoperabilità di soluzioni differenti.
Sulla base di questa classificazione, verranno realizzate la maggior parte delle
funzionalità di reportistica che saranno utilizzate a supporto del processo di
valutazione delle attività di Implementation, Fixing e Detection che caratterizzano lo
sviluppo dei sistemi che stiamo considerando.
L’analisi supportata dal tool è rivolta ai componenti e non hai progetti, cosa che fino
ad ora non è stata considerata nello scenario del caso di studio. Dato che lo sviluppo
di ognuno di essi è indipendente sino al processo di integrazione, si può considerare
questa diversità un punto di forza dello studio, nato con l’obiettivo di mettere in luce
le differenze tra le istanze dei processi di testing dei singoli componenti realizzati da
differenti suppliers, evitando così di polarizzare i risultati delle analisi al particolare
sistema considerato.
98
3.1 Requisiti
Vengono di seguito riportati i requisiti alla base del tool che è stato realizzato.
1. Il sistema deve permettere l’accesso grazie ad un apposito form di login-in.
2. Il sistema deve essere organizzato in tre sezioni: KPIs, Implementation e
Prediction.
3. La sezione KPIs deve fornire gli appositi form per il calcolo della diversa tipologia
di KPI considerata e salvarne il risultato, dopo il calcolo, sul database.
4. La sezione Implentation deve essere articolata in diverse sottosezioni: Assess
Product Quality, Evaluate Testing Process, Plan Releases, Assess Debugging
Process e Testing Realese.
5. Il sistema deve prevedere la possibilità di aggiungere un nuovo progetto da
interfaccia utente.
6. Il sistema deve riportare il numero totale dei difetti presenti (aperti e chiusi).
7. Il sistema deve fornire report globali (grafici interattivi e tabelle) sulle issues in
relazione ai diversi attributi previsti per la classificazione: Priority, Severity,
Reproducibility, Status, Resolution. Si dovrà riportare il numero relativo al valore di
ogni attributo di classificazione e il totale.
8. Il sistema deve disporre di una funzionalità che permette di visualizzare tutti i
dettagli relativi alle issues (su tutti i componenti presenti nella base dati) e
permetterne l’esportazione in formato. xls e .csv.
9. Il sistema deve fornire report per componente (grafici interattivi e tabelle) sulle
issues in relazione ai diversi attributi previsti per la classificazione: Priority,
Severity, Reproducibility, Status, Resolution. Si dovrà riportare il numero relativo al
valore di ogni attributo di classificazione e il totale.
10. Il sistema deve disporre di una funzionalità che permette di visualizzare tutti i
dettagli relativi alle issues di un singolo componente e permetterne l’export in
formato. xls e .csv.
99
11. Il sistema deve disporre di funzionalità per effettuare un confronto dei
componenti presenti, in relazione a un determinato attributo di classificazione.
Il report ottenuto dovrà comporsi di una tabella riassuntiva e di un grafico
interattivo (column chart multiplo) che rifletta il confronto tra i diversi componenti.
La tabella deve essere esportabile.
12. Il sistema deve offrire la possibilità di valutare il fixing dei difetti grazie alla
costruzione di grafici che mettano in relazione il numero di difetti aperti rispetto a
quelli chiusi.
13. Per il requisito 12 è prevista un’ analisi a diversi livelli di granularità divisi per
tempo e componenti. Il tempo considerato può essere: giorno, settimana, mese e
anno. Per quanto riguarda i componenti si può decidere di condurre l’analisi in due
modi: considerando il singolo componente o tutti i componenti.
3.2 Descrizione
Per quanto concerne gli aspetti progettuali, si è deciso di realizzare il tool di natura
web based, scelta motivata da una molteplicità di ragioni. Motivo principale che ha
indirizzato il lavoro verso questa scelta è stata la conoscenza acquisita grazie alla
fase di scouting attraverso la quale è stato possibile apprendere che quasi tutti i tool
di DM oggi presenti sul mercato sono di natura Web-based. Altre motivazioni che
spingono verso l’adozione di una soluzione di questo genere, sono racchiuse nei
tangibili vantaggi che essa offre. Tra questi è possibile annoverare:
 Compatibilità cross-platform. Le applicazioni Web-based hanno una maggiore
compatibilità delle applicazioni software scaricabili.
 Semplicità di aggiornamento.
 Elevata fruibilità d’accesso. Non occorre scaricare, installare e configurare
software ma sarà sufficiente registrarsi e inseguito loggarsi per poter accedere
all’applicazione.
100
 Meno requisiti di memoria. Per la loro natura client-server hanno requisiti meno
esigenti in termini di memoria Ram (in riferimento alla parte client), questo
perché il carico elaborativo risiede sul server.
 Accesso multi-user. Permetto l’utilizzo a più utenti in concorrenza.
 Libertà di lavoro. Non vincolano a svolgere il lavoro da una determinata
postazione, offrendo quindi una maggiore flessibilità in termini di mobilità.
 Scalabilità. Possono crescere facilmente in relazione alle esigenze dell’azienda.
 Ampie soluzioni di sviluppo. Per realizzare soluzioni web-based esistono una
pletora di linguaggi e framework a supporto degli sviluppatori.
 Riduzione dei costi di gestione. Le applicazioni web-based consentono di
abbattere i costi di gestione aziendali.
3.3 Tecnologie utilizzate
Per quanto riguarda le tecnologie utilizzate per la realizzazione del tool effecT!,
viene riportato in figura 3.1 un quadro riassuntivo contenente sia le tecnologie usate
lato client e sia quelle lato server.
Figura 3.1 Tecnologie usate in effecT!
101
Nella parte alta della pila sono collocate le tecnologie alla base della realizzazione
della parte client del tool chiamato “effecT!”. Sono state realizzate pagine HTML5
alle quali sono state aggiunte aspetti decorativi ed effetti grafici grazie all’utilizzo dei
fogli di stile CSS. L’adozione di questi è resa necessaria per poter separare i
contenuti dalla formattazione e permettere una progettazione più chiara e facile da
utilizzare, sia per gli autori delle pagine HTML che per gli utenti, garantendo
contemporaneamente anche riuso del codice e facile manutenibilità.
Notiamo inoltre la presenza di javascript e jQuery. Quest’ultimo rappresenta una
libreria di funzioni javascript, per applicazioni web, che si propone come obiettivo
quello di semplificare la programmazione lato client delle pagine HTML. E’ un
software liberamente distribuibile e gratuito. E’stato scelto l’utilizzo di jQuery
perché grazie alla sua sintassi ottimizzata, semplifica la navigazione dei documenti,
la selezione degli elementi del DOM, la creazione di animazioni, la gestione di eventi
e l’implementazione di funzionalità AJAX.
La parte centrale della pila mostrata in figura 3.1 rappresenta la nostra logica di
business, ovvero tutta la logica applicativa che rende operativa l’applicazione. In
ambito di progettazione web, l’espressione business logic è spesso associata ad
architetture di tipo three-tier. Viene tipicamente ospitata ed eseguita da un
application server (elaborazione server side) su richiesta del client attraverso il
proprio web-browser, interfacciandosi con la parte dati che in questo caso è
rappresentata da un database MySQL.
Sempre nella parte centrale della pila, notiamo la presenza della sigla RESTful API,
JAX-RS API e RestEasy.
Perché si è scelto l’approccio RESTful e non Soap?
RESTful è un architettura basata sul protocollo HTTP introdotta per la prima volta
nel 2000 da Roy Fielding nella sua tesi: “Architectural Styles and the Design of
Network-based Software Architecture” ([30]). In questa tesi si analizzavano alcuni
principi alla base di diverse architetture software, tra cui quelli di un’architettura
102
software che consentisse di vedere il Web come una piattaforma per l’elaborazione
distribuita. È bene precisare che i principi REST non sono necessariamente legati al
Web, nel senso che si tratta di principi astratti di cui il World Wide Web ne risulta
essere un esempio concreto. All’epoca questa visione del Web passò un pò in
sordina, ma negli ultimi anni l’approccio REST è venuto alla ribalta come metodo
per la realizzazione di Web Services altamente efficienti e scalabili ed ha al suo
attivo un significativo numero di applicazioni. Il motivo è semplice: dal momento
che il Web ha tutto quello che serve per essere considerata una piattaforma di
elaborazione distribuita secondo i principi REST, non sono necessarie altre
sovrastrutture per realizzare quello che è il Web programmabile .
Come detto in precedenza, REST non è un’architettura nè uno standard, ma un
insieme di linee guida per la realizzazione di un’architettura di sistema. Ma
quali sono questi principi che rendono il Web adatto a realizzare Web Service
secondo l’approccio REST? Il tutto può essere riassunto nei seguenti cinque
principi:
 Identificazione delle risorse. Le risorse sono gli elementi su cui si basano i
Web Service RESTful, a differenza dei Web Service SOAP-oriented che sono
basati sul concetto di chiamata remota. Per risorsa si intende un qualsiasi
elemento oggetto di elaborazione. Il principio che stiamo analizzando
stabilisce che ciascuna risorsa deve essere identificata univocamente. Essendo
in ambito Web, il meccanismo più naturale per individuare una risorsa è dato
dal concetto di URI.
 Utilizzo esplicito dei metodi http. Una volta spiegato come individuare una
risorsa si avverte la necessità di un meccanismo per indicare quali operazioni
effettuare su di esse. Il principio dell’uso esplicito dei metodi HTTP ci indica
di sfruttare i metodi (o verbi) predefiniti di questo protocollo, e cioè GET,
POST, PUT e DELETE. Questo rende uniforme l’invocazione di operazioni
sulle risorse, cioè il client non ha bisogno di sapere qual è la specifica
103
interfaccia da utilizzare per invocare il metodo che consente di ottenere la
rappresentazione di un cliente. In un contesto non RESTful potremmo avere
metodi come ad es. “getCliente()” o altra specifica dipendente dalle scelte di
chi ha sviluppato il Web Service. In un contesto RESTful sappiamo già a
priori come ottenere la rappresentazione di una risorsa. In altre parole, questo
principio REST stabilisce una mappatura uno a uno tra le tipiche operazioni
CRUD (creazione, lettura, aggiornamento, eliminazione di una risorsa)
mostrata in tabella 3.1 e i metodi HTTP. È opportuno notare che questo
principio è in contrasto con quella che è la tendenza generale nell’utilizzo dei
metodi HTTP.
Infatti, molto spesso viene utilizzato il metodo GET per
eseguire qualsiasi tipo di interazione con il server. Ad esempio, spesso per
Tabella 3. 1 Mapping operazioni CRUD - HTTP
l’inserimento di una nuova risorsa (per esempio un nuovo progetto o utente
ecc.) nell’ambito di un‘applicazione Web viene usato il metodo GET su un
URI. Questo approccio non è conforme ai principi REST perché il metodo
GET serve per accedere alla rappresentazione di una risorsa e non per crearne
una nuova. In pratica questo uso del metodo GET introduce un effetto
collaterale che, tra l’altro, può avere delle conseguenze indesiderate se, ad
esempio, l’URI viene invocato più volte o se la risorsa viene memorizzata in
uno dei vari livelli di cache esistenti tra client e server. Come principio
generale, nel progettare un Web Service in modalità REST è utile evitare l’uso
di verbi negli URI ma limitarsi ad utilizzare nomi, ricordandosi che un URI
104
identifica una risorsa. Allo stesso modo è opportuno sottolineare che il corpo
di una richiesta HTTP con metodi PUT e POST è pensato per il trasferimento
della rappresentazione di una risorsa e non per eseguire chiamate remote o
altre attività simili.
 Risorse autodescrittive. I principi REST non pongono nessun vincolo sulle
modalità di rappresentazione di una risorsa. Virtualmente è possibile utilizzare
il formato che più si preferisce obblighi verso uno standard. Di fatto, però, è
opportuno utilizzare formati il più possibile standard in modo da semplificare
l’interazione
con
i
client.
Inoltre,
sarebbe
opportuno
prevedere
rappresentazioni multiple di una risorsa, per soddisfare client di tipo diverso. Il
tipo di rappresentazione inviata dal Web Service al client è indicato nella
stessa risposta HTTP tramite un tipo MIME, così come avviene nella classica
comunicazione tra Web server e browser. Un client a sua volta ha la possibilità
di richiedere una risorsa in uno specifico formato sfruttando l’attributo Accept
di una richiesta HTTP di tipo GET. La possibilità di rappresentazioni multiple
produce alcuni benefici pratici: ad esempio, se abbiamo un output sia HTML,
sia XML, possiamo consumare il servizio sia con un’applicazione sia con un
comune browser. In altre parole, seguendo i principi REST nel progettare
un’applicazione Web è possibile costruire sia una Web API che una Web UI .
 Collegamenti tra risorse. Un altro vincolo dei principi REST consiste nella
necessità che le risorse siano tra loro messe in relazione tramite link
ipertestuali. Questo principio è anche noto come HATEOAS e pone l’accento
sulle modalità di gestione dello stato dell’applicazione. In sostanza, tutto
quello che un client deve sapere su una risorsa e sulle risorse ad essa correlate
deve essere contenuto nella sua rappresentazione o deve essere accessibile
tramite collegamenti ipertestuali. In questo modo il client può accedere alle
risorse correlate seguendo semplicemente i collegamenti contenuti nella
rappresentazione della risorsa corrente.
105
 Comunicazione senza stato. Il principio della comunicazione stateless è ben
noto a chi lavora con il Web. Questa è infatti una delle caratteristiche
principali del protocollo HTTP, cioè ciascuna richiesta non ha alcuna
relazione con le richieste precedenti e successive. Lo stesso principio si
applica ad un Web Service RESTful, cioè le interazioni tra client e server
devono essere senza stato. È importante sottolineare che sebbene REST
preveda la comunicazione stateless, non vuol dire che un’applicazione non
deve avere stato. La responsabilità della gestione dello stato dell’applicazione
non deve essere conferita al server, ma rientra nei compiti del client. La
principale ragione di questa scelta è la scalabilità: mantenere lo stato di una
sessione ha un costo in termini di risorse sul server e all’aumentare del numero
di client tale costo può diventare insostenibile. Inoltre, con una comunicazione
senza stato è possibile creare cluster di server che possono rispondere ai client
senza vincoli sulla sessione corrente, ottimizzando le prestazioni globali
dell’applicazione.
JAX-RS
Java definisce il supporto REST tramite Java Specification Request (JSR) 311.
Questa specifica si chiama JAX-RS (l’API Java per RESTful Web Services). JAXRS utilizza le annotazioni per definire la rilevanza REST di classi Java. Jersey è
l’implementazione di riferimento per la specifica JSR 311. L’implementazione
Jersey fornisce una libreria per implementare Web Services in un contenitore di
servlet Java. Sul lato server Jersey fornisce un’implementazione servlet che analizza
classi predefinite per identificare le risorse RESTful e un’implementazione che
fornisce una libreria client per comunicare con un web service RESTful.
Un’applicazione web REST consiste, dunque, di classi di dati (risorse) e servizi.
Questi due tipi sono in genere mantenute in diversi package e il servlet Jersey verrà
106
istruito attraverso il web.xml per analizzare alcuni pacchetti per determinate classi di
dati.
JAX-RS notazioni
Vengono riportate in tabella 3.2 le annotazioni fondamentali, corredate dalla relativa
descrizione, che sono state utilizzate per la creazione delle Web-Services utilizzate
nel tool effecT!
Tabella 3. 2 JAX-RS Annotation
Il percorso completo di una risorsa è basata sulla URL di base e “l’annotation @”
percorso della classe a cui si riferisce, come mostrato in figura 3.2.
Figura 3.2 Esempio path completo risorsa
L’ultimo livello della pila rappresentata in figura 3.1 si riferisce al back-end
rappresentato da un database Mysql e da un middleware Hibernate che rappresenta lo
107
strato collante tra il database e la business logic. Il database non è stato progettato in
questo lavoro di tesi, ma è stato ereditato da un altro lavoro precedente.
Una sua rappresentazione ER è riportata, per motivi di spazio, alla fine del capitolo.
Hibernate
E’ bene spendere qualche parola su questo middleware che rientra nelle tecnologie
utilizzate in questo lavoro. Hibernate è stato originariamente sviluppato da un team
internazionale di programmatori volontari coordinati da Gavin King; in seguito il
progetto è stato proseguito sotto l’egida di Jboss, che ne ha curato la
standardizzazione rispetto alle specifiche Java EE ([31]). E’ un software free, opensource distribuito sotto licenza GNU. Oggi è arrivato alla versione 4.0.1. Hibernate
fornisce un servizio di Object-relational mapping (ORM) ovvero gestisce
la persistenza dei dati sul database attraverso la rappresentazione e il mantenimento
su database relazionale di un sistema di oggetti Java. Nell’ambito dello sviluppo
di applicazioni web tale strato software si frappone tra il livello logico di business o
di elaborazione e quello di persistenza dei dati sul database (Data Access Layer). Il
mapping (tra tabelle e classi Java) offerto si traduce in una maggiore semplicità di
interrogare la basi di dati. Esso viene specificato in appositi file XML. In linea di
principio, lo sviluppatore è esonerato da:
 richieste di esecuzione di chiamate SQL
 gestione manuale dei risultati di chiamate SQL e loro eventuale conversione in
oggetti
Il codice dell’applicazione usa le API di Hibernate per gestire la persistenza e
l’applicazione rimane portabile garantendo pochissimo overhead.
L’utilizzo tipico che si fa di Hibernate è noto come “Meet in the Middle” in cui si
dispone di una base dati esistente e rappresenta anche la modalità in cui è stato usato
in questo lavoro di tesi. Fare una trattazione completa di Hibernate sarebbe oneroso e
108
soprattutto esula dallo scopo di questo lavoro, pertanto verrà brevemente presentato
solo il meccanismo di gestione della persistenza.
Hibernate - Gestione della persistenza
I principali elementi di un’applicazione che fa uso di Hibernate per la gestione della
persistenza sono: le classi di dominio realizzate in Java, una base di dati, un file che
definisce il mapping di ogni classe persistente, file di configurazione di Hibernate e
le interfacce per l’accesso alla base di dati (Session, Transaction e Query
appartenenti al package “org.hibernate”).
Le classi di dominio vengono definite come in qualsiasi applicazione Java e
tipicamente consistono in metodi Get e Set per l’accesso in lettura e scrittura delle
proprietà degli oggetti della classe.
La base di dati formata da tabelle è mantenuta all’interno di un certo DBMS nel
nostro caso mySQL provvista del proprio driver jdbc.
Nel file di mapping per le classi persistenti (in formato XML) viene definita la
corrispondenza tra le proprietà delle classi persistenti sulle tabelle della base di dati.
Deve soddisfare la grammatica specificata all’interno di un apposito DTD (es. in
figura 3.3) chiamato hibernate-mappping-3.0.dtd.
Figura 3.3 Esempio DTD Hibernate
L’operazione di mapping è stata eseguita automaticamente dall’IDE utilizzato, in
questo caso è Netbeans, indicando semplicemente i package che contengono i model
ovvero le tabelle del nostro database rappresentate in classi Java.
109
Il file per la gestione della configurazione di Hibernate costituisce la parte
dell’applicazione che gestisce la persistenza, ovvero la parte che si connette alla base
di dati e ha bisogno di avere le informazioni necessarie ad effettuare la connessione,
quali il DBMS, il driver JDBC, la base di dati, utente/password ecc. Tutte queste
informazioni sono anche esse contenute in un file XML.
Le interfacce Hibernate rappresentano tre mezzi per l’accesso alla base di dati, tutte
appartenenti al package org.hibernate. Esse sono le seguenti:
Session. Ogni istanza rappresenta una sessione di comunicazione tra applicazione e
base di dati quindi comprende i metodi per salvare/caricare oggetti nella/dalla base di
dati.
Transaction. Ogni istanza rappresenta una transazione così da conferire un maggiore
disaccoppiamento dell’applicazione: non è necessario usare l’API JDBC per
impostare una transazione. Gioca al ruolo di gestore di transazioni in un sistema
che accede a più basi di dati all’interno di un’unica unità di lavoro di sistema.
Query. Interfaccia che permette di creare ed eseguire query, sia nel linguaggio di
query di Hibernate (HQL) che in SQL.
Per quanto riguarda l’ambiente di sviluppo è stato scelto Netbeans, mentre come
application server GlassFish.
Tutti i grafici presenti nel tool sono stati realizzati utilizzando le Google Chart API.
3.4 Database utilizzato
Viene mostrato in figura 3.4 lo schema relativo al database utilizzato in effecT! e
segue una breve descrizione delle principali tabelle che lo caratterizzano.
110
Figura 3.4 Database effecT!
111
Tabelle principali:
 Analysis. Contiene informazioni relative alle analisi svolte (label, data di
inizio e fine) e del progetto a cui si riferiscono.
 Issue. E’ la tabella che contiene tutte le informazioni necessarie alla
caratterizzazione delle issues. Questa tabella rappresenta il nostro schema di
classificazione.
 Projects. Contiene le informazioni per memorizzare eventuali nuovi progetti.
 Component. Informazioni relative al componente. Serve per poter creare
progetti formati da uno o più componenti.

ODC data e ODC attributes. Tabelle per il supporto allo schema di
classificazione di ODC.
 V&VTecnique. Contiene informazioni relative ad eventuali tecniche di testing
memorizzate nel sistema.
 Project Metric. Tiene traccia delle metriche di prodotto associate ad un
componente.
 CSV_Admitted_Values. Contiene le informazioni relative ai valori che
possono assumere eventuali bug, importati da altre sorgenti.
 Custom_field. Tabella che consente l’eventuale aggiunta di campi
personalizzati da parte dell’utente per la caratterizzazione delle issues.
 Phase_info. Grazie a questa tabella possiamo ottenere delle informazioni
relative alla fase in cui una determinata issue si trova. I possibili stati sono:
detection, injection, fixing e showdet_phase.
Sono presenti tabelle che consentono di gestire le diverse tipologie di utenti, i
rispettivi profili ed i permessi a loro associati. Sono state predisposte delle tabelle per
consentire all’utente di aggiungere campi personalizzati al momento della
sottomissione di una nuova issue e tabelle che permettano di gestire eventuali gruppi
112
di utenti. Infine sono presenti delle tabelle che permettono di tenere traccia delle
differenti modalità di riproducibilità dei bug.
Viene di seguito mostrato come è stato fatto il mapping dei campi fondamentali per
la caratterizzazione delle issues, considerando per esempio due sistemi di bug/issue
tracking presenti nello scouting: Mantis e Jira. Vengono a tal fine riportate le tre
tabelle relative alle issue così da poter spiegare le corrispondenze.
Figura 3.5 Tabella issue effecT!
113
Figura 3.6 Mantis_bug_table e Jiraissue table
114
Dalle tabelle riportate si evince che i campi della tabella Issue del database effecT!
consentono di mappare difetti importati da altre sorgenti come ad esempio Mantis e
Jira sul nostro schema di classificazione. Infatti sono stati predisposti campi per
mappare il progetto (nel nostro lavoro è unico), l’id del componente e gli attributi
indispensabili per la classificazione: priority, status, severity, reproducibility, data di
detection, data di fixing e Id (associata alla issue). Questo perché tra i requisiti alla
base del tool vi è la necessità di evitare problematiche di interoperabilità che
potrebbero essere originate dalla gestione dei difetti con schemi di classificazioni
differenti.
Inoltre, come è stato precedentemente introdotto nella descrizione delle tabelle
principali, è stata prevista la possibilità di aggiungere campi personalizzati alle issue
al momento della sottomissione nel sistema, grazie alle tabelle custom field, cosa che
permette una gestione molto simile a quella di Jira e di Mantis.
115
Capitolo 4. Esempi di utilizzo
4.1 Dataset utilizzato
L’unità dell’analisi di questo caso di studio è composta dai difetti software rilevati
dai team di V&V in sede di qualification testing dei CSCI, che precede il processo di
integrazione. Ai fini della conduzione dello studio non è stato ritenuto necessario che
i componenti facciano parte dello stesso sistema, dato che lo sviluppo di ognuno di
essi è indipendente sino al processo di integrazione, che non viene considerato da
questo studio. Questa diversità è da ritenersi un punto di forza dello studio, nato con
l’obiettivo di mettere in luce le differenze tra le istanze dei processi di testing dei
singoli componenti realizzati da differenti suppliers, evitando così di polarizzare i
risultati delle analisi al particolare sistema considerato. All’epoca del prelievo della
base dati del sistema di bug-tracking dell’azienda, sono stati ritenuti idonei e
selezionati sei componenti, con un periodo di segnalazione delle anomalie che va tra
l’ottobre del 2009 e l’agosto del 2012, scartando CSCI che non implementassero
requisiti di sistema. Cinque dei sei componenti considerati nello studio sono
impiegati in sistemi critici di homeland-security che si occupano principalmente di
sorveglianza marittima, portuale e costiera. L’altro componente dei sei ha il compito
di presentare agli utenti contenuti informativi nell’ambito di sistemi a supporto della
situational-awareness in campo militare. Per ragioni di confidenzialità non è stato
possibile riportare né il nome effettivo dei componenti né il particolare sistema o
sistemi di cui fanno o faranno parte. Da questo punto un eventuale riferimento ad essi
116
avverrà con gli acronimi: C1, C2, …, C6. Il risultato ottenuto è un insieme di 1296
difetti aperti di cui 950 sono stati chiusi. Nel dataset sono state considerate tutte le
issues ad eccezione di quelle segnate come duplicate e quelle per cui sono richieste
nuove funzionalità.
4.2 Scenari di utilizzo
Analizziamo le funzionalità del tool effecT! con delle screen-capture di utilizzo
concreto. Nella figura 4.1 viene mostrata la schermata iniziale del tool, la quale è
preceduta da un form di login, grazie alla quale è possibile scegliere quale sezione
del tool esplorare. In questo caso sono previste tre sezioni: KPIs, Implementation e
Prediction. Di queste tre, la sezione Prediction non è al momento disponibile.
Figura 4.1 Form Login e sezioni effecT!
117
4.2.1 Panoramica Generale
Sezione KPIs (Key Performance Indicators)
La misura della produttività del software è ottenuta dalla comprensione della
definizione di cinque fasi specifiche indicate appunto con la sigla KPIs.
Sono
previste KPIs per le fasi di: Requirement Analysis, Design, Implementation,
Verification e Maintenance ([32]). Le KPIs devono essere calcolate solo alla fine
della fase a cui sono collegate (per esempio il KPI collegato alla Requirement
Analysis verrà calcolato una sola volta al termine di questa fase). Non devono essere
calcolate periodicamente durante ogni fase. Solo le KPIs relative alla fase di
Maintenance devono essere calcolate mensilmente e i parametri coinvolti nel loro
calcolo sono il numero di SPRs risolte e il numero di ore spese per la risoluzione. In
figura 4.2 viene riportato uno screen-capture relativo alla sezione KPIs.
Figura 4.2 Sezione KPIs
118
Dal drop-down menu è possibile selezionare il tipo di KPIs da valutare e dopo la
selezione comparirà il relativo form. Una volta calcolato, il risultato, sarà salvato nel
database. In figura 4.3 viene mostrato un form, relativo alle Requirements Analysis
KPIs.
Figura 4.3 Requirements Analysis KPIs
Nella barra superiore è presente una funzionalità che sarà oggetto di una successiva
implementazione: l’importazione di un file csv. Gli altri form non vengono mostrati
perché sono simili, cambiano solo i parametri che caratterizzano la KPI.
Per una migliore navigabilità, è stato inserito un link nella barra superiore, denotato
con “Home” che permette di ritornare alle sezioni del tool illustrate in figura 4.1 per
poter selezionare un altro tipo di analisi da condurre.
Sezione Implementation
119
Questa sezione rappresenta la parte principale del tool. Infatti, attraverso di essa è
possibile ottenere le informazioni sintetiche che portano
contributo tangibile al
processo decisionale. In figura 4.4 viene la sezione Implementation di effecT!
Figura 4.4 Sezione Implentation effecT!
Nella parte alta del tool troviamo un menu, attraverso cui è possibile accedere a tutte
le funzionalità che esso offre. Nella parte sinistra è presente una barra di ricerca, per
ricercare componenti e/o progetti (nel caso di studio non sono stati considerati
progetti differenti, dunque questo è una predisposizione per future implementazioni).
Il link Global View collocato al di sotto della barra di ricerca offre la possibilità di
ottenere tutte le informazioni presenti nel database e la possibilità di esportarle in
120
forma di tabelle Excel o in formato .CSV (figura 4.5 e 4.6). Questa è uno dei requisiti
funzionali molto importante perché gli utenti utilizzatori devono poter essere in
condizioni di esportare ed usare i dati, per altre analisi o per poterci lavorare su un
foglio di calcolo.
Figura 4.5 Global View
In figura viene mostrato un estratto del report ottenuto grazie alla funzionalità
associata al link Global View. Nella parte bassa viene mostrato il download del file
.xls associato alla tabella rappresentata in figura. Un parte del file .xls ottenuto viene
mostrato in figura 4.6 e in figura 4.7 viene mostrato il download questa volta però in
formato .CSV.
Figura 4.6 Global View file .xls
121
Figura 4.7 Global View file .csv
Il pulsante Add Project permette la visualizzazione di un pop-up figura 4.8 attraverso
il quale sarà possibile effettuare l’inserimento di un nuovo progetto.
Figura 4.8 Nuovo progetto
122
4.2.2 Issues Report
La prima vista che analizziamo è la Issues Report (figura 4.9) accessibile grazie al
menu presente in testa alla pagina principale del tool. Questa vista permette di
valutare le issues in relazione alle loro caratteristiche: Priority, Severity,
Reprodubility, Status e Resolution. Queste valutazioni sono in questo caso globali,
ovvero si riferiscono a tutto il dataset considerato e prevedono la caratterizzazione in
relazione ai differenti valori che ogni singolo attributo può assumere (es. l’ attributo
Priority prevede valori che possono essere: immediate, urgent, normal, high, low,
none ). Infine è presente nel menu una vista denotata All Issues a cui è associata la
stessa funzionalità espletata da Global View.
Figura 4.9 Issues Report
Severity
La prima classificazione sfrutta l’attributo Severity. Questa riporta le percentuali dei
livelli di Severity che sono stati associati dai team di V&V alle anomalie. In questo
caso i possibili valori che l’attributo di classificazione può assumere vengono
rappresentati in figura 4.10. La Severity, indica,con il suo valore, l’impatto che il bug
123
avrà sul sistema. Questo fa intuire che issues con severity Major saranno oggetto di
processi di risoluzione accurati e prioritari rispetto agli altri. Nella figura viene
inoltre mostrato un Pie chart che riflette la distribuzione delle issues in relazione
all’attributo considerato. Non vengono mostrate le percentuali, poiché essendo il
grafico interattivo sarà sufficiente selezionare lo “spicchio” di torta di interesse per
mostrare numero e relativa percentuale (come in figura per il valore Major).
Figura 4.10 Distribuzione livelli di Severity di tutti i componenti
Priority
La seconda classificazione sfrutta l’attributo Priority. Questa riporta le percentuali
dei livelli di Priority con i quali i team di V&V hanno classificato i vari bug. In
figura 4.11 viene riportato il Pie chart della distribuzione, i valori che può assumere
124
l’attributo Priority e le relative percentuali. La priorità è una proprietà che è
direttamente condizionata dalla Severity (si associa una maggiore priorità ad una
issue in relazione alla gravità della severity). Entrambe condizionano il processo di
fixing e in particolare influenzano il Time To Fix dei difetti.
Figura 4.11 Distribuzione livelli di priority di tutti i componenti
Reproducibility
La terza classificazione
sfrutta l’attributo Reproducibility. Questa riporta le
percentuali dei livelli di riproducibilità con i quali i team di V&V hanno classificato i
vari bug. La riproducibilità è una caratteristica molto importante poiché ad essa si
può collegare la natura del bug. Essa fornisce informazioni preziose per il testing e
dipende dall’esperienza dei tester, poiché bug non classificabili non sono pienamente
125
gestibili dal processo. In figura 4.12 viene riportato il Pie chart della distribuzione, i
valori che può assumere l’attributo Reproducibility e le relative percentuali.
Status
La quarta classificazione
sfrutta l’attributo Status. Questo attributo permette di
capire in che stato si trova la issues, in relazione al possibile workflow stabilito dal
team di V&V. I risultati sono mostrati in figura 4.13
Figura 4.12 Distribuzione livelli di reproducibility di tutti i componenti
Resolution
La quinta ed ultima classificazione viene sulla base dell’attributo Resolution. Questo
attributo permette di valutare l’evoluzione del processo di fixing sulle issues.
In figura 4.13 vengono mostrati i risultati ottenuti.
126
Tutte queste informazioni, globali, permettono di ottenere rapidamente una
conoscenza generale delle issues presenti nei nostri componenti. In particolare
attraverso queste prime informazioni possiamo avere un resoconto su quanti difetti
hanno per esempio una priorità urgente di risoluzione, oppure quanti di essi sono
caratterizzati da una severità di tipo Major, così da poter avere una prima valutazione
dello sforzo richiesto dai componenti in esame e poter predisporre i piani di test
dimensionando opportunamente il quantitativo di risorse per il suo svolgimento.
Figura 4.13 Distribuzione livelli di status di tutti i componenti
127
Figura 4.14 Distribuzione livelli di resolution di tutti i componenti
4.2.3 Component Level View
Il tool realizzato permette di eseguire le analisi globali riportate nel sotto-paragrafo
4.2.2 anche a livello di singolo componente. Questo permette di analizzare le
caratteristiche individuali per poter capire, ad esempio, quali sono i componenti che
hanno il più alto numero di difetti urgenti o che sono caratterizzati dal più basso
numero di difetti ecc. In figura 4.15 viene rappresentata un estratto della view
associata a questa funzionalità.
128
Figura 4.15 Component Level View
Dal drop-down menu è possibile scegliere il tipo di analisi da effettuare. E’stata
prevista una funzionalità che permette di visualizzare tutti i dettagli sulle issues
relativi al solo componente oggetto dell’analisi (rappresenta un restrizione del
risultato ottenuto con Global View) con la possibilità di esportare sia in formato .xls,
che in formato .csv. In figura 4.16 viene riportata un sola analisi relativa al
componente N°1, dal momento che le altre sono uguali dal punto di vista funzionale
a meno di differenze di dati.
129
Figura 4.16 Component1-Issues For Resolution
4.2.4 Component Summary Issues
Questa vista, accessibile anch’essa dal menu presente in testa alla pagina principale
del tool, permette di
confrontare i componenti presenti nel nostro dataset in
relazione ai vari attributi di classificazione. Questo rappresenta una funzionalità
molto importante ai fini del processo decisionale, in quanto si riesce ad avere un
confronto tangibile (anche in questo caso con tabelle e grafici) dei componenti
considerando un particolare attributo di caratterizzazione. Per il grafico dei risultati è
stato scelto un
column chart, il quale riporta sull’asse delle ascisse i singoli
componenti (indicati con il rispettivo id) e sulle ordinate il numero dei difetti
presenti. Ogni componente avrà tante colonne, quanti sono i valori che può assumere
l’attributo di classificazione considerato. Anche in questo caso il confronto può
essere fatto per Severity, Priority, Reproducibility, Resolution, Status. A queste è
130
stata aggiunta la possibilità di conoscere il numero di difetti per singolo componente.
In figura 4.17 viene riportato il menu associato a questa vista.
Figura 4.17 Summary Component - Menu
Seguono nelle altre figure alcuni esempi di confronti tra i componenti del dataset,
rispetto ai vari attributi. La figura 4.18 riporta un confronto in relazione all’attributo
Reproducibility ed la figura 4.19 un confronto relativo all’attributo di Severity.
Infine viene mostrato in figura 4.20 il confronto dei componenti in relazione al
numero di issues che caratterizza ognuno di essi. L’analisi dei singoli componenti, e
la reportistica di confronto, consentono rifinire il processo di ispezione e determinare
i componenti critici, collegarli alle relative fasi e fare in modo che il loro processo di
gestione sia definito in base alle informazioni rilevate. Questa tipologia di analisi
consente, inoltre, la valutazione del CSCI e del fornitore responsabile del rilascio.
Questo consente alla team di testing/integrazione di chiedere delle revisioni, su una
determinata fase di sviluppo o sull’intero componente.
131
Figura 4.18 Summary Component Reproducibility
Naturalmente la tabella relativa ai risultati può essere esportata in formato .xsl
132
Figura 4.19 Summary Component -Severity
133
Figura 4.20 Summary Component
4.2.5 Assess Debugging Process
Attraverso il menu presente in testa tool, è possibile selezionare diverse viste (figura
4.21) grazie alle quali si possono ottenere informazioni riguardo alla differenti fasi
che formano il processo di gestione dei difetti, le attività legate alla loro risoluzione e
al testing dei componenti d’interesse. Queste informazioni vengono fornite sotto
forma di metriche (definite appositamente per la determinata analisi a cui si
riferiscono) e grafici.
134
Figura 4. 21 Menu Viste
La vista Assess Debugging Process (Figura 4.22) si compone di una tabella in cui
vengono riportate le metriche globali riferite al processo di fixing e di una sezione
formata da due drop-down menu che permetteranno di costruire dei grafici (con
differente granularità) per mettere in relazione il numero di difetti aperti/ chiusi.
Analizziamo le metriche presenti in tabella.
% Closed. Indica la percentuale di difetti che sono stati chiusi rispetto a quelli aperti.
TTfix(µ,med). Indica il tempo medio impiegato per il fixing, considerando valore
medio e mediana.
FixDiff, FixTrend. Il primo parametro viene calcolato come la differenza al tempo t
tra il numero di difetti meno il numero di difetti chiusi. Il secondo indica il numero
di difetti chiusi per unità di tempo. Ci si aspetta che queste metriche siano entrambi
costanti nel tempo, cosa che si tradurrebbe nella vicinanza tra il trend di chiusura e
quello di apertura.
Kurtosis. Indica un allontanamento dalla normalità distributiva, rispetto alla quale si
verifica un maggiore appiattimento o un maggiore allungamento. Alti valori di
Kurtosis sono preferibili perché indicano che la maggior parte della varianza è data
da pochi picchi. Questi sono preferibili nella parte sinistra della distribuzione.
135
Skew. Valori positivi sono preferibili e indicano una distribuzione right-tailed.
Infine per un’analisi a grana fine sono presenti i parametri TTFix definiti per classe
di priorità, severità e riproducibilità (funzionalità oggetto di future implementazioni).
Figura 4.22 Assess Debugging Process
Grazie ai due drop-down menu è possibile selezionare il tipo di granularità (giorno,
settimane, mese, anno) che rappresenterà l’asse delle ascisse del grafico che
costruiremo per mettere in relazione il numero di difetti chiusi rispetto a quelli aperti.
Sarà possibile costruire tale grafico sia per singolo componente e sia per tutti i
componenti del sistema in modo tale da avere una visione sia globale che singolare.
Nelle figura che seguono vengono riportati degli screen-capture relativi ai grafici
globali (per tutti i componenti e per tutti i livelli di granularità) e quelli relativi ad un
singolo componente (è stato scelto C1) per mostrare le funzionalità a livello di
singolo componente. L’andamento delle curve di apertura e chiusura dei difetti,
permette di ottenere informazioni sull’efficienza del processo di testing; il processo è
efficiente se l’andamento della curva dei difetti chiusi segue quanto più è possibile
quello della curva dei difetti aperti (la differenza tra le curve fornisce il numero di
difetti non risolti). I grafici, infine, possono presentare situazioni in cui le curve
136
raggiungono livelli di stabilità, questo è dovuto al fatto che alcuni difetti non sono
stati risolti nell’intervallo di tempo considerato dal nostro dataset.
Figura 4.23 Day - All component
Figura 4.24 Week - All component
137
Figura 4.25 Month - All component
Figura 4.26 Year - All component
138
Figura 4.27 Day - component1
Figura 4.28 Week - component1
139
Figura 4.29 Month - component1
Figura 4.30 Year - component1
140
4.2.6 Assess Product Quality
Questa è la vista contenente le metriche di base (quali numero di difetti, difetti
residui e difetti stimati, numero di difetti caratterizzati per priorità, severità,
riproducibilità, stato e risoluzione) a cui si aggiungono due metriche di
implementazione (densità attesa dei difetti, e numero di difetti aperti e chiusi).
Queste informazioni sono globali, ovvero riferite a tutto il data set. Nella stessa vista
è presente un collegamento alla component-level view per poter effettuare le analisi
sui singoli componenti. Le tabelle presenti sono esportabili sia in formato “.csv” che
in “.xls”. Questa è stata scelta come prima vista da mostrare appena viene selezionata
la sezione implementation del tool “effecT!” (figura 4.31). Ad alcune metriche
compare nella colonna relativa al valore la sigla “Not Available” questo perché
dovranno essere ricavate da future estensioni del tool.
Figura 4.31 Assess Product Quality
141
Conclusioni e sviluppi futuri
Il lavoro svolto in questa attività di tesi ha permesso di studiare la valutazione del
processo software, attraverso l’analisi dei difetti e la realizzazione di uno strumento
di supporto, nel contesto aziendale di un grande “sistem integrator”. La procedura
applicata per l’analisi dei difetti è stata concepita per ridurre al minimo la possibilità
di aggiungere costi esosi e ispezioni intrusive, finalizzate ad evitare di stravolgere il
processo in corso.
I risultati ottenuti forniscono una serie di approfondimenti sull’efficienza del
processo di sviluppo e su ciascun componente monitorato. Da ciò deriva una
valutazione più accurata delle fasi critiche, l’identificazione dei componenti più
difettosi e/o dei componenti critici, permettendo
la valutazione dei fornitori
responsabili di un determinato componente.
Questi risultati sono di supporto a professionisti, quali manager ed ingegneri, che
occupandosi di sistemi di grandi e/o medie dimensioni, sviluppati secondo un
approccio a componenti, lavorano ad alti livelli di astrazione e necessitano di
informazioni sintetiche da utilizzare nel processo decisionale per ottenere un tradeoff dei tre parametri costo, qualità e tempo o ottimizzarne uno di essi.
Le metriche raccolte e le informazioni fornite dal tool (classificazione per Severity,
Priority, Status, Reproducibility e Resolution) permettono di avere un quadro
generale per comprendere il quantitativo di risorse da allocare per il test, basandosi
sulla difettosità dei componenti, in questo modo i componenti più “critici” possono
essere oggetto di test diversi, come ad esempio test giornalieri piuttosto
che
142
settimanali. Si evince, pertanto, che l’utilizzo del tool consente agli appaltatori di
migliorare e/o ridurre lo sforzo richiesto per un determinato componente.
I dati relativi alle analisi statiche, infine, permettono di predire il failure rate dei
componenti il quale può essere sfruttato a supporto della progettazione dei casi di
test. Il confronto tra i vari componenti, in relazione agli attributi di classificazione e i
trend ottenibili dalla comparazione tra difetti aperti e chiusi con diversi livelli di
granularità, forniscono un contributo prezioso al processo decisionale, dal momento
che permettono di capire come sta procedendo la risoluzione dei difetti nel tempo
rispetto al rilevamento.
Si evidenzia, grazie allo strumento, lo stretto legame
che esiste tra la defect
management ed il change management, essendo i cambiamenti collegati tanto alla
priorità (o ad un altro attributo di classificazione) quanto all’impatto in termini di
costo e tempo che lo caratterizzano.
Per sviluppi futuri il tool può essere corredato di tantissime altre funzionalità, quali la
gestione dei progetti differenziata per permessi utenti, meccanismi di notifiche
avanzati e altra reportistica che possa coprire vari aspetti relativi al processo di
sviluppo, offrendo supporto ad altre metodologie di progettazione. Questi aspetti
renderebbero il tool uno strumento tanto completo da poter concorrere con soluzioni
già presenti e affermate sul mercato.
143
Code Snippets
Web Service -All Issues
144
Issues Java
/**
*
* @author Effect
*/
@Entity
@Table(name = "issue")
@XmlRootElement
@NamedQueries({
@NamedQuery(name = "Issue.findAll", query = "SELECT i FROM Issue i"),
@NamedQuery(name = "Issue.findById", query = "SELECT i FROM Issue i WHERE i.id = :id"),
@NamedQuery(name = "Issue.findByVeVtechniqueID", query = "SELECT i FROM Issue i
WHERE i.veVtechniqueID = :veVtechniqueID"),
@NamedQuery(name = "Issue.findByProjectId", query = "SELECT i FROM Issue i WHERE
i.projectId = :projectId"),
@NamedQuery(name = "Issue.findByProjectVersionId", query = "SELECT i FROM Issue i
WHERE i.projectVersionId = :projectVersionId"),
@NamedQuery(name = "Issue.findByComponentId", query = "SELECT i FROM Issue i WHERE
i.componentId = :componentId"),
@NamedQuery(name = "Issue.findByAnalysisId", query = "SELECT i FROM Issue i WHERE
i.analysisId = :analysisId"),
@NamedQuery(name = "Issue.findByIssuenum", query = "SELECT i FROM Issue i WHERE
i.issuenum = :issuenum"),
@NamedQuery(name = "Issue.findByPkey", query = "SELECT i FROM Issue i WHERE i.pkey =
:pkey"),
@NamedQuery(name = "Issue.findByIssueType", query = "SELECT i FROM Issue i WHERE
i.issueType = :issueType"),
@NamedQuery(name = "Issue.findBySummary", query = "SELECT i FROM Issue i WHERE
i.summary = :summary"),
@NamedQuery(name = "Issue.findByPriority", query = "SELECT i FROM Issue i WHERE
i.priority = :priority"),
@NamedQuery(name = "Issue.findBySeverity", query = "SELECT i FROM Issue i WHERE
i.severity = :severity"),
@NamedQuery(name = "Issue.findByReproducibility", query = "SELECT i FROM Issue i
WHERE i.reproducibility = :reproducibility"),
@NamedQuery(name = "Issue.findByResolution", query = "SELECT i FROM Issue i WHERE
i.resolution = :resolution"),
@NamedQuery(name = "Issue.findByIssuestatus", query = "SELECT i FROM Issue i WHERE
i.issuestatus = :issuestatus"),
@NamedQuery(name = "Issue.findByDetected", query = "SELECT i FROM Issue i WHERE
i.detected = :detected"),
@NamedQuery(name = "Issue.findByUpdated", query = "SELECT i FROM Issue i WHERE
i.updated = :updated"),
@NamedQuery(name = "Issue.findByTestCaseNumber", query = "SELECT i FROM Issue i
WHERE i.testCaseNumber = :testCaseNumber"),
@NamedQuery(name = "Issue.findByFixingDate", query = "SELECT i FROM Issue i WHERE
i.fixingDate = :fixingDate")})
145
public class Issue{
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Basic(optional = false)
@Column(name = "ID")
private Integer id;
@Column(name = "VeV_technique_ID")
private Integer veVtechniqueID;
@Column(name = "PROJECT_ID")
private Integer projectId;
@Column(name = "PROJECT_VERSION_ID")
private Integer projectVersionId;
@Column(name = "COMPONENT_ID")
private Integer componentId;
@Column(name = "ANALYSIS_ID")
private Integer analysisId;
@Column(name = "issuenum")
private Integer issuenum;
@Size(max = 255)
@Column(name = "pkey")
private String pkey;
@Size(max = 255)
@Column(name = "issue_type")
private String issueType;
@Size(max = 255)
@Column(name = "SUMMARY")
private String summary;
@Lob
@Size(max = 2147483647)
@Column(name = "DESCRIPTION")
private String description;
@Size(max = 255)
@Column(name = "PRIORITY")
private String priority;
@Size(max = 255)
@Column(name = "SEVERITY")
private String severity;
@Size(max = 255)
@Column(name = "REPRODUCIBILITY")
private String reproducibility;
@Size(max = 255)
@Column(name = "RESOLUTION")
private String resolution;
@Size(max = 255)
@Column(name = "issuestatus")
private String issuestatus;
@Column(name = "DETECTED")
@Temporal(TemporalType.TIMESTAMP)
private Date detected;
@Column(name = "UPDATED")
private Date updated;
@Column(name = "test_case_number")
private Integer testCaseNumber;
146
@Column(name = "FIXING_DATE")
private Date fixingDate;
@Lob
@Size(max = 65535)
@Column(name = "FIXING_DESCRIPTION")
private String fixingDescription;
public Issue() { }
public Issue(Integer id) {
this.id = id;
}
@XmlElement
public Integer getId() {
return id;
}
public void setId(Integer id) {
this.id = id;
}
@XmlElement
public Integer getVeVtechniqueID() {
return veVtechniqueID;
}
public void setVeVtechniqueID(Integer veVtechniqueID) {
this.veVtechniqueID = veVtechniqueID;
}
@XmlElement
public Integer getProjectId() {
return projectId;
}
public void setProjectId(Integer projectId) {
this.projectId = projectId;
}
@XmlElement
public Integer getProjectVersionId() {
return projectVersionId;
}
public void setProjectVersionId(Integer projectVersionId) {
this.projectVersionId = projectVersionId;
}
@XmlElement
public Integer getComponentId() {
return componentId;
}
147
public void setComponentId(Integer componentId) {
this.componentId = componentId;
}
@XmlElement
public Integer getAnalysisId() {
return analysisId;
}
public void setAnalysisId(Integer analysisId) {
this.analysisId = analysisId;
}
@XmlElement
public Integer getIssuenum() {
return issuenum;
}
public void setIssuenum(Integer issuenum) {
this.issuenum = issuenum;
}
@XmlElement
public String getPkey() {
return pkey;
}
public void setPkey(String pkey) {
this.pkey = pkey;
}
@XmlElement
public String getIssueType() {
return issueType;
}
public void setIssueType(String issueType) {
this.issueType = issueType;
}
@XmlElement
public String getSummary() {
return summary;
}
public void setSummary(String summary) {
this.summary = summary;
}
@XmlElement
public String getDescription() {
return description;
}…
148
Issues Service
import com.prova.dao.IssueDAO;
import com.prova.model.Issue;
import java.util.List;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
/* @author Effect */
@Path("issueService")
public class IssueService {
private final IssueDAO dao = new IssueDAO();
//Tutte le issue della tabella
@GET
@Path("/Issues")
@Produces({MediaType.APPLICATION_JSON,MediaType.APPLICATION_XML})
public List<Issue> getAllIssue(){
return dao.getAllIssue();
}
//Issue in funzione dell'ID del componente
@GET
@Path("/IssueByCompId/{compId}")
@Produces({MediaType.APPLICATION_XML,MediaType.APPLICATION_JSON})
public List<Issue> getIssueByCompId(@PathParam("compId") int compId){
return dao.getIssueByCompId(compId);
}
//Issue in funzione della priority
@GET
@Path("/IssueByPriority/{priority}")
@Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
public List<Issue> getAllIssueByPriority(@PathParam("priority") String priority){
return dao.getIssueByPriority(priority);
}
//Issue in funzione della severity
@GET
@Path("/IssueBySeverity/{severity}")
@Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
public List<Issue> getAllIssueBySeverity(@PathParam("severity") String severity){
return dao.getIssueBySeverity(severity);
}
…
149
Issues Dao
import com.prova.hibernate.HibernateUtil;
import com.prova.model.Issue;
import java.util.List;
import org.hibernate.HibernateException;
import org.hibernate.Query;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
/* @author effecT!*/
public class IssueDAO {
SessionFactory sessionFactory = HibernateUtil.getSessionFactory();
public List<Issue> getAllIssue() {
List<Issue> allIssue = null;
Session session = null;
try {
session = sessionFactory.openSession();
session.beginTransaction();
allIssue = session.createQuery("from Issue").list();
session.getTransaction().commit();
} catch (HibernateException e) {
if (session != null) {
session.getTransaction().rollback();
}
} finally {
session.close();
}
}
return allIssue;
}
public List<Issue> getIssuePerComponent(int compId, int choise, String attribute) {
List<Issue> allIssue = null;
Session session = null;
String sql = "from Issue i where i.componentId= :componentId and ";
switch(choise){
case 1: sql = sql +"i.priority= :attribute"; //Case per priority
break;
case 2: sql = sql +"i.severity= :attribute"; //Case per severity
break;
case 3: sql = sql +"i.reproducibility= :attribute"; //Case per reproducibility
break;
case 4: sql = sql +"i.issuestatus= :attribute"; //Case per issuestatus
break;
}
150
try {
session = sessionFactory.openSession();
session.beginTransaction();
allIssue = session.createQuery(sql).setParameter("componentId",
compId).setParameter("attribute", attribute).list();
session.getTransaction().commit();
} catch (HibernateException e) {
session.getTransaction().rollback();
}
} finally {
session.close();
}
}
return allIssue;
}
}
Script per esportare tabelle in file .xls
/* Export Table to xls */
FExport = (function() {
var version = "1.3";
var uri = {excel: 'data:application/vnd.ms-excel;base64,', csv: 'data:application/csv;base64,'};
var template = {excel: '<html xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REChtml40"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><!--[if
gte mso
9]><xml><x:ExcelWorkbook><x:ExcelWorksheets><x:ExcelWorksheet><x:Name>{worksheet}<
/x:Name><x:WorksheetOptions><x:DisplayGridlines/></x:WorksheetOptions></x:ExcelWorkshe
et></x:ExcelWorksheets></x:ExcelWorkbook></xml><![endif]-></head><body><table>{table}</table></body></html>'};
var base64 = function(s) {
return window.btoa(unescape(encodeURIComponent(s)));
};
var format = function(s, c) {
return s.replace(/{(\w+)}/g, function(m, p) {
return c[p];
});
var get = function(element) {
if (!element.nodeType) {
return document.getElementById(element);
}
return element;
};
151
var ee = {
/** @expose */
excel: function(anchor, table, name) {
table = get(table);
var ctx = {worksheet: name || 'Worksheet', table: table.innerHTML};
var hrefvalue = uri.excel + base64(format(template.excel, ctx));
anchor.href = hrefvalue;
// Return true to allow the link to work
return true;
}
};
return ee;
}());
Script per esportare tabelle in file .csv
jQuery.fn.table2CSV = function(options) {
var options = jQuery.extend({
separator: ',',
header: [],
delivery: 'popup' // popup, value
},
options);
var csvData = [];
var headerArr = [];
var el = this;
//header
var numCols = options.header.length;
var tmpRow = []; // construct header avalible array
if (numCols > 0) {
for (var i = 0; i < numCols; i++) {
tmpRow[tmpRow.length] = formatData(options.header[i]);
}
} else {
$(el).filter(':visible').find('th').each(function() {
if ($(this).css('display') != 'none') tmpRow[tmpRow.length] = formatData($(this).html());
});
}
row2CSV(tmpRow);
$(el).find('tr').each(function() {
var tmpRow = [];
$(this).filter(':visible').find('td').each(function() {
if ($(this).css('display') != 'none') tmpRow[tmpRow.length] = formatData($(this).html());
});
row2CSV(tmpRow); });
152
if (options.delivery == 'popup') {
var mydata = csvData.join('\n');
return popup(mydata);
} else {
var mydata = csvData.join('\n');
return mydata;
}
function row2CSV(tmpRow) {
var tmp = tmpRow.join('') // to remove any blank rows
// alert(tmp);
if (tmpRow.length > 0 && tmp != '') {
var mystr = tmpRow.join(options.separator);
csvData[csvData.length] = mystr;
}
}
function formatData(input) {
// replace " with “
var regexp = new RegExp(/["]/g);
var output = input.replace(regexp, "“");
//HTML
var regexp = new RegExp(/\<[^\<]+\>/g);
var output = output.replace(regexp, "");
if (output == "") return '';
return '"' + output + '"';
}
function popup(data) {
var generator = window.open('', 'csv', 'height=400,width=600');
generator.document.write('<html><head><title>CSV</title>');
generator.document.write('</head><body >');
generator.document.write('<textArea cols=70 rows=15 wrap="off" >');
generator.document.write(data);
generator.document.write('</textArea>');
generator.document.write('</body></html>');
generator.document.close();
return true;
}
};
153
Bibliografia
[1] Ian Sommerville. Software Engineering, 8/E. Pearson Education, 2008
[2] Industry-Academia Partnerships and Pathways , Iceberg project,
[3] H. J. Harrington, «The Productivity and Quality Connection,» IEEE Journal on
Selected Areas in Communication, vol. 4, nº 7, pp. 1009-1014, 1986.
[4] APM, «A History of the Association for Project Management 1972-2010,»
Association for Project Management, Buckinghamshire, 2010.
[5] ISO/IEC 15504:2012-Information tecnology-Process assessment 2012
[6] ISO/IEC 12207-2008. Systems and software engineering- Software life cycle
processess 2008
[7] CMMI Product Team. CMMI for Development, Version 1.2, CMMI-DEV, V1.2,
CMU/SEI-2006-TR-008, ESC-TR-2006-008. Pittsburgh: Software engineering
Institute 2006
[8] http://www.defectmanagement.com/defectmanagement/estimpact.htm
[9] http://www.defectmanagement.com/defectmanagement/delbaselining.htm
[10] IEEE: IEEE Std. 1044-2009. Standard Classification for Software Anomalies.
[11] Ram Chillarege, Inderpal S Bhandari, Jarir K Chaar, Michael J Halliday, Diane
S Moebus, Bonnie K Ray, and M-Y Wong. Orthogonal defect classication-a concept for in-process measurements. Software Engineering, IEEE Transactions on,
18(11):943-956, 1992.
[12] IEEE: IEEE Std. 1044-2009. Standard Classification for Software Anomalies.
[13] Vallespir, D., Grazioli, F., Herbert, J.: A Framework to Evaluate Defect
Taxonomies. In: VI Workshop Ingeniería de Software (WIS), Argentina, pp.643-652
(2009).
154
[14] Lars-Ola Damm, Lars Lundberg, and Claes Wohlin. Determining the
improvement potential of a software development organization through fault analysis:
A method and a case study. In Torgeir Dingsøyr, editor, Software Process
Improvement, volume 3281 of Lecture Notes in Computer Science, pages 138–149.
Springer Berlin Heidelberg, 2004.
[15]L.-O. Damm and L. Lundberg. Identification of test process improvements by
combining fault trigger classification and faults-slip-through measurement. In
Empirical Software Engineering, 2005. 2005 International Symposium on, page 10
pp., nov.2005.
[16] Melleg°ard N, Staron M, T¨orner F. A light-weight defect classification scheme
for embedded automotive software and its initial evaluation. Proc. 23rd IEEE
International Symposium on Software Reliability Engineering (ISSRE), 2012.
[17] Wagner S. Defect classification and defect types revisited. Proc. 2008 workshop
on Defects in large software systems, 2008; 39–40.
[18] Freimut B, Denger C, Ketterer M. An industrial case study of implementing and
validating defect classification for process improvement and quality management.
Proc. 11th IEEE Int. Symposium on Software Metrics, 2005.
[19] MIL-STD-498, Overview and Tailoring Guidebook, US Dept. of Defense 1996
[20] Carrozza G, Faella M, Fucci F, Pietrantuono R, Russo S. Engineering air traffic
control systems with a model-driven approach. IEEE Software 2013; 30(3):42–48,
doi:http://doi.ieeecomputersociety.org/10.1109/MS.2013.20
[21] http://www.mantisbt.org
[22] https://www.atlassian.com/software/jira
[23] http://www.bugzilla.org
[24] http://www.websina.com/bugzero/
[25] http://www.redmine.org/
[26] http://www.trackstudio.com/
[27] https://www.polarion.com/
[28]
http://www.serena.com/index.php/en/solutions/app-dev-delivery/issue-defect155
management
[29] http://www-03.ibm.com/software/products/en/ratiqualmana
[30] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
[31] http://hibernate.org
[32] Selex, New KPIs introduction
156

Progettazione di un cruscotto di analisi dei difetti dei componenti in

Transcript

Documenti analoghi

N. 4 Dicembre 2012 - Registro Toscano Difetti Congeniti

- PORTO - Publications Open Repository TOrino

Catalogo senza foto in PDF

I Sessione

Italian / English

maison bibelot - Associazione Nazionale Case d`Asta italiane

Libero come il software

tennis NEWS - OkTennis Market