Embed Size (px)
Citation preview
1
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 CHECHILE Prof. Maurizio FERMEGLIA
ANNO ACCADEMICO 2008-2009
2
Indice
Introduzione ..................................................................................................................... 3
Capitolo 1: analisi e progettazione ................................................................................ 4
1.1 CRM ................................................................................................................ 5
1.2 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
3
2.2.3.5 Comunicazioni con l’operatore ........................................... 35
Conclusione ....................................................................................................................... 36
Bibliografia ........................................................................................................................ 37
4
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.
5
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.
1.1 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.
1.2 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.
6
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.
1.3 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.
1.4 Progettazione architetturale
Da un’analisi dei requisiti si ottengono le principali funzionalità del sistema da realizzare:
7
- 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.
8
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.
9
Diagramma del sistema per la gestione da parte dell’operatore:
Fig. 1.2: Diagramma del sistema per la gestione del ticket
1.5 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.
1.5.1 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:
1. CONSULTANT: (a) Inserimento dati Consultant. (b) Aggiornamento dati
Consultant.
2. USERS: (a) Inserimento dati User. (b) Aggiornamento dati User.
3. PRODUCT: (a) Inserimento dati nuovo Prodotto. (b) Aggiornamento dati
Prodotto.
10
4. INCIDENT: (a) Inserimento dati nuovo Incident.
5. CAMBIAMENTO: (a) Inserimento dati nuovo Cambiamento.
1.5.2 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.
1.5.3 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.
11
Fig. 1.3: Schema E-R
1.5.4 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.
Consultant
ConsultantID Codice che identifica univocamente Consultant
Nome Descrive il nome dell’operatore
Cognome Descrive il cognome dell’operatore
Mail Rappresenta l’indirizzo di posta elettronica dell’operatore
Amministratore Definisce se il Consultant ha privilegi di amministratore o meno
Users
UserID Codice che identifica univocamente Users
Nome Descrive il nome dell’utente
Cognome Descrive il cognome dell’utente
Telefono Rappresenta il recapito telefonico dell’utente
Mail Rappresenta l’indirizzo di posta elettronica dell’utente
Incident
IncidentID Codice che identifica univocamente Incident
Data Rappresenta la data in cui il problema è stato segnalato
Stato Definisce lo stato in cui si trova l’Incident nel momento presente
Urgenza Definisce l’importanza dell’Incident
Note Descrizione del problema
Allegato File che l’utente può inserire per descrivere il problema
NomeAllegato Descrive il nome dell’Allegato
12
Product
ProductID Codice che identifica univocamente Product
Nome Definisce il nome del prodotto oggetto di assistenza
Tipo Rappresenta la categoria del Product
Cambiamento
CambiamentoID Codice che identifica univocamente Cambiamento
Data Rappresenta la data in cui si verifica un aggiornamento dell’Incident
Oggetto Descrive l’oggetto che ha generato il Cambiamento
Descrizione Descrive in dettaglio il Cambiamento
Allegato File che può essere l’oggetto del Cambiamento stesso
NomeAllegato Descrive il nome dell’Allegato
Risolve
Collega 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.
Riguarda
Collega 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.
Genera
Collega 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.
Aggiorna
Collega 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.
13
Fig. 1.4: Schema E-R con attributi
1.6 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).
1.6.1 Casi d’uso
Di seguito vengono elencate le principali operazioni che verranno effettuate sul sistema,
indicando il soggetto che esegue tale operazione.
Operazione Soggetto
Inserimento nuovo Incident Utente
Assegnazione dell’Incident ad un Operatore Operatore
Inserimento nuovo Cambiamento Operatore/Sistema/Utente
Aggiornamento dello Stato dell’Incident Operatore/Sistema
Invio di una email di notifica all’Utente Operatore
Invio di una email con la proposta di soluzione all’Utente Operatore
Inserimento nuovo Utente Sistema
Inserimento nuovo Operatore Amministratore
Aggiornamento dati Operatore Amministratore
Inserimento nuovo Prodotto Amministratore
14
Aggiornamento dati Prodotto Amministratore
Chiusura di un Incident Operatore
Visualizzazione dettagli Incident e relativi Cambiamenti Operatore/Utente/Amm.
Risposta da parte di un Utente all’Operatore Utente
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.
1.6.2 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.
15
1.6.3 Diagramma UML dei casi d’uso
Di seguito sono rappresentati i principali casi d’uso utilizzando un diagramma UML.
Fig. 1.5: Diagramma UML
16
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.
2.1.1 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.
2.1.2 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.
17
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).
18
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).
19
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.
20
2.1.3 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).
21
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).
22
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
23
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
2.1.4 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).
24
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
25
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.
2.2 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.
2.2.1 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.
26
Fig. 2.13: Modello logico del database
2.2.2 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.
27
Fig. 2.14: Schema delle form della consultant application
2.2.2.1 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.
28
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()
2.2.2.2 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=" & LoginForm.UsernameTextBox.Text & ";" & _
"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', " & _
29
"[Urgenza]='" & ComboBoxUrgenza.SelectedItem.ToString & "', " & _
"[ConsultantID]='" & LoginForm.UsernameTextBox.Text & "' " & _
"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()
2.2.2.3 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.
2.2.2.4 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.
30
- 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.
2.2.2.5 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.
2.2.3 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:
31
Fig. 2.15: Mappa del sito dedicato alla richiesta di assistenza
2.2.3.1 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.
2.2.3.2 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))
32
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:
<asp:SqlDataSource
ID="SQLDataSource1"
runat ="server"
DataSourceMode = "DataReader"
ConnectionString = "Data Source=localhost;Initial
Catalog=Prova;Integrated Security=True"
ProviderName="System.Data.SqlClient"
SelectCommand = "SELECT
Incident.[IncidentID],Incident.[Data],
Incident.[Stato], Product.[Nome] As [Prodotto],
Product.[Tipo], Users.[Nome], Users.[Cognome]
FROM [Incident]
INNER JOIN [Users] ON Users.[UserID]=Incident.[UserID]
INNER JOIN [Product] ON Product.[ProductID]=
Incident.[ProductID]
WHERE Users.[UserID] = @NomeLog
AND Incident.[Stato] <> 'Closed' ;" >
<SelectParameters>
<asp:ControlParameter ControlID = "LabelNomeLog" Name = "NomeLog"
PropertyName = "Text"/>
</SelectParameters>
</asp:SqlDataSource>
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
33
pagina DettaglioIncident. Ecco il codice utilizzato per la GridView contente gli incident nella
pagina Default:
<asp:GridView
ID="GridView1"
runat="server"
DataSourceID="SQLDataSource1"
AutoGenerateColumns="False"
DataKeyNames="IncidentID">
<Columns>
<asp:HyperLinkField DataNavigateUrlFields="IncidentID"
DataNavigateUrlFormatString=
"DettaglioIncident.aspx?IncidentID={0}"
NavigateUrl="DettaglioIncident.aspx"
DataTextField="IncidentID"
HeaderText="IncidentID"
SortExpression="IncidentID" />
<asp:BoundField DataField="Data"
HeaderText="Data"
SortExpression="Data" />
<asp:BoundField DataField="Stato"
HeaderText="Stato"
SortExpression="Stato" />
<asp:BoundField DataField="Tipo"
HeaderText="Tipo"
SortExpression="Tipo" />
<asp:BoundField DataField="Prodotto"
HeaderText="Prodotto"
SortExpression="Prodotto" />
<asp:BoundField DataField="Nome"
HeaderText="Nome"
SortExpression="Nome" />
<asp:BoundField DataField="Cognome"
HeaderText="Cognome"
SortExpression="Cognome" />
</Columns> </asp:GridView>
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.
2.2.3.3 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.
34
2.2.3.4 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")
35
2.2.3.5 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.
36
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.
37
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/
