Tesi Giuseppe Chechile

UNIVERSITÀ DEGLI STUDI DI TRIESTE FACOLTÀ DI INGEGNERIA CORSO DI LAUREA TRIENNALE IN INGEGNERIA INFORMATICA Dipartimento di Elettrotecnica, Elettronica e Informatica TESI DI LAUREA IN BASI DI DATI PROGETTO E SVILUPPO DI UN’APPLICAZIONE WEB PER LA GESTIONE DI RICHIESTE DI ASSISTENZA Laureando:Relatore: Giuseppe CHECHILEProf. Maurizio FERMEGLIA ANNO ACCADEMICO 2008-2009 Indice Introduzione ..................................................................................................................... 3 Capitolo 1: analisi e progettazione ................................................................................ 4 CRM ................................................................................................................ 5 Trouble ticket system ..................................................................................... 5 1.3 Requisiti ........................................................................................................... 6 1.4 Progettazione Architetturale ......................................................................... 6 1.5 Progettazione Database .................................................................................. 9 1.5.1 Operazioni eseguite sul database ...................................................... 9 1.5.2 Glossario dei termini ......................................................................... 10 1.5.3 Schema modello concettuale Entity-Relationship ............................ 10 1.5.4 Analisi delle entità e delle relazioni .................................................. 11 1.6 Progettazione Software ................................................................................. 13 1.6.1 Casi d’uso ......................................................................................... 13 1.6.2 Attori coinvolti .................................................................................. 14 1.6.3 Diagramma UML dei casi d’uso ....................................................... 14 Capitolo 2: realizzazione ................................................................................................16 2.1 Interfaccia .......................................................................................................16 2.1.1 Configurazione sistema .....................................................................16 2.1.2 Esempi di utilizzo da parte dell’Utente .............................................16 2.1.3 Esempi di utilizzo da parte dell’Operatore ........................................20 2.1.4 Esempi di utilizzo da parte dell’Amministratore ...............................23 2.2 Implementazione sistema ..............................................................................25 2.2.1 Progettazione logica database ............................................................25 2.2.2 Consultant software application ........................................................26 2.2.2.1 Autenticazione ....................................................................27 2.2.2.2 Assegnazione di un incident ...............................................28 2.2.2.3 Aggiornamento di un incident ............................................29 2.2.2.4 Visualizzazione incident risolti ...........................................29 2.2.2.5 Operazioni di amministrazione ...........................................30 2.2.3 Portale web ........................................................................................30 2.2.3.1 Autenticazione ....................................................................31 2.2.3.2 Visualizzazione degli incident aperti ..................................31 2.2.3.3 Visualizzazione degli incident risolti ..................................33 2.2.3.4 Inserimento nuova richiesta di assistenza ...........................34 2.2.3.5 Comunicazioni con l’operatore ...........................................35 Conclusione ....................................................................................................................... 36 Bibliografia ........................................................................................................................ 37 Introduzione L’argomento trattato in questa tesi riguarda lo sviluppo di un prototipo di trouble ticket system. In particolare, il sistema tratterà richieste di assistenza riguardanti problemi relativi a prodotti informatici di tipo hardware e software. L’obbiettivo è quello di produrre un sistema software che sia di supporto ad un team di operatori in grado di soddisfare le richieste di assistenza. Il sistema dovrà essere in grado di ricevere le richieste di assistenza, inoltrare tali richieste ad un operatore in grado di risolvere il problema e di inviarne la soluzione all’utente che ne ha fatto richiesta. La creazione del prototipo di trouble ticket system prevede lo sviluppo di: un’interfaccia web dedicata agli utenti che ha il compito di ricevere nuove richieste di assistenza, di aggiornare l’utente riguardo lo stato di avanzamento del trattamento del suo problema e di dare la possibilità all’utente di visualizzare le proprie richieste avanzate in passato. un database contenente dati relativi agli utenti che fanno richiesta di assistenza, agli operatori del sistema che hanno il compito di trovare una soluzione alle richieste di assistenza, a tutte le fasi del trattamento del problema e alla gestione generale del sistema. un interfaccia window form dedicata agli operatori e all’amministratore del sistema che è in grado di assegnare agli operatori le richieste da parte degli utenti, di aggiornare lo stato di una richiesta, di inviare una proposta di soluzione al problema e di visualizzare le richieste risolte. Questa interfaccia consente inoltre all’amministratore di gestire i prodotti oggetto di cui si offre assistenza e i dati relativi a utenti e operatori. Il prototipo di trouble ticket system è stato sviluppato in compatibilità con Microsoft Windows Vista e Microsoft Internet Explorer 8. Come ambiente di sviluppo dell’interfaccia window e web è stato utilizzato Microsoft Visual Studio 2008 e come linguaggio di programmazione VB.NET. Come ambiente di utilizzo nella fase di test è stato utilizzato Microsoft Windows Server 2003. Per la creazione e gestione del database è stato utilizzato Microsoft SQL Server 2008. Il sistema richiede il pacchetto Microsoft .Net Framework 3.5. I successivi capitoli descrivono il problema relativo alla gestione di richieste di assistenza, le basi teoriche per lo sviluppo del sistema, le fasi relative all’analisi del problema, alla progettazione e allo sviluppo del prototipo del sistema di gestione delle richieste di assistenza. Capitolo 1: analisi e progettazione Nella prima parte di questo capitolo si descrive brevemente la teoria che sta alla base del problema della gestione delle richieste di assistenza. Successivamente si tratterà l’analisi del problema per arrivare alla definizione della struttura di ciò che verrà utilizzato all’interno del prototipo. CRM – Customer Relationship Management Il CRM è un sistema di processi per la gestione della relazione con i clienti, attraverso il quale si possono costruire relazioni personalizzate e prolungate al fine di aumentare la soddisfazione della clientela. Il CRM può essere suddiviso in tre tipologie: CRM operativo: soluzioni per automatizzare i processi che prevedono il contatto diretto con il cliente. CRM analitico: procedure e strumenti per migliorare la conoscenza del cliente al fine di poter effettuare uno studio sui comportamenti dei clienti stessi. CRM direzionale: metodologie e tecnologie integrate per pianificare l’atteggiamento dell’azienda nei confronti del cliente. Il problema relativo alla gestione delle richieste di assistenza viene affrontato mediante lo sviluppo di un sottosistema di CRM di tipo operativo. Si cercherà infatti di produrre un prototipo di sistema, in grado di automatizzare la ricezione delle richieste di aiuto e di offrire un supporto per l’invio di risposte da parte dell’operatore attraverso l’utilizzo di un trouble ticket system. Trouble ticket system Un trouble ticket system è un pacchetto software in grado di gestire elenchi di problemi in base all’esigenze di un’azienda o di un’organizzazione. Generalmente un sistema di questo tipo, detto anche issue tracking system, è utilizzato per ricevere, aggiornare e risolvere i problemi segnalati da clienti o da utenti interni all’organizzazione. Il termine “ticket” in questo contesto rappresenta un dato all’interno dell’ issue tracking system, contenente informazioni relative agli interventi di assistenza da parte del personale di supporto tecnico. I “ticket” sono generalmente creati in un help desk o in un call center e identificati univocamente, in modo tale da poter risalire rapidamente alle informazioni relative all’utente, al problema e a tutto il personale che ha preso parte alla creazione di una soluzione. Generalmente le informazioni contenute in un “ticket” riguardano dati relativi a chi genera la richiesta di assistenza, al problema riscontrato dall’utente e a chi il problema lo deve risolvere. Requisiti Dopo aver preso visione in generale dell’issue tracking system, si definiscono i requisiti specifici per il sistema da sviluppare: L’interfaccia dedicata all’utente per le sue operazioni è un portale web. Solo un utente autorizzato può avere accesso al portale web. La prima pagina visualizzata dall’utente deve contenere l’elenco di tutte le sue richieste ancora in fase di risoluzione. Dare la possibilità all’utente di effettuare richieste di assistenza. Dare all’utente una vista informativa aggiornata sullo stato di trattamento delle sue richieste. Rendere visibile uno storico delle richieste risolte all’utente. Gli operatori dovranno utilizzare un’applicazione window form per la gestione dei problemi. Un operatore deve essere in grado di prendere in considerazione le richieste di assistenza che non sono state ancora assegnate. Al problema preso in considerazione deve essere assegnata una priorità che sarà invisibile all’utente. Un operatore deve poter aggiornare lo stato di avanzamento della risoluzione dei problemi. L’operatore deve poter contattare l’utente per una comunicazione informativa, una richiesta di informazioni aggiuntive o inviare una proposta di soluzione. L’utente deve essere in grado di rispondere alle comunicazioni da parte di un operatore quando queste vengono richieste. L’operatore deve essere in grado di chiudere la pratica relativa ad un problema risolto. Ogni operazione di aggiunta, aggiornamento o chiusura deve essere archiviata. Ogni comunicazione tra operatore e utente deve essere archiviata. Deve essere presente un operatore con privilegi di amministratore. L’amministratore deve poter eseguire operazioni di inserimento e di aggiornamento su dati relativi ai prodotti dei quali si offre assistenza. L’amministratore deve essere in grado di inserire e aggiornare i dati relativi agli operatori del sistema. Progettazione architetturale Da un’analisi dei requisiti si ottengono le principali funzionalità del sistema da realizzare: Interfaccia web per gli utenti che permetta l’invio di richieste di assistenza, che dia una visione dettagliata e aggiornata su ticket presenti e passati e che permetta la comunicazione con gli operatori. Interfaccia Window Form per gli operatori che sia di supporto per la gestione dei ticket e per la comunicazione con l’utenza. Verifica delle credenziali di utenti e operatori. Uso di un database per l’archiviazione dei ticket e dei dati necessari alla gestione del sistema stesso. Interazione con un DBMS per le operazioni sul database. Utilizzo di email “no reply” per le comunicazioni all’utente da parte dell’operatore. Si procede con lo sviluppo di uno schema generale dell’architettura del trouble ticket system. Basandosi sui requisiti precedentemente definiti, si descrivono le procedure con cui si intende rendere possibili le funzionalità del sistema. Si descrivono ora i principali eventi che consentono all’utente di inviare la richiesta di assistenza in presenza di un problema relativo ad uno dei prodotti trattati dal sistema: La nascita di un problema irrisolvibile da parte dell’utente rende necessaria una richiesta di assistenza. L’utente iscritto al sistema consulta il portale web per la richiesta di assistenza. Dopo essersi autenticato e aver descritto il problema sul portale web il sistema invia una richiesta di soluzione. La richiesta di soluzione deve contenere dati relativi al tipo di problema, al prodotto su cui si è verificato il problema e all’utente. La richiesta di soluzione viene inserita nel database. Di seguito è rappresentato un diagramma del sistema per la richiesta di assistenza. Fig. 1.1: Diagramma del sistema per la richiesta di assistenza Si procede con la descrizione delle procedure di gestione del ticket che portano l’operatore dall’acquisizione dei dati relativi al problema alla creazione di una proposta di soluzione per l’utente: L’operatore consulta il database attraverso l’applicazione window form per poter utilizzare i dati relativi al problema da risolvere. L’operatore genera una proposta di soluzione al problema dell’utente attraverso i dati ottenuti dal sistema. La proposta di soluzione viene comunicata all’utente via mail. Ricevuta la proposta di soluzione, l’utente contatta il portale web e genera una risposta per l’operatore. La risposta da parte dell’utente viene inserita nel database. L’operatore legge la risposta dell’utente attraverso l’applicazione per la gestione dei ticket a sua disposizione. In caso di risposta positiva dell’utente alla proposta di soluzione, il ticket verrà chiuso, altrimenti l’operatore dovrà generare una nuova proposta di soluzione in base alla risposta dell’utente. Diagramma del sistema per la gestione da parte dell’operatore: Fig. 1.2: Diagramma del sistema per la gestione del ticket Progettazione Database In questo paragrafo si descrive l’analisi e la progettazione che porterà alla definizione dello schema concettuale del database per l’archiviazione dei dati relativi ai ticket. Operazioni eseguite sul database Si definiscono le operazioni eseguite sulla base di dati relativamente alle principali entità del sistema per la gestione delle richieste di assistenza: CONSULTANT: (a) Inserimento dati Consultant. (b) Aggiornamento dati Consultant. USERS: (a) Inserimento dati User. (b) Aggiornamento dati User. PRODUCT: (a) Inserimento dati nuovo Prodotto. (b) Aggiornamento dati Prodotto. INCIDENT: (a) Inserimento dati nuovo Incident. CAMBIAMENTO: (a) Inserimento dati nuovo Cambiamento. Glossario dei termini Si descrivono i termini relativi a entità e relazioni utilizzate nello schema concettuale del database. Consultant: è l’operatore che si occupa di risolvere i problemi degli Users. Users: è l’utente che fa richiesta di assistenza al sistema. Product: è il prodotto sul quale il sistema offre assistenza. Incident: è il problema che l’User sottopone al Consultant chiedendone la soluzione. Cambiamento: rappresenta ogni evento relativo all’Incident dopo la sua creazione. Schema modello concettuale Entity-Relationship Si definiscono le principali entità e relazioni per la creazione dello schema Entity-Relationship (E-R). Le entità utilizzate nello schema E-R sono: Consultant; Users; Product; Incident; Cambiamento. Le relazioni tra le entità dello schema sono: Risolve: relazione tra l’entità Consultant e Incident; Riguarda: relazione tra l’entità Incident e Product; Genera: relazione tra l’entità Users e Incident; Aggiorna: relazione tra l’entità Cambiamento e Incident. Di seguito viene rappresentato lo schema E-R. Fig. 1.3: Schema E-R Analisi delle entità e delle relazioni Si procede con un’ulteriore analisi delle entità e delle relazioni al fine di definire gli attributi per gli elementi dello schema E-R. ConsultantConsultantIDCodice che identifica univocamente ConsultantNomeDescrive il nome dell’operatoreCognomeDescrive il cognome dell’operatoreMailRappresenta l’indirizzo di posta elettronica dell’operatoreAmministratoreDefinisce se il Consultant ha privilegi di amministratore o meno UsersUserIDCodice che identifica univocamente UsersNomeDescrive il nome dell’utenteCognomeDescrive il cognome dell’utenteTelefonoRappresenta il recapito telefonico dell’utenteMailRappresenta l’indirizzo di posta elettronica dell’utente IncidentIncidentIDCodice che identifica univocamente IncidentDataRappresenta la data in cui il problema è stato segnalatoStatoDefinisce lo stato in cui si trova l’Incident nel momento presenteUrgenzaDefinisce l’importanza dell’IncidentNoteDescrizione del problemaAllegatoFile che l’utente può inserire per descrivere il problemaNomeAllegatoDescrive il nome dell’Allegato ProductProductIDCodice che identifica univocamente ProductNomeDefinisce il nome del prodotto oggetto di assistenzaTipoRappresenta la categoria del Product CambiamentoCambiamentoIDCodice che identifica univocamente CambiamentoDataRappresenta la data in cui si verifica un aggiornamento dell’IncidentOggettoDescrive l’oggetto che ha generato il CambiamentoDescrizioneDescrive in dettaglio il CambiamentoAllegatoFile che può essere l’oggetto del Cambiamento stessoNomeAllegatoDescrive il nome dell’Allegato RisolveCollega l’entità Consultant e Incident, definendo ogni intervento di assistenza di un operatore.Cardinalità uno a molti: ogni Incident può essere assegnato solo ad un Consultant, mentre un Consultant può risolvere Incident diversi. Un Incident non è assegnato al momento della sua creazione. RiguardaCollega l’entità Incident e Product, definendo il prodotto oggetto del problema.Cardinalità uno a molti: ogni Incident può trattare un solo prodotto, mentre un prodotto può essere oggetto di diversi Incident. Ogni Incident deve trattare un prodotto, ma un prodotto può non essere oggetto di problemi. GeneraCollega l’entità Users e Incident, definendo l’utente che ha richiesto assistenza per il problema.Cardinalità uno a molti: ogni Incident deve avere un solo utente, mentre un utente può aver fatto richiesta di assistenza per molti problemi. Ogni Incident deve avere un utente e ogni utente deve aver almeno un Incident. AggiornaCollega l’entità Cambiamento e Incident, definendo gli eventi relativi ad un Incident.Cardinalità uno a molti: ogni Cambiamento è relativo ad un Incident, mentre ogni Incident ha molti cambiamenti. Un Incident non ha cambiamenti al momento della sua creazione, mentre un Cambiamento deve essere riferito ad un Incident. Dopo aver definito gli attributi delle entità, si può disegnare il seguente schema E-R con gli attributi appena definiti. Fig. 1.4: Schema E-R con attributi Progettazione software In questa sezione vengono analizzati i principali casi d’uso dell’applicazione relativamente agli utilizzatori del sistema, anche attraverso l’utilizzo di modelli Unified Modeling Language (UML). Casi d’uso Di seguito vengono elencate le principali operazioni che verranno effettuate sul sistema, indicando il soggetto che esegue tale operazione. OperazioneSoggettoInserimento nuovo IncidentUtenteAssegnazione dell’Incident ad un OperatoreOperatoreInserimento nuovo CambiamentoOperatore/Sistema/UtenteAggiornamento dello Stato dell’IncidentOperatore/SistemaInvio di una email di notifica all’UtenteOperatoreInvio di una email con la proposta di soluzione all’UtenteOperatoreInserimento nuovo UtenteSistemaInserimento nuovo OperatoreAmministratoreAggiornamento dati OperatoreAmministratoreInserimento nuovo ProdottoAmministratoreAggiornamento dati ProdottoAmministratoreChiusura di un IncidentOperatoreVisualizzazione dettagli Incident e relativi CambiamentiOperatore/Utente/Amm.Risposta da parte di un Utente all’OperatoreUtente Alcune operazioni appena definite hanno più di un soggetto, in questi casi le operazioni possono essere semplicemente effettuate da diversi soggetti. Il caso dell’operazione di visualizzazione degli Incident e relativi Cambiamenti è vincolata al tipo di soggetto che l’ha effettuata: un Utente può visualizzare i dati dei propri Incident, un Operatore può visualizzare i dati di tutti gli Incident che ha risolto o sta cercando di risolvere e l’Amministratore può visualizzare i dati relativi a tutti gli Incident. Attori coinvolti Nella definizione delle operazioni effettuate sul sistema sono stati definiti 4 soggetti: Utente: sono le persone che richiedono assistenza per un problema. Operatore: sono le persone che hanno il compito di risolvere i problemi segnalati dagli Utenti. Amministratore: sono uno o più Operatori con privilegi che consentono loro operazioni di inserimento e gestione relativamente a Prodotti, Operatori e Utenti. Sistema: rappresenta un’ operazione automatica da parte del sistema. Diagramma UML dei casi d’uso Di seguito sono rappresentati i principali casi d’uso utilizzando un diagramma UML. Fig. 1.5: Diagramma UML Capitolo 2 : realizzazione In questo capitolo si descrivono, nella prima parte, la configurazione necessaria al funzionamento del prototipo ed alcuni esempi di utilizzo del sistema. Nella seconda parte si descrive l’implementazione del sistema, descrivendo la realizzazione di quelle componenti descritte in fase di analisi e progettazione. 2.1 Interfaccia In questa sezione si descrive il modo in cui il sistema è utilizzato da parte dell’utente, dell’operatore e dell’amministratore. Prima di illustrare le modalità di utilizzo del trouble ticket system, si descrive la configurazione necessaria al sistema. Configurazione del sistema In questa sezione si anticipano componenti descritti nella parte finale di questo capitolo. Il sistema, per come è stato progettato, necessita, per funzionare, della presenza di un DBMS per la base di dati e di un Web server per l’interfaccia dedicata all’utente. Sia il DBMS che il Web server necessitano di un amministratore esterno al truoble ticket system per la configurazione, in particolare per la parte relativa alle autorizzazioni di operatori ed utenti. La necessità di un’amministrazione esterna verrà ripresa in seguito, nella descrizione dell’infrastruttura utilizzata dal prototipo. Esempi di utilizzo da parte dell’Utente In questa sezione si descrive il modo in cui l’utente può utilizzare l’interfaccia web a lui dedicata per eseguire le funzioni descritte nelle sezioni precedenti. Dopo la connessione al portale web e la propria autenticazione, l’utente ha una vista sulle sue richieste di assistenza non ancora risolte. Dalla pagina iniziale l’utente avrà anche la possibilità di accedere alle principali funzioni attraverso dei link che verranno discussi nei punti successivi. Fig. 2.1: Dettaglio della pagina di default del portale web L’utente ha la possibilità di vedere i dettagli di un ticket in una nuova pagina, cliccando un valore della colonna IncidentID della tabella in figura 2.1. In questa nuova pagina sono visibili sia dati principali che i cambiamenti relativi all’incident raccolti, rispettivamente in una tabella di dettaglio (fig. 2.2 in alto) e in una tabella riassuntiva (fig. 2.2 in basso). L’utente ha la possibilità di effettuare un download dell’allegato alla propria richiesta di assistenza cliccando il bottone “Salva” (fig. 2.2). Fig. 2.2: Dettaglio della pagina del portale web con informazioni dell’incident Si possono vedere i dettagli di un singolo cambiamento in una nuova pagina, alla quale si può accedere dalla pagina di dettaglio di un incident, cliccando i valori della colonna CambiamentoId nella tabella in figura 2.2. La nuova pagina contiene una tabella di dettaglio per le informazioni del cambiamento e un bottone per il download degli allegati, similmente a quanto visto al punto precedente. L’inserimento un nuovo incident viene effettuato compilando un form in una pagina dedicata ai nuovi incident, raggiungibile cliccando il bottone “Nuovo Incident” della pagina iniziale (fig. 2.1). La compilazione del form prevede la scelta del tipo e il nome del prodotto oggetto del problema, la descrizione del problema ed eventualmente l’upload di un allegato (fig. 2.3). Dopo la compilazione del form è possibile proseguire con la richiesta di aiuto cliccando il bottone “Insert” o annullare l’operazione cliccando il bottone “Cancel” (fig.2.3 in basso). Fig. 2.3: Dettaglio della pagina web dedicata ad una nuova richiesta di aiuto La risposta ad una comunicazione da parte di un operatore è affidata ad un form in una pagina dedicata (fig. 2.4). L’accesso a questa pagina è possibile solo attraverso un link comunicato via mail dall’operatore. La compilazione del form da parte dell’utente prevede l’inserimento di un “oggetto” e una descrizione di ciò che gli è stato richiesto, è inoltre possibile aggiungere un allegato. Fig. 2.4: Dettaglio della pagina web dedicata alla comunicazione con l’operatore Il procedimento per la visualizzazione dei dati relativi agli incident risolti è del tutto simile a quello utilizzato per gli incident ancora in fase di risoluzione. La pagina con i dati di interesse è raggiungibile cliccando il bottone “Incident risolti” nella pagina principale (fig. 2.1 in basso). Il modo in cui i dati relativi all’incident e ai suoi cambiamenti è identico a quello descritto in precedenza e visualizzato nella figura 2.2. Esempi di utilizzo da parte dell’Operatore In questa sezione si descrive ora il modo in cui un operatore può utilizzare la Consultant software application a lui dedicata per eseguire le funzioni descritte nelle sezioni precedenti. L’operatore dopo l’autenticazione ha a disposizione un menu per la selezione delle sue principali operazioni. La finestra di menu contiene informazioni relative al numero di incident non ancora assegnati e al numero di incident aperti e chiusi che hanno come Consultant l’operatore che sta utilizzando il sistema (fig. 2.5). Fig. 2.5: Menu dell’applicazione per l’operatore L’assegnazione dell’incident viene effettuata da un operatore in una finestra dedicata, contente l’elenco degli incident ancora non assegnati. La finestra è raggiungibile dal menu cliccando il bottone “Risolvi” (fig.2.5). L’operatore seleziona un elemento dalla lista degli incident senza operatore, ne assegna la priorità che ritiene adeguata al problema e conferma l’assegnazione dell’incident premendo il bottone “Prendi in considerazione” (fig. 2.6). Questo procedimento può essere ripetuto per tutti gli incident della lista. Per annullare un’assegnazione o per chiudere la finestra dopo un’operazione si preme il bottone “Esci” (fig. 2.6 in basso). Fig. 2.6: Finestra per l’assegnazione dell’incident Le operazioni principali dell’operatore su un incident preso in considerazione partono dalla selezione dell’incident su cui lavorare; questa scelta è possibile in una nuova finestra raggiungibile dal menu con la pressione del bottone “Aggiorna”. Fig. 2.7: Finestra per la selezione dell’incident da aggiornare Dalla finestra di dettaglio dell’incident si possono visualizzare tutte le informazioni dell’incident stesso e la lista di tutti i suoi cambiamenti. Si può cambiare lo stato dell’incident cliccando il bottone “Cambia stato”, dopo aver selezionato il nuovo stato ed eventualmente descrivendo le motivazioni del cambiamento. Inoltre si può avere accesso a due nuove finestre: una per mandare mail all’utente che ha generato l’incident e una per visualizzare i dettagli di un cambiamento. Per il download dell’allegato è sufficiente premere il bottone “Scarica allegato” (fig. 2.8). Fig. 2.8: Finestra di dettaglio dell’incident da aggiornare Si possono osservare le informazioni dettagliate di un cambiamento in una nuova finestra raggiungibile cliccando il bottone “Dettaglio” nella finestra di dettaglio incident (fig. 2.8). In questa nuova finestra, oltre alla visualizzazione dei dati del cambiamento, è possibile effettuare il download dell’eventuale allegato (fig. 2.9 in basso). Fig. 2.9: Finestra di dettaglio di un cambiamento dell’incident da aggiornare La finestra dedicata all’invio di mail all’utente è accessibile dalla finestra di dettaglio incident con la pressione del tasto “Manda mail” (fig. 2.8 in basso). La finestra contiene già i dati relativi all’utente destinatario. Per inviare la mail è necessario selezionare il tipo di mail da inviare, così facendo verranno suggeriti oggetto e corpo della mail. Dopo aver modificato opportunamente l’oggetto e il corpo, l’operatore può inviare la mail cliccando “Manda” (fig. 2.10 in basso). Con la pressione del bottone “Aggiungi allegato” è possibile allegare un file alla mail da spedire all’utente. Fig. 2.10: Finestra per l’invio di email all’utente Esempi di utilizzo da parte dell’Amministratore In questa sezione si descrive il modo in cui l’operatore, con privilegi d’amministratore, utilizza la consultant application. In questo caso particolare si descrivono solo le operazioni specifiche dell’amministratore, tralasciando le funzionalità del sistema disponibili all’operatore descritte nel paragrafo precedente. Dopo aver effettuato il login al sistema, l’amministratore visualizza una finestra di menu differente da quella di un semplice operatore. Infatti questa finestra di menu dà la possibilità di accedere alle funzioni di amministratore attraverso il pulsante “Gestione” (fig. 2.11). Fig. 2.11: Finestra di menu dell’amministratore Dalla finestra di menu principale è possibile accedere ad un nuovo menu che permette di eseguire le funzioni dedicate all’amministratore: la gestione degli operatori, la gestione dei prodotti e una vista su tutti gli incident trattati dal sistema. Ad ogni operazione appena descritta è dedicata una finestra. La finestra per la gestione degli operatori contiene una lista di tutti gli operatori del sistema, dà la possibilità di modificarne i dati e di aggiungerne di nuovi. Le operazioni di modifica e di inserimento vengono effettuate attraverso la compilazione di un form in nuove finestre raggiungibili dai bottoni “Modifica” e “Novo” (fig. 2.12). Fig. 2.12: Finestra dell’amministratore per la gestione degli operatori In modo identico a quanto accade per la gestione degli operatori, la finestra di gestione dei prodotti, oggetto di assistenza, contiene una lista dei prodotti e dà la possibilità di inserirne di nuovi o di modificare quelli già esistenti. Come al punto precedente, le operazioni di inserimento e d’aggiornamento vengono effettuate attraverso dei form in nuove finestre raggiungibili con la pressione dei bottoni “Modifica” e “Nuovo”. L’amministratore ha accesso ad una finestra che gli permette di avere una vista su tutti gli incident del sistema, anche su quelli di cui lui non è il Consultant. Il modo in cui l’amministratore può visualizzare i dati relativi agli incident è simile a quello descritto in precedenza per l’operatore. In questo caso però l’amministratore non può modificare i dati degli incident. Implementazione sistema In questa sezione si porteranno avanti i concetti presentati nella sezione di analisi, presentando il modo in cui sono state realizzate le componenti del prototipo di trouble ticket system. Progettazione logica database L’obbiettivo di questo paragrafo è quello di arrivare alla definizione del modello logico del database preso in considerazione in fase di analisi. Nella fase di analisi relativa alla progettazione concettuale della base di dati si era definito lo schema E-R con attributi. Ora si effettuerà uno studio su tale schema al fine di ottenere uno schema E-R ristrutturato. Lo schema concettuale non presenta ridondanze o generalizzazioni di entità, si può quindi arrivare allo schema E-R ristrutturato dopo la definizione degli identificatori primari. In questo caso gli identificatori primari sono tutti interni alle entità e non c’è bisogno di inserirne di nuovi. Si arriva alla definizione di uno schema E-R ristrutturato del tutto simile allo schema E-R con attributi. Avendo definito il modello concettuale e lo schema Entity-Relationship ristrutturato possiamo disegnare il seguente schema logico del database. Fig. 2.13: Modello logico del database Consultant software application Si descrive ora la realizzazione delle principali componenti della consultant software application. Lo schema seguente riproduce il modo in cui sono organizzate le form utilizzate per l’implementazione delle funzioni della consultant software application. Fig. 2.14: Schema delle form della consultant application Autenticazione L’autenticazione degli attori descritti in fase di analisi è di tipo SQL authentication ed è gestita dal server SQL scelto come DBMS per la base dati utilizzata per il prototipo. Come accennato in precedenza, questa scelta rende necessaria una configurazione esterna da parte dell’amministratore del server SQL, che ha il compito di inserire gli utilizzatori della consultant software application tra gli utenti dell’DBMS e di autorizzarli ad effettuare operazioni sul database. L’username e la password necessari all’autenticazione dell’utente vengono inseriti nella LoginForm, dalla quale si potrà proseguire alla MenuForm che verificherà le credenziali dell’utente. Nel caso in cui la connessione al database, mediante l’utilizzo dei dati inseriti nella LoginForm, non fosse andata a buon fine, il sistema impedirà all’utente di proseguire. Per quanto riguarda l’autenticazione degli amministratori del sistema si è utilizzato un metodo interno che si aggiunge a quello appena descritto: il sistema controlla se chi ha effettuato il login è un semplice operatore o un amministratore, attraverso un’interrogazione del database. Soltanto nel caso in cui l’utente appena autenticato sia stato riconosciuto come amministratore, nella finestra di menu verrà visualizzato il bottone “Gestione” (fig. 2.11), necessario per effettuare operazioni d’amministratore. Command = New ADODB.Command Command.ActiveConnection = Connection strCmd =
SELECT * FROM [Consultant]
& _
WHERE Consultant.[ConsultantID]
& _
LIKE '
& LoginForm.UsernameTextBox.Text &
';
Command.CommandText = strCmd rst = Command.Execute rst.MoveFirst() TextBoxNome.Text = RTrim(rst(
Nome
).Value) &

& _ RTrim(rst(
Cognome
).Value) TextBoxMail.Text = rst(
Mail
).Value Amministratore = rst(
Amministratore
).Value If Amministratore = False Then ButtonGestione.Visible = False End If rst.Close() Assegnazione di un incident All’operazione di assegnazione è stata dedicata la UnassignedForm (fig. 2.6), il cui funzionamento è stato descritto precedentemente. In particolare, la conferma dell’assegnazione dell’incident lancia due operazioni sul database: l’inserimento nella tabella Cambiamento di un nuovo record e l’aggiornamento di un record della tabella Incident. Di seguito il codice associato all’evento “Click” del bottone per l’assegnazione dell’incident: Dim indice As Integer Dim Connection As ADODB.Connection Dim Command As ADODB.Command Dim strCnn As String Dim strCmd As String indice = DataGridView1.CurrentRow.Index 'Connessione al server SQL di prova utilizzato per 'lo sviluppo del prototipo Connection = New ADODB.Connection strCnn =
Provider=SQLOLEDB; Data Source=SERVER-TULKAS;
& _
database=Prova; UID=
;
& _
Password=
& LoginForm.PasswordTextBox.Text &
;
Connection.Open(strCnn) 'DataGridView1 contiene gli incident non assegnati, 'indice il numero di riga puntata della DataGridView1 indice = DataGridView1.CurrentRow.Index 'DataGridView1(0, indice).Value.ToString è il valore 'dell'IncidentID della riga numero
indice
della DataGridView1 Command = New ADODB.Command Command.ActiveConnection = Connection strCmd =
UPDATE [Incident] SET
& _
[Stato]='Assigned',
& _
[Urgenza]='
& ComboBoxUrgenza.SelectedItem.ToString &
',
& _
[ConsultantID]='
'
& _
WHERE [IncidentID]='
& DataGridView1(0, indice).Value.ToString _ &
' ;
Command.CommandText = strCmd Command.Execute() Command = New ADODB.Command Command.ActiveConnection = Connection strCmd =
INSERT INTO [Cambiamento] ([Data], [Oggetto],
& _
[Descrizione], [Allegato], [NomeAllegato], [IncidentID])
& _
VALUES (SYSDATETIME(), 'Assegnato',
& _
'Incident è stato assegnato', NULL, NULL,
& _
'
& DataGridView1(0, indice).Value.ToString &
');
Command.CommandText = strCmd Command.Execute() Connection.Close() Aggiornamento di un incident Per le operazioni di aggiornamento dell’incident vengono utilizzate in tutto quattro form: OpenForm (fig. 2.7), visualizza una lista di incident assegnati all’operatore che sta utilizzando il sistema. OpenDetailForm (fig. 2.8), è una vista dettagliata dell’incident selezionato nella DataGridView della OpenForm. Offre la possibilità di cambiare lo stato del’incident, di visualizzare tutti i suoi cambiamenti e di aprire le form MailForm e CambiamentoDettForm. CaombiamentoDettForm (fig. 2.9), è una vista di dettaglio del cambiamento selezionato in una DataGridView dalla OpenDeatailForm. MailForm (fig. 2.10), permette l’invio di mail “no reply” all’utente che ha generato l’incident. I dati relativi al destinatario vengono caricati in automatico al momento dell’apertura di MailForm. L’oggetto e il corpo della mail vengono suggeriti in base alla scelta del tipo di mail che si desidera inviare, la scelta viene fatta su una ListBox e comprende mail di comunicazione e di proposta di soluzione. L’invio di una mail comporta la modifica dello stato dell’incident in “Wait Customer” e il salvataggio della mail stessa in un nuovo cambiamento. Per l’invio della mail è stata utilizzata la classe SmtpClient e per l’upload dell’allagato la classe OpenFileDialog. Visualizzazione incident risolti Per la visualizzazione degli incident risolti sono state utilizzate tre form simili a quelle descritte al punto precedente: ClosedForm, è una finestra contenente una DataGridView con la lista degli incident risolti dell’operatore che sta utilizzando il sistema. ClosedDeatailForm, contiene le informazioni dettagliate di un incident risolto e la lista di tutti i sui cambiamenti. CambiamentoDettForm (fig. 2.9), visualizza tutte le informazioni relative ad un cambiamento selezionato nella ClosedDetailForm. Operazioni dell’amministratore Come detto nei precedenti paragrafi, l’operatore con privilegi di amministratore ha accesso ad un menu per le funzioni dedicate riguardanti la gestione dei prodotti e degli operatori; ha inoltre la possibilità di visualizzare i dati relativi a tutti gli incident trattati dal sistema. La GestioneMenuForm è una maschera che permette l’accesso a tre form di gestione: GestioneConsultantForm, GestioneIncidentForm e GestioneProductForm. La GestioneConsultantForm contiene una lista di tutti gli operatori. Selezionando un operatore è possibile aggiornarne i dati cliccando il pulsante “Modifica”, in questo modo viene aperta la ConsultantForm contenente tutte le informazioni di un operatore che potranno essere modificate. Dalla GestioneConsultantForm è possibile inserire un nuovo operatore cliccando il pulsante “Nuovo”, anche in questo caso viene aperta la ConsultantForm che verrà utilizzata come maschera per l’inserimento dei dati di un nuovo operatore. Il funzionamento e la realizzazione della coppia GestioneProductForm-ProductFrom è del tutto simile a quello della GestioneConsultantForm-ConsultantForm. I prodotti vengono visualizzati nella GestioneProductForm dalla quale è possibile modificarli o crearne di nuovi con la pressione dei bottoni “Modifica” e “Nuovo”. La GestioneIncidentForm contiene una lista di tutti gli incident che sono stati trattati dal sistema e dà la possibilità di vedere i dettagli dell’incident selezionato dalla DataGridView nella GestioneIncidentDetailForm. Le finestre GestioneIncidentForm e GestioneIncidentDetailForm hanno il compito di fornire una vista degli incident. Portale web Il portale web è l’interfaccia al sistema, utilizzata dall’utente per richiedere assistenza. Le pagine del sito sono state realizzate in ASP.NET e verranno descritte nei paragrafi successivi. Per lo sviluppo del prototipo è stata utilizzata una Master Page basta su di un web design template open source di nome Multiflex 3.7. Il sito è organizzato secondo la seguente mappa: Fig. 2.15: Mappa del sito dedicato alla richiesta di assistenza Autenticazione L’autenticazione degli utenti al sito web è di tipo Windows. L'autenticazione Windows considera l'identità dell'utente fornita da Microsoft Internet Information Services (IIS), in questo caso viene utilizzata esclusivamente l'autenticazione integrata di Windows (NTLM). Come accennato nel paragrafo 2.1.1, è necessario l’intervento dell’amministratore del server sul quale è presente il sito web; infatti è necessario l’inserimento dei dati degli utenti nell’IIS ed è necessario configurare il server Web in modo da consentire l’accesso al sito esclusivamente agli utenti inseriti nell’IIS. Per lo sviluppo e i test del prototipo di trouble ticket system è stato utilizzato l’Application Server di Windows Server 2003. Visualizzazione degli incident aperti La pagina Default è la prima pagina che l’utente vede dopo aver effettuato il login. La pagina contiene una GridView con la lista di tutti gli incident dell’utente ancora aperti e dà la possibilità di accedere alla pagina DettaglioIncident. Al caricamento della pagina Dafault vengono caricati i dati relativi all’utente dal server IIS con il seguente codice: Dim NomeLog As String Dim adPath As String =
LDAP://SERVER-TULKAS/DC=smallbusiness,DC=local
Dim sFilter As String = _ [String].Format(
(&(objectCategory=person)(sAMAccountName={0}))
, _ User.Identity.Name.Split(New Char() {
"
c})(1)) Using de As New DirectoryEntry(adPath) de.AuthenticationType = AuthenticationTypes.Secure Dim attribs As String() = New String() _ {
givenName
,
sn
,
mail
,
homephone
,
sAMAccountName
} Dim ds As New DirectorySearcher(de, sFilter, attribs) Using src As SearchResultCollection = ds.FindAll() Dim sr As SearchResult = Nothing If src.Count > 0 Then sr = src(0) End If Dim array(4) As String Dim i As Integer = 0 For Each key As String In attribs If sr.Properties.Contains(key) Then For Each o As Object In sr.Properties(key) array(i) = o i = i + 1 Next End If Next LabelFirstName.Text = (array(0)) LabelLastName.Text = (array(1)) LabelMail.Text = (array(2)) LabelPhone.Text = (array(3)) NomeLog = (array(4)) LabelNomeLog.Text = NomeLog End Using End Using La LabelNomeLog viene caricata con il NomeLog estratto dall’IIS e verrà utilizzata come parametro della SQLDataSource1: ,[object Object], Per raggiungere la pagina DettaglioIncident è necessario cliccare un valore della colonna incidentID in tabela (fig. 2.1), l’incidentID selezionato verrà passato come parametro per la pagina DettaglioIncident. Ecco il codice utilizzato per la GridView contente gli incident nella pagina Default: ,[object Object], La pagina DettaglioIncident contiene una tabella con tutte le informazioni relative all’incident e una tabella con la lista di tutti i suoi cambiamenti (fig. 2.2 in basso). Cliccando un CambiamentoID della tabella con la lista dei cambiamenti si arriva alla pagina DettaglioCambiamento passando come parametro il CambiamentoID selezionato. Visualizzazione degli incident risolti Dalla pagina Default si può accedere alla pagina ClosedIncident attraverso il LinkButton “Incident risolti” (fig. 2.1 in basso). La pagina ClosedIncident contiene una GridView identica a quella utilizzata per gli incident aperti nella pagina Default, salvo il fatto che contiene la lista degli incident risolti. Utilizzando un HyperLinkField è possibile accedere alla pagina DettaglioIncident e passare il parametro IncidentId selezionato nella GridView. Il funzionamento della pagina DettaglioIncident è lo stesso di quello definito nel paragrafo precedente. Inserimento nuova richiesta di assistenza Per l’operazione di inserimento di una nuova richiesta di assistenza viene utilizzata la pagina NuovoIncident, che contiene il form necessario alla raccolta dei dati relativi al problema (fig. 2.3). Per l’upload dell’eventuale allegato, è stata utilizzata la classe FileUpload. Al momento della conferma dell’operazione i dati inseriti nel form vengono salvati sul database e l’utente viene ridiretto alla pagina Default: Dim filePath As String = FileUpload1.PostedFile.FileName Dim filename As String = Path.GetFileName(filePath) Dim note As String Dim strConn As String =
Data Source=localhost;
& _
Initial Catalog=Prova;Integrated Security=True
Dim con As New SqlConnection(strConn) Dim NomeFile As String Dim bytes As Byte() If FileUpload1.FileName <>

Then Dim fs As Stream = FileUpload1.PostedFile.InputStream Dim br As New BinaryReader(fs) bytes = br.ReadBytes(fs.Length) End If If FileUpload1.FileName <>

Then note =
'
& Replace(TextBoxNote.Text,
'
,
''
) &
'
Else note =
NULL
End If If FileUpload1.FileName =

Then NomeFile =
NULL
Else NomeFile =
'
& FileUpload1.FileName &
'
End If Dim strQuery As String =
INSERT INTO [Incident] ([Data], [Stato],
& _
[Urgenza], [Note], [Allegato], [NomeAllegato],
& _
[UserID], [ProductID], [ConsultantID]) VALUES
& _
( SYSDATETIME(), 'Unassigned', NULL,
& _

& note &
, @Allegato,
& NomeFile &
,'
& _ Label1.Text &
', '
& _ DropDownListProdotto.SelectedItem.Value &
', NULL)
Dim cmd As New SqlCommand(strQuery) If FileUpload1.FileName <>

Then cmd.Parameters.Add(
@Allegato
, SqlDbType.Binary).Value = bytes Else cmd.Parameters.Add(
@Allegato
, SqlDbType.Binary).Value = _ SqlTypes.SqlBinary.Null End If cmd.CommandType = CommandType.Text cmd.Connection = con con.Open() cmd.ExecuteNonQuery() con.Close() con.Dispose() Response.Redirect(
Default.aspx
) Comunicazioni con l’operatore Come visto in precedenza, le comunicazioni all’utente vengono fatte attraverso mail “noreply”. Le eventuali risposte dell’utente all’operatore vengono effettuate attraverso le pagine NovoCambiamento e SoluzioneIncident, che potranno essere raggiunte soltanto attraverso un link diretto presente nel body della mail ricevuta dall’utente. La pagina NuovoCambiamento è utilizzata per consentire risposte all’operatore in merito ad una proposta di soluzione non soddisfacente o ad una richiesta di ulteriori informazioni riguardanti il problema. L’inserimento della risposta è affidato ad una form (fig. 2.4). La risposta dell’utente viene inserita nel database come cambiamento relativo all’incident oggetto della comunicazione. La pagina SoluzioneIncident viene visualizzata dall’utente solo in caso di soddisfazione per la proposta di soluzione, infatti è raggiungibile solo se l’utente clicca il link suggerito nella mail in caso di soluzione del problema. La pagina contiene un messaggio che conferma la chiusura dell’incident, il suo caricamento comporta il cambiamento dello stato dell’incident in “Closed” e l’inserimento di un nuovo cambiamento che registra la chiusura dell’incident. Per entrambe le pagine i parametri necessari alle loro operazioni sono inseriti nel link alle pagine. Conclusione L’obbiettivo principale del lavoro svolto era quello di progettare e sviluppare un sistema per la gestione di problemi relativi a componenti software e hardware per il centro servizi informatici dell’Ateneo. Alla conclusione del lavoro si è giunti ad un prototipo di trouble ticket system in grado di eseguire tutte le funzioni discusse in fase di analisi. Le funzionalità sono state testate in ambiente locale mediante l’utilizzo di un server virtuale. Per il prototipo sono state sviluppate: 16 form per il software dedicato agli operatori. 7 pagine aspx per il portale web dedicato agli utenti un database composto da 5 tabelle. Il passo successivo allo sviluppo del prototipo è l’implementazione del sistema in un ambiente reale; questo richiederà principalmente una modifica del sistema per quanto riguarda la configurazione di connessione al database e, secondariamente, alcune modifiche minori del sistema, in modo da adattarlo alle scelte dell’organizzazione nella quale verrà utilizzato. Bibliografia Gary S. Walker, (2001) IT problem management. Microsoft, MSDN Library. http://msdn.microsoft.com/it-it/library/default.aspx Microsoft, ASP.net. http://www.asp.net/ Microsoft, TechNet Library. http://technet.microsoft.com/it-it/library/default.aspx Open Source Web Design. http://www.oswd.org/

Tesi Giuseppe Chechile

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (16)

Similar to Tesi Giuseppe Chechile

Similar to Tesi Giuseppe Chechile (20)

Tesi Giuseppe Chechile