Studio e realizzazione di un sistema web per il monitoraggio delle previsioni di budget in processi...

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

Ai miei genitori

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;

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

8

FIGURA 2 - SCENARIO ATTUALE

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

UC-07 Apertura Forecast

Description Apertura di un nuovo Forecast. L’attivazione dell’operazione avviene cliccando l’apposito pulsante.

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. L’attivazione dell’operazione avviene cliccando l’apposito pulsante.

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

Rapporto di cardinalità 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.

Rapporto di cardinalità 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.

Rapporto di cardinalità 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.

Rapporto di cardinalità 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.

Rapporto di cardinalità 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.

Rapporto di cardinalità 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.

Rapporto di cardinalità 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.

31

2.

3.

32

4.

5.

33

6.

7.

34

8.

9.

35

10.

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.

http://it.wikipedia.org/wiki/Design_pattern

http://it.wikipedia.org/wiki/Software

http://it.wikipedia.org/wiki/Business_logic

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

http://it.wikipedia.org/wiki/Rete_informatica

http://it.wikipedia.org/wiki/Directory_service

http://it.wikipedia.org/wiki/Microsoft

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.

3.2.4 Modulo sviluppato 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.

3.3.2 Modulo sviluppato 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.

http://it.wikipedia.org/wiki/Applicazione_(informatica)

http://it.wikipedia.org/wiki/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...

Technology

Transcript of Studio e realizzazione di un sistema web per il monitoraggio delle previsioni di budget in processi...