Studio e realizzazione di un sistema web per il monitoraggio delle previsioni di budget in processi aziendali di controllo di gestione

UNIVERSITÀ DEGLI STUDI DI TRIESTE
DIPARTIMENTO DI MATEMATICA E GEOSCIENZE
Corso di Laurea Magistrale in Informatica
curriculum Ingegneria Informatica
Studio e realizzazione di un sistema web per il
monitoraggio delle previsioni di budget in processi
aziendali di controllo di gestione
Anno Accademico 2012/2013
LAUREANDO
Francesco Polita
RELATORE
Prof. Alberto Bartoli
CORRELATORE
Dott. Dario Sottana

iv
Indice
INTRODUZIONE................................................................................................................. 1
1 ANALISI DEI REQUISITI ............................................................................................... 3
1.1 Introduzione........................................................................................................................................3
1.2 Descrizione generale del sistema.........................................................................................................3
1.3 Definizioni ...........................................................................................................................................3
1.4 Vincoli e prerequisiti............................................................................................................................4
1.4.1 Vincoli di progetto ................................................................................................................................. 4
1.4.2 Prerequisiti ............................................................................................................................................ 5
1.5 Contesto..............................................................................................................................................5
1.5.1 Scenario di riferimento.......................................................................................................................... 5
1.5.2 Monitoraggio dell’allineamento............................................................................................................ 6
1.5.3 Collocamento del software.................................................................................................................... 6
1.6 Criticità/Rischi ................................................................................................................................... 10
1.7 Requisiti funzionali ............................................................................................................................ 11
1.7.1 [UR_DOC] Documentazione di processo ............................................................................................. 11
1.7.2 [UR_FC] Gestione Forecast.................................................................................................................. 11
1.7.3 [UR_ROLE] Ruoli ed attori di processo ................................................................................................ 12
1.7.4 [UR_REP] Report.................................................................................................................................. 13
1.8 Modello dei casi d’uso ....................................................................................................................... 13
1.8.1 Premessa ............................................................................................................................................. 13
1.8.2 Attori.................................................................................................................................................... 13
1.8.3 Diagrammi dei casi d’uso..................................................................................................................... 13
1.8.4 Specifica dei casi d’uso ........................................................................................................................ 16
1.8.5 Diagrammi delle attività ...................................................................................................................... 18
1.9 Altri requisiti (non funzionali)............................................................................................................ 22
1.9.1 [UR_SUP] Supportabilità...................................................................................................................... 22
1.9.2 [UR_USA] Usabilità .............................................................................................................................. 22
1.9.3 [UR_AFF] Affidabilità ........................................................................................................................... 23
1.10 Requisiti della base di dati................................................................................................................. 23
2 PROGETTAZIONE...................................................................................................... 25
2.1 Progettazione concettuale................................................................................................................. 25
2.1.1 Analisi delle entità: attributi e chiavi primarie .................................................................................... 26
2.1.2 Analisi delle associazioni: descrizione, rapporto di cardinalità e attributi .......................................... 27

v
2.2 Progettazione logica .......................................................................................................................... 29
2.2.1 Ristrutturazione dello schema E-R....................................................................................................... 29
2.2.2 Schema logico relazionale ................................................................................................................... 30
2.3 Architettura del software .................................................................................................................. 37
2.3.1 Introduzione: architetture a tre livelli ................................................................................................. 37
2.3.2 ASP.NET MVC....................................................................................................................................... 37
2.3.3 Composizione delle architetture ......................................................................................................... 38
2.4 Progettazione interfaccia grafica ....................................................................................................... 39
2.5 Valutazione del template grafico....................................................................................................... 44
3 IMPLEMENTAZIONE ................................................................................................. 45
3.1 Autenticazione e recupero di informazioni su Active Directory ......................................................... 45
3.1.1 Architettura delle ricerche su Active Directory ................................................................................... 46
3.1.2 Modulo sviluppato............................................................................................................................... 47
3.2 Estrazione di dati da fogli di calcolo con OpenXML............................................................................ 48
3.2.1 Office Open XML.................................................................................................................................. 48
3.2.2 SpreadsheetML.................................................................................................................................... 49
3.2.3 OpenXML SDK...................................................................................................................................... 51
3.3 Report mediante le librerie Kendo UI ................................................................................................ 54
3.3.1 Esempio: AutoComplete widget.......................................................................................................... 54
3.3.3 Premessa ............................................................................................................................................. 55
3.3.4 Grid widget .......................................................................................................................................... 56
3.3.5 Chart widget ........................................................................................................................................ 58
3.4 Considerazioni................................................................................................................................... 59
3.5 Interfaccia prodotto finale................................................................................................................. 59
3.5.1 Presentazione user interface attraverso un caso di utilizzo................................................................ 59
3.5.2 Funzionalità non disponibili................................................................................................................. 67
3.5.3 Valutazione responsività ..................................................................................................................... 67
4 CONCLUSIONI .......................................................................................................... 73
4.1 Obiettivi ............................................................................................................................................ 73
4.2 Sviluppi futuri.................................................................................................................................... 73
4.3 Opinioni personali ............................................................................................................................. 74
4.4 Stato attuale...................................................................................................................................... 74
5 BIBLIOGRAFIA.......................................................................................................... 75

1
Introduzione
“In un'azienda, il controllo di gestione è quell’insieme di attività volte a guidare la gestione verso il
conseguimento degli obiettivi stabiliti in sede di pianificazione operativa, rilevando lo scostamento tra
obiettivi pianificati e risultati conseguiti e informando di tali scostamenti gli organi responsabili,
affinché possano attuare le opportune azioni correttive.”1
Il monitoraggio dell’andamento economico finanziario di un’azienda ha cadenza tipicamente mensile
e si esplica in elaborati detti report. Si tratta di collezioni di dati, generalmente esposti in formato
tabellare, in cui vengono messi a confronto dati economici, patrimoniali e finanziari a preventivo e a
consuntivo.
Il problema analizzato durante il lavoro di tesi concerne la metodologia adottata nell’elaborazione
dei report e la sequenza di attività che compongono il processo di monitoraggio presso l’azienda in
cui è stato sviluppato il progetto.
In particolare, sono stati riscontrati i seguenti punti deboli.
 L’attività di raccolta ed elaborazione di dati aziendali viene svolta manualmente, attraverso
una sequenza di operazioni copia/incolla su fogli di calcolo.
 Non sussiste alcuna forma di archiviazione strutturata delle informazioni.
 L’intero processo richiede la trasmissione di una considerevole quantità di messaggi di posta
elettronica contenenti dati sensibili.
L’obiettivo di questo lavoro è progettare e realizzare un prototipo software che gestisca l’inserimento
dei dati raccolti al fine di trasformarli in informazioni utili all’azienda:
 classificando tali dati secondo specifici orizzonti temporali e divisioni aziendali;
 rendendo persistenti tali dati con l’ausilio di un DBMS;
 elaborando e presentando report utili ai fini del processo di monitoraggio.
L’esigenza di creare tale prototipo è nata dal fatto che al momento l’azienda non dispone di uno
strumento software che realizzi le funzionalità sopra indicate; risulterebbe quindi utile
sperimentarne l’adozione. Infatti, oltre agli evidenti benefici che si trarrebbero evitando
l’elaborazione manuale dei fogli di calcolo, l’introduzione di un applicativo accessibile via web
favorirebbe la centralizzazione dell’intero processo, strutturando e rendendo maggiormente
efficiente lo scenario attuale.
Tali miglioramenti deriverebbero dalla riduzione del numero di operazioni che compongono il
processo, dall’abbandono della trasmissione di dati aziendali via posta elettronica e dall’archiviazione
strutturata e sistematica dei dati registrati.
Il lavoro di tesi è stato svolto presso Cluster Reply S.r.l., società del gruppo Reply S.p.A., nelle sedi di
Silea e di Trieste.
La realizzazione del prototipo in oggetto ha previsto lo studio e l’utilizzo di diverse tecnologie legate
allo sviluppo web, si citano le più rilevanti:
 HTML5, CSS3 e javaScript nello sviluppo della parte front-end;
1
http://it.wikipedia.org/wiki/Controllo_di_gestione

2
 ASP.NET (linguaggio C#) nello sviluppo della parte back-end, e come Framework di
riferimento;
 MVC come pattern architetturale;
 Active Directory nell’autenticazione degli utenti;
 SQL Server nella gestione della base di dati;
 alcune librerie di supporto tra cui OpenXML SDK, Bootstrap e Kendo UI.
Si riporta di seguito una breve descrizione dei capitoli in cui è articolata la tesi.
Il primo capitolo contiene l’analisi dei requisiti del sistema. Offre una prima descrizione dello
strumento in questione, menzionando i vincoli di progetto ai quali ci si è attenuti, per poi addentrarsi
nell’illustrazione del contesto di collocamento del software. Infine, viene presentata la lista dei
requisiti raccolti, focalizzando l’attenzione sul modello dei casi d’uso.
Il secondo capitolo descrive la fase di progettazione del sistema. In primis, viene riportata la
progettazione della base di dati che si conclude con la presentazione dello schema logico relazionale
ottenuto. Viene quindi trattata l’architettura del software e la progettazione dell’interfaccia grafica.
Il terzo capitolo riporta l’implementazione dei principali moduli che compongono il sistema finale e a
seguire l’esposizione dell’interfaccia utente.
Nel quarto capitolo, infine, si delineano le conclusioni del lavoro svolto, valutando quanto realizzato
sulla base degli obiettivi di progetto.

3
1 Analisi dei requisiti
1.1 Introduzione
Il capitolo “Analisi dei requisiti” presenta una precisa analisi del sistema in oggetto.
Tale analisi è funzionale a stabilire che cosa il sistema deve fare e quali servizi deve fornire sulla base
dei bisogni espressi dal committente. Le decisioni sul come deve realizzare tutto ciò, sono rimandate
al capitolo di progettazione del sistema.
La raccolta dei requisiti ha avuto luogo tramite una serie di interviste rivolte al mio tutor aziendale e
al personale amministrativo di Cluster Reply i quali, rappresentando i destinatari del sistema,
svolgono il ruolo di committente.
Il capitolo si apre con una generica descrizione del sistema e del contesto in cui si troverà ad operare
scendendo poi nel dettaglio dell’analisi dei requisiti che il prodotto finale deve soddisfare.
Si consideri che l’approccio seguito per lo sviluppo del software è di tipo prototipale, quindi nuovi
requisiti potranno essere introdotti successivamente, oltre a tutti i vincoli che fino a questo
momento non sono ancora stati individuati.
1.2 Descrizione generale del sistema
Il sistema, indicato nel seguito come software o applicativo, prevede mediante il suo uso,
l’inserimento e la consultazione di dati aziendali via web. Tali dati, verranno resi persistenti con
l’ausilio di una base di dati e, prima di essere presentati all’utente, saranno oggetto di elaborazioni
matematiche indicate dal committente.
L’utente accederà al sistema attraverso un qualsiasi dispositivo che disponga di un browser web e
che sia connesso alla rete Internet. Effettuato l’accesso, potrà avvalersi delle funzionalità messe a
disposizione dall’applicativo semplicemente muovendo il cursore del mouse e “cliccando” nelle
apposite aree2
.
In prima approsimazione, le funzionalità messe a disposizione dell’utente riguardano:
 l’inserimento di dati aziendali;
 la consultazione di report derivanti dall’elaborazione dei dati inseriti;
 il filtraggio delle informazioni visualizzate in base a specifici criteri.
1.3 Definizioni
 Utente (User): la persona, o le persone, che operano o interagiscono direttamente con
l’applicativo.
 Committente (Customer): la persona, o le persone, che acquistano il prodotto e di solito (ma
non necessariamente) decidono i requisiti. Nel contesto di questa prassi raccomandata il
committente e il fornitore possono essere membri della stessa organizzazione.
 SFA (Sales Force Automation): l'acronimo SFA fa riferimento ad un software aziendale di
supporto alle vendite. Il sistema SFA provvede alla comunicazione tra venditore e centrale
operativa, programma e controlla l’azione dei venditori, li assiste nella messa a punto di un
2
Ovviamente se il dispositivo in questione è un dispositivo mobile il click del mouse (o del trackpad/touchpad)
sarà sostituito dal tap del dito sullo schermo.

4
piano di vendita o di promozione di un determinato prodotto. Assiste inoltre la raccolta degli
ordini dei clienti evitando movimentazione cartacea, riducendo la possibilità d'errore umano
e velocizzando l'arrivo dei dati relativi agli ordini nella sede centrale.
 Budget: Strumento contabile di tipo preventivo; lo scopo del budget è quello di confrontare i
dati preventivi con i dati consuntivi. Il budget si struttura su base annuale, ma viene diviso su
periodi di tempo più brevi, nel caso in questione, viene monitorato e aggiornato
mensilmente. Alla fine del mese si confronta il dato di budget con il risultato effettivo, se si
riscontrano scostamenti possono essere adottate contromisure volte al miglioramento delle
condizioni.
 GeCo (Gestione Commesse): è un applicativo per la gestione e il controllo delle commesse.
Lo scopo principale di GeCo è fornire un ambiente formale per la gestione e il controllo delle
singole attività legate alla realizzazione di progetti o di consulenza. Consente ai capi progetto
e a tutte le risorse aziendali coinvolte di monitorare e avere sotto controllo tutte le fasi di
avanzamento e sviluppo delle commesse, l’evoluzione dei progetti, con relativi calcoli e
consuntivi rispetto alle specifiche iniziali, dei gruppi di lavoro e della produzione.
1.4 Vincoli e prerequisiti
1.4.1 Vincoli di progetto
1.4.1.1 Tecnologie software
Per quanto concerne l’ambiente di sviluppo l’azienda ha posto i seguenti vincoli:
 ambiente Microsoft .NET Framework (versione 4), avvalendosi del design pattern Model-
View-Controller (MVC) e del linguaggio di programmazione C Sharp (C#);
 DBMS di supporto alla base di dati Microsoft SQL Server 2008 R2.
Mentre per quel che riguarda l’ambiente di lavoro:
 sistema operativo Microsoft Windows Server 2008 R2 virtualizzato;
 IDE
3
Microsoft Visual Studio 2012 Professional.
1.4.1.2 Autenticazione
Si assume come vincolo di progetto che il parco di utenze che possono essere abilitate all'accesso
siano quelle disponibili all'interno del directory service Microsoft Active Directory e precisamente
appartenenti al dominio REPLYNET. Ciò significa che un utente che non può essere autenticato su
tale servizio non potrà accedere all’applicativo.
In particolare, gli scenari che possono presentarsi sono tre:
 l'utente accede all'applicativo attraverso un web browser installato su sistema operativo
Microsoft Windows nel quale ha già ha effettuato il log-in con le proprie credenziali di
dominio;
diverso da Microsoft Windows;
3
Si tratta di un software di supporto ai programmatori in fase di sviluppo del codice sorgente di un programma.
Per maggiori informazioni visitare http://en.wikipedia.org/wiki/Integrated_development_environment.

5
Microsoft Windows, ma l’utenza con la quale ha effettuato l’accesso non corrisponde ad un
utenza nel domino REPLYNET.
Nel primo caso, l'applicativo verificherà, in background, che le credenziali inserite nel dispositivo in
uso identifichino l'utente su Active Directory, effettuerà quindi l’operazione che prende il nome di
Windows Authentication.
Nei restanti casi, il browser restituirà all’utente un form nel quale inserire le proprie credenziali. Tali
credenziali, verranno poi verificate su Active Directory con la stesso protocollo previsto dalla
Windows Authentication (NTLM o Kerberos).
1.4.1.3 Autorizzazione
L’autenticazione dell’utente dovrà essere seguita dalla fase di autorizzazione. Ciò consentirà al
sistema di determinare quali funzionalità e quali informazioni rendere disponibili all’utente.
1.4.1.4 Raggiungibilità
L'applicativo deve essere raggiungibile via web.
1.4.2 Prerequisiti
1.4.2.1 Fruibilità
L'applicativo deve essere fruibile con i più comuni browser di ultima generazione (Internet Explorer
dalla versione 8.0 in poi), compresi i browser mobile.
1.5 Contesto
1.5.1 Scenario di riferimento
Cluster Reply è una S.r.l. suddivisa in più Business Unit (BU), in ogni BU vi è un reparto Management
all'interno del quale compaiono diversi profili di Manager organizzati secondo una scala gerarchica
che parte dal "Senior Consultant" e raggiunge l'apice con il "Partner". Ogni Manager ha il compito di
individuare nuovi clienti, offrire soluzioni, censire nuove opportunità di business, cercando di
allinearsi con gli obiettivi di budget fissati a inizio anno.
FIGURA 1 – SCHEMA STRUTTURA CLUSTER REPLY
Ogni trattativa viene inizialmente delineata con l'ausilio del sistema informatico SFA, ciò permette di
tener traccia di tutte le opportunità procurate da un Manager in un determinato periodo. Nel

6
tracciare una nuova opportunità, il Manager assegna una percentuale di fiducia alla stessa; tale
parametro, detto Confidence, indica la probabilità di accettazione della trattativa in corso da parte
del cliente.
Quando una commessa viene confermata dal cliente, la trattativa viene portata nel sistema GeCo,
dove vengono raccolte informazioni più dettagliate riguardo a commessa e cliente.
I dati registrati nel sistema GeCo vengono verificati e validati ogni mese in sede di Controllo di
Gestione dal management di Cluster Reply.
Nel foglio di calcolo (denominato CoGe) aggiornato mensilmente dall'amministrazione centrale (o da
un Partner) vengono affiancate le commesse confermate e le opportunità aperte, pesate con il
proprio grado di fiducia.
Dall'unione dei dati contenuti in CoGe e SFA emerge un nuovo foglio di calcolo (denominato
Allineamento SFA-CoGe) con finalità reportistica, utilizzato per misurare i risultati ottenuti e rilevare
se gli obiettivi parziali4
assegnati siano stati effettivamente raggiunti da ogni BU. Mappando tali
report su tutte le BU si ottiene un documento, che prende il nome di Forecast Report, il cui scopo è
fornire una visione globale sull’andamento dell’azienda.
Tale documento, permette di fare un confronto sull’allineamento tra i dati tracciati da entrambi i
sistemi, SFA e CoGe. I dati raccolti durante questo processo, che prende il nome di “allineamento SFA
CoGe”, vengono analizzati per evidenziare il trend sulle trattative economiche per ogni BU al fine di
assicurare la coerenza con gli obiettivi di budget.
1.5.2 Monitoraggio dell’allineamento
Lo scenario appena descritto richiede un monitoraggio periodico di quanto contenuto nel foglio di
calcolo “allineamento SFA CoGe”, al fine di verificare che quanto tracciato nei sistemi SFA sia in linea
con quanto dichiarato nel documento CoGe. I manager di ogni BU, allo scadere di ogni forecast5
, si
preoccuperanno di aggiornare correttamente le opportunità tracciate nei sistemi SFA. Tale
aggiornamento può riguardare diversi fattori, per citarne alcuni:
 le percentuali di fiducia associate alle opportunità;
 le date di chiusura delle trattative;
 il valore economico associato alle trattative;
 il ritardo sul tracciamento di una nuova opportunità.
A modifiche avvenute, viene prodotto un nuovo foglio CoGe, che verrà utilizzato nell’elaborazione
dei “Forecast report”.
1.5.3 Collocamento del software
In questo contesto, il software da sviluppare si propone di rilevare e confrontare i dati provenienti da
CoGe e SFA per realizzare quella funzionalità di reportistica attualmente ricoperta dai documenti
Allineamento SFA-CoGe e Forecast report. Ad oggi, tale operazione viene svolta manualmente,
4
Con obiettivi parziali si vuole fare riferimento alla ripartizione su scala mensile degli obiettivi fissati a inizio
anno.
5
Sono i forecast infatti a scandire l’attività di controllo e, sebbene la durata di ogni Forecast sia tipicamente di
un mese, non è detto che il forecast coincida con inizio e fine del mese in corso.

7
ovvero, i documenti sopracitati vengono costruiti effettuando una serie di operazioni di copia/incolla
su fogli di calcolo, per poi essere inviati via posta elettronica ai Manager di ogni BU.
Lo scopo finale del progetto è quindi strutturare e rendere maggiormente efficiente il processo di
monitoraggio descritto attraverso l’introduzione dello strumento in oggetto.
Risulta evidente che, strutturando e centralizzando il caricamento dei dati e l’elaborazione dei report,
si evitano una discreta quantità di operazioni perlopiù ripetitive e i risultati vengono prodotti in modo
istantaneo. Allo stesso tempo, si assolve al problema del mantenimento di uno storico relativo ai
Forecast precedenti, cosa che oggi non avviene in modo strutturato.
Si riportano di seguito le rappresentazioni grafiche che descrivono lo scenario odierno e l’ipotetico
scenario che si verrebbe a presentare a seguito dell’adozione dell’applicativo.

9
FIGURA 3 - ADOZIONE DEL SISTEMA IN ESAME

10
FIGURA 4 - CONFRONTO TRA I DUE SCENARI
Dopo una prima analisi si evince che le macro funzionalità che si richiedono all’applicativo si possono
riassumere nei punti che seguono.
 Possibilità di importare i file contenenti i dati da analizzare.
 Possibilità di visualizzare opportuni report ricavati dall’elaborazione dei dati caricati.
 Mantenimento di uno storico relativo ai documenti precedentemente caricati e ai report
ottenuti.
In prima approsimazione gli utenti destinati all'uso del sistema sono i seguenti:
 Amministratore di sistema
 Gestore di sistema
 Utente generico, che comprende:
 Partner
 Senior Manager
 Manager
 Senior Consultant
1.6 Criticità/Rischi
Per ragioni di sicurezza il software non interagirà direttamente con i sistemi SFA, ma acquisirà i dati
da fogli di calcolo (in formato .xls) contenenti i dati di interesse per il processo delineato.

11
1.7 Requisiti funzionali
1.7.1 [UR_DOC] Documentazione di processo
1.7.1.1 [UR_DOC_01] Acquisizione della documentazione
Per ogni Forecast aperto l’applicativo deve consentire l’inserimento della documentazione di
processo.
1.7.1.1.1 [UR_DOC_001] Acquisizione foglio di calcolo SFA
Per ogni BU, l’applicativo deve permettere l’upload di un foglio di calcolo in formato .xls contenente
i dati provenienti dai sistemi SFA.
1.7.1.1.2 [UR_DOC_002] Acquisizione foglio di calcolo CoGe
Per ogni BU, l’applicativo deve permettere l’upload del foglio di calcolo CoGe (formato .xls).
1.7.1.1.3 [UR_DOC_003] Sovrascrittura della documentazione
Si richiede, inoltre, la possibilità di sovrascrivere documenti precedentemente caricati. La
sovrascrittura della documentazione deve essere inibita nel caso in cui il Forecast di riferimento sia
stato chiuso (vedi paragrafo 1.7.2.2).
1.7.1.2 [UR_DOC_02] Persistenza della documentazione
Ogni volta che un documento viene caricato nel sistema i dati in esso contenuti devono essere
estratti e trascritti nella base di dati di riferimento.
1.7.1.3 [UR_DOC_03] Denominazioni multiple cliente
Si richiede la possibilità di attribuire una denominazione unica a clienti che su trattative differenti
compaiono con differenti denominazioni.
Se, ad esempio, su SFA comparissero le tre voci “Generali_Doc”, “Generali_Prod”, “TeamGenerali”,
l’applicativo dovrà fornire la possibilità di mappare tali voci nella più generica “GENERALI”.
1.7.2 [UR_FC] Gestione Forecast
1.7.2.1 [UR_FC_01] Apertura nuovo Forecast
L’applicativo deve permettere l’apertura di un nuovo Forecast; la data di apertura deve poter essere
impostata dall’utente. Tale operazione non è concessa nei seguenti casi:
 il forecast precedente non è stato chiuso;
 la data di apertura precede la data di chiusura del forecast precedente.
1.7.2.2 [UR_FC_02] Chiusura Forecast
L’applicativo deve permettere la chiusura del Forecast corrente; la data di chiusura deve poter essere
impostata dall’utente. La chiusura non è concessa nei seguenti casi:
 non sono presenti Forecast aperti;
 la data di chiusura precede la data di apertura del forecast corrente.

12
1.7.3 [UR_ROLE] Ruoli ed attori di processo
L'applicativo deve essere in grado di distinguere differenti ruoli utente sulla base delle credenziali
fornite durante il log-in. Le informazioni e le funzionalità esposte dipenderanno proprio dal ruolo
dell’utente nell’ambito del sistema.
1.7.3.1 [UR_ROLE_01] BU User
Identifica l’utente base del sistema. Fanno riferimento a questo ruolo i tre profili aziendali: “Senior
Manager”, “Manager” e “Senior Consultant”.
1.7.3.2 [UR_ROLE_02] Operator
Identifica l’operatore a livello business del sistema; fa riferimento alla figura aziendale che si occupa
dell’inserimento della documentazione nel sistema, quindi, in prima approsimazione al Partner.
1.7.3.3 [UR_ROLE_03] Administrator
Identifica l’amministratore di sistema. Le funzionalità che lo riguardano sono:
 la gestione dei Forecast (apertura e chiusura)
 la gestione delle utenze (creazione, aggiornamento, cancellazione e blocco);
 la gestione dei ruoli e della relativa mappatura sulle utenze;
 la gestione delle funzionalità e della relativa mappatura su ruoli e utenze;
 la gestione delle denominazioni multiple dei clienti.
La seguente tabella presenta l’associazione Ruoli - Profili aziendali che deve essere adottata di
default dal sistema.
Ruoli
Profili
aziendali
BU User Operator Administrator
Ammistratore
di sistema
X
Gestore di
sistema
X X
Partner X X
Senior
Manager
X
Manager X
Senior
Consultant
X
TABELLA 1 - ASSOCIAZIONE PROFILI AZIENDALI-RUOLI
1.7.3.4 [UR_ROLE_04] Provenienza
L'applicativo deve poter risalire alla BU di provenienza dell’utente sulla base delle credenziali fornite
durante l’accesso all’applicativo.

13
1.7.4 [UR_REP] Report
1.7.4.1 [UR_REP_01] Visualizzazione report allineamento
L'applicativo deve fornire all'utente un report che corrisponda all'attuale documento Allineamento
SFA-CoGe.
1.7.4.2 [UR_REP_02] Visualizzazione report forecast
L'applicativo deve fornire all'utente un report che corrisponda all'attuale documento Forecast report.
1.7.4.3 [UR_REP_03] Report tramite grafici
L'applicativo dovrebbe presentare un grafico a barre che metta a confronto i valori di CoGe e Budget
per ogni BU.
Altri requisiti su eventuli grafici verranno introdotti in futuro.
1.8 Modello dei casi d’uso
1.8.1 Premessa
Si potrà constatare, nei paragrafi seguenti, che non tutti i requisiti funzionali sono coperti dagli Use
Cases, questa scelta è stata dettata dalla volontà di selezionare un sottoinsieme di requiti minini sui
quali concentrarsi per la realizzazione di un prototipo. Ciò ha permesso di ottenere un prototipo
funzionante in minor tempo e consentirà di raffinare i requisiti già definiti sulla base di test operativi
eseguiti dagli utenti che realmente usufruiranno dell’applicativo.
1.8.2 Attori
Viene presentata di seguito la lista degli attori che interagiranno con il sistema.
 BU User
 Administrator
 Operator
 Active Directory
 Browser
1.8.3 Diagrammi dei casi d’uso
Nello schema sotto riportato si mostra la struttura del sistema in questione. I vari sottosistemi
interagiscono tra loro per fornire le funzionalità complessive dello stesso.
FIGURA 5 - STRUTTURA DEL SISTEMA

14
In ogni diagramma che verrà esplicitato nei prossimi paragrafi si assumono le seguenti associazioni di
specializzazione tra attori:
FIGURA 6 - SPECIALIZZAZIONE DEGLI ATTORI
1.8.3.1 Sottosistema ACCESSO AL SISTEMA
FIGURA 3 – SOTTOSISTEMA LOG-IN

15
1.8.3.2 Sottosistema INSERIMENTO
FIGURA 4 – SOTTOSISTEMA INSERIMENTO
1.8.3.3 Sottosistema GESTIONE FORECAST
FIGURA 5 – SOTTOSISTEMA GESTIONE FORECAST

16
1.8.3.4 Sottosistema CONSULTAZIONE
FIGURA 5 – SOTTOSISTEMA CONSULTAZIONE
1.8.4 Specifica dei casi d’uso
UC-01 Richiede accesso al sistema
Description Operazione di richiesta d’accesso al sistema.
L’attivazione avviene digitando l’indirizzo dell’applicativo sul Browser e
premendo il tasto invio.
Preconditions 1. Il Browser utilizzato supporta la Windows Authentication.
Actors Utente generico, Browser, Active Directory
Normal Sequence 1. L’Utente immette nel Browser l’indirizzo dell’applicativo e preme invio.
2. Il Browser invia la richiesta al server.
3. Il server avverte il Browser che è richiesta Windows Authentication
(inserisce nella risposta HTTP i due header WWW-Authenticate
Negotiate, WWW-Authenticate NTML).
4. Il Browser contratta l’autenticazione dell’ Utente seguendo uno dei due
protocolli: NTLM o Kerberos.
5. Le credenziali vengono verificate su Active Directory.
6. Se le credenziali identificano un Utente su Active Directory la fase di
autententicazione termina con esito positivo.
7. Se anche la fase di autorizzazione termina con esito positivo, il Browser
esegue il rendering dell’home page dell’applicativo (altrimenti, vedi
6a).
Postconditions
Extensions 6a. Viceversa, il server inoltra al Browser una risposta HTTP avente come
status code 401 Unauthorized e contenente gli header WWW-
Authenticate Negotiate, WWW-Authenticate NTML).
7a. Il Browser presenta all’Utente un form per l’inserimento delle
credenziali.
UC-02 Compila browser form
Description Compilazione del form presentato dal Browser.
Preconditions L’autenticazione o l’autorizzazione hanno avuto esito negativo.
Actors Utente generico, Browser
Normal Sequence 1. L’Utente compila il form fornito dal Browser e preme invio.
2. Si ripete la stessa sequenza di operazioni descritte nello Use case UC-

17
01 a partire dal punto 6.
Postconditions
Extensions Vedi Extensions UC-01.
UC-03 Inserimento dati SFA
Description Caricaricamento del foglio di calcolo contenente i dati provenienti dal
sistema SFA.
L’attivazione dell’operazione avviene cliccando l’apposito pulsante che
permette di selezionare un file.
Preconditions Il documento in questione deve essere un foglio di calcolo in formato .xls.
Actors Operator, Browser
Normal Sequence 1. L’Operator individua il documento sul proprio disco locale attraverso
l’apposita finestra di navigazione fornita dal Browser e preme invia.
2. Se nel Forecast corrente e nella BU di riferimento non è stato caricato
precedentemente un foglio relativo a SFA, il Browser invia il file al
server.
Postconditions La base di dati di supporto contiene le informazioni presenti nel
documento caricato.
Extensions 2a. Viceversa, viene mostrata la richiesta di conferma per sovrascrivere i
dati precedentemente caricati.
UC-04 Inserimento dati CoGe
Description Caricaricamento del foglio di calcolo CoGe.
L’attivazione dell’operazione avviene cliccando l’apposito pulsante che
permette di selezionare un file.
Preconditions Il documento in questione deve essere un foglio di calcolo in formato .xls.
Actors Operator, Browser
Normal Sequence 1. L’Operator individua il documento sul proprio disco locale attraverso
l’apposita finestra fornita dal Browser e preme invia.
2. Se nel Forecast corrente e nella BU di riferimento non è stato caricato
precedentemente un foglio CoGe, il Browser invia il file al server.
Postconditions La base di dati di supporto contiene i dati presenti nel documento caricato.
Extensions 2a. Viceversa, viene mostrata la richiesta di conferma per sovrascrivere i
dati precedentemente caricati.
UC-05 Consulta Allineamento SFA-CoGe
Description Consultazione del report Allineamento SFA-CoGe.
L’attivazione dell’operazione avviene cliccando l’apposito pulsante.
Preconditions
Normal Sequence 1. L’Utente preme il pulsante per la consultazione del report in questione.
2. Il Browser inoltra la richiesta al sistema.
3. Il sistema elabora i dati richiesti e li restituisce al Browser.
4. Il Browser effettua il rendering della pagina richiesta.
Postconditions
Extensions

18
UC-06 Consulta Forecast Report
Description Consultazione del report Forecast Report.
Preconditions
Normal Sequence 1. L’Utente preme il pulsante per la consultazione del report in questione.
2. Il Browser inoltra la richiesta al sistema.
3. Il sistema elabora i dati richiesti e li restituisce al Browser.
4. Il Browser effettua il rendering della pagina richiesta.
Postconditions
Extensions
UC-07 Apertura Forecast
Description Apertura di un nuovo Forecast.
Preconditions
Actors Administrator, Browser
Normal Sequence 1. L’Administrator imposta una data di apertura e preme il pulsante per
inviare il comando.
2. Se il Forecast corrente è stato chiuso, viene verificata la correttezza
della data impostata.
3. Se la data di apertura è antecedente alla data di chiusura del Forecast
precedente, l’operazione termina con esito positivo.
Postconditions La base di dati di supporto è stata aggiornata. Il Forecast corrente risulta
essere il Forecast appena aperto.
Extensions 2a. Altrimenti, viene segnalato l’errore con un apposito messaggio.
3a. Altrimenti, viene segnalato l’errore con un apposito messaggio.
UC-08 Chiusura Forecast
Description Chiusura del Forecast corrente.
Preconditions
Actors Administrator, Browser
Normal Sequence 1. L’Administrator imposta una data di chiusura e preme il pulsante per
inviare il comando.
2. Se il Forecast corrente è aperto, viene verificata la correttezza della
data impostata.
3. Se la data di chiusura è antecedente alla data di apertura del Forecast
corrente, l’operazione termina con esito positivo.
Postconditions La base di dati di supporto è stata aggiornata. Il Forecast corrente risulta
essere il Forecast appena aperto.
Extensions 2a. Altrimenti, viene segnalato l’errore con un apposito messaggio.
3a. Altrimenti, viene segnalato l’errore con un apposito messaggio.
1.8.5 Diagrammi delle attività
Si presentano di seguito i diagrammi delle principali attività.

19
1.8.5.1 Diagramma 1 – Accesso al sistema

20
1.8.5.2 Diagramma 2 – Apertura Forecast

21
1.8.5.3 Diagramma 3 – Inserimento documentazione

22
1.8.5.4 Diagramma 4 – Consultazione report
1.9 Altri requisiti (non funzionali)
1.9.1 [UR_SUP] Supportabilità
L'applicativo deve presentare un'interfaccia utente responsiva, ovvero, qualora sia utilizzato
attraverso browser mobile, deve presentare un'interfaccia che si adatti completamente alle
dimensioni dello schermo del dispositivo in uso.
1.9.2 [UR_USA] Usabilità
L'applicativo deve assistere l'utente in tutte le operazioni che possono presentare criticità o
interpretazioni differenti.

23
L'applicativo deve presentare un'interfaccia utente semplice ed intuitiva, che permetta ad un utente
con conoscenze informatiche medie di sfruttarlo a pieno fin dal primo utilizzo.
1.9.3 [UR_AFF] Affidabilità
L'applicativo deve prevenire le principali vulnerabilità riscontrate nelle applicazioni web attuali, sarà
quindi compito del fornitore sviluppare opportuni test per accertare la sicurezza dello stesso.
1.10Requisiti della base di dati
 L’azienda Cluster Reply è composta da diverse BU, ciascuna delle quali possiede un nome
univoco e una sede.
 Per ogni BU si vorrà tenere traccia del personale che compone il reparto Management (si
tratta degli utenti che saranno abilitati all’uso dell’applicativo).
 Per ciascun utente verrà memorizzato il nome, il cognome, l’indirizzo email, il profilo
aziendale e i ruoli ricoperti (ai fini dell’applicativo).
 Sarà di interesse mantenere uno storico relativo alle precedenti proiezioni (Forecast) relative
a ciascuna BU.
 Un Forecast sarà associato ad una data di apertura e ad una data di chiusura. Ad ogni
Forecast sarà associato un attributo che indica se lo stesso è ancora aperto oppure se è stato
chiuso.
 Dato che l’elaborazione dei report verrà effettuata ad ogni richiesta di consultazione
dell’utente (elaborazione on-demand) si vorrà mantenere una copia del contenuto dei
documenti SFA e CoGe (definitivi6
) relativi ad ogni Forecast.
 Ogni funzionalità dell’applicativo sarà fruibile da un sottoinsieme (non vuoto) di ruoli utente,
si vorrà quindi mantenere l’insieme delle associazioni funzionalità, ruoli utente associati.
 Poichè ad alcuni utenti sarà dato accesso alle informazioni relative a più BU, risulterà
necessario tenere traccia della visibilità (in termini di BU) associata a ciascun utente.
 Al fine di gestire in modo efficace le denominazioni multiple di un cliente si richiede di poter
tenere traccia di un cliente e di tutte le diverse denominazioni ad esso associato.
6
L’ultima versione inserita.

25
2 Progettazione
2.1 Progettazione concettuale
Una volta che tutti i requisiti sono stati raccolti e analizzati, il passo successivo consiste nel creare
uno schema concettuale per la base di dati, usando un modello dei dati concettuali di alto livello.
Questa fase è detta progettazione concettuale.
In una prima analisi lo schema architetturale individuato si compone dalle seguenti entità:
 BU
 UTENTE
 FORECAST
 COGE
 SFA
 FUNZIONALITA
 CUSTOMER
 RUOLO
Le relazioni che intercorrono tra le entità, in un primo stadio di raffinamento, sono:
 appartiene : relazione tra BU e UTENTE.
 relativo : relazione tra BU e FORECAST.
 compone(s) : relazione tra FORECAST e SFA.
 compone(c) : relazione tra FORECAST e COGE.
 partecipa : relazione tra SFA, COGE e CUSTOMER.
 fruibile: relazione tra RUOLO e FUNZIONALITA.
 ricopre: relazione tra UTENTE e RUOLO.
 visibilita: relazione tra BU e UTENTE.

26
FIGURA 7 - SCHEMA INIZIALE DELLA BASE DI DATI
2.1.1 Analisi delle entità: attributi e chiavi primarie
BU
Nome
Nome che identifica univocamente una Business Unit.
Chiave primaria
Sede Nome della sede in cui risiede la BU.
UTENTE
Email
Email aziendale che identifica univocamente un utente.
Chiave primaria
Nome Nome dell’utente.
Cognome Cognome dell’utente.
FORECAST
Id
Identificativo di un determinato Forecast.
Chiave primaria
Data apertura Data in cui il Forecast è stato aperto.
Data chiusura Data in cui il Forecast è stato chiuso (se è stato chiuso).

27
Chiuso Stringa che indica se il Forecast è stato chiuso o meno.
SFA
Id
Identificativo di un determinato foglio di calcolo contenente i dati
provenienti dai sistemi SFA.
Chiave primaria
Data estrazione
Data nella quale i dati vengono estratti dal foglio di calcolo e
salvati nella base di dati.
BU Nome della BU alla quale i dati estratti fanno riferimento.
Campi SFA
Segue la lista dei campi componenti il foglio di calcolo SFA. Si è
scelto di ometterli in quanto non rilevanti ai fini della
progettazione della base di dati.
COGE
Id
Identificativo di un determinato documento CoGe.
Chiave primaria
Data estrazione
Data nella quale i dati vengono estratti dal foglio di calcolo e
salvati nella base di dati.
BU Nome della BU alla quale i dati estratti fanno riferimento.
Campi Coge
Segue la lista dei campi componenti il foglio di calcolo CoGe. Si è
scelto di ometterli in quanto non rilevanti ai fini della
progettazione della base di dati.
FUNZIONALITA
Id
Identificativo di una determinata funzionalità.
Chiave primaria
Descrizione Descrizione testuale della funzionalità in questione.
CUSTOMER
Nome
Nome che identifica in modo univoco un cliente.
Chiave primaria
Denominazioni Lista delle dominazioni da associare al cliente.
RUOLO
Nome
Nome che identifica in modo univoco un ruolo.
Chiave primaria
2.1.2 Analisi delle associazioni: descrizione, rapporto di cardinalità e attributi

28
appartiene
Descrizione Associa ciascun utente alla propria BU.
Rapporto di cardinalità
1:N Ogni utente appartiene ad una BU. Una BU contiene uno o più
utenti.
relativo
Descrizione Mette in relazione un Forecast con la BU a cui fa riferimento.
1:N Ogni Forecast è associato ad una BU. Ad una BU sono associati
0 o più Forecast.
compone (s)
Descrizione
Mette in relazione un documento SFA con il Forecast di
riferimento.
1:1 Ogni documento SFA compone un solo Forecast. Ogni Forecast
è associato ad al più un solo documento SFA.
compone (c)
Descrizione
Mette in relazione un documento CoGe con il Forecast di
riferimento.
1:1 Ogni documento CoGe compone un solo Forecast. Ogni
Forecast è associato ad al più un solo documento CoGe.
fruibile
Descrizione Associa un ruolo alle funzionalità delle quali può fruire.
M:N Ogni ruolo può fruire di una o più funzionalità. Una
funzionalità è fruibile da uno o più ruoli.
ricopre
Descrizione Associa un utente al/i ruolo/i che ricopre.
M:N Ogni utente può ricoprire uno o più ruoli. Ogni ruolo può
essere ricoperto da più utenti.
visibilita
Descrizione Associa un utente alle BU da esso visibili.
M:N Ogni utente può avere visibilità di una o più BU. Ogni BU può
essere visibile da uno o più utenti.

29
partecipa
Descrizione
Associa i documenti SFA e CoGe ai clienti che compaiono nelle
commesse.
M:N Ogni documento contiene una lista di uno o più clienti. Ogni
cliente può essere contenuto in nessuno o più documenti.
Terminata la fase di progettazione concettuale, è emersa l’esigenza di introdurre un ulteriore vincolo
sui requisti. E’ stato richiesto, infatti, che le funzionalità messe a disposizione fossero in qualche
modo legate ai singoli utenti oltre che ai ruoli. Ciò consentirebbe di gestire casi eccezionali in cui, ad
esempio, vi sia la necessità di permettere ad un utente di usufruire di una determinata funzionalità
sebbene il ruolo ad esso assegnato glielo impedisca. In una situazione di questo tipo, sarebbe
inopportuno modificare il ruolo dell’utente in quanto lo stesso verrebbe abilitato a tutte le
funzionalità messe a disposizione di tale ruolo.
L’introduzione del vincolo appena descritto ha comportato l’inserimento dell’associazione “dispone”
tra le entità UTENTE e FUNZIONALITA.
FIGURA 8 - SCHEMA CONCETTUALE FINALE DELLA BASE DI DATI
2.2 Progettazione logica
2.2.1 Ristrutturazione dello schema E-R
Rimozione delle gerarchie
Lo schema non presenta gerarchie di generalizzazione / specializzazione.
Rimozione delle entità deboli
Lo schema non presenta entità deboli da rimuovere.

30
Rimozione degli attributi composti
Lo schema non prevede attributi composti.
Rimozione degli attributi multivalore
L’unico attributo multivalore presente nello schema è l’attributo Denominazioni che compare
nell’entità CUSTOMER. La rimozione di tale attributo richiede l’introduzione della nuova entità
DENOMINAZIONE e dell’associazione “designato_come”.
2.2.2 Schema logico relazionale
Segue la traduzione dello schema concettuale ristrutturato in un equivalente schema logico
relazionale.
Ciascuna entità dello schema E-R ristrutturato viene mappata in un equivalente schema relazionale, il
quale prevede la segnalazione della relativa chiave primaria (sottolineandola) e dei vincoli di integrità
referenziali tra chiavi esterne e chiavi (indicati da una freccia che punta alla chiave riferita).
1.

36
Di seguito si presenta lo schema logico relazionale ottenuto.
FIGURA 9 - SCHEMA LOGICO RELAZIONALE DELLA BASE DI DATI

37
2.3 Architettura del software
2.3.1 Introduzione: architetture a tre livelli
Nella progettazione ed implementazione di applicazioni data-centric, ovvero applicazioni che
sfruttano una sorgente dati (nel caso più comune, un database relazionale) per persistere le
informazioni trattate, l'approccio più diffuso è quello di scomporre il sistema in diversi strati
applicativi (layer), ciascuno dei quali caratterizzato da una forte focalizzazione e specializzazione
funzionale.
Ogni layer esegue compiti ben definiti ed è in grado di comunicare con gli altri strati, demandando ad
essi le eventuali azioni non di propria pertinenza. Pertanto, secondo questo approccio architetturale,
le funzionalità più complesse vengono ottenute dalla collaborazione di più elementi specializzati,
dislocati nei diversi layer applicativi secondo un ordine di invocazione gerarchico ben preciso.
Ciascun layer si compone di classi che svolgono compiti simili e omogenei, ma che agiscono su dati e
scenari diversi. Questa omogeneità funzionale rappresenta la caratteristica principale di ogni strato
applicativo.
Per quanto riguarda le applicazioni web si individuano in genere tre livelli logici; perciò, quando si fa
riferimento a questo tipo di applicazioni, si parla spesso di architetture a tre livelli.
I layer in questione sono i seguenti
 Presentation Layer: ha lo scopo di gestire l’interazione del sistema con il mondo esterno, in
particolare con gli utenti. Include le maschere per la visualizzazione e l’inserimento dei dati, i
controlli e i meccanismi per intercettare e trattare opportunamente gli eventi che sono
scatenati in funzione delle azioni svolte dagli utenti.
 Business Logic Layer: comprende l’insieme delle regole di business che regolano il
funzionamento dell’applicazione, intercetta le richieste provenienti dallo strato di
presentazione e le gestisce nel modo più appropriato.
 Data Access Layer: si occupa di persistere le informazioni trattate dall’applicazione e conosce
le modalità per leggerle e salvarle in una sorgente dati di qualche tipo.
Se da un lato un numero maggiore di moduli implica un maggiore sforzo in termini di
programmazione, dall'altro la scomposizione dell'applicazione in oggetti raggruppati in modo
omogeneo a formare i diversi layer comporta una migliore organizzazione e strutturazione logica del
codice, con vantaggi enormi in termini di manutenibilità e scalabilità.
Basti pensare che se si presentasse la necessità di cambiare sistema di database, sarebbe sufficiente
modificare uno solo dei livelli dell’applicazione.
2.3.2 ASP.NET MVC
Nel caso in questione, uno dei requisiti di progetto ha fortemente vincolato la struttura
dell’architettura del sistema, che si è dovuta attenere alle linee guida del design pattern ASP.NET
MVC.
Il Model-View-Controller (MVC) è un pattern architetturale molto diffuso nello sviluppo di
sistemi software che si propone di separare la logica di presentazione dei dati dalla logica di business.

38
In particolare, ASP.NET MVC rapprenta un modello di programmazione all’interno del Framework di
sviluppo web ASP.NET che aderisce al pattern MVC.
Tale pattern prevede la separazione della logica dell’applicazione in tre livelli:
 il Model fornisce la logica per l’accesso ai dati utili all'applicazione, contiene inoltre la
definizione delle entità coinvolte;
 il View si occupa di mostrare i dati contenuti nel Model;
 il Controller riceve i comandi dell'utente (in genere attraverso il view) e li attua modificando
lo stato degli altri due componenti.
FIGURA 10 - SCHEMA PATTERN MVC
2.3.3 Composizione delle architetture
In fase di progettazione si è profilato un ulteriore vincolo progettuale che ha posto il problema di
integrare il design pattern ASP.NET MVC nell’architettura a tre livelli sopra descritta. Nel dettaglio,
l’azienda ha richiesto di strutturare il sistema nei tre livelli descritti sopra (PL,BLL,DAL) creando un
differente progetto di Visual Studio per ogni livello.
Si è quindi studiata una soluzione che permettesse di inglobare nella three level architecture la
separazione logica prevista da MVC
7
senza snaturarne il significato.
Il risultato è rappresentato nello schema che segue.
7
La separazione tra Model, View e Controller in ASP.NET prevede l’utilizzo di tre folder differenti, uno per ogni
componente logica.

39
FIGURA 11 - ARCHITETTURA DEL SISTEMA
Ogni livello (e quindi ogni progetto) rappresenta una porzione significativa del problema generale da
risolvere, perciò è organizzato in più folder, ognuno dei quali raccoglie oggetti simili per funzionalità
svolte.
Come si può notare è stato introdotto un ulteriore livello adiacente a tutti gli altri. Esso rappresenta
un modello del dominio dell’applicazione, ovvero un insieme di classi che servono a rappresentare le
entità coinvolte. Includerà quindi la definizione di tutte le entità il cui contesto, ai fini dello sviluppo,
non può essere confinato ad un unico livello.
Il Presentation Layer contiene i folder relativi a View e Controller del pattern MVC, mentre il Model è
stato distributo tra i restanti livelli. Ciò comporta che il livello di presentazione svolga ambedue i
compiti:
 fornire al client le pagine web sulla base delle elaborazioni svolte;
 ricevere dal server web le richieste HTTP provenienti dal client sotto forma di URL e trasferire
allo strato sottostante le informazioni acquisite.
Per quanto riguarda le funzioni svolte dai livelli Business Logic e Data Access si rimanda al paragrafo
2.3.1.
2.4 Progettazione interfaccia grafica
Mockup
Nell’ambito dello sviluppo web un mockup non è altro che una rappresentazione statica e
approsimativa di come apparirà il prodotto finale. Permette agli sviluppatori di mostrare una sorta di
“preview” delle pagine che comporranno il sistema all’utente finale.
Nel caso in esame, i mockup presentati sono stati sottoposti al responsabile del progetto per una
valutazione prima di cominciare la fase di sviluppo.

40
1. Allineamento SFA-CoGe, documentazione non inserita
FIGURA 12 - ALLINEAMENTO SFA-COGE (DOCUMENTAZIONE NON INSERITA)
2. Inserimento documentazione
FIGURA 13 - INSERIMENTO DOCUMENTAZIONE

41
3. Allineamento SFA-CoGe, foglio Confronto
FIGURA 14 - ALLINEAMENTO SFA-COGE, FOGLIO CONFRONTO

42
4. Allineamento SFA-CoGe, foglio Componenti offerta
FIGURA 15 - ALLINEAMENTO SFA-COGE, FOGLIO COMPONENTI OFFERTA

43
5. Forecast report
FIGURA 16 - FORECAST REPORT

44
6. Chiusura Forecast
FIGURA 17 - CHIUSURA FORECAST
2.5 Valutazione del template grafico
In questa fase l’azienda ha richiesto la valutazione del template grafico da utilizzare nello sviluppo
della user interface dell’applicativo. In particolare è stato chiesto di fornire un campione, composto
da un massimo di 5 alternative, di template Twitter Bootstrap.
Twitter bootstrap è un framework grafico rilasciato dal team di sviluppo di Twitter, che permette di
avvalersi di una serie di componenti grafici (pulsanti,form, tabelle ecc.) forniti con i relativi fogli di
stile8
(CSS).
La fase di ricerca del template è stata preceduta dalla definizione dei parametri sui quali basare la
valutazione. Dopo un confronto con il responsabile di progetto, i parametri emersi sono:
 compatibilità con browser e sistemi operativi più diffusi;
 versione di Bootstrap utilizzata;
 qualità della documentazione fornita;
 struttura e responsività del layout;
 attinenza con il logo dell’azienda;
 eventuali malfunzionamenti riscontrati nelle versioni demo.
Presentato il campione, la scelta del responsabile di progetto è ricaduta sul template “Metronic”
sviluppato dal team Keenthemes9
all’interno del framework Bootstrap 3.1.0.
8
Per maggiorni informazioni visitare il sito http://getbootstrap.com/

45
3 Implementazione
Segue la descrizione dei moduli principali che compongono il sistema. Tutti i moduli che verranno
presentati sono stati sviluppati dall’autore. Ove, in caso contrario, si faccia riferimento a librerie
esterne verrà opportunamente indicato.
3.1 Autenticazione e recupero di informazioni su Active Directory
Come indicato nei vincoli di progetto l’autenticazione dell’utente avviene avvalendosi della Windows
authentication sul sistema di directory service Microsoft Active Directory.
Active Directory è un insieme di servizi di rete meglio noti come directory service adottati dalla
maggior parte dei sistemi operativi Microsoft Windows Server. Un directory service è un sistema
software che memorizza, organizza e fornisce l'accesso alle informazioni contenute in una directory.
Nell’ingegneria del software, una directory è un’associazione di nomi e valori che consente la ricerca
di valori dato un nome.
L’integrazione della Windows authentication in un’ applicazione ASP.NET risulta molto semplice, in
quanto è sufficiente dichiarare, nelle proprietà del progetto, l’intenzione di adottare la Windows
authentication disabilitando al tempo stesso l’Anonymous authentication.
FIGURA 18 - MASCHERA PROPRIETÀ PROGETTO IN VISUAL STUDIO 2012
Il sistema provvederà automaticamente ad intercettare le richieste degli utenti e ad identificarli su
Active Directory prima di fornire accesso all’applicativo.
Più complesso si è rivelato il recupero di informazioni relative agli utenti sul directory service in
esame. Una delle tecniche che permette di eseguire tale operazione si avvale dell’utilizzo delle API
LDAP.
Tali API forniscono accesso al procollo LDAP, che costituisce una via per l’interazione con i sistemi di
directory service, come Active Directory.
LDAP (Lightweight Directory Access Protocol) è un protocollo che permette di accedere ai servizi
di directory basati sul modello x.50010
. Permette di interrogare, creare, aggiornare e cancellare
9
http://themeforest.net/item/metronic-responsive-admin-dashboard-template/4021469
10
Il modello X.500 è uno standard per la realizzazione di un servizio di directory globale e distribuito.

46
informazioni memorizzate in un directory service su una connessione TCP, tipicamente attraverso la
porta 389. I dettagli del protocollo e dell’implementazione sono definiti nel RFC2251: “The
Lightweight Directory Access Protocol (v3)” e su altri documenti come, ad esempio, le specifiche
tecniche nel RFC3377.
3.1.1 Architettura delle ricerche su Active Directory
L’architettura delle ricerche su Active Directory include componenti sia client che server.
Relativamente al lato client, l’applicazione costruisce le richieste LDAP da inviare al server. A seconda
di come l’applicativo è stato scritto, una delle tre APIs che verranno nel seguito presentate viene
utilizzata per inviare le richieste. Le LDAP request ricevute vengono quindi elaborate dal Directory
System Agent (DSA). Si riporta di seguito lo schema riepilogativo dell’architettura descritta fornito
nella documentazione Microsoft.
FIGURA 19 - ACTIVE DIRECTORY SEARCHES ARCHITECTURE
Le tre LDAP APIs che possono essere utilizzate lato client sono qui descritte.
 System.DirectoryServices (ADSI for .NET Framework): si tratta di un namespace del .NET
Framework che fornisce un semplice accesso alle LDAP directories. Richiede l’installazione
del .NET Framework.
 Active Directory Service Interfaces (ADSI) (Ads*.dll): costituisce un set di interfacce aperte che
astraggono i dettagli delle comunicazioni LDAP.
 Native LDAP API (Wldap32.dll): fornisce una serie di funzioni che permettono di cercare e
recuperare informazioni da un LDAP directory service.

47
FIGURA 20 - ACTIVE DIRECTORY SEARCHES INTERFACES
In questa circostanza si è scelto di avvalersi delle interfacce ADSI fornite con il namespace
System.DirectoryServices.
Il valore aggiunto introdotto dall’utilizzo di tali interfacce rispetto alle altre, è dato dal fatto che:
 si tratta di APIs a livello più alto;
 sono più semplici da utilizzare.
3.1.2 Modulo sviluppato
Ai fini dell’applicativo, risulta di interesse recuperare la mail di un utente la cui identità è già stata
verificata su Active Directory. Nello specifico, dato lo username dell’utente nel dominio REPLYNET si
vuole recuperare l’indirizzo email aziendale ad esso associato.
Il modulo sviluppato prevede la ricezione di uno username e di una lista di proprietà11
e la
conseguente restituzione della lista di valori associati a tali proprietà nell’ordine in cui sono stati
richiesti.
FIGURA 21 - SCHEMA MODULO ACTIVE DIRECTORY SEARCHES
Risulta evidente che si è cercato di sviluppare il modulo nel modo più generico possibile, in modo tale
che se in futuro dovesse sorgere l’esigenza di recuperare altre informazioni non sia necessario
modificare o addirittura riscrivere l’intero modulo.
Le due classi principali nel namespace System.DirectoryServices sono DirectoryEntry e
DirectorySearcher. La prima viene utilizzata per stabilire una connessione con il directory service, la
seconda fornisce i metodi per effettuare la ricerca.
11
Con proprietà si fa riferimento agli attributi associati ad ogni User su Active Directory (ad esempio “mail”,
”givenName”, “department” ecc.).

48
Una volta stabilita la connessione e istanziata la classe DirectorySearcher è possibile impostare un
filtro sulla ricerca che si sta per effettuare. Nel modulo sviluppato è stato utilizzato il seguente filtro:
FRAMMENTO DI CODICE 1 - FILTRO UTILIZZATO NELLA RICERCA
Viene quindi verificato che l’oggetto che si sta cercando sia istanza della classe “user” e che il
“sAMAccountName”12
corrisponda a userName.
Il passo successivo consiste nel definire le proprietà che si vogliono recuperare nell’oggetto
DirectorySearcher:
FRAMMENTO DI CODICE 2 - INSERIMENTO DELLE PROPRIETÀ NELL'OGGETTO DIRECTORYSEARCHER
Infine si esegue la ricerca, in questo caso verrà prodotto un unico risultato dato che
sAMAccountName identifica in modo univoco un utente.
FRAMMENTO DI CODICE 3 - AVVIO DELLA RICERCA
Se la ricerca ha avuto esito positivo all’interno dell’oggetto SearchResult saranno contenute le
proprietà richieste, che possono essere estratte con operazioni del tipo:
FRAMMENTO DI CODICE 4 - ESTRAZIONE DELLE PROPRIETÀ RICHIESTE
3.2 Estrazione di dati da fogli di calcolo con OpenXML
In questo paragrafo verrà trattato il processo di estrazione dei dati di interesse da fogli di calcolo in
formato .xls, avvalendosi delle librerie OpenXML.
3.2.1 Office Open XML
Office Open XML (chiamato anche OOXML o OpenXML) è un formato di file, basato sul linguaggio
XML, per la rappresentazione di documenti informatici, come documenti di testo, fogli di calcolo,
presentazioni e grafici. Sviluppato inizialmente da Microsoft, come formato per la rappresentazione
dei prodotti Microsoft Office, è stato successivamente standardizzato da ECMA (ECMA-376) e poi da
ISO e IEC (ISO/IEC 29500).
Lo standard prevede tre principali linguaggi di markup: WordprocessingML,SpreadsheetML e
PresentationML. Come è facile intuire, ai fini del progetto di tesi, il linguaggio analizzato è lo
SpreadsheetML, ovvero il linguaggio di markup con lo scopo di rappresentare fogli di calcolo.
12
sAMAccountName rappresenta il logon name di uno user su Active Directory.

49
3.2.2 SpreadsheetML
Un documento SpreadsheetML è composto di una sezione centrale detta workbook e di più sezioni
separate (dette worksheet) per ogni foglio di lavoro. Affinchè un documento SpreadsheetML possa
ritenersi valido deve contenere la sezione workbook e almeno una sezione worksheet.
3.2.2.1 Sezione workbook
Il primo e più importante compito della sezione workbook è di tenere traccia dei fogli di lavoro.
Ad ogni foglio sono associati un nome, un ID utilizzato nell’ordinamento dei fogli e un rID
(relationship ID) che punta alla sezione del workbook nella quale il foglio è memorizzato.
FIGURA 22 - ESEMPIO DI WORKBOOK MINIMO
3.2.2.2 Sezione worksheet
La prima parte della sezione riguarda le proprietà del worksheet; quindi, seguono i dati contenuti
nell’elemento sheetData. All’interno di tale elemento saranno definite le righe e le celle che
compongono il foglio di calcolo. Una nuova riga viene definita mediante l’elemento row, mentre una
nuova cella viene definita mediante l’elemento c.
Il valore contenuto nella cella viene incluso all’interno di un elemento v, se si tratta di un valore
numerico (vedi fig. 22).
FIGURA 23 - WORKSHEET CONTENENTE UN UNICO DATO
Nel caso in cui il valore contenuto in una cella sia ottenuto attraverso una formula verrà utilizzato
l’elemento f per dichiarare la formula e l’elemento v conterrà il risultato dell’elaborazione. Tale
valore fa riferimento all’ultima occorrenza in cui la formula è stata calcolata.

50
FIGURA 24 - ESEMPIO DI FORMULA
La memorizzazione di stringhe segue invece una procedura di ottimizzazione che prende il nome di
shared strings. Questa tecnica permette di ottimizzare lo spazio richiesto quando il foglio di calcolo
contiene molteplici istanze della stessa stringa. Prevede, infatti, di memorizzare in una tabella
(shared string table) la stringa in questione e di referenziare la stessa attraverso un indice. In questo
modo, si evita l’inclusione della stringa nel campo value dell’elemento cella.
La shared string table compare come una sezione separata all’interno del workbook e viene definita
attraverso l’elemento sst. Mentre un nuovo item viene aggiunto attraverso l’elemento si (string
item).
FIGURA 25 - ESEMPIO DI SHARED STRING TABLE
Per indicare che il valore contenuto in una cella è di tipo stringa si usa la dichiarazione “t=s” tra gli
attributi dell’elemento cella. L’elemento v incluso nella cella viene utilizzato per indicare l’indice della
shared string table.

51
FIGURA 26 - ESEMPIO DI INDICIZZAZIONE DELLE STRINGHE
Come si può notare dalla Figura 26, gli elementi riga e cella sono tipicamente accompagnati da un
identificatore di posizione.
Altri elementi possono comparire nella definizione di un documento SpreadsheetML, vengono però
omessi in quanto non rilevanti ai fini del progetto.
3.2.3 OpenXML SDK
OpenXML SDK è una libreria aperta che fornisce un insieme di classi .NET che permettono di
manipolare file che aderiscono alle specifiche dello standard Office Open XML. Integra al suo interno
la tecnologia LINQ (Language Integrated Query), un componente del .NET Framework che aggiunge ai
linguaggi .NET la capacità di effettuare interrogazioni su oggetti utilizzando una sintassi simile a
SQL13
.
Il modulo in questione è stato progettato tenendo conto del fatto che la struttura dei fogli di calcolo
è sempre la stessa, sia per quanto riguarda i fogli CoGe che per i fogli SFA.
Ciò ha permesso di individuare dei punti cardine sui quali basare la lettura del documento; le
seguenti assunzioni valgono per entrambi i documenti:
 il nome del foglio di calcolo contenente i dati da leggere rimane immutato nel tempo;
 i dati vengono esposti a partire da una determinata riga;
 tra due entry della tabella non compare mai una riga interamente vuota;
 esiste una colonna le cui celle non sono mai vuote qualora la riga corrispondente contenga
una entry della tabella. In altre parole, se una cella appartenente a tale colonna è vuota
significa che l’intera riga è vuota.
Si è cercato di implementare il metodo che realizza il modulo in oggetto nel modo più generale e
flessibile possibile, in modo tale da:
13
Per maggiori informazioni si rimanda al sito http://msdn.microsoft.com/it-it/library/bb397926.aspx.

52
 utilizzare lo stesso metodo per la lettura di entrambi i documenti (SFA e CoGe);
 riuscire a far fronte a piccole variazioni strutturali dei documenti senza dover riscrivere parti
di codice.
Il metodo riceve i seguenti parametri:
 path del file, corrisponde al path in cui il server ha temporaneamente salvato il file;
 nome del foglio di calcolo, nome del foglio nel quale si leggono i dati;
 indice inizio lettura, numero di riga corrispondente ai titoli dei campi della tabella;
 colonna di riferimento, colonna usata come riferimento nel calcolo del numero di righe da
analizzare.
Se l’elaborazione va a buon fine viene restituito un oggetto di tipo DataTable14
contenente i dati
estratti dal documento.
FIGURA 27 - SCHEMA MODULO SPREADSHEETML EXTRACTION
Si riportano di seguito le righe di codice ritenute più significative ai fini del processo.
FRAMMENTO DI CODICE 5
Disponendo del riferimento alla sezione worksheet è possibile calcolare l’indice dell’ultima riga da
leggere, semplicemente individuando la prima cella non “manipolata” della colonna di riferimento.
14
Rappresenta una tabella di dati in memoria.

53
Segue quindi la creazione di una DataTable il cui numero di righe e colonne corrisponda esattamente
alle dimensioni della tabella di dati contenuta nel foglio di calcolo.
Il passo successivo consiste nella lettura, riga per riga, del contenuto delle celle che includono i dati.
Tale operazione richiede la verifica del tipo di dato che si sta andando a leggere:
 se si tratta di un dato numerico o di un tipo Boolean è sufficiente leggere il contenuto
dell’elemento value incluso nella cella;
 nel caso di una stringa il contenuto viene estratto dalla shared string table.
FRAMMENTO DI CODICE 6 - LETTURA, RIGA PER RIGA, DEL CONTENUTO DELLE CELLE.
Il dato letto ad ogni ciclo verrà quindi inserito nella DataTable che verrà infine restituita al chiamante.

54
3.3 Report mediante le librerie Kendo UI
Telerik Kendo UI è una libreria basata su HTML 5 e jQuery che agevola lo sviluppo di componenti
grafici evoluti, sia per il web che per il mobile. Sfrutta HTML5, CSS3 e jQuery per fornire una serie di
widget legati alle tre categorie: web, mobile e data visualization.
In particolare, nello sviluppo del progetto, sono state utilizzate le librerie Telerik UI for ASP.NET, un
set di server-side wrappers che permettono l’utilizzo dei widget di Kendo UI tramite codice C# o
VB.NET.
FIGURA 28 - KENDO UI FRAMEWORK
I wrappers evitano allo sviluppatore la scrittura di codice JavaScript. Infatti, nella pratica, lo
sviluppatore definisce i componenti attraverso codice C# (nel dettaglio avvalendosi della Razor
Syntax15
), poi saranno i wrappers ad occuparsi della produzione del codice JavaScript necessario
all’inizializzazione dei widget lato client.
3.3.1 Esempio: AutoComplete widget
Per illustrare lo scenario appena descritto si presenta di seguito un semplice esempio il cui scopo è
quello di fornire all’utente un Autocomplete widget.
15
La Razor Syntax è una particolare sintassi usata nella programmazione ASP.NET per creare pagine web
dinamiche. In sostanza, consente di incorporare codice server-based (C# o Visual Basic) in pagine web.

55
FRAMMENTO DI CODICE 7 - AUTOCOMPLETE KENDO UI WRAPPER
Tale codice, inserito all’interno di una pagina .cshtml16
, definisce un AutoComplete Kendo UI wrapper
attraverso la sintassi Razor.
A run-time viene prodotto il seguente codice JavaScript lato client:
FRAMMENTO DI CODICE 8 - AUTOCOMPLETE KENDO UI WIDGET
Come si può notare il widget viene collocato esattamente sopra il div, laddove era stato definito
mediante il wrapper.
Dal punto di vista grafico il risultato prodotto è il seguente.
Le librerie in questione sono state utilizzate all’interno di più moduli nel progetto, come la
definizione di report in formato tabellare e nella produzione di un grafico a barre.
3.3.3 Premessa
La struttura dei report implementati ricalca esattamente quanto contenuto nei fogli di calcolo
attualmente in uso.
Per ovvi motivi i dati che verranno mostrati sono puramente inventati.
16
Si tratta dell’estensione delle View del pattern MVC.

56
3.3.4 Grid widget
In più sezioni dell’applicativo sono stati inseriti dei report che si avvalgono del widget Grid. Tale
widget permette di rappresentare i dati attraverso tabelle, fornendo al tempo stesso supporto per
l’interazione con i dati (ad esempio paginazione, ordinamento, raggruppamento ecc.).
3.3.4.1 Esempio di utilizzo: report Componenti offerta
Il report componenti offerta rappresenta uno dei fogli di calcolo che compongono il documento
Allineamento SFA-CoGe. Si tratta di una tabella composta da undici campi di differenti tipi (testuali,
numerici e date).
Il wrapper, inserito nella View “Componenti”, espone dati che vengono elaborati on-demand, ogni
volta che l’utente seleziona la voce corrispondente. Se i documenti SFA e CoGe non sono stati inseriti
per la BU e il Forecast selezionati, verrà prodotta una tabella vuota.
La dinamica con la quale i dati vengono passati alla View (e quindi al wrapper) si può articolare in sei
passaggi.
1. L’utente invia la richiesta per visualizzare la View Componenti sottoforma di url.
2. La richiesta viene raccolta dal server, che invoca il metodo Componenti contenuto nel
Controller specificato nella richiesta.
3. All’interno del metodo vengono richiesti i dati al layer sottostante.
4. Terminate le elaborazioni i dati vengono restituiti al metodo chiamante.
5. Il metodo invoca la View Componenti passando come parametro una lista di oggetti
ComponentiOfferta.
6. La View riceve la lista e la rende disponibile ai componenti contenuti nella pagina.
La seguente riga di codice realizza il punto 6: la View dichiara che il model ricevuto è un IEnumerable
di oggetti ComponentiOfferta. E’ quindi possibile accedere al model in questione attraverso la Razor
syntax @Model.
FRAMMENTO DI CODICE 9 - DICHIARAZIONE E INIZIALIZZAZIONE MODEL
Si riporta quindi il codice che realizza il wrapper in oggetto. Come si può notare, nella prima riga di
codice viene passato il Model al wrapper Grid.

57
FRAMMENTO DI CODICE 10 - GRID WRAPPER CHE REALIZZA IL REPORT COMPONENTI OFFERTA
Particolare importanza riveste l’utima riga di codice, che determina la modalità con la quale la griglia
richiede i dati al server nelle operazioni di paginazione, ordinamento e filtraggio. Nel caso in
questione è stato utilizzato il cosiddetto server-binding, ciò implica che il wrapper esegua delle
richieste HTTP-GET al server per portare a termine le operazioni sopracitate.
Il risultato prodotto sul client è la tabella che segue.
FIGURA 29 - GRID WIDGET CHE RAPPRESENTA IL REPORT COMPONENTI OFFERTA
3.3.4.2 Grid Layout
I widget grid che sono stati presentati sono il risultato di un’analisi volta al miglioramento della
leggibilità dei dati presentati. Si è scelto infatti di intervenire nel template standard delle griglie
fornite da Kendo UI per adattarsi alle seguenti esigenze:

58
 il titolo di ogni colonna deve essere esposto in grasseto e al centro della colonna stessa;
 ogni titolo deve essere completamente leggibile (perlomeno nei dispositivi desktop);
 la larghezza della tabella deve adattarsi alle dimensioni della finestra del browser;
 la larghezza delle colonne deve porter essere modificata dall’utente;
 se, il ridimensionamento di una o più colonne, determinasse un aumento della larghezza
della tabella dovrebbe comparire una barra di scrolling orizzontale che permetta all’utente di
visualizzare le colonne non più visibili.
3.3.5 Chart widget
Come suggerisce il nome, i widget Char sono dei componenti forniti da Kendo UI che permettono di
costruire grafici sui dati che gli vengono passati. Il rendering avviene direttamente sul client
attraverso la tecnologia SVG oppure sfruttando l’elemento Canvas incluso nell’HTML5.
3.3.5.1 Esempio di utilizzo: Forecast report
Il Forecast report rappresenta il report comprensivo di tutte le BU che viene inoltrato
dall’amministrazione centrale a tutti i gli attori del controllo di gestione alla chiusura di ogni Forecast.
Si compone di una tabella e di un grafico a barre; verrà di seguito presentato il wrapper utilizzato
nella definizione del grafico a barre.
FIGURA 30 - CHART WRAPPER UTILIZZATO FORECAST REPORT

59
Anche in questo caso si segnala l’ultima riga del wrapper, che determina il tipo di data-binding
utilizzato. A differenza di quanto illustrato precedentemente, in questa situazione si fa utilizzo
dell’ajax-binding, il che comporta l’utilizzo di richieste ajax nella popolazione delle barre. In
particolare, viene inviata una ajax request al metodo CoGeBudgetComparison contenuto nel
Controller Reports. Elaborate le informazioni richieste i dati verranno restituiti dal server in formato
JSON17
.
Il risultato prodotto sul client è il seguente grafico.
FIGURA 31 - CONFRONTO COGE BUDGET
3.4 Considerazioni
Come il lettore potrà intuire molti altri sono i moduli software che compongono il prodotto finale, si
è scelto però di concentrarsi sui processi ritenuti più caratterizzanti e meno frequenti nell’ambito
dello sviluppo di applicativi web.
3.5 Interfaccia prodotto finale
Si è deciso di presentare l’interfaccia utente del prototipo attraverso un caso reale di utilizzo.
3.5.1 Presentazione user interface attraverso un caso di utilizzo
Ipotesi iniziali:
 l’utente in questione è un amministratore di sistema abilitato a tutte le funzionalità offerte;
 il Forecast corrente è il secondo (su una scala che va da 1 a 12);
 sono già stati caricati i documenti SFA e CoGe per la BU di provenienza dell’utente nel
Forecast corrente.
17
JSON, acronimo di JavaScript Object Notation, è un formato adatto per lo scambio dei dati
in applicazioni client-server.

60
1. Report Allineamento SFA-CoGe, foglio Confronto
FIGURA 32 - REPORT ALLINEAMENTO SFA-COGE, FOGLIO CONFRONTO
Lo screenshot rappresenta l’Home Page dell’applicativo. I valori in alto a destra dello schermo stanno
ad indicare che sono stati aperti due Forecast e che l’utente può visualizzare i report relativi a
quattro BU.
L’utente può avvalersi delle funzionalità messe a disposizione dall’applicativo utilizzando la sidebar
sulla sinistra dello schermo.
2. Report Allineamento SFA-CoGe, espansione lista Forecast
FIGURA 33 - REPORT ALLINEAMENTO SFA-COGE, ESPANSIONE LISTA FORECAST
Espandendo la lista corrispondente all’icona di sinistra (nella notification list) si può notare che viene
mostrata la lista dei Forecast che sono stati aperti. Se presente, il Forecast aperto viene indicato con
un lucchetto aperto.

61
Cliccando su uno dei Forecast della lista verranno presentati i report relativi a tale Forecast per la BU
selezionata. Il Forecast selezionato di default è quello corrente (aperto o chiuso).
3. Report Allineamento SFA-CoGe, espansione lista BU
FIGURA 34 - REPORT ALLINEAMENTO SFA-COGE, ESPANSIONE LISTA BU
Similmente al caso precedente, espandendo la lista corrispondente all’icona di destra (nella
notification list) verrà mostrata la lista di BU visibili dall’utente corrente. Selezionando una delle BU
presenti nella lista verrano mostrati i report relativi a tale BU. La BU selezionata di default è la BU di
provenienza dell’utente corrente.
4. Chiusura di un Forecast
FIGURA 35 - CHIUSURA DI UN FORECAST

62
La sezione in oggetto permette la chiusura del Forecast corrente. E’ possibile selezionare una data di
chiusura diversa da quella corrente attraverso il widget Calendar.
5. Chiusura di un Forecast (nessun Forecast da chiudere)
FIGURA 36 - CHIUSURA DI UN FORECAST (NESSUN FORECAST DA CHIUDERE)
Dopo aver chiuso il Forecast corrente il sistema segnala che non sono più presenti Forecast da
chiudere. Come si evince dalla figura, la chiusura del Forecast viene segnalata anche attraverso la
chiusura del lucchetto nella lista dei Forecast disponibili.
6. Inserimento documentazione (nessun Forecast aperto)
FIGURA 37 - INSERIMENTO DOCUMENTAZIONE (NESSUN FORECAST APERTO)
Entrando nella sezione relativa all’inserimento della documentazione, verrà visualizzato un
messaggio che segnala l’impossibilità di procedere con l’operazione, data l’assenza di un Forecast
aperto.

63
7. Apertura nuovo Forecast
FIGURA 38 - APERTURA NUOVO FORECAST
Aprendo la sezione dedicata a tale scopo è possibile aprire un nuovo Forecast. La data di apertura è
selezionabile attraverso l’apposito widget; di default viene selezionata la data corrente.
8. Inserimento documentazione
FIGURA 39 - INSERIMENTO DOCUMENTAZIONE
Arrivati a questo punto è possibile inserire la documentazione nel sistema. L’utente potrà scegliere se
navigare sul proprio file system attraverso l’apposita finestra fornita dal browser, oppure trascinare il
file da caricare nell’area corrispondente (drag and drop).

64
9. Inserimento documentazione (operazione avvenuta)
FIGURA 40 - INSERIMENTO DOCUMENTAZIONE (OPERAZIONE AVVENUTA)
Alla pressione del tasto Upload File, viene fornito un messaggio che descrive l’esito dell’operazione.
10. Report Allineamento SFA-CoGe, foglio Componenti offerta
FIGURA 41 - REPORT ALLINEAMENTO SFA-COGE, FOGLIO COMPONENTI OFFERTA
E’ possibile consultare il foglio Componenti offerta relativo al report Allineamento SFA-CoGe per i
dati appena inseriti.
Cliccando il pulsante in alto a sinistra nella sidebar (a lato del logo Reply) è possibile ridurre le
dimensioni della sidebar stessa, rendendo più comoda la consultazione del report in questione (vedi
figura).

65
FIGURA 42 - REPORT ALLINEAMENTO SFA-COGE, FOGLIO COMPONENTI OFFERTA (DIMENSIONI OTTIMALI)
Se ritenuto opportuno, è possibile modificare la larghezza delle colonne per migliorare la leggibilità
dei dati.
FIGURA 43 - REPORT ALLINEAMENTO SFA-COGE, FOGLIO COMPONENTI OFFERTA (MODIFICA LARGHEZZA COLONNE)

66
11. Inserimento documentazione (sovrascrittura)
FIGURA 44 - INSERIMENTO DOCUMENTAZIONE (SOVRASCRITTURA)
Nell’ipotesi in cui l’utente decida di sovrascrivere i dati precedentemente inseriti, il sistema segnala
le conseguenze che l’operzazione comporta.
12. Forecast report
FIGURA 45 - FORECAST REPORT
Entrando nell’apposita sezione si possono consultare i Forecast report. Si è supposto che nel
frattempo anche le altre BU abbiano inserito la documentazione di processo che le riguarda.

67
Si rileva dalla figura sottostante che spostando il cursore del mouse sopra una colonna si può
osservare la cifra rappresentata dalla stessa.
FIGURA 46 - FORECAST REPORT (DETTAGLIO GRAFICO)
3.5.2 Funzionalità non disponibili
Nel caso in cui l’utente corrente non disponga dei diritti necessari per fruire di tutte le funzionalità
offerte, viene presentata un’interfaccia utente privata di alcune componenti. Ad esempio, si
supponga che l’utente non sia abilitato all’inserimento dei documenti e alla gestione dei Forecast;
l’interfaccia che gli sarà presentata viene mostrata nella figura sottostante.
FIGURA 47 - ESEMPIO FUNZIONALITA' LIMITATE
Come si può notare, la sidebar non include più le voci “Documentazione” e “Forecast”.
3.5.3 Valutazione responsività
Si presentano alcuni screenshots con lo scopo di illustrare come l’interfaccia utente si adatti al
cambio di risoluzione su differenti dispositivi mobile.

68
1. Test su dispositivo iPad mini(768x1024 px)
FIGURA 48 – REPORT CONFRONTO SU IPAD MINI (768X1024 PX)
Come si evince dalla Figura 48, la sidebar viene eliminata e il menu per la navigazione
dell’applicazione viene collocato in alto, nella notification bar. Per espanderlo è sufficiente premere il
pulsante in alto a destra (vedi Figura 49).

69
FIGURA 49 - INSERIMENTO DOCUMENTAZIONE SU IPAD MINI (768X1024 PX)

70
FIGURA 50 - REPORT COMPONENTI OFFERTA SU IPAD MINI (1024X768 PX)
Ruotando il dispositivo la sidebar ricompare in quanto la larghezza dello schermo è sufficientemente
grande da consentire l’utilizzo dell’applicativo in questa modalità.
Tale caratteristica è insita nel template grafico utilizzato e si avvale delle cosiddette Media Queries18
.
18
Le Media Queries sono dei moduli CSS3 che consentono alla pagina web che li include di usare diversi stili
CSS sulla base di alcune caratteristiche del device che effettua la richiesta (per la pagina medesima).

71
1. Test su dispositivo Nokia Lumia(480x800 px)
FIGURA 51 - APERTURA FORECAST SU NOKIA LUMIA (480X800 PX)

72
FIGURA 52 - FORECAST REPORT SU NOKIA LUMIA (800X480 PX)
FIGURA 53 - FORECAST REPORT SU NOKIA LUMIA (800X480 PX)

73
4 Conclusioni
4.1 Obiettivi
L’obiettivo del progetto di tesi prevedeva la progettazione e realizzazione di un’applicazione web che
consentisse il caricamento di dati aziendali su una struttura dati di supporto e la conseguente
consultazione di specifici report; regolando al tempo stesso l’accesso e le funzionalità messe a
disposizione degli utenti finali.
Gli obiettivi prefissati possono considerarsi complessivamente raggiunti, sebbene non tutti i requisiti
emersi durante la fase di analisi siano stati soddisfatti. Si tenga presente che, già in fase di
progettazione, si è valutato insieme al responsabile di progetto di trascurare alcuni dei requisiti
registrati per tenerne eventualmente conto in una seconda versione del prototipo.
Le funzionalità che si possono riscontrare nell’applicativo realizzato si possono riassumere nell’elenco
che segue.
 Upload (ed eventuale sovrascrittura) dei fogli di calcolo SFA e CoGe con conseguente
archiviazione dei dati in una base di dati relazionale.
 Consultazione dei report relativi al processo di Allineamento SFA-CoGe e di chiusura del
Forecast corrente, con possibilità di filtraggio in base a BU e Forecast (solo per l’anno
corrente).
 Gestione di apertura e chiusura Forecast.
 Autenticazione dell’utente su Active Directory.
 Discriminazione delle informazioni e delle funzionalità rese disponibili all’utente in base a
specifici criteri di visibilità.
Mentre, i requisiti non soddisfatti comprendono:
 [UR_DOC_04]: non è stata implementata la gestione delle denominazioni multiple di un
cliente;
 [UR_SUP_01]: sebbene il software sia stato realizzato in un ottica di responsività non tutti i
contenuti risultano completamente fruibili da un dispositivo mobile. Esempio di ciò sono le
scrolling list che permettono di selezionare BU e Forecast.
 [UR_USA_01]: il requisito di usabilità è stato soddisfatto solo in parte, poichè in taluni casi
l’applicativo non assiste adeguatamente l’utente durante l’utilizzo. Ad esempio, al verificarsi
di problemi legati all’upload dei fogli di calcolo anzichè fornire un errore generico il sistema
dovrebbe indicare all’utente la precisa causa del problema o, perlomeno, fornire un’ipotesi.
 [UR_AFF]: non essendo stata effettuata alcuna analisi relativa alla sicurezza del sistema il
requisito può ritenersi non soddisfatto.
4.2 Sviluppi futuri
In futuro, in un’ottica maggiormente orientata al “mobile” si potrà pensare all’introduzione di
componenti grafici progettati esclusivamente per agevolare la fruizione di contenuti attraverso
dispositivi mobili. Componenti peraltro forniti anche con le librerie di Kendo UI.

74
Si ipotizza che altri possibili sviluppi potranno derivare dall’introduzione di alcune variazioni sul
processo di monitoraggio sopra delineato; infatti, a parere dell’autore, si potrebbe trarre beneficio
(in termini di numero di operazioni da svolgere) dalle seguenti considerazioni.
 I dati potrebbero venire letti direttamente dai sistemi di supporto al management attraverso
un meccanismo di importazione automatica.
 L’applicativo potrebbe consentire la visualizzazione e l’aggiornamento dei documenti SFA e
CoGe rendendo superflua la sovrascrittura dei documenti e mantenendo al tempo stesso uno
storico delle versioni precedenti alle modifiche.
Infine, relativamente all’amministrazione del sistema, risulta quasi indispensabile un pannello di
controllo per la gestione delle utenze, dei ruoli e delle funzionalità, cosa che al momento avverrebbe
attraverso il DBMS in uso.
Si sottointende che tra i possibili sviluppi futuri sia compreso l’adempimento dei sopracitati requisiti
non soddisfatti.
4.3 Opinioni personali
La progettazione e lo sviluppo dell’applicativo in oggetto hanno permesso di scontrarsi con alcune
problematiche abbastanza frequenti nell’ambito del web development, quali:
 l’autenticazione dell’ utente e l’interazione con un un sistema di directory service;
 l’integrazione di un template grafico sviluppato da terzi e la successiva modifica di alcune
regole CSS di cui si compone;
 l’incompatibilità tra plugin sviluppati da fornitori differenti;
 la ricerca, l’analisi e l’utilizzo di librerie che consentissero la lettura di documenti esterni al
sistema.
Inoltre, uno degli aspetti più importanti del lavoro effettuato, attiene la sperimentazione e
implementazione di nuove tecnologie prima sconosciute o note in modo solo superficiale all’autore.
Compiti quali l’individuazione, lo studio e l’utilizzo di queste tecnologie, sono stati svolti in completa
autonomia, pur confrontandosi periodicamente con il tutor aziendale.
Infine, il confronto con un progetto di dimensioni considerevoli ha permesso altresì di studiare e
applicare metodologie di progettazione conosciute solo a livello teorico, come ad esempio gli Use
cases diagrams, gli Activity diagrams e i Mockup.
Da non tralasciare l’importanza derivante dall’esperienza cumulata praticando un tirocinio in un
contesto aziendale reale.
4.4 Stato attuale
L’applicativo è in fase di collaudo, una volta eseguiti i test necessari e operati gli opportuni
accorgimenti verrà sottoposto all’amministrazione centrale di Cluster Reply per una valutazione
operativa, a cui seguirà l’eventuale messa in produzione.

75
5 Bibliografia
Allen Scott, 2012. Pluralsight - Building Applications with ASP.NET MVC 4. [Online course]
Available at: http://pluralsight.com/training/Courses/TableOfContents/mvc4-building
Allen Scott, 2013. Pluralsight - ASP.NET MVC 4 Fundamentals. [Online course]
Available at: http://www.pluralsight.com/training/Courses/TableOfContents/mvc4
Allen Scott, 2013. Pluralsigth - Introduction to Bootstrap. [Online course]
Available at: http://www.pluralsight.com/training/Courses/TableOfContents/bootstrap-introduction
Bochicchio D., Mostarda S., Civera C., Golia R., 2010. ASP.NET 4.0 in C# e VB. Guida completa per lo
sviluppatore. Hoepli Editore.
KeenThemes, 2013. Metronic - Admin Dashboard Template, Documentation For Version 1.5.3.
[Online]
Available at: http://themeforest.net/item/metronic-responsive-admin-dashboard-template/4021469
Liberty Jesse, 2013. Pluralsight - Kendo and MVC From Scratch. [Online course]
Available at: http://www.pluralsight.com/training/Courses/TableOfContents/kendo-mvc-from-
scratch
Library, Microsoft MSDN, s.d. ASP.NET Session State Overview. [Online]
Available at: http://msdn.microsoft.com/en-us/library/ms178581(v=vs.100).aspx
Library, Microsoft MSDN, s.d. Directory Services Technical Articles. [Online]
Available at: http://msdn.microsoft.com/en-us/library/hh703253(v=vs.85).aspx
Library, Microsoft MSDN, s.d. Open XML SDK 2.5. [Online]
Available at: http://msdn.microsoft.com/en-us/library/office/bb448854.aspx
Library, Microsoft MSDN, s.d. Using System.DirectoryServices to Search the Active Directory. [Online]
Available at: http://msdn.microsoft.com/en-us/library/ms973834.aspx#dotnetadsearch_topic1
Library, Microsoft TechNet, 2010. Active Directory Searches Technical Reference. [Online]
Available at: http://technet.microsoft.com/en-us/library/cc728370(v=ws.10).aspx
Microsoft MSDN, Data Developer Center, s.d. Code First Data Annotations. [Online]
Available at: http://msdn.microsoft.com/en-us/data/jj591583.aspx
Ramez A. Elmasri, S. B. N., 2007. Sistemi di basi di dati. Fondamenti. Quinta edizione, a cura di:
Pearson Editore.
Rolando Guay Paz Josè, 2013. Beginning ASP.NET MVC 4, a cura di: Apress Editore.
Telerik, s.d. Complete Kendo UI Documentation. [Online]
Available at: http://docs.telerik.com/kendo-ui/

76
Vugt, W. v., 2007. Open XML The markup explained. [Online]
Available at: http://openxmldeveloper.org/cfs-filesystemfile.ashx/__key/communityserver-
components-postattachments/00-00-00-19-70/Open-XML-Explained.pdf

Studio e realizzazione di un sistema web per il monitoraggio delle previsioni di budget in processi aziendali di controllo di gestione

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Similar to Studio e realizzazione di un sistema web per il monitoraggio delle previsioni di budget in processi aziendali di controllo di gestione

Similar to Studio e realizzazione di un sistema web per il monitoraggio delle previsioni di budget in processi aziendali di controllo di gestione (20)

Studio e realizzazione di un sistema web per il monitoraggio delle previsioni di budget in processi aziendali di controllo di gestione