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

Dimensione: px
Iniziare la visualizzazioe della pagina:

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

Transcript

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dettagli

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

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

Dettagli

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

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

Dettagli

Novità di Visual Studio 2008

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

Dettagli

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

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

Dettagli

SDD System design document

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

Dettagli

UNIVERSITÀ DEGLI STUDI DI SALERNO

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

Dettagli

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

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

Dettagli

Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni

Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni White paper Programmabilità di rete con l'infrastruttura Cisco basata sulle applicazioni Panoramica Questo documento analizza il supporto alla programmabilità nell'infrastruttura ACI (Application Centric

Dettagli

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

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

Dettagli

Architettura SW Definizione e Notazioni

Architettura SW Definizione e Notazioni Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Stili Architetturali E. TINELLI Architettura SW Definizione e Notazioni Definizione ANSI/IEEE Std Std1471-2000

Dettagli

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

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

Dettagli

Software project management. www.vincenzocalabro.it

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

Dettagli

Ciclo di Vita Evolutivo

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

Dettagli

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

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

Dettagli

Programmazione Java Avanzata

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

Dettagli

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

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

Dettagli

Sistemi Informativi e WWW

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

Dettagli

Attività: 3.d Test e sperimentazione

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

Dettagli

Una soluzione per la gestione del packaging online

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

Dettagli

Sistemi Informativi Distribuiti

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

Dettagli

REPERTORIO DELLE QUALIFICAZIONI PROFESSIONALI DELLA REGIONE CAMPANIA

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

Dettagli

Processi di Business e Sistemi di Gestione di Workflow: concetti di base. Prof. Giancarlo Fortino g.fortino@unical.it

Processi di Business e Sistemi di Gestione di Workflow: concetti di base. Prof. Giancarlo Fortino g.fortino@unical.it Processi di Business e Sistemi di Gestione di Workflow: concetti di base Prof. Giancarlo Fortino g.fortino@unical.it Introduzione Le aziende devono modificare la loro organizzazione per cogliere le nuove

Dettagli

TECNICO SUPERIORE PER LE APPLICAZIONI INFORMATICHE

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

Dettagli

UML e (R)UP (an overview)

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

Dettagli

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

SWIM v2 Design Document

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

Dettagli

Processi principali per il completamento del progetto

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

Dettagli

INGEGNERIA DEL SOFTWARE. Prof. Paolo Salvaneschi

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

Dettagli

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

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

Dettagli

5 Gestione dei progetti software. 5.1 Attività gestionale. Sistemi Informativi I Lezioni di Ingegneria del Software

5 Gestione dei progetti software. 5.1 Attività gestionale. Sistemi Informativi I Lezioni di Ingegneria del Software 5 Gestione dei progetti software. Dopo aver completato lo studio del ciclo di vita del software, in questa parte vengono discussi gli aspetti gestionali della produzione del software. Vengono esaminate

Dettagli

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

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

Dettagli

Il software: natura e qualità

Il software: natura e qualità Sommario Il software: natura e qualità Leggere Cap. 2 Ghezzi et al. Natura e peculiarità del software Classificazione delle qualità del software Qualità del prodotto e del processo Qualità interne ed esterne

Dettagli

Obiettivi d esame PHP Developer Fundamentals on MySQL Environment

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

Dettagli

2. Ciclo di Vita e Processi di Sviluppo

2. Ciclo di Vita e Processi di Sviluppo 2. Ciclo di Vita e Processi di Sviluppo come posso procedere nello sviluppo? Andrea Polini Ingegneria del Software Corso di Laurea in Informatica (Ingegneria del Software) 2. Ciclo di Vita e Processi di

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

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

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

Dettagli

Indice. Prefazione all edizione italiana

Indice. Prefazione all edizione italiana Indice Prefazione all edizione italiana XV Capitolo 1 Il software e l ingegneria del software 1 1.1 L evoluzione del ruolo del software 3 1.2 Il software 5 1.3 La natura mutevole del software 8 1.4 Il

Dettagli

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

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

Dettagli

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

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

Dettagli

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

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

Dettagli

Corso di Informatica Modulo T3 B1 Programmazione web

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

Dettagli

Pattern Architetturali e Analisi Architetturale

Pattern Architetturali e Analisi Architetturale Pattern Architetturali e Analisi Architetturale Ingegneria del Software parte II Andrea Bei Pattern Architetturali Pattern Architetturale Descrive il modello organizzativo strutturale di un sistema software

Dettagli

Concetti base. Impianti Informatici. Web application

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

Dettagli

TECNICO SUPERIORE PER LO SVILUPPO DEL SOFTWARE

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

Dettagli

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti

Sviluppo di applicazioni web con il pattern Model-View-Controller. Gabriele Pellegrinetti Sviluppo di applicazioni web con il pattern Model-View-Controller Gabriele Pellegrinetti 2 MVC: come funziona e quali sono vantaggi che derivano dal suo utilizzo? La grande diffusione della tecnologia

Dettagli

La gestione dei progetti informatici

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

Dettagli

Architettura del software: dai Casi d Uso al Modello

Architettura del software: dai Casi d Uso al Modello Architettura del software: dai Casi d Uso al Modello Lorenzo Barbieri Sono un Senior Trainer/Consultant in ObjectWay SpA (www.objectway.it), specializzato in architetture Microsoft.NET, Windows, SQL Server,

Dettagli

USO OTTIMALE DI ACTIVE DIRECTORY DI WINDOWS 2000

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

Dettagli

RenderCAD S.r.l. Formazione

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

Dettagli

ANALISI DI UN CASO DI EVOLUZIONE NELL ADOZIONE DELLA SOLUZIONE PROJECT AND PORTFOLIO MANAGEMENT DI HP.

ANALISI DI UN CASO DI EVOLUZIONE NELL ADOZIONE DELLA SOLUZIONE PROJECT AND PORTFOLIO MANAGEMENT DI HP. INTERVISTA 13 settembre 2012 ANALISI DI UN CASO DI EVOLUZIONE NELL ADOZIONE DELLA SOLUZIONE PROJECT AND PORTFOLIO MANAGEMENT DI HP. Intervista ad Ermanno Pappalardo, Lead Solution Consultant HP Software

Dettagli

Pieces of Technology at your service. dottesttm

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

Dettagli

Soluzioni di strong authentication per il controllo degli accessi

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

Dettagli

Project Planning. Politecnico di Milano. Progetto di Ingegneria del Software 2. 15 novembre 2011. Elisabetta Di Nitto Raffaela Mirandola

Project Planning. Politecnico di Milano. Progetto di Ingegneria del Software 2. 15 novembre 2011. Elisabetta Di Nitto Raffaela Mirandola Politecnico di Milano Progetto di Ingegneria del Software 2 Project Planning Autori: Claudia Foglieni Giovanni Matteo Fumarola Massimo Maggi Professori: Elisabetta Di Nitto Raffaela Mirandola 15 novembre

Dettagli

NetCrunch 6. Server per il controllo della rete aziendale. Controlla

NetCrunch 6. Server per il controllo della rete aziendale. Controlla AdRem NetCrunch 6 Server per il controllo della rete aziendale Con NetCrunch puoi tenere sotto controllo ogni applicazione, servizio, server e apparato critico della tua azienda. Documenta Esplora la topologia

Dettagli

I Modelli della Ricerca Operativa

I Modelli della Ricerca Operativa Capitolo 1 I Modelli della Ricerca Operativa 1.1 L approccio modellistico Il termine modello è di solito usato per indicare una costruzione artificiale realizzata per evidenziare proprietà specifiche di

Dettagli

BOARD 8.1: Cosa c è di nuovo

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

Dettagli

Base Dati Introduzione

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

Dettagli

3. SOFTWARE MANAGEMENT

3. SOFTWARE MANAGEMENT 3. SOFTWARE MANAGEMENT Introdurre caratteristiche e problematiche della direzione di progetto software (software management) Discutere la pianificazione di un progetto e la temporizzazione (scheduling)

Dettagli

Sistema sicurezza: rilevazione preventiva dei rischi

Sistema sicurezza: rilevazione preventiva dei rischi Concorso INAIL 2010 Sistema sicurezza: rilevazione preventiva dei rischi Documento di progetto Lucrezia Repetti Classe 5 I1- a.s. 2009-2010 ISII Tecnico G. Marconi - Piacenza Gennaio 2010 2 SOMMARIO SOMMARIO...

Dettagli

LBINT. http://www.liveboxcloud.com

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

Dettagli

Metodologia TenStep. Maggio 2014 Vito Madaio - TenStep Italia

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

Dettagli

Componenti di una applicazione. Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali:

Componenti di una applicazione. Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali: Componenti di una applicazione Un programma applicativo è strutturato come un insieme organizzato di tre componenti funzionali: Un sottosistema di interfaccia con l utente (IU, user interface o anche presentation

Dettagli

CONCETTI DI BASE PER LA QUALITA

CONCETTI DI BASE PER LA QUALITA CONCETTI DI BASE PER LA QUALITA Misura: è una funzione m: A -> B che associa ad ogni attributo A di un osservabile nel mondo reale o empirico (dominio) un oggetto formale B nel mondo matematico (range);

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

Business white paper. Sette best practice per creare applicazioni che rispondano alle esigenze aziendali

Business white paper. Sette best practice per creare applicazioni che rispondano alle esigenze aziendali Business white paper Sette best practice per creare applicazioni che rispondano alle esigenze aziendali Indice 3 Sommario esecutivo 3 Introduzione 3 Best practice a livello aziendale 5 Best practice a

Dettagli

TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE

TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE TECNOLOGIE DELL INFORMAZIONE E DELLA COMUNICAZIONE PER LE AZIENDE Materiale di supporto alla didattica Tecnologie dell informazione e della comunicazione per le aziende CAPITOLO 3: Progettazione e sviluppo

Dettagli

SCELTA DEL TEST DA ESEGUIRE

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

Dettagli

Registro SPICCA Architettura del Software

Registro SPICCA Architettura del Software Registro SPICCA Architettura del Software Versione 1.0 del 25/08/2009 Sommario 1 Introduzione... 4 1.1 Scopo... 4 1.2 Obiettivo... 4 1.3 Riferimenti... 4 1.4 Panoramica del documento... 4 2 Rappresentazione

Dettagli

PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI

PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI PROGETTI DISPONIBILI IL CORSO DI PROGETTO DI RETI E SISTEMI INFORMATICI 1 Web Link Monitor... 2 2 Database Browser... 4 3 Network Monitor... 5 4 Ghost Site... 7 5 Copy Search... 9 6 Remote Audio Video

Dettagli

CORSO DI FORMAZIONE PER: TECNICO DELLE ATTIVITA' DI PROGETTAZIONE, SVILUPPO E AGGIORNAMENTO DI SITI WEB

CORSO DI FORMAZIONE PER: TECNICO DELLE ATTIVITA' DI PROGETTAZIONE, SVILUPPO E AGGIORNAMENTO DI SITI WEB Avviso Pubblico PROV-BR 02/2013 PO FSE 2007/2013 ASSE II OCCUPABILITA' Formazione per Inserimento-Reinserimento Lavorativo Approvato con D.D. n.85 del 24/01/2014, pubblicata sul BURP n. 17 del 06/02/2014

Dettagli

SCP: SCHEDULER LAYER. a cura di. Alberto Boccato

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

Dettagli

DD - Design Document

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

Dettagli

La Document Orientation. Come implementare un interfaccia

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

Dettagli

Descrizione generale. Architettura del sistema

Descrizione generale. Architettura del sistema Descrizione generale Sister.Net nasce dall esigenza di avere un sistema generale di Cooperazione Applicativa tra Enti nel settore dell Informazione Geografica che consenta la realizzazione progressiva

Dettagli

Framework di Middleware. per Architetture Enterprise

Framework di Middleware. per Architetture Enterprise Framework di Middleware per Architetture Enterprise Corso di Ingegneria del Software A.A.2011-2012 Un po di storia 1998: Sun Microsystem comprende l importanza del World Wide Web come possibile interfaccia

Dettagli

CAPITOLO 19: COSTRUIRE SISTEMI IN SICUREZZA (a.a. 2007/2008) Professore:Stefano Bistarelli Studentessa: Assunta Di Giorgio

CAPITOLO 19: COSTRUIRE SISTEMI IN SICUREZZA (a.a. 2007/2008) Professore:Stefano Bistarelli Studentessa: Assunta Di Giorgio CAPITOLO 19: COSTRUIRE SISTEMI IN SICUREZZA (a.a. 2007/2008) Professore:Stefano Bistarelli Studentessa: Assunta Di Giorgio COSTRUIRE SISTEMI IN SICUREZZA Sicurezza nella definizione dei requisiti e nell

Dettagli

Classificazione Nuovo Esame PMP

Classificazione Nuovo Esame PMP Notizie sul nuovo esame PMP a partire dal Agosto 0 Classificazione Nuovo Esame PMP Questo è il link al documento del PMI: Crosswalk Between Current and New PMP Classifications del PMI Di seguito trovi

Dettagli

ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE

ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE Allegato 1.4 Cicli di vita del software Pagina 1 di 20 Indice 1 CICLI DI VITA... 3 1.1 Ciclo di Sviluppo...3 1.2 Ciclo di Manutenzione...5 2 LE FASI PROGETTUALI...

Dettagli

ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE

ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE Allegato 1.4 Cicli di vita del software Pagina 1 di 20 Indice 1 CICLI DI VITA... 3 1.1 Ciclo di Sviluppo... 3 1.2 Ciclo di Manutenzione... 5 2 LE FASI PROGETTUALI...

Dettagli

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB

SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica SVILUPPO ONTOLOGIE PER LA GESTIONE DOCUMENTALE E LORO INTEGRAZIONE ALL INTERNO DI UNA PIATTAFORMA WEB Relatore Chiarissimo

Dettagli

Sviluppo di un applicazione mobile per la gestione degli interventi tecnici tramite geolocalizzazione

Sviluppo di un applicazione mobile per la gestione degli interventi tecnici tramite geolocalizzazione UNIVERSITA DEGLI STUDI DI FERRARA Corso di Laurea in informatica Anno Accademico 2011-2012 Sviluppo di un applicazione mobile per la gestione degli interventi tecnici tramite geolocalizzazione Relatore:

Dettagli

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0

PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO 147 6/001.0 PIANIFICAZIONE E REALIZZAZIONE DI UN SISTEMA INFORMATIVO ELEMENTI FONDAMENTALI PER LO SVILUPPO DI SISTEMI INFORMATIVI ELABORAZIONE DI

Dettagli

Object-Relational Mapping

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

Dettagli

Ingegneria dei Requisiti

Ingegneria dei Requisiti Corso di Laurea Specialistica in Ingegneria Informatica Corso di Ingegneria del Software A. A. 2008 - Ingegneria dei Requisiti E. TINELLI Contenuti I requisiti del software Documento dei requisiti I processi

Dettagli

Single Sign On sul web

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

Dettagli

Studio di fattibilità (2) Identificazione ed analisi dei requisiti

Studio di fattibilità (2) Identificazione ed analisi dei requisiti Prime fasi nella produzione del software &RUVR GL,QJHJQHULD GHO 6RIWZDUH Capitolato d appalto o doc. formale di richiesta prodotto Incontri con il committente e/o interviste Esercitazione Studio del dominio

Dettagli

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

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

Dettagli

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

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

Dettagli

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

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

Dettagli

Il diagramma dei casi d uso

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

Dettagli

Indice REGIONE BASILICATA

Indice REGIONE BASILICATA DIPARTIMENTO PROGRAMMAZIONE UFFICIO SISTEMA INFORMATIVO REGIONALE E Via Vincenzo Verrastro n 4 fax 0971/668954 REGI ONE BASI UFFICIO S. I. LICA R. S. TA Piano dei Test Id Sistema APPROVAZIONI Redatto da:

Dettagli

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione

Introduzione. File System Distribuiti. Nominazione e Trasparenza. Struttura dei DFS. Strutture di Nominazione File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema Introduzione File System Distribuito

Dettagli

File System Distribuiti

File System Distribuiti File System Distribuiti Introduzione Nominazione e Trasparenza Accesso ai File Remoti Servizio Con/Senza Informazione di Stato Replica dei File Un esempio di sistema 20.1 Introduzione File System Distribuito

Dettagli

SINPAWEB corso per Tecnico della programmazione e dello sviluppo di siti internet e pagine web co.reg 58036 matricola 2012LU1072

SINPAWEB corso per Tecnico della programmazione e dello sviluppo di siti internet e pagine web co.reg 58036 matricola 2012LU1072 Provincia di Lucca Servizio Istruzione, Formazione e Lavoro. Sviluppo Economico SINPAWEB corso per Tecnico della programmazione e dello sviluppo di siti internet e pagine web co.reg 58036 matricola 2012LU1072

Dettagli

ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE

ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE ALLEGATO 1.4 CICLI DI VITA DEL SOFTWARE Allegato 1.4 Cicli di vita del software Pagina 1 di 16 Indice 1 CICLI DI VITA... 3 1.1 Ciclo di Sviluppo... 3 1.2 Ciclo di Manutenzione... 5 2 LE FASI PROGETTUALI...

Dettagli

TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE

TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE ISTRUZIONE E FORMAZIONE TECNICA SUPERIORE SETTORE INDUSTRIA E ARTIGIANATO TECNICO SUPERIORE PER IL SISTEMA INFORMATIVO AZIENDALE STANDARD MINIMI DELLE COMPETENZE TECNICO PROFESSIONALI DESCRIZIONE DELLA

Dettagli

Applicazione: OIL Online Interactive helpdesk

Applicazione: OIL Online Interactive helpdesk Riusabilità del software - Catalogo delle applicazioni: Gestione ICT Applicazione: OIL Online Interactive helpdesk Amministrazione: Consiglio Nazionale delle Ricerche (CNR) Responsabile dei sistemi informativi

Dettagli

Novell ZENworks Configuration Management in ambiente Microsoft * Windows *

Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Guida GESTIONE SISTEMI www.novell.com Novell ZENworks Configuration Management in ambiente Microsoft * Windows * Novell ZENworks Configuration Management in ambiente Microsoft Windows Indice: 2..... Benvenuti

Dettagli

Guida al livellamento delle risorse con logica Critical Chain (2 parte)

Guida al livellamento delle risorse con logica Critical Chain (2 parte) Paolo Mazzoni 2011. E' ammessa la riproduzione per scopi di ricerca e didattici se viene citata la fonte completa nella seguente formula: "di Paolo Mazzoni, www.paolomazzoni.it, (c) 2011". Non sono ammesse

Dettagli