Alta: la probabilità che il rischio si verifichi è compresa

Transcript

1 Speed It App Carlo Branca, Giovanni Grano, Matteo Merola, Simone Scalabrino, Andrea De Lucia (tutor), Filomena Ferrucci (tutor) University of Salerno, Fisciano (SA), Italy Sommario Speed It App è un sistema composto da un applicazione mobile e un applicazione web che aiutano gli organizzatori di grandi eventi, come conferenze, concerti, eventi sportivi o simili, ad organizzare il processo di registrazione dei clienti. L enfasi è posta sul velocizzare le code definendo un nuovo workflow, utilizzando tool innovativi. Nel nostro sistema, l applicazione mobile è usata dagli organizzatori per scannerizzare le persone in coda, catturando un codice QR identificativo che ogni persona ha (sul suo smartphone o su normale carta). Questa applicazione fa confluire i dati delle persone su un applicazione web che gli organizzatori possono usare per preparare procedure e kit di benvenuto che devono eventualmente consegnare ai partecipanti. Sono state toccate tutte le fasi dell ingegneria del software al fine di realizzare Speed It App, ma si è data maggior enfasi al testing, al fine di consegnare un prodotto di alta qualità. I. INTRODUZIONE Sono tante le occasioni in cui, prima di poter partecipare ad un evento, è necessario effettuare la registrazione presso un punto apposito. In questi casi è molto comune la presenza di molte persone in coda. Si pensi, ad esempio, a conferenze scientifiche o convegni: spesso bisogna preparare dei kit di benvenuto (personalizzati) da consegnare a ogni partecipante. Una normale gestione delle code ha i seguenti svantaggi: Tempo: è necessario preparare i kit prima che inizi la procedura di registrazione Risorse: è necessario coinvolgere molte persone per ridurre i tempi, soprattutto nel caso in cui si vuole usare più di un punto di registrazione Spazio: se si vogliono preparare preventivamente i kit, bisogna trovare un posto che li ospiti in modo relativamente sicuro Speed It App ha come obiettivo principale la velocizzazione di processi di registrazione in diversi ambienti: il prodotto è stato pensato principalmente per conferenze scientifiche o convegni, ma può essere utile in molte altre occasioni (eventi sportivi, concerti, etc). Il progetto ha lo scopo di progettare e implementare una serie di applicazioni mobili e web di qualità piuttosto elevata. La relazione è organizzata come di seguito specificato: a) Sezione II: contiene un analisi degli obiettivi, delle risorse, del budget e del tempo a disposizione, grazie ai quali è stato possibile elaborare un piano di progetto. Sono presenti anche informazioni sul modello di ciclo di vita del software utilizzato, nonché dettagli circa la gestione della qualità all interno del progetto. b) Sezione III: spiega come si è proceduto alla raccolta e all analisi dei requisiti del sistema, l approccio utilizzato per l organizzazione del RAD e i modelli utilizzati per descrivere nella maniera più precisa e meno ambigua possibile il sistema. c) Sezione IV: mostra i risultati della fase di System Design, quindi come sono stati individuati i sottosistemi, come è mappata l applicazione su diversi nodi hardware e altri dettagli, come la specifica precisa dei servizi principali dei sottosistemi. d) Sezione V: accenna alla fase di Object Design, mostrando il diagramma delle classi principali e descrivendo i design pattern scelti. e) Sezione VI: definisce in maniera più precisa il design del database, come si intende conservare i dati persistenti e le tecnologie utilizzate per lo storage. f) Sezione VII: contiene informazioni su come si è proceduto e si procederà all implementazione del prodotto e sulle tecnologie utilizzate. g) Sezione VIII: mostra in maniera dettagliata come si è pianificato il testing e come sono stati progettati i singoli casi di test, grazie ai quali sarà possibile assicurare un buon livello di qualità del prodotto. h) Sezione IX: spiega come e perché sono state prese alcune scelte, sia tecniche sia gestionali, al fine di renderle esplicite e tracciabili. i) Sezione X: accenna ai tool utilizzati per gestire le versioni degli artefatti. j) Sezione XI: presenta i risultati raggiunti, i deliverable rilasciati attualmente e i deliverable attesi in futuro. k) Sezione XII: contiene le conclusioni e un riassunto di tutto quello che è stato presentato in questa relazione. II. PIANIFICAZIONE GENERALE Nella fase iniziale del progetto è stato necessario valutare la fattibilità dell idea. A tale proposito, è stato necessario condurre uno studio, valutando in maniera molto grossolana i costi e i tempi del progetto, in relazione al tempo a disposizione. Dato che si è deciso di partecipare alla competizione molto tardi, infatti, questo studio ha assunto un ruolo di particolare importanza. Alla fine si è valutato che l esperienza del team in applicazioni di questo tipo potesse, in qualche modo, sopperire alla penuria di tempo a disposizione. Realizzare un progetto del genere, tuttavia, avrebbe comunque potuto portare al fallimento se non si fosse proceduto con una pianificazione attenta.

2 Codice Nome Responsabilità DL 1 SPMP Tutti DL 2 Requirement Analysis Document SS DL 3 System Design Document MM DL 4 Object Design Document MM DL 5 Database Design Document GG DL 6 Test Plan CB e SS DL 7 Test Case Specification CB DL 8 Test Log SS DL 9 Test Incident Report MM DL 10 Implementazione Tutti DL 11 Rationale GG Tabella I TABELLA DEI DELIVERABLE DA RILASCIARE. IN GRASSETTO, I DELIVERABLE CHE SARANNO CONSEGNATI ENTRO LA SCADENZA. Attività Stima pessimistica Stima probabile Stima ottimistica Pianificazione 12h 10h 8h Analisi requisiti 30h 20h 18h System design 14h 10h 8h Object design 10h 6h 5h Implementazione 140h 100h 80h Testing (specifica) 40h 25h 20h Testing (esecuzione) 40h 20h 20h Totale 290h 190h 160h Tabella II STIMA DEI COSTI DELLE ATTIVITÀ. I TOTALI SONO APPROSSIMATI ALLE DECINE. Rischio Probabilità Impatto Scarsa conoscenza del dominio Media Serio applicativo Implementazione non completa Bassa Serio Ritardo di un task Bassa Tollerabile Ritardo su un attività pre SCORE- Bassa Catastrofico IT Ritardo su un attività post Bassa Serio SCORE-IT Tabella III RISCHI DEL PROGETTO. Figura 1. Struttura organizzativa del progetto L obiettivo principale dell elaborazione del piano è stato quello di stimare, in maniera più attenta, i costi del progetto, i deliverable da sviluppare e quelli da rilasciare per la scadenza, nonché la decisione del modello di ciclo di vita del software da adottare. Il vincolo principale da tenere in considerazione, come già detto, era il tempo, di circa un mese in totale, dato che la scadenza è fissata. Alla luce di questa limitazione importante, sono stati decisi i deliverable da sviluppare, e quali deliverable sviluppare per la scadenza (in tabella I). La struttura organizzativa del progetto (figura 1) è estremamente semplice: i due tutor, da un lato, hanno supervisionato il lavoro e sono stati attivi nella fase iniziale di raccolta di requisiti, fornendo informazioni dettagliate ai membri del team sul dominio applicativo e su quelli che sono diventati, poi, i requisiti del sistema; dall altro i membri del team hanno provveduto a produrre tutta la documentazione fornita e parte dell implementazione. A. Stima di costi e rischi La stima dei costi di un progetto è una delle sfide più complesse, soprattutto nelle fasi iniziali. Ci si è basati soprattutto sull esperienza dei team member per stimare il numero di ore richieste da ognuna delle macro-attività individuate. Nella tabella II non è specificata una stima puntuale, ma tre stime: una pessimistica, una ottimistica e una considerata la più probabile. I totali sono approssimati alle decine, dato le stime della prima fase di pianificazione sono molto grezze. Oltre ai costi, è importante gestire in maniera appropriata tutti i rischi che si ritiene di dover monitorare durante tutto il progetto. La tabella III mostra, appunto, i rischi che saranno attentamente gestiti. Le probabilità identificate sono le seguenti: Bassa: la probabilità che il rischio si verifichi è compresa nell intervallo 0%-30%. Media: la probabilità che il rischio si verifichi è compresa nell intervallo 30%-60%. Alta: la probabilità che il rischio si verifichi è compresa nell intervallo 60%-100%. I possibili impatti, invece, sono i seguenti: Insignificante: il verificarsi del rischio non compromette la buona riuscita del progetto. Tollerabile: classifica rischi di semplice gestione in quanto le problematiche ad essi collegate sono facilmente risolvibili. Serio: rischi di questo tipo possono rallentare notevolmente il progetto mettendone a rischio la buona riuscita; è necessario risolverli nel più breve tempo possibile. Catastrofico: rischi di difficile soluzione; se non affrontati per tempo portano di sicuro al fallimento. Per ogni rischio individuato, sono stati definiti dei piani di minimizzazione e di contingenza, al fine, rispettivamente, di ridurre la probabilità e ridurre l eventuale impatto del verificarsi di un rischio. B. Piani tecnici di processo Per lo sviluppo del progetto si è scelto di utilizzare un istanza del meta-modello a spirale: il processo di sviluppo sarà sottoposto in ogni sua fase al rispetto delle quattro task regions offerte da tale modello: Determinazione di obiettivi e alternative: obiettivi specifici per la fase del progetto 2

3 1.Determinare gli obiettivi Progresso 2. Identificare e risolvere i rischi Revisione Piano inziale Requisiti iniziali Analisi dei requisiti System design Sviluppo codice Piano di Verifica e sviluppo convalida Sviluppo UI Object design Test plan Verifica e convalida Progettazione test Integrazione Test 4. Pianificazione della prossima iterazione Rilasci 3. Sviluppo e test Figura 2. Istanza del meta-modello a spirale Valutazione delle alternative e dei rischi: analisi dei rischi del progetto; si prendono precauzioni per ridurli o ridurne l incidenza all interno del progetto Sviluppo e convalida: si creano gli artefatti richiesti e si convalidano i risultati Pianificazione: viene revisionato il progetto e si decide se e come effettuare un nuovo giro di spirale La scelta è ricaduta su questo modello poiché esso rende esplicita la gestione dei rischi e permette di determinare eventuali errori nelle fasi iniziali. Una prima iterazione è consistita nel raccogliere e nell analizzare in maniera approfondita i requisiti del sistema, sviluppando vari modelli, sia statici sia dinamici, e nell implementare le interfacce grafiche dedicate a tutti gli utenti e relative a tutte le applicazioni che si intendono sviluppare. In particolare, l implementazione dell interfaccia relativa ai due siti web potrà essere usata come base per le fasi di sviluppo future, ed è stata progettata in modo tale da poter essere, successivamente, integrata con il sistema funzionante. Le interfacce relative alle due app mobili, invece, sono semplici mock-up throw-away. Alla fine dell iterazione si sono convalidati i requisiti. Segue un primo incremento di sviluppo, definito in due iterazioni del modello: In una prima iterazione si è proceduto con System Design, Object Design e pianificazione del testing. Una seconda iterazione prevede la specifica dettagliata dei casi di test, l implementazione delle prime funzionaltà core e il relativo testing. La figura 2 mostra un estratto dell istanza del meta-modello a spirale che si seguirà. Un secondo incremento di sviluppo, definito in una sola iterazione del modello, consisterà nell implementare le ultime funzionalità restanti e nel testarle. Infine, un ultima iterazione del modello sarà dedicata alla pianificazione e alla realizzazione dell alpha-testing. Nel primo incremento di sviluppo saranno definite e imple- Figura 3. Work Breakdown Structure del progetto Figura 4. Scheduling del progetto mentate le API Rest necessarie al funzionamento dell intero sistema. Nel secondo incremento saranno sviluppati i seguenti sottosistemi: WebApp; Applicazione mobile. C. Attività e scheduling Definiti i costi e i rischi del progetto, si è proceduto con l elaborazione dettagliata del piano. Per prima cosa è stata definita la Work Breakdown Structure (WBS), ovvero è stato diviso il lavoro in sotto-lavori in maniera ricorsiva. La WBS (in figura 3 ne è presente una parte, di alto livello) è entity-oriented ed è stata prodotta utilizzando un approccio top-down. La WBS è particolarmente importante, poiché, a partire da questa, è possibile fare uno scheduling delle attività. In questo caso è stato scelto di mostrare il risultato di questa fase di pianificazione attraverso un diagramma di Gantt (figura 4). D. Piano di qualità Nel quality plan sono stati definiti gli standard, i processi e le procedure di qualità adottate nel progetto Speed It App. In particolare: 3

4 Codice Nome Data inizio Data fine AC 1 Pianificazione 18/01/15 20/01/15 AC 2 Raccolta e analisi requisiti 21/01/15 28/01/15 AC 3 Implementazione (#1) 29/01/15 5/02/15 AC 4 System design 6/02/15 8/02/15 AC 5 Object design 9/02/15 10/02/15 AC 6 Pianificazione tesing 6/02/15 10/02/15 AC 7 Specifica test 16/02/15 19/02/15 AC 8 Database Design 16/02/15 19/02/15 AC 9 Sviluppo test JUnit 20/02/15 25/02/15 AC 10 Implementazione (#2) 20/02/15 2/03/15 AC 11 Testing (#1) 3/03/15 9/03/15 AC 12 Implementazione (#3) 3/03/15 17/03/15 AC 13 Testing (#2) 18/03/15 23/03/15 AC 14 Alpha-testing 24/03/15 3/04/15 Tabella IV SCHEDULING DELLE ATTIVITÀ. Figura 5. Organizzazione nel processo di qualità obiettivi di qualità processi da applicare per raggiungere gli obiettivi procedure da utilizzare per il controllo di qualità procedure da utilizzare per l approvazione e la revisione le metriche di progetto le responsabilità all interno del team le modalità di comunicazione L organizzazione all interno del processo di quality management è stata strutturata nel seguente modo: I ruoli indicati all interno del diagramma non sono fissi ma possono essere ricoperti da diversi team member in diversi periodi di tempo. Nel documento sono stati definiti i principali task per il corretto svolgimento del processo di quality management, in particolare: Definizione del piano di qualità: in questa fase sono definiti gli standard di qualità in base ai costi, benefici attesi, criteri di accettazione, scheduling e obiettivi del progetto. Definizione di checklist di revisione: in questa fase sono state definite le checklist di revisione per ogni artefatto. Il livello di dettaglio e qualità richiesta dalle checklist è direttamente influenzato dal documento di Quality Plan. Figura 6. Categorie di qualità Elaborazione artefatto: durante questa fase i membri del team si occupano di definire l artefatto software. L elaborazione dell artefatto deve seguire le linee guida fornite nel Quality Plan. Revisione artefatto: in questa fase i revisori hanno il compito di leggere l artefatto oggetto dell ispezione e annotare i difetti. Lo scopo è quello di trovare quanti più difetti possibili Correzione artefatto: nel caso in cui la revisione non ha trovato difetti, allora il documento è accettato. In caso contrario, segue una fase di rework, in cui l autore dell artefatto con difetti ha il compito di apportare le opportune modifiche. Il processo prosegue con un ulteriore verifica che ha l obiettivo di assicurare che i difetti siano stati effettivamente corretti, e che non siano stati apportati altri difetti. I documenti sotto osservazione nel processo di quality assurance sono: Requirements Analysis Document System Design Document Object Design Document Database Design Document Test Plan Software Project Management Plan Lo standard di riferimento per la definizione del Quality Plan è l ISO/IEC 9126, che definisce un modello di qualità del software. In particolare tale standard, definisce sei categorie di qualità, ulteriormente suddivise in sotto categorie secondo una struttura gerarchica. Nella figura 6 sono rappresentate le sotto categorie considerate di maggior importanza per la qualità del progetto Speed It App: Oltre alla definizione dettagliata delle caratteristiche di qualità, è stato definito un peso per ognuna di esse, ovvero l importanza che gli sarà attribuita nella valutazione delle qualità del sistema, con una scala di valori per il peso che va da 5 (caratteristica di qualità molto importante) a 1 (caratteristica di qualità poco importante). Nel quality plan sono state definite le modalità e gli strumenti di comunicazione, le regole per la pubblicazione dei documenti, le regole per gli identificatori dei documenti, il ciclo di vita dei documenti e il processo di revisione. Per il raggiungimento della qualità, sono state definite metriche sui documenti, ovvero: Indice di inesattezza 4

5 Indice di leggibilità (Gulpease) e metriche sul codice: Lines of Code (LOC) Complessità Ciclomatica di McCabe Lack of Choesion Method (LCOM) Per quanto riguarda il processo di revisione, le strategie e le tecniche sono state definite internamente al team. Nel Quality Plan, dunque, non è stato specificato tale aspetto. Tuttavia si procederà a definire software review conformi agli obiettivi di qualità delineati. III. RACCOLTA E ANALISI DEI REQUISITI La fase di raccolta e di analisi dei requisiti è molto importante, poiché permette di modellare il sistema che dovrà essere realizzato. Requisiti incompleti e casi d uso ambigui sono problemi frequenti, che si ripercuotono sull intero sistema. Dato il focus del progetto sulla qualità, e in particolare sul testing, non si è potuto fare a meno di dare molta importanza a questa fase, in modo da assicurare una specifica completa e corretta, come base solida per la definizione dei casi di test. A. Raccolta dei requisiti Data la scarsa conoscenza del dominio applicativo da parte dei membri del team di sviluppo, si è proceduto, in una fase preliminare, a consultare diversi docenti universitari per capire com è strutturato il processo di registrazione in una conferenza scientifica, come vengono preparati gli eventuali kit di benvenuto e quali sono le problematiche principali da poter risolvere. Sono stati, quindi, definiti i requisiti principali del sistema, che sono stati successivamente arricchiti al fine di rendere l esperienza degli organizzatori e dei partecipanti più gradevole. 1) Requisiti funzionali: Gli utenti potranno accedere alle seguenti funzionalità: FR1: Visualizzazione della lista completa degli iscritti a Speed It App(e di filtrarli secondo determinati criteri) attraverso il sito web; FR2: Visualizzazione dell ordine di arrivo dei partecipanti in coda, attraverso il sito web; FR3: Riconoscimento degli identificativi dei partecipanti che sono in coda, attraverso app mobile; FR4: Segnalazione di un partecipante in coda senza QR code tramite app mobile; FR5: Segnalazione di un partecipante in coda senza QR code e impegnato (segnalazione come sconosciuto); FR6: Segnalazione di un partecipante in coda tramite codice QR scansionato con app mobile; FR7: Creazione, rimozione e modifica di una coda attraverso l applicazione web; FR8: Aggiunta di una lista di utenti al sistema tramite l applicazione web; FR9: Generazione codice QR per il pairing del dispositivo mobile all applicazione web; FR10: Possibilità di contrassegnare un partecipante come già servito, direttamente dall interfaccia di visualizzazione della coda, nella web app. 2) Requisiti non funzionali: Oltre alle funzionalità specificate, sono richieste anche altre caratteristiche: NR1: È richiesto che gli organizzatori possano usare con semplicità gli strumenti messi a disposizione (le funzionalità devono essere chiaramente accessibili). NR2: Il sistema deve essere molto affidabile, dato che, se adottato, diventa critico nell organizzazione. NR3: Il sistema dev essere molto reattivo. Il riconoscimento degli identificativi deve richiedere non più di 5 secondi, mentre la visualizzazione dell ordine di arrivo deve richiedere meno di 10 secondi. NR4: Le applicazioni mobili dovranno essere sviluppate in Java e Objective-C, per supportare dispositivi Android e ios. NR5: Il sistema deve poter essere facilmente adattato ad un database proprietario che contiene i dati del singolo evento gestito. NR6: Il sistema deve consistere solo di pacchetti facilmente installabili da un tecnico in un tempo massimo di due ore. NR7: Il sistema deve gestire in modo sicuro i dati personali dei partecipanti, richiedendo, comunque solo le informazioni necessarie all identificazione e alla semplificazione della registrazione. Il sistema dev essere ultimato e testato accuratamente prima dell evento al fine di garantirne un ottimale funzionamento nel corso della conferenza. B. Sistema proposto Il sistema dovrà essere strutturato in modo da essere utilizzato sia da dispositivi fissi sia da dispositivi mobili. Il sistema proposto consisterà, quindi, di due applicativi software: Sito web per gli organizzatori: sarà disponibile un sito web che permetterà agli organizzatori di monitorare costantemente la coda, di conoscere l ordine di arrivo delle persone in modo da minimizzare il tempo per la ricerca dei kit spettanti agli ospiti in coda; Applicazione per gli organizzatori: gli organizzatori avranno a disposizione un applicazione grazie alla quale potranno scannerizzare gli identificativi dei partecipanti che sono in coda. C. Modello dei casi d uso Nella fase di analisi dei requisiti si è proceduto a trasformare i requisiti funzionali in scenari e, successivamente, casi d uso. Gli scenari hanno l obiettivo di facilitare l individuazione dei casi d uso, soprattutto di quelli che rappresentano eccezioni rispetto ai casi d uso facilmente deducibili dai requisiti. I diagrammi nelle figure 7, 8 e 9 descrivono il sistema e i vari casi d uso individuati in maniera riassuntiva. Al fine di rendere i casi d uso tracciabili rispetto ai requisiti, si è fatto in modo che il RAD sia organizzato in modo che le 5

6 <<click>> Figura 7. iscritti Casi d uso relativi al controllo degli accessi e alla gestione degli Figura 10. Sequence diagram della funzionalità Associazione del dispositivo scanner macro-sezioni facciano riferimento ai requisiti funzionali e le sotto-sezioni rappresentino determinati insiemi di casi d uso, tutti strettamente legati, in cui è presente un caso d uso principale (numerato con un progressivo) e vari casi d uso eccezionali, identificati attraverso il l identificativo del caso d uso principale seguito da un sotto-identificativo progressivo. Figura 8. Casi d uso relativi al controllo degli ID Figura 9. Casi d uso relativi alla gestione della coda D. Modelli dinamici e mock-up Molte delle funzionalità del sistema sono comuni, e c è una sorta di convenzione tacita su come devono essere realizzate (si vedano, ad esempio, le funzionalità che implementano il CRUD degli utenti, etc.). Altre funzionalità, benché siano meno comuni e più specifiche, sono comunque molto semplici da capire. Per tutte queste funzionalità si è ritenuto che fosse superfluo definire modelli dinamici che ne descrivessero accuratamente l andamento. Per altre funzionalità meno intuitive, invece, è stato utile definire modelli precisi, in particolare sequence diagram e state chart diagram. La figure 10 mostra un esempio di diagramma dinamico. Per tutte le funzionalità sono stati realizzati dei mock-up, che mostrano l interfaccia grafica del sistema finale. Nel RAD non è presente esattamente un mock-up per ogni funzionalità, dato che alcune di queste sono riassunte in un singolo screenshot. La figura 11 mostra un esempio di prototipo del sistema. Al fine di rendere più agevole la lettura e la comprensione di un singolo caso d uso, si è pensato di inserire gli scenari, i casi d uso, i modelli dinamici e i prototipi insieme, all interno delle sotto-sezioni. Dividere il RAD in base al tipo di modello avrebbe reso l informazione frammentaria e più difficile da ricostruire. IV. DESIGN DEL SISTEMA Terminata la fase iniziale di raccolta e analisi approfondita dei requisiti, si è iniziato a progettare la soluzione al problema. Il primo passo è consistito nel definire l architettura del sistema che si vuole realizzare. Risultato di questa fase è 6

7 Figura 11. Mock-up della funzionalità Visualizzazione della coda il System Design Document, il quale contiene informazioni dettagliate sulla divisione in sotto-sistemi, su come il software sarà mappato sull hardware e su quali saranno le interfacce tra i vari sotto-sistemi. A. Divisione in sotto-sistemi e mapping hardware/software La figura 12 mostra la divisione del sistema in sotto-sistemi. Come si evince facilmente, si è scelto di usare una semplice architettura client-server. Si è preferito adottare questa architettura rispetto ad un architettura di tipo three/four-tier poiché garantisce maggiore sicurezza e soprattutto migliori prestazioni, dato che il DBMS si troverà sulla stessa macchina del webserver e non ci saranno overhead dovuti alla comunicazione tra due macchine diverse. La figura 13, invece, mostra come le varie componenti software dovranno essere installate sulle diverse macchine che compongono il sistema. Il sistema centralizza tutte le operazioni nel server. Un possibile problema di questo approccio è la presenza di un collo di bottiglia proprio dovuto al fatto che un solo server deve fornire servizi a tutti i client. La soluzione, quindi, è scarsamente scalabile e non potrà, probabilmente, essere utilizzata per eventi molto grandi. Sarà preferibile, dunque, fare in modo che, in futuro, si possa modificare questa architettura senza troppo sforzo, attraverso un attenta fase di Object Design e soprattutto di implementazione. B. Servizi dei sotto-sistemi Un altra attività importante della fase di System Design è la definizione dei servizi dei sotto sistemi. Questi sono particolarmente utili, poiché definiscono le interfacce dei sottosistemi, che dovranno essere rispettate durante la fase di implementazione al fine di avere un sistema funzionante e di evitare problemi in fase di integrazione. In questa fase iniziale si è preferito concentrarsi sui servizi offerti dal server alle applicazioni mobili. In particolare si sono individuati i seguenti servizi: 1) Lista utenti: servizio con il quale si può prelevare la lista degli utenti iscritti (eventualmente filtrata) divisa per pagine di lunghezza variabile. 2) Dettagli utente: servizio che permette di ricevere i dettagli di un utente a partire dal suo identificativo. Figura 12. Decomposizione in sotto-sistemi Figura 13. Mapping hardware/software 3) Rimozione utente: permette di eliminare un utente con l identificativo specificato 4) Aggiunta utente: permette di aggiungere un utente manualmente dal dispositivo mobile, specificandone i dettagli. 5) Aggiunta lista utenti: permette di aggiungere una lista di utenti (in formato CSV) al database. 6) Login: permette di controllare le credenziali di accesso (password) di un amministratore. 7) Lista code: permette di prelevare la lista delle code. 8) Dettagli coda: restituisce i dettagli della coda con l identificativo specificato. 7

8 1 getusers({pagesize, filter}):[user] 2 getuser({id}):user 3 removeuser({id}):apimessage 4 adduser({title, firstname, middlename, lastname, sex, , {extrafields}}):apimessage 5 addusers(csv):apimessage 6 login({password}):apimessage 7 getqueues():[queue] 8 getqueue({id}):queue 9 removequeue({name}):apimessage 10 addqueue({name}):apimessage 11 renamequeue({name, newname}):apimessage 12 addtoqueue({queuename, userid}):apimessage 13 clearqueue({name}):apimessage 14 getqueuehead({name, n, from}):[queue] 15 skip({queuename}):apimessage 16 next({queuename, removed}):apimessage 17 associatedevice({devicename, pairingtoken}): APIMessage 18 getassociationtoken({name}):{token} 19 Figura 14. Interfacce dei servizi 9) Aggiungi coda: Aggiunge una coda al database. 10) Elimina coda: permette di eliminare la coda con il nome specificato. 11) Rinomina coda: restituisce i dettagli della coda con l identificativo specificato. 12) Aggiungi alla coda: permette di aggiungere un utente alla coda specificata. 13) Pulisci coda: permette di eliminare tutti gli utenti di una determinata coda. 14) Testa della coda: restituisce i primi n utenti in una coda specificata a partire da un determinato utente. 15) Salta riconoscimento: permette di saltare un riconoscimento, identificando l utente come sconosciuto. 16) Prossimo: servizio chiamato quando il primo utente in coda è stato servito. Sposta la testa della coda. 17) Token di associazione: genera un token che permette di associare la coda specificata ad un dispositivo mobile (tramite il servizion Associa dispositivo ). 18) Associa dispositivo: servizio chiamato dal dispositivo mobile. Associa il device ad una coda, in base al token scannerizzato. La figura 14 mostra, nel dettaglio, le interfacce dei servizi descritti. In ogni caso, le API esibiscono, nella home page, una versione precisa ed aggiornata della documentazione dei singoli servizi (figura 15). C. Sicurezza La sicurezza è uno degli aspetti importanti del sistema, dato che non dovrebbe essere consentito l accesso ad utenti non autorizzati, poiché potrebbero esserci danni dovuti alla violazione della privacy degli utenti e al rallentamento dell intero processo. Per questo motivo, al fine di garantire un livello di sicurezza accettabile, sono state prese le seguenti decisioni: Tutte le connessioni tra dispositivi devono avvenire utilizzando il protocollo HTTPS (HTTP su SSL). Questo consente di evitare che i dati possano essere intercettati da Figura 15. Documentazione dettagliata delle API terzi. Per evitare attacchi di tipo man in the middle sarà necessario installare sul server un certificato rilasciato da una qualunque Certification Authority. Non potranno essere utilizzati certificati self signed, se non in fase di sviluppo e testing. Per l autenticazione dei sistemi che interagiscono tramite API REST dev essere effettuato un controllo basato su un meccanismo di token univoci per ogni applicazione client. Tali token sono generati casualmente e non cambiano durante l utilizzo delle API. Per quanto riguarda gli identificativi univoci, rappresentati attraverso codici QR, questi sono generati una sola volta per ogni utente, in maniera del tutto casuale. L identificativo per l associazione del dispositivo scanner viene generato in maniera casuale ogni volta che si accede alla funzionalità apposita da desktop, ed ha una validità di 120 secondi, dopo i quali viene rimosso e invalidato. V. OBJECT DESIGN L Object Design Document ha lo scopo di produrre un modello capace di integrare in modo coerente e preciso tutti i servizi individuati nelle fasi precedenti. In particolare definisce le interfacce delle classi, le operazioni, i tipi, gli argomenti e la signature dei sottosistemi. Inoltre, definisce i trade-off, le linee guida e i design pattern per l implementazione. I trade-off di design presi in considerazione sono: Comprensibilità vs costi: la comprensibilità del codice è un aspetto di fondamentale importanza, non solo per la manutenzione, ma anche per la fase di testing del prodotto. Per questo motivo si è scelto di utilizzare i commenti Javadoc oltre ai commenti standard. Questa caratteristica aggiungerà dei costi allo sviluppo del progetto ma renderà ogni classe e metodo facilmente interpretabile anche da chi non ha collaborato al progetto. Riuso vs sviluppo: nel progetto si è data grande importanza al riuso. Si utilizzerà Polymer al fine di definire interfacce grafiche gradevoli e adattabili automaticamente a più dispositivi. Nel documento sono state definite le naming convention, in particolare convenzioni su: Nomi dei file: convenzioni sul nome e sull estensione. 8

9 mobile o il client web usando meccanismi di autenticazione differenti. Figura 16. Struttura del Pattern DAO Organizzazione dei file: convenzioni su struttura e lunghezza dei file. Indentazione: convenzioni sulla lunghezza delle linee e sullo spostamento. Commenti: formattazione dei commenti di implementazione e di documentazione. Dichiarazioni: numero di dichiarazioni per linea, inizializzazione, posizione, dichiarazioni di classe ed interfaccia. Istruzioni: semplici, composte, return, if, if-else, if-else-if else, for, while, do-while, switch, try-catch. Spazi bianchi: linee e spazi. Nomi: convenzione su nomi di classi, interfacce, metodi, variabili e costanti. Consuetudini di programmazione. Per quanto riguarda la scelta dei design pattern, la scelta è ricaduta sul Bridge Pattern, sul DAO pattern e sullo Strategy Pattern. Per l utilizzo delle librerie per la generazione dei codici QR e per il riconoscimento di questi ultimi, si è deciso di adottare il design pattern Bridge. L idea del pattern Bridge è quella di separare l interfaccia di una classe (che cosa si può fare con la classe) dalla sua implementazione (come lo fa). In tal modo si può usare questo design pattern al fine di rendere più agevole una eventuale sostituzione della componente relativa ai codici QR. Per quanto riguarda la logica di accesso alla sorgente di dati, si è deciso di utilizzare il pattern DAO. L idea alla base del pattern DAO (Data Access Object) è di disaccoppiare la logica di business dalla logica di accesso ai dati. Questo si ottiene spostando la logica di accesso ai dati dai componenti di business ad una classe DAO. Questo approccio garantisce che un eventuale cambiamento del dispositivo di persistenza non comporti modifiche sui componenti di business. Esiste una classe DAO per ogni classe che rappresenta entità del dominio di applicazione. Questa classe conterrà i metodi di integrazione e manipolazione della corrispondente classi di dominio. In particolare conterrà le funzionalità di base CRUD (Create, Read, Update, Delete). Per quanto concerne il meccanismo di autenticazione token based tra client e server APIs si è scelto di utilizzare un design pattern comportamentale di tipo Strategy/Policy. Questo pattern permette di scegliere a run-time una strategy in base a una policy definita e consente, ad esempio, di autenticare il client VI. DESIGN DEL DATABASE I dati persistenti di Speed It App saranno salvati all interno di un database, e ci si servirà di un DBMS per la gestione dei dati. In questa fase è necessario prendere alcune decisioni importanti, come il tipo di DBMS che si vuole utilizzare. Si è scelto di utilizzare un DBMS di tipo NoSQL orientato ai documenti (MongoDB). Si è preferita questa soluzione rispetto a un database SQL classico perché si pensa di non dover ricorrere a query complesse, con molte join. Le migliori prestazioni di MongoDB, insieme ai pochi vantaggi concreti che si sarebbero tratti dall utilizzo di database relazionali, ha fatto, quindi, propendere per questa scelta. Tutto il processo decisionale è stato mappato nel documento di Rationale, di cui presentiamo un estratto in seguito. VII. IMPLEMENTAZIONE Come visto nella sezione III, Speed It App sarà composta fondamentalmente da tre applicazioni: Un applicazione web che offra servizi di back-end tramite i quali gestire l intero sistema Speed It App. Un applicazione web dedicata agli organizzatori, che permetta di gestire tutte le informazioni relative agli utenti, dalla registrazione alla coda. Un applicazione mobile dedicata agli organizzatori, che permetta di interagire con la coda di partecipanti durante la fase di registrazione all evento. A. Interfacce grafiche In questa prima fase di implementazione è stato progettato di realizzare tutte le interfacce grafiche del sistema, in alcuni casi prototipi throw-away (applicazioni mobile), in altri casi vere e proprie parti del sistema, che saranno integrate successivamente con il back-end, per far funzionare il tutto. Al fine di rendere l esperienza grafica del sistema uniforme, si è pensato di utilizzare anche per le applicazioni web uno stile simile a quello mobile. In particolare si è scelto di adottare il material design[1], introdotto nell ultima versione di Android[2]. Per rendere il design delle applicazioni web pulito, si è scelto di utilizzare Polymer[3], progetto open-source che si pone l obiettivo di facilitare la creazione di applicazioni web, adattabili sia a desktop, sia a dispositivi mobili di vario genere (da smartphone a tablet). Una delle caratteristiche chiave di Polymer è la possibilità di definire delle componenti web personalizzate, oltre a fornire varie componenti pre-confezionate che implementano il material design. Il concetto di componente web è simile al concetto di classe nell object-oriented programming: trattasi di entità su cui è possibile definire determinate operazioni e che hanno un layout grafico predefinito. Sebbene il concetto di componente web preceda il progetto Polymer[4], quest ultimo definisce dei meccanismi per la definizione di componenti in maniera 9

10 uniforme e semplificata. Oltre alla progettazione grafica di Speed It App, sono state definite alcune componenti web, in alcuni casi riutilizzabili in più contesti: page-visitor: permette di organizzare le liste in pagine, fornisce un navigatore di pagine e definisce alcune animazioni. queue-manager: permette di visualizzare una coda di elementi, definisce un operazione per mostrare il prossimo elemento in coda e definisce le animazioni di transizione. sia-ajax: estende il componente Polymer core-ajax e permette di eseguire chiamate AJAX in maniera semplificata, gestendo automaticamente alcune categorie di errori. B. Back-end Si è scelto di utilizzare Java EE, quindi Apache Tomcat, per il back-end dell applicazione. Questo permetterà di velocizzare l implementazione, data la maggiore esperienza del team con il linguaggio di programmazione Java. Attualmente sono state definite alcune componenti importanti: alcune di esse permetteranno di semplificare la comunicazione tra applicazioni mobili e server, altre permettono di scrivere in maniera automatica alcune parti delle pagine web. In particolare: La classe APIConsumer ha l obiettivo di eseguire chiamate a servizi semplicemente specificandone il nome e i parametri. Sarà necessario specificare un token, da passare per ogni chiamata a servizio al fine di autenticarsi presso il server; questa componente aggiunge automaticamente il token alla lista di parametri, evitando ogni volta una lettura del file di configurazione da parte del chiamante. La classe ConfigManager interpreta il file di configurazione e fornisce metodi per estrarne informazioni. VIII. PIANIFICAZIONE DEL TESTING L obiettivo del processo di testing è verificare il corretto funzionamento di Speed It App in diversi casi, studiati appositamente per mettere alla prova ogni singola funzionalità e caratteristica del sistema, al fine di ottenere un corretto funzionamento. I risultati di questa fase saranno usati per capire dove bisognerà intervenire, e quindi correggere eventuali errori o apportare modifiche per il miglioramento dei vari sottosistemi. il processo sarà iterato fino a che non si otterranno i risultato attesi, in accordo con i tempi di sviluppo previsti. A. Funzionalità da testare Nella fase di testing sono state prese in considerazione tutte le funzionalità di Speed It App. Nello specifico: Visualizzazione iscritti Generazione codice QR Aggiunta e rimozione di code Identificazione tramite codice QR Aggiunta utente unknown alla coda Aggiunta manuale di un utente alla coda Visualizzazione dell ordine di arrivo al desk Eliminazione utenti non registrati Contrassegno di un utente come già servito B. Pass/Fail criteria Il testing ha successo se l output osservato è diverso dall output atteso: ciò signica che la fase di testing avrà successo se individuerà una failure. In tal caso questa verrà analizzata e, se legata ad un fault, si procederà alla sua correzione. Sarà infine iterata la fase di testing per verificare che la modifica non abbia impattato su altri componenti del sistema. Al contrario, il testing fallirà se l output osservato sarà uguale all oracolo. C. Approccio utilizzato Per la selezione dei casi di test di Speed It App è stato scelto il criterio di selezione Category Partition[5], in grado di selezionare un sottoinsieme intelligente di casi di test ottenibili attraverso il criterio SECT (Strong Equivalence Class Testing). Si cercherà di minimizzare le scelte delle categorie, selezionando solo quelle più importanti, al fine di garantire una buona qualità del prodotto e ridurre i costi in termini di tempo, evitando l esplosione combinatorica dei casi di test. Le fasi di testing individuate sono le seguenti: Testing di unità Testing di integrazione Testing funzionale (di sistema) Alpha-testing Testing di accettazione Non è prevista una fase di beta-testing: a causa della natura del sistema, infatti, è difficile organizzare delle sessioni di testing in ambienti non controllati. 1) Testing di unità: In questa fase si controllerà la qualità delle singole parti che compongono il sistema. Per unità si intendono le singole classi del sistema. Verranno generate delle test suite utilizzando JUnit, attraverso le quali si potrà fare facilmente testing di regressione in futuro. 2) Testing di integrazione: Per l integrazione si seguirà la strategia Top-down. Questa permette di trovare subito gli errori nelle interfacce grafiche, spesso le più soggette a problemi di vario genere. I layer individuati sono i seguenti: API Mobile App Web App Verranno creati degli stub che simulino i servizi REST forniti dal layer API. Si testerà prima i layer Mobile App; in seguito si procederà con l integrazione e il testing del layer Web App. 3) Testing funzionale (di sistema): Al fine di verificare che l intero sistema abbia un livello di qualità accettabile, si procederà con il testing dell intero sistema completamente integrato, eseguendo tutti i casi di test individuati. 10

11 4) Alpha-testing: In questa fase si organizzerà una sessione di testing coinvolgendo persone esterne al progetto, le quali proveranno il sistema in un ambiente controllato dal team di sviluppo; quest ultimo, tuttavia, non dovrà poter influire direttamente sulle scelte degli utenti, ma si limiterà ad annotare eventuali problemi, a rispondere alle domande degli utenti, a orchestrare le fasi dell intero processo che si vuole simulare (es: scannerizzazione del QR, organizzazione della coda etc). In questa fase sarà possibile controllare se i requisiti di performance individuati nella fase di analisi dei requisiti sono rispettati. 5) Test di accettazione: In questa fase si farà provare il sistema ai clienti che considerano l opportunità di utilizzare Speed It App, al fine di mostrare le varie fuzionalità e di verificare che il sistema risponda alle esigenze. Si eseguirà una simulazione, come nella fase di alpha-testing. Il cliente avrà la possibilità di orchestrare le varie fasi del processo che si vuole simulare. D. Progettazione di casi di test Nel metodo Category Partition il sistema viene diviso in funzioni che possono essere testate indipendentemente. Il metodo individua i parametri (es. username, password) di ogni funzione e per ogni parametro individua categorie distinte. Oltre ai parametri, possono essere considerati anche gli oggetti d ambiente (variabili globali, database). Le categorie rappresentano le proprietà o caratteristiche principali dei parametri. Le categorie vengono suddivise ulteriormente in scelte, in modo del tutto simile alla partizione in classi di equivalenza. Dopodiché vengono individuati i vincoli che esistono tra le scelte, ossia il modo in cui l occorrenza di una scelta può influenzare l esistenza di un altra scelta. Vengono generati i test frames, che consistono di combinazioni valide di scelte nelle categorie e infine vengono convertiti in test data. L individuazione di parametri, categorie, condizioni d ambiente, dipende fortemente dall esperienza del tester. La tecnica rende le decisioni di testing esplicite e aperte a revisioni. Inoltre aiuta a ridurre i casi di test e rende il testing sistematico e più praticabile.[5] 1) Generazione di casi di test per la funzionalità Riconoscimento ID: La funzionalità di login prevede l input di quattro parametri d ambiente: ID, utente, condizioni esterne e fotocamera scanner. Per il parametro ID sono state individuate le seguenti categorie: Tipo Validità Per il parametro utente è stata individuata: In coda virtuale Per il parametro condizioni esterne è stata individuata l unica categoria: Luminosità Per il parametro fotocamera scanner è stata individuata: Variabile d ambiente Categoria Tipo (rtyp) Validità (rval) Variabile d ambiente Categoria In coda virtuale (uque) Variabile d ambiente Categoria Luminosità (elum) Variabile d ambiente Categoria Messa a fuoco (dfoc) ID Scelta 1. Stampato 2. Su smartphone [property Smartphone] 1. Valido 2. Non valido [error] Utente Scelta 1. Sì [error] 2. No Condizioni esterne Scelta 1. Luce diretta [property del sole HighLight] 2. Luce indiretta [property del sole LowLight] 3. Luce artificiale [property bassa LowLight] 4. Luce artificiale [property alta HighLight] Fotocamera scanner Scelta 1. Automatica [if Smartphone] 2. Manuale [if Smartphone] 3. Nessuna [if Smartphone] Tabella V PROGETTAZIONE DEI CASI DI TEST Codice Combinazione Esito TC 14.1 rtyp1rval1uque1 errore TC 14.2 rtyp1rval1uque2elum1 ok TC 14.3 rtyp1rval1uque2elum2 ok TC 14.4 rtyp1rval1uque2elum3 ok TC 14.5 rtyp1rval1uque2elum4 ok TC 14.6 rtyp1rval2 errore TC 14.7 rtyp2rval1uque1 errore TC 14.8 rtyp2rval1uque2elum1dfoc1 ok TC 14.9 rtyp2rval1uque2elum1dfoc2 ok TC rtyp2rval1uque2elum1dfoc3 ok TC rtyp2rval1uque2elum2dfoc1 ok TC rtyp2rval1uque2elum2dfoc2 ok TC rtyp2rval1uque2elum2dfoc3 ok TC rtyp2rval1uque2elum3dfoc1 ok TC rtyp2rval1uque2elum3dfoc2 ok TC rtyp2rval1uque2elum3dfoc3 ok TC rtyp2rval1uque2elum4dfoc1 ok TC rtyp2rval1uque2elum4dfoc2 ok TC rtyp2rval1uque2elum4dfoc3 ok TC rtyp2rval2 errore Tabella VI GENERAZIONE AUTOMATICA DEL TEST FRAME Messa a fuoco Ognuna di queste categorie è stata suddivisa in scelte, in modo del tutto simile al metodo delle classi di equivalenza. Ad ogni scelta che causa un errore è stata applicata l annotazione speciale [error] (tabella V). La fase successiva consiste generazione automatica dei test frame, ovvero delle combinazioni valide di scelte nelle categorie (tabella VI). 11

12 E. Generazione automatica dei test frame Un apparente problema di fronte al quale ci si è trovati è che i casi di test, dipendendo molto dall esperienza di chi li progetta, possono cambiare, subire revisioni e così via, e quando si modificano le categorie o le scelte è necessario ricreare tutto il test frame. Per risolvere questo problema si è pensato di progettare e realizzare un tool in grado di generare automaticamente i test frame a partire dalla specifica. La possibilità di generare automaticamente i test frame è uno dei vantaggi del Category Partition[5]. Il tool è composto da varie componenti: 1) Parser: prende in input una stringa che contiene la reg: 2 Tipo rtyp: 3 Stampato 4 Su smartphone property:smartphone 5 $end 6 7 àvalidit rval: 8 Valido 9 Non valido error 10 $end 11 $end 12 user: 14 In coda virtuale uque: 15 ìs error 16 No 17 $end specifica del caso di test, la interpreta e definisce tutti i 18 $end parametri, con le relative categorie, scelte, vincoli e condizioni, 19 esterne cest: creando degli oggetti che contengono questi tipi di dati. Nella 21 àluminosit elum: figura 17 è riportato un esempio di specifica. Il linguaggio 22 Luce diretta del sole property:highlight permette di definire tutti gli elementi in questo modo: 23 Luce indiretta del sole property:lowlight 24 Luce artificiale bassa property:lowlight a) Parametri: È necessario che l indentazione sia al livello 0 (niente spazi o tab). Il carattere speciale % indica che 26 $end 25 Luce artificiale alta property:highlight 27 si sta definiendo un parametro, mentre il permette $end 28 di definire variabili d ambiente. Segue il nome del parametro, scanner dscan: separato da un simbolo dal suo nome breve (inutilizzato 30 Messa a fuoco dfoc: 31 attualmente). La dichiarazione deve concludersi con il carattere :. La definizione del parametro deve concludersi con Automatica if:smartphone 32 Manuale if:smartphone 33 Nessuna if:smartphone la parola chiave $end, al livello 0 di indentazione. 34 $end 35 b) Categorie: È necessario che l indentazione sia al livello $end 1 (esattamente 1 tab). Bisogna specificare soltanto il nome della categoria, il suo nome breve e concludere la linea con il Figura 17. Esempio di specifica di caso di test carattere :. La definizione della categoria deve concludersi con la parola chiave $end, al livello 1 di indentazione. c) Scelte: È necessario che l indentazione sia al livello IX. RATIONALE 2 (esattamente 2 tab). La linea è composta dal contenuto della Il team di Speed App It ha sempre dedicato una parte scelta, separato (attraverso il carattere ) da proprietà e dell effort complessivo per lo sviluppo dei propri progetti alla condizioni, separate tra di loro dal carattere. gestione del razionale. Si è fortemente convinti che si tratti di d) Proprietà: Si usa la parola chiave property, seguita uno strumento di incredibile valore a supporto di tutto il ciclo da : e dal nome della proprietà che si vuole aggiungere. di vita di un progetto software. e) Condizioni: Si usa la parola chiave if, seguita da Il razionale è la motivazione delle decisioni effettuate. Tenta : e dalla condizione che si vuole testare. di catturare il processo decisionale alle spalle di qualsiasi f) Errori: Si usa semplicemente la parola chiave error. 2) Generatore di combinazioni: prende in input un array di parametri, dato in output dal parser e dà in output una array di combinazioni generate. Il generatore inizialmente definisce un albero delle scelte i cui percorsi rappresentano tutte le possibili combinazioni (SECT). In seguito fa una visita in profondità scelta. Il suo modello presenta le ragioni che hanno guidato la realizzazione di un sistema, incluse le sue funzionalità e la sua implementazione. Il razionale è critico in due aree: supporto alle decisioni e supporto alla cattura della conoscenza. Il processo di razionale va a tracciare gli elementi del processo di decisione, ossia: e utilizza proprietà, errori e condizioni per estrarre solo le Issue, un problema o una domanda che richiede una combinazioni lecite. discussione per il problema sollevato. 3) Generatore L A TEX: prende in input un array di combinazioni, dato in output dal generatore di combinazioni, e un array Alternative (o position), possibile soluzione che risolve il problema che ci si è posti. di parametri, dato in output dal parser, e dà in output codice L A TEX per definire le tabelle dei test frame e delle specifiche. Dato che tutta la documentazione del progetto è stata prodotta in L A TEX, questa componente ha permesso di automatizzare Criteria, qualità desiderabili che una soluzione dovrebbe soddisfare. Argumentation, ovvero uno statement che supporta una posizione o una qualsiasi altra componente. al 100% la generazione delle tabelle del Test Plan, grazie ad ulteriori script. Decision, la soluzione a una issue rappresentata dall alternativa scelta in accordo ai criteri di valutazione usati 12

13 per la valutazioni, la selezione e la giustificazione per la stessa. A. Il Framework IBIS Si è scelto di utilizzare il framework IBIS (Issue Based Information System), ossia una tecnica di visualizzazione argument based sviluppata nei primi anni 70 [6]. IBIS è famoso per il suo utilizzo nella mappatura del dialogo e per fornire un approccio collaborativo alla risoluzione dei problemi. Il nucleo originario di IBIS consiste in tre elementi principali: 1) Issues (o questions): ossia problemi che devono essere risolti. 2) Positions (o idee): risposte alle issues. In generale l insieme delle positions a una issue rappresenta l insieme dei punti di vista rispetto un possibile problema. 3) Arguments: possono essere a favore o contro una position o una issue. L intero set di argomentazioni che risponde a una idea rappresenta l insieme dei molteplici punti di vista su esso. Nome Node Icon Description Question Answer Pro Con Decision Argument Domanda o issue Fornisce una possibile risposta a una domanda Supporta un idea Argomentazione contro un idea Risolve una questione associandola ad un idea Fornisce una argomentazione di carattere generale, usualmente in risposta a una position Tabella VII NODI STANDARD strategia di risoluzione dei conflitti. Tra le diverse strategie si è scelto di adottare la Management is always right inteso come l intervento dei tutor Andrea De Lucia e Filomena Ferrucci nel processo decisionale. Figura 18. Il modello IBIS rappresentato con un UML class diagram Successivamente sono stati introdotti nel framework i criterion, ossia le qualità desiderabili che una position dovrebbe avere, e le resolution ovvero l alternativa selezionata per una issue. La grammatica del framework IBIS può essere schematizzata in una serie di semplici regole. Una issue può essere sollevata o nascere da qualsiasi altra issue, position o argument. In altre parole, ogni elemento di IBIS può essere soggetto a una nuova questione. Una idea può rispondere solamente ad una questione. Gli arguments invece possono essere associati unicamente ad una idea. B. Compendium La scelta del tool per la gestione del Rationale è ricaduta su CompendiumLD. Esso include un set di nodi ed icone facilmente utilizzabili per l issue mapping, per il management degli stessi e per il tracciamento di action item e issue. Fornisce inoltre una serie di mezzi predefiniti per il mapping di attività di learning. Di seguito, nella tabella VII sono descritti i nodi principali per l utilizzo del tool in questione. C. Strategia di risoluzione dei conflitti Occasionalmente, qualora non fosse possibile per i partecipanti al progetto raggiungere un consenso riguardante una issue attraverso la negoziazione, è necessario stabilire una D. Contenuto del documento Il documento di Rationale è stato redatto in maniera molto snella ed agile. In esso vi sono integrati come appositi capitoli i documenti di Requirements Analysis Rationale e System Design Rationale. La motivazione di tale scelta risiede nella considerazione che, trattandosi di un progetto di dimensioni modeste, è parso ridondante produrre più documenti di rationale. Dunque il risultato finale è articolato in tre capitoli: 1) Introduzione, nel quale viene descritto il framework scelto, i tool da utilizzare nonché la strategia di risoluzione dei conflitti adottata; 2) Requirements Analysis Rationale Document, nel quale confluiscono i processi decisionali riguardanti la fase di specifica ed analisi dei requisiti. 3) Rationale per proposed software architecture nel quale vengono esplicitate le scelte di design del sistema. Per quanto riguarda la preliminare analisi di requirements rationale, il primo processo decisionale affrontato e modellato all interno del documento è stata la scelta del modello del ciclo di vita del software. Le alternative proposte sono state le seguenti: modello a cascata, modello a spirale o una qualunque metodologia agile da scegliere successivamente. Nelle prime fasi di discussione, a causa dei stringenti tempi di sottomissione, ci si è inizialmente orientati verso modelli focalizzati principalmente sullo sviluppo, i quali avrebbero permesso la realizzazione del sistema in tempi rapidi alleggerendo l effort 13

14 per la produzione di documentazione tecnica. Tuttavia l utilizzo di una metodologia agile ci è parso rischioso in quanto nessun elemento del team ha esperienza nell utilizzo di tali tecniche. Migrando quindi verso metodiche più familiari al team di sviluppo, ci si è orientati sul modello a spirale in quanto esso consente una gestione esplicita dei rischi, a fronte soprattutto del lavoro in un dominio applicativo di cui abbiamo scarsa conoscenza. Sempre per tale motivo tale modello consente una revisione continua da parte dei nostri tutor del lavoro svolto. Il processo di razionale alla base di questa scelta è descritto in figura 19. Figura 20. DBMS relazionale: Resolution Figura 19. Modello a spirale: Resolution Un ulteriore processo decisionale importante affrontato riguarda la gestione dei dati persistenti ed in particolare la scelta del DBMS. Le alternative considerate vertevano tra un DBMS relazionale classico e uno di tipo NoSQL orientato ai documenti. Analizzando il dominio applicativo di SpeedItApp si è osservata la mancanza di query complesse e di numerose operazioni di join. La natura stessa delle informazioni utilizzate dal nostro sistema non incoraggiava la scelta e l utilizzo di una base di dati così rigida e strutturata come quella di tipo relazionale. Un database NoSQL orientato ai documenti ci avrebbe permesso oltretutto di sviluppare un sistema più leggero e performante. Tutte queste considerazioni, unitamente alla curva di apprendimento molto rapida caratteristica di queste basi di dati, ci hanno portato alla scelta di MongoDB come DBMS utilizzato da SpeedItApp. Tutto il processo relazionale sin qui descritto è mappato in figura 20. X. GESTIONE DELLE VERSIONI La realizzazione collaborativa di un progetto può essere molto complessa se non si scelgono i tool adatti. In questo caso si è deciso di fare delle scelte mirate, al fine di tenere traccia dei cambiamenti e di evitare problemi dovuti alla modifica contemporanea di alcuni file. Per gestire tutti gli artefatti software è stato utilizzato il sistema di versioning Git. La scelta è ricaduta su questo sistema perché il team di sviluppo ha più esperienza con esso rispetto ad altri strumenti simili. L utilizzo di Git, come già accennato in precedenza, non si è limitato al solo codice sorgente, ma è stato esteso anche alla documentazione. Poiché questi sistemi sono efficaci solo su file di tipo testuale, si è scelto di utilizzare L A TEX per la compilazione dei documenti, cercando di dividere ogni singolo documento in più file, in base alle sezioni logiche di cui è composto. In questo modo si sono ridotti al minimo i conflitti dovuti a commit contemporanei di più membri del team, poiché si lavorava sempre su file diversi, anche se si doveva compilare lo stesso documento. XI. RISULTATI RAGGIUNTI I deliverable prodotti e consegnati insieme a questa relazione sono: Requirement Analysis Document System Design Document Object Design Document Test Plan Design Rationale Document Implementazione dell interfaccia grafica della web app dedicata agli organizzatori Implementazione dell interfaccia grafica del sito web dedicato ai partecipanti Tool per la generazione automatica di casi di test a partire dalle specifiche (Category Partition) Le scadenze che si erano individuate in fase di pianificazione sono state tutte, grossomodo, rispettate. I criteri di qualità, 14

15 allo stato attuale, sono stati rispettati, sia per quanto riguarda la documentazione, sia la parte di implementazione fornita. XII. CONCLUSIONI Si è presentato in questa relazione il progetto Speed It App. Il sistema prodotto consentirà di velocizzare il processo di registrazione ad eventi quali conferenze scientifiche, convegni, concerti e così via. Utilizzando un modello di ciclo di vita del software iterativo ed incrementale è stato possibile rilasciare una parte del sistema e buona parte della documentazione. Oltre alla comune documentazione di un progetto software, è stato scritto anche un Design Rationale Document, nel quale sono state mappate tutte le scelte prese e grazie al quale sarà possibile, in futuro, comprendere i motivi di determinate decisioni. La pianificazione del testing è passata anche per la realizzazione di un tool per la generazione automatica di casi di test a partire dalla loro specifica, che ha permesso di risparmiare una notevole quantità di tempo. RIFERIMENTI BIBLIOGRAFICI [1] [Online]. Available: [2] [Online]. Available: [3] [Online]. Available: [4] [Online]. Available: [5] T. J. Ostrand and M. J. Balcer, The category-partition method for specifying and generating fuctional tests, Communications of the ACM, vol. 31, no. 6, pp , [6] H. W. R. W.Kunz, Issue as elements of information system,