Progettazione di un cruscotto di analisi dei difetti dei componenti in
Transcript
Progettazione di un cruscotto di analisi dei difetti dei componenti in
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 2.2 Confronto Tools (2/3) ................................................................................................. 90 Tabella 2.3 Confronto Tools (3/3) ................................................................................................. 90 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale Tabella 2.2 Confronto Tools (2/3) Tabella 2.3 Confronto Tools (3/3) 90 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale Figura 2.24 Jira - workflow grafico Figura 2.25 Jira - workflow testuale 94 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale Figura 3.4 Database effecT! 111 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale Figura 3.6 Mantis_bug_table e Jiraissue table 114 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale Figura 4.18 Summary Component Reproducibility Naturalmente la tabella relativa ai risultati può essere esportata in formato .xsl 132 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale Figura 4.19 Summary Component -Severity 133 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale Figura 4.25 Month - All component Figura 4.26 Year - All component 138 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale Figura 4.27 Day - component1 Figura 4.28 Week - component1 139 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale Figura 4.29 Month - component1 Figura 4.30 Year - component1 140 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale Code Snippets Web Service -All Issues 144 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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") @Temporal(TemporalType.TIMESTAMP) private Date updated; @Column(name = "test_case_number") private Integer testCaseNumber; 146 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale @Column(name = "FIXING_DATE") @Temporal(TemporalType.TIMESTAMP) 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 { if (session != null) { 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale try { session = sessionFactory.openSession(); session.beginTransaction(); allIssue = session.createQuery(sql).setParameter("componentId", compId).setParameter("attribute", attribute).list(); session.getTransaction().commit(); } catch (HibernateException e) { if (session != null) { session.getTransaction().rollback(); } } finally { if (session != null) { 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale [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 Progettazione di un cruscotto di analisi dei difetti dei componenti di sistemi software large-scale 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