1. 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 RELATORE
Enrico Natella Chiar.mo Prof. Maurizio Fermeglia
Anno Accademico 2009/2010

3. Ai miei genitori

5. 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
i

6. 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
ii

7. 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
iii

8. 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
1

9. 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.
2

10. 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.
3

11. 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
4

12. 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
5

13. 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
6

14. 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
7

15. 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.
8

16. 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.
9

17. 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.
10

18. 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.
11

19. 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.
12

20. 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
13

21. 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
14

22.  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 Spese
dipendente in un determinato periodo (solitamente un
mese)
15

23. Spesa Somma anticipata da un cliente per la quale si richiede un Nota spese, Cliente,
rimborso Commessa, Risorsa
Cliente Figura alla quale si è offerto il proprio servizio Commessa, Risorsa
Commessa Progetto associato al cliente per il quale vengono sostenute Cliente, Risorsa
le spese
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 Risorsa
particolare si individuano: Commerciale, Produzione,
Direttivo e Struttura
16

24. 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.
17

25.  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
18

26. 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
19

27. 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
20

28. 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
21

29. 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.
22

30. Costsheet CostsheetTrack ExpenseType BookingTrack RequestSource
ID ID ID ID ID
M onth IdC ostsheet Description IdU ser Name
Year Date M axA mount IdBooking Description
IdU ser IdE xpenseTy pe P repaid IdC ustomer
IdS tatus A mount Booking IdC ommessa
N ote Km IdBookingTy pe
TotalA dv ance DestinationC ity S tartBookingDate
Supplier
N oC osts N ote E ndBookingDate
ID
N oBilling P repaid RequestDate
RagioneS ociale
C reateBy IdC ustomer DepartureC ity
A ddress
C reateDate IdC ommessa Booking A rriv alC ity
C ity
A pprov alDate KmF orBilling ID A mount
Telephone
KmRefoundRateF orBilling M onth Description
Email
A mountTripF orBilling Year N ote
Status TicketN umber C losed E xistP enal
ID Billing C reateBy P enal
C ode IsE ntertainmentE xpense C reateDate IdA ttachment
Description IsBill IdS upplier BookingType
C ancelDate ID
IdRequestS ource Description
C ompany C arA v ailable
LicenseP late
Figura 3-1: Gestione Nota Spese
PROGETTI RISORSE CLIENTI
ID ID ID
IDCliente Alias Ragione
Progetto Sede Note
Descrizione Nome_Risorsa IDAM
Disable IDTipoRisorsa CRMRef
CodiceProgetto IDGruppo GUID
ProgettoAM Telefono
IDPM Cellulare
IDCategoria Fax
IDAzienda Mail
GUID MailCLiente
IDResponsabile
AllowTracking
Disable
AllowInsertRecupero
IDProfilo
TIPICOMMESSA COMMESSE
IDAzienda
IDTipoCommessa ID
GUID
Descrizione IDProgetto
MonteOre Commessa
PrevedeDataChiusura Descrizione
UnitaMisura CodiceCommessa
OrdineFatturazione CommessaAM
RISORSE_COMMESSE
Fatturabile Disable
ID
GiornateVendute
IDRisorsa
IDTipoCommessa
IDCommessa
DataChiusura
DataInizio
GUID
Figura 3-2: Tracciamento ore lavorative
23

31. 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, Viene attivato dopo l’inserimento o
UPDATE 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, Viene attivato dopo l’inserimento o
UPDATE 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, Viene attivato dopo l’inserimento o
UPDATE 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:
24

32.  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 Restituisce le note spese
@Year int (costsheet) di una certa risorsa
@IdUser uniqueidentifier in un certo mese e in un certo
anno.
Costsheet_IsApproved @ID uniqueidentifier Verifica se lo stato di una nota
@IsApproved bit OUTPUT spese è approvato
CostsheetTrack_GetByIdCostsheet_Joined @IdCostsheet Estrae i dati del
uniqueidentifier 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 Aggiorna i campi del
text costsheettrack tramite file
xml.
GetUsersWhoHaveToCompile_ForVAPP @Month_From int Restituisce l'elenco delle note
@Year_From int spesa (per mese ed anno) non
@Month_To int ancora compilate
@Year_To int appartenenti ad utenti
@IDCustomer afferenti la commessa
uniqueidentifier selezionata.
@IDCommessa
uniqueidentifier
Costsheet_ResetStatus @IdUser uniqueidentifier Resetta lo stato di una nota
@Year int spese imposta i campi
@Month int [IdStatus] a TOCOMPILE ed
[ApprovedBy] e
[ApprovalDate] a NULL.
Tabella 3-11: Stored Procedures
25

33. 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.
26

34. 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.
27

35.  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.
28

36. 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
29

37. 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.
30

38. 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.
31

39. 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.
32

40. 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, è
33