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

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "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: https://www.polymer-project.org/ [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,

Università degli Studi di Salerno GPS: Gestione Progetti Software. Project Proposal Versione 1.1

Università degli Studi di Salerno GPS: Gestione Progetti Software. Project Proposal Versione 1.1 Università degli Studi di Salerno GPS: Gestione Progetti Software Project Proposal Versione 1.1 Data 27/03/2009 Project Manager: D Amato Angelo 0521000698 Partecipanti: Nome Andrea Cesaro Giuseppe Russo

Dettagli

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test

Verifica e Validazione (V & V) Software e difetti. Processo di V & V. Test Software e difetti Il software con difetti è un grande problema I difetti nel software sono comuni Come sappiamo che il software ha qualche difetto? Conosciamo tramite qualcosa, che non è il codice, cosa

Dettagli

Università degli Studi di Salerno Ingegneria del Software: Tecniche Avanzate

Università degli Studi di Salerno Ingegneria del Software: Tecniche Avanzate Università degli Studi di Salerno Ingegneria del Software: Tecniche Avanzate Mystic Pizza Gestione Pizzeria Scheda di Progetto Version 1.0 Data 19/03/2007 Indice degli argomenti 1. Introduzione 3 a. Scenario

Dettagli

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. L altra strada per il BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio L altra strada per il BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 Il BPM Il BPM (Business Process Management) non è solo una tecnologia, ma più a grandi linee una disciplina

Dettagli

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in

Gestione Requisiti. Ingegneria dei Requisiti. Requisito. Tipi di Requisiti e Relativi Documenti. La gestione requisiti consiste in Ingegneria dei Requisiti Il processo che stabilisce i servizi che il cliente richiede I requisiti sono la descrizione dei servizi del sistema Funzionalità astratte che il sistema deve fornire Le proprietà

Dettagli

SDD System design document

SDD System design document UNIVERSITA DEGLI STUDI DI PALERMO FACOLTA DI INGEGNERIA CORSO DI LAUREA IN INGEGNERIA INFORMATICA TESINA DI INGEGNERIA DEL SOFTWARE Progetto DocS (Documents Sharing) http://www.magsoft.it/progettodocs

Dettagli

Ciclo di Vita Evolutivo

Ciclo di Vita Evolutivo Ciclo di Vita Evolutivo Prof.ssa Enrica Gentile a.a. 2011-2012 Modello del ciclo di vita Stabiliti gli obiettivi ed i requisiti Si procede: All analisi del sistema nella sua interezza Alla progettazione

Dettagli

Il diagramma dei casi d uso

Il diagramma dei casi d uso Il diagramma dei casi d uso Laboratorio di Ingegneria del Software Prof. Paolo Ciancarini Dott. Sara Zuppiroli A.A. 2010/2011 Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011

Dettagli

Una soluzione per la gestione del packaging online

Una soluzione per la gestione del packaging online Una soluzione per la gestione del packaging online WebCenter WebCenter è un efficiente piattaforma web per la gestione del packaging, dei processi aziendali, dei cicli di approvazione e delle risorse digitali.

Dettagli

UBIQUITY 6 e Server. Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity.

UBIQUITY 6 e Server. Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity. UBIQUITY 6 e Server Privato Introduzione Il documento descrive le novità introdotte con la versione 6 della piattaforma software ASEM Ubiquity. Versione Descrizione Data 1 Prima emissione 21/06/2015 Disclaimer

Dettagli

Scope Management. IT Project Management. Lezione 3 Scope Management. Monitoring del progetto (Earned Value) Creazione diagrammi Pert/CPM/Gantt

Scope Management. IT Project Management. Lezione 3 Scope Management. Monitoring del progetto (Earned Value) Creazione diagrammi Pert/CPM/Gantt IT Project Management Lezione 3 Scope Management Federica Spiga A.A. 2009-2010 1 Check list del PM Identificare i requisiti del cliente Monitoring del progetto (Earned Value) Identificare i deliverable

Dettagli

Gestione parte IIC. Diagrammi di Gantt. Esempio. Schemi di scomposizione delle attività

Gestione parte IIC. Diagrammi di Gantt. Esempio. Schemi di scomposizione delle attività Schemi di scomposizione delle attività Gestione parte IIC Work Breakdown Structures (WBS) Struttura ad albero: radice: attività principale i nodi figli rappresentano la scomposizione del nodo padre le

Dettagli

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI

Dettagli

Programmazione Java Avanzata

Programmazione Java Avanzata Programmazione Java Avanzata Accesso ai Dati Ing. Giuseppe D'Aquì Testi Consigliati Eclipse In Action Core J2EE Patterns - DAO [http://java.sun.com/blueprints/corej2eepatterns/patterns/dataaccessobject.html]

Dettagli

Software project management. www.vincenzocalabro.it

Software project management. www.vincenzocalabro.it Software project management Software project management Sono le attività necessarie per assicurare che un prodotto software sia sviluppato rispettando le scadenze fissate rispondendo a determinati standard

Dettagli

Concetti base. Impianti Informatici. Web application

Concetti base. Impianti Informatici. Web application Concetti base Web application La diffusione del World Wide Web 2 Supporto ai ricercatori Organizzazione documentazione Condivisione informazioni Scambio di informazioni di qualsiasi natura Chat Forum Intranet

Dettagli

Novità di Visual Studio 2008

Novità di Visual Studio 2008 Guida al prodotto Novità di Visual Studio 2008 Introduzione al sistema di sviluppo di Visual Studio Visual Studio Team System 2008 Visual Studio Team System 2008 Team Foundation Server Visual Studio Team

Dettagli

DD - Design Document

DD - Design Document Politecnico di Milano Progetto di Ingegneria del Software 2 DD - Design Document Autori: Claudia Foglieni Giovanni Matteo Fumarola Massimo Maggi Professori: Elisabetta Di Nitto Raffaela Mirandola 1 gennaio

Dettagli

UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTA DI INGEGNERIA DIPARTIMENTO DI SISTEMI E INFORMATICA. Elaborato di Tecnologie del Software per Internet

UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTA DI INGEGNERIA DIPARTIMENTO DI SISTEMI E INFORMATICA. Elaborato di Tecnologie del Software per Internet UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTA DI INGEGNERIA DIPARTIMENTO DI SISTEMI E INFORMATICA Elaborato di Tecnologie del Software per Internet JMSWEB 2 SISTEMA PER LO SCAMBIO DI MESSAGGI TRA APPLICAZIONI

Dettagli

SUITE SISTEMI. la suite di soluzioni dedicate all ufficio Sistemi Informativi. White Paper

SUITE SISTEMI. la suite di soluzioni dedicate all ufficio Sistemi Informativi. White Paper SUITE SISTEMI la suite di soluzioni dedicate all ufficio Sistemi Informativi White Paper Introduzione Suite Sistemi è un pacchetto di soluzioni per la gestione di tutte le attività che coinvolgono l ufficio

Dettagli

Corso di Informatica Modulo T3 B1 Programmazione web

Corso di Informatica Modulo T3 B1 Programmazione web Corso di Informatica Modulo T3 B1 Programmazione web 1 Prerequisiti Architettura client/server Elementi del linguaggio HTML web server SQL server Concetti generali sulle basi di dati 2 1 Introduzione Lo

Dettagli

Single Sign On sul web

Single Sign On sul web Single Sign On sul web Abstract Un Sigle Sign On (SSO) è un sistema di autenticazione centralizzata che consente a un utente di fornire le proprie credenziali una sola volta e di accedere a molteplici

Dettagli

UML e (R)UP (an overview)

UML e (R)UP (an overview) Lo sviluppo di sistemi OO UML e (R)UP (an overview) http://www.rational.com http://www.omg.org 1 Riassumento UML E un insieme di notazioni diagrammatiche che, utilizzate congiuntamente, consentono di descrivere/modellare

Dettagli

LA TEMATICA. Questa situazione si traduce facilmente:

LA TEMATICA. Questa situazione si traduce facilmente: IDENTITY AND ACCESS MANAGEMENT: LA DEFINIZIONE DI UN MODELLO PROCEDURALE ED ORGANIZZATIVO CHE, SUPPORTATO DALLE INFRASTRUTTURE, SIA IN GRADO DI CREARE, GESTIRE ED UTILIZZARE LE IDENTITÀ DIGITALI SECONDO

Dettagli

Base Dati Introduzione

Base Dati Introduzione Università di Cassino Facoltà di Ingegneria Modulo di Alfabetizzazione Informatica Base Dati Introduzione Si ringrazia l ing. Francesco Colace dell Università di Salerno Gli archivi costituiscono una memoria

Dettagli

TEORIA sulle BASI DI DATI

TEORIA sulle BASI DI DATI TEORIA sulle BASI DI DATI A cura del Prof. Enea Ferri Cos è un DATA BASE E un insieme di archivi legati tra loro da relazioni. Vengono memorizzati su memorie di massa come un unico insieme, e possono essere

Dettagli

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione

Processi (di sviluppo del) software. Fase di Analisi dei Requisiti. Esempi di Feature e Requisiti. Progettazione ed implementazione Processi (di sviluppo del) software Fase di Analisi dei Requisiti Un processo software descrive le attività (o task) necessarie allo sviluppo di un prodotto software e come queste attività sono collegate

Dettagli

Sondaggi OnLine. Documento Tecnico. Descrizione delle funzionalità del servizio

Sondaggi OnLine. Documento Tecnico. Descrizione delle funzionalità del servizio Documento Tecnico Sondaggi OnLine Descrizione delle funzionalità del servizio Prosa S.r.l. - www.prosa.com Versione documento: 1, del 30 Maggio 2005. Redatto da: Michela Michielan, michielan@prosa.com

Dettagli

Obiettivi d esame PHP Developer Fundamentals on MySQL Environment

Obiettivi d esame PHP Developer Fundamentals on MySQL Environment Obiettivi d esame PHP Developer Fundamentals on MySQL Environment 1.0 Ambiente di sviluppo 1.1 Web server e database MySQL Comprendere la definizione dei processi che si occupano di fornire i servizi web

Dettagli

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software.

Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica. Ingegneria del Software. Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software La fase di Test Giulio Destri Ing. del Software: Test - 1 Scopo del modulo Definire

Dettagli

BOARD 8.1: Cosa c è di nuovo

BOARD 8.1: Cosa c è di nuovo Better decisions. Better business. BOARD 8.1: Cosa c è di nuovo Mobile Business Intelligence nativa, miglior supporto per le grandi implementazioni e nuove funzionalità di Performance Management portano

Dettagli

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE I.C.T. Information and Communication Technology TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE

Dettagli

Manuale di Integrazione IdM-RAS

Manuale di Integrazione IdM-RAS IdM-RAS Data: 30/11/09 File: Manuale di integrazione IdM-RAS.doc Versione: Redazione: Sardegna IT IdM-RAS Sommario 1 Introduzione... 3 2 Architettura del sistema... 4 2.1 Service Provider... 4 2.2 Local

Dettagli

DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER

DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER DATABASE IN RETE E PROGRAMMAZIONE LATO SERVER L architettura CLIENT SERVER è l architettura standard dei sistemi di rete, dove i computer detti SERVER forniscono servizi, e computer detti CLIENT, richiedono

Dettagli

Metodologia TenStep. Maggio 2014 Vito Madaio - TenStep Italia

Metodologia TenStep. Maggio 2014 Vito Madaio - TenStep Italia Metodologia TenStep Maggio 2014 Vito Madaio - TenStep Italia Livello di Complessità Processo di Project Management TenStep Pianificare il Lavoro Definire il Lavoro Sviluppare Schedulazione e Budget Gestire

Dettagli

La gestione dei progetti informatici

La gestione dei progetti informatici Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Ingegneria del Software La gestione dei progetti informatici Giulio Destri Ing. del Sw: Gestione - 1 Scopo

Dettagli

SWIM v2 Design Document

SWIM v2 Design Document PROGETTO DI INGEGNERIA DEL SOFTWARE 2 SWIM v2 DD Design Document Matteo Danelli Daniel Cantoni 22 Dicembre 2012 1 Indice Progettazione concettuale Modello ER Entità e relazioni nel dettaglio User Feedback

Dettagli

REPERTORIO DELLE QUALIFICAZIONI PROFESSIONALI DELLA REGIONE CAMPANIA

REPERTORIO DELLE QUALIFICAZIONI PROFESSIONALI DELLA REGIONE CAMPANIA REPERTORIO DELLE QUALIFICAZIONI PROFESSIONALI DELLA REGIONE CAMPANIA SETTORE ECONOMICO PROFESSIONALE 1 SETTORE MECCANICA;PRODUZIONE E MANUTENZIONE DI MACCHINE;IMPIANTISTICA Processo Lavorazioni aeronautiche

Dettagli

Principi dell ingegneria del software Relazioni fra

Principi dell ingegneria del software Relazioni fra Sommario Principi dell ingegneria del software Leggere Cap. 3 Ghezzi et al. Principi dell ingegneria del software Relazioni fra Principi Metodi e tecniche Metodologie Strumenti Descrizione dei principi

Dettagli

Brochure Internet. Versione 2010.1 The Keyrules Company s.r.l. Pagina 2 di 8

Brochure Internet. Versione 2010.1 The Keyrules Company s.r.l. Pagina 2 di 8 Ogni organizzazione possiede un sistema di regole che la caratterizzano e che ne assicurano il funzionamento. Le regole sono l insieme coordinato delle norme che stabiliscono come deve o dovrebbe funzionare

Dettagli

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali

Considera tutti i requisiti funzionali (use cases) NON deve necessariamente modellare i requisiti non funzionali Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Progettazione OO E. TINELLI Punto di Partenza Il modello di analisi E una rappresentazione minima del

Dettagli

5. Requisiti del Software II

5. Requisiti del Software II 5. Requisiti del Software II Come scoprire cosa? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 5. Requisiti del Software II 1 / 22 Sommario 1 Generalità

Dettagli

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi

Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI. Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Sistemi Informativi DERIVAZIONE DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti Assembly Lines Esercizi Obiettivi Nelle lezioni precedenti abbiamo descritto come modellare i requisiti funzionali

Dettagli

Rational Unified Process Introduzione

Rational Unified Process Introduzione Rational Unified Process Introduzione G.Raiss - A.Apolloni - 4 maggio 2001 1 Cosa è E un processo di sviluppo definito da Booch, Rumbaugh, Jacobson (autori dell Unified Modeling Language). Il RUP è un

Dettagli

Sistemi Informativi Distribuiti

Sistemi Informativi Distribuiti Corso di Laurea Magistrale in Ingegneria Gestionale Corso di Sistemi Informativi Modulo II A. A. 2013-2014 SISTEMI INFORMATIVI MODULO II Sistemi Informativi Distribuiti 1 Sistemi informativi distribuiti

Dettagli

Centro Nazionale per l Informatica nella Pubblica Amministrazione. Gara a procedura aperta n. 1/2007. per l appalto dei

Centro Nazionale per l Informatica nella Pubblica Amministrazione. Gara a procedura aperta n. 1/2007. per l appalto dei Centro Nazionale per l Informatica nella Pubblica Amministrazione Gara a procedura aperta n. 1/2007 per l appalto dei Servizi di rilevazione e valutazione sullo stato di attuazione della normativa vigente

Dettagli

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi Università di Bergamo Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica INGEGNERIA DEL SOFTWARE Prof. Paolo Salvaneschi 1 Obiettivi Scopi del corso: - Fornire gli elementi di base della disciplina,

Dettagli

Pieces of Technology at your service. dottesttm

Pieces of Technology at your service. dottesttm Pieces of Technology at your service dottesttm DOTNET - AUTOMATIZZAZIONE DELL ANALISI STATICA, CODE REVIEW, TEST UNIT dottest è una soluzione di test di sviluppo integrato per automatizzare una vasta gamma

Dettagli

RenderCAD S.r.l. Formazione

RenderCAD S.r.l. Formazione Corso Descrizione La durata di questo corso è complessivamente di ore 150 di cui 85 ore di teoria, 35 ore di pratica e 30 ore di stage in azienda. Nel nostro territorio esiste una richiesta di tale figura,

Dettagli

SCP: SCHEDULER LAYER. a cura di. Alberto Boccato

SCP: SCHEDULER LAYER. a cura di. Alberto Boccato SCP: SCHEDULER LAYER a cura di Alberto Boccato PREMESSA: Negli ultimi tre anni la nostra scuola ha portato avanti un progetto al quale ho partecipato chiamato SCP (Scuola di Calcolo Parallelo). Di fatto

Dettagli

Processi principali per il completamento del progetto

Processi principali per il completamento del progetto Piano di progetto È un documento versionato, redatto dal project manager per poter stimare realisticamente le risorse, i costi e i tempi necessari alla realizzazione del progetto. Il piano di progetto

Dettagli

Nuvola It Data Space

Nuvola It Data Space MANUALE UTENTE INDICE 1. Descrizione servizio... 3 1.1. Informazioni sul servizio di Telecom Italia... 3 1.2. Ruoli e Autenticazione per il servizio di Telecom Italia... 3 1.3. Strumenti... 5 1.4. Documentazione...

Dettagli

Object-Relational Mapping

Object-Relational Mapping Object-Relational Mapping Versione Preliminare Antonella Poggi Dipartimento di informatica e Sistemistica Sapienza Università di Roma Progetto di Applicazioni Software Anno accademico 2008-2009 Questi

Dettagli

Turbodoc. Archiviazione Ottica Integrata

Turbodoc. Archiviazione Ottica Integrata Turbodoc Archiviazione Ottica Integrata Archiviazione Ottica... 3 Un nuovo modo di archiviare documenti, dei e immagini... 3 I moduli di TURBODOC... 4 Creazione dell armadio virtuale... 5 Creazione della

Dettagli

Introduzione a Oracle 9i

Introduzione a Oracle 9i Introduzione a Oracle 9i Ing. Vincenzo Moscato - Overview sull architettura del DBMS Oracle 9i L architettura di Oracle 9i si basa sul classico paradigma di comunicazione client-server, in cui sono presenti

Dettagli

Soluzioni di strong authentication per il controllo degli accessi

Soluzioni di strong authentication per il controllo degli accessi Abax Bank Soluzioni di strong authentication per il controllo degli accessi Allegato Tecnico Milano Hacking Team S.r.l. http://www.hackingteam.it Via della Moscova, 13 info@hackingteam.it 20121 MILANO

Dettagli

Programmazione Java Avanzata

Programmazione Java Avanzata Programmazione Java Avanzata Librerie fondamentali Ing. Giuseppe D'Aquì Testi Consigliati Eclipse in Action (David Gallardo, Ed Burnette and Robert McGovern), Manning (2003) JUnit Cookbook [http://junit.sourceforge.net/doc/cookbook/cookbook.htm]

Dettagli

Gestire un progetto di introduzione di sistemi informativi di SCM. 1 Marco Bettucci Gestione della produzione II - LIUC

Gestire un progetto di introduzione di sistemi informativi di SCM. 1 Marco Bettucci Gestione della produzione II - LIUC Gestire un progetto di introduzione di sistemi informativi di SCM 1 Che cos è un progetto? Una serie complessa di attività in un intervallo temporale definito... finalizzate al raggiungimento di obiettivi

Dettagli

Sistemi Informativi e WWW

Sistemi Informativi e WWW Premesse Sistemi Informativi e WWW WWW: introduce un nuovo paradigma di diffusione (per i fornitori) e acquisizione (per gli utilizzatori) delle informazioni, con facilità d uso, flessibilità ed economicità

Dettagli

Cultura Tecnologica di Progetto

Cultura Tecnologica di Progetto Cultura Tecnologica di Progetto Politecnico di Milano Facoltà di Disegno Industriale - DATABASE - A.A. 2003-2004 2004 DataBase DB e DataBase Management System DBMS - I database sono archivi che costituiscono

Dettagli

Configuratore di Prodotto Diapason

Configuratore di Prodotto Diapason Configuratore di Prodotto Diapason Indice Scopo di questo documento...1 Perché il nuovo Configuratore di Prodotto...2 Il configuratore di prodotto...3 Architettura e impostazione tecnica...5 Piano dei

Dettagli

EXPLOit Content Management Data Base per documenti SGML/XML

EXPLOit Content Management Data Base per documenti SGML/XML EXPLOit Content Management Data Base per documenti SGML/XML Introduzione L applicazione EXPLOit gestisce i contenuti dei documenti strutturati in SGML o XML, utilizzando il prodotto Adobe FrameMaker per

Dettagli

UNIVERSITÀ DEGLI STUDI DI SALERNO

UNIVERSITÀ DEGLI STUDI DI SALERNO UNIVERSITÀ DEGLI STUDI DI SALERNO Ingegneria del Software SYSTEM DESIGN DOCUMENT ANNO ACCADEMICO 2015/2016 Versione 2.3 Top Manager: Nome Prof. De Lucia Andrea Project Manager: Nome Matricola De Chiara

Dettagli

Vodafone Device Manager. La soluzione Vodafone per gestire Smartphone e Tablet aziendali in modo semplice e sicuro

Vodafone Device Manager. La soluzione Vodafone per gestire Smartphone e Tablet aziendali in modo semplice e sicuro La soluzione Vodafone per gestire Smartphone e Tablet aziendali in modo semplice e sicuro In un mondo in cui sempre più dipendenti usano smartphone e tablet per accedere ai dati aziendali, è fondamentale

Dettagli

Il catalogo MANAGEMENT Si rivolge a: Imprenditori con responsabilità diretta. Quadri sulla gestione

Il catalogo MANAGEMENT Si rivolge a: Imprenditori con responsabilità diretta. Quadri sulla gestione 6 Il catalogo MANAGEMENT Si rivolge a: Imprenditori con responsabilità diretta Quadri sulla gestione Impiegati con responsabilità direttive Dirigenti di imprese private e organizzazioni pubbliche, interessati

Dettagli

SISTEMI E RETI. Crittografia. Sistemi distribuiti e configurazione architetturale delle applicazioni WEB.

SISTEMI E RETI. Crittografia. Sistemi distribuiti e configurazione architetturale delle applicazioni WEB. SISTEMI E RETI Crittografia. Sistemi distribuiti e configurazione architetturale delle applicazioni WEB. CRITTOGRAFIA La crittografia è una tecnica che si occupa della scrittura segreta in codice o cifrata

Dettagli

2009. STR S.p.A. u.s. Tutti i diritti riservati

2009. STR S.p.A. u.s. Tutti i diritti riservati 2009. STR S.p.A. u.s. Tutti i diritti riservati Sommario COME INSTALLARE STR VISION CPM... 3 Concetti base dell installazione Azienda... 4 Avvio installazione... 4 Scelta del tipo Installazione... 5 INSTALLAZIONE

Dettagli

SPIKE APPLICATION SECURITY: SICUREZZA DIRETTAMENTE ALL INTERNO DEL CICLO DI VITA DEL SOFTWARE

SPIKE APPLICATION SECURITY: SICUREZZA DIRETTAMENTE ALL INTERNO DEL CICLO DI VITA DEL SOFTWARE SPIKE APPLICATION SECURITY: SICUREZZA DIRETTAMENTE ALL INTERNO DEL CICLO DI VITA DEL SOFTWARE La sicurezza delle applicazioni web si sposta a un livello più complesso man mano che il Web 2.0 prende piede.

Dettagli

La Document Orientation. Come implementare un interfaccia

La Document Orientation. Come implementare un interfaccia La Document Orientation Come implementare un interfaccia Per eliminare l implementazione di una interfaccia da parte di una classe o documento, occorre tirarla su di esso tenendo premuto il tasto ctrl.

Dettagli

Privacy Policy e utilizzo dei cookie.

Privacy Policy e utilizzo dei cookie. Privacy Policy e utilizzo dei cookie. Privacy Policy Informativa resa ai sensi dell articolo 13 del D.lgs. n.196/2003 ai visitatori del sito di Hakomagazine e fruitori dei servizi offerti dallo stesso,

Dettagli

Ingegneria del Software Requisiti e Specifiche

Ingegneria del Software Requisiti e Specifiche Ingegneria del Software Requisiti e Specifiche Obiettivi. Affrontare i primi passi della produzione del software: la definizione dei requisiti ed il progetto architetturale che porta alla definizione delle

Dettagli

Indice. 1.13 Configurazione di PHP 26 1.14 Test dell ambiente di sviluppo 28

Indice. 1.13 Configurazione di PHP 26 1.14 Test dell ambiente di sviluppo 28 Indice 25 184 Introduzione XI Capitolo 1 Impostazione dell ambiente di sviluppo 2 1.1 Introduzione ai siti Web dinamici 2 1.2 Impostazione dell ambiente di sviluppo 4 1.3 Scaricamento di Apache 6 1.4 Installazione

Dettagli

IL PROCESSO TECNICO DI PIANIFICAZIONE: TECNICHE DI SCOMPOSIZIONE DI UN PROJECT (WBS) LABORATORIO INTEGRATO DI COSTRUZIONE E PRODUZIONE LEZIONE 3

IL PROCESSO TECNICO DI PIANIFICAZIONE: TECNICHE DI SCOMPOSIZIONE DI UN PROJECT (WBS) LABORATORIO INTEGRATO DI COSTRUZIONE E PRODUZIONE LEZIONE 3 IL PROCESSO TECNICO DI PIANIFICAZIONE: TECNICHE DI SCOMPOSIZIONE DI UN PROJECT (WBS) IL PROCESSO TECNICO DI PIANIFICAZIONE Un progetto è un insieme complesso di numerose attività finalizzate al raggiungimento

Dettagli

Attività: 3.d Test e sperimentazione

Attività: 3.d Test e sperimentazione UNIONE EUROPEA FONDO EUROPEO DI SVILUPPO REGIONALE. REGIONE PUGLIA AREA POLITICHE PER LO SVILUPPO, IL LAVORO E L INNOVAZIONE "Living Labs Smartpuglia 2020" P.O. FESR Puglia 2007-13 - Asse I - Linea di

Dettagli

Web Programming Specifiche dei progetti

Web Programming Specifiche dei progetti Web Programming Specifiche dei progetti Paolo Milazzo Anno Accademico 2010/2011 Argomenti trattati nel corso Nel corso di Web Programming sono state descritti i seguenti linguaggi (e tecnologie): HTML

Dettagli

Manuale LiveBox WEB AMMINISTRATORE DI SISTEMA. http://www.liveboxcloud.com

Manuale LiveBox WEB AMMINISTRATORE DI SISTEMA. http://www.liveboxcloud.com 2015 Manuale LiveBox WEB AMMINISTRATORE DI SISTEMA http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi

Dettagli

ALLEGATO 13.2 - Esempio di questionario per la comprensione e valutazione del sistema IT

ALLEGATO 13.2 - Esempio di questionario per la comprensione e valutazione del sistema IT ALLEGATO 13.2 - Esempio di questionario per la comprensione e valutazione del sistema IT Premessa L analisi del sistema di controllo interno del sistema di IT può in alcuni casi assumere un livello di

Dettagli

LBINT. http://www.liveboxcloud.com

LBINT. http://www.liveboxcloud.com 2014 LBINT http://www.liveboxcloud.com LiveBox Srl non rilascia dichiarazioni o garanzie in merito al contenuto o uso di questa documentazione e declina qualsiasi garanzia espressa o implicita di commerciabilità

Dettagli

USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000

USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000 VERITAS StorageCentral 1 USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000 1. Panoramica di StorageCentral...3 2. StorageCentral riduce il costo totale di proprietà per lo storage di Windows...3 3. Panoramica

Dettagli

Lo Studio di Fattibilità

Lo Studio di Fattibilità Lo Studio di Fattibilità Massimo Mecella Dipartimento di Informatica e Sistemistica Università di Roma La Sapienza Definizione Insieme di informazioni considerate necessarie alla decisione sull investimento

Dettagli

Code Architects S.r.l. SWOP Semantic Web-service Oriented Platform B2SO201

Code Architects S.r.l. SWOP Semantic Web-service Oriented Platform B2SO201 UNIONE EUROPEA FONDO EUROPEO DI SVILUPPO REGIONALE. REGIONE PUGLIA AREA POLITICHE PER LO SVILUPPO IL LAVORO E L INNOVAZIONE Modello M14 Allegati RTA POR PUGLIA 2007-2013 - Asse I Linea 1.1 Azione 1.1.2

Dettagli

I valori di un prodotto disegnato da chi lo usa Vantaggi che garantiscono l'alta qualità del servizio

I valori di un prodotto disegnato da chi lo usa Vantaggi che garantiscono l'alta qualità del servizio Gestire, condividere e controllare le informazioni nei processi aziendali Dataexpert attraverso un evoluto sistema di Document Management, consente la gestione e la condivisione di flussi informativi aziendali

Dettagli

Laboratorio di Progettazione di Sistemi Software Introduzione

Laboratorio di Progettazione di Sistemi Software Introduzione Laboratorio di Progettazione di Sistemi Software Introduzione Valentina Presutti (A-L) Riccardo Solmi (M-Z) Indice degli argomenti Introduzione all Ingegneria del Software UML Design Patterns Refactoring

Dettagli

Rischi 1. Definizione di rischio nello sviluppo del software Analisi dei rischi Gestione dei rischi

Rischi 1. Definizione di rischio nello sviluppo del software Analisi dei rischi Gestione dei rischi Rischi 1 Definizione di rischio nello sviluppo del software Analisi dei rischi Gestione dei rischi Un ingegnere del software viene coinvolto direttamente nel processo di identificazione delle aree potenziali

Dettagli

SCELTA DEL TEST DA ESEGUIRE

SCELTA DEL TEST DA ESEGUIRE SCELTA DEL TEST DA ESEGUIRE Tenete il passo dei cicli di rilascio sempre più veloci. Scoprite l automazione con il tocco umano. ESECUZIONE DI UN TEST 26032015 Test funzionali Con Borland, tutti i membri

Dettagli

Università degli Studi di Bologna Facoltà di Ingegneria. Tecnologie Web L-A A.A. 2014 2015. Esercitazione 08 DAO e Hibernate

Università degli Studi di Bologna Facoltà di Ingegneria. Tecnologie Web L-A A.A. 2014 2015. Esercitazione 08 DAO e Hibernate Università degli Studi di Bologna Facoltà di Ingegneria Tecnologie Web L-A A.A. 2014 2015 Esercitazione 08 DAO e Hibernate Agenda Pattern DAO e framework Hibernate progetto d'esempio relativo alla gestione

Dettagli

WEB TECHNOLOGY. Il web connette. LE persone. E-book n 2 - Copyright Reserved

WEB TECHNOLOGY. Il web connette. LE persone. E-book n 2 - Copyright Reserved WEB TECHNOLOGY Il web connette LE persone Indice «Il Web non si limita a collegare macchine, ma connette delle persone» Il Www, Client e Web Server pagina 3-4 - 5 CMS e template pagina 6-7-8 Tim Berners-Lee

Dettagli

Sviluppo Applicazioni Mobile Lezione 12 JDBC. Dr. Paolo Casoto, Ph.D - 2012

Sviluppo Applicazioni Mobile Lezione 12 JDBC. Dr. Paolo Casoto, Ph.D - 2012 + Sviluppo Applicazioni Mobile Lezione 12 JDBC + Cosa vediamo nella lezione di oggi Oggi analizzeremo insieme una specifica tecnologia Java per l accesso e la manipolazione di basi di dati relazionali

Dettagli

Mobility Manager 2.7 USER MANUAL. Guida. Pag. 1/11. SISTeMA s.r.l. www.sistemaits.com

Mobility Manager 2.7 USER MANUAL. Guida. Pag. 1/11. SISTeMA s.r.l. www.sistemaits.com Mobility Manager 2.7 Guida Pag. 1/11 1 Introduzione... 3 2 Guida... 4 2.1 Accedere e cambiare la password... 4 2.2 Per il mobility manager... 5 2.2.1 Configurare l indagine... 5 2.2.2 Funzionalità Mappa...

Dettagli

CONTENT MANAGMENT SYSTEMS

CONTENT MANAGMENT SYSTEMS CONTENT MANAGMENT SYSTEMS ESTRATTO DA: Ileana D'Incecco, Progettare la comunicazione web per organizzazioni non-profit con strumenti open source: ideazione e realizzazione del sito web della Casa delle

Dettagli

Gestione dei Progetti (2005-2006)

Gestione dei Progetti (2005-2006) Gestione dei Progetti (2005-2006) Alessandro Agnetis DII Università di Siena (Alcune delle illustrazioni contenute nella presentazione sono tratte da PMBOK, a guide to the Project Management Body of Knowledge,

Dettagli

Software testing. Lezione 3 Functional Testing Federica Spiga federica_spiga@yahoo.it. A.A. 2010-2011 Autori: A.Bei/F.Rabini/F.

Software testing. Lezione 3 Functional Testing Federica Spiga federica_spiga@yahoo.it. A.A. 2010-2011 Autori: A.Bei/F.Rabini/F. 1 Software testing Lezione 3 Functional Testing Federica Spiga federica_spiga@yahoo.it A.A. 2010-2011 Autori: A.Bei/F.Rabini/F.Spiga 2 Functional Testing Sotto la dicitura funzionale si raccolgono i criteri

Dettagli

Per la ricerca di soggetti qualificati per la progettazione e lo sviluppo del Portale agroalimentare

Per la ricerca di soggetti qualificati per la progettazione e lo sviluppo del Portale agroalimentare Per la ricerca di soggetti qualificati per la progettazione e lo sviluppo del Portale agroalimentare CIG: Z7A142CF56 Specifiche tecniche Sommario 1. Oggetto del servizio... 2 1.1 Documenti di riferimento...2

Dettagli

Modellazione di sistema

Modellazione di sistema Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Modellazione di sistema E. TINELLI Contenuti Approcci di analisi Linguaggi di specifica Modelli di

Dettagli

Settore delle carte di pagamento (PCI) Standard di protezione dei dati (DSS) Riepilogo delle modifiche di PCI DSS dalla versione 2.0 alla 3.

Settore delle carte di pagamento (PCI) Standard di protezione dei dati (DSS) Riepilogo delle modifiche di PCI DSS dalla versione 2.0 alla 3. Settore delle carte di pagamento (PCI) Standard di protezione dei dati (DSS) Riepilogo delle modifiche di PCI DSS dalla versione 2.0 alla 3.0 Novembre 2013 Introduzione Il presente documento contiene un

Dettagli

Modello OAIS. Modello di riferimento. Il Modello. Prof.ssa E. Gentile a.a. 2011-2012. Un modello di riferimento dovrebbe descrivere:

Modello OAIS. Modello di riferimento. Il Modello. Prof.ssa E. Gentile a.a. 2011-2012. Un modello di riferimento dovrebbe descrivere: Modello OAIS Prof.ssa E. Gentile a.a. 2011-2012 Prof.ssa E. Gentile Progettazione e Produzione di Contenuti Digitali 1 Modello di riferimento Un modello di riferimento dovrebbe descrivere: le componenti

Dettagli

Organizzazione delle informazioni: Database

Organizzazione delle informazioni: Database Organizzazione delle informazioni: Database Laboratorio Informatico di base A.A. 2013/2014 Dipartimento di Scienze Aziendali e Giuridiche Università della Calabria Dott. Pierluigi Muoio (pierluigi.muoio@unical.it)

Dettagli

Meet O Matic. Design Document. Autori: Matteo Maggioni Luca Mantovani. Matricola: 721923 721014

Meet O Matic. Design Document. Autori: Matteo Maggioni Luca Mantovani. Matricola: 721923 721014 Meet O Matic Design Document Autori: Matteo Maggioni Luca Mantovani Matricola: 721923 721014 1 Indice 1 Introduzione 4 2 Architettura 4 3 Definizione della base di dati 6 3.1 Tabelle, campi e chiavi primarie.................

Dettagli

Indice. Introduzione. PARTE PRIMA PHP: i fondamenti 1

Indice. Introduzione. PARTE PRIMA PHP: i fondamenti 1 Indice Introduzione XV PARTE PRIMA PHP: i fondamenti 1 Capitolo 1 Perché PHP e MySQL? 3 1.1 Cos è PHP? 3 1.2 Cos è MySQL? 4 1.3 La storia di PHP 5 1.4 La storia di MySQL 6 1.5 Le ragioni per amare PHP

Dettagli

Il ciclo di progetto focus su. Fase di Pianificazione o Formulazione Work Breakdown Structure Diagramma di GANTT Diagramma di PERT

Il ciclo di progetto focus su. Fase di Pianificazione o Formulazione Work Breakdown Structure Diagramma di GANTT Diagramma di PERT Il ciclo di progetto focus su Fase di Pianificazione o Formulazione Work Breakdown Structure Diagramma di GANTT Diagramma di PERT analisi periodica e finale di: efficienza, efficacia, impatto atteso, sostenibilità

Dettagli