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,

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi

AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma. Unified Process. Prof. Agostino Poggi AOT Lab Dipartimento di Ingegneria dell Informazione Università degli Studi di Parma Unified Process Prof. Agostino Poggi Unified Process Unified Software Development Process (USDP), comunemente chiamato

Dettagli

GoBus: Progettazione e Sviluppo di un App a Supporto della Mobilità

GoBus: Progettazione e Sviluppo di un App a Supporto della Mobilità GoBus: Progettazione e Sviluppo di un App a Supporto della Mobilità Gemma Catolino, Elisa D Eugenio, Davide De Chiara, Alessandro Longo Dipartimento di Studi e Ricerche Aziendali - Management & Information

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

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

Università degli Studi di Parma. Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica Università degli Studi di Parma Facoltà di Scienze MM. FF. NN. Corso di Laurea in Informatica A.A. 2007-08 CORSO DI INGEGNERIA DEL SOFTWARE Prof. Giulio Destri http://www.areasp.com (C) 2007 AreaSP for

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

I Valori del Manifesto Agile sono direttamente applicabili a Scrum:!

I Valori del Manifesto Agile sono direttamente applicabili a Scrum:! Scrum descrizione I Principi di Scrum I Valori dal Manifesto Agile Scrum è il framework Agile più noto. E la sorgente di molte delle idee che si trovano oggi nei Principi e nei Valori del Manifesto Agile,

Dettagli

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina

Sistemi di supporto alle decisioni Ing. Valerio Lacagnina Cosa è il DSS L elevato sviluppo dei personal computer, delle reti di calcolatori, dei sistemi database di grandi dimensioni, e la forte espansione di modelli basati sui calcolatori rappresentano gli sviluppi

Dettagli

Gestione delle Architetture e dei Servizi IT con ADOit. Un Prodotto della Suite BOC Management Office

Gestione delle Architetture e dei Servizi IT con ADOit. Un Prodotto della Suite BOC Management Office Gestione delle Architetture e dei Servizi IT con ADOit Un Prodotto della Suite BOC Management Office Controllo Globale e Permanente delle Architetture IT Aziendali e dei Processi IT: IT-Governance Definire

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

FileMaker Server 12. Guida introduttiva

FileMaker Server 12. Guida introduttiva FileMaker Server 12 Guida introduttiva 2007 2012 FileMaker, Inc. Tutti i diritti riservati. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 FileMaker e Bento sono marchi di FileMaker,

Dettagli

white paper La Process Intelligence migliora le prestazioni operative del settore assicurativo

white paper La Process Intelligence migliora le prestazioni operative del settore assicurativo white paper La Process Intelligence migliora le prestazioni operative del settore assicurativo White paper La Process Intelligence migliora le prestazioni operative del settore assicurativo Pagina 2 Sintesi

Dettagli

Configuration Management

Configuration Management Configuration Management Obiettivi Obiettivo del Configuration Management è di fornire un modello logico dell infrastruttura informatica identificando, controllando, mantenendo e verificando le versioni

Dettagli

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE

ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE ORACLE BUSINESS INTELLIGENCE STANDARD EDITION ONE A WORLD CLASS PERFORMANCE Oracle Business Intelligence Standard Edition One è una soluzione BI completa, integrata destinata alle piccole e medie imprese.oracle

Dettagli

RUP (Rational Unified Process)

RUP (Rational Unified Process) RUP (Rational Unified Process) Caratteristiche, Punti di forza, Limiti versione del tutorial: 3.3 (febbraio 2007) Pag. 1 Unified Process Booch, Rumbaugh, Jacobson UML (Unified Modeling Language) notazione

Dettagli

ManageEngine ITSM: HelpDesk ITIL, gestione degli asset IT e MDM. Andrea Mannara Business Unit Manager

ManageEngine ITSM: HelpDesk ITIL, gestione degli asset IT e MDM. Andrea Mannara Business Unit Manager ManageEngine ITSM: HelpDesk ITIL, gestione degli asset IT e MDM Andrea Mannara Business Unit Manager ManageEngine Portfolio Network Data Center Desktop & MDM ServiceDesk & Asset Active Directory Log &

Dettagli

SMS API. Documentazione Tecnica YouSMS SOAP API. YouSMS Evet Limited 2015 http://www.yousms.it

SMS API. Documentazione Tecnica YouSMS SOAP API. YouSMS Evet Limited 2015 http://www.yousms.it SMS API Documentazione Tecnica YouSMS SOAP API YouSMS Evet Limited 2015 http://www.yousms.it INDICE DEI CONTENUTI Introduzione... 2 Autenticazione & Sicurezza... 2 Username e Password... 2 Connessione

Dettagli

Panoramica su ITIL V3 ed esempio di implementazione del Service Design

Panoramica su ITIL V3 ed esempio di implementazione del Service Design Master Universitario di II livello in Interoperabilità Per la Pubblica Amministrazione e Le Imprese Panoramica su ITIL V3 ed esempio di implementazione del Service Design Lavoro pratico II Periodo didattico

Dettagli

DynDevice ECM. La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali

DynDevice ECM. La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali DynDevice ECM La Suite di applicazioni web per velocizzare, standardizzare e ottimizzare il flusso delle informazioni aziendali Presentazione DynDevice ECM Cos è DynDevice ICMS Le soluzioni di DynDevice

Dettagli

Intalio. Leader nei Sistemi Open Source per il Business Process Management. Andrea Calcagno Amministratore Delegato

Intalio. Leader nei Sistemi Open Source per il Business Process Management. Andrea Calcagno Amministratore Delegato Intalio Convegno Open Source per la Pubblica Amministrazione Leader nei Sistemi Open Source per il Business Process Management Navacchio 4 Dicembre 2008 Andrea Calcagno Amministratore Delegato 20081129-1

Dettagli

BPEL: Business Process Execution Language

BPEL: Business Process Execution Language Ingegneria dei processi aziendali BPEL: Business Process Execution Language Ghilardi Dario 753708 Manenti Andrea 755454 Docente: Prof. Ernesto Damiani BPEL - definizione Business Process Execution Language

Dettagli

La suite Dental Trey che semplifica il tuo mondo.

La suite Dental Trey che semplifica il tuo mondo. La suite Dental Trey che semplifica il tuo mondo. impostazioni di sistema postazione clinica studio privato sterilizzazione magazzino segreteria amministrazione sala di attesa caratteristiche UNO tiene

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello del sistema 4 2.1 Requisiti hardware........................ 4 2.2 Requisiti software.........................

Dettagli

UML Component and Deployment diagram

UML Component and Deployment diagram UML Component and Deployment diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania I diagrammi UML Classificazione

Dettagli

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT

Copyright Università degli Studi di Torino, Progetto Atlante delle Professioni 2009 IT PROCESS EXPERT IT PROCESS EXPERT 1. CARTA D IDENTITÀ... 2 2. CHE COSA FA... 3 3. DOVE LAVORA... 4 4. CONDIZIONI DI LAVORO... 5 5. COMPETENZE... 6 Quali competenze sono necessarie... 6 Conoscenze... 8 Abilità... 9 Comportamenti

Dettagli

Cos è l Ingegneria del Software?

Cos è l Ingegneria del Software? Cos è l Ingegneria del Software? Corpus di metodologie e tecniche per la produzione di sistemi software. L ingegneria del software è la disciplina tecnologica e gestionale che riguarda la produzione sistematica

Dettagli

Il ciclo di vita del software

Il ciclo di vita del software Il ciclo di vita del software Il ciclo di vita del software Definisce un modello per il software, dalla sua concezione iniziale fino al suo sviluppo completo, al suo rilascio, alla sua successiva evoluzione,

Dettagli

Corso di Amministrazione di Sistema Parte I ITIL 3

Corso di Amministrazione di Sistema Parte I ITIL 3 Corso di Amministrazione di Sistema Parte I ITIL 3 Francesco Clabot Responsabile erogazione servizi tecnici 1 francesco.clabot@netcom-srl.it Fondamenti di ITIL per la Gestione dei Servizi Informatici Il

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello della Web Application 5 3 Struttura della web Application 6 4 Casi di utilizzo della Web

Dettagli

I N F I N I T Y Z U C C H E T T I WORKFLOW HR

I N F I N I T Y Z U C C H E T T I WORKFLOW HR I N F I N I T Y Z U C C H E T T I WORKFLOW HR WORKFLOW HR Zucchetti, nell ambito delle proprie soluzioni per la gestione del personale, ha realizzato una serie di moduli di Workflow in grado di informatizzare

Dettagli

How to Develop Accessible Linux Applications

How to Develop Accessible Linux Applications How to Develop Accessible Linux Applications Sharon Snider Copyright 2002 IBM Corporation v1.1, 2002-05-03 Diario delle Revisioni Revisione v1.1 2002-05-03 Revisionato da: sds Convertito in DocBook XML

Dettagli

Quali dati potremmo modificare? Impostazioni sul campionato, risultati, designazioni, provvedimenti disciplinari, statistiche e tanto ancora.

Quali dati potremmo modificare? Impostazioni sul campionato, risultati, designazioni, provvedimenti disciplinari, statistiche e tanto ancora. WCM Sport è un software che tramite un sito web ha l'obbiettivo di aiutare l'organizzazione e la gestione di un campionato sportivo supportando sia i responsabili del campionato sia gli utilizzatori/iscritti

Dettagli

Dalla Mappatura dei Processi al Business Process Management

Dalla Mappatura dei Processi al Business Process Management Dalla Mappatura dei Processi al Business Process Management Romano Stasi Responsabile Segreteria Tecnica ABI Lab Roma, 4 dicembre 2007 Agenda Il percorso metodologico Analizzare per conoscere: la mappatura

Dettagli

Convegno 6 giugno 2013 Federlazio Frosinone

Convegno 6 giugno 2013 Federlazio Frosinone Convegno 6 giugno 2013 Federlazio Frosinone pag. 1 6 giugno 2013 Federlazio Frosinone Introduzione alla Business Intelligence Un fattore critico per la competitività è trasformare la massa di dati prodotti

Dettagli

SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras

SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras SOA GOVERNANCE: WHAT DOES IT MEAN? Giorgio Marras 2 Introduzione Le architetture basate sui servizi (SOA) stanno rapidamente diventando lo standard de facto per lo sviluppo delle applicazioni aziendali.

Dettagli

Sistem Design Document (SDD) Franchising viruale

Sistem Design Document (SDD) Franchising viruale Sistem Design Document (SDD) Franchising viruale 1- Introduzione 1.1- Scopo del sistema Lo scopo del sistema è quello di progettare un franchising virtuale operante nel settore della distribuzione degli

Dettagli

Problem Management. Obiettivi. Definizioni. Responsabilità. Attività. Input

Problem Management. Obiettivi. Definizioni. Responsabilità. Attività. Input Problem Management Obiettivi Obiettivo del Problem Management e di minimizzare l effetto negativo sull organizzazione degli Incidenti e dei Problemi causati da errori nell infrastruttura e prevenire gli

Dettagli

Processi ITIL. In collaborazione con il nostro partner:

Processi ITIL. In collaborazione con il nostro partner: Processi ITIL In collaborazione con il nostro partner: NetEye e OTRS: la piattaforma WÜRTHPHOENIX NetEye è un pacchetto di applicazioni Open Source volto al monitoraggio delle infrastrutture informatiche.

Dettagli

Business Process Management

Business Process Management Corso di Certificazione in Business Process Management Progetto Didattico 2015 con la supervisione scientifica del Dipartimento di Informatica Università degli Studi di Torino Responsabile scientifico

Dettagli

Enterprise Content Management. Terminologia. KM, ECM e BPM per creare valore nell impresa. Giovanni Marrè Amm. Del., it Consult

Enterprise Content Management. Terminologia. KM, ECM e BPM per creare valore nell impresa. Giovanni Marrè Amm. Del., it Consult KM, ECM e BPM per creare valore nell impresa Giovanni Marrè Amm. Del., it Consult Terminologia Ci sono alcuni termini che, a vario titolo, hanno a che fare col tema dell intervento KM ECM BPM E20 Enterprise

Dettagli

E-MAIL INTEGRATA OTTIMIZZAZIONE DEI PROCESSI AZIENDALI

E-MAIL INTEGRATA OTTIMIZZAZIONE DEI PROCESSI AZIENDALI E-MAIL INTEGRATA OTTIMIZZAZIONE DEI PROCESSI AZIENDALI E-MAIL INTEGRATA Ottimizzazione dei processi aziendali Con il modulo E-mail Integrata, NTS Informatica ha realizzato uno strumento di posta elettronica

Dettagli

Istituto Tecnico Commerciale Indirizzo AFM articolazione SIA PERCHE???

Istituto Tecnico Commerciale Indirizzo AFM articolazione SIA PERCHE??? Istituto Tecnico Commerciale Indirizzo AFM articolazione SIA PERCHE??? Opportunità di lavoro: ICT - Information and Communication Technology in Azienda Vendite Acquisti Produzione Logistica AFM SIA ICT

Dettagli

Business Process Modeling and Notation e WebML

Business Process Modeling and Notation e WebML Business Process Modeling and Notation e WebML 24 Introduzione I Web Service e BPMN sono standard de facto per l interoperabilità in rete a servizio delle imprese moderne I Web Service sono utilizzati

Dettagli

2- Identificazione del processo. (o dei processi) da analizzare. Approcci: Esaustivo. In relazione al problema. Sulla base della rilevanza

2- Identificazione del processo. (o dei processi) da analizzare. Approcci: Esaustivo. In relazione al problema. Sulla base della rilevanza PROCESS MAPPING (2) Approcci: 2- Identificazione del processo Esaustivo (o dei processi) da analizzare Mappatura a largo spettro (es.: vasta implementazione di un ERP) In relazione al problema ad es. i

Dettagli

Energy Data Management System (EDMS): la soluzione software per una gestione efficiente dell energia secondo lo standard ISO 50001

Energy Data Management System (EDMS): la soluzione software per una gestione efficiente dell energia secondo lo standard ISO 50001 Energy Data Management System (EDMS): la soluzione software per una gestione efficiente dell energia secondo lo standard ISO 50001 Oggi più che mai, le aziende italiane sentono la necessità di raccogliere,

Dettagli

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN)

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) System Overview di Mattia Bargellini 1 CAPITOLO 1 1.1 Introduzione Il seguente progetto intende estendere

Dettagli

IBM Cognos 8 BI Midmarket Reporting Packages Per soddisfare tutte le vostre esigenze di reporting restando nel budget

IBM Cognos 8 BI Midmarket Reporting Packages Per soddisfare tutte le vostre esigenze di reporting restando nel budget Data Sheet IBM Cognos 8 BI Midmarket Reporting Packages Per soddisfare tutte le vostre esigenze di reporting restando nel budget Panoramica Le medie aziende devono migliorare nettamente le loro capacità

Dettagli

Release Management. Obiettivi. Definizioni. Responsabilità. Attività. Input

Release Management. Obiettivi. Definizioni. Responsabilità. Attività. Input Release Management Obiettivi Obiettivo del Release Management è di raggiungere una visione d insieme del cambiamento nei servizi IT e accertarsi che tutti gli aspetti di una release (tecnici e non) siano

Dettagli

La gestione documentale con il programma Filenet ed il suo utilizzo tramite la tecnologia.net. di Emanuele Mattei (emanuele.mattei[at]email.

La gestione documentale con il programma Filenet ed il suo utilizzo tramite la tecnologia.net. di Emanuele Mattei (emanuele.mattei[at]email. La gestione documentale con il programma Filenet ed il suo utilizzo tramite la tecnologia.net di Emanuele Mattei (emanuele.mattei[at]email.it) Introduzione In questa serie di articoli, vedremo come utilizzare

Dettagli

Boot Camp Guida all installazione e alla configurazione

Boot Camp Guida all installazione e alla configurazione Boot Camp Guida all installazione e alla configurazione Indice 4 Introduzione 5 Cosa ti occorre 6 Panoramica dell installazione 6 Passo 1: verifica la presenza di aggiornamenti. 6 Passo 2: apri Assistente

Dettagli

più del mercato applicazioni dei processi modificato. Reply www.reply.eu

più del mercato applicazioni dei processi modificato. Reply www.reply.eu SOA IN AMBITO TELCO Al fine di ottimizzare i costi e di migliorare la gestione dell'it, le aziende guardano, sempre più con maggiore interesse, alle problematiche di gestionee ed ottimizzazione dei processi

Dettagli

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014

Processi di business sovra-regionali relativi ai sistemi regionali di FSE. Versione 1.0 24 Giugno 2014 Processi di business sovra-regionali relativi ai sistemi regionali di FSE Versione 1.0 24 Giugno 2014 1 Indice Indice... 2 Indice delle figure... 3 Indice delle tabelle... 4 Obiettivi del documento...

Dettagli

Le funzionalità di un DBMS

Le funzionalità di un DBMS Le funzionalità di un DBMS Sistemi Informativi L-A Home Page del corso: http://www-db.deis.unibo.it/courses/sil-a/ Versione elettronica: DBMS.pdf Sistemi Informativi L-A DBMS: principali funzionalità Le

Dettagli

BRM. Tutte le soluzioni. per la gestione delle informazioni aziendali. BusinessRelationshipManagement

BRM. Tutte le soluzioni. per la gestione delle informazioni aziendali. BusinessRelationshipManagement BRM BusinessRelationshipManagement Tutte le soluzioni per la gestione delle informazioni aziendali - Business Intelligence - Office Automation - Sistemi C.R.M. I benefici di BRM Garantisce la sicurezza

Dettagli

un occhio al passato per il tuo business futuro

un occhio al passato per il tuo business futuro 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 un occhio al passato per il tuo business futuro BUSINESS DISCOVERY Processi ed analisi per aziende virtuose Che cos è La Business Discovery è un insieme

Dettagli

FIRESHOP.NET. Gestione Utility & Configurazioni. Rev. 2014.3.1 www.firesoft.it

FIRESHOP.NET. Gestione Utility & Configurazioni. Rev. 2014.3.1 www.firesoft.it FIRESHOP.NET Gestione Utility & Configurazioni Rev. 2014.3.1 www.firesoft.it Sommario SOMMARIO Introduzione... 4 Impostare i dati della propria azienda... 5 Aggiornare il programma... 6 Controllare l integrità

Dettagli

FORM Il sistema informativo di gestione della modulistica elettronica.

FORM Il sistema informativo di gestione della modulistica elettronica. Studio FORM FORM Il sistema informativo di gestione della modulistica elettronica. We believe in what we create This is FORM power La soluzione FORM permette di realizzare qualsiasi documento in formato

Dettagli

www.bistrategy.it In un momento di crisi perché scegliere di investire sulla Business Intelligence?

www.bistrategy.it In un momento di crisi perché scegliere di investire sulla Business Intelligence? In un momento di crisi perché scegliere di investire sulla Business Intelligence? Cos è? Per definizione, la Business Intelligence è: la trasformazione dei dati in INFORMAZIONI messe a supporto delle decisioni

Dettagli

L 8 maggio 2002 il Ministero

L 8 maggio 2002 il Ministero > > > > > Prima strategia: ascoltare le esigenze degli utenti, semplificare il linguaggio e la navigazione del sito. Seconda: sviluppare al nostro interno le competenze e le tecnologie per gestire in proprio

Dettagli

Neomobile incentra l infrastruttura IT su Microsoft ALM, arrivando a 40 nuovi rilasci a settimana

Neomobile incentra l infrastruttura IT su Microsoft ALM, arrivando a 40 nuovi rilasci a settimana Storie di successo Microsoft per le Imprese Scenario: Software e Development Settore: Servizi In collaborazione con Neomobile incentra l infrastruttura IT su Microsoft ALM, arrivando a 40 nuovi rilasci

Dettagli

Architettura di un sistema informatico 1 CONCETTI GENERALI

Architettura di un sistema informatico 1 CONCETTI GENERALI Architettura di un sistema informatico Realizzata dal Dott. Dino Feragalli 1 CONCETTI GENERALI 1.1 Obiettivi Il seguente progetto vuole descrivere l amministrazione dell ITC (Information Tecnology end

Dettagli

t.fabrica wanna be smarter? smart, simple, cost effectiveness solutions for manufactoring operational excellence.

t.fabrica wanna be smarter? smart, simple, cost effectiveness solutions for manufactoring operational excellence. t.fabrica wanna be smarter? smart, simple, cost effectiveness solutions for manufactoring operational excellence. Per le aziende manifatturiere, oggi e sempre più nel futuro individuare ed eliminare gli

Dettagli

Il Business Process Management: nuova via verso la competitività aziendale

Il Business Process Management: nuova via verso la competitività aziendale Il Business Process Management: nuova via verso la competitività Renata Bortolin Che cosa significa Business Process Management? In che cosa si distingue dal Business Process Reingeneering? Cosa ha a che

Dettagli

Relazione sul data warehouse e sul data mining

Relazione sul data warehouse e sul data mining Relazione sul data warehouse e sul data mining INTRODUZIONE Inquadrando il sistema informativo aziendale automatizzato come costituito dall insieme delle risorse messe a disposizione della tecnologia,

Dettagli

Elementi di UML (7): Diagrammi dei componenti e di deployment

Elementi di UML (7): Diagrammi dei componenti e di deployment Elementi di UML (7): Diagrammi dei componenti e di deployment Università degli Studi di Bologna Facoltà di Scienze MM. FF. NN. Corso di Laurea in Scienze di Internet Anno Accademico 2004-2005 Laboratorio

Dettagli

INTRODUZIONE ALLA GESTIONE DEL PROGETTO SOFTWARE CON UML

INTRODUZIONE ALLA GESTIONE DEL PROGETTO SOFTWARE CON UML Università degli Studi di Parma Dipartimento di Matematica e Informatica Corso di Laurea in Informatica DISPENSE INTRODUTTIVE INTRODUZIONE ALLA GESTIONE DEL PROGETTO SOFTWARE CON UML Prof. Giulio Destri

Dettagli

GUIDA RAPIDA emagister-agora Edizione BASIC

GUIDA RAPIDA emagister-agora Edizione BASIC GUIDA RAPIDA emagister-agora Edizione BASIC Introduzione a emagister-agora Interfaccia di emagister-agora Configurazione dell offerta didattica Richieste d informazioni Gestione delle richieste d informazioni

Dettagli

Il Business Process Management nella PA: migliorare la relazione con i cittadini ed ottimizzare i processi interni. A cura di Bernardo Puccetti

Il Business Process Management nella PA: migliorare la relazione con i cittadini ed ottimizzare i processi interni. A cura di Bernardo Puccetti Il Business Process Management nella PA: migliorare la relazione con i cittadini ed ottimizzare i processi interni A cura di Bernardo Puccetti Il Business Process Management nella PA Presentazione SOFTLAB

Dettagli

B.P.S. Business Process Server ALLEGATO C10

B.P.S. Business Process Server ALLEGATO C10 B.P.S. Business Process Server ALLEGATO C10 REGIONE BASILICATA DIPARTIMENTO PRESIDENZA DELLA GIUNTA REGIONALE UFFICIO SISTEMA INFORMATIVO REGIONALE E STATISTICA Via V. Verrastro, n. 4 85100 Potenza tel

Dettagli

White Paper. Operational DashBoard. per una Business Intelligence. in real-time

White Paper. Operational DashBoard. per una Business Intelligence. in real-time White Paper Operational DashBoard per una Business Intelligence in real-time Settembre 2011 www.axiante.com A Paper Published by Axiante CAMBIARE LE TRADIZIONI C'è stato un tempo in cui la Business Intelligence

Dettagli

PLM Software. Answers for industry. Siemens PLM Software

PLM Software. Answers for industry. Siemens PLM Software Siemens PLM Software Monitoraggio e reporting delle prestazioni di prodotti e programmi Sfruttare le funzionalità di reporting e analisi delle soluzioni PLM per gestire in modo più efficace i complessi

Dettagli

dei processi di customer service

dei processi di customer service WHITE PAPER APRILE 2013 Il Business Process Orchestrator dei processi di customer service Fonte Dati: Forrester Research Inc I marchi registrati citati nel presente documento sono di proprietà esclusiva

Dettagli

Problem Management proattivo di sicurezza secondo ITIL: attività di Etichal Hacking

Problem Management proattivo di sicurezza secondo ITIL: attività di Etichal Hacking Seminario associazioni: Seminario a cura di itsmf Italia Problem Management proattivo di sicurezza secondo ITIL: attività di Etichal Hacking Andrea Praitano Agenda Struttura dei processi ITIL v3; Il Problem

Dettagli

IT Service Management

IT Service Management IT Service Management ITIL: I concetti chiave ed il livello di adozione nelle aziende italiane Matteo De Angelis, itsmf Italia (I) 1 Chi è itsmf italia 12 th May 2011 - Bolzano itsmf (IT Service Management

Dettagli

Web Conferencing Open Source

Web Conferencing Open Source Web Conferencing Open Source A cura di Giuseppe Maugeri g.maugeri@bembughi.org 1 Cos è BigBlueButton? Sistema di Web Conferencing Open Source Basato su più di quattordici componenti Open-Source. Fornisce

Dettagli

COME FRODE. la possibilità propri dati. brevissimo. Reply www.reply.eu

COME FRODE. la possibilità propri dati. brevissimo. Reply www.reply.eu FRAUD MANAGEMENT. COME IDENTIFICARE E COMB BATTERE FRODI PRIMA CHE ACCADANO LE Con una visione sia sui processi di business, sia sui sistemi, Reply è pronta ad offrire soluzioni innovative di Fraud Management,

Dettagli

IT Service Management

IT Service Management IT Service Management L'importanza dell'analisi dei processi nelle grandi e medie realtà italiane Evento Business Strategy 2.0 Firenze 25 settembre 2012 Giovanni Sadun Agenda ITSM: Contesto di riferimento

Dettagli

DataFix. La soluzione innovativa per l'help Desk aziendale

DataFix. La soluzione innovativa per l'help Desk aziendale DataFix D A T A N O S T O P La soluzione innovativa per l'help Desk aziendale La soluzione innovativa per l'help Desk aziendale L a necessità di fornire un adeguato supporto agli utenti di sistemi informatici

Dettagli

Introduzione alla Programmazione ad Oggetti in C++

Introduzione alla Programmazione ad Oggetti in C++ Introduzione alla Programmazione ad Oggetti in C++ Lezione 1 Cosa è la Programmazione Orientata agli Oggetti Metodologia per costruire prodotti software di grosse dimensioni che siano affidabili e facilmente

Dettagli

Progetto BPR: Business Process Reengineering

Progetto BPR: Business Process Reengineering Progetto BPR: Business Process Reengineering Riflessioni frutto di esperienze concrete PER LA CORRETTA INTERPRETAZIONE DELLE PAGINE SEGUENTI SI DEVE TENERE CONTO DI QUANTO ILLUSTRATO ORALMENTE Obiettivo

Dettagli

APPLICAZIONE WEB PER LA GESTIONE DELLE RICHIESTE DI ACQUISTO DEL MATERIALE INFORMATICO. Francesco Marchione e Dario Richichi

APPLICAZIONE WEB PER LA GESTIONE DELLE RICHIESTE DI ACQUISTO DEL MATERIALE INFORMATICO. Francesco Marchione e Dario Richichi APPLICAZIONE WEB PER LA GESTIONE DELLE RICHIESTE DI ACQUISTO DEL MATERIALE INFORMATICO Francesco Marchione e Dario Richichi Istituto Nazionale di Geofisica e Vulcanologia Sezione di Palermo Indice Introduzione...

Dettagli

IT FINANCIAL MANAGEMENT

IT FINANCIAL MANAGEMENT IT FINANCIAL MANAGEMENT L IT Financial Management è una disciplina per la pianificazione e il controllo economico-finanziario, di carattere sia strategico sia operativo, basata su un ampio insieme di metodologie

Dettagli

ARP (Address Resolution Protocol)

ARP (Address Resolution Protocol) ARP (Address Resolution Protocol) Il routing Indirizzo IP della stazione mittente conosce: - il proprio indirizzo (IP e MAC) - la netmask (cioè la subnet) - l indirizzo IP del default gateway, il router

Dettagli

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace:

Introduzione. E un sistema EAI molto flessibile, semplice ed efficace: Overview tecnica Introduzione E un sistema EAI molto flessibile, semplice ed efficace: Introduce un architettura ESB nella realtà del cliente Si basa su standard aperti Utilizza un qualsiasi Application

Dettagli

MANUALE DI INSTALLAZIONE GESTIONE FLOTTE /REMIND

MANUALE DI INSTALLAZIONE GESTIONE FLOTTE /REMIND Progettisti dentro e oltre l impresa MANUALE DI INSTALLAZIONE GESTIONE FLOTTE /REMIND Pag 1 di 31 INTRODUZIONE Questo documento ha lo scopo di illustrare le modalità di installazione e configurazione dell

Dettagli

Business Intelligence: dell impresa

Business Intelligence: dell impresa Architetture Business Intelligence: dell impresa Silvana Bortolin Come organizzare la complessità e porla al servizio dell impresa attraverso i sistemi di Business Intelligence, per creare processi organizzativi

Dettagli

Plesk Automation. Parallels. Domande tecniche più frequenti

Plesk Automation. Parallels. Domande tecniche più frequenti Parallels Plesk Automation Primo trimestre, 2013 Domande tecniche più frequenti Questo documento ha come scopo quello di rispondere alle domande tecniche che possono sorgere quando si installa e si utilizza

Dettagli

CORSO DI ALGORITMI E PROGRAMMAZIONE. JDBC Java DataBase Connectivity

CORSO DI ALGORITMI E PROGRAMMAZIONE. JDBC Java DataBase Connectivity CORSO DI ALGORITMI E PROGRAMMAZIONE JDBC Java DataBase Connectivity Anno Accademico 2002-2003 Accesso remoto al DB Istruzioni SQL Rete DataBase Utente Host client Server di DataBase Host server Accesso

Dettagli

L idea. 43.252.003.274.489.856.000 combinazioni possibili di cui solo una è quella corretta

L idea. 43.252.003.274.489.856.000 combinazioni possibili di cui solo una è quella corretta Guardare oltre L idea 43.252.003.274.489.856.000 combinazioni possibili di cui solo una è quella corretta I nostri moduli non hanno altrettante combinazioni possibili, ma la soluzione è sempre una, PERSONALIZZATA

Dettagli

DBMS (Data Base Management System)

DBMS (Data Base Management System) Cos'è un Database I database o banche dati o base dati sono collezioni di dati, tra loro correlati, utilizzati per rappresentare una porzione del mondo reale. Sono strutturati in modo tale da consentire

Dettagli

Windows Mail Outlook Express 6 Microsoft Outlook 2003 Microsoft Outlook 2007 Thunderbird Opera Mail Mac Mail

Windows Mail Outlook Express 6 Microsoft Outlook 2003 Microsoft Outlook 2007 Thunderbird Opera Mail Mac Mail Configurare un programma di posta con l account PEC di Il Titolare di una nuova casella PEC può accedere al sistema sia tramite Web (Webmail i ), sia configurando il proprio account ii nel programma di

Dettagli

LA TECHNOLOGY TRANSFER PRESENTA SUZANNE ROBERTSON MASTERING THE REQUIREMENTS PROCESS COME COSTRUIRE IL SISTEMA CHE IL VOSTRO UTENTE DESIDERA

LA TECHNOLOGY TRANSFER PRESENTA SUZANNE ROBERTSON MASTERING THE REQUIREMENTS PROCESS COME COSTRUIRE IL SISTEMA CHE IL VOSTRO UTENTE DESIDERA LA TECHNOLOGY TRANSFER PRESENTA SUZANNE ROBERTSON MASTERING THE REQUIREMENTS PROCESS COME COSTRUIRE IL SISTEMA CHE IL VOSTRO UTENTE DESIDERA ROMA 20-22 OTTOBRE 2014 RESIDENZA DI RIPETTA - VIA DI RIPETTA,

Dettagli

Rational Asset Manager, versione 7.1

Rational Asset Manager, versione 7.1 Rational Asset Manager, versione 7.1 Versione 7.1 Guida all installazione Rational Asset Manager, versione 7.1 Versione 7.1 Guida all installazione Note Prima di utilizzare queste informazioni e il prodotto

Dettagli

END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE DEL CLIENTE

END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE DEL CLIENTE END-TO-END SERVICE QUALITY. LA CULTURA DELLA QUALITÀ DAL CONTROLLO DELLE RISORSE ALLA SODDISFAZIONE In un mercato delle Telecomunicazioni sempre più orientato alla riduzione delle tariffe e dei costi di

Dettagli

Parallels Plesk Panel

Parallels Plesk Panel Parallels Plesk Panel Notifica sul Copyright ISBN: N/A Parallels 660 SW 39 th Street Suite 205 Renton, Washington 98057 USA Telefono: +1 (425) 282 6400 Fax: +1 (425) 282 6444 Copyright 1999-2009, Parallels,

Dettagli

Pagine romane (I-XVIII) OK.qxd:romane.qxd 7-09-2009 16:23 Pagina VI. Indice

Pagine romane (I-XVIII) OK.qxd:romane.qxd 7-09-2009 16:23 Pagina VI. Indice Pagine romane (I-XVIII) OK.qxd:romane.qxd 7-09-2009 16:23 Pagina VI Prefazione Autori XIII XVII Capitolo 1 Sistemi informativi aziendali 1 1.1 Introduzione 1 1.2 Modello organizzativo 3 1.2.1 Sistemi informativi

Dettagli

Rischio impresa. Rischio di revisione

Rischio impresa. Rischio di revisione Guida alla revisione legale PIANIFICAZIONE del LAVORO di REVISIONE LEGALE dei CONTI Formalizzazione delle attività da svolgere nelle carte di lavoro: determinazione del rischio di revisione, calcolo della

Dettagli

Le Dashboard di cui non si può fare a meno

Le Dashboard di cui non si può fare a meno Le Dashboard di cui non si può fare a meno Le aziende più sensibili ai cambiamenti stanno facendo di tutto per cogliere qualsiasi opportunità che consenta loro di incrementare il business e di battere

Dettagli

REAL WORLD AND VIRTUAL WORLD ARCHITECTURE FOR INTERCONN INTERCONNECTING FIRST AND SECOND LIFE

REAL WORLD AND VIRTUAL WORLD ARCHITECTURE FOR INTERCONN INTERCONNECTING FIRST AND SECOND LIFE REAL WORLD AND VIRTUAL WORLD ARCHITECTURE FOR INTERCONNECTING FIRST AND SECOND LIFE Università degli studi di Catania Facoltà di Ingegneria 26 Gennaio 2009 Sommario 1 Introduzione 2 Middleware Middleware:

Dettagli