Porting evolutivo di un’applicazione per la gestione di note spese in ambiente share point 2010
105
UNIVERSITÀ DEGLI STUDI DI TRIESTE FACOLTÀ DI INGEGNERIA Corso di laurea specialistica in Ingegneria Informatica Tesi di laurea in Complementi di Basi di Dati PORTING EVOLUTIVO DI UN’APPLICAZIONE PER LA GESTIONE DI NOTE SPESE IN AMBIENTE SHAREPOINT 2010 LAUREANDO Enrico Natella RELATORE Chiar.mo Prof. Maurizio Fermeglia Anno Accademico 2009/2010
-
Upload
enriconatella -
Category
Documents
-
view
1.775 -
download
0
description
Transcript of Porting evolutivo di un’applicazione per la gestione di note spese in ambiente share point 2010
UNIVERSITÀ DEGLI STUDI DI TRIESTE
FACOLTÀ DI INGEGNERIA
Corso di laurea specialistica in Ingegneria Informatica
Tesi di laurea in
Complementi di Basi di Dati
PORTING EVOLUTIVO DI UN’APPLICAZIONE
PER LA GESTIONE DI NOTE SPESE
IN AMBIENTE SHAREPOINT 2010
LAUREANDO
Enrico Natella
RELATORE
Chiar.mo Prof. Maurizio Fermeglia
Anno Accademico 2009/2010
Ai miei genitori
i
Indice
1 Introduzione .............................................................................................................................................. 1
2 Analisi ........................................................................................................................................................ 3
2.1 Introduzione ...................................................................................................................................... 3
2.2 I requisiti ............................................................................................................................................ 4
2.2.1 Analisi dei requisiti .................................................................................................................... 4
2.2.2 Documento dei requisiti .......................................................................................................... 10
2.2.3 Glossario dei termini................................................................................................................ 15
3 Disegno della Base di Dati ....................................................................................................................... 17
3.1 Introduzione .................................................................................................................................... 17
3.2 Entità................................................................................................................................................ 17
3.3 Tabelle ............................................................................................................................................. 18
3.4 Osservazioni ..................................................................................................................................... 22
3.5 Schema fisico ................................................................................................................................... 22
3.6 Trigger .............................................................................................................................................. 24
3.7 Stored Procedures ........................................................................................................................... 24
4 Migrazione da SharePoint 2007 a SharePoint 2010 ................................................................................ 26
4.1 Requisiti per l'aggiornamento ......................................................................................................... 26
4.1.1 Requisito hardware: 64 bit ...................................................................................................... 26
4.1.2 Requisito di sistema operativo ................................................................................................ 27
4.1.3 Requisito del database management system .......................................................................... 27
4.1.4 Strumento di verifica pre-aggiornamento ............................................................................... 27
4.1.5 Comando di Windows PowerShell per la verifica dei database .............................................. 28
4.1.6 Console di aggiornamento ....................................................................................................... 28
4.2 Panoramica del processo di aggiornamento ................................................................................... 29
4.2.1 Aggiornamento basato sul collegamento di database ............................................................ 29
4.2.2 Procedure consigliate per testare l'aggiornamento ................................................................ 29
4.3 Allegare database ed eseguire l'aggiornamento ............................................................................. 31
4.3.1 Panoramica del processo ......................................................................................................... 31
4.3.2 Prima di iniziare ....................................................................................................................... 32
4.3.3 Impostare per la sola lettura i database della versione precedente ....................................... 32
4.3.4 Per eseguire il backup di un database in SQL Server 2008 ...................................................... 32
ii
4.3.5 Scollegare i database della versione precedente .................................................................... 33
4.3.6 Ripristinare una copia di backup del database ........................................................................ 34
4.3.7 Verifica dell'aggiornamento per il database ............................................................................ 34
4.4 Conversione di Web User Control in Visual Web Part..................................................................... 35
4.4.1 Smart Part ................................................................................................................................ 35
4.4.2 Visual Web Part ....................................................................................................................... 35
4.4.3 Conversione ............................................................................................................................. 36
4.5 Osservazioni ..................................................................................................................................... 36
4.5.1 Autenticare gli utenti ............................................................................................................... 37
4.5.2 Ospitare l’applicativo ............................................................................................................... 37
5 Confronto fra il documento dei requisiti e il progetto esistente ............................................................ 38
5.1 Confronto con l’applicativo esistente .............................................................................................. 38
5.1.1 Compilazione della nota spese ................................................................................................ 38
5.1.2 Approvazione della nota spese ................................................................................................ 39
6 L’applicativo ............................................................................................................................................. 40
6.1 Introduzione .................................................................................................................................... 40
6.2 Obiettivi dell’applicativo .................................................................................................................. 40
6.3 Progettazione .................................................................................................................................. 40
6.3.1 Qualità del software ................................................................................................................ 40
6.3.2 Strategie di sviluppo ................................................................................................................ 41
6.3.3 Strategie di progetto................................................................................................................ 41
6.3.4 I moduli .................................................................................................................................... 42
6.3.5 Strumenti utilizzati per lo sviluppo dell’applicativo ................................................................ 42
6.3.6 Processo Unificato di sviluppo del software ........................................................................... 44
6.3.7 I diagrammi di attività.............................................................................................................. 45
6.4 I ruoli ................................................................................................................................................ 46
6.5 La codifica ........................................................................................................................................ 47
6.5.1 Descrizione della solution ........................................................................................................ 47
6.5.2 Accesso ai dati ......................................................................................................................... 48
6.5.3 Visual Web Part ....................................................................................................................... 48
6.5.4 Mail .......................................................................................................................................... 57
6.5.5 Validazione dei dati ................................................................................................................. 58
6.6 Testing ............................................................................................................................................. 59
6.6.1 Unit Testing .............................................................................................................................. 59
iii
6.6.2 Test Funzionali ......................................................................................................................... 61
6.7 Installazione dell’applicativo ........................................................................................................... 66
6.7.1 Web.config ............................................................................................................................... 67
6.7.2 Active Directory ....................................................................................................................... 71
6.7.3 Database .................................................................................................................................. 71
6.7.4 Tabella di Configurazione ........................................................................................................ 71
7 I modi d’uso ............................................................................................................................................. 73
7.1 Introduzione .................................................................................................................................... 73
7.2 Le funzionalità generali ................................................................................................................... 73
7.2.1 CostsheetCompilation ............................................................................................................. 74
7.2.2 CostsheetApprovement ........................................................................................................... 80
7.2.3 BillingOperations ..................................................................................................................... 84
7.2.4 Report ...................................................................................................................................... 88
7.2.5 Booking .................................................................................................................................... 90
7.2.6 Configuration ........................................................................................................................... 95
8 Conclusioni .............................................................................................................................................. 96
Bibliografia ....................................................................................................................................................... 97
Ringraziamenti ................................................................................................................................................. 98
1
1 Introduzione
L’idea di sviluppare un applicativo per la gestione delle note spese e prenotazioni è nata dall’esigenza di
migliorare e innovare il sistema che attualmente il gruppo Teorema utilizza all’interno delle sue aziende.
Fino alla realizzazione di questo programma, infatti, la compilazione delle note spese avveniva tramite
foglio Excel. Si è deciso quindi di progettare un applicativo che andasse incontro alle esigenze dei
dipendenti e, allo stesso tempo, permettesse agli amministratori di tenere traccia di tutte le spese
sostenute tramite l’introduzione di una base di dati che fosse condivisa da tutto il gruppo. Bisogna
specificare che in passato si era già iniziato a sviluppare tale applicativo all’interno di SharePoint 2007,
senza mai però giungere a un prodotto finito. Per cui per il suo sviluppo si partirà dal software esistente,
eseguendo un porting evolutivo verso SharePoint 2010.
Il prodotto software, descritto nel seguito, è frutto di una successione di fasi di sviluppo quali la
raccolta dei requisiti, la loro successiva analisi, la progettazione dei dati da un lato e delle applicazioni
dall’altro, e infine da una fase di test, installazione e collaudo. Si è ritenuto opportuno seguire il modello
di sviluppo a cascata. I vincoli di progetto, propedeutici all’intero sviluppo, si possono elencare nel modo
seguente.
I vincoli concernenti il sistema operativo hanno richiesto che sulla macchina fosse installato
Microsoft Windows Server 2008 con all’interno SharePoint 2010. Quelli riguardanti il Data Base
Management System hanno stabilito l’utilizzo di Microsoft SQL Server nella versione 2008. L’ambiente di
sviluppo presupposto è stato SharePoint 2010, affiancato con Visual Studio 2010 e SharePoint Designer.
I vincoli attinenti le risorse hardware sono legati alle caratteristiche minime richieste da SharePoint.
L’elaborato compie un excursus che descrive tutti gli stadi del progetto. Nel primo capitolo viene
descritta l’attività di analisi svolta, lo studio dei requisiti teso alla definizione di un sistema che
rispettasse appieno gli obiettivi preposti. Proseguendo verso il capitolo successivo, viene presentato il
disegno della base di dati, pilastro del sistema. A tale fine, sono presi in esame tutti i passi che hanno
portato alla realizzazione del suo schema fisico. A questo, segue il capitolo relativo alla fase di
migrazione, in cui si analizza la fase del porting dell’applicativo da SharePoint 2007 a SharePoint 2010.
Nel capitolo successivo viene svolta un’analisi per confrontare il documento dei requisiti prodotto nella
prima fase con l’applicativo esistente. Attorno a metà della trattazione si colloca il capitolo che entra nel
vivo dello sviluppo dell’applicativo. Vengono esposte tutte le fasi volte a raggiungere tale meta: dallo
studio degli obiettivi a quello delle specifiche, dalla progettazione alla realizzazione, giungendo infine
alla verifica complessiva. Il capitolo che segue ha lo scopo di essere d’ausilio all’utilizzatore che si
2
avvicina per la prima volta al sistema. Vengono definite le funzionalità implementate, facendo largo uso
di immagini esplicative. Il capitolo successivo è stato scritto invece per descrivere le procedure al fine di
una corretta installazione dell’applicativo. Il nono capitolo si pone a chiusura della dissertazione e ha
uno scopo riepilogativo; infatti, in questa sezione trovano posto le conclusioni tratte a progetto
ultimato.
3
2 Analisi
2.1 Introduzione In questo primo capitolo viene descritta la fase iniziale del ciclo di vita del software realizzato. L’attività
di analisi rappresenta l’inizio dell’intero processo di sviluppo, nonché il momento più critico: un errore in
questa fase si ripercuoterebbe sull’intero progetto. Per questo è stato introdotto un modello, il quale
può essere concepito come uno schema a blocchi caratterizzato da particolari input e output (Fig. 2-1).
Figura 2-1: Modello per lo sviluppo del software
Per questo progetto, si è scelto il modello di sviluppo a cascata, secondo cui la realizzazione di
un prodotto software consta di una sequenza di fasi strutturata in analisi dei requisiti, progetto,
sviluppo, collaudo, integrazione e manutenzione. Ciascuna di queste fasi produce un ben preciso output
che viene utilizzato come input per la fase successiva (da cui la metafora della cascata). (Fig. 2-2).
Lungo il capitolo verrà delineato il procedimento che, dall’acquisizione dei requisiti e da una loro
successiva elaborazione, ha portato alla definizione di uno schema concettuale del progetto, di enorme
importanza per lo sviluppo complessivo.
4
Figura 2-2: Il modello di sviluppo a cascata
2.2 I requisiti Scopo generale dell’analisi è stabilire che cosa il sistema in questione deve fare (mentre le decisioni sul
come sono rimandate alla successiva fase di progettazione). I requisiti sono le caratteristiche che utente
e committente desiderano che siano presenti in un prodotto software da realizzare. L’obiettivo di un
progetto di sviluppo software, quando si realizza un nuovo sistema o si apportano modifiche a un
sistema già esistente, è sempre realizzare un prodotto che soddisfi i requisiti.
Il caso in questione è particolare, in quanto si parte da un progetto preesistente che deve essere
migrato verso una nuova piattaforma ed integrato con alcune nuove funzionalità. Visto che la
precedente fase di analisi era stata svolta più di un anno prima, si è pensato fosse necessario procedere
ad una nuova analisi, per verificare che i precedenti requisiti fossero ancora validi e soprattutto per
determinare le caratteristiche per le nuove componenti.
2.2.1 Analisi dei requisiti
Il fine ultimo di questo progetto è la realizzazione di un applicativo per la gestione e centralizzazione
delle prenotazioni e delle note spese dei dipendenti. A tale scopo è necessario raccogliere i dati
necessari all’interno di un database che soddisfi taluni requisiti. La precisione adoperata durante la fase
di acquisizione dei requisiti è fondamentale. Infatti, le specifiche ottenute come risultato, permettono di
5
determinare la tecnologia e l’architettura del sistema, stimando tempi e costi della realizzazione
complessiva. Questa attività si esplica, in primo luogo, nella stretta collaborazione fra l’analista ed
alcune figure aziendali e, in secondo luogo, nell’analisi di documentazione esistente.
Il reperimento dei requisiti è un’attività difficile e non standardizzabile. Utenti diversi possono
fornire informazioni diverse: utenti a livello più alto hanno spesso una visione più ampia ma meno
dettagliata. Per questi motivi la prima intervista è avvenuta con il project manager dell’azienda, che ha
disegnato un quadro generale della realtà, descrivendo a linee generali gli obiettivi del progetto. Le
interviste successive sono avvenute invece con le impiegate del settore amministrativo dell’azienda, che
hanno illustrato tutte le funzionalità che il prodotto finale dovrebbe avere, essenzialmente basandosi sul
metodo di lavoro che attualmente utilizzano. Queste interviste si sono svolte in più fasi, delineando di
volta in volta il progetto sempre con migliore accuratezza. L’attività di analisi ha quindi avuto inizio da
uno studio attento delle parole delle impiegate. Si riporta di seguito uno stralcio dell’intervista relativa
alla parte sulle prenotazioni.
Intervista alle impiegate dell’amministrazione
Ci sono cinque categorie di prodotti per le quali una risorsa può richiedere una prenotazione:
Albergo
Aereo
Navetta
Treno
Automobile
Albergo
Prenotazione
La risorsa che ha bisogno di pernottare in un albergo deve specificare in una mail i seguenti campi:
Cliente
Commessa
Città
Periodo di pernottamento
Una volta che il dipendente del settore amministrativo riceve la mail, per prima cosa verifica se nella
città l’azienda ha già delle foresterie a cui appoggiarsi. Se non è così, controlla se nella città di
destinazione qualcuno in precedenza aveva già pernottato per cercare di prenotare nello stesso albergo.
Se è una città “nuova”, l’operatore amministrativo effettuerà una ricerca di un albergo che risponda ai
6
requisiti aziendali. Una volta trovato prenderà contatto con l’albergo per verificare la disponibilità di
posti liberi. Se c’è la disponibilità verrà inviato un fax di conferma all’albergo con l’autorizzazione al
pagamento (Se l’albergo è già stato utilizzato in precedenza, avranno già il numero della carta di
credito). Quando l’albergo avrà accettato la prenotazione, inviando il documento di accettazione, si
provvederà a comunicare alla risorsa in questione l’avvenuta prenotazione tramite mail, inserendovi
all’interno il link al sito dell’albergo e le date di check in e check out. L’operatore a questo punto
provvederà a registrare la prenotazione. Una volta completato il pernottamento, se non sarà stato
l’albergo stesso ad inviare la fattura all’azienda, sarà la risorsa che dovrà provvedere a portare in
azienda la fattura emessa dall’albergo.
Cancellazione
La risorsa comunica via mail o telefonicamente che è necessario annullare la prenotazione per l’albergo.
L’operatore amministrativo contatterà l’albergo e annullerà la prenotazione. Nel 90% dei casi non è
necessario pagare nessuna penale. Al completamento della cancellazione della prenotazione sarà
necessario inviare una mail alla risorsa interessata e in copia anche all’ufficio personale.
Spostamento
La risorsa comunica via mail o telefonicamente che è necessario modificare la prenotazione per
l’albergo. L’operatore amministrativo contatterà l’albergo per verificarne la disponibilità e in caso
positivo modificherà la prenotazione. Solitamente per questi spostamenti non è prevista alcun tipo di
penale. Nel caso in cui non ci sia la disponibilità, bisognerà procedere alla cancellazione della
prenotazione e alla ricerca di un albergo alternativo. Al termine delle operazioni verrà inviata una mail
alla risorsa interessata dell’avvenuto spostamento della prenotazione.
Aereo
Prenotazione
La risorsa che ha bisogno di prenotare un volo aereo deve specificare in una mail i seguenti campi:
Cliente
Commessa
Città di partenza
Città di destinazione
Data di andata e/o ritorno
Ora desiderata di Partenza/Arrivo
7
Una volta che il dipendente del settore amministrativo riceve la mail, controlla sui siti delle compagnie
aeree o tramite agenzia i possibili voli. Una volta trovati dei voli che rispettano i requisiti, vengono
comunicati alla risorsa interessata i possibili orari. Quando la risorsa sceglie i voli di suo interesse, li
comunica in amministrazione che provvederà alla prenotazione. I biglietti dei voli arriveranno via mail
direttamente alla risorsa e in copia anche all’ufficio personale. In questo modo non sarà necessario che
la risorsa, di ritorno dal suo viaggio, porti i biglietti stampati come ricevuta.
Cancellazione
La risorsa comunica via mail o telefonicamente che è necessario annullare la prenotazione del volo.
L’operatore amministrativo contatterà il sito della compagnia o l’agenzia viaggi e annullerà la
prenotazione. In questo caso ci sarà sicuramente da pagare una penale. Al completamento della
cancellazione della prenotazione sarà necessario inviare una mail alla risorsa interessata e in copia
anche all’ufficio personale.
Spostamento
La risorsa comunica via mail o telefonicamente che è necessario modificare la prenotazione del volo.
L’operatore amministrativo contatterà il sito della compagnia o l’agenzia viaggi per verificarne la
disponibilità e in caso positivo modificherà la prenotazione, dovendo quasi sicuramente pagare una
penale. Nel caso in cui non ci sia la disponibilità, bisognerà procedere alla cancellazione della
prenotazione (con penale) e alla ricerca di un volo alternativo. Al termine delle operazioni verrà inviata
una mail alla risorsa interessata dell’avvenuto spostamento della prenotazione.
Navetta
Prenotazione
Alla prenotazione di un volo aereo può essere associata anche la prenotazione della navetta per gli
spostamenti da e per l’aeroporto. Sarà la stessa risorsa che avrà la possibilità di chiedere questo servizio.
Nel caso in cui se lo dimenticasse l’operatore amministrativo proporrà comunque l’acquisto. Il servizio di
navetta viene proposto per gli aeroporti di Ronchi dei Legionari, di Lubiana, di Venezia e di Treviso.
All’avvenuta richiesta, l’operatore contatterà il fornitore del servizio e tramite il sito potrà inserire
automaticamente le informazioni necessarie tramite il voucher della prenotazione del volo. Il fornitore
del servizio invierà una mail per la presa in carico. Due giorni prima della partenza, invece, il fornitore
invierà una mail direttamente alla risorsa che necessita del trasporto con all’interno specificato l’orario
di pick up. Il pagamento viene effettuato a fine mese tramite fattura.
Cancellazione
La risorsa comunica via mail o telefonicamente che è necessario annullare la prenotazione della navetta.
L’operatore amministrativo contatterà il fornitore del servizio e annullerà la prenotazione. In questo
8
caso ci sarà sicuramente da pagare una penale. Al completamento della cancellazione della
prenotazione sarà necessario inviare una mail alla risorsa interessata e in copia anche all’ufficio
personale.
Spostamento
La risorsa comunica via mail o telefonicamente che è necessario modificare la prenotazione della
navetta. L’operatore amministrativo contatterà il fornitore del servizio per verificarne la disponibilità e
in caso positivo modificherà la prenotazione, dovendo quasi sicuramente pagare una penale. Nel caso in
cui non ci sia la disponibilità, bisognerà procedere alla cancellazione della prenotazione (con penale) e
alla ricerca di una navetta alternativa. Al termine delle operazioni verrà inviata una mail alla risorsa
interessata dell’avvenuto spostamento della prenotazione.
Treno
Prenotazione
La risorsa che ha bisogno di prenotare un treno deve specificare in una mail i seguenti campi:
Cliente
Commessa
Città di destinazione
Data di andata e/o ritorno
Ora desiderata di partenza/arrivo
Una volta che il dipendente del settore amministrativo riceve la mail, contatta il sito di Trenitalia o il call
center per ricercare i treni possibili. Una volta trovati dei treni che rispettano i requisiti, vengono
comunicati alla risorsa interessata i possibili orari. Quando la risorsa sceglie i treni di suo interesse, li
comunica in amministrazione che provvederà alla prenotazione del posto. L’operatore amministrativo
manderà quindi una mail alla risorsa con all’interno il codice della prenotazione (ticketless). Di ritorno
dal suo viaggio, la risorsa dovrà portare i biglietti stampati come ricevuta.
Cancellazione
La risorsa comunica via mail o telefonicamente che è necessario annullare la prenotazione del treno.
L’operatore amministrativo contatterà Trenitalia e annullerà la prenotazione. In questo caso ci sarà
sicuramente da pagare una penale. Al completamento della cancellazione della prenotazione sarà
necessario inviare una mail alla risorsa interessata e in copia anche all’ufficio personale.
9
Spostamento
La risorsa comunica via mail o telefonicamente che è necessario modificare la prenotazione del treno.
L’operatore amministrativo contatterà Trenitalia per verificarne la disponibilità e in caso positivo
modificherà la prenotazione, dovendo quasi sicuramente pagare una penale. Al termine delle operazioni
verrà inviata una mail alla risorsa interessata dell’avvenuto spostamento della prenotazione.
Automobile
Prenotazione
La risorsa che ha bisogno di prenotare un’automobile deve specificare in una mail i seguenti campi:
Cliente
Commessa
Città di destinazione
Data di andata e/o ritorno
Una volta che il dipendente del settore amministrativo riceve la mail, per prima cosa verifica la
disponibilità dell’auto aziendale. Se questa è disponibile, viene prenotata e viene inviata una mail di
conferma alla risorsa che l’ha richiesta. Se invece l’auto aziendale non è disponibile, è necessario
contattare AVIS, che è il fornitore d’auto convenzionato con l’azienda. Una volta prenotata l’automobile,
l’operatore amministrativo compilerà il voucher necessario e ne darà una copia alla risorsa a cui serve
l’auto. Ovviamente verrà inviata anche una mail di conferma con i dati della prenotazione.
Cancellazione
La risorsa comunica via mail o telefonicamente che è necessario annullare la prenotazione
dell’automobile. L’operatore amministrativo contatterà AVIS e annullerà la prenotazione. In questo caso
non ci sarà da pagare alcuna penale. Al completamento della cancellazione della prenotazione sarà
necessario inviare una mail alla risorsa interessata e in copia anche all’ufficio personale.
Spostamento
La risorsa comunica via mail o telefonicamente che è necessario modificare la prenotazione
dell’automobile. L’operatore amministrativo contatterà AVIS per verificarne la disponibilità e in caso
positivo modificherà la prenotazione. In questo caso è necessario modificare il voucher, pur
mantenendo sempre lo stesso. Al termine delle operazioni verrà inviata una mail alla risorsa interessata
dell’avvenuto spostamento della prenotazione.
Riorganizzando le frasi per concetti simili, integrandole con la documentazione esistente, è stato
ottenuto il documento dei requisiti.
10
2.2.2 Documento dei requisiti
Gestione Nota Spese
La gestione delle note spese si articola in tre fasi principali:
Compilazione della nota spese
Approvazione della nota spese
Selezione delle spese per la fatturazione
Reportistica
Compilazione della nota spese
La gestione delle note spese dovrà consentire l’inserimento delle informazioni da parte di tutti i
dipendenti/collaboratori, attraverso un’apposita sezione all’interno della intranet aziendale. L’utente
avrà diritti di “contribute” per consentire l’inserimento, la modifica e l’eventuale cancellazione delle
informazioni. Al termine della compilazione l’utente dovrà chiudere la nota spese e richiederne
l’approvazione. Nel caso in cui la nota spese non contenga nessuna spesa, l’utente dovrà comunque
chiuderla per non bloccare il flusso che coinvolge l’amministrazione. Sarà possibile compilare note spese
per mesi successivi a quello corrente, senza però poterne chiedere l’approvazione. Esisterà un utente
“Super User” che potrà inserire note spese per i consulenti esterni o in caso di necessità anche per un
qualsiasi dipendente.
Le informazioni da gestire saranno le seguenti:
Mese / Anno: indicano rispettivamente il mese e l’anno a cui la nota spese fa riferimento,
fondamentale per la fatturazione.
Risorsa: indica il dipendente che ha compilato la nota spese. Generalmente sarà lo stesso
che si è loggato nel sistema. Caso particolare per il Super User che avrà la possibilità di
selezionare l’utente per il quale sta inserendo la nota spese.
Cliente: indica il cliente per il quale si è sostenuta la spesa.
Commessa: indica la particolare commessa collegata al cliente per il quale si è sostenuta la
spesa.
Data: rappresenta la data in cui si è sostenuta la spesa
Descrizione: piccola relazione esplicativa della spesa.
Tipo di costo:
o Vitto: spesa relativa a pasti.
o Alloggio: spesa relativa a un pernottamento.
o Trasporti: spesa riguardante il trasferimento.
11
o Km: spesa sostenuta muovendosi con l’auto di proprietà.
o Altro: tutto quello che non rientra nelle categorie precedenti.
Km: rappresenta il numero di Km sostenuti dalla risorsa. Da compilare solo in caso di tipo
spesa chilometrico.
Città di destinazione: rappresenta il luogo di destinazione di una trasferta. Da compilare solo
in caso di tipo spesa chilometrico.
Fattura: indica se per la spesa sostenuta la risorsa è in possesso di una fattura.
Rappresentanza: indica se la spesa sostenuta è avvenuta per rappresentanza.
Totale spese documentate: somma di tutte le spese sostenute ad eccezione delle spese di
tipo chilometrico.
Totale spese chilometriche: somma di tutte le spese di tipo chilometrico.
Totale anticipato: somma che è stata anticipata al dipendente prima della trasferta. Questo
valore sarà inserito in un secondo momento dall’amministrazione.
Totale a pagare: somma del totale spese documentate e del totale spese chilometriche, al
quale va sottratto l’eventuale totale anticipato.
Allegati: informazione indicante il numero progressivo dello scontrino associato alla spesa.
Tale numero viene indicato a mano sul retro dello scontrino direttamente dal dipendente e
poi riportato a livello di spesa al fine di relazionare il cartaceo con l’informazione
digitalizzata.
Per ogni cliente esisterà una “commessa generica” che darà modo di inserire spese relative ad attività
extra (es. presale, ecc.). Durante l’inserimento della nota spese l’utente dovrà avere la possibilità di
visualizzare il coefficiente di rimborso chilometrico applicato per il calcolo. Se il tipo spesa sarà
chilometrico, la risorsa dovrà valorizzare due campi aggiuntivi rispetto agli altri casi e cioè il numero di
Km effettuati e la città in cui ci si è recati. Al fine di una corretta visualizzazione delle spese è necessario
tenere sempre separate le spese di tipo chilometrico dalle altre tipologie di spesa, perché soggette a un
diverso trattamento fiscale. Il rimborso chilometrico non è soggetto a tassazione in capo al dipendente,
in quanto non è classificabile come remunerazione, ma come indennizzo per costi sostenuti dal
dipendente per conto dell’impresa. Premettendo che per trasferta si intende lo spostamento del
dipendente dalla propria abituale sede di lavoro, verso un altro luogo, al fine di svolgere l’attività
lavorativa, è necessario separare l’ipotesi in cui il dipendenti effettui la trasferta di lavoro al di fuori del
Comune ove è ubicata la sede di lavoro, da quella svolta all’interno dello stesso Comune:
Nel primo caso è previsto il regime di non imponibilità;
Nel secondo caso invece l’indennità percepita dal dipendente è soggetta a tassazione.
12
Le spese documentate invece sono sempre esenti dalla tassazione. Una cosa molto importante è dare la
possibilità all’utente di stampare su carta la nota spese, per poi firmarla: questo è fondamentale al fine
del rispetto delle normative vigenti, per associare gli scontrini e le fatture al dipendente che ha
sostenuto quelle spese.
Approvazione della nota spese
Le informazioni inserite dai dipendenti saranno sottoposte a flusso di approvazione da parte di una
sezione del reparto di amministrazione, che sarà indicata come Approvatori (VAPP). In caso di assenza
dell’utente che approva, ci sarà la possibilità di definire un utente di “backup” in grado di svolgere gli
stessi compiti. Gli approvatori potranno filtrare per: mese/anno e risorsa. In questo modo
visualizzeranno un elenco di note spese delle quali potranno vedere i dettagli e procedere con
l’eventuale approvazione o rifiuto (inserendo eventualmente un commento). In caso di rifiuto sarà
inviata in automatico una mail all’utente che ha compilato la nota spese. Quando questa invece verrà
sottoposta nuovamente ad approvazione, ne verrà inviata una all’amministrazione. In ogni nota spese
l’approvatore, prima di approvare, potrà inserire un importo detto “Totale Anticipato” che andrà a
sottrarsi al Totale A Pagare. In generale ci sarà la possibilità di stampare su carta.
Selezione delle spese per la fatturazione
A questa sezione può accedere solo una parte dell’amministrazione che verrà definita Visualizzatori
(VAPP). I visualizzatori delle note spese approvate potranno selezionare le spese ammissibili dal cliente
(quelle concordate sull’offerta del progetto) e salvare tale selezione; l’operazione produrrà quindi il
calcolo del totale ammissibile verso il cliente. Sarà possibile scegliere in fase di ricerca se visualizzare
solo le spese approvate oppure aggiungere anche quelle in attesa di approvazione (ad esempio mostrate
in grigio), senza però poterle selezionare. Le note spese compilate da una particolare categoria di utente
(es. i Commerciali) saranno sottoposte ad approvazione, ma non saranno poi visibili ai visualizzatori. Gli
importi delle spese relative a viaggi in auto non saranno riportati; per ognuna di esse sarà invece data la
possibilità di inserire un numero di Km ed un coefficiente di rimborso chilometrico, il cui prodotto darà
l’importo fatturabile al cliente. I visualizzatori delle approvazioni potranno filtrare per: mese/anno (o
definire un intervallo di tempo), cliente e commessa. Verranno visualizzate le commesse di tutte le
risorse. La visualizzazione di tali informazioni avverrà solo se le stesse risulteranno approvate. Per le
note spese in attesa di valutazione o di cui non è stata ancora richiesta l’approvazione, sarà generato un
avviso contenente l’elenco delle risorse coinvolte. In generale ci sarà la possibilità di stampare su carta.
13
Reportistica
Questa sezione è stata richiesta sia dal reparto dell’amministrazione, sia dal livello dirigenziale
dell’azienda. In pratica si richiede una schermata in cui sia possibile visualizzare dei report riassuntivi con
all’interno l’ammontare di tutte le note spese rimborsate ai dipendenti. Questi report dovranno essere
filtrati in base a dei parametri che potranno essere specificati dagli utenti stessi. Questi parametri sono:
Data inizio: specifica l’inizio dell’arco temporale di cui si vogliono analizzare le spese sostenute
dai dipendenti;
Data fine: specifica la fine dell’arco temporale di cui si vogliono analizzare le spese sostenute dai
dipendenti;
Risorsa: può essere specificata per visualizzare tutte le spese rimborsate ad un singolo
dipendente
Centro di costo: le spese possono essere filtrate in base al centro di costo, cioè in base alle
quattro categorie di dipendenti che sono presenti all’interno dell’azienda e cioè Produzione,
Commerciale, Direttivo e Struttura;
Sede: le spese possono essere filtrate in base alla sede di riferimento del dipendente che le ha
sostenute, in questo caso quindi o Milano o Trieste;
Cliente: specifica la visualizzazione di tutte le spese sostenute dai dipendenti per un particolare
cliente;
Commessa: specifica la visualizzazione di tutte le spese sostenute dai dipendenti per una
particolare commessa;
Anche in questo, al fine di una corretta visualizzazione delle spese, è necessario tenere sempre separate
le spese di tipo chilometrico dalle altre tipologie di spesa, perché soggette a un diverso regime fiscale.
Gestione prenotazioni
La gestione delle prenotazioni dovrà essere disponibile esclusivamente per il personale del reparto
amministrativo con diritti “contribute”. I dipendenti potranno richiedere una prenotazione tramite mail
o telefono e successivamente accedere in sola lettura ai dati della prenotazione inserita
dall’amministrazione. L’inserimento di una nuova prenotazione sarà subordinato alla selezione di un
cliente e di una commessa con relativo “codice commessa” ad essa associato. Senza il codice commessa
non sarà possibile inserire l’informazione. La necessità di una prenotazione potrà scaturire da
un’indicazione da parte del dipendente verso l’amministrazione, la quale procederà all’inserimento della
prenotazione attraverso apposita sezione del portale. Al termine della prenotazione il dipendente
riceverà notifica di operazione avvenuta tramite mail automatica. In ogni momento avrà comunque la
14
possibilità di collegarsi al portale per visionare i dettagli della prenotazione. Al termine di ogni mese
l’amministrazione dovrà “Chiudere” le prenotazioni per quel mese, in modo da rendere le relative spese
disponibili per il processo di selezione di ciò che può essere fatturato ad un cliente (vedi Gestione Nota
Spese). Sarà quindi necessario mettere a disposizione dei dipendenti amministrativi una pagina con le
spese sostenute nelle note spese e le spese delle prenotazioni. In questo modo sarà possibile creare un
unico documento contenente tutte le spese da fatturare ai clienti. Sarà inoltre prevista una pagina in cui
l’utente dell’amministrazione potrà inserire tutti i fornitori dei servizi, siano essi alberghi, compagnie
aeree, aziende di noleggio auto, ecc. In questo modo sarà possibile tenere traccia dei fornitori già
utilizzati e risparmiare tempo in ricerca. In generale ci dovrà essere la possibilità di stampare su carta la
prenotazione.
Dati necessari
Le informazioni che il sistema deve gestire sono le seguenti:
Anno e Mese: indicano rispettivamente il mese e l’anno in cui verrà eseguita la fattura al cliente
Risorsa: indica il dipendente per il quale si sta inserendo la prenotazione
Cliente: indica il cliente per il quale si sta effettuando la prenotazione
Commessa: indica la commessa associata al cliente.
Tipo prenotazione
o Albergo
o Volo
o Navetta
o Treno
o Auto
Data inizio fruizione del bene
Data fine fruizione del bene
Data richiesta prenotazione: data in cui è pervenuta all’amministrazione la richiesta della
prenotazione
Città di partenza: indica la città di partenza, naturalmente questo campo è da inserire per tutti i
casi tranne quello in cui si stia prenotando un albergo
Città di destinazione: rappresenta la città di arrivo, da compilare per tutti i tipi di prenotazione
Prezzo: somma sostenuta per la prenotazione del servizio
Descrizione
Note
15
Esiste Penale: indica se la modifica o la cancellazione della prenotazione comporta o meno il
pagamento di una penale
Valore Penale: indica l’ammontare della penale, nel caso in cui questa sia prevista
Allegati
o Richiesta collega
o (Fattura)ricevuta
o Conferma dal fornitore
o Mail al collega e ufficio personale
o Fax di richiesta prenotazione
Dati fornitore
o Ragione sociale
o Indirizzo
o Telefono
o Email
o Sito internet
Data cancellazione prenotazione
Origine richiesta prenotazione
o Email
o A voce
o Telefono
Disponibilità auto aziendale: indica se l’auto aziendale è disponibile o meno al momento della
prenotazione
Identificativo auto: indica il numero di targa dell’auto che è stata prenotata.
2.2.3 Glossario dei termini
Per ridurre i rischi d’errore, derivanti da incomprensioni potenzialmente pericolose in fase di sviluppo, si
è stilato un glossario dei termini incontrati durante l’acquisizione dei requisiti. Tale glossario associa ad
ogni termine il suo significato.
Termine Descrizione Collegamenti
Nota Spese Documento contenente le spese sostenute da un dipendente in un determinato periodo (solitamente un mese)
Spese
16
Spesa Somma anticipata da un cliente per la quale si richiede un rimborso
Nota spese, Cliente, Commessa, Risorsa
Cliente Figura alla quale si è offerto il proprio servizio Commessa, Risorsa
Commessa Progetto associato al cliente per il quale vengono sostenute le spese
Cliente, Risorsa
Risorsa Dipendente dell’azienda Cliente, Commessa
Prenotazione Accordo anticipato per la fruizione di un servizio Cliente, Commessa, Risorsa
Centro di Costo Indica una suddivisione all’interno dell’azienda, in particolare si individuano: Commerciale, Produzione, Direttivo e Struttura
Risorsa
17
3 Disegno della Base di Dati
3.1 Introduzione
Lo sviluppo della base di dati per questo applicativo non ha potuto seguire un percorso tradizionale, in
quanto si era già in presenza di un’applicazione esistente con una propria base di dati. Si è proceduto
quindi analizzando il nuovo documento dei requisiti e creando solamente una tabella delle entità per
cercare di capire se le tabelle esistenti erano adeguate alle nuove esigenze.
L’applicativo presenta un’ulteriore problematica: esso infatti si deve appoggiare a una base di dati
esterna per recuperare le informazioni riguardanti le risorse, i clienti e le commesse. Infatti, in azienda è
presente un applicativo per il tracciamento delle ore lavorative al cui interno è necessario andare a
recuperare i dati fondamentali al corretto funzionamento dell’applicativo per la gestione delle note
spese. Partendo da questi presupposti si sono analizzate le varie entità.
3.2 Entità
Le entità sono gli oggetti principali del data base. Un'entità rappresenta un gruppo omogeneo
d'informazioni. Per questo applicativo sono state individuate le seguenti entità:
Costsheet: rappresenta la nota spese. Essa è caratterizzata da un mese e da un anno, necessari
ai fini del rimborso in busta paga, da una risorsa che ha compilato la nota spese e da un totale
anticipato, che rappresenta la somma che è stata anticipata al dipendente per sostenere le
spese.
CostsheetTrack: rappresenta ciascuna riga di una nota spese. Essa è caratterizzata dal cliente,
dalla commessa, dalla data della spesa, dalla sua tipologia, dal numero di chilometri percorsi,
dalla tipologia di attestazione ricevuta (se scontrino o fattura) e dall’ammontare della spesa.
Booking: rappresenta il foglio delle prenotazioni, al suo interno ritroviamo l’elenco di tutte le
prenotazione effettuate per un determinato mese e anno, con l’indicazione della risorsa che l’ha
creata e la data di creazione.
BookingTrack: rappresenta ciascuna riga del foglio delle prenotazioni, in pratica è la
prenotazione vera e propria. Al suo interno è necessario specificare la risorsa per cui si sta
effettuando la prenotazione, il cliente e la commessa associati, la tipologia di prenotazione e
l’ammontare della prenotazione.
ExpenseType: rappresenta il tipo di spesa, associata alla nota spese. In pratica serve a
identificare la tipologia di spesa sostenuta dal dipendente, che può essere di vari tipi: trasporti,
vitto, alloggio, altro, km.
18
BookingType: rappresenta il tipo di prenotazione che può essere aereo, albergo, automobile,
navetta o treno.
Status: indica lo status di una nota spese, che può trovarsi nei seguenti stati, in base al livello di
avanzamento:
o Accettata: la nota spese è stata accettata dall’approvatore e quindi le spese al suo
interno sono disponibili per la successiva fase di fatturazione;
o Compilata: la nota spese è stata compilata dalla risorsa e ne è stata richiesta
l’approvazione;
o Rifiutata: la nota spese è stata rifiutata dall’approvatore;
o Da compilare: la nota spese è in fase di compilazione e quindi non ne è stata ancora
chiesta l’approvazione.
Supplier: rappresenta il fornitore del servizio per la parte relativa alla gestione delle
prenotazioni. Quest’entità è caratterizzata da una ragione sociale, da un indirizzo, un numero di
telefono e dalla tipologia.
3.3 Tabelle
Ogni entità e rappresentabile all’interno del database tramite una tabella. Ecco quindi le tabelle
risultanti per la base di dati progettata.
Costsheet
ID È il codice univoco che individua ciascuna nota spesa
Month È il mese al quale si riferisce la nota spese
Year È l’anno al quale si riferisce la nota spese
IdUser Rappresenta il codice univoco associato alla risorsa che ha compilato la nota spese
IdStatus Rappresenta il codice univoco associato allo stato della nota spese
Note Note che accompagnano la nota spese
TotalAdvance Totale anticipato
NoCosts Indica se è si tratta di una nota spese senza spese
NoBilling Indica se si tratta di una nota spese che non deve essere fatturata
CreateBy Indica il nome della risorsa che ha compilato effettivamente la nota spese
CreateDate Data in cui è stata creata la nota spese
19
ApprovalDate Data in cui è stata approvata la nota spese
Tabella 3-1: Costsheet
CostsheetTrack
ID È il codice univoco che individua ciascuna spesa
IdCostsheet Rappresenta il codice univoco che associa la spesa alla nota spese
Date Data in cui è stata sostenuta la spesa
IdExpenseType Rappresenta il codice unico che identifica il tipo di spesa sostenuta
Amount Esprime il prezzo della spesa
Km Indica i Km che sono stati sostenuti per tale spesa
DestinationCity Rappresenta la città di destinazione per il viaggio sostenuto
Note Piccola descrizione per spiegare meglio la spesa sostenuta
IdCustomer Rappresenta il codice univoco associato al cliente per il quale è stata sostenuta
la spesa
IsCommessa Rappresenta il codice univoco associato alla commessa al quale la risorsa ha
lavorato
KmForBilling Indica quanti sono i Km che è possibile fatturare al cliente
KmRefoundRateForBilling Indica il coefficiente del rimborso chilometrico per la fatturazione
AmountTripForBilling Rappresenta il totale fatturabile al cliente
TicketNumber Indica il numero sequenziale associato allo scontrino
Billing Indica se la spesa è stata selezionata per la fatturazione
IsEntertainmentExpense Indica se è una spesa di rappresentanza
IsBill Indica se per la spesa sostenuta si è ricevuta fattura o scontrino
Tabella 3-2: CostsheeTrack
Booking
ID È il codice univoco che individua ciascun foglio delle prenotazioni
Month Identifica il mese nel quale è fatturata la prenotazione
Year Rappresenta l’anno nel quale è fatturata la prenotazione
Closed Indica se il foglio delle prenotazioni è stato chiuso e reso disponibile per la fatturazione
20
CreateBy Indica la risorsa ce ha creato il foglio delle prenotazioni
CreateDate Indica la data di creazione del foglio delle prenotazioni
Tabella 3-3: Booking
BookingTrack
ID È il codice univoco che individua ciascuna prenotazione
IdUser Identifica la risorsa per la quale si è effettuata la prenotazione
IdBooking Indica a quale foglio prenotazioni è associata la prenotazione corrente
IdCustomer Rappresenta il codice univoco associato al cliente al quale si addebiterà la
prenotazione
IdCommessa Rappresenta il codice univoco associato alla commessa
IdBookingType Rappresenta il codice univoco associato al tipo di prenotazione
StartBookingDate Data di inizio fruizione del bene
EndBookingDate Data di fine fruizione del bene
RequestDate Data in cui è stata ricevuta la richiesta per la prenotazione
DepartureCity Città di partenza
ArrivalCity Città di arrivo
Amount Prezzo della prenotazione
Description Descrizione sintetica della prenotazione
Note Note sulla prenotazione
ExistPenal Indica se esiste o meno una penale
Penal Valore della penale
IdAttachment Codice identificativo associato all’allegato
IdSupplier Codice identificativo associato al fornitore del servizio
CancelDate Data di cancellazione della prenotazione
IdRequestSource Codice identificativo associato al tipo di richiesta
CompanyCarAvailable Indica se l’auto aziendale è dispobile
LicensePlate Rappresenta il numero di targa dell’auto prenotata
Tabella 3-4: BookingTrack
21
ExpenseType
ID È il codice univoco che individua ciascun tipo di spesa
Description Descrive la tipologia di spesa
MaxAmount Indica la soglia massima spendibile per quel tipo di spesa
Tabella 3-5: ExpenseType
BookingType
ID È il codice univoco che individua ciascun tipo di prenotazione
Description Descrive la tipologia di prenotazione
Tabella 3-6: BookingType
Status
ID È il codice univoco che individua ciascuno status
Code Codice dello status
Description Descrive la tipologia di prenotazione
Tabella 3-7: Status
Supplier
ID È il codice univoco che individua ciascun fornitore
RagioneSociale Rappresenta la ragione sociale del fornitore
Address Indica l’indirizzo del fornitore
City Indica la città del fornitore
Telephone Rappresenta il numero di telefono del fornitore
Email Rappresenta la mail del fornitore
Tabella 3-8:Supplier
RequestSource
ID È il codice univoco che individua l’origine della prenotazione
Name Rappresenta l’origine della prenotazione
Description Descrive brevemente l’origine della prenotazione
Tabella 3-9: RequestSource
22
3.4 Osservazioni
Rispetto al data base esistente è emerso che mancano alcuni campi importanti, soprattutto nella tabella
CostsheetTrack, quella relativa alle singole spese di una nota spese. Perciò sono stati aggiunte le
seguenti colonne:
DestinationCity: indica la città di destinazione, da valorizzare solo nel caso in cui la tipologia di
spese sia chilometrica;
IsBill: campo relativo alla tipologia di attestazione ricevuta, cioè se scontrino o fattura;
IsEntertainmentExpense: campo indicante se la spesa sostenuta è una spesa di rappresentanza.
La tabella che però più di tutte ha avuto bisogno di una ristrutturazione importante è stata quella
relativa alle prenotazioni, cioè la tabella BookingTrack. A questa infatti è stato necessario aggiungere
una decina di nuovi campi, prima non presenti:
StartBookingDate: colonna che indica la data di inizio di fruizione del bene;
EndBookingDate: colonna indicante la data di fine di fruizione del bene;
RequestDate: indica la data in cui è stata ricevuta la richiesta;
DepartureCity: indica la città di partenza;
ArrivalCity: indica la città di destinazione;
ExistPenal: indica se la cancellazione o modifica della prenotazione comporta il pagamento di
una penale;
Penal: definisce l’ammontare della penale;
CompanyCarAvailable: indica se l’auto aziendale è disponibile oppure no.
IdSupplier: indica l’identificativo del fornitore
Infine è stato necessario creare la tabella relativa ai fornitori, che non era stata pensata per l’applicativo
precedente.
3.5 Schema fisico Ecco infine come si presenta lo schema fisico dell’applicativo. Nella prima immagine viene riportato lo
schema fisico aggiornato del database relativo alla gestione delle note spese. Nella seconda immagine vi
è invece parte dello schema del database relativo al tracciamento delle ore lavorative, dal quale
vengono recuperati i dati necessari per le risorse, i clienti e le commesse.
23
Figura 3-1: Gestione Nota Spese
Figura 3-2: Tracciamento ore lavorative
Costsheet
ID
Month
Year
IdUser
IdStatus
Note
TotalA dv ance
NoC osts
NoBilling
C reateBy
C reateDate
A pprov alDate
CostsheetTrack
ID
IdC ostsheet
Date
IdExpenseTy pe
Amount
Km
DestinationC ity
Note
Prepaid
IdC ustomer
IdC ommessa
KmForBilling
KmRefoundRateForBilling
AmountTripForBilling
TicketNumber
Billing
IsEntertainmentExpense
IsBill
Status
ID
Code
Description
ExpenseType
ID
Description
MaxAmount
Prepaid
Booking
Booking
ID
Month
Year
C losed
C reateBy
C reateDate
BookingTrack
ID
IdUser
IdBooking
IdC ustomer
IdC ommessa
IdBookingTy pe
StartBookingDate
EndBookingDate
RequestDate
DepartureC ity
A rriv alC ity
Amount
Description
Note
ExistPenal
Penal
IdA ttachment
IdSupplier
C ancelDate
IdRequestSource
C ompanyC arA v ailable
LicensePlate
BookingType
ID
Description
Supplier
ID
RagioneSociale
A ddress
C ity
Telephone
RequestSource
ID
Name
Description
CLIENTI
ID
Ragione
Note
IDAM
CRMRef
GUID
COMMESSE
ID
IDProgetto
Commessa
Descrizione
CodiceCommessa
CommessaAM
Disable
GiornateVendute
IDTipoCommessa
DataChiusura
DataInizio
GUID
RISORSE_COMMESSE
ID
IDRisorsa
IDCommessa
RISORSE
ID
Alias
Sede
Nome_Risorsa
IDTipoRisorsa
IDGruppo
Telefono
Cellulare
Fax
MailCLiente
IDResponsabile
AllowTracking
Disable
AllowInsertRecupero
IDProfilo
IDAzienda
GUID
PROGETTI
ID
IDCliente
Progetto
Descrizione
Disable
CodiceProgetto
ProgettoAM
IDPM
IDCategoria
IDAzienda
GUID
TIPICOMMESSA
IDTipoCommessa
Descrizione
MonteOre
PrevedeDataChiusura
UnitaMisura
OrdineFatturazione
Fatturabile
24
3.6 Trigger Una novità importante che è stata introdotta nella base di dati sono i trigger. In questa particolare
applicazione i trigger sono particolarmente utili in quanto permettono di gestire l’integrità referenziale
fra tabelle appartenenti a database diversi. La gestione dell’integrità avviene però solamente in una
direzione, in quanto non è stato possibile modificare la tabella con la chiave primaria presente nel
database del tracciamento delle ore lavorative, in quanto già in produzione. Infatti per rendere
l’integrità più completa sarebbe stato necessario un trigger che, alla cancellazione di un record con la
chiave primaria, scrivesse il valore null in corrispondenza della chiave esterna. Perciò sono stati
sviluppati solo trigger che all’inserimento di nuovi valori nel database della gestione delle note spese
effettuano un controllo sull’esistenza o meno delle chiavi esterno inserite in tabella.
Ecco una tabella con l’elenco dei trigger implementati per la base di dati:
Trigger Tabella / Operazione Descrizione
IU_Booking Booking / AFTER INSERT, UPDATE
Viene attivato dopo l’inserimento o l’aggiornamento di una riga. Questo trigger è stato creato per gestire l’integrità referenziale. Viene verificato che esista l’id del cliente. Viene verificato che esista l’id della commessa. Viene verificato che esista l’id della risorsa
IU_CostsheetTrack CostsheetTrack / AFTER INSERT, UPDATE
Viene attivato dopo l’inserimento o l’aggiornamento di una riga. Viene verificato che esista l’id del cliente. Viene verificato che esista l’id della commessa.
IU_Costsheet Costsheet / AFTER INSERT, UPDATE
Viene attivato dopo l’inserimento o l’aggiornamento di una riga. Questo trigger è stato creato per gestire l’integrità referenziale. Viene verificato che esista l’id della risorsa.
Tabella 3-10: Triggers
3.7 Stored Procedures Una stored procedure è in genere un set ordinato di comandi T-SQL (linguaggio usato per interrogare
Microsoft SQL-SERVER) che costituiscono insieme una singola unità logica. Permettono la definizione di
parametri in ingresso e in uscita, la definizione di variabili, come anche la selezione di dati e la
definizione di cicli.
Le stored procedures offrono molti vantaggi rispetto all’invio di singoli comandi al server:
25
permettono di usare nomi brevi invece di lunghe stringhe per richiedere l’esecuzione di
operazioni anche complesse;
sono pre-ottimizzate e precompilate risparmiando tempo ogni volta che la SP viene richiamata;
possono essere richiamate da alte SPs rendendo il codice riutilizzabile.
Non sono transazionali di per sé ma può rendersi necessario l’uso di transazioni per garantire l’atomicità
di un operazione complessa e la consistenza dei dati.
Nome della Stored Procedure Parametri Descrizione
Costsheet_InsertForCurrentMonth Inserisce per tutti gli utenti il costsheet per il mese corrente, se mancante
Costsheet_GetByMonthYearIdUser @Month int @Year int @IdUser uniqueidentifier
Restituisce le note spese (costsheet) di una certa risorsa in un certo mese e in un certo anno.
Costsheet_IsApproved @ID uniqueidentifier @IsApproved bit OUTPUT
Verifica se lo stato di una nota spese è approvato
CostsheetTrack_GetByIdCostsheet_Joined @IdCostsheet uniqueidentifier
Estrae i dati del CostsheetTrack in base all'id del Costsheet e se il costo è prepagato o meno. Le join vengono fatte sulle tabelle ExpenseType, Currency del db TeoNotaSpese e CLIENTI E PROGETTI del db TeoTracking al fine di estrarne le rispettive descrizioni
CostsheetTrack_UpdateBulkAfterVAPP @costsheetTrackUpdateXML text
Aggiorna i campi del costsheettrack tramite file xml.
GetUsersWhoHaveToCompile_ForVAPP @Month_From int @Year_From int @Month_To int @Year_To int @IDCustomer uniqueidentifier @IDCommessa uniqueidentifier
Restituisce l'elenco delle note spesa (per mese ed anno) non ancora compilate appartenenti ad utenti afferenti la commessa selezionata.
Costsheet_ResetStatus @IdUser uniqueidentifier @Year int @Month int
Resetta lo stato di una nota spese imposta i campi [IdStatus] a TOCOMPILE ed [ApprovedBy] e [ApprovalDate] a NULL.
Tabella 3-11: Stored Procedures
26
4 Migrazione da SharePoint 2007 a SharePoint 2010
Microsoft SharePoint Server 2010 è stato progettato per garantire la scalabilità e migliorare le
prestazioni e, come tale, richiede i componenti hardware e software aggiuntivi descritti di seguito.
Questi requisiti si applicano sia all'approccio con aggiornamento sul posto che a quello con
aggiornamento basato sul collegamento di database. Per facilitare un aggiornamento prevedibile e
ridurre al minimo l'impatto dei problemi di personalizzazione e ambientali che possono impedire la
corretta esecuzione dell'aggiornamento, è possibile utilizzare il cmdlet Windows PowerShell test-
spcontentdatabase, la nuova opzione Console di aggiornamento oppure l'operazione Stsadm
preupgradecheck.
4.1 Requisiti per l'aggiornamento
Prima di poter eseguire un aggiornamento sul posto o un aggiornamento basato sul collegamento di
database a SharePoint Server 2010, l'ambiente di Office SharePoint Server 2007 esistente o il nuovo
ambiente di SharePoint Server 2010 deve soddisfare i requisiti minimi riportati di seguito.
4.1.1 Requisito hardware: 64 bit
SharePoint Server 2010 può essere eseguito solo in una versione a 64 bit del sistema operativo Windows
Server 2008 R2 o Windows Server 2008 con SP2. Se si prevede di eseguire un aggiornamento sul posto,
l'installazione di Office SharePoint Server 2007 deve essere eseguita in un ambiente Windows Server
2008 a 64 bit. Se l'installazione di Office SharePoint Server 2007 si trova in un ambiente a 32 bit, non
sarà possibile eseguire un aggiornamento sul posto nel server o nella server farm esistente. Sarà
necessario installare SharePoint Server 2010 in un server o in una farm diversa che supporti le
applicazioni a 64 bit e quindi spostare i dati in tale server o farm utilizzando il metodo di aggiornamento
basato sul collegamento di database. Per individuare e risolvere più facilmente eventuali problemi dei
processi di migrazione e aggiornamento, è consigliabile non combinare le azioni di migrazione a un
ambiente a 64 bit e di aggiornamento sul posto a SharePoint Server 2010. Poiché è richiesto un
ambiente a 64 bit per eseguire l'aggiornamento sul posto a SharePoint Server 2010, è necessario
eseguire la migrazione a un sistema operativo a 64 bit prima di eseguire un aggiornamento sul posto. Se
si utilizza un metodo di aggiornamento basato sul collegamento di database, sarà possibile eseguire la
migrazione a un ambiente a 64 bit nell'ambito del processo di aggiornamento.
27
Prima di eseguire la migrazione a un ambiente a 64 bit:
Aggiornare Office SharePoint Server 2007 allo stesso Service Pack o livello di aggiornamento
software in tutti i computer della farm di origine.
Determinare se è necessario ricompilare le applicazioni a 32 bit esistenti e gli assembly
personalizzati, ad esempio le web part e i ricevitori di eventi, per l'esecuzione nell'ambiente a 64
bit. Alcune applicazioni possono essere eseguite in entrambi gli ambienti e non devono essere
ricompilate. Se le applicazioni esistenti sono di terze parti, controllare con il fornitore di terze
parti le versioni a 64 bit e la compatibilità.
4.1.2 Requisito di sistema operativo
SharePoint Server 2010 deve essere eseguito in una versione a 64 bit di Windows Server 2008 R2 o
Windows Server 2008 con Service Pack 2 (SP2). È possibile combinare la migrazione all'hardware a 64 bit
con la migrazione a Windows Server 2008 o Windows Server 2008 R2. Se si utilizza già hardware a 64 bit,
è possibile eseguire l'aggiornamento da Windows Server 2003 a Windows Server 2008 o Windows
Server 2008 R2. Se si esegue la migrazione a hardware a 64 bit, eseguire inoltre la migrazione a
Windows Server 2008 o Windows Server 2008 R2 contemporaneamente.
4.1.3 Requisito del database management system
SharePoint Server 2010 richiede un server database a 64 bit di una delle versioni seguenti: Microsoft
SQL Server 2008 R2, SQL Server 2008 con Service Pack 1 (SP1) e aggiornamento cumulativo 2 o SQL
Server 2005 con SP3 e aggiornamento cumulativo 3. Se nell'installazione corrente di Office SharePoint
Server 2007 viene utilizzato SQL Server 2000, sarà necessario eseguire l'aggiornamento a una di queste
versioni prima dell'aggiornamento a SharePoint Server 2010.
4.1.4 Strumento di verifica pre-aggiornamento
Lo strumento di verifica pre-aggiornamento è uno strumento da riga di comando che viene eseguito in
un ambiente di Office SharePoint Server 2007 per individuare potenziali problemi per l'aggiornamento e
per esaminare i suggerimenti e le procedure consigliate.
STSADM.exe -o preupgradecheck
Utilizzando lo strumento di verifica pre-aggiornamento, è possibile ottenere diverse informazioni, tra
cui:
Un elenco di tutti i server e i componenti della farm e l'indicazione se i server soddisfano i
requisiti seguenti per l'aggiornamento: hardware a 64 bit e sistema operativo Windows Server
2008.
28
Gli URL di mapping di accesso alternativo in uso nella farm.
Un elenco di tutte le definizioni di sito, i modelli di sito, le caratteristiche e i Language Pack
installati nella farm.
La presenza di eventuali personalizzazioni nella farm non supportate, ad esempio modifiche
dello schema di database.
L'eventuale presenza di elementi orfani di database o sito nella farm.
L'esistenza di eventuali impostazioni di configurazione mancanti o non valide nella farm, ad
esempio un file Web.config mancante, nomi host non validi o account di servizio non validi.
L'indicazione se i database soddisfano i requisiti per l'aggiornamento, ad esempio se i database
sono impostati per la lettura/scrittura e se i database e le raccolte siti archiviati in Database
interno di Windows non superano 4 GB di dimensioni.
Lo strumento di verifica pre-aggiornamento è disponibile in Office SharePoint Server 2007 Service Pack 2
ed è stato aggiornato nell'aggiornamento cumulativo di ottobre 2009 per Microsoft Windows
SharePoint Services 3.0 e Microsoft Office SharePoint Server 2007.
4.1.5 Comando di Windows PowerShell per la verifica dei database
È possibile utilizzare il cmdlet di Windows PowerShell test-spcontentdatabase prima di collegare un
database del contenuto a SharePoint Server 2010 per stabilire se nell'ambiente mancano eventuali
personalizzazioni sul lato server.
4.1.6 Console di aggiornamento
Una nuova caratteristica disponibile con l'aggiornamento consente all'amministratore di server o al
proprietario di siti di determinare quando e se utilizzare il nuovo aspetto di SharePoint Server 2010 per
una raccolta siti specifica. Gli amministratori di server possono scegliere di adottare il nuovo aspetto per
tutti i siti durante l'aggiornamento, fare in modo che siano i proprietari dei siti a scegliere dopo
l'aggiornamento o mantenere l'aspetto precedente per tutti i siti. Se l'amministratore del server delega
la decisione ai proprietari di siti dopo l'aggiornamento di un sito tramite un aggiornamento sul posto,
sarà disponibile un'opzione di anteprima nell'interfaccia utente dei siti. Tale opzione consente di
visualizzare un'anteprima dell'aspetto di SharePoint Server 2010 per il sito:
Se gradisce l'aspetto e il funzionamento del sito, il proprietario può accettare l'aggiornamento
visivo.
Se invece desidera mantenere l'aspetto precedente, il proprietario può ripristinare l'aspetto di
Office SharePoint Server 2007.
Per impostazione predefinita, viene mantenuto l'aspetto di Office SharePoint Server 2007.
29
4.2 Panoramica del processo di aggiornamento
Quando si esegue l'aggiornamento da Microsoft Office SharePoint Server 2007 a Microsoft SharePoint
Server 2010, è possibile scegliere due metodi diversi, ovvero l'aggiornamento sul posto e quello basato
sul collegamento di database. Un aggiornamento sul posto consente di aggiornare tutti i siti di Microsoft
SharePoint sullo stesso hardware, mentre un aggiornamento basato sul collegamento di database
consente di spostare il contenuto in una nuova farm o in un nuovo hardware. È possibile inoltre
combinare questi due tipi di aggiornamento in metodi ibridi che riducono il tempo di inattività durante
l'aggiornamento stesso. Per il caso d’interesse si è proceduto effettuando un aggiornamento basato sul
collegamento del database, visto che le risorse hardware in cui era installato SharePoint 2007 non erano
sufficienti ad eseguire la versione 2010.
4.2.1 Aggiornamento basato sul collegamento di database
Un aggiornamento basato sul collegamento di database consente di passare a un nuovo componente
hardware o a una nuova farm. Durante un aggiornamento di questo tipo, si scollegano tutti i database
del contenuto da una farm esistente per poi collegarli all'installazione di una nuova server farm. Quando
si collegano i database alla nuova server farm, viene eseguito il processo di aggiornamento e i dati
vengono aggiornati sul posto. Nei passaggi seguenti viene descritto quanto avviene durante un
aggiornamento basato sul collegamento di database:
1. L'amministratore di server installa e configura una nuova farm di SharePoint Server 2010 e
quindi trasferisce tutte le personalizzazioni nella nuova farm e verifica l'ambiente.
2. L'amministratore di server scollega i database del contenuto dalla farm di Office SharePoint
Server 2007 precedente e disconnette la farm, ad esempio modificando il servizio di
bilanciamento del carico o le applicazioni Web IIS in modo da arrestare le richieste dei servizi
oppure disattivando tutti i componenti e i servizi in ogni computer server della farm.
3. L'amministratore di server collega i database del contenuto alla nuova farm e aggiorna il
contenuto.
4. L’amministratore di server verifica che l'aggiornamento sia stato eseguito correttamente e
quindi configura la nuova farm in modo da iniziare a gestire le richieste del nuovo URL.
4.2.2 Procedure consigliate per testare l'aggiornamento
Per conoscere l'ambiente prima di tentare di effettuare un aggiornamento e per eseguire una
pianificazione accurata del tempo necessario per l'aggiornamento, è consigliabile eseguire uno o più
aggiornamenti di prova. L'obiettivo di tale testing è quello di individuare e risolvere anticipatamente
eventuali problemi, in modo da poter essere certi del processo e del relativo esito al momento
dell'esecuzione dell'aggiornamento vero e proprio. Per eseguire un testing utile e accurato del processo
30
di aggiornamento da Microsoft Office SharePoint Server 2007 a Microsoft SharePoint Server 2010,
eseguire le procedure consigliate seguenti:
1. Rendere l'ambiente di testing il più simile possibile all'ambiente reale. Se possibile, utilizzare lo
stesso tipo di hardware e configurarlo con le stesse impostazioni, gli stessi URL e così via. È
consigliabile eliminare il più possibile le differenze tra l'ambiente di testing e l'ambiente reale.
Più saranno numerose le differenze, più sarà il tempo necessario per risalire a eventuali
problemi non correlati per essere certi che non si verifichino durante l'aggiornamento effettivo.
2. Conoscere quanto più possibile la composizione dell'ambiente. Eseguire innanzitutto un esame
completo. Prendere nota dell'hardware e del software presenti nell'ambiente, delle
personalizzazioni del lato server installate e utilizzate, della relativa posizione, nonché delle
impostazioni necessarie. Ciò consentirà di effettuare una pianificazione più completa e di
eseguire più facilmente un ripristino nel caso l'aggiornamento avesse esito negativo.
3. Utilizzare dati reali. Per eseguire i test, utilizzare copie dei database effettivi. Quando si esegue
un test utilizzando dati reali, è possibile identificare le eventuali aree problematiche, nonché
determinare le prestazioni dell'aggiornamento. In questo modo si ha inoltre l'opportunità di
misurare la durata di diverse sequenze e azioni di aggiornamento eseguite su tipi di dati diversi.
Se non è possibile testare tutti i dati, eseguire il test su un sottoinsieme di dati rappresentativo
per essere certi di aver individuato tutti gli eventuali problemi con le dimensioni e i tipi diversi di
siti, elenchi, raccolte e personalizzazioni presenti nell'ambiente.
4. Eseguire più test. Un singolo test può indicare se si verificheranno problemi di grossa portata,
ma eseguendo più test si avrà la certezza di aver individuato tutti i problemi che potrebbero
verificarsi e si potrà calcolare in modo più preciso la tempistica del processo. L'esecuzione di più
test consente di stabilire quali metodi di aggiornamento saranno più efficaci per il proprio
ambiente, di quali tecniche pianificare l'utilizzo per ridurre al minimo il tempo di inattività e con
quali modalità possono cambiare le prestazioni o il processo dopo avere risolto i problemi
rilevati nel corso dei primi test. Il test finale ha la funzione di confermare che tutti gli errori siano
stati eliminati e che si è pronti per aggiornare l'ambiente di produzione.
5. Non ignorare gli avvisi. Benché non si tratti di un errore, la situazione segnalata da un avviso può
dare luogo a problemi in una fase successiva del processo di aggiornamento. Cercare di
eliminare gli errori, ma esaminare attentamente anche gli avvisi, in modo da essere ben
consapevoli di quali potrebbero esserne gli effetti.
6. Testare l'ambiente aggiornato, non solo il processo di aggiornamento. Verificare i servizi e le
applicazioni di servizio. Eseguire una ricerca per indicizzazione ed esaminare i file di registro.
Controllare che i siti Web personali funzionino.
31
7. Verificare i siti in entrambe le modalità della Console di aggiornamento. Non presumere che, se
è possibile visualizzare correttamente l'anteprima del sito in una modalità, questo funzioni
anche nell'altra modalità. Provare a utilizzare sia la versione precedente che quella nuova.
8. Considerare la possibilità di avere un ambiente di anteprima. È possibile creare un ambiente di
anteprima in cui gli utenti possano controllare i propri siti dopo un aggiornamento di prova ed
essere di aiuto nella verifica dell'aggiornamento e nell'individuazione dei problemi. A tale scopo,
è possibile avvalersi di un ambiente di sola lettura oppure consentire agli utenti di apportare le
modifiche desiderate, avvertendoli che tali modifiche non verranno tuttavia salvate.
Considerare la possibilità di limitare tale ambiente di anteprima a un gruppo di pochi siti
rappresentativi e di consentire l'accesso alle sole persone interessate, in modo da ridurre il
tempo necessario per ospitare l'ambiente di anteprima e la quantità di commenti ricevuti.
4.3 Allegare database ed eseguire l'aggiornamento
Quando si esegue l'aggiornamento da Microsoft Office SharePoint Server 2007 a Microsoft SharePoint
Server 2010 mediante il metodo di aggiornamento basato sul collegamento di database, viene
aggiornato solo il contenuto dell'ambiente e non le impostazioni di configurazione. Il metodo basato sul
collegamento di database è particolarmente utile se si cambia l'hardware oppure se si desidera
riconfigurare la topologia della server farm come parte del processo di aggiornamento.
Il primo passaggio del processo consiste nell'allestire un nuovo ambiente in cui ospitare il contenuto
aggiornato. Dopo aver creato il nuovo ambiente, è possibile utilizzare le procedure illustrate in questo
articolo per scollegare e quindi ricollegare i database allo scopo di effettuare l'aggiornamento effettivo.
4.3.1 Panoramica del processo
Quando si effettua l'aggiornamento basato sul collegamento di database, si rimuovono i database nella
farm precedente e quindi si collegano alla nuova farm. Quando si collega un database alla nuova farm,
viene eseguito il processo di aggiornamento e viene aggiornato l'intero database. Il processo di
aggiornamento basato sul collegamento di database è simile al processo di aggiornamento sul posto.
L'unica differenza è rappresentata dal fatto che il processo di aggiornamento basato sul collegamento di
database viene eseguito manualmente e in un ambiente separato. Se si desidera mantenere la farm
originale e consentire agli utenti di continuare ad accedere ai dati, è necessario impostare i database in
sola lettura e collegare una copia di backup dei database. È possibile collegare e aggiornare i database
da Microsoft Office SharePoint Server 2007 o Microsoft Windows SharePoint Services 3.0 in un nuovo
ambiente Microsoft SharePoint Server 2010. I passaggi per impostare e collegare i database al nuovo
ambiente sono gli stessi per entrambe le origini.
32
4.3.2 Prima di iniziare
Verificare che siano soddisfatti tutti i requisiti hardware e software. È necessario disporre di una
versione a 64 bit di Windows Server 2008 o di Windows Server 2008 R2. Per le server farm è
inoltre necessario disporre di una versione a 64 bit di SQL Server 2005 o di SQL Server 2008. Per
ulteriori informazioni su tali requisiti, ad esempio sugli aggiornamenti specifici che devono
essere installati, vedere Determinare i requisiti hardware e software (SharePoint Server 2010).
Assicurarsi di essere pronti a impostare gli account necessari utilizzando le autorizzazioni
appropriate.
Verificare che l'account utilizzato per aggiungere i database sia membro del ruolo predefinito
del database db_owner per i database del contenuto che di desidera aggiornare.
Eseguire lo strumento di verifica pre-aggiornamento sui siti archiviati nei database. La verifica
pre-aggiornamento consente di identificare potenziali problemi di aggiornamento nell'ambiente
in modo da poterli affrontare prima dell'aggiornamento.
Creare un nuovo ambiente server farm.
Ricercare e correggere gli eventuali errori di coerenza di database.
4.3.3 Impostare per la sola lettura i database della versione precedente
Se per l'aggiornamento si utilizza l'approccio ibrido dei database di sola lettura, impostare i database
della versione precedente per la sola lettura prima di eseguirne il backup. In qualsiasi tipo di
aggiornamento basato sul collegamento di database è anche possibile impostare temporaneamente i
database per la sola lettura per assicurarsi di acquisire tutti i dati nel backup in modo da ripristinare e
aggiornare lo stato corrente dell'ambiente. Se i database vengono impostati per la sola lettura, gli utenti
potranno continuare a visualizzare il contenuto, ma non saranno in grado di effettuare aggiunte o
modifiche.
Importante: non è possibile aggiornare un database in sola lettura. Se si utilizza un collegamento di
database con database di sola lettura, si ripristina una copia del database e si esegue l'aggiornamento
della copia. Se non si utilizza questo metodo ma si desidera impostare temporaneamente i database per
la sola lettura mentre si esegue il backup dei dati correnti, accertarsi di impostare i database per la
lettura-scrittura prima di collegarli e aggiornarli.
Al termine di questa procedura, saranno stati creati i duplicati dei database del contenuto di sola
lettura.
4.3.4 Per eseguire il backup di un database in SQL Server 2008
1. Nel server database fare clic sul pulsante Start, scegliere Tutti i programmi, Microsoft SQL Server
2008 e quindi SQL Server Management Studio.
33
2. Nella casella Connetti al server immettere le informazioni per la connessione e quindi fare clic su
Connetti .
3. Dopo essersi connessi all'istanza appropriata del motore di database di SQL Server 2008, in
Esplora oggetti espandere il nome del server.
4. Espandere Database, fare clic con il pulsante destro del mouse sul database di cui si desidera
eseguire il backup, scegliere Attività e quindi Backup. Verrà visualizzata la finestra di dialogo
Backup database.
5. Nella casella Database dell'area Origine verificare il nome del database.
6. Nella casella Tipo di backup selezionare Completo.
7. In Componente di cui eseguire il backup selezionare Database.
8. Nell'area Set di backup accettare il nome predefinito o digitare un nuovo nome nella casella di
testo Nome.
9. Nell'area Destinazione specificare il tipo di destinazione di backup selezionando Disco o Nastro e
quindi specificare una destinazione. Per creare una destinazione diversa, fare clic su Aggiungi.
10. Fare clic su OK per avviare il processo di backup.
Ripetere la procedura precedente per eseguire il backup dei database del contenuto e dei servizi
condivisi utilizzati da Microsoft Office SharePoint Server 2007 nell'ambiente.
4.3.5 Scollegare i database della versione precedente
Per collegare i database al nuovo ambiente e aggiornare i dati, è necessario scollegarli dall'ambiente
corrente, spostarli quindi in un nuovo server di database o lasciarli in quello esistente e collegarli alle
applicazioni Web.
Per scollegare un database del contenuto da un'applicazione Web
1. Nella sezione Gestione applicazione Web SharePoint della pagina Gestione applicazioni di
Amministrazione centrale fare clic su Database del contenuto.
2. Nella pagina Gestisci database del contenuto fare clic sul database del contenuto che si desidera
scollegare.
3. Nella sezione Rimozione database del contenuto della pagina Gestisci impostazioni database del
contenuto selezionare la casella di controllo Rimuovi database del contenuto e quindi fare clic
su OK.
4. Ripetere i passaggi 2 e 3 per ogni database del contenuto da scollegare.
È anche possibile utilizzare l'operazione Stsadm deletecontentdb per scollegare un database del
contenuto da un'applicazione Web. Se si intende spostare i database in un server di database diverso, è
34
necessario scollegare anche i database dall'istanza di SQL prima di spostarli e collegarli alla nuova
istanza di SQL Server dopo averli spostati.
4.3.6 Ripristinare una copia di backup del database
Dopo avere configurato la nuova server farm, è possibile ripristinare le copie di backup dei database in
una delle edizioni seguenti: Microsoft SQL Server 2008 R2, SQL Server 2008 con Service Pack 1 (SP1) e
aggiornamento cumulativo 2 e SQL Server 2005 con SP3 e aggiornamento cumulativo 3. Si noti che è
necessario eseguire il ripristino in una versione a 64 bit di SQL Server 2008 R2, SQL Server 2008 con SP1
e aggiornamento cumulativo 2 e SQL Server 2005 con SP3 e aggiornamento cumulativo 3. Iniziare con un
database e quindi verificare che il ripristino abbia funzionato prima di ripristinare gli altri database.
Per ripristinare una copia di backup di un database in SQL Server 2008
1. Dopo essersi connessi all'istanza appropriata del motore di database di SQL Server 2008, in
Esplora oggetti espandere il nome del server.
2. Fare clic con il pulsante destro del mouse su Database e quindi scegliere Ripristina database.
Verrà visualizzata la finestra di dialogo Ripristina database.
3. Nella pagina Generale della finestra di dialogo Ripristina database digitare il nome del database
da ripristinare nell'elenco Database di destinazione.
4. Nella casella di testo Temporizzazione lasciare l'impostazione predefinita, ovvero Più recente.
5. Per specificare l'origine e il percorso dei set di backup da ripristinare, fare clic su Dispositivo di
origine e quindi su Sfoglia per selezionare il file di backup.
6. Nella finestra di dialogo Seleziona backup verificare che nella casella Supporti di backup sia
selezionato File.
7. Nell'area Percorso backup fare clic su Aggiungi.
8. Nella finestra di dialogo Individua file di backup selezionare il file che si desidera ripristinare,
fare clic su OK e quindi nella finestra di dialogo Seleziona backup fare clic su OK.
9. Nella griglia Selezionare i set di backup da ripristinare della finestra di dialogo Ripristina
database selezionare la casella di controllo Ripristina accanto al backup completo più recente.
10. Nella pagina Opzioni della finestra di dialogo Ripristina database selezionare la casella di
controllo Sovrascrivi il database esistente in Opzioni di ripristino.
11. Fare clic su OK per avviare il processo di ripristino.
4.3.7 Verifica dell'aggiornamento per il database
Dopo avere collegato un database, è possibile utilizzare la pagina Stato aggiornamento di
Amministrazione centrale per verificare lo stato dell'aggiornamento nelle raccolte siti. Al termine del
processo di aggiornamento, è possibile esaminare il file del registro di aggiornamento per controllare se
35
durante il processo si siano verificati problemi. Esaminare inoltre tutti i siti aggiornati allo scopo di
individuare e risolvere gli eventuali problemi di visualizzazione del contenuto. Per visualizzare la pagina
Stato aggiornamento in Amministrazione centrale fare clic su Aggiornamento e migrazione e quindi su
Controlla stato aggiornamento.
4.4 Conversione di Web User Control in Visual Web Part
L’applicativo sviluppato precedentemente era stato progetto per SharePoint 2007. Chiunque abbia
creato una web part per SharePoint 2007 sa che l’esperienza di sviluppo non è così valida come uno
potrebbe aspettarsi. Bisogna infatti creare una web part in Visual Studio 2008, sulla base del template
“Webpart”, ma non è possibile progettare l’interfaccia grafica trascinando i controlli necessari all’interno
della webpart. Bisogna sviluppare il tutto senza cioè avere una minima anteprima grafica. Per venire
incontro a questo problema è stata sviluppata una speciale webpart denominata SmartPart.
4.4.1 Smart Part
La SmartPart è una webpart generica che può contenere user controls di ASP.NET. Il primo grande
beneficio che questo comporta è la possibilità di sviluppare WebUserControls sfruttando l’interfaccia
grafica offerta dal tool di sviluppo di Visual Studio 2008. In questo modo si può subito avere
un’anteprima veritiera di quanto si sta andando a creare. Inoltre dà la possibilità agli user control di
avere accesso all’object model di SharePoint, in modo tale che dal codice dello user control sia possibile
interrogare oggetti di Sharepoint. Un’altra caratteristica è che lo user control può esporre alcune
proprietà di cui si fa carico la SmartPart , in modo tale che l’utente abbia la possibilità di specificare dei
valori per tali proprietà all’interno del sito di SharePoint.
Durante la migrazione è però emerso un problema: la SmartPart non è compatibile con SharePoint 2010.
Questa speciale webpart, infatti, è stata sviluppata da un team non ufficiale di Microsoft appositamente
per la versione 2007 del portale e, ad oggi, non è stata ancora convertita nel formato compatibile con
SharePoint 2010. Ne esiste una versione compatibile, ma è ancora in versione beta e purtroppo, dopo
averla testata, non si è dimostrata sufficientemente stabile, vista anche la natura alquanto critica delle
funzioni che deve gestire l’applicativo. Per questo è stato necessario convertire gli user controls in visual
web part.
4.4.2 Visual Web Part
Con la versione 2010 di SharePoint è stato fatto un grosso passo in avanti soprattutto per quanto
riguarda la piattaforma di sviluppo, non solo perché è stato incrementato notevolmente l’insieme di
caratteristiche che la piattaforma può supportare, ma anche perché sono stati fatti significativi
investimenti nella creazione di un insieme di tool progettati per rendere il processo di sviluppo più
36
produttivo e più accessibile agli sviluppatori di tutti i livelli. Tutto questo si traduce in SharePoint Tools
per Visual Studio 2010.
Una delle strutture più utilizzate dagli sviluppatori all’interno di SharePoint è senza ombra di dubbio la
Web Part. Per questo uno dei nuovi template per Visual Studio 2010 è il template per progettare le
Visual Web Part, che fornisce la possibilità agli sviluppatori di progettare graficamente una web part di
cui può essere fatto il deploy direttamente in SharePoint. Questa nuova caratteristica viene
notevolmente incontro alle esigenze degli sviluppatori, offrendo un tool dal facile utilizzo e
dall’immediata integrazione. Per questo motivo si è deciso di convertire gli user controls del vecchio
progetto in Visual Web Part.
4.4.3 Conversione
Il primo passo per iniziare la fase di conversione è stato quello di creare un nuovo progetto all’interno
della solution scegliendo come template “Visual Web Part” sotto la voce SharePoint 2010. Il passo
successivo è stato quello di copiare il codice dello user control all’interno della visual web part.
Ovviamente il codice è stato epurato da tutte quelle righe iniziali dichiarative, al posto delle quali sono
stati inseriti tutti i riferimenti utili al corretto funzionamento della pagina all’interno di SharePoint.
L’ultimo passo, forse quello più importante, è stato il trasferimento del codice C#. Gli user controls di
partenza infatti non avevano specificato al loro interno un file contente il Code Behind. La situazione
pregressa era la seguente: erano presenti due progetti distinti, uno contente tutti gli user controls e uno
contenente tutto il codice associato a ciascun controllo. Non essendo le due parti esplicitamente
collegate fra loro era stato necessario creare due classi per ciascun user control, una precompilata
contenente la dichiarazione di tutti i controlli utilizzati nella pagina e una con i metodi veri e propri.
Nella nuova Visual Web Part, invece, è stato possibile dichiarare esplicitamente all’interno del controllo
a quale file dovesse fare riferimento per i metodi, semplificando così anche la procedura di dichiarazione
dei metodi. Nella nuova configurazione non è stato necessario creare una classe precompilata in quanto
i controlli presenti sulla pagina erano già disponibili e accessibili nel code behind. Quindi è stato
sufficiente copiare solamente il codice della classe che dichiarava esplicitamente i metodi utilizzati nella
pagina all’interno del file .cs associato alla Visual Web Part. Naturalmente questo procedimento è stato
iterato per tutti gli user control presenti all’interno del vecchio progetto, aggiungendo per ciascuno di
essi una nuova Visual Web Part dentro il nuovo workspace. Alla fine della fase di migrazione sono
risultate esserci una decina di nuove Visual Web Part.
4.5 Osservazioni
L’applicativo sviluppato non sfrutta ancora tutte le potenzialità che l’ambiente di SharePoint mette a
disposizione. Al momento la struttura è utilizzata principalmente per due motivi:
37
Autenticare gli utenti
Ospitare l’applicativo
4.5.1 Autenticare gli utenti
SharePoint mette a disposizione degli sviluppatori un valido meccanismo di autenticazione degli utenti,
con la possibilità di creare gruppi con privilegi diversi. Tramite questa funzionalità si riesce a specificare
con un livello di dettaglio molto alto quali pagine possono essere visitate da ciascun gruppo. Più
precisamente si può specificare per ciascuna pagina quali sono le azioni che alcuni utenti possono fare a
differenza di altri. Questo meccanismo inoltre si basa sul servizio di gestione degli utenti di Active
Directory: tramite questo servizio è stato possibile utilizzare le stesse utenze che i dipendenti
dell’azienda utilizzano per accedere alla rete aziendale anche per accedere al nuovo applicativo. In
questo modo non si introduce la complessità di ricordarsi un ulteriore nome utente e soprattutto una
password. L’autenticazione inoltre è stata usata per personalizzare la top link bar di Sharepoint, cioè
quella barra che contiene i link alle pagine a cui gli utenti hanno diritto di accedere.
4.5.2 Ospitare l’applicativo
SharePoint offre la possibilità di creare web applications, site collections, web sites e web pages. Le web
applications sono il contenitore più grande, all’interno del quale si possono creare le site collections, che
come dice la parola stessa sono delle collezioni di siti web. All’interno della site collection a sua volta è
possibile creare più web sites e ancora in cascata creare delle web page. Per l’applicativo è stato quindi
necessario creare una web application, indispensabile perché il programma sviluppato ha bisogno di
modificare il file di configurazione web.config e quindi non può essere condiviso da altri applicativi. Poi è
stata creata una site collection, un web site ed infine una decina di web page.
38
5 Confronto fra il documento dei requisiti e il progetto
esistente
Giunto a questo punto ci sono tutti gli elementi necessari per fare un punto sulla situazione e capire
quali sono le parti che sono già state sviluppate, quali quelle che sarà necessario modificare e quali
quelle da sviluppare completamente da zero. Questo discorso vale naturalmente solo per la parte
concernente la gestione delle note spese, in quanto la parte delle prenotazioni sarà da implementare
completamente ex novo.
5.1 Confronto con l’applicativo esistente
L’applicativo esistente presenta tre pagine principali: la prima relativa alla compilazione della nota spese
mentre le altre due riguardano l’approvazione delle note spese, in particolare una per la lista e l’altra
per il dettaglio. Quindi già a una prima analisi si può affermare che mancano completamente le parti
relative alla selezione delle spese da fatturare ai clienti e la parte della reportistica.
Si analizzano ora nel dettaglio le due parti presenti.
5.1.1 Compilazione della nota spese
La pagina si presenta in questo modo: nell’intestazione sono specificati il mese e l’anno per i quali si sta
compilando la nota spese. Sono due combo box dalle quali si può scegliere anche un mese e un anno
diversi dall’attuale, in modo tale che la risorsa abbia la possibilità di rivedere anche le note spese
passate. Subito sotto l’intestazione c’è un riquadro in cui sono specificati il mese, l’anno, il beneficiario e
lo status della nota spese. Sotto si trova una tabella con l’elenco delle spese sostenute per quel mese e
anno specificati, con la possibilità di inserire nuove spese e modificare o cancellare quelle già presenti.
Il primo dettaglio che balza subito all’attenzione è la mancata separazione fra le due tipologie di
spese, quelle chilometriche e quelle documentate. Vi è presente un unico totale assieme al totale
anticipato. Sarà quindi da implementare questa suddivisione fra le categorie. Altro aspetto che si nota è
la mancanza della colonna relativa alla città di destinazione, casella che è da valorizzare solo nel caso in
cui la tipologia di spesa sia chilometrica. Inoltre mancano anche le colonne relative alla fattura e alla
spesa di rappresentanza. Un altro particolare che non viene riscontrato rispetto al documento dei
requisiti è il coefficiente di rimborso chilometrico, non presente nella pagina sviluppata. Infine fra i
pulsanti presenti in fondo alla pagina non ve n’è uno per la stampa della nota spese.
39
5.1.2 Approvazione della nota spese
La pagina si presenta in questo modo: nell’intestazione sono presenti tre criteri di ricerca in cui possono
essere specificati il mese e l’anno, la risorsa e lo stato della nota spese. Al di sotto si presenta una tabella
in cui c’è l’elenco di tutte le note spese che corrispondono ai criteri di ricerca selezionati. Alla fine di ogni
riga della tabella vi è un pulsante per andare al dettaglio della nota spese. Alla sua pressione si va alla
pagina del dettaglio in cui viene sfruttata la stessa visual web part sviluppata per la parte di
compilazione della nota spese. In questo caso però non sono abilitati né la modifica, né la cancellazione
né soprattutto l’inserimento di nuove spese. I pulsanti presenti a fondo pagina permettono di salvare la
nota spese, di approvarla o di rifiutarla. Anche in questo caso, come nel caso precedente è assente un
pulsante per la stampa. Una cosa fondamentale che manca è inoltre l’invio delle mail in automatico alla
risorsa, una volta che è stata approvata la nota spese. Le modifiche da apportare a queste pagine sono
le stesse del caso precedente, in quanto, soprattutto per la pagina dei dettagli, si usa la stessa visual
web part utilizzata per la pagina di compilazione della nota spese.
40
6 L’applicativo
6.1 Introduzione
Ora che è stata definita la base di dati, si può passare al fulcro dell’intero progetto. In questo capitolo
viene, infatti, descritto lo sviluppo dell’applicativo, in particolare vengono analizzati gli obiettivi del
programma e le specifiche tecniche per la sua progettazione.
6.2 Obiettivi dell’applicativo
L’obiettivo dell’applicativo consiste nel gestire le note spese e le prenotazioni dei dipendenti
dell’azienda Teorema. In pratica si vuole costruire all’interno dell’intranet aziendale un’infrastruttura in
grado di permettere l’inserimento delle note spese da parte di tutti i dipendenti e delle prenotazioni
solo da parte dell’amministrazione. Le note spese dovranno subire un processo di approvazione prima
che le spese possano essere disponibili al settore dell’amministrazione per essere poi fatturate ai clienti.
Le prenotazioni invece non necessitano del processo di approvazione, quindi alla loro chiusura saranno
subito disponibili per la fatturazione.
6.3 Progettazione
Tra i momenti di analisi e di sviluppo si è approfondita la fase di progettazione. Proprio in questo
periodo è stata definita la struttura del sistema cercando di rispettare i parametri di qualità esterna e
interna del prodotto dettati dalle regole della Software Engineering.
6.3.1 Qualità del software
Rispettare tutte le qualità non risulta essere un facile compito. Di seguito vengono riportati i parametri a
cui si è dato maggior rilievo.
- Correttezza: capacità del software di eseguire correttamente i suoi compiti. Rispondenza,
quindi, alle relative specifiche.
- Efficienza: capacità del software di utilizzare in modo economico e razionale le risorse di calcolo
in termini di spazio e tempo.
- Usabilità: il software presenta facilità di apprendimento e di utilizzo per l’utente.
- Estendibilità: il software presenta facilità ad essere adattato a possibili cambiamenti nelle
specifiche.
- Riusabilità: possibilità di utilizzare il software (in tutto o in parte) per diverse applicazioni.
41
- Strutturazione: grado di organizzazione interna in parti con funzioni specifiche ed interagenti.
- Leggibilità: capacità del programma di presentare esplicitamente le scelte fatte dal progettista. I
commenti lungo il codice risultano di estrema importanza.
- Robustezza: capacità del software di funzionare anche in condizioni anomale. In tal senso
vengono gestite le eccezioni.
- Manutenibilità: il software presenta facilità di gestione dei problemi durante la fase di utilizzo.
- Modificabilità: il software presenta facilità di modifica a seguito della scoperta di un errore o a
causa di una variazione delle necessità applicative.
- Sicurezza: capacità del software di non consentire utilizzi non autorizzati.
6.3.2 Strategie di sviluppo
La fase di progettazione richiede la suddivisione del sistema da realizzare in una gerarchia di moduli, che
assume la forma di un albero o di un grafo. La definizione dei moduli può avvenire secondo le direzioni
di sviluppo top-down o bottom-up.
- Sviluppo top-down: Attraverso questa strategia viene formulata una visione generale del
sistema senza scendere nel dettaglio di alcuna delle sue parti. Successivamente vengono inseriti
i vari moduli. Essi vengono rifiniti, inserendo ulteriori dettagli finché la specifica completa è
sufficientemente dettagliata da validare il modello.
- Sviluppo bottom-up: Attraverso questa strategia le parti individuali del sistema sono
direttamente specificate in dettaglio. Questi segmenti vengono poi connessi tra loro in modo da
formare componenti più grandi, fino a realizzare un sistema completo.
La strategia di sviluppo adottata è stata la prima descritta. La garanzia di una modularità efficiente è
stata decisiva alla propensione verso lo sviluppo top-down. Sicuramente non minor rilievo ha avuto il
fatto che per questo progetto non dovessero essere utilizzati moduli preesistenti.
6.3.3 Strategie di progetto
Ortogonalmente alla direzione di sviluppo è stato necessario decidere come strutturare i moduli. A
questo proposito si sono esaminate diverse strategie di progetto.
- strategia orientata alle funzioni: Questo metodo prevede che un modulo racchiuda una
funzionalità. Il progetto viene scomposto in insieme di unità interagenti, ognuna corrispondente
ad una funzione chiaramente definita.
42
- information hiding: Questo metodo prevede di “nascondere” il funzionamento interno di una
parte di un programma, in modo da proteggere il resto dai cambiamenti che si produrrebbero
nel caso di funzionamento difettoso, oppure da implementazioni diverse del programma.
Questa strategia risolve il problema dell’accoppiamento, infatti, i moduli comunicano solo
tramite funzioni di interfaccia e per mezzo dei loro parametri.
- strategia orientata agli oggetti: Questo metodo prevede che il sistema sia progettato come un
insieme di oggetti interagenti. Un oggetto è noto all’esterno come un insieme di funzionalità. Le
funzioni di interfaccia costituiscono il protocollo dell’oggetto.
Nell’ottica di razionalizzare la progettazione si è ritenuto necessario seguire il metodo orientato alle
funzioni. Questo approccio ha garantito una coesione di tipo funzionale determinando anche un basso
accoppiamento.
6.3.4 I moduli
Arrivati a questo livello di progettazione, l’analisi si è spostata sui moduli, le componenti elementari del
sistema completo. Un modulo è stato pensato come un’unità con un compito ben preciso, in grado di
offrire servizi agli altri moduli e di questi utilizzarne le funzionalità. Si è cercato di garantire la bontà dei
moduli osservando i criteri che caratterizzano la qualità dei componenti software.
- Dimensione dei moduli: Tale parametro richiede che il sistema sia costituito da moduli piccoli e
facilmente comprensibili.
- Coesione interna: Tale parametro tratta il grado di intercorrelazione dei componenti di un
modulo. Un modulo si può definire buono quando ha la massima coesione interna, cioè non
contiene nessuna componente esterna.
- Accoppiamento: Tale parametro tratta il grado di interrelazione di un modulo con gli altri
moduli del sistema. Essi devono presentare il minimo accoppiamento: se l’accoppiamento è alto
modificare un modulo implica la modifica anche dei moduli che sono in relazione con questo.
L’applicativo è stato sviluppato con la volontà di assicurare la massima coesione ed il minimo
accoppiamento.
6.3.5 Strumenti utilizzati per lo sviluppo dell’applicativo
Per sviluppare l’applicativo si è utilizzato Visual Studio 2010, l'ultimo IDE creato da Microsoft, per
programmatori che sviluppano per piattaforme Windows e .NET Framework 4.0. Esso permette di usare
svariati linguaggi di programmazione, tra cui VB.NET, C++, C# e altri ancora. Inoltre offre la possibilità di
creare applicazioni e servizi Web ASP.NET, in C# o in VB.NET. In particolare sono stati utilizzati gli
43
SharePoint Development Tools che integrano all’interno dell’IDE tutte le funzionalità per sviluppare
oggetti correlati a SharePoint. Di questi strumenti si è sfruttata a fondo la possibilità di creare Visual
Web Part da caricare poi direttamente all’interno del portale di SharePoint.
Come Database Management System si è utilizzato SQL Server 2008, un DBMS relazionale
prodotto da Microsoft. SQL Server 2008 offre una piattaforma dati affidabile, produttiva ed efficiente
per eseguire le più esigenti applicazioni mission-critical, abbattere tempi e costi di sviluppo e gestione
delle applicazioni e fornire informazioni traducibili in azione a tutti i livelli dell'organizzazione.
Per la gestione dei profili degli utenti si è ricorsi ad Active Directory, un insieme di servizi di rete
meglio noti come directory service adottati dai sistemi operativi Microsoft a partire da Windows 2000
Server. Active Directory si fonda sui concetti di dominio e di directory. Si può vedere Active Directory e
quindi il Dominio come un mondo in cui vengono concentrate tutte le risorse della rete a partire da:
account utente, account computer, cartelle condivise, stampanti ecc. ecc.
Infine, come contenitore per tutto, si è utilizzato SharePoint 2010, un programma lato server
che permette la creazione di particolari siti web principalmente ad uso aziendale (Intranet) ma che
possono anche essere messi in rete e quindi essere disponibili e utilizzati come normali siti web.
L'autenticazione viene fatta inserendo un nome utente e password al momento del login. Questa
procedura viene agevolata dal single sign on che nell'ambito delle tecnologie Microsoft viene spesso
inserito al momento dell'accensione del proprio pc. Il sistema si preoccuperà pertanto di autenticarvi
automaticamente nei siti in cui si dispone delle credenziali di accesso. L'importante valore aggiunto sta
nel condividere informazioni e/o documenti in diversi modi. È possibile creare liste, repository
documentali, calendari sincronizzati con outlook e molto altro ancora. SharePoint è completamente
integrato con il pacchetto Office e offre molte soluzioni come il "versionamento" dei documenti che
essendo salvati su server godono del vantaggio della collaborazione. Due utenti, infatti, possono
collegarsi da due posti differenti e visionare o lavorare sullo stesso documento. Va fatta una
precisazione: un solo utente può modificare un certo documento mentre più persone possono visionarlo
in contemporanea. Questa operazione viene definita check-out (in italiano "estrai") e check-in (in
italiano "archivia") e serve ad impedire che si crei confusione su chi modifica cosa. Uno dei punti di forza
di SharePoint sono proprio i permessi. Essi infatti sono alla base di ogni elemento (Site Collection, Site,
Lista/Repository, Pagina o Folder/Item). È possibile infatti associare un permesso praticamente a tutto
andando a discriminare qualsiasi degli oggetti citati in precedenza. Questo consente di creare dei
particolari siti web in cui a seconda del livello autorizzativo del quale un utente è dotato, è concesso
vedere o non vedere certi elementi e con quale tipologia (se in sola lettura o in contribuzione).
44
Componenti aggiuntivi
Per rendere esteticamente più accattivante l’interfaccia grafica dell’applicativo, si è deciso di utilizzare i
componenti di Telerik, che includono più di 70 controlli di assoluta affidabilità che aiutano a costruire
web application di alta qualità. Questi componenti sono stati sviluppati sulla base di Microsoft ASP.NET
AJAX e non introducono un’implementazione proprietaria di Ajax. In questo modo le applicazioni
risultano più veloci, più sicure e ricche di funzionalità.
Un altro componente aggiuntivo utilizzato è la Microsoft Enterprise Library, cioè una collezione
di componenti software riutilizzabili (blocchi di applicazione) progettati per assistere gli sviluppatori
software in alcuni compiti della programmazione, quali ad esempio il logging, la validazione, l’accesso ai
dati, la gestione delle eccezioni e molti altri. Vengono forniti come codice sorgente, casi di test e
documentazione che possono essere utilizzati così come sono , estesi o modificati dagli sviluppatori per
essere utilizzati in progetti più complessi. In questo caso questa libreria è stata sfruttata principalmente
per due problemi: l’accesso ai dati e la validazione dei dati inseriti dall’utente.
Per costruire i report, infine, si è utilizzato lo strumento ReportViewer 2010 messo a
disposizione da Microsoft. Questo controllo permette agli sviluppatori di web application di creare
report molto dettagliati e di presentarli agli utenti tramite un’interfaccia semplice e intuitiva. Il
ReportViewer è in grado di analizzare due tipologie di report:
Report locali: questi sono report che vengono eseguiti direttamente dall’applicazione client,
attraverso il controllo ReportViewer. All’interno di Visual Studio vi è un apposito template per la
costruzione di report di questo genere.
Report remoti: questi report sono ospitati nel server di Sql Server Reporting Services. Il controllo
è utilizzato come un meccanismo di visualizzazione di un report che è già stato definito e
pubblicato all’interno del Report Server.
Una delle caratteristiche più utili di ReportViewer è la sua capacità di sfruttare come data source del
report un LINQDataSource. Attraverso Visual Studio è possibile aggiungere automaticamente un
ObjectDataSource all’inserimento del viewer e creare quindi una facile connessione ai dati.
6.3.6 Processo Unificato di sviluppo del software
La seguente sezione si propone di descrivere l’applicativo in maniera convenzionale utilizzando il
linguaggio di modellizzazione visuale UML. Secondo la definizione formale il Processo Unificato coinvolge
persone, progetti, strumenti, processi, prodotti: i partecipanti e gli sviluppatori coinvolti nel progetto di
sviluppo di un sistema, seguono un determinato processo, utilizzando strumenti di ausilio nello sviluppo,
generando prodotti software.
45
Il processo parte dai requisiti dell’utente, che sono stati raccolti nei casi d’uso, delle sequenze di
esecuzione del sistema in grado di fornire un valore all’utente. Dai casi d’uso sono stati prodotti i
modelli del sistema e le implementazioni che li realizzano.
6.3.7 I diagrammi di attività
I diagrammi di attività rappresentano il sistema di Workflow, in altri termini la logica interna di un
processo. Rappresentano l’evoluzione dei flow chart, e, come tali, si occupano di evidenziare il flusso di
attività. Permettono la rappresentazione di processi paralleli e della relativa sincronizzazione. Di seguito
viene riportato un diagramma di attività che rappresenta tutte le fasi che vengono percorse per ogni
singola nota spese e prenotazione.
Gestione Nota Spese
Ap
pro
vato
riD
ipen
den
tiV
isu
aliz
zato
ri
Creare/Modificare Nota Spese
Richiedere approvazione?
Salvare nota spese
Salvare?
NO
SI
Eliminare modifiche
NO
Erogato anticipo di cassa?
Inserire anticipo di cassa
SI
Approva?
Selezionare spese da fatturare
Creare report SI
Aggiungere/Modificare/Eliminare spesa?
Chiusura Nota Spese
Inserire/Modificare/ Eliminare spesa
Effettuate spese?
NO
SI
SI
NO
Inserire Nota?
NOInserire nota SI
NO
INIZIO
Mail automaticaMail automatica
NO
Figura 6-1: Diagramma di attività per la gestione note spese
46
Gestione PrenotazioniA
mm
inis
traz
ion
eD
ipe
nd
en
ti
Creare/Modificare documento prenotazione
Salvare documento prenotazioni
Salvare?SI
Eliminare modifiche
NO
Aggiungere/Modificare/Eliminare prenotazione?
Chiusura prenotazione
Inserire/Modificare/ Eliminare prenotazione
Effettuate prenotazioni?
NO
SI
SI
INIZIOInvio mail/Telefonata
per prenotare
Chiudere prenotazione?
NO
NO
Visualizzare prenotazione
SI
Mail automaticaMail automatica
Figura 6-2: Diagramma di attività per la gestione prenotazioni
6.4 I ruoli Analizzando i requisiti dell’applicativo sono emersi cinque ruoli principali:
Operators: vengono definiti così tutti coloro che hanno la possibilità di inserire le note spese
all’interno dell’applicativo.
AccountManagers: a questo gruppo appartengono gli utenti che possono creare le note spese,
ma che a differenza degli altri non hanno bisogno di richiedere l’approvazione.
SuperUsers: qui sono presenti tutti coloro che possono editare le note spese di tutti e che
possono crearle per conto terzi. Hanno quindi la possibilità di scegliere da un menu a tendina
quale risorsa impersonare.
Approvers: all’interno di questo gruppo si trovano gli utenti che hanno il compito di approvare o
respingere le note spese.
BillingReaders: in questo gruppo ci sono gli utenti che si occupano di produrre le fatture da
inviare ai clienti.
BookingCreators: vengono definiti in questo modo coloro che hanno la possibilità di inserire
prenotazioni all’interno del sistema.
BookingReaders: a questo gruppo appartengono coloro che possono richiedere una
prenotazione e che di conseguenza hanno i diritti a visualizzarla in sola lettura
47
6.5 La codifica La fase di codifica del sistema ha lo scopo di implementare i moduli del progetto così come sono stati
descritti nella fase precedente, quella della progettazione, e in particolare nel documento delle
specifiche. Durante questa fase viene realizzato concretamente il progetto, cioè avviene la scrittura del
codice, il test di ciascun modulo ed infine l’integrazione di tutti i moduli sviluppati.
6.5.1 Descrizione della solution
La solution presenta al suo interno sette diversi progetti:
Teorema.NotaSpese.Authentication: questo progetto ha lo scopo di gestire l’autenticazione
degli utenti, soprattutto per quanto riguarda i gruppi a cui appartengono. Ogni utente, infatti, a
seconda dei gruppi a cui appartiene, ha la possibilità di visualizzare o meno alcune parti delle
visual web part sviluppate. Per esempio gli utenti approvatori non hanno la possibilità di editare
la tabella delle note spese, a differenza di tutte le altre risorse che hanno anche i diritti di
aggiungere, modificare o cancellare le spese.
Teorema.NotaSpese.Configuration: questo progetto è stato utilizzato per impostare e per
leggere i parametri di configurazione dell’applicativo, che sono specificati in un’apposita tabella
del database. In questo modo si ha accesso diretto a quei valori che altrimenti sarebbero difficili
da raggiungere.
Teorema.NotaSpese.Data: all’interno di questo progetto si trovano tutte le classi che vengono
utilizzate per l’accesso ai dati del database. In questo modo si demanda a queste classi tutte le
problematiche relative all’interrogazione del database, lasciando maggiormente pulito il codice
delle pagine web.
Teorema.NotaSpese.Data.Validation: in questo progetto si trovano le classi che hanno il compito
di validare i dati inseriti dagli utenti prima che vengano salvati all’interno del database. In questo
modo si evita che l’utente inserisca valori non validi all’interno delle form.
Teorema.NotaSpese.Entities: in questo progetto si è creata una classe per ogni entità del
database, in modo da venire incontro alle esigenze della programmazione. Le classi di questo
progetto vengono utilizzate soprattutto dal progetto Teorema.NotaSpese.Data, per inserire i
dati recuperati dal database in oggetti ben formati.
Teorema.NotaSpese.Helpers: in questo progetto si trovano tutte le classi adibite a funzionalità
quali la conversione in diversi formati, l’invio delle mail, la creazione di template.
Teorema.NotaSpese.VisualWebPart: questo è il progetto più importante, all’interno del quale si
trovano tutte le visual web part sviluppate per l’applicativo. Non necessariamente ciascuna web
part corrisponde a una pagina web, in quanto si è cercato di riutilizzare il codice e quindi più
pagine web condividono le stesse visual web part.
48
6.5.2 Accesso ai dati
Per l’accesso ai dati è stato utilizzato il provider SqlClient, che è altamente ottimizzato per la
combinazione .net/sql server e permette di raggiungere risultati ottimali. Questo provider è molto
veloce, molto più veloce rispetto all’accesso al database attraverso il layer OLEDB, in quanto vi accede
sfruttando le librerie native. Oltre a sfruttare questo provider, per una più facile scrittura del codice per
l’accesso al database si è utilizzato la Microsoft Enterprise Library, che mette a disposizione degli
strumenti molto validi per gestire in modo facile e quasi automatizzato l’accesso ai dati. Si riporta di
seguito uno stralcio di codice:
public static DataTable GetByIdUser(Guid idUser) { Database db = DatabaseFactory.CreateDatabase(); DbCommand dbCommand = db.GetStoredProcCommand("Costsheet_GetByIdUser"); db.AddInParameter(dbCommand, "IdUser", DbType.Guid, idUser); DataSet ds = db.ExecuteDataSet(dbCommand); if ((ds != null) && (ds.Tables.Count > 0)) { return ds.Tables[0]; } return null; }
Per poter utilizzare questa procedura è però necessario specificare all’interno del file web.config quale
sia il database di default, oltre ad aver specificato nella connection string il nome del database e del suo
provider. Per la precisione è necessario aggiungere le seguenti righe al web.config:
<dataConfiguration defaultDatabase="Teorema_NotaSpese" />
<connectionStrings>
<add name="Teorema_NotaSpese" connectionString="Data Source=sp2010;Initial
Catalog=T_Teorema_NotaSpese;User Id=enrico.natella; Password=Password123"
providerName="System.Data.SqlClient" />
<add name="Teorema_Tracking" connectionString="Data Source=sp2010;Initial
Catalog=TrackingWeb;User Id=enrico.natella; Password=Password123"
providerName="System.Data.SqlClient" />
</connectionStrings>
6.5.3 Visual Web Part
In questo paragrafo si analizzano approfonditamente tutte le visual web part utilizzate all’interno
dell’applicativo.
CostsheetCompilation
Questa visual web part viene utilizzata per la compilazione della nota spese. Essa al suo interno richiama
due user controls, che sono quelli della ricerca e quella della compilazione vera e propria della nota
spese. Oltre a questi due controlli, nella pagina è presente un meccanismo molto importante per la
gestione della nota spese. Infatti, in alto si trovano due combobox per la selezione dell’anno e del mese:
49
questi due controlli possono essere utilizzati per la visualizzazione delle note spese precedentemente
approvate, o comunque note spese dei mesi precedenti. La procedura funziona in questo modo: al
caricamento della pagina viene controllato il valore di una query string relativa all’id della nota spese. Se
questo valore è presente, allora vengono caricate tutte le spese relative a quello specifico id. Altrimenti,
risalendo all’utente che è correntemente loggato, si fa una query per capire se la risorsa ha già iniziato a
compilare una nota spese per il mese e anno corrente. In caso positivo si risale all’id della nota spese in
questione e si fa una redirect della pagina a se stessa aggiungendo come query string l’id della nota
spese. Se invece la risorsa non ha ancora inserito alcuna spesa per il mese e anno corrente, si procede
alla creazione di una nuova nota spese all’interno del database, tramite chiamata ad apposita stored
procedure, e si fa, come nei casi precedenti, una redirect della pagina a se stessa impostando come
query string l’id della nota spese appena creata. Una cosa da sottolineare è che i due controlli anno e
mese sono associati a due data source che sono modificati in base alle note spese inserite dalla risorsa:
al loro interno compaiono solo gli anni e i mesi per i quali è stata compilata una nota spese dalla risorsa
correntemente loggata nel sistema. In questo modo si è provveduto anche a non dare la possibilità
all’utente di inserire note spese per i mesi successivi a quello corrente, come da specifiche. Andando più
a fondo all’interno di questo meccanismo, alla selezione dell’anno d’interesse, viene eseguita una query
per riempire il datasource contenente i mesi per i quali sono state compilate le note spese. Una volta
selezionato anche il mese viene eseguita in automatico una query per risalire alla nota spesa di interesse
e la pagina è aggiornata con tutte le spese sostenute in quello specifico mese. Ecco uno stralcio di codice
di questa procedura:
protected override void OnLoad(EventArgs e) { base.OnLoad(e); GridTotal = 0; GridTotalDoc = 0; GridTotalKm = 0; string idCostsheetString = Request.QueryString["IdCostsheet"]; if (string.IsNullOrEmpty(idCostsheetString)) { this.Visible = false; return; } Guid idCostsheet; try { idCostsheet = new Guid(idCostsheetString); } catch { Response.Write("Errore! IdCostsheet non valido nella query string"); this.Visible = false; return;
50
} if (!IsPostBack || this.CurrentCostsheet == null || this.CurrentCostsheet.ID != idCostsheet) { this.CurrentCostsheet = CostsheetProvider.GetByIDCostsheet(idCostsheet); if (this.CurrentCostsheet.User.UserName.ToLower() != ASPNETCurrentUser.GetCurrentUser().ToLower()) { if (CurrentUser == null) { Response.Redirect(ConfigProvider.PageUserNotExistent, true); } else if (! (CurrentUser.UserRoles.Contains(UserRole.SuperUser) || CurrentUser.UserRoles.Contains(UserRole.Approver)) ) { Response.Redirect(ConfigProvider.PageUnauthorized, true); return; } } LoadControlsByCostsheet(this.CurrentCostsheet); } }
Il controllo ascx dedicato alla ricerca compare solamente se l’utente loggato appartiene al
gruppo dei superusers. Questa categoria di utenti ha la possibilità di inserire note spese per conto di
altri, per questo il controllo propone un campo di ricerca in cui specificare il nome (o parte di esso) della
persona che si vuole impersonare e una combobox contenente tutte le risorse corrispondenti al criterio
di ricerca inserito. Una volta selezionato un utente dalla combobox la pagina si aggiornerà
automaticamente proponendo l’ultima nota spese della risorsa selezionata, fornendo comunque la
possibilità di cambiare sia il mese sia l’anno. Una volta selezionata una risorsa compare un ulteriore
pulsante che può essere utilizzato per cambiare la risorsa da impersonare.
Il controllo dedicato all’inserimento vero e proprio delle spese merita particolare attenzione,
essendo il modulo centrale attorno al quale ruota l’intero applicativo. Questo controllo presenta una
caratteristica alquanto particolare: a seconda dell’utente che è loggato all’interno del sistema, esso
espone dei controlli piuttosto che altri. Per questo motivo è stata creata una procedura che personalizza
la configurazione del controllo a seconda dell’utente loggato. Ecco uno stralcio di codice che si occupa di
questo:
private void ConfigureVisualization() { //Buttons configuration switch (CurrentCostsheet.Status.Code)
51
{ case "TOCOMPILE": if (CurrentUser.ID != CurrentCostsheet.User.ID && !CurrentUser.UserRoles.Contains(UserRole.SuperUser)) { this.DisableAll(); } else { this.btnAccept.Visible = false; this.btnReject.Visible = false; this.btnSubmit.Visible = true; this.btnOk.Visible = true; this.btnPrint.Visible = true; if (RadGrid1.Items.Count == 0) { btnClose.Visible = true; } else { btnClose.Visible = false; } } break; case "COMPILED": if (!CurrentUser.UserRoles.Contains(UserRole.Approver)) { this.DisableAll(); this.btnPrint.Visible = true; } else { this.DisableInsertDelete(this.RadGrid1); this.btnAccept.Visible = true; this.btnReject.Visible = true; this.btnSubmit.Visible = false; this.btnOk.Visible = true; this.btnClose.Visible = false; this.btnPrint.Visible = true; } break; case "ACCEPTED": this.DisableAll(); this.btnPrint.Visible = true; break; case "REJECTED": if (CurrentUser.ID != CurrentCostsheet.User.ID && !CurrentUser.UserRoles.Contains(UserRole.SuperUser)) { this.DisableAll(); this.btnPrint.Visible = true; } else { this.btnAccept.Visible = false; this.btnReject.Visible = false; this.btnSubmit.Visible = true; this.btnOk.Visible = true; this.btnClose.Visible = false; this.btnPrint.Visible = true; } break; default: throw new Exception("Stato del costsheet non contemplato!");
52
} ////If the logged in user is an Approver... if (UserProvider.GetRoles(ASPNETCurrentUser.GetCurrentUser()).Contains(UserRole.Approver)) { this.DisableInsertDelete(this.RadGrid1); //enables the TotalAdvance if the user is an Approver foreach (var footer in RadGrid1.MasterTableView.GetItems(GridItemType.Footer)) { if (CurrentCostsheet.Status.Code == "COMPILED") { RadNumericTextBox rnt = footer.FindControl("rntTotalAdvance") as RadNumericTextBox; if (rnt != null) { rnt.Enabled = true; rnt.ShowButton = true; } } } } }
Una delle parti configurabili sono i pulsanti in fondo alla pagina: a seconda dell’utente loggato e dello
stato della nota spese i pulsanti vengono visualizzati o meno. Per esempio se l’utente è un approvatore
verranno visualizzati i pulsanti che permettono di accettare o di rifiutare di una nota spese. Un'altra
parte configurabile è il campo relativo al totale anticipato: questo valore è modificabile solamente da un
approvatore, quindi nel caso in cui ci sia loggato un operatore il campo viene disabilitato.
Il componente principale di questo controllo è costituito da un RadGrid, l’equivalente di Telerik
per un gridview. Esso si presenta come una tabella all’interno della quale è possibile inserire nuove
spese, modificare o cancellare quelle presenti. L’inserimento e la modifica sono stati modificati rispetto
al software precedente: prima infatti per inserire o modificare una spesa compariva un form all’interno
della tabella, mentre si è preferito editare i campi InLine, direttamente quindi su ciascuna linea della
tabella. Queste permette un inserimento molto più rapido dei dati.
Un miglioramento rispetto al software precedente è stato nella query che recupera i clienti a
partire da una risorsa. In precedenza nella combobox apparivano tutti i clienti ai quali è associata una
risorsa, ora invece appaiono solo i clienti presso i quali è stata tracciata un’attività all’interno del
tracking nel mese per il quale si sta compilando la nota spese. In questo modo le risorse vengono aiutate
nella compilazione, suggerendo solo i clienti presso i quali hanno effettivamente fornito servizio.
CostsheetApprovement
Questa visual web part si trova nella pagina che viene utilizzata dal gruppo NS_Approvers per approvare
o respingere le note spese. La pagina si presenta con in alto dei criteri di ricerca per filtrare le note
spese, mentre la maggior parte della pagina è occupata da un RadGrid in cui sono elencate le note spese
53
di tutti i dipendenti. Affianco a ogni riga è presente un pulsante che permette di andare alla pagina in cui
è presenta il dettaglio della nota spese selezionata. Quello che è stato aggiunto rispetto al software
precedente è il pulsante di stampa: alla fine di ogni riga è, infatti, presente un pulsante che permette di
stampare un report contenente la nota spese compilata da una risorsa. Per fare ciò è stato necessario
creare un local report e utilizzare la sua proprietà di esportazione verso un file di immagine EMF, per
consentirne la stampa in automatico. Ovviamente non è stato possibile implementare la stampa sul
client, perché per le impostazioni di sicurezza del browser questo non è effetivamente fattibile, visto che
si cerca di stampare qualcosa che non è visualizzato nella pagina corrente. Perciò si è ricorsi alla stampa
dal server, tramite la stampante di default. Questo all’interno dell’azienda non è un problema, perché
comunque le stampe di tutti i client vengono gestite in modo centralizzato dal server. Ecco di seguito
uno stralcio del codice che ha permesso la stampa:
protected void btnPrint_Click(object sender, EventArgs e) { ImageButton chk = (ImageButton)sender; GridDataItem item = (GridDataItem)chk.NamingContainer; string keyvalue = item.GetDataKeyValue("ID").ToString(); Guid id = new Guid(keyvalue); LocalReport report = new LocalReport(); report.ReportPath = "Report2.rdlc"; report.DataSources.Add(new ReportDataSource("DataSet1", CostsheetTrackProvider.GetByIdCostsheetApproval(id))); report.DataSources.Add(new ReportDataSource("DataSet2", CostsheetTrackProvider.GetPartialSum(id))); Export(report); m_currentPageIndex = 0; Print(); Dispose(); } // Routine to provide to the report renderer, in order to // save an image for each page of the report. private Stream CreateStream(string name, string fileNameExtension, Encoding encoding, string mimeType, bool willSeek) { Stream stream = new MemoryStream(); m_streams.Add(stream); return stream; } // Export the given report as an EMF (Enhanced Metafile) file. private void Export(LocalReport report) { string deviceInfo = "<DeviceInfo>" + " <OutputFormat>EMF</OutputFormat>" + " <PageWidth>11in</PageWidth>" + " <PageHeight>8.5in</PageHeight>" + " <MarginTop>0.25in</MarginTop>" + " <MarginLeft>0.25in</MarginLeft>" + " <MarginRight>0.25in</MarginRight>" + " <MarginBottom>0.25in</MarginBottom>" + "</DeviceInfo>"; Warning[] warnings; m_streams = new List<Stream>(); report.Render("Image", deviceInfo, CreateStream, out warnings);
54
foreach (Stream stream in m_streams) stream.Position = 0; } // Handler for PrintPageEvents private void PrintPage(object sender, PrintPageEventArgs ev) { Metafile pageImage = new Metafile(m_streams[m_currentPageIndex]); ev.Graphics.DrawImage(pageImage, ev.PageBounds); m_currentPageIndex++; ev.HasMorePages = (m_currentPageIndex < m_streams.Count); } private void Print() { if (m_streams == null || m_streams.Count == 0) return; PrintDocument printDoc = new PrintDocument(); if (!printDoc.PrinterSettings.IsValid) { return; } printDoc.DefaultPageSettings.Landscape = true; printDoc.PrintPage += new PrintPageEventHandler(PrintPage); printDoc.Print(); } public void Dispose() { if (m_streams != null) { foreach (Stream stream in m_streams) stream.Close(); m_streams = null; } }
La stampa lato client è comunque resa disponibile, ma solo una volta che si è entrati nel
dettaglio della nota spese e si è creato il relativo report tramite il controllo ReportViewer. Questo
controllo, infatti, oltre a mettere a disposizione degli utenti la possibilità di stampare, consente anche di
esportare i report in tre formati diversi: PDF, Word ed Excel. Esportando all’interno del pacchetto di
Office, c’è inoltre la possibilità di editare i report, personalizzandoli, prima di andare alla stampa.
La pagina dei dettagli della nota spese, sfrutta lo stesso user control utilizzato per la pagina di
compilazione, solamente che in questo caso sono stati disabilitati sia la possibilità di aggiungere nuove
spese, sia la possibilità di eliminare una spesa già esistente. Rispetto al software precedente è stata data
la possibilità ai membri del gruppo NS_Approvers di editare le spese presenti nel caso in cui ci siano
delle piccole imprecisioni. In questo modo non sarà più necessario rifiutare la nota spese chiedendo alla
risorsa di correggere l’imprecisione, ma sarà lo stesso approvatore a poter apportare la modifica.
BillingOperations
Questa pagina è stata creata completamente da zero. In alto trovano spazio dei criteri di ricerca per
filtrare le spese in base alla data, al cliente e alla commessa. Più in basso sono invece presenti due
55
RadGrid: uno per la gestione delle spese documentate e uno per la gestione delle spese chilometriche.
La tabella relativa alle spese documentate non presenta alcuna peculiarità, mentre è importante
descrivere nel dettaglio quella relativa alle spese chilometriche. Le spese chilometriche, infatti, bisogna
trattarle in modo diverso dalle altre, soprattutto perché ci sono degli accordi commerciali fra l’azienda e
i clienti che prevedono dei rimborsi standardizzati oppure a forfait. È nata quindi l’esigenza di fornire la
possibilità agli utenti appartenenti al gruppo NS_BillingReaders di modificare i km inseriti dai dipendenti
nella nota spese così come il coefficiente di rimborso chilometrico. Questi valori restano comunque
indipendenti da quelli rimborsati al dipendente, servono solamente per creare la fattura al cliente. Per
procedere con la modifica della riga è possibile cliccare sull’icona di modifica accanto alla riga di
interesse, oppure anche fare doppio click sulla riga: in questi modi la riga entra in modalità di editing e
diventano quindi modificabili i due campi relativi ai chilometri e al coefficiente di rimborso chilometrico.
Accanto ad ogni riga delle due tabelle è stata aggiunta una checkbox che permette la selezione
della relativa spesa per la fatturazione. Per evitare di eseguire una chiamata al database per ogni
checkbox selezionata, si è deciso di salvare l’id della riga all’interno di un dictionary, e di salvare le
modifiche all’interno del database in un unico momento alla pressione del pulsante “Salva”. Ecco il
codice associato alla pressione del pulsante “Salva”:
protected void btnSave_Click(object sender, EventArgs e) { if (billingOperation.Count == 0) { return; } else { foreach (var pair in billingOperation) { Database db = DatabaseFactory.CreateDatabase(); DbCommand dbCommand = db.GetStoredProcCommand("CostsheetTrack_SetBilling"); db.AddInParameter(dbCommand, "ID", DbType.Guid, pair.Key); db.AddInParameter(dbCommand, "Status", DbType.Boolean, pair.Value); db.ExecuteDataSet(dbCommand); } RadGrid1.Rebind(); RadGridSpeseDocumentate.Rebind(); billingOperation.Clear(); } }
Una volta che le spese sono state selezionate per la fatturazione e sono state salvate, queste
diventano non più modificabili e in tabella appaiono disabilitate e di colore grigio. È stata però fornita la
possibilità di sbloccare le spese già fatturate, in modo tale che i dipendenti dell’amministrazione
possano modificare una fatturazione già eseguita in precedenza. Questo avviene tramite il pulsante
56
“Sblocca le spese” che richiama una stored procedure che setta a false il campo billing della tabella
CostsheetTrack.
Un’altra peculiarità di questa pagina è l’aggiornamento automatico dei totali: alla selezione di
una spesa per la fatturazione, vengono immediatamente aggiornati anche tutti i totali, sia quelli
riguardanti le spese documentate, sia quelli relativi alle spese chilometriche.
Report
Questa pagina è stata richiesta esplicitamente dalla direzione dell’azienda per poter tenere traccia di
tutte le spese che sostengono i dipendenti dell’azienda. Inoltre risulta di grande utilità anche per gli
operatori del reparto amministrativo che tramite questo report riescono a incrociare più dati e a
verificarne la correttezza. Nella pagina in alto si trovano una serie di criteri che permettono all’utente di
filtrare le informazioni secondo i seguenti parametri:
Data inizio
Data fine
Risorsa
Centro di costo
Cliente
Commessa
All’interno della pagina è poi presente un ReportViewer, che permette la visualizzazione del
local report che è stato appositamente creato. Questo report presenta dei parametri che vengono
specificati alla sua chiamata tramite la seguente procedura:
private void SetReportParameters() { ReportParameter customerParameter = new ReportParameter("Customer", rcbCustomer.Text); ReportViewer1.LocalReport.SetParameters(new ReportParameter[] { customerParameter }); ReportParameter commessaParameter = new ReportParameter("Commessa", rcbCommessa.Text); ReportViewer1.LocalReport.SetParameters(new ReportParameter[] { commessaParameter }); ReportParameter userParameter = new ReportParameter("User", rcbUser.Text); ReportViewer1.LocalReport.SetParameters(new ReportParameter[] { userParameter }); ReportParameter costCentreParameter = new ReportParameter("CostCentre", rcbCostCentre.Text); ReportViewer1.LocalReport.SetParameters(new ReportParameter[] { costCentreParameter }); if (DateFrom.SelectedDate != null) { ReportParameter dateFromParameter = new ReportParameter("DateFrom", DateFrom.SelectedDate.Value.ToString("MMMM yyyy", new CultureInfo("it-IT"))); ReportViewer1.LocalReport.SetParameters(new ReportParameter[]{dateFromParameter }); } else { ReportParameter dateFromParameter = new ReportParameter("DateFrom", "");
57
ReportViewer1.LocalReport.SetParameters(new ReportParameter[]{dateFromParameter }); } if (DateTo.SelectedDate != null) { ReportParameter dateToParameter = new ReportParameter("DateTo", DateTo.SelectedDate.Value.ToString("MMMM yyyy", new CultureInfo("it-IT"))); ReportViewer1.LocalReport.SetParameters(new ReportParameter[] { dateToParameter }); } else { ReportParameter dateToParameter = new ReportParameter("DateTo", ""); ReportViewer1.LocalReport.SetParameters(new ReportParameter[] { dateToParameter }); } }
Questi parametri sono necessari per compilare esattamente l’intestazione del report, specificando il
periodo di tempo, la risorsa, il centro di costo, il cliente e la commessa di cui si stanno visualizzando le
spese.
Booking
Questa pagina è utilizzata dagli utenti appartenenti al gruppo BookingCreators per inserire le
prenotazioni all’interno del sistema. Nella pagina in alto ci sono due combobox dalle quali poter
scegliere l’anno e il mese per i quali si sta effettuando la prenotazione. Più sotto si trova un RadGrid con
l’elenco di tutte le prenotazioni inserite. Per questa tabella c’è la possibilità di aggiungere, modificare o
cancellare una prenotazione. In questo RadGrid, a differenza di quello presente nella pagina di
compilazione della nota spese, la modalità di inserimento e modifica avviene tramite un form che
compare all’interno della tabella.
6.5.4 Mail
Una nuova funzionalità che è stata implementata è l’invio della mail. Ci sono tre casi in cui c’è la
necessità di inviare un’email:
Quando l’approvatore accetta una nota spese;
Quando l’approvatore rifiuta una nota spese;
Quando la risorsa richiede l’approvazione per una nota spese precedentemente rifiutata;
Quando viene inserita una nuova prenotazione;
Quando viene modificata o cancellata una prenotazione.
È stato quindi sviluppato un metodo generale per l’invio delle mail, che viene poi richiamato con
parametri diversi a seconda dei tre casi visti sopra. Il metodo è stato codificato nel modo seguente:
58
private static void SendMailMessage(string subject, string body, string destinatary) { // Compone la mail MailAddress from = new MailAddress(ConfigProvider.MailSender, "Teorema Gestione Nota Spese"); MailAddress to = new MailAddress(destinatary); MailMessage mail = new MailMessage(from, to); mail.IsBodyHtml = true; mail.Subject = subject; mail.Body = body; // Spedisce la mail SmtpClient client = new SmtpClient(); client.Host = ConfigProvider.SmtpHost; client.Send(mail); }
Per l’invio delle mail si è utilizzata la classe System.Net.Mail, che permette di inviare mail utilizzando il
protocollo SMTP. All’interno del gruppo Teorema si utilizza come SmtpHost Microsoft Exchange, quindi
è necessario specificare il nome del server su cui è in esecuzione Exchange. Per il mittente delle mail si è
creato appositamente un account in modo tale che le mail risultino sempre arrivare dall’indirizzo
6.5.5 Validazione dei dati
Per la validazione dei dati inseriti dagli utenti, siano questi i dati delle note spese o quelli delle
prenotazioni, si è utilizzata una libreria esterna denominata Fluent Validation, una piccola libreria per le
applicazioni .NET che mette a disposizione una pratica interfaccia e delle espressioni facilmente intuibili
per costruire le regole di validazione per gli oggetti creati. Ecco uno stralcio del codice relativo alla
validazione dei dati inseriti per le note spese:
public CostsheetTrackValidator() { #region NotEmpty rules RuleFor(ct => ct.IdCostsheet).NotEmpty() .WithMessage("<span style='color:red'>Non è stata selezionata una Nota Spese!</span>"); RuleFor(ct => ct.Date).NotEmpty().NotEqual(DateTime.MinValue).NotEqual(DateTime.MaxValue) .WithMessage("<span style='color:red'>Campo Data obbligatorio.</span><br>"); RuleFor(ct => ct.IdCustomer.Value).NotEqual(Guid.Empty) .WithMessage("<span style='color:red'>Campo Cliente obbligatorio.</span><br>"); RuleFor(ct => ct.IdCommessa.Value).NotEqual(Guid.Empty) .WithMessage("<span style='color:red'>Campo Commessa obbligatorio.</span><br>"); RuleFor(ct => ct.IdExpenseType).NotEqual(Guid.Empty) .WithMessage("<span style='color:red'>Campo Tipo Spesa obbligatorio.</span><br>"); RuleFor(ct => ct.Km.Value).NotEmpty().When(ct => ct.IdExpenseType == ExpenseTypeKm.ID) .WithMessage("<span style='color:red'>Campo Km obbligatorio e maggiore di zero.</span><br>");
59
RuleFor(ct => ct.DestinationCity).NotEmpty().When(ct => ct.IdExpenseType == ExpenseTypeKm.ID) .WithMessage("<span style='color:red'>Campo città di destinazione obbligatorio.</span><br>"); RuleFor(ct => ct.Note).NotEmpty() .WithMessage("<span style='color:red'>Campo Descrizione obbligatorio.</span><br>"); RuleFor(ct => ct.Amount.Value).NotEmpty() .WithMessage("<span style='color:red'>Campo Spesa obbligatorio e maggiore zero.</span><br>"); #endregion }
In pratica vengono verificate le seguenti condizioni:
Campo data obbligatorio
Campo cliente obbligatorio
Campo commessa obbligatorio
Campo Tipo Spesa obbligatorio
Campo Km obbligatorio e maggiore di zero se il tipo spesa è chilometrico
Campo città di destinazione obbligatorio se il tipo spesa è chilometrico
Campo descrizione obbligatorio
Campo spesa obbligatorio e maggiore di zero
6.6 Testing In questa sezione si prendono in considerazione due tipologie di test: lo unit testing e i test funzionali.
6.6.1 Unit Testing
Nella programmazione informatica, lo Unit Testing è una procedura usata per verificare singole parti di
un codice sorgente. Per unità si intende genericamente la minima parte testabile di un codice sorgente:
nella programmazione procedurale un'unità può rappresentare un singolo programma, funzione,
procedura, etc.; nella programmazione orientata agli oggetti, la più piccola unità può essere il metodo.
Lo Unit Testing si articola in test case ciascuno dei quali dovrebbe essere indipendente dagli altri. Lo Unit
Testing viene normalmente eseguito dagli sviluppatori, non da utenti finali. Lo scopo dello Unit Testing è
quello di verificare il corretto funzionamento di parti di programma permettendo così una precoce
individuazione dei bug. Uno Unit Testing accurato può dare una prova certa se un pezzo di codice
funziona correttamente, con importanti vantaggi.
Semplifica le modifiche: lo unit testing facilita la modifica del codice del modulo in momenti
successivi (refactoring) con la sicurezza che il modulo continuerà a funzionare correttamente. Il
60
procedimento consiste nello scrivere test case per tutte le funzioni e i metodi, in modo che se una
modifica produce un fallimento del test, si possa facilmente individuare la modifica responsabile. Unit
test già predisposti semplificano la vita al programmatore nel controllare che una porzione di codice stia
ancora funzionando correttamente. Un buon unit testing produce test case che coprano tutti i percorsi
del codice dell'unità, con particolare attenzione alle condizioni nei cicli (test sugli if, while, for). In sistemi
con unit testing continuo, tali test sono in grado di garantire l'automatica integrità del codice ad ogni
modifica.
Supporta la documentazione: lo unit testing fornisce una documentazione "viva" del codice,
perché è intrinsecamente un esempio di utilizzo dell'API del modulo. I test case incorporano le
caratteristiche critiche per il successo di un'unità di codice. Tali caratteristiche indicano l'uso appropriato
dell'unità e i comportamenti errati che devono essere identificati nel suo funzionamento. Pertanto lo
unit testing documenta tali caratteristiche, sebbene in molti ambienti questi non possono costituire la
sola documentazione necessaria. In compenso, la tradizionale documentazione diventa spesso obsoleta
a cause di successive modifiche del codice non documentate.
Limitazioni dello unit testing: in generale il testing non riesce ad identificare tutti gli errori in un
programma e lo stesso vale per lo Unit Testing che, analizzando per definizione le singole unità, non può
identificare gli errori di integrazione, problemi legati alla performance e altri problemi legati al sistema
in generale. Lo unit testing è più efficace se utilizzato in congiunzione con altre tecniche di testing del
software. Come ogni forma di testing, anche lo Unit Testing non può individuare l'assenza di errori ma
può solo evidenziarne la presenza.
Il testing del software è un problema di matematica combinatoria. Per esempio, ogni test
booleano richiede almeno due test, uno per la condizione di "vero" e uno per quella di "falso". Si può
dimostrare che, per ogni linea di codice funzionale, siano necessarie dalla 3 alle 5 linee di codice per il
test. È quindi irrealistico testare tutte le possibili combinazioni di input di qualsiasi codice non banale
senza un tool apposito di generazione di casi di test.
Per ottenere gli sperati benefici dallo unit test, è richiesto un rigoroso senso di disciplina durante
tutto il processo di sviluppo. È essenziale mantenere traccia non solo dei test che non stati sviluppati ed
eseguiti, ma anche di tutte le modifiche effettuate al codice funzionale dell'unità in esame e di tutte le
altre. L'uso di un sistema di controllo versione è essenziale. Se una versione successiva di una unità
fallisce un test che aveva passato in precedenza, il sistema di controllo versione permette di evidenziare
le modifiche al codice intervenute nel frattempo.
61
6.6.2 Test Funzionali
Nell’ingegneria del software un test case è un insieme di condizioni o variabili attraverso cui un tester
può determinare se un applicazione o un sistema software funziona correttamente oppure no. Per
analizzare tutti i test case è opportuno partire costruendo il diagramma di workflow dell’applicazione,
individuando quali sono i processi coinvolti, chi sono gli attori che entrano in gioco e le possibili azioni di
tutti gli attori. Sono stati individuati due processi principali: quello riguardante la creazione di una nota
spese e quello riguardante la creazione di una prenotazione. Per ciascuno di questi processi sono poi
stati individuati i rispettivi attori:
Processo: gestione nota spese
Attori: dipendenti, approvatori, approvatori di Back Up, visualizzatori, Super User.
Azioni
1. Dipendenti (anche super user):
a. Inserire nota spese
b. Inserire spesa
c. Modificare spesa
d. Eliminare spesa
e. Chiudere nota spese
f. Modificare nota spese
g. Stampare
2. Approvatori (anche approvatori di back up):
a. Visualizzare nota spese
b. Aggiungere anticipo di cassa
c. Aggiungere nota
d. Approvare nota spese
e. Respingere nota spese
f. Stampare
3. Visualizzatori
a. Visualizzare note spese
b. Selezionare le spese da fatturare ai clienti
c. Creare report
d. Stampare
Processo: gestione prenotazioni.
62
Attori: dipendenti, amministrazione.
Azioni:
1. Dipendenti:
a. Visualizzare prenotazioni
b. Stampare prenotazioni
2. Amministrazione:
a. Inserire prenotazione
b. Modificare prenotazione
c. Eliminare prenotazione
d. Chiudere prenotazione
e. Stampare
Per costruire un insieme di test case sufficientemente completo, in grado di analizzare ogni possibile
condizione di utilizzo, si è partiti dal diagramma di workflow e si è iniziato ad analizzare ogni percorso
possibile dell’albero. Il principio base di questa procedura è quello di assicurarsi di passare almeno una
volta per ciascun ramo dell’albero ed effettuare almeno un paio di iterazioni per ogni ciclo presente. In
questo modo si ha la certezza di testare ogni possibile percorso. Ogni cammino trovato diventa un test
case al quale viene associato un nome univoco che lo identifica all’interno della struttura. Procedendo in
questo modo sono stati individuati 15 test cases, 10 per quanto riguarda la parte di gestione delle note
spese e 5 per quanto riguarda la parte di gestione delle prenotazioni.
Il passo successivo è quello di analizzare ogni singolo test case e individuare le possibili variabili che
entrano in gioco per ogni singola azione del test. Naturalmente ci sono azioni che presentano un
numero considerevole di variabili, mentre alcune più semplici in cui non vi è presente neanche una
variabile. Le azioni individuate sono state 25, mentre il numero totale di variabili coinvolte è stato di 22.
A partire poi dalle variabili trovate, si è proceduto ad un’analisi per capire quale fosse il possibile range
di valori che ciascuna variabile potesse assumere all’interno dell’applicativo. In questa fase si è tenuto
conto sia dei valori accettati dal sistema, sia di quelli che non rispettano le specifiche del programma. In
questo modo si è cercato di simulare ogni possibile input da parte dell’utente finale, per riuscire a
testare l’applicativo in qualunque condizione di utilizzo e prevenire ogni qualsivoglia malfunzionamento.
Una volta trovati i possibili valori di test per ciascuna variabile, si è proceduto ad effettuare una
combinazione di valori/variabili che fosse la più completa possibile. Analizzare tutte le variabile con tutti
63
i loro possibili valori risulterebbe infatti impossibile, visto che il numero di test cases aumenterebbe in
maniera esponenziale, facendo incrementare in questo modo sia i tempi per la realizzazione dei test sia i
costi. Il problema viene invece in parte evitato, visto che le azioni che hanno molte variabili e che quindi
risulterebbero difficili da testare completamente compaiono in più test cases. Con un po’ di accortezza
infatti si riescono ad analizzare tutti i casi possibili, ovviamente non per ogni singolo test case, ma
complessivamente.
Ecco la lista dei Test Cases individuati:
Processo Test Case Azioni
Nota spese
Test 1 Creare Nota Spese
Inserire nuova spesa
Richiedere approvazione
Approvare Nota Spese
Selezionare spese da fatturare
Creare report
Test 2 Creare Nota Spese
Nessuna spesa
Chiudere Nota Spese
Test 3 Creare Nota Spese
Inserire nuova spesa
Inserire nuova spesa
Richiedere approvazione
Inserire anticipo di cassa
Approvare Nota Spese
Selezionare spese da fatturare
Creare report
Test 4 Creare Nota Spese
Inserire nuova spesa
Non richiedere approvazione
Salvare Nota Spese
Test 5 Creare Nota Spese
Inserire nuova spesa
Non richiedere approvazione
Non salvare modifiche
Test 6 Creare Nota Spese
Inserire nuova spesa
Inserire nuova spesa
Modificare spesa
Richiedere approvazione
64
Inserire Nota
Respingere Nota Spese
Selezionare spese da fatturare
Creare report
Test 7 Creare Nota Spese
Inserire nuova spesa
Inserire nuova spesa
Eliminare spesa
Richiedere approvazione
Inserire anticipo di cassa
Inserire Nota
Approvare Nota Spese
Selezionare spese da fatturare
Creare report
Test 8 Modificare Nota Spese
Inserire nuova spesa
Richiedere approvazione
Respingere Nota Spese
Selezionare spese da fatturare
Creare report
Test 9 Modificare Nota Spese
Inserire nuova spesa
Non richiedere approvazione
Salvare Nota Spese
Test 10 Modificare Nota Spese
Modificare spesa
Richiedere approvazione
Inserire anticipo di cassa
Inserire Nota
Approvare Nota Spese
Selezionare spese da fatturare
Creare report
Prenotazione
Test 1 Inviare mail per prenotare
Creare nuovo documento prenotazione
Inserire nuova prenotazione
Chiudere documento prenotazione
Test 2 Inviare mail per prenotare
Creare nuovo documento prenotazione
Inserire nuova prenotazione
Salvare Nota Spese
Test 3
Chiamare per prenotare
65
Creare nuovo documento prenotazione
Inserire nuova prenotazione
Non salvare modifiche
Test 4 Nessuna prenotazione
Creare nuovo documento prenotazione
Chiudere documento prenotazione
Test 5 Modificare documento prenotazione
Inserire nuova prenotazione
Modificare prenotazione
Chiudere documento prenotazione Tabella 6-1: Test Cases
Di seguito le variabili associate a ciascuna azione:
Processo Azioni Variabili
Nota Spese Inserire nuova spesa
Data (date time)
Cliente (dropdown list)
Commessa (dropdown list)
Tipo Spesa (dropdown list)
Km (int)
Descrizione (String)
Spesa (currency)
Allegato (int)
Modificare spesa Spese presenti (int)
Data (date time)
Cliente (dropdown list)
Commessa (dropdown list)
Tipo Spesa (dropdown list)
Km (int)
Descrizione (String)
Spesa (currency)
Allegato (int)
Eliminare spesa Spese presenti (int)
Richiedere approvazione Spese presenti (int)
Inserire Nota Nota (string)
Inserire anticipo di cassa Anticipo di cassa (currency)
Selezionare spese da fatturare Spese selezionate (combo box)
Prenotazione Inserire nuova prenotazione
Mese/Anno (date time)
66
Risorsa (dropdpwn list)
Cliente (dropdown list)
Commessa (dropdown list)
Data prenotazione (Date time)
Dettaglio prenotazione (String)
Prezzo (currency)
Modificare prenotazione Prenotazioni presenti (int)
Mese/Anno (date time)
Risorsa (dropdpwn list)
Cliente (dropdown list)
Commessa (dropdown list)
Data prenotazione (Date time)
Dettaglio prenotazione (String)
Prezzo (currency)
Eliminare prenotazione Prenotazioni presenti (int)
Chiudere documento prenotazione
Prenotazioni presenti (int)
Tabella 6-2: Variabili
6.7 Installazione dell’applicativo Per installare l’applicativo è necessario creare una nuova web application all’interno di una farm
SharePoint 2010. Poi bisogna aggiungere una nuova site collection, un nuovo site ed infine creare tante
pagine web quante sono necessarie all’applicativo.
Nella cartella root della web application bisogna creare tre cartelle:
Img: questa cartella contiene tutte le immagini che vengono utilizzate all’interno
dell’applicativo;
MailTemplates: in questa cartella sono presenti i template che vengono utilizzati per l’invio delle
mail;
Report: qui si trovano tutti i report con estensione rdlc che vengono utilizzati dal programma
per visualizzare i dati.
Il passo successivo è quello di copiare nella cartella bin, sempre nella root della web application, tutte le
dll necessarie all’applicativo per funzionare correttamente. In particolare devono essere copiate tutte
quelle dll che non vengono caricate automaticamente da Visual Studio al momento del deploy
dell’applicativo. Quindi tutte quelle dll relative all’accesso ai dati, alla loro validazione, all’autenticazione
e alla resa grafica dell’applicativo (Telerik).
67
Un'altra azione fondamentale per il corretto funzionamento dell’applicativo è la modifica del file
web.config.
6.7.1 Web.config
Innanzitutto bisogna inserire all’interno della <configSections> sotto <configuration> la seguente riga
<section name="dataConfiguration"
type="Microsoft.Practices.EnterpriseLibrary.Data.Configuration.DatabaseSettings,
Microsoft.Practices.EnterpriseLibrary.Data" />
Questo è necessario per utilizzare i servizi offerti dal Microsoft Enterprise Library, cioè una collezione di
componenti software riutilizzabili (blocchi di applicazione) progettati per assistere gli sviluppatori
software in alcuni compiti della programmazione, quali ad esempio il logging, la validazione, l’accesso ai
dati, la gestione delle eccezioni e molti altri. Vengono forniti come codice sorgente, casi di test e
documentazione che possono essere utilizzati così come sono , estesi o modificati dagli sviluppatori per
essere utilizzati in progetti più complessi. In questo caso questa libreria è stata sfruttata principalmente
per due problemi: l’accesso ai dati e la validazione dei dati inseriti dall’utente.
Poi, sempre all’interno della stessa sezione, è necessario inserire le seguenti righe:
<sectionGroup name="system.web.extensions"
type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions,
Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
<sectionGroup name="scripting"
type="System.Web.Configuration.ScriptingSectionGroup,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35">
<section name="scriptResourceHandler"
type="System.Web.Configuration.ScriptingScriptResourceHandlerSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="MachineToApplication" />
<sectionGroup name="webServices"
type="System.Web.Configuration.ScriptingWebServicesSectionGroup,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35">
<section name="jsonSerialization"
type="System.Web.Configuration.ScriptingJsonSerializationSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="Everywhere" />
<section name="profileService"
type="System.Web.Configuration.ScriptingProfileServiceSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
68
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="MachineToApplication" />
<section name="authenticationService"
type="System.Web.Configuration.ScriptingAuthenticationServiceSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="MachineToApplication" />
<section name="roleService"
type="System.Web.Configuration.ScriptingRoleServiceSection,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" requirePermission="false"
allowDefinition="MachineToApplication" />
</sectionGroup>
</sectionGroup>
</sectionGroup>
Tutto questo è necessario per poter gestire nel migliore dei modi i comandi Ajax all’interno delle pagine
di SharePoint.
Poi all’interno dell’elemento <SharePoint>, sotto la voce <SafeControls> bisogna aggiungere queste
righe:
<SafeControl Assembly="Telerik.Web.UI, Version=2010.2.929.35, Culture=neutral,
PublicKeyToken=121fae78165ba3d4" Namespace="Telerik.Web.UI" TypeName="*" Safe="true" />
<SafeControl Assembly="ajaxcontroltoolkit, Version=3.0.30930.28736, Culture=neutral,
PublicKeyToken=28f01b0e84b6d53e, processorArchitecture=MSIL" Namespace="AjaxControlToolkit"
TypeName="*" />
Il primo elemento specifica il nome di una dll e del suo particolare numero di versione riguardante
Telerik, una libreria che mette a disposizione dei controlli personalizzati molto efficienti. In particolare
questa libreria è stata utilizzata per ogni componente grafico dell’applicativo, cioè pulsanti, combobox,
tabelle, ecc.
Il secondo elemento è un riferimento alla libreria AjaxControlToolkit, che fornisce una potente
infrastruttura per scrivere controlli Ajax riusabili, personalizzabili ed estensibili.
All’interno dell’elemento <httpHandlers>, sotto la voce <System.Web>, bisogna aggiungere le seguenti
righe:
<httpHandlers>
<remove verb="*" path="*.asmx" />
<add verb="*" path="*.asmx" validate="false"
type="System.Web.Script.Services.ScriptHandlerFactory,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" />
<add verb="*" path="*_AppService.axd" validate="false"
type="System.Web.Script.Services.ScriptHandlerFactory,
69
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" />
<add verb="GET,HEAD" path="ScriptResource.axd"
type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions,
Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
validate="false" />
<add path="ChartImage.axd" type="Telerik.Web.UI.ChartHttpHandler" verb="*"
validate="false" />
<add path="Telerik.Web.UI.DialogHandler.aspx"
type="Telerik.Web.UI.DialogHandler" verb="*" validate="false" />
<add path="Telerik.RadUploadProgressHandler.ashx"
type="Telerik.Web.UI.RadUploadProgressHandler" verb="*"
validate="false" />
<add path="Telerik.Web.UI.WebResource.axd" type="Telerik.Web.UI.WebResource"
verb="*" validate="false" />
<add verb="*" path="Reserved.ReportViewerWebControl.axd"
type="Microsoft.Reporting.WebForms.HttpHandler,
Microsoft.ReportViewer.WebForms, Version=9.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" />
</httpHandlers>
Tutto questo è necessario per la corretta gestione dei controlli Telerik.
All’interno invece della voce <httpModules> è necessario aggiungere:
<httpModules>
<add name="ScriptModule" type="System.Web.Handlers.ScriptModule,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" />
<add name="RadUploadModule" type="Telerik.Web.UI.RadUploadHttpModule" />
<add name="RadCompression" type="Telerik.Web.UI.RadCompression" />
</httpModules>
Il passo successivo è quello di aggiungere la seguente riga per la gestione delle sessioni, altrimenti
disabilitata:
<pages enableSessionState="true" enableViewState="true" enableViewStateMac="true"
validateRequest="false"
pageParserFilterType="Microsoft.SharePoint.ApplicationRuntime.SPPageParserFilt er,
Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
asyncTimeout="7">
All’interno dell’elemento <Modules>, sotto la voce <System.WebServer>, bisogna commentare i campi
<remove name="Session" />
<add name="RadCompression" type="Telerik.Web.UI.RadCompression"/>
E aggiungere i seguenti elementi:
70
<remove name="ScriptModule" />
<add name="ScriptModule" preCondition="managedHandler"
type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0,
Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add name="RadUploadModule" type="Telerik.Web.UI.RadUploadHttpModule" />
All’interno dell’elemento <Handlers>, sotto la voce <System.WebServer>, bisogna aggiungere le
seguenti righe:
<add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode"
type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions,
Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd"
preCondition="integratedMode"
type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions,
Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD"
path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31BF3856AD364E35" />
<add name="ChartImage_axd" path="ChartImage.axd" type="Telerik.Web.UI.ChartHttpHandler"
verb="*" preCondition="integratedMode,runtimeVersionv2.0" />
<add name="Telerik_Web_UI_DialogHandler_aspx" path="Telerik.Web.UI.DialogHandler.aspx"
type="Telerik.Web.UI.DialogHandler" verb="*"
preCondition="integratedMode,runtimeVersionv2.0" />
<add name="Telerik_RadUploadProgressHandler_ashx" path="Telerik.RadUploadProgressHandler.ashx"
type="Telerik.Web.UI.RadUploadProgressHandler" verb="*"
preCondition="integratedMode,runtimeVersionv2.0" />
<add name="Telerik_Web_UI_WebResource_axd" path="Telerik.Web.UI.WebResource.axd"
type="Telerik.Web.UI.WebResource" verb="*"
preCondition="integratedMode,runtimeVersionv2.0" />
Nelle <AppSettings> aggiungere l’elemento:
<add key="UseMultipleTrustedActiveDirectories" value="false" />
Infine bisogna aggiungere le seguenti righe:
<dataConfiguration defaultDatabase="Teorema_NotaSpese" />
<connectionStrings>
<add name="Teorema_NotaSpese" connectionString="Data Source=sp2010;Initial
Catalog=T_Teorema_NotaSpese;User Id=enrico.natella; Password=Password123"
providerName="System.Data.SqlClient" />
<add name="Teorema_Tracking" connectionString="Data Source=sp2010;Initial
Catalog=TrackingWeb;User Id=enrico.natella; Password=Password123"
providerName="System.Data.SqlClient" />
</connectionStrings>
71
Queste ultime righe sono necessarie al corretto funzionamento della libreria EnterpriseLibrary, in
particolare vengono specificate le connection string per ciascuno dei due database necessari
all’applicativo e viene impostato come database di default “Teorema_NotaSpese”.
6.7.2 Active Directory
Un altro aspetto fondamentale è la creazione dei gruppi all’interno di Active Directory. Per funzionare
correttamente, infatti, l’applicativo ha bisogno che in AD ci siano tanti gruppi quante sono le tipologie di
attori che partecipano al processo di gestione delle note spese. Per questo motivo è necessario creare i
seguenti gruppi:
NS_Operators: gruppo nel quale si trovano tutti gli utenti che possono inserire note spese
NS_AccountManagers: a questo gruppo appartengono gli utenti che possono creare le note
spese, ma che a differenza degli altri non hanno bisogno di richiedere l’approvazione.
NS_SuperUsers: qui sono presenti tutti coloro che possono editare le note spese di tutti e che
possono crearle per conto terzi.
NS_Approvers: all’interno di questo gruppo si trovano gli utenti che hanno il compito di
approvare o respingere le note spese.
NS_BillingReaders: in questo gruppo ci sono gli utenti che si occupano di produrre le fatture da
inviare ai clienti.
BookingCreators: vengono definiti in questo modo coloro che hanno la possibilità di inserire
prenotazioni all’interno del sistema.
6.7.3 Database
Affinchè l’applicativo possa funzionare ha bisogno che il proprio database sia presente all’interno del
DBMS specificato nella connection string all’interno del file web.config. Dovrà perciò essere fornita una
copia di backup del database di cui fare un restore nel nuovo ambiente produttivo. Bisogna poi far
puntare l’applicativo al database relativo al tracking contenente le informazioni relative a Risorse, Clienti
e Progetti. Bisogna infine aggiungere al database del tracking alcune stored procedure per recuperare le
informazioni relative a risorse, clienti e progetti.
6.7.4 Tabella di Configurazione
Nel database T_Teorema_NotaSpese è presente una tabella di configurazione, nella quale si possono
specificare significativi parametri di configurazione dell’applicativo. Per esempio si può specificare
l’indirizzo del server di active directory, l’indirizzo del server di posta di microsoft exchange, utilizzato
per l’invio delle mail e tanti altri parametri che vengono descritti più in dettaglio nella tabella
sottostante.
72
Parametro Valore
AD_GROUP_ACCOUNT_MANAGERS NS_AccountManagers
AD_GROUP_APPROVERS NS_Approvers
AD_GROUP_BILLING_READERS NS_BillingReaders
AD_GROUP_OPERATORS NS_Operators
AD_GROUP_SECRETARIES secretaries
AD_GROUP_SUPERUSERS NS_SuperUsers
AD_PATH DC=dev,DC=local
AD_PWD Password123
AD_SERVER SP2010.dev.local
AD_UID Administrator
KM_REFOUND_RATE 0,32
MAIL_APPROVER [email protected]
MAIL_SENDER [email protected]
MAIL_TEMPLATE_APPROVED MailTemplates/CostsheetAccepted.
htm
MAIL_TEMPLATE_COMPILED /MailTemplates/CostsheetSubmitted
.htm
MAIL_TEMPLATE_REJECTED /MailTemplates/CostsheetRejected.
htm
PAGE_BOOKING_COMPILATION /SitePages/Booking.aspx
PAGE_COSTSHEET_APPROVEMENT /SitePages/appr.aspx
PAGE_COSTSHEET_APPROVEMENT_VISUALIZATIO
N
/SitePages/appsingle.aspx
PAGE_COSTSHEET_BILLING_OPERATIONS /SitePages/bill.aspx
PAGE_COSTSHEET_COMPILATION /SitePages/comp.aspx
PAGE_COSTSHEET_PRINT /SitePages/print.aspx
PAGE_UNAUTHORIZED /SitePages/UtenteNonAutorizzato.as
px
PAGE_USER_NOT_EXISTENT /SitePages/UtenteNonEsistente.aspx
SMTP_HOST srvmail.eng.teorema.net
STATUS_IMAGES_URL /Img/{0}.png
73
7 I modi d’uso
7.1 Introduzione
In questo capitolo viene fornita una panoramica sulle funzionalità offerte dall’applicativo. Si è fatto
ricorso a numerose immagini. Infatti, si è ritenuto che le figure esplicassero meglio i seguenti contenuti,
risultando di maggior ausilio al lettore.
7.2 Le funzionalità generali L’applicativo si apre chiedendo all’utente di autenticarsi. Una volta autenticato con lo username e la
password di dominio si accede alla home page del progetto, in cui è presente una breve descrizione
delle funzionalità. Nella top link bar sono presenti tutti i link ai quali la risorsa autenticata ha diritto di
accedere, quindi se per esempio la risorsa è un impiegata del settore amministrativo avrà solamente a
disposizione i link verso le pagine per la selezione delle spese da fatturare ai clienti, mentre tutti gli altri
link verranno nascosti.
74
Si descrive di seguito ciascuna pagina dell’applicativo, con l’intenzione di creare una guida che
sia utile all’utilizzatore finale dell’applicazione.
7.2.1 CostsheetCompilation
Figura 7-1: Pagina per la compilazione della nota spese
Questa pagina è accessibile ai membri dei gruppi NS_Operators, NS_AccountManagers e
NS_SuperUsers. Lo scopo di questa pagina è l’inserimento di una nota spese all’interno dell’applicativo.
Ogni nota spese può contenere al suo interno più spese di tipologie differenti. La pagina si presenta in
questo modo: in alto compaiono due combobox in cui è possibile scegliere il mese e l’anno di
compilazione della nota spese. Si ricorda che è possibile inserire note spese e richiederne l’approvazione
per il mese corrente e per i mesi precedenti a quello corrente. Per i mesi successivi a quello corrente,
invece, vi è la possibilità di inserire la nota spese, ma è inibita la possibilità di richiedere l’approvazione
fino al raggiungimento del mese specificato. Al di sotto dell’anno e del mese vi è presente una piccola
finestra contenente alcuni dettagli, quali il beneficiario e lo status della nota spese. Si ricorda che la nota
spese può trovarsi in quattro stati differenti:
Accettata: la nota spese è stata accettata dall’approvatore e quindi le spese al suo interno sono
disponibili per la successiva fase di fatturazione;
Compilata: la nota spese è stata compilata dalla risorsa e ne è stata richiesta l’approvazione;
Rifiutata: la nota spese è stata rifiutata dall’approvatore;
75
Da compilare: la nota spese è in fase di compilazione e quindi non ne è stata ancora chiesta
l’approvazione.
Al centro della pagina si trova una tabella con l’elenco delle spese inserite, con la possibilità di
aggiungerne di nuove oppure di modificare o cancellare quelle già presenti. Nell’intestazione della
tabella è presente un pulsante che consente l’inserimento di una nuova spesa: alla sua pressione viene
automaticamente aggiunta una riga alla tabella e c’è la possibilità di editarla.
Figura 7-2: Inserimento nuova spesa
I campi da inserire sono i seguenti:
Data: rappresenta la data in cui è stata sostenuta la spesa; questa data è vincolata all’anno e al
mese selezionati per la compilazione della nota spese. Vi è un comodo pulsante per il
selezionamento della data tramite un calendario che proporrà solamente il mese per cui si sta
compilando la nota spese. Una volta selezionata la data desiderata dal calendario, verrà
automaticamente riempito il campo relativo alla data. Su questo campo viene effettuato un
controllo per verificare che non venga lasciato vuoto.
Cliente: rappresenta il cliente per cui si è sostenuta la spesa; questo campo è editabile
attraverso una combobox dalla quale è possibile scegliere da un elenco il cliente desiderato. I
76
clienti che appaiono in questa combobox vengono recuperati interrogando il database del
tracking, che viene utilizzato per il tracciamento delle ore lavorative. In pratica nell’elenco
compariranno solamente i clienti per cui la risorsa che sta compilando la nota spese ha
effettivamente lavorato nel mese di riferimento e non l’elenco di tutti i clienti disponibili. Su
questo campo viene effettuato un controllo per verificare che non venga lasciato vuoto.
Commessa: rappresenta la commessa associata al cliente. La scelta della commessa avviene
tramite una combobox in cui compaiono, come per il cliente, solamente le commesse per il
quale la risorsa ha effettivamente lavorato nel mese di riferimento. Su questo campo viene
effettuato un controllo per verificare che non venga lasciato vuoto.
Descrizione: breve descrizione della spesa sostenuta. Se la tipologia di spesa è di tipo alloggio in
questa campo è necessario specificare il nome della struttura/albergo presso il quale si ha
pernottato. Su questo campo viene effettuato un controllo per verificare che non venga
lasciato vuoto.
Tipo Spesa: rappresenta la tipologia di spesa. Essa può essere scelta attraverso una combobox
in cui compaiono le quattro possibili tipologie di spesa: Alloggio, Altro, Km, Trasporti e Vitto. A
seconda della tipologia di spesa selezionata vengono nascosti o mostrati dei campi della
tabella: se per esempio la tipologia di spesa è Km, verranno resi visibili i campi Km e Città,
mentre saranno disabilitati il campo relativo alla spesa, perché esso sarà calcolato in modo
automatico tramite il coefficiente di rimborso chilometrico, e i campi relativi alla fattura e alla
spesa di rappresentanza. Per tutti gli altri tipi di spesa, invece, i campi Km e Città diventeranno
invisibili, mentre il campo Spesa sarà abilitato. Su questo campo viene effettuato un controllo
per verificare che non venga lasciato vuoto.
Km: rappresenta i Km che la risorsa ha effettuato per raggiungere la sede del cliente. Questo
campo si attiva solamente se la tipologia di spesa selezionata è Km. Su questo campo vengono
effettuati due controlli: il campo non può essere lasciato vuoto e i Km inseriti devono essere
maggiori di zero.
Città: rappresenta la città sede del cliente presso cui si è effettuato il lavoro. Questo campo si
attiva solamente se la tipologia di spesa selezionata è Km. Su questo campo viene effettuato un
controllo per verificare che non venga lasciato vuoto.
Spesa: indica la somma sostenuta per la spesa indicata. Questo campo è da riempire sempre
tranne nel caso in cui la spesa sia di tipo chilometrico. In questo caso, infatti, viene riempito in
automatico moltiplicando i chilometri inseriti con il coefficiente di rimborso chilometrico. Su
questo campo vengono effettuati due controlli: il campo non può essere lasciato vuoto e il
valore inserito deve essere maggiore di zero.
77
Fattura: indica se per la spesa sostenuta si è ricevuta una fattura oppure uno scontrino. Questo
campo è disabilitato nel caso in cui la spesa sia di tipo chilometrico. Su questo campo non viene
effettuato alcun controllo.
Rappresentanza: indica se la spesa sostenuta era per rappresentanza. Questo campo è
disabilitato nel caso in cui la spesa sia di tipo chilometrico. Su questo campo non viene
effettuato alcun controllo.
Allegato: rappresenta il numero da riportare sul retro dello scontrino o della fattura per
associare la riga della spesa allo scontrino. Più spese possono avere lo stesso numero di
allegato. Su questo campo non viene eseguito alcun tipo di controllo.
Per salvare la nuova spesa è necessario premere il pulsante “Inserisci” alla fine della riga. Se invece non
si vogliono salvare le modifiche effettuate è sufficiente cliccare sul pulsante “Annulla”. Prima di salvare
una nuova nota spese vengono naturalmente effettuati tutti i controlli necessari per validare i dati
inseriti. Nel caso in cui un valore non sia valido, verrà visualizzata una scritta di colore rosso esattamente
sotto il campo errato con la descrizione dell’errore commesso. Nella figura riportata sotto si mostra un
esempio in cui si tenta di inserire una nuova nota spese lasciando tutti i campi vuoti.
Figura 7-3: Inserimento di una riga vuota
Il caso della modifica di una spesa precedentemente inserita è molto simile al precedente: per
iniziare a editare una riga è necessario fare click sul pulsante modifica posto in fondo alla riga che si
intende modificare. Una volta modificati i campi desiderati si può procedere al salvataggio delle
modifiche tramite il pulsante “Conferma”, oppure eliminare i cambiamenti effettuati tramite il pulsante
“Annulla”.
Per cancellare una spesa precedentemente inserita è sufficiente cliccare sul pulsante “Cancella”
posto in fondo alla spesa che si desidera cancellare. Apparirà un messaggio di conferma: se si risponde
“Ok” la spesa viene cancellata, altrimenti non succede niente.
Nel footer della tabella, in corrispondenza alla colonna “Spesa”, appaiono quattro voci:
Rimborso spese: rappresenta la somma delle spese documentate;
Rimborso chilometrico: rappresenta la somma delle spese chilometriche;
78
Totale Anticipato: rappresenta la somma che è stata anticipata dall’amministrazione;
Totale a pagare: rappresenta la somma del rimborso spese e del rimborso chilometrico, meno il
totale anticipato; questo è quindi l’importo che viene effettivamente rimborsato al dipendente.
Nessuno di questi campi è editabile, vengono riempiti in automatico dal sistema. Il campo “Totale
Anticipato” può essere invece editato dall’utente approvatore, ma solamente nella sua maschera di
approvazione.
Sempre nel footer della tabella trova spazio il valore del coefficiente di rimborso chilometrico,
che viene recuperato direttamente dal database. L’attuale coefficiente di rimborso chilometrico è
impostato a 0,52 €/Km.
Sotto la tabella è presente un ampio campo per le note: questo campo può essere utilizzato sia
dagli utenti compilatori per specificare qualcosa in particolare, sia dagli utenti approvatori per
commentare qualche spesa.
In fondo alla pagina trovano spazio una serie di pulsanti che appaiono in maniera dinamica a
seconda della tipologia di utente che è loggato all’interno del sistema e a seconda dello status della nota
spese. Si analizzano tutti i vari casi:
Utente appartenente al gruppo NS_Operators e NS_SuperUsers:
o Status: TOCOMPILE
Salva
Richiedi Approvazione
Chiudi (presente solo se non viene inserita alcuna spesa)
Stampa
o Status: COMPILED
Stampa
o Status: REJECTED
Salva
Richiedi Approvazione
Stampa
o Status: APPROVED
Stampa
Utente appartenente al gruppo NS_AccountManagers:
o Stampa
o Chiudi
79
Gli utenti appartenenti al gruppo NS_AccountManagers non hanno bisogno di richiedere l’approvazione,
perciò hanno solo la possibilità di premere il tasto “Chiudi” che rende la nota spesa approvato in
automatico.
Per gli altri utenti, se la spesa è in attesa di approvazione o è stata approvata, l’unica azione disponibile
diventa la stampa della nota spesa: oltre a nascondere tutti gli altri pulsanti, viene inibita ogni modifica
alla tabella. In altre parole non si possono più inserire nuove spese, modificare o cancellare quelle
esistenti. Il pulsante di stampa è invece l’unico che è sempre presente.
Si analizza ora il comportamento di ciascun pulsante:
Salva: vengono salvate tutte le modifiche apportate alla tabella e vengono salvate anche le note;
Richiedi Approvazione: appare una finestra di conferma e in caso positivo la nota spesa viene
resa disponibile agli utenti approvatori che ne valuteranno la corretta compilazione. Se si sta
richiedendo l’approvazione per una nota spese che era stata precedentemente rifiutata, allora
viene inviata automaticamente una mail all’utente approvatore per avvisarlo dell’avvenuta
ricompilazione della nota spese;
Chiudi: questo pulsante è presente solamente nel caso in cui non ci sia alcuna spesa all’interno
della nota spese. Tramite questo pulsante la nota spese viene direttamente approvata;
Stampa: questo pulsante rindirizza l’utente verso una pagina in cui è presente un report che
rende possibile la stampa della nota spese.
Se si tenta di richiedere l’approvazione senza avere inserito alcuna spesa all’interno della nota, appare
un messaggio di errore che avvisa l’utente che non è possibile richiedere l’approvazione se non è
presente almeno una spesa.
Viene riportata nell’immagine di seguito un esempio di nota spese stampata tramite il controllo
reportviewer.
80
Figura 7-4: esempio di stampa della nota spese
7.2.2 CostsheetApprovement
Figura 7-5: Pagina con l’elenco delle note spese da approvare
Questa pagina è accessibile solamente agli utenti appartenenti al gruppo NS_Approvers. Lo scopo di
questa pagina è fornire la possibilità agli utenti approvatori di selezionare le note spese dei dipendenti e
81
approvarle o rifiutarle in base ai requisiti di approvazione. La pagina si presenta in questo modo: in alto
trova spazio un insieme di campi che vengono utilizzati come criteri di ricerca per filtrare le note spese
dei dipendenti. Il primo filtro che si può applicare ai dati è la data: si può, infatti, scegliere il mese e
l’anno per cui analizzare le note spese. Il secondo filtro si riferisce alla risorsa, perciò si possono
visualizzare tutte le note spese di un determinato dipendente. Infine l’ultimo filtro è utilizzato per
filtrare le note spese in base al proprio stato, cioè se visualizzare solo quelle compilate, solo quelle
rifiutate, ecc. Se non viene specificato alcun filtro di ricerca verranno visualizzate tutte le note spese di
tutti i dipendenti.
Più sotto è presente una tabella che elenca tutte le note spese filtrate attraverso i criteri di
ricerca. Vengono visualizzati i seguenti campi:
Anno: anno di compilazione della nota spese;
Mese: mese di compilazione della nota spese;
Nome risorsa: indica il nome della persona che ha compilato la nota spese;
Totale richiesta: indica la somma che è stata richiesta dal dipendente come rimborso spese;
Note: visualizza eventuali note aggiunte o dalla risorsa che ha compilato la nota spese oppure
dall’utente approvatore;
Stato: indica lo stato della nota spese (In Lavorazione, Compilata, Accettata, Rifiutata). Per
indicare lo stato si è fatto ricorso a delle immagini che a colpo d’occhio permettessero di
identificare lo stato di avanzamento della nota spese.
In fondo ad ogni riga sono poi presenti due pulsanti: il primo permette di andare al dettaglio della nota
spese, mentre il secondo permette di stampare la nota spese senza necessariamente dover andare a
visualizzarne i dettagli. In questa tabella sono stati disabilitati tutti i comandi di inserimento,
cancellazione e modifica, quindi non sono presenti né un header né un footer.
82
Figura 7-6: Pagina per l'approvazione della nota spese
Si descrive ora la pagina dei dettagli della nota spese. Anche a questa pagina possono accedere
solamente gli utenti appartenenti al gruppo NS_Approvers. La pagina si presenta in questo modo: in alto
c’è un pulsante che consente di tornare all’elenco delle note spese. Tornando indietro vengono
riproposte le stesse note spese che l’utente aveva filtrato in precedenza. Sotto il pulsante è presente
una tabella in cui sono specificati dei dettagli relativi al mese e all’anno di compilazione della nota spese,
il beneficiario della stessa e il suo stato. Al centro della pagina trova spazio una tabella in cui sono
presenti tutte le spese inserite dalla risorsa, con gli stessi campi che vengono proposti in fase di
compilazione:
Data
Cliente
Commessa
Descrizione
Tipo Spesa
Km
Città
Spesa
Fattura
83
Rappresentanza
Allegato
In fondo ad ogni riga vi è poi un pulsante che consente la modifica della spesa selezionata: questa
funzionalità è stata aggiunta per poter correggere quegli errori che sono magari errori di digitazione,
senza dover ricorrere al rifiuto della nota spese e alla correzione da parte della risorsa interessata.
Naturalmente la possibilità di modificare una spesa è attivata solamente se lo stato della nota spese è
“COMPILATA”. In tutti gli altri casi questo non è possibile.
Nel footer della tabella si trovano gli stessi quattro valori presenti nella tabella di compilazione,
solo che in questo caso il campo totale anticipato è editabile. Gli utenti approvatori sono infatti gli unici
che hanno la possibilità di editare questo campo. Una volta inserito il valore all’interno della casella,
viene aggiornato automaticamente il campo totale a pagare, che si ricorda essere la somma del
rimborso spese e del rimborso chilometrico meno il campo totale anticipato.
Sotto alla tabella delle note spese è presente uno spazio in cui gli utenti approvatori hanno la
possibilità di inserire delle note in commento alla nota spesa in questione. Per esempio possono inserire
la motivazione che ha portato al rifiuto della nota spese. Questo campo sarà poi visualizzato anche dalla
risorsa che ha compilato la nota spese.
In fondo alla pagina trovano spazio una serie di pulsanti che appaiono in maniera dinamica a
seconda dello status della nota spese. Si analizzano tutti i vari casi:
COMPILATA: i pulsanti disponibili sono Salva, Accetta, Rifiuta, Stampa;
IN LAVORO: è disponibile solo il pulsante Stampa;
ACCETTATA: è disponibile solo il pulsante Stampa;
RIFIUTATA: è disponibile solo il pulsante Stampa;
Si analizza ora il comportamento di ciascun pulsante:
Salva: con questo pulsante è possibile salvare tutte le modifiche apportate alla nota spesa, in
particolare vengono salvate le note inserite dall’approvatore e il totale anticipato.
Accetta: con questo pulsante, oltre a salvare le modifiche apportate alla nota spese, viene
impostato lo stato della nota spese ad “APPROVATA” e quindi non è più modificabile da
nessuno. A questo punto le spese presenti all’interno della nota spese vengono rese disponibili
per la successiva fase di fatturazione al cliente. Alla pressione del pulsante viene inoltre inviata
in automatico una mail alla risorsa che ha compilato la nota spese.
Rifiuta: con questo pulsante, oltre a salvare le modifiche apportate alla nota spese, viene
impostato il suo stato a “RIFIUTATA” e quindi ritorna a disposizione della risorsa che l’ha
84
compilata per eventuali modifiche. Alla pressione del pulsante viene inoltre inviata in
automatico una mail alla risorsa che ha compilato la nota spese.
Stampa: premendo questo pulsante, l’utente viene rindirizzato ad una pagina in cui è presente
un report dal quale è possibile stampare la nota spese, oppure esportarla in formato PDF, Word
o Excel.
7.2.3 BillingOperations
Figura 7-7: Pagina per la fatturazione
Questa pagina è accessibile solamente agli utenti appartenenti al gruppo NS_BillingReaders. Lo scopo di
questa pagina è quello di fornire agli utenti del reparto amministrativo la possibilità di selezionare le
spese da fatturare ai clienti. La pagina si presenta in questo modo: in alto trovano posto una serie di
criteri di ricerca che servono per filtrare le spese in base alla data, al cliente e alla commessa. Alla
pressione del pulsante cerca vengono riempite le tabelle sottostanti. La prima tabella contiene tutte le
spese documentate che corrispondono ai criteri di ricerca selezionati. In particolare vengono presentati i
seguenti campi relativi alle spese:
85
Tipo spesa: rappresenta la tipologia di spesa;
Utente: rappresenta la risorsa che ha sostenuto la spesa;
Data: indica la data in cui è stata sostenuta la spesa;
Descrizione: rappresenta una breve descrizione della spesa sostenuta;
Fattura: indica se per la spesa sostenuta è stata ricevuta una fattura o uno scontrino;
Rappresentanza: indica se la spesa è stata sostenuta per rappresentanza;
Totale: indica l’ammontare della spesa;
Stato: indica lo stato della nota spese a cui appartiene la spesa in questione.
All’inizio di ogni riga è presente una checkbox che permette di selezionare le spese che dovranno poi
essere fatturate ai clienti. Le spese selezionabili sono però solo quelle che sono state accettate o che
sono in fase di approvazione, non quelle rifiutate o in fase di compilazione. Nel footer della tabella sono
presenti due voci:
Da fatturare: rappresenta la somma delle spese che sono state selezionate per la fatturazione;
Complessivo: rappresenta la somma di tutte le spese presenti.
Il valore del campo “Da fatturare” viene aggiornato automaticamente ad ogni nuova selezione di una
spesa.
La seconda tabella contiene tutte le spese chilometriche che corrispondono ai criteri si ricerca
selezionati. In particolare vengono presentati i seguenti campi:
Città di destinazione: rappresenta la città in cui si è recato l’utente per svolgere il proprio lavoro;
Utente: rappresenta il nome della risorsa che ha sostenuto il viaggio;
Sede risorsa: rappresenta la sede della risorsa (Milano o Trieste);
Km: indicano i chilometri che sono fatturabili al cliente;
Coefficiente rimborso: rappresenta il coefficiente di rimborso chilometrico da applicare ai
chilometri percorsi;
Data: indica la data in cui è stato sostenuto il viaggio;
Descrizione: rappresenta una breve descrizione della spesa sostenuta;
Totale: indica l’ammontare della spesa;
Stato: indica lo stato della nota spese a cui appartiene la spesa in questione.
All’inizio di ogni riga è presente un pulsante che permette la modifica della riga selezionata. Infatti, i
chilometri che possono essere fatturati al cliente spesso non corrispondono ai chilometri che ha
sostenuto la risorsa, anche perché entrano in gioco accordi commerciali fra l’azienda e il cliente. Ecco
86
quindi che è nata l’esigenza di fornire agli utenti del settore amministrativo la possibilità di modificare i
chilometri e il coefficiente di rimborso chilometrico. Per procedere con la modifica della riga è possibile
cliccare sull’icona di modifica accanto alla riga di interesse, oppure anche fare doppio click sulla riga: in
questi modi la riga entra in modalità di editing e diventano quindi modificabili i due campi relativi ai
chilometri e al coefficiente di rimborso chilometrico. Per salvare le modifiche effettuate è necessario
fare click sul pulsante “Conferma”, mentre per non salvare basta fare click sul pulsante “Annulla”. Le
modifiche a questi due campi sono abilitate solamente se lo stato della nota spese è diverso da
“Rifiutata”.
All’inizio di ogni riga, affianco al pulsante che abilita la modifica, è presente inoltre una checkbox
che permette di selezionare le spese che dovranno poi essere fatturate ai clienti. Le spese selezionabili
sono però solo quelle che sono state accettate o che sono in fase di approvazione, non quelle rifiutate o
in fase di compilazione. Nel footer della tabella sono presenti due voci:
Da fatturare: rappresenta la somma delle spese che sono state selezionate per la fatturazione;
Complessivo: rappresenta la somma di tutte le spese presenti.
Il valore del campo “Da fatturare” viene aggiornato automaticamente ad ogni nuova selezione di una
spesa.
Sotto questa tabella trovano spazio le azioni disponibili, rappresentate da tre pulsanti:
Sblocca le spese: una volta che le spese sono state selezionate per la fatturazione e sono state
salvate, queste diventano non più modificabili e in tabella appaiono disabilitate e di colore
grigio. È stata però fornita la possibilità di sbloccare le spese già fatturate, in modo tale che i
dipendenti dell’amministrazione possano modificare una fatturazione già eseguita in
precedenza.
Salva: tramite la pressione di questo pulsante vengono salvate le modifiche effettuate, in
particolare vengono salvate le modifiche ai chilometri e alle selezioni.
Report: genera un report delle spese da fatturare al cliente, con la possibilità di stamparlo e di
esportarlo in vari formati, tra cui PDF, Word ed Excel.
Affianco ai pulsanti sono presenti i totali complessivi, somma dei totali delle due tabelle:
Totale da fatturare: rappresenta la somma totale da fatturare al cliente, data dalla somma delle
spese documentate selezionate per la fatturazione e delle spese chilometriche selezionate per
la fatturazione;
Totale complessivo: rappresenta la somma totale delle spese sostenute per un cliente, data
dalla somma di tutte le spese documentate e di tutte le spese chilometriche.
87
Al di sotto di tutto è presente un altro RadGrid in cui sono elencati tutti gli utenti afferenti alla
commessa selezionata che devono ancora compilare la nota spese di uno o più mesi nel periodo
selezionato. Questa tabella è stata introdotta per dare all’amministrazione la possibilità di capire se
nelle altre due tabelle sono presenti tutte le spese da fatturare al cliente o meno.
Nell’immagine di seguito riportata viene rappresentato il report che viene generato in
automatico per la fatturazione delle spese ai clienti.
Figura 7-8: esempio di stampa della fatturazione
88
7.2.4 Report
Figura 7-9: Pagina dei Report
Questa pagina è accessibile solamente agli utenti appartenenti ai gruppi NS_BillingReaders e
NS_Approvers. Lo scopo di questa pagina è quello di fornire agli utenti dell’amministrazione e alla
dirigenza dell’azienda un report contenente tutte le spese rimborsate ai clienti. La pagina si presenta in
questo modo: in alto trova spazio un’ampia area contenente i criteri di ricerca per filtrare i dati. I filtri
possibili sono i seguenti:
Da: indica il periodo di inizio per ricercare i dati;
A: indica la fine del periodo all’interno del quale ricercare i dati;
Risorsa: ricerca le spese sostenute da una particolare risorsa;
Centro di Costo: filtra i risultati della ricerca in base ai diversi centri costo;
Cliente: i risultati vengono filtrati in base al nome del cliente;
Commessa: ricerca le spese appartenenti a una specifica commessa.
Una volta selezionati i criteri di ricerca, tramite il pulsante “Report” viene creato un report contenente
tutte le spese corrispondenti ai criteri cercati. Nell’intestazione del report sono anche riportati i filtri che
89
sono stati applicati ai dati. Alla prima interrogazione, i dati vengono forniti raggruppati: nelle colonne i
dati sono raggruppati prima per anno, poi per mese ed infine per tipo di spesa; nelle righe i dati sono
invece raggruppati prima per centro di costo, poi per sede ed infine per risorsa. Successivamente è poi
possibile espandere i dati per visualizzare i dettagli di ogni singola voce. Comunque alla fine di ogni riga
e di ogni colonna c’è il totale complessivo.
Nella figura di seguito è rappresentato un esempio di una stampa del report.
Figura 7-10: esempio di stampa del report
90
7.2.5 Booking
Figura 7-11: Pagina con l'elenco delle prenotazioni
Questa pagina è accessibile solamente agli utenti appartenenti al gruppo BookingCreators. Scopo di
questa pagina è inserire le prenotazioni all’interno dell’applicativo. Si ricorda che le prenotazioni
possono scaturire su richiesta dei dipendenti, che ne invieranno domanda tramite mail o telefonata. La
pagina si presenta in questo modo: in alto ci sono due combobox che sono state inserite per selezionare
l’anno e il mese di riferimento della prenotazione. Da un menu a tendina si può quindi scegliere l’anno e
il mese per i quali si intende inserire la prenotazione. Si ricorda che è possibile inserire prenotazioni
solamente per il mese corrente e per i mesi successivi a quello corrente. Una volta selezionati il mese e
l’anno di interesse vengono caricate automaticamente nella tabella sottostante tutte le prenotazioni
precedentemente inserite. La tabella consente di visualizzare tutte le prenotazioni inserite, ma permette
anche di aggiungerne di nuove, modificare o cancellare quelle presenti.
91
Figura 7-12: Inserimento di una nuova prenotazione
Per aggiungere una nuova prenotazione è necessario fare click sul pulsante “Aggiungi nuova
prenotazione” posto nell’header della tabella. Alla pressione del tasto si apre un form all’interno della
tabella stessa dove è necessario inserire i seguenti valori:
Risorsa: nome del dipendente dell’azienda per il quale si sta effettuando la prenotazione. La
sua selezione avviene tramite una combobox.
Cliente: rappresenta il cliente al quale saranno poi addebitati i soldi della prenotazione. La sua
selezione avviene tramite una combobox.
Commessa: rappresenta la commessa associata al cliente. La sua selezione avviene tramite
una combobox.
Tipo di prenotazione: indica quale tipo di prenotazione si sta inserendo. La sua selezione
avviene tramite una combobox. Si ricorda che i tipi di prenotazioni disponibili sono i seguenti:
o Albergo;
o Navetta;
o Aereo;
o Treno;
92
o Automobile.
Data partenza: indica la data di partenza o comunque la data di inizio di fruizione del bene.
Questa data è selezionabile attraverso un apposito pulsante attraverso il quale è possibile
scegliere un giorno specifico direttamente da un calendario che si apre in una finestra popup.
Data ritorno: indica la data di ritorno o comunque la data di fine di fruizione del bene. Questa
data è selezionabile attraverso un apposito pulsante attraverso il quale è possibile scegliere un
giorno specifico direttamente da un calendario che si apre in una finestra popup.
Città di partenza: indica la città dalla quale si parte; naturalmente questo campo non è da
inserire nel caso in cui si stia effettuando la prenotazione per un albergo;
Città di destinazione: indica la città di arrivo;
Fornitore del servizio: indica il nome dell’azienda che fornisce il servizio, che può essere un
albergo, una compagnia aerea, ecc. La sua selezione avviene tramite una combobox.
Prezzo: rappresenta il costo totale della prenotazione.
Tipo richiesta: in questo campo, tramite una combobox, è possibile scegliere l’origine della
richiesta tra tre valori:
o telefonata
o email
o a voce
Data richiesta: in questo campo, tramite un calendario popup, è possibile scegliere il giorno
preciso in cui è pervenuta la richiesta della prenotazione.
Penale: è costituita da una checkbox per indicare se per la tipologia di prenotazione inserita è
previsto o meno il pagamento di una penale in caso di modifica o cancellazione della
prenotazione.
Descrizione: piccola descrizione della prenotazione.
93
Figura 7-13: Aggiunta di un nuovo fornitore
Un particolare da sottolineare è la presenza di un pulsante affianco alla combobox per la selezione del
fornitore: tramite questo pulsante è infatti possibile aggiungere un nuovo fornitore all’interno del
database. Alla sua pressione comparirà infatti una finestra popup all’interno della quale è possibile
inserire il nuovo fornitore, in particolare sono da aggiungere i seguenti dati:
Ragione Sociale: rappresenta il nome della società per esteso;
Indirizzo: rappresenta l’indirizzo del fornitore;
Città: rappresenta la città sede del fornitore;
Telefono: indica il numero di telefono di riferimento della società;
Email: rappresenta la mail di riferimento della società che fornisce il servizio.
Una volta che il nuovo fornitore è stato salvato, esso compare all’interno della combobox, disponibile
per la selezione. Per inserire la nuova prenotazione è infine necessario fare click sul pulsante “Inserisci”,
mentre se non si vogliono salvare i cambiamenti, sarà sufficiente fare click sul pulsante “Cancella”.
Per modificare una prenotazione precedentemente inserita è necessario fare click sul pulsante
modifica posto all’inizio di ogni riga: in questo modo la riga entrerà in modalità di editing e sarà possibile
94
modificarne i valori inseriti. Una volta fatte le modifiche necessarie, queste potranno essere salvate
tramite il pulsante “Aggiorna”, oppure scartate tramite il pulsante “Cancella”.
Per cancellare una prenotazione precedentemente inserita è sufficiente fare click sul pulsante
“Cancella” posto alla fine di ogni riga. Si apre così una finestra di conferma: se si preme “Ok” la
prenotazione sarà definitivamente cancellata, se si preme “Cancel” non si effettua alcuna modifica.
Prima di poter salvare una nuova prenotazione o comunque prima di poter salvare le modifiche
a una prenotazione esistente vengono eseguiti dei controlli sulla validità dei dati inseriti. Nella figura
sottostante viene mostrato il caso in cui si tenti di salvare una prenotazione con tutti i campi vuoti.
Figura 7-14: Errore in fase di inserimento
95
7.2.6 Configuration
Tramite questa pagina è possibile configurare alcuni parametri necessari al corretto funzionamento del
programma, in particolare si possono specificare:
Coefficiente di rimborso chilometrico: questo valore viene aggiornato ogni anno in base al costo
della benzina;
Email dell’approvatore: tramite questo campo è possibile specificare l’email dell’utente
approvatore;
Email dell’applicativo: tramite questo campo è possibile specificare l’email con la quale verranno
effettuate tutte le comunicazioni all’interno dell’applicativo.
96
8 Conclusioni
Quanto trattato lungo questa tesi è il frutto di un’attività svolta nell’arco di sei mesi. Parte del periodo
iniziale è stata spesa nell’apprendimento delle nuove tecnologie e del nuovo ambiente di lavoro, parte
alla conoscenza approfondita del problema, alla sua analisi e allo studio di possibili soluzioni.
Nel complesso, gli obiettivi prefissati a inizio attività sono stati raggiunti. Infatti, si è realizzato un
applicativo in grado di gestire le note spese e le prenotazioni dei dipendenti, ma soprattutto è stato
sviluppato un programma che ha semplificato il processo aziendale, permettendo una gestione più
accurata e anche un risparmio in termini economici. L’interfaccia grafica finale poi, essendo stata
sviluppata fianco a fianco con coloro che poi andranno ad utilizzare realmente l’applicativo, è risultata
fin da subito di facile comprensione ed utilizzo. I possibili sviluppi futuri vanno sicuramente nella
direzione di una maggiore integrazione fra l’applicativo e SharePoint, magari con il salvataggio dei
documenti all’interno del portale. Poi sarà necessario estendere l’applicazione al di fuori della intranet
aziendale, in modo da permettere anche ai consulenti esterni di poter compilare le note spese.
Attualmente la parte dell’applicativo relativa alla gestione delle note spese è in produzione, quindi i
dipendenti dell’azienda inizieranno a compilare le note spese con il nuovo applicativo nel mese di
marzo. Per i mesi di gennaio e di febbraio di quest’anno ci sarà una persona incaricata di inserire i dati
dai fogli Excel direttamente nell’applicativo, in modo da poter gestire tutto l’anno fiscale. La parte
invece relativa alla gestione delle prenotazioni è ancora in fase di test e si prevede che entrerà in
produzione entro il mese di aprile.
Svolgere quest’attività all’interno di un’azienda mi ha permesso di entrare in contatto con il mondo del
lavoro, imparare un metodo e una procedura di lavoro standard, conoscere quali sono i problemi del
mondo reale, confrontarmi anche con l’utente finale che è sempre difficile da accontentare. In generale
sono molto soddisfatto dell’esperienza svolta in Teorema, sicuramente mi sento di consigliarla a
chiunque debba svolgere una tesi.
97
Bibliografia
[1] Fundamentals of Windows Server 2008 Active Directory – Official Microsoft Learning Product.
[2] Implementing Microsoft Office SharePoint Server 2007 – Microsoft.
[3] Maintaining Microsoft SQL Server 2008 Database - Trainer Manual.
[4] Configuring and Administering Microsoft SharePoint 2010 – Microsoft.
[5] M. Fermeglia. Corso di complementi di basi di dati.
[6] Microsoft Technet. http://technet.microsoft.com.
[7] Supporto tecnico Microsoft. http://support.microsoft.com.
98
Ringraziamenti
Il primo ringraziamento che mi sento di fare va all’azienda Teorema, ai suoi dipendenti e soprattutto alle
persone che mi hanno personalmente seguito in questo lavoro, dedicandomi parte del loro tempo
prezioso. Voglio nominare in particolare le persone che mi sono state vicino: Andrea, che mi ha seguito
passo passo nella fase di formazione rispondendo sempre con grande disponibilità alle mie domande,
Fabrizio, che è stato il mio primo project manager e mi ha seguito nella fase di realizzazione
dell’applicativo, e infine Luca ed Enrico grazie ai quali le giornate sono trascorse più allegramente.
Come non dimenticare poi Walter, amico e compagno d’avventura nel tirocinio presso Teorema. A lui va
un sincero grazie per tutti i consigli che è riuscito a darmi e per il bel periodo trascorso insieme, fra
lavoro e svago.
Un grosso ringraziamento va ai miei amici, vecchi e nuovi, soprattutto quelli che in questo ultimo
periodo mi sono stati accanto, anche semplicemente con la loro presenza fisica, dimostrandosi delle
persone su cui ho potuto, posso e potrò sempre contare.
Un grazie a tutti i compagni dell’università, con i quali ho vissuto intensamente un'esperienza che
segnerà il resto della mia vita.
Un ringraziamento doveroso è da rivolgersi anche al professor Fermeglia, resosi sempre molto
disponibile per ogni tipo di chiarimento, lasciando allo stesso tempo grande libertà nello svolgimento
dell’elaborato.
Un ringraziamento particolare va poi a mia sorella, che mi ha sempre supportato durante tutta la fase di
tirocinio, incoraggiandomi nei momenti più difficili e lodandomi quando le cose andavano meglio.
Naturalmente il ringraziamento più grande va ai miei genitori, sempre un punto di riferimento nella mia
vita e sempre pronti a offrirmi tutto il loro supporto incondizionatamente. Grazie di tutto.
