la gestione delle informazioni nella just-in-time … · corso di laurea specialistica in...

POLITECNICO DI MILANO

Facolta di Ingegneria dell’Informazione

Corso di Laurea Specialistica in Ingegneria Informatica

LA GESTIONE DELLE INFORMAZIONI

NELLA JUST-IN-TIME ORGANIZATION

Relatore: Prof. Alfonso Fuggetta

Correlatore: Ing. Giordano Sassaroli

Tesi di Laurea di:

Giulio Presazzi, matricola 731977

Matteo Valoriani, matricola 736188

Anno Accademico 2010-2011

Ai compagni di questa lunga avventura...

Sommario

Per un’impresa moderna e competitiva e importante avere una visione com-

pleta e aggiornata delle prestazioni e dell’andamento del proprio business.

La Just-In-Time Organization e una filosofia organizzativa che si concentra

sugli aspetti di gestione e analisi delle informazioni al fine di massimizzare

l’efficienza e l’efficacia dell’azienda. Ricevere dati in tempo reale, aiuta il

management a tenere sempre sotto controllo la situazione aziendale, piani-

ficare al meglio le strategie future e risolvere prontamente i problemi che si

presentano. L’ IT puo venire incontro a queste esigenze e fornire strumenti

efficaci e valide soluzioni. Il nostro lavoro parte da questa considerazione

per fornire una soluzione tecnologica in grado aiutare l’azienda. La soluzio-

ne che proponiamo permette l’analisi delle performance aziendali con una

bassa latenza e aiuta prendere decisioni in modo tempestivo. La tecnologia

negli ultimi anni ha subito enormi cambiamenti, in particolare ha visto la

nascita di interfacce innovative e nuovi meccanismi di interazione. Nel no-

stro lavoro abbiamo ripensato queste tecnologie per adattarle alle esigenze

aziendali e fornire dispositivi al supporto delle attivita di business che siano

funzionali e allo stesso tempo innovativi. Il lavoro e stato svolto all’interno di

CEFRIEL societa che svolge attivita di formazione e di consulenza ad alto li-

vello tecnologico e che da anni si e indirizzata verso un modello organizzativo

”Just-In-Time” e quindi gia dotata di un buon livello di informatizzazione.

I

Partendo dall’analisi dell’attuale modello di gestione delle attivita aziendali e

dalle esigenze espresse dai manager, abbiamo sviluppato un sistema integrato

con gli altri gia disponibili, ma che permette di raccogliere e distribuire infor-

mazioni su vari canali in tempo reale, migliorando la capacita di monitorare

lo stato di salute dell’azienda.

Ringraziamenti

Ogni minuto che passi arrabbiato perdi sessanta secondi di felicita

Albert Einstein

Desidero innanzitutto ringraziare il Professor Alfonso Fuggetta per averci

dato la possibilita di svolgere questa tesi all’interno di Cefriel.

Inoltre, ringrazio sentitamente l’Ing. Giordano Sassaroli per la disponibilita

e professionalita e per averci aiutato e indirizzato in questi mesi di lavoro.

Intendo poi ringraziare tutti i coloro che in azienda ci hanno sostenuto e

aiutato: Ing. Fabiano Cattaneo e tutti i responsabili dell’area tecnica.

Ringrazio Matteo, il compagno di tesi. Grazie che hai voluto collaborare

con me in questo lavoro aiutandomi anche nel mio Italiano ’Valtellinese’.

Nonostante ritardi storici e immisurabili ce l’abbiamo fatta.

Un ringraziamento di cuore e per i miei genitori, Fabio e Maria che 5

anni fa mi hanno permesso di iniziare questa esperienza, mi sono stati vicino

mi hanno sostenuto, moralmente ed economicamente: due persone rare e in-

sostituibili. Papa grazie per la tua tranquillita, disponibilita, bonta d’animo e

umilta. Mamma grazie per la tua voglia di fare, il tuo volermi bene(o gelosia

:D) e per tutte le volte che mi hai permesso di non andare a lavorare rinun-

ciando tu ai tuoi momenti :-D .Ringrazio Elena, la mia ’sorellina’ (non ti ho

mai chiamato sorellina vero? ) che con il suo ottimismo mi ha permesso di

vedere il mondo con occhi diversi. Un ringraziamento sentito a una persona

che e entrata attivamente nella mia vita da quasi un anno ormai ma e co-

me se ci fosse da sempre, donandomi tanta felicita e amore. Grazie Giulia,

anche se alle tue richieste rispondo ”Signorsı signore” lo faccio sempre con

piacere;-).

III

Grazie a tutti i miei parenti che mi hanno sempre sostenuto e incoraggiato

in questa esperienza. Un grazie particolare va al mitico nonno Luigi e alla

nonna Pina, come avrei fatto senza di voi? Grazie perche il vostro affetto mi

rimarra per sempre nel cuore. Grazie per le ”mancette” segrete, grazie per

la vostra semplicita, comprensione e bonta.

Un grazie a Massimo e Morena e a tutto lo staff della ”Tana del Grillo”,

compagni di viaggio in questi 5 anni. Siete stati indispensabili da punto di

vista economico, ma la vostra umanita e disponibilita non la dimentichero

mai. Se nei prossimi impieghi avro dei ”padroni” antipatici mi faro rivedere

:-).

Vorrei ringraziare i miei compagni di sempre. Un grazie a Luca, il Fox, il

mio compagno di stanza (e non solo) per tutta questa esperienza. La tua vo-

glia di uscire vincente, il tuo essere razionale, la voglia di divertirsi ed essere

felici ci ha tenuti legati per tutto questo tempo. Grazie ai miei coinquilini, di

oggi e di ieri. Grazie Davide, spero di esserti d’aiuto quanto tu lo sei stato

per me; Mariuccio grazie per i tuoi consigli da vero genietto; Checo grazie

per la tua voglia di divertirti e per i progetti fatti insieme :-). Speriamo di

divertirci e passare momenti indimenticabili come lo sono stati questi mesi.

Grazie a Fabio e Oscar, gli amici di vecchia data. Fabio grazie per la tua

semplicita, spero che avrai tutto il successo che una persona come te merita.

Grazie Oscar, insieme abbiamo girato il ”Mondo” passando momenti indi-

menticabili, la Valtellina ci rimane comunque nel cuore. Grazie alle ragazze

del piano di sotto: Sara A (Saretta ovviamente), Sara B, Caterina, Anna,

Stefania. Grazie ai miei colleghi o ex colleghi universitari e Milanesi: Davide

Staky, Marta la Grosina, Max, Leo e Marco (i dottorandi Fiorentini), Pippo

(il nerd del Micro), Trive, Gigio, Davide, Laura, Alessandra, Guido e Fa-

bio(Airo). Grazie a Callo (Alby o Alberto), compagno di viaggi responsabili,

nel bene, di un’esperienza fantastica.

Grazie a tutti coloro che hanno creduto in me. A quelli che mi incon-

travano lungo la strada e mi chiedevano: ”Come va l’universita ?”. Adesso

finalmente posso rispondere:”E’ finita”. E un po’ e anche merito vostro.

Giulio

Ringraziamenti

Il miglior modo per iniziare a cambiare il mondo,

e iniziare a immaginare un mondo diverso.

Wow, non mi sembra possibile! Sto scrivendo i ringraziamenti della mia

tesi!

Sono passati cinque anni come fossero cinque secondi. Ricordo benissimo il

primo giorno a Milano, un giorno grigio di fine settembre, pioveva e dopo

aver lasciato la mi bella casetta mi sono ritrovato da solo in una stanza semi-

buia e piu grigia del cielo che si intravedeva dalla tapparella rotta. Certo che

come partenza non e stata delle migliori e chi avrebbe pensato che quello fos-

se l’inizio di tutta questa lunga avventura. Ho conosciuto cosı tante persone,

amici, che la lista dei ringraziamenti mi sembra interminabile e penso che

la cosa migliore sia ripercorrere con la mente questi cinque anni per cercare

di non dimenticare nessuno. Il primo giorno di universita mi trovavo seduto

accanto a un valtellinese, il primo che ho conosciuto di una lunga serie, e

un brianzolo fissato con i puntatori. Oggi dopo cinque anni mi capita ancora

di trovarmi seduto con quelle stesse persone: Mari(ucci)o Filipp(iell)o gra-

zie, senza di voi sarebbero stati molto noiosi questi anni di universita. Loro

sono stati i primi che ho conosciuto, ma subito dopo si sono aggiunti molti

altri a partire Marco(Trivellino) e dal branco valtellinese: Luca, Max, Fabio

e Giulio, che mi ha sopportato anche in questa tesi. Naturalmente non posso

dimenticarmi di Oscar con cui ho condiviso esami e serate estenuanti.

In questi anni non c’e stata solo l’universita e non posso non ringraziare i

tanti amici conosciuti nel collegio, con molti dei quali ho condiviso anche una

casa: Flavio, Mauro, Felice, Giovanni, Domenico, Stefano grazie a tutti per

V

avermi fatto compagnia nei miei caffe notturni.

Il bello dell’amicizia e che e una rete che tende ad allargarsi sempre di piu

per accogliere nuove persone e molte altre meritano di essere ringraziate. In-

nanzitutto il lato femminile del corso Marta, Laura, Sara e Alessandra, e poi

ancora Gigio, Davide, Staky e i miei compagni toscani Marco e Leo che mi

avete aiutato a difendermi dalla colonia valtellinese. Una colonia che con

gli anni e diventata sempre piu grande con Sara, Anna, Stefania, Caterina,

Claudio, Francesca, Davide,... grazie a tutti per le divertentissime serate.

Oltre a loro ci sono anche gli amici conosciuti nelle partite di calcetto e la-

vorando a Roma, tutte persone che hanno lasciato un segno in questi cinque

anni.

In questi anni sono cambiate molte cose, sono cambiato io, ma per fortuna

l’amicizia con i vecchi amici Laura, Giulia, Tommaso non e cambiata, grazie.

Arrivando a giorni piu recenti devo ringraziare anche Alfonso Fuggetta che

ci ha accettati come suoi tesisti e Giordano Sassaroli e Fabiano Cattaneo che

ci hanno seguito nello sviluppo di questo lavoro. Ringrazio anche Carlo Ian-

torno che mi ha dato l’opportunita di lavorare in Microsoft dove ho imparato

moltissimo e ho capito un po’ di piu come va il modo fuori dall’universita.

Infine, il ringraziamento piu speciale di tutti va alla mia famiglia: alla mia

Mamma, al mio Babbo e alla mia Taty. Mi avete sempre sorretto e spin-

to avanti senza mai chiedermi nulla, sono quello che sono oggi per merito

vostro. Grazie anche a tutti i parenti e amici che mi hanno sostenuto fisica-

mente con le loro leccornie culinarie.

Questa avventura e finita, non so cosa ci sara domani come non lo sa nes-

sun’altro, ma sicuramente non ho rimpianti per il passato e sono felice per

tutto quello che abbiamo fatto insieme e sono certo che le amicizie strette in

questi anni non svaniranno nel nulla.

A tutti ancora un immenso grazie.

Matteo

Indice

Sommario I

Ringraziamenti Giulio III

Ringraziamenti Matteo V

1 Introduzione 1

1.1 Il contesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Obiettivi della tesi . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Stato dell’arte 7

2.1 La filosofia Just-In-Time . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 JIT Organizations: un’azienda moderna . . . . . . . . 9

2.1.2 Informazioni nella JIT Organizations . . . . . . . . . . 12

2.2 Le tecnologie di presentazione e interazione . . . . . . . . . . . 14

2.2.1 Tecnologie desktop . . . . . . . . . . . . . . . . . . . . 15

2.2.2 Tecnologie mobile . . . . . . . . . . . . . . . . . . . . . 18

2.2.3 Tecnologie entertainment . . . . . . . . . . . . . . . . . 23

3 Proposte per l’impresa Just in Time 27

3.1 La struttura organizzativa di riferimento . . . . . . . . . . . . 28

IX

3.2 Realizzare un’impresa Just-In-Time . . . . . . . . . . . . . . . 31

3.3 Informazioni rilevanti . . . . . . . . . . . . . . . . . . . . . . . 33

3.3.1 Gli utenti . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.3.2 Scenari d’uso . . . . . . . . . . . . . . . . . . . . . . . 37

3.3.3 Il modello di riferimento . . . . . . . . . . . . . . . . . 38

4 Architettura del Sistema 41

4.1 Presentazione dell’architettura . . . . . . . . . . . . . . . . . . 41

4.2 Modello three tier . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2.1 Data Access Layer (DAL) . . . . . . . . . . . . . . . . 44

4.2.2 Layer della logica . . . . . . . . . . . . . . . . . . . . . 45

4.2.3 Presentation and Interation Layer(PIL) . . . . . . . . . 47

4.2.4 Considerazioni . . . . . . . . . . . . . . . . . . . . . . . 49

4.3 Aspetti di sicurezza . . . . . . . . . . . . . . . . . . . . . . . . 49

5 Caso di Studio: CEFRIEL 53

5.1 Descrizione del caso di studio . . . . . . . . . . . . . . . . . . 53

5.1.1 Il CEFRIEL . . . . . . . . . . . . . . . . . . . . . . . . 54

5.1.2 Il modello organizzativo . . . . . . . . . . . . . . . . . 55

5.1.3 Il sistema di controllo e gestione progetti . . . . . . . . 56

5.1.4 Contesto tecnologico . . . . . . . . . . . . . . . . . . . 57

5.2 Esigenze aziendali . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.1 Casi d’uso: Professional . . . . . . . . . . . . . . . . . 58

5.2.2 Casi d’uso: Project Manager . . . . . . . . . . . . . . . 60

5.2.3 Casi d’uso: Account Manager . . . . . . . . . . . . . . 62

5.2.4 Casi d’uso: Head of Division . . . . . . . . . . . . . . . 62

5.3 Architettura di back-end . . . . . . . . . . . . . . . . . . . . . 63

5.3.1 Layer di accesso ai dati . . . . . . . . . . . . . . . . . . 64

5.3.2 Layer logico . . . . . . . . . . . . . . . . . . . . . . . . 71

5.3.3 Analisi dei dati . . . . . . . . . . . . . . . . . . . . . . 76

5.3.4 Comunicazione . . . . . . . . . . . . . . . . . . . . . . 79

5.3.5 Sicurezza del sistema . . . . . . . . . . . . . . . . . . . 83

5.4 I client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5.4.1 Pattern Model-View-View-Model (MVVM) . . . . . . . 88

5.4.2 Front-end desktop . . . . . . . . . . . . . . . . . . . . . 92

5.4.3 Front-end mobile . . . . . . . . . . . . . . . . . . . . . 98

5.4.4 Front-end gestuale . . . . . . . . . . . . . . . . . . . . 100

6 Direzioni future di ricerca e conclusioni 105

6.1 Piloting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

6.2 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.3 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

6.3.1 Sviluppi futuri per il back-end . . . . . . . . . . . . . . 110

6.3.2 Sviluppi futuri per il front-end . . . . . . . . . . . . . . 112

Bibliografia 113

A Tabella comparativa tra piattaforme mobile 117

B Database Gedi Alert 121

C Stati di Progetto 125

Elenco delle figure

2.1 Esempi di alcuni Widget installati su un PC . . . . . . . . . . 16

2.2 Esempi di Pinned Site . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Microsoft Surface . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4 iOS4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5 Windows Phone 7 . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.6 Android 2.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.7 Wii mote e Wii sensor bar . . . . . . . . . . . . . . . . . . . . 24

2.8 Kinect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1 Modello di riferimento . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Ciclo di sviluppo del sistema . . . . . . . . . . . . . . . . . . . 35

3.3 Utenti del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.4 Modello di riferimento . . . . . . . . . . . . . . . . . . . . . . 39

4.1 Componenti dell’architettura . . . . . . . . . . . . . . . . . . . 42

4.2 Architettura a tre livelli . . . . . . . . . . . . . . . . . . . . . 43

4.3 Architettura del Presentation Layer . . . . . . . . . . . . . . . 48

5.1 Schema dell’architettura attuale in CEFRIEL . . . . . . . . . 57

5.2 Use Case Professional . . . . . . . . . . . . . . . . . . . . . . . 59

5.3 Use Case Project Manager . . . . . . . . . . . . . . . . . . . . 61

5.4 Use Case Head of Division . . . . . . . . . . . . . . . . . . . . 63

XIII

5.5 Architettura del sistema nel dettaglio . . . . . . . . . . . . . . 64

5.6 Schema ER di GEDI ALERT . . . . . . . . . . . . . . . . . . 65

5.7 Class Diagram DAL . . . . . . . . . . . . . . . . . . . . . . . 66

5.8 Class Diagram Package CGP . . . . . . . . . . . . . . . . . . . 67

5.9 Esempio Sequence Diagram per chiamata a DAL . . . . . . . . 68

5.10 Business Logic Layer nel dettaglio . . . . . . . . . . . . . . . . 72

5.11 Esempio Sequence Diagram per chiamata a BLL . . . . . . . . 73

5.12 Class diagram del package DataContract . . . . . . . . . . . . 74

5.13 Class diagram del package Analysis . . . . . . . . . . . . . . . 78

5.14 Architettura del web service nel dettaglio . . . . . . . . . . . . 79

5.15 Esempio di utilizzo WCF . . . . . . . . . . . . . . . . . . . . . 81

5.16 Struttura di un servizio WCF . . . . . . . . . . . . . . . . . . 82

5.17 Integrate Windows Authentication (Kerberos v5) . . . . . . . 85

5.18 Scambio di messaggi utilizzando HTTPS . . . . . . . . . . . . 86

5.19 Pattern MVVM . . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.20 Pattern MVVM nell’architettura . . . . . . . . . . . . . . . . 91

5.21 Class diagram delle classi che implementano il MVVM . . . . 92

5.22 Gedi Gadget . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.23 Gedi Gadget in due istanze . . . . . . . . . . . . . . . . . . . . 93

5.24 Inserimento e consuntivazione Professional . . . . . . . . . . . 94

5.25 Visualizzazione dettagli progetti per PM . . . . . . . . . . . . 95

5.26 Pagina di dettaglio per i capi divisione . . . . . . . . . . . . . 97

5.27 Pagina di invio di avvisi . . . . . . . . . . . . . . . . . . . . . 97

5.28 Home GEDI Windows phone 7 . . . . . . . . . . . . . . . . . 100

5.29 Pagina Iniziale GEDI kinect . . . . . . . . . . . . . . . . . . . 103

5.30 Selezione dei progetti . . . . . . . . . . . . . . . . . . . . . . . 103

5.31 Selezione del report . . . . . . . . . . . . . . . . . . . . . . . . 103

6.1 Grafico dei giorni di inserimento dei consuntivi distribuito in

un anno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

6.2 Grafico dei giorni di inserimento dei consuntivi distribuito su

sei mesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

6.3 Totale consuntivi inseriti raggruppati per giorno del mese . . . 107

6.4 Modello di riferimento - Caratteristiche coperte dal front-end

desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108


mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109


gestuale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Elenco delle tabelle

5.1 Tabella dei contesti per il Professional . . . . . . . . . . . . . 60

5.2 Tabella dei contesti per il Project Manager . . . . . . . . . . . 62

5.3 Tabella dei contesti per il Head of Division . . . . . . . . . . . 63

B.2 Campi della tabella Alert . . . . . . . . . . . . . . . . . . . . . 122

B.4 Campi della tabella Tipo . . . . . . . . . . . . . . . . . . . . . 123

XVII

Acronimi e abbreviazioni

CIA Confidentiality, Integrity and Availability

DAL Data Access Layer

EBA Enterprice Business Architecture

ETL Extract, Transform, Load

GEDI Graphical Enterprise Data Integrator

IIS Internet Information Service

JIT Just in Time

MVP Model-View-Presenter

MVVM Model-View-View-Model

OpenNI Open Natural Interface

SAL Stato Avanzamento Lavori

WIP Work in Progress

WCF Windows Communication Foundation

WPF Windows Presentation Foundation

XAML eXtensible Application Markup Language

XIX

Capitolo 1

Introduzione

”The advantage lies not with first movers

but with first movers that can scale up their activities once

the way forward has become clear”

Lowell L. Bryan

Per fronteggiare un mercato sempre piu complesso e dinamico, le imprese

devono aggiornare i propri prodotti, servizi e processi. La variabile tempo,

in questo contesto, gioca un ruolo fondamentale: le aziende infatti devono

prevedere e anticipare le possibili minacce di mercato, preparandosi ad af-

frontarle con le risorse disponibili. In quest’ottica, la tecnologia diventa un

indispensabile asset per tutte le aziende che vogliano tornare a competere nel

mondo post-crisi.

1.1 Il contesto

I due fattori che incidono da sempre sulle decisioni e le strategie aziendali

sono l’analisi del mercato e il monitoraggio delle performances dell’impresa:

2 Capitolo 1. Introduzione

nel primo caso le informazioni provengono dall’esterno, mentre nel secondo

dal funzionamento delle attivita interne. Con l’accelerare delle dinamiche

di mercato su scala globale, ma anche delle dinamiche interne dell’azienda,

risulta sempre piu difficile essere in grado di tenere sotto controllo, in tempi

brevi, tutte le variabili in gioco.

La Just-In-Time Organization e una filosofia organizzativa che vuole mas-

simizzare l’efficienza e l’efficacia dell’azienda nel gestire e analizzare le infor-

mazioni rilevanti per il proprio business. Per fare cio, la JIT organizzation

si concentra su tre aspetti: l’organizzazione dell’azienda, i processi e la tec-

nologia. In particolare, la tecnologia puo venire incontro alle esigenze delle

aziende e fornire soluzioni e strumenti che facilitino la raccolta, l’analisi, la

condivisione e la presentazione delle informazioni.

In questo contesto, la diffusione di tecnologie innovative sta rivoluzio-

nando la tradizionale interazione tra uomo e macchina e nuovi interessanti

scenari si presenteranno nei prossimi anni. L’obiettivo della nostra ricerca e

quello di valutare in contesti diversi quale puo essere un modo efficace di pre-

sentare all’utente le informazioni rilevanti di cui ha bisogno, per determinare

eventuali minacce o criticita aziendali.

1.2 Obiettivi della tesi

Obiettivo di questo lavoro e riuscire a proporre una soluzione che permetta

di analizzare le performance dell’azienda con una bassa latenza e di prende-

re decisioni in modo tempestivo, il tutto introducendo costi o infrastrutture

contenute e coerenti con le dimensioni dell’impresa, ma garantendo la scala-

bilita della soluzione nel futuro. I dati generati dal sistema devono essere il

piu possibile coerenti con lo stato dell’impresa e facilmente accessibili in ogni

1.2. Obiettivi della tesi 3

momento e in ogni luogo.

Fondamentale per il raggiungimento di questo obiettivo e sfruttare in ba-

se al contesto le piu recenti e innovative tecnologie. Infatti, nel corso del

lavoro abbiamo dedicato particolare attenzione a capire quali fossero le esi-

genze delle persone che avrebbero utilizzato il nostro sistema in tre diversi

contesti: quando l’utente e seduto in ufficio davanti al proprio PC, quando e

in mobilita e quando e in riunione con i propri colleghi o con i partner azien-

dali. Per ognuno di questi contesti abbiamo scelto tra le piu interessanti

tecnologie disponibili, quella piu adatta a soddisfare le esigenze dell’uten-

te. Nel complesso, l’obiettivo del lavoro e quello di favorire l’inserimento,

l’aggiornamento e la visualizzazione delle informazioni tramite un sistema

multipiattaforma e multicanale.

Lo studio preliminare e iniziato con l’analisi dell’organizzazione interna

di due aziende particolarmente attente al tema di questa tesi, Microsoft Cor-

poration(oltre 300 sedi nel mondo) e CEFRIEL, e ci ha permesso di astrarre

un primo modello di organizzazione interna di riferimento. Le interviste con

alcuni responsabili delle due societa hanno fatto emergere le esigenze e i pro-

blemi rilevanti per le aziende, in particolare in ambito di organizzazione e

gestione delle informazioni e, inoltre, ci ha permesso di validare il nostro

modello di riferimento con le loro esperienze dirette con partner e clienti.

Partendo dallo studio fatto, abbiamo realizzato un’architettura software

e dei tools che aiutassero le aziende a risolvere alcuni dei problemi che ci

sono stati segnalati e infine abbiamo sviluppato un prototipo che potesse va-

lidare il nostro lavoro. L’azienda che ha accettato di essere il nostro caso di

studio e sperimentare il nostro prototipo e il CEFRIEL, societa di eccellenza

per l’innovazione, la ricerca e la formazione nel settore dell’Information &

Communication Technology, che svolge un’attivita lavorativa basata su pro-


getti e che necessita di avere dati il piu possibile aggiornati sullo stato di

avanzamento dei lavori, per rispettare i vincoli di tempo e di costo.

Il prototipo realizzato conferma la buona flessibilita dell’architettura e

l’effettiva efficacia della nostra proposta. Lo studio attento della struttura

organizzativa permette anche di replicare la nostra soluzione in altre aziende.

Inoltre, le scelte progettuali adottate permettono una buona modularizza-

zione del prototipo, per questo motivo le future implementazioni potranno

riusare facilmente le caratteristiche gia introdotte da noi.

1.3 Struttura della tesi

Questo lavoro di laurea e strutturato come segue:

• Nel capitolo 2 si introduce la Just in Time Organization e l’importanza

di questo tipo di organizzazione nelle imprese moderne. Vengono inoltre

analizzate alcune tra le piu recenti e innovative tecnologie di interazione

tra uomo e macchina per la presentazione delle informazioni.

• Nel capitolo 3 vengono analizzate le problematiche che un’impresa deve

affrontare per avvicinarsi alla Just in Time Organization in termini di

tipologia di informazioni e aree di impatto e vengono descritte quali

sono le esigenze che la tecnologia deve soddisfare.

• Nel capitolo 4 si illustrano le scelte effettuate con le motivazioni che

hanno portato a sviluppare questa architettura software.

• Nel capitolo 5 si analizza come l’architettura descritta nella sezione pre-

cedente e stata calata nel contesto d’uso reale del CEFRIEL. Si descri-

vono alcuni aspetti interessanti dell’implementazione e il suo impiego

in alcuni scenari significativi.

1.3. Struttura della tesi 5

• Nel capitolo 6 sono ricapitolati i risultati ottenuti, analizzandone i

principali vantaggi e proponendo possibili sviluppi futuri.

Capitolo 2

Stato dell’arte

”In short, the just-in-time inventory system focus is having

the right material, at the right time, at the right place,

and in the exact amount, without the safety net of inventory.”

Ryan Grabosky

In questo capitolo sara analizzato lo stato dell’arte dei due ambiti di ricerca

principali di questa tesi: la gestione efficiente di una azienda e le nuove tec-

nologie di interazione tra uomo e macchina. Si cerchera anche di evidenziare

come questi due aspetti possono essere legati

2.1 La filosofia Just-In-Time

La filosofia industriale JIT, spesso abbreviata Just in Time (JIT), nasce

ai primi del 1900 negli stabilimenti della Ford Motor Company negli USA

per ottimizzare la produzione e la consegna di automobili, permettendo di

ridurre la durata del ciclo di produzione da ventuno a soli quattro giorni.

Purtroppo, questo ”Just-In-Time” di tipo manifatturiero lascio ben presto il

7

8 Capitolo 2. Stato dell’arte

posto a magazzini molto grandi e lunghi tempi di ciclo dettati dalle economie

di scala della produzione di massa. Adottato intorno al 1950 in Giappone,

a meta degli anni ’70 il JIT divenne elemento fondamentale e di successo

del Toyota Production System, tant’e che molte aziende continuano a fare

riferimento al JIT come il sistema Toyota. La notevole attenzione rivolta a

identificare e a correggere potenziali problemi che potessero generare forme

di rifiuti, porto ad aumentare la produttivita e la resa.Come risultato, Toyota

e riuscita a ridurre il tempo necessario per produrre una vettura da quindici

giorni a un giorno.Tra la fine degli anni ’80 e i primi anni ’90, la filosofia

ispirata al JIT fu divulgata e applicata anche in occidente e inglobata nel

concetto di Lean Production[30][27].

La filosofia industriale JIT e un insieme di principi e pratiche orientati

al raggiungimento di un elevatissimo livello di efficienza[1] e qualita, basati

sull’idea che le imprese dovrebbero ridurre al massimo le scorte, immagaz-

zinando solo il necessario per la produzione o la distribuzione immediata:

qualsiasi scorta di materiale, semilavorato o prodotto finito e uno spreco,

uno spreco di risorse economiche, finanziarie e un vincolo all’innovazione

continua. Piu il processo e corto nella somma dei processi di progettazione

e di produzione e piu l’industria con i suoi prodotti e servizi e vincente.

In pratica, si tratta di coordinare i tempi di effettiva necessita dei materia-

li sulla linea produttiva con la loro acquisizione e disponibilita nel segmento

del ciclo produttivo e nel momento in cui debbono essere utilizzati, ma cio

significa che un produttore dovrebbe ricevere materie prime o parti dai suoi

fornitori poche ore prima che siano utilizzate e che il prodotto finito dovreb-

be essere spedito ai clienti appena dopo la realizzazione, senza dover tenere

stock delle materie prime o prodotti finiti. Quindi, sono necessarie un cer-

to numero di condizioni supplementari per l’efficace attuazione del JIT, tra

2.1. La filosofia Just-In-Time 9

queste sono incluse lotti di piccole dimensioni, tempi brevi di setup dei mac-

chinari, controlli di qualita efficienti ed efficaci, e forse piu di tutti, progettare

l’intero processo di produzione per ridurre al minimo i backup e ottimizzare

l’efficienza del lavoro umano e macchina. Il just in time abbina elementi

quali affidabilita, riduzione delle scorte e del lead time, ad un aumento della

qualita e del servizio al cliente[18]. In tal modo si riducono enormemente i

costi di immagazzinaggio, gestione, carico e scarico di magazzino.

2.1.1 JIT Organizations: un’azienda moderna

La globalizzazione e la tecnologia stanno spazzando via i modelli del mercato

e dell’industria che, storicamente, hanno definito la natura della concorrenza.

Anche se il ritmo del cambiamento continua ad accelerare, le fondamentali

trasformazioni in atto nell’economia mondiale sono appena all’inizio[9]. Le

variabili che possono influenzare profondamente il successo e il fallimento

sono troppo numerose per essere contate e cio rende impossibile prevedere

con certezza in quali mercati una societa sara collocata o come essa sara

strutturata, anche solo fra qualche anno. Il risultato e un ambiente economico

che e ricco di opportunita, ma anche segnato da un aumento sostanziale del

rischio.

In questo mercato sempre piu complesso e dinamico, per un’impresa e

importante monitorare in tempi rapidi l’andamento delle proprie prestazio-

ni perche offre la possibilita di rimanere al passo con i tempi e reagire in

modo rapido ai cambiamenti. Cio richiede che le imprese si dotino di mo-

delli decisionali e operativi che le rendano capaci di cogliere e interpretare

correttamente tutti i segnali e le informazioni sull’andamento del mercato e

dell’impresa stessa, in tempi molto piu rapidi rispetto al passato. In parti-

colare, la variabile tempo gioca un ruolo di primaria importanza: le imprese


devono essere in grado di rispondere con estrema rapidita agli stimoli esterni,

prevedendo e anticipando potenziali criticita e minacce, e valorizzando tem-

pestivamente tutte le opportunita che si presentano loro[8]. In quest’ottica,

diventano fondamentali due aspetti della raccolta e analisi delle informazio-

ni: la conoscenza approfondita delle dinamiche del mercato e il monitoraggio

proattivo e continuo delle performance dell’impresa stessa. Nel primo, l’ana-

lisi e incentrata su fattori esterni all’impresa, mentre nel secondo e focalizzata

sul funzionamento dell’impresa in tutte le sue parti e ogni aspetto deve essere

analizzato in modo organico e possibilmente in real-time, cosı da permettere

una veloce e tempestiva individuazione delle opportune strategie correttive

e preventive.

Un’analogia tratta da [6] puo aiutare a capire l’importanza della conoscen-

za in periodi di grande incertezza come quello che stiamo vivendo. Prendiamo

due corridori, uno e piu veloce rispetto all’altro e ci si puo aspettare che vinca

sempre su una pista piana, non importa quante volte la gara e ripetuta. Ma

cosa succede se la gara si svolge durante la notte su un percorso disseminato

di rocce e alberi caduti? Supponiamo anche che il corridore piu lento abbia

percorso la pista sia di giorno che di notte, mentre il piu veloce non si e

preoccupato di vedere il percorso in anticipo. Il corridore con la conoscenza

superiore sarebbe probabilmente il vincitore anche se l’altro fosse molto piu

veloce. Inoltre, se il premio in denaro dovesse aumentare, aumenterebbe pure

il valore della conoscenza.

Per raggiungere il livello di efficienza e di conoscenza di cui l’azienda

ha bisogno, si puo reinterpretare il paradigma Just-In-Time, ormai diffuso

in abito manifatturiero, per calarlo nel contesto dei processi di produzione e

analisi dei dati di qualsiasi impresa. L’obiettivo che l’azienda deve perseguire

per essere una Just-In-Time Organization e quello di realizzare un’organiz-


zazione agile e flessibile. La struttura interna deve essere basata su processi

che permettano di raccogliere, analizzare e organizzare in modo organico e

coerente dati provenienti da varie fonti, sia interne che esterne all’azienda,

al fine di monitorare in real-time le proprie performance e dare indicazioni

sulle azioni strategiche da intraprendere.

Se una definizione di Just-In-Time in abito manufatturienro puo essere:

The right material, at the right time, at the right place, and

in the exact amount

in questo nuovo contesto puo quindi essere cosı riletta:

The right information, at the right time, at the right place,

and in the exact amount.

La tecnologie IT a tutti i livelli e la chiave per la creazione dell’infrastrut-

tura abilitante alla JIT Organization, ma deve tenere conto delle principali

criticita del campo in considerazione e cercare di fornire uno strumento che

risponda a quattro requisiti di qualita delle informazioni fondamentali: Time-

liness, Accuracy, Focus e Efficiency. Infatti, per prendere decisioni efficaci,

e indispensabile basarsi su informazioni allineate con l’attuale stato dell’or-

ganizzazione e quindi ottenute tramite strumenti che riducano al minimo

i tempi di latenza. Non solo il fattore tempo e importante, ottenere dati

accurati e completi e importante per ”non sbagliare rotta”, quindi l’architet-

tura IT deve cercare di prevenire l’introduzione di dati errati e evidenziare

possibili errori. Inoltre, vista la grande quantita di informazioni che possono

essere raccolte e indispensabile avere un meccanismo di aggregazione dei dati

e identificare degli indicatori di sintesi significativi. Infine, la raccolta e l’a-

nalisi dei dati non deve introdurre un effort eccessivo rispetto alle dimensioni


e alle esigenze dell’impresa, al fine di non ostacolare le funzioni primarie di

business.

Visti questi requisiti, e indispensabile per l’azienda che voglia seguire la

filosofia Just-In-Time partire da un’architettura informativa che comprenda

cinque aspetti fondamentali. Il primo livello e costituito dalle sorgenti dati

che memorizzino e gestiscono i dati, che devono essere affidabili e garanti-

re l’accessibilita ai dati in qualsiasi istante. Visto che le sorgenti dati sono

spesso incoerenti tra loro, e indispensabile un secondo livello logico, solita-

mente definito Extract, Transform, Load (ETL), che elabori e riconcili tra

loro i dati. I dati riconciliati, devono essere aggregati per ricostruire una

base informativa integra e capace di tenere tutta la serie storica dei dati, su

cui fare analisi e interrogazioni complesse e questi compiti sono solitamente

affidati a un livello di Datawarehouse e uno di Business Analysis. Infine, e

indispensabile non trascurare il livello di Presentation perche e cio che fa la

differenza tra un discreto sistema e un ottimo sistema, inoltre, come sara

evidenziato meglio in 2.2, negli ultimi anni e cambiato notevolmente il modo

di fruire le informazioni e si sono aperti interessanti scenari che non possono

essere trascurati.

2.1.2 Informazioni nella JIT Organizations

La vera sfida che le aziende dovranno affrontare nei prossimi anni, non sara

solo diventare imprese JIT, ma diventare capaci di collaborare e condividere

informazioni Just-In-Time, sia all’interno che all’esterno dell’azienda.

Negli ultimi venti anni si e vista una progressiva integrazione dei sistemi

informativi aziendali con quelle dei fornitori e dei clienti, spesso per migliorare

la gestione dei magazzini e ottimizzare la gestione della produzione. Perche


non rendere disponibile ai partner dell’azienda anche informazioni sullo stato

di avanzamento dei progetti condivisi?

Tutte le piu moderne aziende hanno sistemi, piu o meno efficaci, di repor-

tistica avanzata integrata con sistemi di datawarehouse che forniscono grafici

sui bilanci, sullo stato di avanzamento dei progetti e su molti altri KPI. Una

buona parte di queste informazioni e spesso condivisa manualmente con i vari

partner aziendali, e questo oltre sottrarre tempo per attivita piu rilevanti per

l’azienda non consente di avere mai a disposizione il dato piu aggiornato. Le

imprese che vorranno veramente innovare e rinnovarsi dovranno nei prossimi

anni incrementare la condivisione in tempo reale di informazioni coi i propri

partner, perche questo permette di avere non solo una visione accurata, com-

pleta e istantanea dello stato interno dell’azienda, ma anche dell’ecosistema

extra-aziendale che la circonda.

Un problema spesso evidente, ma trascurato in molte aziende, e quello

legato alla condivisione delle informazioni a tutti i livelli aziendali. Infatti, se

i top-manager riescono solitamente ad avere una buona visibilita dello stato

dell’azienda, scendendo nella piramide aziendale si perde la possibilita di

avere una visione, anche parziale, dello stato dell’azienda a livello operativo.

Capita cosı che i dipendenti non abbiano alcun modo di sapere se i progetti su

cui stanno lavorando hanno dei ritardi o sono stati riscontrati dei problemi,

mentre le stesse informazioni sono accessibili a partner esterni.

Naturalmente, la condivisione di informazioni, spesso molto rilevanti o

strategiche per l’azienda, deve essere preceduta da un’attenta analisi dei dati

che si vanno a condividere e implementata tramite un architettura sviluppata

con particolare attenzione alla sicurezza.


2.2 Le tecnologie di presentazione e intera-

zione

Per una JIT Organization, un aspetto fondamentale e indispensabile per

la gestione efficace delle informazioni sono le tecnologie di visualizzazione

e interazione con i dati. Infatti, ormai tutte le aziende sono in grado di

raccogliere grandi quantita di informazioni, ma poche riescono a utilizzarle

al meglio perche utilizzano tecnologie di visualizzazione e interazione poco

intuitive che non sono in grado di far emergere i dati significativi.

Negli ultimi anni sono state messe a punto tecnologie molto innovative

per quanto riguarda l’interazione tra uomo e macchina. Negli anni ’70, agli

albori dello sviluppo della moderna Information Technology i computer erano

concepiti principalmente come raccoglitori di informazioni. Questa concezio-

ne si e ripercossa sull’impostazione data alle interfacce grafiche sviluppate

usando la metafora, tuttora e largamente in uso, del desktop: la UI si basa

su finestre, cartelle, icone e menu di gestione, ma tralascia completamente

l’utente. La recente evoluzione delle User Interface ha posto invece l’attenzio-

ne sull’utente e le sue esigenze sviluppando tecnologie altamente interattive e

intuitive[23]. Queste tecnologie sono ormai largamente diffuse e hanno ormai

raggiunto un grado di maturita tale da poterle utilizzare anche in contesti

aziendali. Inoltre, il continuo abbassamento del costo di miniaturizzazione e

produzione dei componenti sta rendendo disponibili ad un pubblico sempre

piu ampio device molto sofisticati.

In questa sezione passeremo velocemente in rassegna le tecnologie piu

interessanti che potrebbero, in contesti diversi, venire in contro anche ai

bisogni dell’azienda.

2.2. Le tecnologie di presentazione e interazione 15

2.2.1 Tecnologie desktop

La diffusione di notebook ad alte prestazioni a prezzi sempre piu accessibili e

la nascita di nuovi dispositivi mobili, ha cambiato la tradizionale definizione

di computer desktop che si basava essenzialmente sulla forma e le dimensio-

ni del computer. Sempre piu spesso questo termine viene usato invece per

definire tutti quei device non pensati per essere usati “in movimento”. In

particolare in questo ambito si sta notando una progressiva integrazione tra i

sistemi operativi e i servizi web e di Cloud Computing, fino a poco tempo fa

fruibili esclusivamente tramite browser. Inoltre, stanno nascendo, e continue-

ranno a svilupparsi nei prossimi anni, soluzioni multiutente pensate per far

lavorare piu persone contemporaneamente sullo stesso device, introducendo

cosı nuovi meccanismi di collaborazione e di interazione.

Widget

I widget sono piccole web-application che possono essere inserite all’interno

dei siti web o, da alcuni anni, direttamente sui desktop o lo smartphone

dell’utente. Ogni widget e disponibile come una ready-to-use application,

bastano pochi click per installarli sul PC, sono visivamente molto attraenti

e personalizzabili dall’utente.

Grazie alla loro immediatezza visiva, sono spesso usati per visualizzare

immagini, grafici, statistiche, sintesi, o qualsiasi tipo di informazione che e

interessante per l’utente tenere costantemente sotto controllo. I widget risul-

tano anche molto utili per eseguire velocemente operazioni brevi, per esempio

controllare se e arrivata una nuova email, che normalmente richiederebbero

l’apertura del browser o altri programmi.

I widget possono essere realizzati come una piccola pagina e utilizza-

re qualsiasi tecnologia supportata dai browser come, ad esempio, Flash,


Fig. 2.1: Esempi di alcuni Widget installati su un PC

JavaScript o Silverlight.

Pinned Site

Il Pinning e una nuova funzionalita di Internet Explorer 9 per Windows 7 che

consente agli sviluppatori web di creare funzionalita aggiuntive che possono

essere utilizzate dalla barra delle applicazioni di Windows 7. Tra le varie

funzionalita le piu rilevanti e utili sono tre: e possibile fornire notifiche, ad

esempio nuovi l’arrivo di nuovi messaggi o la pubblicazione di nuovi articoli;

e possibile fare clic destro sull’icona per accedere a un elenco di link in varie

parti del sito; e infine, si possono avere delle anteprime del sito con dei

controlli che permettono, ad esempio, di controllare una web-radio.

Il vantaggio per gli utenti che visitano regolarmente alcune pagine Web,

e quello,grazie ai Pinned Site, di poter accedere direttamente ai loro siti

preferiti e, da loro punto di vista, i siti che implementano queste funzionalita

possono, secondo alcune stime, incrementare le loro visite fino al 50%.


Fig. 2.2: Esempi di Pinned Site

Microsoft Surface

Microsoft Surface e un prodotto multi-touch(fino a 50 input simultanei) di

Microsoft che si sviluppa come una combinazione tecnologica di software e

hardware che consente a uno o piu utenti, di manipolare contenuti digitali

con l’uso di gesture.Gli utenti possono interagire con la macchina toccando o

trascinando la punta delle dita o oggetti, quali pennelli, attraverso lo schermo.

Questo paradigma di interazione e anche noto come Natural User Interface

(NUI).

Anche se ancora poco diffusa, la piattaforma Microsoft Surface incentiva

le persone a lavorare e prendere decisioni insieme: grazie a interfacce pensate

per essere utilizzate a 360 gradi, Surface consente di creare esperienze che

cambiano il modo di collaborare e interagire tra le persone e, grazie anche al

riconoscimento degli oggetti, tra gli quelli del mondo reale.


Fig. 2.3: Microsoft Surface

2.2.2 Tecnologie mobile

Gartner[11] stima che alla fine del 2010, 1.2 miliardi di persone siano in grado

di usufruire di smart device evoluti in grado di fornire un ambiente ideale per

la convergenza tra mobilita e web. I dispositivi mobili stanno avvicinando

sempre piu a veri e propri computer, con una quantita incredibile di capacita

di elaborazione e una notevole disponibilita di banda. La qualita dell’espe-

rienza di applicazioni di questi dispositivi, che possono sfruttare la posizione,

il movimento e il contesto di dove si trova l’utente, sta portando i clienti a

interagire con le aziende preferibilmente attraverso dispositivi mobili. Questo

ha portato ad una gara per sviluppare applicazioni mobili come strumenti

per migliorare i rapporti con i clienti e guadagnare un vantaggio competitivo

rispetto ai concorrenti le cui interfacce sono puramente basato su browser.

Infatti, da quando Apple nel 2007 lancio ufficialmente il primo iPhone,

anche il mondo mobile e sempre piu contraddistinto dalle tecnologie touch-

screen. Come e stato evidenziato in [12] questo trend diventera dominate nel

2011 con oltre il 60% dei dispositivi mobili venduti in Europa Occidentale e

in Nord America che implementera un’interfaccia touch-screen. Le aziende

produttrici andranno presto anche oltre e spingendosi fino a sviluppare inter-


facce multitouch, per garantire la miglior esperienza d’uso possibile all’utente

e il massimo in fatto di competitivita. L’utilizzo di applicazioni dedicate per

i dispositivi mobili permette di sfruttare al meglio le caratteristiche (touch-

screen, fotocamera, gps,..) rispetto ad applicazioni web che, al contrario,

spesso non si adattano bene alle piccole dimensioni dello schermo e non sono

in grado di garantire una User-Experience paragonabile a quella delle mobile

application.

Per quanto riguarda le piattaforme, si stanno delineando tre piattaforme

di riferimento: iOS di Apple, Android di Google e recentemente Windows

Phone di Microsoft, anche se altre potrebbero emergere nei prossimi mesi.

Per una tabella comparative dettagliata si rimanda all’appendice A.

iOS

iOS e la piattaforma sviluppata da Apple dedicata al mondo mobile, in par-

ticolare su iPod, iPhone, iPad, visto che le policy Apple non permettono di

installare iOS su altri device.

iOS fatto il suo successo tramite le applicazioni ed e stata la prima piat-

taforma che ha mostrato quello che una applicazione mobile ben realizzata

potrebbe fare per migliorare l’esperienza dell’utente. Come tale, l’interfac-

cia utente(Fig.2.4) di iOS e totalmente incentrata sulle App, la schermata

iniziale e un elenco a scorrimento di applicazioni e il messaggio che vuole

trasmettere e chiaro:C’e un App per tutto o quasi.

Il risultato e che la maggior parte degli utenti finali si ritrova con pagine

e pagine di applicazioni, ma e comunque facile muoversi intorno al telefono,

o con l’editor di layout in iTunes, riordinare le App in base alla frequenza di

utilizzo e di importanza. iOS incoraggia ad avere molte applicazioni, forte

dell’integrazione con l’Apple Store, anche facilitando la ricerca con Spotlight:


Fig. 2.4: iOS4

visto che il modello di interazione richiede molto spesso lo scorrimento, e

quando si arriva ad avere nove o dieci schermate comincia a essere molto

scomodo per l’utente, scorrendo a sinistra dalla prima schermata appare la

schermata di ricerca tramite cui avviare direttamente l’applicazione voluta.

Windows Phone

Windows Phone 7 e la prima release del nuovo sistema operativo Microsoft

per il mondo mobile, e al contrario della scelta di Apple, Microsoft ha deciso

di rendere disponibile il proprio OS a vari produttori di device e di concen-

trarsi solo sulla parte software, imponendo pero dei requisiti hardware minimi

molto elevati.

Windows Phone 7 e stato da poco lanciato e, anche se in questo momento

ha il piu piccolo ecosistema di applicazione, ha l’unica UI che sta creando


un certo scalpore. Infatti, Microsoft sembra aver dedicato molto tempo a

studiare il modo in cui gli utenti utilizzano le loro applicazioni. La nuova

UI(Fig.2.5) si basa sull’idea che sono le informazioni a raggiungere l’utente,

in contrapposizione alla continua navigazione all’interno delle applicazioni

in cerca di informazioni. Il design della schermata iniziale e incentrato sui

bisogni della persona e non sulle applicazioni.

Fig. 2.5: Windows Phone 7

E possibile scaricare tutte le applicazioni che si desidera, ma la schermata

iniziale di Windows Phone 7 permette di focalizzarsi solo su alcune informa-

zioni importanti: le Live Tile permettono di mostrare all’utente informazioni

contestuali e sempre aggiornate senza l’avvio l’applicazione. Utilizzando la

funzione di hub, contenuti simili possono essere raggruppati in un unico conte-

nitore. Ad esempio, l’hub immagini racchiude in un’unica live tile i contenuti

provenienti da piu applicazioni di photo sharing.

L’idea di Microsoft e quella di enfatizzare le azioni e non le applicazioni

specifiche. Windows Phone 7 non rende decine di applicazioni immediata-

mente accessibili, optando invece per dare agli utenti gli strumenti per per-


sonalizzare la propria esperienza sulla schermata Home con le informazione

che vogliono tenere sempre sott’occhio. Naturalmente, quando l’utente vuole

puo accedere alla lista completa delle applicazioni con un semplice tocco e

scorrere l’elenco, ma questo elenco non puo essere ordinato ed e una sem-

plice lista, in questo modo l’utente si sente cosı limitato da importare nella

schermata iniziale le cose importanti. La Home ha una quantita limitata di

spazi, perche piu si aggiungono tile, piu l’user-esperience diventa degradante

in quanto si deve scorrere sempre di piu per vedere le applicazioni.

Windows Phone 7 si caratteristica anche per un interessante integrazio-

ne con i servizi e i giochi Xbox Live e per il futuro e prevista anche un

integrazione con i giochi che sfruttano Kinect.

Android

Android e la piattaforma open source dedicata al mondo tablet e dispo-

sitivi mobile sviluppata da Google. Come Microsoft, Google ha deciso di

concentrarsi sullo sviluppo lato software affidando ai vendor la realizzazione

dei dispositivi, ma contrariamente a Microsoft non ha imposto dei vincoli

hardware per i device incentivando cosı la prolificazione di dispositivi dal-

le forme piu diverse e l’utilizzo in vari contesti anche non legati al mondo

mobile(dispositivi per la cucina,...).

Android e una sorta di ibrido dei due sistemi descritti in precedenza,

e probabilmente sara rivista completamente con la prossima major release.

Android ha una Home(Fig.2.6) come Windows Phone 7 in cui e possibile

inserire shortcut alle applicazioni e anche widget interattivi per tenere sot-

t’occhio le informazioni, ma a seconda del telefono specifico gli utenti hanno

da tre a sette schermi. La lista completa di applicazioni, invece, ricalca la UI

di iOS. Questo sistema permette agli utenti di creare la schermata iniziale


Fig. 2.6: Android 2.3

a proprio piacimento e se ben organizzate, lo scorrimento tra le schermate

dovrebbe essere ridotto a pochi tocchi.

2.2.3 Tecnologie entertainment

Nate in ambito entertainment, molte delle recenti tecnologie sono state ria-

dattate anche a contesti aziendali, per questo motivo, e interessante analiz-

zare brevemente quelle piu innovative che hanno rivoluzionato il modo di

interagire tra uomo e macchina e hanno ridefinito l’idea stessa di videogioco.

Nintendo Wii

Nintendo Wii e la console per videogiochi prodotta da Nintendo con pecu-

liarita molto interessanti che gli hanno permesso di essere la prima a rivo-

luzionare il modo di giocare con un videogames casalingo introducendo il

movimento fisico dell’utente.


Fig. 2.7: Wii mote e Wii sensor bar

La sua caratteristica piu distintiva e il controller senza fili, il Wiimo-

te(Fig.2.7) crasi di Wii e Remote, che reagisce alle forze vettrici e all’orienta-

mento rispetto allo spazio tridimensionali, attraverso il sistema di accelero-

metri e giroscopi presente al suo interno, e invia le informazioni alla console

tramite Bluethooth. Il controller e il maggiore distacco dagli ultimi ven-

ti anni di design di console, noto anche come free hand controller, utilizza

un approccio differente da quello tradizionale nel tentativo di risultare inte-

ressante per un pubblico piu vasto. Il Wiimote ha la forma di un comune

telecomando da televisione e viene tenuto in una sola mano e, essendo simme-

trico, e ugualmente utilizzabile da destri e mancini. Il controller tramite un

dispositivo ottico posto ad una delle sue estremita interagisce con la Sensor

Bar(Fig.2.7) rendendo possibile il suo utilizzo come sistema di puntamento

sullo schermo della TV.


Il risultato ottenuto dalla Nintendo e senza dubbio stato rivoluzionario:

l’utente semplicemente tenendo il mano il controller e muovendolo puo in-

teragire con i giochi, il tutto con estrema naturalezza e semplicita. Questo

tipo di interazione e stato per alcuni anni esclusiva prerogativa di questa

console, ma recentemente e stato introdotto anche nella Sony PlayStation 3

e, in maniera piu evoluta e ancora piu rivoluzionaria, nella Microsoft Xbox

360.

Il grande successo ottenuto dalla console e il suo concept innovativo, ha

spinto anche molte comunita scientifiche a sfruttare il Wiimote in numerosi

progetti [19] [24] [25] [17] anche non legati all’ambito entertainment, come

dimostra una rapida ricerca in Internet.

Microsoft Kinect

Microsoft ha presentato a Luglio 2010 una nuova periferica per Xbox 360,

Kinect (originariamente Project Natal), un nuovo controller-free gaming de-

vice che si presenta come un modo del tutto nuovo per vivere esperienza

entertainment in salotto.

Nonostante le dimensioni ridotte, il dispositivo Kinect(Fig.2.8)e dotato

di telecamera RGB, doppio sensore di profondita a raggi infrarossi composto

da un proiettore a infrarossi e da una telecamera sensibile alla stessa banda

e della tecnologia motion-sensing che riesce a tenere traccia di 48 punti di

movimento sul corpo umano.

Con Kinect, gli utenti non hanno piu bisogno di memorizzare diversi

comandi per interagire con il gioco, ma come recita lo spot:”You are the

controller”. Semplicemente posizionandosi di fronte al sensore e Kinect si

autocalibra e riconosce la voce e il tuo volto degli utenti che hanno gia giocato.


Fig. 2.8: Kinect

A dicembre 2010 la societa Prime Sense, compagnia israeliana da tem-

po impegnata in ricerca e sviluppo di sistemi di controllo senza dispositivi

fisici da impugnare e responsabile della tecnologia del sistema di telecamere

di Kinect, ha rilasciato i driver open source per l’innovativa periferica Mi-

crosoft, compatibili con Windows e Linux, insieme a un middleware, NITE,

per il riconoscimento del movimento. Questi driver consentono di accedere

alle funzioni audio, video e ai sensori di profondita di Kinect e sono basati

sulle API di OpenNI (Open Natural Interactions). OpenNI permette di cat-

turare il movimento in tempo reale, il riconoscimento di gesti delle mani e

dei comandi vocali e implementa anche un ”analizzatore di scena”, che rileva

figure in primo piano e le separa dallo sfondo. Utilizzando queste librerie,

come gia accaduto per la Wii, la tecnologia di Kinect e stata utilizzata per

molti progetti di ricerca non legati al gaming o all’entertainment. Recente-

mente, Microsoft ha anche dichiarato che entro il 2011 la periferica Kinect

sara integrata anche con Windows Phone 7.

Capitolo 3

Proposte per l’impresa Just in

Time

”An organizational structure consists of activities such as task allocation,

coordination and supervision, which are directed towards

the achievement of organizational aims.”

D.S. Pugh[22]

Per poter definire un’architettura software per le JIT Organization flessibile

e efficiente, in grado di adattarsi a un ampio numero di aziende, e necessario

partire da un modello organizzativo di riferimento. In questo capitolo, sara

definito il modello che e stato estratto studiando l’organizzazione interna

di Microsoft, del Cefriel e, indirettamente, dei loro clienti. Partendo dal

modello di riferimento, saranno poi evidenziate le criticita che un impresa

deve superare per diventare una JIT Organization.

28 Capitolo 3. Proposte per l’impresa Just in Time

3.1 La struttura organizzativa di riferimento

La migliore struttura organizzativa per ogni azienda dipende da molti fattori

tra cui il lavoro che svolge, la sua dimensione in termini di dipendenti, fattu-

rato, e la dispersione geografica delle sue strutture. Nel corso del tempo, sono

stati proposti sia modelli di Flat Organization sia di Hierarchical organiza-

tion, ma negli ultimi anni le aziende di maggiore successo si sono orientate

verso modelli ibridi che garantiscono sia maggiore efficienza e efficacia sia

maggiore flessibilita.

In particolare, nelle organizzazioni in cui si lavora per lo piu in modo

parallelo e concorrente su progetti complessi e ampi, si e diffuso il modello

organizzativo a Matrice(Fig. 3.1). Questo modello attua una divisione del

lavoro basata su un duplice criterio organizzativo: per funzione e per progetto

da realizzare.

Gli impiegati sono suddivisi in unita organizzative, Divisioni, in base a

criteri che variano da azienda ad azienda, ma che solitamente tendono a

raggruppare persone con competenze comuni e, se l’azienda e molto am-

pia, per aerea geografica. In questo modo, ogni divisione e specializzata

ad assolvere particolari funzioni aziendali ed e guidata da un Head of Divi-

sion(capodivisione). Lo head of division e responsabile della gestione quoti-

diana della divisione attraverso la definizione dei processi, delle procedure e

delle cosiddette best practices da adottare. Il capodivisione si occupa anche

della crescita e dello sviluppo delle risorse, definendo gli obiettivi per i singoli

componenti della divisione.

In base ai progetti o prodotti da realizzare, il Project Manager di riferi-

mento richiede risorse con competenze specifiche dai diversi dipartimenti. Il

compito del project manager sara, in questo caso, di tipo prettamente pro-

gettuale, basato sull’organizzazione dei tempi di lavoro in relazione al numero

3.1. La struttura organizzativa di riferimento 29

Fig. 3.1: Modello di riferimento

di ore settimanali allocate per ogni membro del team. A progetto ultimato,

l’unita organizzativa appositamente formata si scioglie e i suoi membri sono

destinati a nuovi incarichi.

In questo sistema, ogni membro di una divisione puo essere assegnato

ad un singolo progetto o a piu progetti, tutti da portare avanti in modo

parallelo. Ogni risorsa quindi, riportera il proprio stato di avanzamento lavori

direttamente al project manager e non al head of division. Cio significa che

ogni membro di un team rispondera a due (o anche piu) manager e sara,

in effetti, egli stesso membro di due (o piu) team. L’appartenenza a piu


squadre, pertanto, potrebbe comportare anche un ruolo differente di volta in

volta ed una responsabilita precisa nei confronti di ogni manager.

Oltre agli head of division e ai project manager, sono spesso presenti altre

due figure che permettono all’organizzazione di incrementare ulteriormente

la propria efficienza e coprire altri aspetti chiave per il business: l’Account

Manager e il Resource Manager.

Mentre il project manager e una figura focalizzata sulla realizzazione dei

progetti, l’account manager e una persona che e responsabile della gestio-

ne delle vendite e della relazione con particolari clienti, solitamente i piu

importanti. L’account manager ha il compito di lavorare con i clienti per

identificare le loro esigenze e capire come l’azienda possa rispondere al me-

glio a tali esigenze, in modo che il cliente non decida di cambiare partner.

A seconda delle dimensioni della societa, l’account manager puo gestire un

unico cliente o puo avere un portfolio di clienti.

Il resource manager e una figura simile al head of division, ma con una

visibilita che va oltre la singola divisione. Avendo una visione globale delle

risorse aziendali, il resource manager si occupa di ottimizzare l’allocazione

delle persone nei diversi progetti aperti. Anche se molto utile, questa figura

non e sempre presente in azienda e puo essere sostituita dando maggiori

responsabilita ai head of division.

Uno dei vantaggi di una struttura a matrice e l’utilizzo efficiente delle

risorse, specialmente di quelle con competenze piu pregiate, che non possono

esser utilizzate a pieno soltanto da un progetto, ma possono essere occupate

pienamente lavorando su piu progetti. Piuttosto che duplicare funzioni, co-

me dovrebbe essere fatto in una struttura semplice, le risorse sono condivise

con elevata flessibilita, derivante dalla possibilita di gestire le risorse umane

a seconda delle necessita operative dei vari progetti. Questo fa sı che le orga-

3.2. Realizzare un’impresa Just-In-Time 31

nizzazioni a matrice consentono alle divisioni funzionali di concentrarsi sulle

proprie competenze specifiche di business e permettono ai progetti di esse-

re allestiti con specialisti provenienti da qualsiasi parte dell’organizzazione.

Inoltre, mentre i reparti funzionali promuovono lo sviluppo delle competenza

funzionali, allo stesso tempo, il lavoro in gruppi di progetto con esperti di al-

tre divisioni favorisce la cross-fertilizzazione di idee. Infine, l’organizzazione

a matrice e anche la piu flessibile quando ci sono cambiamenti di esigenze di

business o di priorita e alcune ricerche mostrano come questo tipo di orga-

nizzazione incrementi la frequenza della comunicazione interna, sia formale

che informale[16].

3.2 Realizzare un’impresa Just-In-Time

Uno tra i maggiori problemi di molte aziende e che le relazioni di riporto

sono complesse e alcune persone potrebbero riportare contemporaneamente

a un capodivisione e uno o piu project manager. Inoltre, la duplice linea di

comando determina condizioni di potenziale conflittualita tra responsabili di

funzione e responsabili di progetto che rende indispensabile una forte comu-

nicazione e cooperazione tra capi divisione e project manager per organizzare

al meglio il tempo delle risorse.

La qualita delle informazioni e la velocita con cui vengono scambiate di-

ventano fondamentali per il funzionamento dell’organizzazione. Per riuscire

a creare un impresa JIT che rispetti i requisiti descritti nel capitolo prece-

dente sono richiesti sia interventi di carattere tecnologico sia organizzativo

fondamentali per l’Enterprice Business Architecture (EBA). Con il termine

EBA si fa riferimento a un’architettura, allineata con le strategie aziendali,

che offre una base comune per integrare le persone, i processi e tecnologie:


un dominio comune a cui tutte le iniziative strategiche sono collegate[28][29].

In particolare, l’EBA deve consentire l’allineamento strategico e l’integrazio-

ne dei processi aziendali con l’architettura enterprise al fine di migliorare le

capacita di monitoraggio e l’efficienza complessiva dell’azienda.

Business process: Un’analisi attenta dei processi di business, l’insieme dei

processi finalizzati al raggiungimento degli obiettivi di business, puo

evidenziare la necessita di rivedere o definire nuovi processi che ten-

gano conto anche della produzione di dati necessari al monitoraggio

dell’andamento dell’azienda e della loro qualita. I nuovi processi de-

vono considerare le caratteristiche peculiari di ogni divisione, facili-

tando la raccolta dei dati con meccanismi semplici che non incidano

negativamente sull’efficienza del processo.

Information Management: L’elevata quantita di dati e informazioni rac-

colti a livello di processo devono essere organizzati e gestiti definendo

mappe concettuali e modelli che definiscano le relazioni tra gli elementi

facilitandone l’usabilita e la condivisione.

People & Organization: L’aspetto che piu di altri incide ed e indispensa-

bile per realizzare un’impresa JIT e l’organizzazione e la motivazione

delle persone. Se sull’organizzazione e gia stata dedicata la sezione pre-

cedente, e bene soffermarsi anche sull’importanza delle persone. Come

ci e stato confermato dalle interviste fatte, la presenza di tool e ar-

chitetture sofisticate sono inutili se non si ha un forte commitment da

parte del management al tema della gestione delle informazione. Tutte

le persone dell’azienda devono essere motivate e devono capire l’im-

portanza di un inserimento accurato, tempestivo, continuo e sicuro dei

dati. Per questo motivo, sono necessari interventi di comunicazione e

3.3. Informazioni rilevanti 33

sensibilizzazione delle persone che evidenzino, anche con esempi con-

creti, come la scarsita o la poca qualita dei dati incida negativamente

sulla valutazione dello stato dell’azienda.

IT Architecture: Anche se gli aspetti legati alle tecnologie IT da soli non

bastano a trasformare un’organizzazione in una organizzazione JIT,

molto spesso architetture poco flessibili o tool dalla pessima user ex-

perience sono elementi che disincentivano gli utenti dall’utilizzo e di-

ventano scuse per la scarsa attenzione alla qualita delle informazioni,

causando gravi inefficienze e problemi nel monitoraggio aziendale.

Il nostro lavoro, si concentra in particolare su questo elemento della Enter-

price Business Architecture e cerca di definire un’architettura di riferimento

per gli aspetti di integrazione e elaborazione dei dati e offrire soluzioni per

la presentazione e fruizione delle informazioni. Particolare attenzione e sta-

ta posta nel coniugare usabilita e accessibilita delle informazioni con stru-

menti multicanale che sfruttino al meglio le potenzialita dei device di nuova

generazione.

3.3 Informazioni rilevanti

Il requisito fondamentale per un’impresa Just-In-Time e quello di riuscire a

fornire attivamente le informazioni rilevanti per le persone nel giusto luogo

e nel giusto momento. A questo requisito fondamentale possono essere ag-

giunte molte altre caratteristiche che migliorano ulteriormente l’efficienza e

l’efficacia dell’impresa.

Per prima cosa, e consigliabile che i meccanismi che portano le informa-

zioni verso l’utente seguano approcci di tipo push anziche pull, cioe cerchino

di prevenire le esigenze e fornire in anticipo le informazioni di cui la persona


puo avere bisogno. Per capire quali informazioni potrebbero essere utili si

deve sfruttare al meglio le informazioni sul contesto in cui l’utente si trova.

Per migliorare ulteriormente la qualita delle informazioni che vengono

trasmesse in azienda, si possono sfruttare dei profili, generati automatica-

mente o configurati dall’utente stesso, che permettono di personalizzare i

dati trasmessi in base chi li dovra utilizzare e al fine per cui i dati sono

richiesti.

Se il processo e stato accuratamente progettato, e possibile raccogliere

una grande quantita di dati sui processi aziendali, ma affinche questi dati si

trasformino in informazioni utili e necessario definire degli indicatori sintetici,

KPI, che siano in grado di dare una prospettiva generale sullo stato dell’a-

zienda. Questa capacita di sintesi deve poi essere inserita negli strumenti utili

usati, che devono essere in grado di comunicare facilmente e velocemente il

significato di un determinato indicatore.

Infine, una caratteristica importante per rendere il sistema completo e

la capacita di navigare i dati al fine di ricercare dettagli aggiuntivi rispetto

all’indicatore sintetico.

La Fig. 3.2 mostra tutti gli aspetti del processo di sviluppo di un’archi-

tettura IT, e delle soluzioni specifiche, per la Just-In-Time Organization. In

particolare, si deve notare che come tutti i processi di sviluppo e un processo

ciclico che tende ad arricchire di funzionalita e a migliorare le prestazioni del

sistema ad ogni iterazione.

Un problema molto frequente che porta a realizzare soluzioni che non

rispecchiano le esigenze degli utenti e quello di considerare come punto di

partenza il dato. Infatti, in molti casi, partendo dalla struttura dei dati, non

e possibile realizzare una architettura completa e efficiente poiche in realta il

vero focus deve essere posto sugli utenti. Considerando come punto di parten-


za il dato, si tende a portare all’utente un numero eccessivo di informazioni

che, spesso, non contengono le informazioni che realmente servono.

Fig. 3.2: Ciclo di sviluppo del sistema

Il nostro approccio e invece fortemente incentrato sull’utente e parte pro-

prio dall’individuazione e classificazione degli utilizzatori del sistema. Una

volta individuati gli attori in gioco, si passa a un’attenta analisi degli obietti-

vi di business di ognuno di loro e dei possibili usi che faranno della soluzione

finale. Dagli obiettivi di business e possibile capire quali indicatori di busi-

ness siano rilevanti e per essi stabilire delle metriche adatte. Solo a questo

punto ha realmente senso domandarsi da quali sorgenti di dati partire per

creare e alimentare gli indicatori che sono stati individuati. Individuati e

modellizzati i dati, si puo passare a integrare le varie sorgenti in un’unica

piattaforma e realizzare tool di analisi. I risultati dell’analisi devono, infine,

essere presentati all’utente e per riuscirci nel modo piu efficace bisogna rea-

lizzare soluzioni pensate per gli specifici device che saranno utilizzati per la

visualizzazione.


3.3.1 Gli utenti

Come gia evidenziato nel modello di riferimento, sono stati individuati cinque

attori che interagiscono principalmente nel sistema azienda(Fig. 3.3).

Fig. 3.3: Utenti del sistema

Professional: e principalmente una fonte di dati per il sistema. Inserisce

dati relativi al suo lavoro che possono essere analizzati dai manager

a cui fa riferimento. In alcuni casi, il professional puo anche essere

utilizzatore delle informazioni, ma solo relative alla sua persona.

Project Manager(PM): e colui che gestisce il progetto e richiedere al head

of division le persone da allocare ai singoli progetto. Oltre alle persone,

gestisce anche le altre risorse del progetto come la formazione, l’utilizzo

il software e le trasferte. A sua volta il PM e un professional assegnato

al progetto. Il PM interagisce con il sistema principalmente per fare

operazioni di analisi, ma e anche a sua volta una sorgente di dati ad

esempio nei confronti degli account manager e dei head of division.


Account Manager (AM): e colui che gestisce tutti i progetti relativi a un

unico cliente. Ha le stesse esigenze del project manager, ma con una

visione trasversale sul cliente.

Head of Division (HoD): e a capo di una divisione all’interno dell’azien-

da. Deve approvare la richiesta di risorse provenienti dal PM ed e

interessato principalmente al lato finanziario della gestione della divi-

sione.

Resouce Manager (RM): ha un focus simile ai HoD, ma con una visione

che va oltre la singola divisione. Il suo compito principale e ottimizzare

l’allocazione delle risorse.

3.3.2 Scenari d’uso

Tipicamente e possibile distinguere tre contesti in cui i lavoratori dell’azienda

si possono trovare a interagire con le informazioni dell’organizzazione: in

ufficio davanti al proprio PC, in mobilita e in riunione con i propri colleghi

o con partner aziendali.

La situazione tipica e quella di un dipendente, che nel suo ufficio di fronte

al suo PC, ha la necessita di avere sempre a disposizione i dati riguardanti

il suo ruolo nell’impresa. In questo contesto l’utente ha a disposizione tutti

gli strumenti per eseguire qualsiasi tipo di azione, ma e comunque necessario

capire quali tra questi strumenti possono rendere i suoi compiti piu facili e

veloci.

Spesso un dipendente si trova a compiere spostamenti per il suo lavoro, ma

ha la necessita di poter ugualmente visualizzare le informazione come se fosse

in azienda. I dispositivi mobili, che oggi sono paragonabili ad comune PC

per la gamma di servizi offerti, permettono di colmare questa esigenza. Due


aspetti sono pero critici e devono essere affrontati in questo contesto. Il primo

aspetto riguarda e la criticita delle informazioni e quindi l’accesso sicuro e

controllato al servizio, il secondo invece riguarda lo studio dell’interfaccia

utente e quindi l’interazione con l’applicazione che deve risultare piacevole,

semplice, veloce e deve tener conto delle dimensioni dello schermo.

Il terzo contesto che vogliamo considerare e quello dei meeting aziendali e

dei contesti collaborativi, dove si ha l”esigenza di esporre e presentare risul-

tati, offerte tecnologiche e dettagli di progetto. In questo contesto, l’aspetto

piu significativo e la facilita con cui i partecipanti possono interagire con le

informazioni e collaborare tra loro. Tipicamente in questo contesto si ha

disposizione schermi di dimensioni elevate e sale appositamente attrezzate.

3.3.3 Il modello di riferimento

Dopo aver analizzato i bisogni degli utenti nelle diverse situazioni in cui si

potrebbero trovare, si aprono diversi orizzonti per lo sviluppo. La Fig. 3.4

vuole descrivere sinteticamente i diversi aspetti che diverse soluzioni potreb-

bero coprire. Lo schema mostra come si possono coprire prospettive differenti

partendo dai bisogni dell’utente e progressivamente allargarsi a nuovi ambiti.

Si individuano cinque aspetti principali: Context, Device, Tool, Aggregation,

Time.

L’utente, che resta il perno della nostra analisi, puo trovarsi a lavorare

principalmente in due contesti: da solo o con altre persone. Il primo caso

e quello piu semplice e comune e la maggioranza dei software in commercio

sono pensati per questo contesto. In realta, in azienda e molto comune

lavorare con altre persone, basti solo pensare a quanti meeting vengono fatti

in una settimana. Le soluzioni che indirizzano verso questo contesto devono

specificatamente tenere conto dell’interazione tra le persone.


Fig. 3.4: Modello di riferimento

Allargando ulteriormente l’analisi, si deve naturalmente tenere conto dei

device che saranno utilizzati, sia dal punto di vista hardware sia da quello

software. Dal punto di vista hardware, alcuni fattori essenziali sono il tipo

di interazione che il device permette (mouse, touch, multitouch, gesture,... )

e le dimensioni degli schermi su cui saranno visualizzate le informazioni. Dal

punto di vista software, la scelta di un sistema operativo o di un linguaggio

di sviluppo puo incidere fortemente sulla velocita di sviluppo, ma anche sulla

capacita di integrare e riutilizzare i componenti gia presenti.

Sui diversi device si possono sviluppare tool diversi (portali, widget, stru-

menti di reportistica,...) ognuno dei quali finalizzati a obiettivi diversi e

conseguentemente progettati per soddisfare requisiti diversi.

Le soluzioni sviluppate possono avere modalita di visualizzazione dei da-

ti che vanno dalla piu sintetica metafora, sole se l’azienda va bene fulmini e

pioggia in caso di problemi, al datasheet con funzioni di aggregazione e esplo-


sione per visualizzare i dati completi di una tabella di un report. Tra questi

due estremi sono presenti un’infinita di stili e modelli di visualizzazione in-

termedi che molto utili, a seconda del contesto, per visualizzare informazioni

di carattere differente.

Infine, un alto aspetto da prendere in considerazione prima di realizzare

la soluzione software e il fattore tempo. Questo fattore e particolarmente

importante perche puo diventare un aspetto dannoso per il sistema e un re-

quisito vincolante e discriminante per tutta l’architettura. Ad esempio, e

inutile che il sistema sia progettato per realizzare analisi realtime quando le

informazioni generate vengono utilizzate per prendere decisioni settimana-

li. Al contrario, soluzioni utilizzate per generare informazioni per prendere

decisioni in realtime, si pensi ad esempio ai broker di borsa, non possono

permettersi ritardi nell’elaborazione dei dati e devono essere dimensionate

per garantire il massimo della disponibilita con il minor tempo possibile.

Il modello di analisi qui proposto, sara ripreso nel capitolo6 per valutare

quali di questi aspetti le soluzioni proposte riescono a coprire e quali aspetti

potrebbero essere sviluppati in futuro.

Capitolo 4

Architettura del Sistema

”Un giorno le macchine riusciranno a risolvere tutti i problemi,

ma mai nessuna di esse potra porne uno.”

Albert Einstein

Questo capitolo presenta l’architettura software generale che proponiamo.

In particolare, si cerca di evidenziare, dettagliando puntualmente i diversi

layer software, come l’architettura proposta risponda alle esigenze di impresa

just-in-time che sono emerse nei capitoli precedenti.

4.1 Presentazione dell’architettura

L’architettura che proponiamo si basa un componente di back-end, che si

occupa di estrarre le informazioni dai sistemi interni all’azienda, aggregarle

e tenerle aggiornate e pronte all’uso, e da una componente di front-end per

la visualizzazione.

Questa architettura non necessita di modifiche alle risorse gia presenti in

aziendale, ma si integra con esse in particolare nel livello di integrazione e

42 Capitolo 4. Architettura del Sistema

Fig. 4.1: Componenti dell’architettura

aggregazione dei dati e in quello di presentazione. I vari sistemi di CRM,

ERP, mail service dell’azienda vengono utilizzati come fonte dal quale rica-

vare le informazioni e, nel caso in cui l’azienda fosse dotata di datawarehouse

e strumenti di reportistica gia collaudati, il sistema prevedera anche l’accesso

diretto a queste informazioni.

La Fig. 4.1 mostra il macro-schema dell’architettura, dal reperimento

delle informazioni fino alla presentazione e visualizzazione di questi. Dietro

4.2. Modello three tier 43

a tutto cio c’e l’esigenza di riconoscere dei dati eterogenei tra di loro che a

seconda del genere devono essere gestiti in modo differente.

4.2 Modello three tier

La nostra architettura software adottata segue il tipico modello a tre livelli[2]

(Fig. 4.2), in particolare, i layer di accesso ai dati e di logica sono collocati

server-side e il layer di presentazione e spostato interamente client-side.

Fig. 4.2: Architettura a tre livelli

Le due parti comunicano tramite web-service[13] e questo permette di

separare completamente lo sviluppo della grafica da quello della logica. La

scelta di questo tipo di architettura e dovuto ai seguenti motivi:

• Maggiore garanzia di sicurezza per cio che riguarda i dati aziendali.

Infatti, la suddivisione tra business layer e data layer permette l’accesso


ai database solo a coloro che hanno le autorizzazioni necessarie per il

sistema.

• Valore aggiunto per la gestione del codice e della sua evoluzione nel

tempo. L’aggiunta di nuovi moduli e la manutenzione di quelli attual-

mente presenti risulta piu immediata e semplice perche ogni componen-

te e nettamente separata dagli altri. Inoltre, in caso di errori e facile

trovare il problema e intervenire sul modulo individuato.

• La separazione tra la logica e il database funzionale significa un miglior

bilanciamento del carico.

• L’architettura e di tipo aperto, cioe non si lega in modo particolare

ad un tipo di client, garantendo la flessibilita necessaria per andare a

sostituire un client con uno di diversa natura senza modificare in nessun

modo la logica.

4.2.1 Data Access Layer (DAL)

Entrando nel dettaglio dell’architettura, il primo livello da analizzare e il

Data Access Layer(DAL).

L’applicazione dovrebbe potere accedere a ogni singola informazione azien-

dale in formato elettronico, dai dati dei clienti presenti sul CRM, alle mail

che vengono scambiate tra i dipendenti. Il layer in analisi ha il compito di

gestire le connessioni con le varie fonti dati tramite dei componenti detti

Connector suddivisi per tipologia di fonte (Mail Service, CRM, ERP, Report

Manager,... ) e poi sotto-classati in base sistema usato (Exchange, Gmail,

...). Questo permette di poter gestire un’ampia gamma di possibili fonti dati

e utilizzare la nostra soluzione indipendentemente dai software gia disponibili

in azienda. Il layer dei dati si occupa anche di uniformare i dati provenienti


dalle diverse fonti per renderli omogenei e ottimizzarne l’utilizzo nelle fasi

successive.

Oltre ai connettori, DAL si occupa anche di uniformare i dati provenienti

dalle diverse sorgenti per renderli omogenei e ottimizzarne l’utilizzo nelle fasi

successive generando un modello dei dati contenuti nelle diverse fonti. Questo

favorisce un rapido passaggio dei dati tra la parte di logica del sistema e le

sorgenti informative, il tutto in modo trasparente alla tecnologia usata per

implementare.

4.2.2 Layer della logica

Il secondo livello dell’architettura e costituito dal Business Logic Layer(BLL)

che implementa tutta la logica del sistema. Il BBL e costituito da tre compo-

nenti fondamentali: SecurityManager, InfromationManager, AlertManager.

L’InfromationManager gestisce il recupero delle informazioni e offre me-

todi per l’inserimento di dati. InfromationManager gestisce anche il recupero

di dati gia elaborati e provenienti da uno strumento di reportistica esterno o

da un datawarehouse.

AllertManager e il componente che permette di creare e smistare ai diversi

utenti avvisi riguardanti informazioni di suo interesse.

Il SecurityManager implementa le funzionalita di autenticazione degli

utenti e di gestione delle sessioni di lavoro interfacciandosi con il reposi-

tory degli utenti. Le caratteristiche di sicurezza che questo componente deve

garantire sono dettagliate in 4.3.

L’analisi dei dati riveste un ruolo sempre piu determinate e anche le azien-

de, che fino a pochi anni fa si concentravano per lo piu sulla raccolta dei dati,

stanno spostando gran parte dei loro investimenti sullo sviluppo o l’acquisto

di tool di analisi e di previsione. BLL si fa anche carico dell’analisi delle


informazioni provenienti dalle diverse fonti. Le informazioni, nelle loro varie

declinazioni(report, contact, task,...), vengono analizzate da ProjectsAna-

lyzer per rilevare il livello di importanza e l’utente interessato. Per ogni

categoria di utilizzatore e disponibile un struttura che descrive le gerarchie

di interessi in base alle quali devono essere classificate le informazioni. In

base ai risultati delle analisi, il sistema genera automaticamente degli avvi-

si che vengono recapitati all’utente. Un esempio di analisi interessante per

i manager puo essere la valutazione e previsione dei costi di un progetto e

la segnalazione di eventuali sformanti di budget. Questa analisi a priori ha

il compito di ridurre i tempi di risposta durante l’utilizzo dell’applicazione

client.

Web Services

La scelta di utilizzare web service come interfaccia tra front-end e back-

end del sistema permette di avere una soluzione molto flessibile e facilmente

estensibile.

Sfruttando il protocollo HTTP e incapsulando i messaggi secondo il pro-

tocollo SOAP, siamo in grado di fornire a un ogni utente aziendale collegato a

internet le informazioni selezionate in qualunque luogo si trovi. Inoltre il web

service, essendo basato su tecnologie protocolli standard, permette di acce-

dere al sistema indipendentemente dalla tecnologia utilizzata lato client. Gli

sviluppi futuri del front-end sono quindi del tutto svincolati dalla tecnologia

di back-end.

Un ulteriore vantaggio e la possibilita di collegare tra loro piu servizi riu-

tilizzando le funzionalita gia implementate. Per esempio, tramite web service

l’azienda puo decidere di integrare il nostro sistema con quello contabile per

verificare i giorni lavorati dai dipendenti e segnalare irregolarita.


4.2.3 Presentation and Interation Layer(PIL)

L’ultimo livello, il Presentation and Interation Layer(PIL) (Fig. 4.3) ha il

compito di implementare i front-end che gestiscono l’interazione dell’utente

con il sistema. Per scelta progettuale abbiamo deciso di ridurre al minimo

la logica contenuta lasciando solamente quella necessaria alla gestione della

grafica.

Le user interface devono essere quanto piu possibile smart e user-friendly

per permettere un inserimento rapido dei dati e una consultazione efficace

delle informazioni. Per perseguire questi obiettivi sono stati sviluppati client

di visualizzazione diversi pensati per specifici contesti e device.

Infatti, per raggiungere gli obietti posti e indispensabile sviluppare client

dedicati al tipo di device utilizzato per riuscire a sfruttare a pieno le po-

tenzialita di questi strumenti, garantendo la maggiore semplicita d’uso per

l’utente. Questa scelta implica lo sviluppo e il mantenimento di client molto

diversi tra loro, ma questo aspetto non e comunque critico.

Un primo fattore da considerare e il mercato: negli ultimi anni l’appari-

zione di device sempre piu evoluti, semplici e interattivi ha spinto a ripensare

il normale concetto di fruizione di un servizio, in particolar modo dell’uti-

lizzo del web. Fino a qualche anno fa, il principale meccanismo per rendere

disponibile la fruizione di un servizio era la realizzazione siti web e appli-

cazioni utilizzabili tramite browser perche garantiscono un buon livello di

inter-operabilita e l’indipendenza dal sistema che l’utente utilizza. Oggi si

sta osservando, sopratutto in ambito mobile, un’inversione di rotta che porta

a preferire la realizzazione di App dedicate e specifiche per particolari fa-

miglie di device. Seguendo questa tendenza, anche molti dei principali siti

web mondiali hanno deciso di sviluppare applicazioni dedicate per garantire

all’utente di fruire da device mobile gli stessi, e in alcuni casi maggiori, con-


tenuti presenti sul web. Questa tendenza ha portato alcune riviste a titolare

addirittura che: ‘The Web Is Dead. Long Live the Internet’[3].

Il secondo fattore importante da tenere presente e che concentrando tutta

la logica dell’applicazione nella parte di back-end, si puo mantenere e svilup-

pare agevolmente il codice che gestisce le operazioni core della piattaforma,

senza modificare minimamente i client. Inoltre, mantenere la logica indi-

pendente dal livello presentazione permette di avere un sistema fortemente

multi-canale e multi-device, indipendente dalla tecnologie di visualizzazione.

Fig. 4.3: Architettura del Presentation Layer

Per ognuno dei tre contesti evidenziati in 3.3.2, e necessario pensare e

sviluppare un front-end dedicato per essere in grado di fornire ai lavoratori

della JIT Organizzation un efficace meccanismo di interazione con le infor-

mazioni in qualsiasi situazione si trovino ad operare. Le tecnologie descritte

nel 2 possono essere utili a questo scopo.

4.3. Aspetti di sicurezza 49

4.2.4 Considerazioni

L’architettura cosı presentata e molto agile e flessibile, in particolare possia-

mo vedere come sia semplice agganciarsi ad altre fonti di dati sia interne che

esterni all’azienda. Per garantire ottime prestazione, scalabilita e affidabilita

il back-end potrebbe essere sviluppato sfruttando un servizio di Cloud Com-

puting. Utilizzando semplici thin-client per i vari device sara possibile acce-

dere ai dati dai dispositivi fissi e portatili piu disparati, dagli smartphones,

ai dispositivi desktop, passando per diplay touch-sceen e maxischermi.

4.3 Aspetti di sicurezza

Visto l’uso in contesti aziendali, l’architettura deve necessariamente con-

tenere un modulo per la gestione della sicurezza che rispetti determinate

caratteristiche.

In ogni sistema la sicurezza e sempre uno dei punti critici, poiche spesso

viene mal progettata e ritenuta di secondo piano rispetto all’obiettivo effetti-

vo per cui il sistema e pensato: tale problema e poco rilevante solo per piccole

applicazioni non destinate alla interazione tra sistemi eterogenei complessi o

all’ambito aziendale. Al crescere della complessita e dell’importanza del si-

stema informatico, il problema della sicurezza deve essere ben strutturato

e deve garantire quello che viene spesso definito paradigma Confidentiality,

Integrity and Availability (CIA)[5]. A questi tre elementi del paradigma se

ne aggiunge un quarto indispensabile nei contesti aziendali: l’Autenticazione.

Confidenzialita: Con confidenzialita si intende la protezione dei dati e

delle informazioni scambiati tra un mittente e uno o piu destinatari, impe-

dendo a terzi di venirne in possesso o di essere capaci dei comprenderne il


significato. Risulta pero difficile impedire che le informazioni e i dati vengano

in possesso di persone estranee alla comunicazione, perche cio comporterebbe

l’utilizzo di un canale di trasmissione sicuro che pero nella maggior parte dei

casi non e utilizzabile perche non disponibile o troppo costoso. Si preferisce

quindi non basare la sicurezza sul mezzo trasmissivo, spesso intrinsecamente

insicuro (basti pensare a internet o reti wifi), ma sul livello logico: in un si-

stema che garantisce la confidenzialita, una terza parte che entri in possesso

delle informazioni scambiate tra mittente e destinatario, non e in grado di

ricavarne alcun contenuto informativo intelligibile.

Integrita: Con integrita si intende la protezione dei dati e delle informazio-

ni nei confronti delle modifiche del contenuto, accidentali oppure effettuate

da una terza parte, essendo compreso nell’alterazione anche il caso limite

della generazione ex novo di dati ed informazioni. Insito nel concetto di in-

tegrita vi e quindi la possibilita di verificare con assoluta certezza se un dato

o una informazione sono rimasti inalterati nel loro contenuto durante la loro

trasmissione.

Disponibilita: Con disponibilita si intende il fatto che in ogni momento

le persone autorizzate possono ricevere e inviare le informazioni di cui hanno

bisogno in un tempo ‘ragionevole’, definito in fase di specifica. Questa ca-

ratteristica, tipica della progettazione di impianti informatici, risulta molto

interessante anche lato software quando si deve gestire l’interazione sicura

tra ‘gruppi’ di utenti: cio comporta spesso scambio di informazioni per ga-

rantire la sicurezza e l’integrita dei dati inviati nel gruppo e percio eventuali

modifiche al piano di sicurezza devono essere comunicate a tutti gli utenti in

modo tempestivo per non generare conflitti.

4.3. Aspetti di sicurezza 51

Autenticazione: Una piu approfondita analisi merita il requisito di auten-

ticazione, che si lega trasversalmente con il paradigma CIA. Con tale termine,

derivante dalla parola greca authentes (autore), si e soliti definire un proces-

so che permette di verificare la presunta identita di un interlocutore di una

comunicazione o del creatore di un documento. Definire in modo univoco l’i-

dentita di un utente, o di un’altro sistema, e riconoscerlo e fondamentale per

poter progettare e gestire correttamente una efficiente politica autorizzazioni

ad un servizio o ad una risorsa e una politica di ‘fiducia’ verso le risorse messe

a disposizione da altri: si deve essere certi che l’interlocutore con il quale si

stanno scambiando delle informazioni sia veramente chi dice di essere e non

un impostore.

In letteratura si e soliti raggruppare i metodi di autenticazione in tre

paradigmi: One-way(il piu diffuso), uno solo dei due interlocutori si identifica

verso l’altro, che si presume avere una identita valida; Two way, entrambi

gli interlocutori di devono identificare reciprocamente; Trusted third-party, si

utilizza una terza parte ritenuta ‘affidabile’ da entrambi gli interlocutori che

autentichi entrambi.

Un’altra classificazione che caratterizza ulteriormente i tipi di autenti-

cazione possibili e la seguente: il soggetto che si deve autenticare possiede

qualcosa (smat card, certificati digitali,...); il soggetto che si deve autenticare

conosce qualcosa (password, PIN,...); il soggetto che si deve autenticare ha

una determinata caratteristica o comportamento (iride, voce, impronta,...).

Attualmente nel mondo dei sistemi informatici i meccanismi piu utilizzati

per l’autenticazione sono l’uso di password alfanumeriche, ma recentemente

si stanno affermando nell’ambito delle trasmissioni sicure l’uso dei certificati

digitali e dei sistemi integrati di autenticazione come la Integrated Windows

Authentication di Microsoft. Tutte queste soluzioni sono state considerate


e utilizzate nel caso di studio. Fin da ora e bene pero chiarire che una

buona gestione dell’autenticazione degli agenti che interagiscono nel sistema

e fondamentale per permettere dei servizi differenziati in base ai privilegi che

ogni agente possiede.

Capitolo 5

Caso di Studio: CEFRIEL

”Se puoi immaginarlo, puoi anche realizzarlo”

Walt Disney

In questo capitolo si vuole mostrare come l’architettura precedentemente

descritta e stata calata in un contesto reale, evidenziando sia le caratteristiche

sviluppare lato back-end sia quelle lato front-end, con particolare attenzione

per i client realizzati.

5.1 Descrizione del caso di studio

Il sistema mostrato nel capitolo precedente e stato applicato e integrato in un

caso reale, in particolare l’azienda con la quale abbiamo lavorato e CEFRIEL.

Grazie a questa collaborazione siamo riusciti a comprendere al meglio i pro-

blemi e le esigenze di un’azienda moderna. Inoltre, lavorando su un sistema

reale abbiamo affrontato il problema di integrare una nuova tecnologia in

un ambiente gia stabile e consolidato. La nostra soluzione, Graphical En-

54 Capitolo 5. Caso di Studio: CEFRIEL

terprise Data Integrator (GEDI) ha l’obiettivo di rispondere alle esigenze

precedentemente descritte nel contesto della gestione dei progetti.

5.1.1 Il CEFRIEL

CEFRIEL opera dal 1988 come centro di eccellenza per l’innovazione, la ricer-

ca e la formazione nel settore dell’Information & Communication Technology.

Suo obiettivo primario e rafforzare i legami tra universita e imprese attraver-

so un approccio multidisciplinare che, partendo dalle esigenze dell’impresa,

integra i risultati della ricerca, le migliori tecnologie presenti sul mercato,

gli standard emergenti e la realta dei processi industriali, per innovare o

realizzare nuovi prodotti e servizi.

CEFRIEL e oggi una societa consortile i cui soci sono il Politecnico di

Milano, l’Universita degli Studi di Milano, l’Universita degli Studi di Milano-

Bicocca, l’Universita degli Studi dell’Insubria, la Regione Lombardia e 15

aziende multinazionali operanti nel settore ICT e dell’editoria multimedia-

le. CEFRIEL e parte attiva dell’ICT Institute, la recente istituzione del

Politecnico di Milano nata per coordinare e promuovere le iniziative dell’A-

teneo per la formazione, ricerca e innovazione nel settore delle tecnologie

dell’informazione e della comunicazione.

Visto il contesto altamente tecnologico in cui opera, CEFRIEL e gia do-

tato di un sistema informativo in cui integrare la nostra soluzione. Altra

caratteristica che fa del CEFRIEL un candidato ideale e che il suo business

principale si sviluppa grazie a progetti, che quindi devono essere gestiti nella

maniera piu efficiente possibile. Infine, la presenza sia del mondo industriale

che di quello accademico, fa di CEFRIEL un possibile catalizzatore per la

diffusione di soluzioni che possono migliorare l’efficienza organizzativa delle

aziende italiane.

5.1. Descrizione del caso di studio 55

5.1.2 Il modello organizzativo

L’attivita lavorativa in CEFRIEL e incentrata sui progetti. Ogni dipendente

aziendale ha il compito di fare evolvere un progetto il piu velocemente pos-

sibile secondo le esigenze del cliente, l’organizzazione dell’azienda percio si

sviluppa nel rispetto di questo obiettivo.

Cefriel e suddiviso in quattro divisioni: Digital Interaction & Visual Ex-

perience (DI), Digital Enterprise & Information Systems (DE), Digital Plat-

forms & Pervasive ICT (DP) e Digital Knowledge & Education (DK). Questa

divisione rafforza il livello qualitativo dei progetti e rende piu efficaci i tempi

di esecuzione, aspetto fondamentale per una societa come questa.

I principali ruoli ricoperti in Cefriel sono quattro: Head of Division, Ac-

count Manager, Project Manager e Professional. I capi di divisione sono i

responsabili delle singole divisioni e quindi di tutte le risorse che ne fanno

parte. I project manager, invece, sono i responsabili dei progetti e si occu-

pano sia della gestione delle persone che degli aspetti amministrativi come

le fatture, il Stato Avanzamento Lavori (SAL) e il Work in Progress (WIP).

Trasversalmente alle divisioni i project manager possono richiedere risorse

esperte in determinati ambiti per allocarli su uno dei progetti di cui sono

responsabili. Gli account manager sono quelle risorse, che alla pari del pro-

ject manager, sono responsabili di progetto, ma con riferimento diretto a

un particolare cliente. L’account manager e di solito il collegamento tra il

cliente e l’insieme di progetti che sono sviluppati per esso. Infine, la figu-

ra del professional racchiude tutte le singole risorse che vengono allocate su

ogni progetto. Naturalmente anche i capi divisione, i project manager e gli

account manager sono a loro volta professional.

Come appare evidente, l’organizzazione aziendale in CEFRIEL rientra

perfettamente nel modello generale descritto nel capitolo 3, fatta eccezione


per la figura di resource manager che viene sostituita in termini di responsa-

bilita dalle altre figure presenti.

5.1.3 Il sistema di controllo e gestione progetti

Come e gia stato piu volte sottolineato, in ogni azienda e fondamentale moni-

torare lo stato di avanzamento dei lavori in atto e per fare cio e indispensabile

partire dai dati inseriti dai lavoratori. In particolare nelle aziende incentrate

sullo sviluppo di progetti, ha un ruolo determinante l’inserimento dei con-

suntivi, cioe quante ore ogni professional ha lavorato sui progetti a cui e

assegnato.

In CEFRIEL, a dimostrazione della particolare attenzione per il tema

trattato, era gia presente un sistema per il controllo e la gestione dei progetti

sviluppato ad hoc alcuni anni fa dallo stesso CEFRIEL. Il sistema si e evoluto

col tempo cercando di migliorare costantemente sia dal punto di vista delle

funzionalita che da quello della semplicita di utilizzo.

Come in ogni azienda, i professionisti sono tenuti a consuntivare entro

fine mese le ore lavorate, ma facilitare le operazioni di inserimento e modi-

fica incentiva i dipendenti a tenere sempre aggiornate le informazioni. In

quest’ottica di miglioramento continuo, la nostra soluzione vuole proporre

nuovi meccanismi di inserimento e modifica dei dati da affiancare a quelli gia

presenti.

I capi divisione, projet manager e account manager devono analizzare

e aggiornare settimanalmente lo stato di avanzamento dei progetti. Con

la soluzione proposta vogliamo offrire ai manager aziendali la possibilita di

avere ancora piu informazioni per aiutarli a prendere decisioni consapevoli

e tempestive. Il sistema vuole essere un valido strumento di supporto che

5.1. Descrizione del caso di studio 57

cerca di individuare eventuali problemi o ritardi nelle attivita dei progetti e

gli evidenzia alle persone di competenza.

5.1.4 Contesto tecnologico

CEFRIEL attualmente utilizza SQL SERVER come DBMS per la gestione

del database. Le basi di dati considerate ai fini del nostro scopo sono mostrate

in Fig. 5.1:

Fig. 5.1: Schema dell’architettura attuale in CEFRIEL

• CGP DB:database contenente i dati attuali e i dettagli della gestione

dei progetti.

• CGP REPORT: base di dati contenente i report (effettuati periodi-

camente nell’arco della giornata) dei dati provenienti da CGP DB.

• CGP DW: e il datawarehouse dell’azienda. Questo database contiene

lo storico e il sintetico delle informazioni provenienti da CGP DB. Inol-

tre integra i dati con le voci contenute negli ERP e i dati provenienti

dai processi aziendali. Questo database viene riempito una volta al

giorno in orari notturni.


Inoltre CEFRIEL e dotato di un’altro server sul quale e situata la Web

Application che attualmente viene usata per il controllo di gestione. La

Web Application e ospitata su un Web Server IIS. Sulla stessa macchina e

presente anche una applicazione per generare cruscotti aziendali utilizzata

per visualizzare i report provenienti dal datawarehouse.

5.2 Esigenze aziendali

Dalle interviste fatte e dall’analisi dell’organizzazione aziendale abbiamo evi-

denziato i principali casi d’uso per le tipologie di utente presenti in CEFRIEL.

Per ogni tipologia di utente e presente anche una una tabella che indica

il livello di importanza di una determinata azione nei tre ambiti analizzati

in 3.3.2. La tabella e frutto di un sondaggio fatto all’interno dell’azienda e

indica quindi le priorita dal punto di vista dell’utilizzatore finale.

5.2.1 Casi d’uso: Professional

Lo use case (Fig. 5.2) mostra le principali esigenze di un professional del-

l’azienda. Ogni utente, deve per prima cosa loggarsi al sistema e solo dopo

essere stato riconosciuto puo accedere alle informazioni aziendali. Un pro-

fessional assegnato a uno o piu progetto deve eseguire determinate attivita

suddivise in task e periodicamente deve consuntivare, cioe riportare nel siste-

ma le ore impiegate per eseguire i compiti assegnategli. Complessivamente le

ore effettivamente lavorate devono essere maggiori o uguali a quelle indica-

te dal contratto del professional e quindi deve poter verificare facilmente di

aver inserito i dati in modo completo. Dalle nostre analisi e emerso che un

bisogno molto comune per le aziende e quello di avere un meccanismo rapido

e mirato per segnalare problemi ai loro dipendenti. Per questo motivo, tra le

5.2. Esigenze aziendali 59

esigenze che e necessario soddisfare per un professional c’e anche la possibi-

lita di ricevere gli avvisi generati automaticamente o inviati da uno dei suoi

referenti.

Fig. 5.2: Use Case Professional

Naturalmente le esigenze evidenziate assumono una rilevanza diverse a

seconda dei contesti in cui un professional si trova. Per il professional gli sce-

nari piu comuni sono due: seduto davanti a un PC e l’ambito mobile. Mentre

in ambito desktop hanno rilevanza tutte le esigenze evidenziate, in ambito

mobile gli aspetti di visualizzazione delle informazioni sono piu rilevanti degli

aspetti di inserimento. Tipicamente, le persone quando si trovano a utilizzare

device mobili per accedere al sistema sono interessati a visualizzare lo stato

di dei propri consuntivi o delle attivita da compiere e controllare se ci sono

avvisi urgenti che gli riguardano.


La tabella (Tabella 5.1) riassume schematicamente la rilevanza delle di-

verse attivita in abito mobile e desktop.

Attivita Mobile Desktop

Inserimento consuntivi Bassa Alta

Visualizzazione consuntivi Media Alta

Visualizzazione task Media Alta

Visualizzazione alert Alta Alta

Tabella 5.1: Tabella dei contesti per il Professional

5.2.2 Casi d’uso: Project Manager

Lo use case (Fig. 5.3) mostra le principali esigenze caratteristiche di un pro-

ject manager dell’azienda, naturalmente essendo anche un professional ere-

dita tutte le attivita evidenziate precedentemente. Il project manager si

differenzia dal professional per le funzioni di management, quindi necessita

di informazioni piu elaborate generate aggregando da dati semplici che per-

mettano una visione dello stato di avanzamento dei progetti. I primi due

dati da tenere in considerazione sono l’andamento del SAL, cioe i costi del

progetto, e del WIP, cioe di quanto valore e gia stato sviluppato rispetto al

valore complessivo del progetto. L’altro aspetto di interesse per il project

manager e l’andamento dei consuntivi perche permette di vedere se i dati

di WIP e SAL sono realmente allineati con lo stato attuale del progetto.

Per esempio, un SAL molto basso puo dipendere dal fatto che uno o piu

dipendenti non hanno ancora inserito i propri consuntivi e quindi il costo

delle ore uomo lavorate non e ancora stato aggiunto. Infine, diversamente

dal professional, il project manager deve avere la possibilita di inviare delle

5.2. Esigenze aziendali 61

segnalazioni alle persone che lavorano nei progetti di sua competenza, per

esempio, per sollecitare l’inserimento dei dati.

Fig. 5.3: Use Case Project Manager

Come per il professional, anche per il project manager la priorita di un’a-

zione varia a seconda del contesto in cui l’utente si trova(Tabella 5.2). In

questo caso tutti e tre i contesti individuati sono significativi, in particola-

re nel contesto mobile e meeting sono rilevanti gli aspetti di visualizzazione

dello stato dei progetti. Per quanto riguarda la possibilita di inviare avvisi

agli utenti resta comunque rilevante nel contesto mobile, ma non in quello

meeting.


Attivita Mobile Desktop Meeting

Invio di alert Media Alta Bassa

Visualizzazione WIP Alta Alta Alta

Visualizzazione SAL Alta Alta Alta

Visualizzazione stato consuntivi Alta Alta Bassa

Tabella 5.2: Tabella dei contesti per il Project Manager

5.2.3 Casi d’uso: Account Manager

Le attivita che puo svolgere l’account manager sono simili a quelle del pro-

ject manager, infatti, i due utenti sono differenziati principalmente dal tipo

di progetti al quale fanno riferimento: gli account manager hanno visibi-

lita su tutti i progetti collegati al cliente a cui sono assegnati. Le esigenze

dell’account manager risultano quindi del tutto analoghe a quelle del projet

manager in tutti e tre i contesti che abbiamo evidenziato.

5.2.4 Casi d’uso: Head of Division

Lo use case (Fig. 5.4) mostra le principali esigenze dei HoD delle diverse divi-

sioni. Rispetto a un project manager, il HoD si focalizza principalmente sullo

stato di allocazione delle proprie risorse e sulla quantita di ore consuntiva-

te. Naturalmente, in quanto manager anche il capodivisione ha la possibilita

di inviare messaggi a tutte le risorse della propria divisione per segnalare

riallocazioni o evidenziare il ritardo nell’inserimento dei consuntivi.

Anche per il HoD sono significativi tutti e tre i contesti evidenziati(Tabella

5.3) e, come per il project manager, nel contesto di un meeting o in ambi-

to mobile prevale l’esigenza di visualizzare i dati dello stato della propria

divisione.

5.3. Architettura di back-end 63

Fig. 5.4: Use Case Head of Division

Attivita Mobile Desktop Meeting

Invio di alert Media Alta Bassa

Visualizzazione ore allocate Alta Alta Alta

Visualizzazione ore consuntivate Alta Alta Alta

Tabella 5.3: Tabella dei contesti per il Head of Division

5.3 Architettura di back-end

Iniziamo ora a descrivere nel dettaglio la soluzione sviluppata per il caso

specifico di CEFRIEL. Il back-end segue il modello descritto nel capitolo

precedente e si compone da due livelli: il livello di accesso ai dati (DAL)

e livello di logica(BLL), che a sua volta contiene una parte dedicata alla

gestione del web service e una dedicata all’analisi dei dati (Fig. 5.5).

Visto che l’infrastruttura di dominio del CEFRIEL e basata su piatta-

forma Windows, abbiamo deciso di implementare tutta la parte di back-end


Fig. 5.5: Architettura del sistema nel dettaglio

utilizzando il framework .NET, con linguaggio di programmazione C#, che

assicura un eccellente integrazione con i sistemi preesistenti. Inoltre, l’uti-

lizzo di questo framework ha permesso di adottare una serie di accorgimenti

che garantiscono un’ottima flessibilita ed espandibilita del sistema.

5.3.1 Layer di accesso ai dati

L’attuale sistema Controllo Gestione Progetti (CGP) e basato su un database

chiamato CGP DB che contiene tutti i dati dei progetti attualmente attivi,

ma anche lo storico del lavoro effettuato all’interno dell’azienda. A questo

database ne e stato affiancato uno di supporto,GEDI ALERT, che abbiamo

creato per favorire la gestione degli avvisi. Abbiamo scelto di non integrare,

almeno per ora, i due database sia per policy aziendali sia per garantire

indipendente liberta di sviluppo dei due sistemi.


Fig. 5.6: Schema ER di GEDI ALERT

GEDI ALERT e schematicamente molto semplice in quanto deve conte-

nere soltanto l’elenco degli avvisi che circolano nel sistema e la loro priorita.

In particolare GEDI ALERT contiene due tabelle (Fig. 5.6): Alert e Tipo.

Per una descrizione dettagliata delle tabelle si rimanda all’Appendice B.

DAL si occupa di gestire il collegamento ai database e fornisce una serie

di metodi per facilitare le query sui dati. Dal class diagram(Fig. 5.7) si puo

capire l’organizzazione interna di DAL: il layer e composto dalla classe statica

GediDataLayerConnector e dai package Alert e CGP.

L’elemento principale del package Alert e la classe AlertDBManager, i

cui metodi sono esposti tramite interfaccia IAlertDBManager, che facilita

l’inserimento e il recupero dei dati dal database GEDI Alert.

Il package CGP e strutturato analogamente al package ALERT e contiene

le classi per l’accesso e la gestione di CGP DB, ma poiche le azioni che si

possono voler eseguire su questo database sono piu complesse e piu ampie

abbiamo deciso di creare tre classi ognuna delle quali dedicata alla gestione

di particolari aspetti. La classe BusinessDBManager fornisce i metodi per

ottenere alcune informazioni generali, come i giorni di chiusura aziendale, e i

metodi per eseguire l’inserimento e l’estrazione di un determinato consunti-

vo. Oltre a questi metodi, la classe fornisce anche quelli per ottenere le classi

dedicate alla gestione di particolari aspetti di CGP DB. La classe Projec-


Fig. 5.7: Class Diagram DAL

tsManager e specializzata nelle operazioni per la gestione delle informazioni

di CGP relative ai progetti, come SAL e WIP e l’elenco dei consuntivi in un

arco di tempo. La classe ResourceManager permette di accedere alle infor-

mazioni riguardanti le risorse, come il numero di ore di lavoro presenti nel

suo contratto o il ruolo aziendale ricoperto. I metodi delle tre classi sono

esposti tramite le rispettive interfacce IProjectsManager, IResourceManager

e IBusinessDBManager(Fig. 5.8).


Fig. 5.8: Class Diagram Package CGP

Entrambi i package contengono a loro volta un package, rispettivamente

AlertDataContext e CGPDataContext, con le classi dedicate a mappare il

modello dei dati contenuto dei database.

Le classi che implementano le interfacce non sono direttamente accessi-

bili e instanziabili dall’esterno, ma e necessario passare attraverso la classe

statica GediDataLayerConnector. Questo approccio segue il classico Factory

Pattern[10] che permette di modificare facilmente le relazioni tra le classi

concrete o crearne di nuove senza pregiudicare l’utilizzatore che, poiche non

ha visibilita della struttura implementativa, non avra nessuna ricaduta sulle

modifiche effettuate. Questa struttura risulta molto utile per esempio se si


volesse modificare il database utilizzato o se si volesse collegare nuove basi

di dati al sistema, garantendo cosı massima flessibilita e manutenibilita.

Fig. 5.9: Esempio Sequence Diagram per chiamata a DAL

Il Sequence diagram in Fig. 5.9 mostra come avviene una comune chiama-

ta a DAL, in questo caso si vuole estrarre la lista dei professional assegnati a

un determinato progetto. La prima volta che il client vuole accedere alla ba-

se di dati chiede alla classe GediDataLayerConnector di generare il manager

per il BusinessDB. Una volta generato IBusinessDBManager puo richiede-

re la classe per la gestione dei progetti, IProjectManager, e infine chiamare

il metodo per ottenere la lista dei professional assegnati al progetto. Le

classi sono generate solamente la prima volta che il client accede a DAL e

memorizzate per le successive operazioni.

LINQ

Uno dei vantaggi derivanti dall’utilizzo del framework .NET e la possibilita

di sfruttare a pieno la tecnologia LINQ [4].


La maggior parte dei programmi scritti oggi manipola in un modo o nel-

l’altro dati, e spesso questi dati vengono memorizzati in database relazionali.

Eppure c’e un divario enorme tra moderni linguaggi di programmazione e

database nel modo modo in cui rappresentano e manipolano le informazioni.

Per esempio, i linguaggi di programmazione per accedere alle informazioni

dei database devono utilizzare le API di basso livello offerte da DBMS che

richiedono query espresse come stringhe di testo. Queste query sono porzioni

significative della logica del programma, eppure sono opache al linguaggio,

incapaci di beneficiare compile-time verification e design-time features, co-

me il completamento automatico del codice. Dopo due decenni, l’industria

ha raggiunto un punto stabile nell’evoluzione delle tecnologie di program-

mazione orientati agli oggetti (OO) e i programmatori danno per scontato

caratteristiche come classi, oggetti e metodi. Guardando la generazione at-

tuale e quella successiva, e diventato quindi evidente che la prossima grande

sfida nella tecnologia di programmazione e quello di ridurre la complessita

di accesso e l’integrazione di informazioni che non sono nativamente definita

usando la tecnologia OO. Le due piu comuni fonti di informazioni non-OO

sono i database relazionali e XML.

Piuttosto che aggiungere funzionalita relazionali o specifiche per XML

ai linguaggi di programmazione, il progetto LINQ utilizza un approccio piu

generale che implica l’aggiunta di funzionalita di query generiche che si ap-

plicano a tutte le fonti di informazione, non solo relazionale o dati XML.

Questa funzione viene chiamata .NET Language Integrated Query(LINQ).

Un query-language integrato permette di beneficiare di metadati ricchi, ana-

lisi della sintassi in fase di compilazione, tipizzazione statica e completamento

automatico che in precedenza erano disponibili solo per codice imperativo.

Offre inoltre un unico meccanismo di query dichiarativo da applicare a tut-


te le informazioni in memoria, non solo informazioni provenienti da fonti

esterne. LINQ utilizza una sintassi simile a SQL, ma, oltre ai vantaggi gia

evidenziati, permette di avere il mapping automatico delle risorse in oggetti

che rende possibile eseguire interrogazioni complesse in modo molto semplice.

Tutte queste caratteristiche, combinate alla completa integrazione con

il DBMS SQL Server, ci hanno portato a scegliere LINQ come tecnologia

da utilizzare nel nostro sistema. CEFRIEL usa nell’applicazione Web di

CGP query scritte in linguaggio SQL classico, uno degli obiettivi secondari di

questo lavoro e stato quello di valutare e testare LINQ come nuova tecnologia

che possa in futuro sostituire il vecchio livello di accesso ai dati.

Per completare la breve descrizione delle caratteristiche che ci hanno spin-

to a utilizzare LINQ, evidenziamo quali sono gli altri vantaggi particolarmen-

te significativi e utili nel conteso CEFRIEL:

• Transaction: ogni interrogazione LINQ viene eseguita automaticamen-

te in un contesto transazionale, ma che puo essere implementato anche

manualmente.

• Standard query : Linq offre una metodologia standard per eseguire que-

ry, questo puo valere per tabelle relazionali, ma anche per altre fonti di

dati.

• Compile-time verification: Controllo degli errori di sintassi in fase di

compilazione e tipizzazione dei dati.

• Mapping : Mappatura semplice e intuitiva delle Stored Procedure gia

sviluppate.


5.3.2 Layer logico

Il secondo livello che andiamo ad analizzare nel dettaglio e quello della logica

applicativa. Trovandosi nel mezzo tra Presentation Layer e Data Layer, il

compito di BLL e quello di fornire ai client un mezzo semplice per accedere

a dati che normalmente richiederebbero interrogazioni complesse.

Un’alto ruolo che svolge la logica e quello di mantenere la sessione attiva

per ogni singolo utente che effettua la chiamata. Nel momento in cui avvie-

ne l’autenticazione la logica viene inizializzata, e per tutta la durata della

sessione rimane attiva mantenendo le informazioni riguardo l’utente che sta

accedendo al sistema.

Anche l’analisi dei dati ricade nel livello di business logic, ma causa la sua

complessita e l’esigenza di mantenerla indipendente dal resto del sistema, e

stato deciso di realizzare un componente separato che potesse essere gestito

e sviluppato in modo autonomo.

Il BLL e costituito da tre componenti principali che permettono di fornire

servizi verso l’esterno: SecurityManager, ProjectStateManager, AlertMana-

ger (Fig. 5.10).

Il SecurityManager e sviluppato tramite due classi che implementano la

funzionalita di autenticazione degli utenti, Access Validator, e quella di iden-

tificazione del ruolo aziendale dell’utente, User Identificator. Tramite Access

Validator, l’utente che tenta di utilizzare il sistema senza ricoprire un ruolo

all’interno dell’azienda viene automaticamente rifiutato e non puo esegui-

re alcun tipo di operazione, al contrario, se l’utente ha un account valido

all’interno del dominio aziendale, User Identificator identifica la posizione

ricoperta e abilita le funzionalita configurate per quel ruolo. La scelta di

dividere le funzionalita tra queste due classi permette di gestire facilmente

l’integrazione con i sistemi aziendali, ad esempio l’active directory di dominio,


Fig. 5.10: Business Logic Layer nel dettaglio

e gestire metodi di autenticazione devesi.

ProjectStateManager si occupa di implementare i metodi per la gestione

dei dati inseriti e facilitarne il recupero da parte del front-end.

L’AlertManager e il componente dedicato alla gestione degli avvisi che

permette agli utenti di inserire nuove segnalazioni e recuperare quelle gia

presenti nel sistema.

Infine, BLL comprende due package dedicati rispettivamente alla gestione

del web service e all’analisi dei dati.

La Fig. 5.11 mostra un sempio di esecuzione di una chiamata a un metodo

attraverso web service. Non appena dal client arriva la chiamata al metodo,

la classe che implementa il web service, controlla tramite l’access validator se


Fig. 5.11: Esempio Sequence Diagram per chiamata a BLL

l’utente ha le autorizzazioni necessarie all’esecuzione del metodo. Se l’utente

non dispone delle autorizzazioni la connessione viene chiusa e l’esecuzione

abortita. Nel caso contrario, l’esecuzione prosegue con la chiamata al rela-

tivo metodo della logica. La logica verifica se l’utente ha gia eseguito altre

operazioni e, se e ancora presente una sessione valida, recupera le informa-

zioni dell’utente. Se invece non e presente una sessione valida ne crea una.

Nell’esempio, dopo una serie di interazioni con DAL, la logica ottiene tutti

gli alert della risorsa e li converte nel DataContract AlertContract. La lista

degli AlertContract cosı ottenuti viene ripassata alla classe che implementa

il web service, la quale gestisce la serializzazione e lo scambio asincrono dei

dati con il client.


DataContract

Un DataContract e un accordo formale tra un servizio e un client che descrive

astrattamente i dati da scambiare. Per comunicare, non e necessario che il

client e il servizio condividano gli stessi tipi, ma solo gli stessi contratti

dei dati. Un contratto definisce con precisione, per ogni parametro o tipo

restituito, i dati serializzati (trasformati in XML) che verranno scambiati.

Nella nostra applicazione questi contratti sono definiti a livello di BLL

per poter essere condivisi tra tutti i web service e fornite alle classi che

implementano le interfacce di servizio informazioni strutturate, pronte per

essere trasmesse ai client. Sono stati definiti i seguenti contratti:

Fig. 5.12: Class diagram del package DataContract


AlertContract definisce i dati che rappresentano un singolo alert.

ConsuntiviContract rappresenta la struttura di un oggetto consuntivo.

AllocazioneContract rappresenta le informazioni di una singola alloca-

zione e contiene la lista dei ConsuntiviContract relativi ai consuntivi

inseriti per l’allocazione di riferimento.

TaskContract rappresenta le informazioni relative ai task e contiene la lista

dei AllocazioneContract relativi alle allocazioni associate al task.

AttivitaContract e il contratto che racchiude le informazioni un’attivita

di progetto. Contiene al suo interno la lista dei TaskContract relativi

ai task associati alla attivita.

ProgettoContract racchiude la definizione di tutte le informazioni rilevanti

di un progetto, tra cui la lista AttivitaContract relativi alle attivita

presenti per il progetto.

RisorsaContract e il contratto che definisce quali informazioni di una ri-

sorsa vengono passate tra server e client. Contiene la lista dei Consun-

tiviContract riferiti ai consuntivi inseriti.

SALContract contiene i parametri rilevanti per lo Stato Avanzamento La-

vori.

WIPContract contiene i parametri rilevanti per il valore di Work In Pro-

gress.

SerialGraphicalContract e la struttura piu generale in grado di contenere

delle serie di dati da potere visualizzare come grafico nel client.


I dati contenuti i questi contratti sono nel formato standard XML, e le

chiamate al servizio sono chiamate HTTP. Questi due standard permettono

l’eventuale fruizione di questi servizi anche da tecnologie non necessariamente

Microsoft.

5.3.3 Analisi dei dati

Il componente che abbiamo realizzato per l’analisi dei dati fa logicamente

parte del business logic layer, ma in considerazione della sua funzionalita

abbiamo deciso di svilupparlo in modo autonomo dal resto della logica. Il

componente di analisi deve periodicamente analizzare l’intero business db

e generare avvisi relativi all’attuale situazione dei progetti o delle risorse

coinvolte nell’azienda.

Visto che l’operazione di analisi puo in alcuni casi essere particolarmente

onerosa dal punto di vista prestazionale, sopratutto per il DBMS, il pro-

cesso del tool di analisi e separato dal resto del sistema. Questo permette

all’amministratore di decidere quando far partire l’analisi, con che frequenza

e eventualmente di interromperla lasciando inalterato il resto del sistema.

Inoltre, lasciando separato il tool di analisi e possibile sostituirlo o integrarlo

con altri sistemi, ad esempio, con un datawarehouse.

In particolar modo, il nostro analizzatore si concentra sul controllo di

quelli che possono essere eventi particolarmente dannosi per l’efficacia dell’a-

zienda. I vincoli che vengono analizzati, e che eventualmente generano degli

avvisi per le persone di dovere, sono i seguenti:

Regole di validazione allocazione risorsa

• Ore inserite dal professional nel mese precedente. Per ogni giorno il

totale delle ore deve essere maggiore o uguale alle ore di contratto della


risorsa. Se il totale e minore di quello richiesto viene inviato alla risorsa

e ai suoi manager un alert di alta priorita, dove si segnala il ritardo nella

consuntivazione.

• Ore inserite dal professional nella settimana precedente. Vincolo ana-

logo al precedente, ma su intervallo settimanale. Questo avviso e me-

no rilevante di quello precedente dal punto di vista di contabilita, ma

permette all’utente di controllare se e in linea con i consuntivi della

settimana prima e ai manager di sapere quanto sono aggiornati i dati

a loro disposizione.

Regole di validazione stato progetto

• Data di fine lavori. Se la data di terminazione del progetto e precedente

a quella dell’avvio del processo di analisi, e il progetto non risulta chiuso

viene generato un avviso urgente per il project manager responsabile

del progetto.

• Chiusura di progetto. Il sistema notifica il progetto chiuso, che non

risulta o terminato o rifiutato.

• Stato di progetto. Se il progetto risulta non ‘essere in linea” con le

policy aziendale, viene sollevato un alert che ne segnala il motivo.

• Data ultimo SAL. Se il project manager, responsabile della gestione

del SAL di un progetto, non aggiorna la voce dopo un certo numero di

giorni (configurabile dall’amministratore), il sistema lo notifica.

• Data fattura emessa. Analizzando la data dell’ultima fattura di proget-

to emessa possono essere generati due avvisi. Il primo, piu importante,

viene generato se e gia trascorsa la data in cui doveva essere emessa una


fattura. Il secondo, meno critico, permette di segnalare che e si sta av-

vicinando il giorno in cui il responsabile dovrebbe emettere la fattura.

Il numero di giorni entro il quale segnalare questo alert e configurabile

dall’amministratore del sistema.

Analizziamo ora la struttura interna del package Analysis.

Fig. 5.13: Class diagram del package Analysis

Il processo che si occupa di effettuare l’analisi e separato dal resto del

sistema. La classe AnalisiThread si occupa delle operazioni preliminari che

pero sono essenziali per l’analisi del sistema, come la connessione con il data

access layer. Finite le operazioni iniziali, AnalisiThread inizia a scandire

prima tutte le risorse e poi i progetti per eseguire l’analisi.

Le analisi sono eseguite tramite le classi AnalisiRisorsa e AnalisiProgetto

che ereditano e re-implementano dalla classe astratta Analisi il metodo ese-

gui. Questa struttura rende molto semplice l’implementazione di una nuova


classe di analisi, ad esempio che si appoggi a un datawarehouse, o specia-

lizzare ulteriormente le due classi di analisi gia implementate, ad esempio

per inserire nuovi tipi di analisi sui dati delle risorse. Molto semplicemente,

e sufficiente estendere la super classe Analisi e re-implementare il metodo

esegui.

5.3.4 Comunicazione

Negli ultimi anni, il passaggio all’architettura orientata al servizio(SOA) ha

cambiato lo sviluppo del software. Sia fatto tramite SOAP o in qualche altro

modo, le applicazioni che interagiscono attraverso i servizi sono diventate la

norma. Come gia evidenziato, anche noi abbiamo deciso di utilizzare per la

pubblicazione dei dati verso il front-end un web service.

Fig. 5.14: Architettura del web service nel dettaglio

La Fig. 5.14 mostra nello specifico cosa comprende il package Web Service


contenuto in BLL. I metodi esposti dal servizio sono raggruppati in due in-

terfacce, IProject e IAlert, che riuniscono rispettivamente le chiamate riferite

allo stato dei progetti e le chiamate dedicate alla gestione degli alert. L’uti-

lizzo delle interfacce permette lato client un uso piu ordinato delle chiamate

al web service.

Le interfacce esposte sono implementate in due diversi modi tramite le

classi IWAService e HTTPSService. IWAService e l’implementazione web

service che sfrutta le caratteristiche dellaIntegrated Windows Authentication

per gestire l’acceso al sistema. Questa implementazione e molto utile in

contesti dove la piattaforma di riferimento e Windows. HTTPSService e

invece l’implementazione che sfrutta HTTPS come protocollo di trasmissione

e l’Access Validator presente in BLL per gestire gli accessi. HTTPSService e

utile per poter utilizzare il sistema da sistemi operativi diversi da Windows

e device che non supportano le Windows Credential. Maggiori dettagli sugli

aspetti di sicurezza saranno forniti nell’ultima sezione di questo capitolo.

In fase di deploy i due web service possono essere contemporaneamente

attivati su indirizzi o porte diverse, oppure si puo scegliere di pubblicare

solamente uno dei due.

La scelta di realizzare due soluzione diverse vuole permettere di lasciare

grande liberta per gli sviluppi futuri, sia sul piano di integrazione con gli altri

sistemi sia dal punto di vista dello sviluppo di nuovi client.

Windows Communication Foundation

Nello sviluppo software con framework .NET, la creazione di web service e

facilitata dall’utilizzo di Windows Communication Foundation (WCF).

WCF e un sottosistema applicativo che risolve tutta una una serie di

problemi comuni nella comunicazione tra applicazioni fornendo supporto sia


per protocolli standard come SOAP, ma anche altri tra i piu comuni e diffusi

protocolli come JSON. Tra le altre cose, emergono tre aspetti fondamentali:

perfetta integrazione con le altre tecnologie di comunicazione preesistenti nel

Framework .NET, interoperabilita con applicazioni basate su altre tecnologie

e supporto esplicito per lo sviluppo orientato ai servizi.

Fig. 5.15: Esempio di utilizzo WCF

In particolare il secondo aspetto ha un ruolo rilevante in contesti aziendali,

dove le imprese si dotano spesso di sistemi e applicazioni che sono state

acquistate da una vasta gamma di fornitori che sfruttano le tecnologie piu

disparate. Le applicazioni basate su WCF sono in grado di lavorare con altri

software in esecuzione in una grande varieta di contesti(Fig. 5.15):

• Applicazioni basate su altre tecnologie, come Java EE application ser-

ver, che supportano i servizi Web standard. Queste applicazioni pos-


sono essere in esecuzione su macchine Windows o su computer che

eseguono altri sistemi operativi.

• Applicazioni WCF in esecuzione in un processo diverso sulla stessa

macchina Windows

• Applicazioni WCF in esecuzione su un altro computer Windows

Ogni servizio WCF e caratterizzato da tre componenti principali (Fig.

5.16): una classe di servizio che implementa uno o piu metodi; un processo

host in cui il servizio viene eseguito; uno o piu endpoint che consentono ai

client di accedere al servizio.

Fig. 5.16: Struttura di un servizio WCF

Nel nostro caso, come evidenziato nel capitolo precedente, abbiamo deciso

di sviluppare due diversi tipi di service class, IWAService e HTTPSService,

che si differenziano a seconda del contesto d’uso: la prima sara per utilizzo

esclusivo all’interno della rete aziendale, mentre la seconda e indirizzata a

coloro che utilizzeranno l’applicazione dall’esterno dell’azienda, per esempio

da dispositivi mobili. Le due classi si occupano di gestire i diversi aspetti di

sicurezza, mentre per tutte le altre operazioni fanno comune riferimento alle

classi per la gestione della logica interne a BLL. Naturalmente, alle due classi


sono stati associati anche due diversi endpoint con diverse caratteristiche di

sicurezza.

Per quanto quanto riguarda l’hosting dell’applicazione abbiamo deciso

di non utilizzare un semplice processo, ma ci siamo affidati a Internet In-

formation Service (IIS) 7.0 per garantire maggiori performance, sicurezza e

affidabilita.

5.3.5 Sicurezza del sistema

L’aspetto della sicurezza del sistema e stato affrontato con attenzione. Il

framework WCF offre una vasta gamma di soluzioni adottabili in questo

ambito [14] che non modificano in alcun modo la struttura delle’architettura,

ma intervengono sul livello di interfaccia tra servizio e client.

Per quello che riguarda l’autenticazione, una dei requisiti essenziali era

quello di rendere il sistema sicuro, ma allo stesso tempo il piu immediato

possibile da fruire. Per questo motivo, abbiamo sfruttato il piu possibile

gli strumenti di autenticazione offerti da IIS come la Integrated Windows

Authentication per sistemi operativi Windows. Per il dispositivo mobile,

si e voluto lasciare ampia liberta di evoluzione verso sistemi non basati su

piattaforma Microsoft e si e predisposto un sistema di riconoscimento delle

credenziali basato sulla classica Form Authentication.

In entrambi i casi il modulo che si occupa della gestione degli accessi

controlla la validita delle credenziali e restituisce una conferma di avvenuta

autenticazione. Tali informazioni sono ricercate e recuperate nell’Active Di-

rectory, il quale contiene l’elenco degli account registrati nel dominio. Nel

caso di IWA e stato possibile sfruttare a pieno il modulo per il controllo gia

presente in IIS, mentre per la FA abbiamo implementato un componente ad

hoc.


Integrated Windows Authentication

Integrated Windows Authentication e il sistema di autenticazioni preferi-

to per utenti che si trovano all’interno dello stesso dominio Windows. Le

informazioni su l’utente che sta utilizzando il client sono fornite al sistema

attraverso uno scambio crittografato di informazioni che coinvolgono il client,

il web service e un terzo server fidato.

Il vantaggio di questo tipo di autenticazione e che l’utente non deve inse-

rire altre credenziali oltre a quelle che ha gia inserito per accendere il device.

Inoltre, la IWA non invia le password dell’utente o altre informazioni sensi-

bili al server, ma si limita a comunicare l’username della persona che vuole

accedere al sistema.

In Fig.5.17 e raffigurato lo scambio di messaggi secondo il protocollo

Kerberos che abbiamo utilizzato nella nostra soluzione.

Quando il client accede al servizio manda la richiesta al Domain Control-

ler, il quale e composto da un Authentication Service e da Ticket Granting

Service collegati direttamente all’Active Directory. Il Domain Controller gli

fornisce un service session-key e un service ticket necessari per contattare il

Service Server. Il client manda il messaggio di autenticazione (time stamp)

criptato utilizzando una service session-key e service ticket al Service Server.

A questo punto, usando la service session-key, il Service Server decripta il

messaggio di autenticazione (time stamp) e lo valuta. Se questo messaggio

passa il test, il server cifra il timestamp usando la service session-key e ri-

passa il messaggio al client. Il client decifra il messaggio e se il messaggio

e lo stesso di quello originale il servizio e valido e il client procede con la

connessione. Il protocollo Kerberos non solo permette di utilizzare la Win-

dows Authentication, ma controlla la mutua autenticazione di client e server

prima dello scambio di messaggi.


Fig. 5.17: Integrate Windows Authentication (Kerberos v5)

Se a livello di autenticazione il protocollo precedentemente descritto e

altamente prestazionale, non vale lo stesso per quanto riguarda i requisiti

cardine del modello CIA in quanto non fornisce nessuna delle tre caratte-

ristiche richieste. In realta, questa mancanza dei requisiti CIA non e un

problema, in quanto l’ambiente entreprise nel quale e collocata l’architettura

e ritenuto sufficientemente sicuro per garantire i requisiti di Confidenzialita,

Integrita e Disponibilita. L’uso di questo meccanismo di autenticazione per

interagire dall’esterno dell’azienda e invece fortemente sconsigliato, a meno

che non venga prima instaurata una VPN.


Form Authentication

La Form Authentication e il classico sistema di autenticazione che prevede

l’inserimento del nome utente e della password utilizzando delle caselle di

testo e che e spesso utilizzato nelle pagine web perche garantisce sicurezza

e allo stesso tempo semplicita per l’utente. Naturalmente, poiche questo

sistema viene prevalentemente usato dall’esterno dell’azienda, non possiamo

fare affidamento sulla sicurezza dell’ambiente enterprise come nel caso della

autenticazione integrata di Windows. Per risolver il problema dell’insicurezza

del canale la prassi piu comune, e che anche noi abbiamo deciso di adottare, e

la cifratura del messaggio. In particolare si e utilizzato il protocollo HTTPS,

cioe HTTP over Secure Socket Layer, con autenticazione server.

Fig. 5.18: Scambio di messaggi utilizzando HTTPS

Questo protocollo richiede un certificato X509 valido per il server verifi-

cabile dal client (Vedi Fig. 5.18) per garantire le policy di sicurezza minime

per rispettare vincoli del modello CIA. Non avendo a disposizione un certifi-

cato rilasciato da una certification authority riconosciuta, abbiamo utilizzato

un certificato Self-Signed dal server. L’uso di questo tipo di certificato non

inficia le caratteristiche del protocollo, a condizione che il certificato venga

5.4. I client 87

distribuito prima al client tramite un meccanismo crittografico o in ambien-

te sicuro come quello enterprise. E’ comunque consigliabile l’utilizzo di un

certificato firmato da una certification authority.

In questo contesto il meccanismo di autenticazione e differente dal prece-

dente. Inizialmente si ha la negoziazione fra le parti dell’algoritmo da utiliz-

zare e successivamente lo scambio della chiave da utilizzare per la cifratura

dei messaggi. Dopo questa fase iniziale, client e server iniziano a comunicare

tramite messaggi cifrati con chiave simmetrica e autenticati. Tutte le volte

che il client fa una richiesta al server per invocare un servizio deve include le

proprie credenziali. Il server decifra il messaggio, controlla che le credenziali

siano valide e in caso affermativo permette di accedere al servizio. In questo

caso il controllo della validita delle credenziali e affidato all’Access Validator

(vedi Fig. 5.5), che verifica se l’utente che ha richiesto l’accesso al servizio

e registrato come utente di dominio nell’Active Directory e che la password

inviata e corretta.

Il vantaggio di questa soluzione e che puo essere usata da qualsiasi device

con qualsiasi sistema operativo, ma paga un maggiore effort nella fase iniziale

e un overhead durante tutta la fase di scambio di messaggi.

5.4 I client

Avere le informazioni non sempre e rilevante, bisogna anche riuscire a rappre-

sentarle in modo efficace e soprattutto in modo intuitivo per l’utilizzatore[20].

Il livello presentazione e a diretto contatto con la user experience dell’utente,

quindi tutte le scelte adottate sono state attentamente studiate e testate.

Per scelta progettuale abbiamo ridotto il piu possibile la logica contenuta

nei client, semplificando lo sviluppo di soluzioni per dispositivi diversi. Tra le


alternative esaminate abbiamo deciso di sviluppare nell’ambito desktop un

Windows Gadget, nell’ambito mobile un’applicazione per Windows Phone

7 e un proof of concept di un’applicazione in contesto meeting che utilizza

Kinect.

Per realizzare un’interfaccia utente in grado di soddisfare al meglio i re-

quisiti dei propri utenti, serve e una piattaforma che renda facile costruire

interfacce usando semplici modelli di progettazione. Per questo abbiamo de-

ciso di utilizzare come linguaggio di sviluppo nuovamente il framework .NET

e in particolare Silverlight 4.0, che fa parte di Windows Presentation Foun-

dation (WPF) . Gli aspetti che ci hanno spinto a scegliere questa tecnologia

sono principalmente tre:

• Possibilita di realizzare interfacce altamente interattive e complesse,

ma allo stesso tempo intuitive.

• Possibilita di adottare in modo efficiente il pattern di sviluppo Model-

View-View-Model (MVVM), che garantisce il massimo del riutilizzo del

codice.

• Disponibilita della tecnologia tutti e tre i contesti di interesse.

5.4.1 Pattern MVVM

Da quando si e cominciato a creare interfacce utente software, ci sono stati

vari pattern di progettazione per contribuire a rendere piu facile lo sviluppo.

Ad esempio, il Model-View-Presenter (MVP), variante del pattern per

eccellenza per molti anni Model-View-Controller, ha goduto di popolarita su

diverse piattaforme di programmazione. Quello che si vede sullo schermo e la

View, i dati da visualizzare sono il Model e il Presenter collega le due parti:

5.4. I client 89

la View sfrutta il Presenter per estrarre i dati del modello, reagire all’input

dell’utente e altre attivita simili.

Partendo da questo modello e stato poi proposto il Presentation Model

(PM) pattern[15], simile a MVP, ma che presenta in piu una astrazione

della View, chiamata appunto PresentationModel, e in cui ogni View diventa

semplicemente un rendering di questa astrazione.

Ultima evoluzione di questa sequenza di modelli e il Model-View-ViewModel

(MVVM) pattern[26], specializzazione del piu generale modello PM, per il fra-

mework .NET. Come dice il nome stesso, MVVM si basa su tre componenti

essenziali: il Model, la View e il ViewModel.

Fig. 5.19: Pattern MVVM

La View definisce la struttura e l’aspetto di cio che l’utente vede sullo

schermo. Idealmente, il code-behind di una vista contiene solo il costruttore,

ma in alcuni casi, puo contenere codice di logica di interfaccia che implementa

un comportamento visivo che e difficile o inefficiente esprimere in eXtensible

Application Markup Language (XAML), come le animazioni complesse, o

quando il codice ha bisogno di manipolare direttamente gli elementi visivi

presenti nella View. Naturalmente la View deve essere personalizzata in base

al device e al contesto in cui l’utente utilizzera l’applicazione.

Il ViewModel incapsula la logica di presentazione e dati per la View. A

differenza del Presenter in MVP, un ViewModel non ha bisogno di un riferi-


mento a una View, ma e la View che si lega a una proprieta del ViewModel

che espone i dati contenuti nel Model o altri dati specifici per la View. Le

associazioni tra i due componenti sono molto semplici da costruire perche

basta impostare il ViewModel come DataContext della View a cui si vuole

associare. Se i valori delle proprieta del ViewModel cambiano, i nuovi valo-

ri sono propagati automaticamente alla View tramite il Data Binding(Fig.

5.19). Quando l’utente fa clic su un pulsante nella vista, il comando asso-

ciato implementato nel ViewModel esegue l’azione richiesta. Il ViewModel

ha quindi il compito di coordinare l’interazione della View con tutte le classi

del Model, nel nostro caso, instanzia un una classe proxy che mappa i me-

todi offerti dal web service e si occupa di gestire le chiamate asincrone. Il

ViewModel, e non la View, esegue tutte le modifiche da apportate ai dati del

modello. Le classi della View non hanno idea che esistano le classi del Model,

mentre il ViewModel e il Model non sono a conoscenza dell’esistenza della

View e questo disaccoppia in modo ottimale lo sviluppo delle varie parti.

Infine, Model incapsula la logica business e dati e nel nostro caso e

collocato completamente lato back-end (Fig. 5.20).

L’aspetto piu importante di WPF che rende facile utilizzare MVVM e

l’infrastruttura di data binding che permette con una semplice associazione,

e implementazione dell’interfaccia INotifyPropertyChanged, di rimuovere la

necessita in ViewModel di scrivere il codice per l’aggiornamento della View.

Il sistema supporta anche meccanismi per la convalida dei dati di input e

fornisce un metodo standard di trasmissione degli errori di convalida alla

View.

MVVM e un modello molto popolare anche perche le classi ViewModel

sono facili da testare. In un certo senso, View e Unit Test sono solo due tipi

di consumatori del ViewModel. La possibilita di generare facilmente casi di

5.4. I client 91

Fig. 5.20: Pattern MVVM nell’architettura

test aiuta nel corso del tempo a ridurre il costo di mantenimento.

Nel nostro caso specifico(Fig. 5.21), adoperando MVVM siamo riusciti nei

tre contesti di riferimento a riutilizzare, con piccolissime modifiche, la parte

di ViewModel riscrivendo solamente il codice relativo alla View per sfruttare

al meglio le caratteristiche del device che stavamo utilizzando.


Fig. 5.21: Class diagram delle classi che implementano il MVVM

5.4.2 Front-end desktop

I gadgets Desktop sono piccole applicazioni specializzate che sono general-

mente sviluppate per eseguire un singolo task. Il vantaggio di queste appli-

cazione e la possibilita di averle sempre sott’occhio e a portata di click sul

desktop, garantendo cosı l’immediatezza che stavamo cercando.

Il gadget Windows e composto principalmente da tre viste: la Home

principale che anche la parte sempre visibile quando il gadget e attivo, la

pagina Settings dove si possono configurare le impostazioni del gadget e la

pagina Flyout che, a richiesta, estende l’area del gadget per permette di

visualizzare maggiori dettagli.

La Fig. 5.22 mostra come si presenta l’interfaccia del gadget al primo av-

vio. Dopo un rapido login automatico, del tutto invisibile all’utente, la home

mostra nella parte alta i ruoli che la persona ricopre all’interno di CEFRIEL.

In ogni pagina della home vengono mostrati l’elenco dei messaggi, raggruppa-

5.4. I client 93

Fig. 5.22: Gedi Gadget Fig. 5.23: Gedi Gadget in due istanze

ti per tipologia, che l’utente a deciso di voler visualizzare nel proprio gadget.

Per quanto riguarda lo stile del gadget, ci siamo ispirati allo stile della nuova

UI Metro presente sui nuovi WindowsPhone 7[7].

Uno dei vantaggi dell’uso dei gadget e la possibilita di creare istanze

differenti per il singolo oggetto. Per l’utente che ricopre due (o piu) ruoli

all’interno dell’azienda e possibile creare un’istanza del gadget per ogni ruolo

ricoperto e avere una visione completa e immediata di tutte le sue aree di

competenza(vedi Fig. 5.23). Se l’utente lo ritiene utile, ogni gadget puo essere

ancorato stabilmente in primo piano e ne puo essere regolata l’opacita.

Il gadget e stato sviluppato principalmente utilizzando Silverlight v.4 e

in questo modo, come visto nella sezione MVVM, siamo riusciti a creare un

ottimo disaccoppiamento tra interfaccia grafica e logica e a massimizzare il

riuso e la manutenibilita del codice.

La home si caratterizza per lo stile basato sui Tile, in cui ogni rettan-

golo rappresenta una tipologia di avviso che puo interessare l’utente. I tile

contengono un’icona che rimanda alla tipologia di avviso, il nome del tipo di


avviso e il numero di alert di quella categoria. La lista e l’aspetto dei singo-

li tile e completamente personalizzabile tramite i settings. Quando l’utente

vuole inserire dei dati o leggere degli avvisi puo semplicemente cliccare sul

tile corrisponde. Per tutti i ruoli aziendali la struttura iniziale a tile e la

stessa, ma naturalmente contiene tipi diversi di informazioni.

Le pagine di flyout vengono mostrate alla selezione di un tile e raccolgono

tutti i dettagli e le azioni che e possibile eseguire nel sistema. Le pagine sono

state sviluppate rispettando le esigenze evidenziate dai casi d’uso descritti

5.2 e sfruttando al meglio i feedback degli utenti che hanno provato il sistema.

Fig. 5.24: Inserimento e consuntivazione Professional

Dal flayout dedicato ai professional (Fig. 5.24) e possibile controllare i

progetti, le attivita, i task e allocazioni su cui l’utente e allocato e puo vi-

sualizzare, inserire e modificare le ore consuntivate. Nella parte bassa, e

rappresentato il grafico delle ore consuntivate nell’ultimo mese per il proget-

to selezionato o per tutti i progetti su cui il professional e allocato. Ogni

utente ha anche la possibilita, cliccando sull’icona gialla di attenzione in al-

5.4. I client 95

to a sinistra, di visualizzare un elenco di avvisi che lo riguardano e che gli

ricordano scadenze o che sono stati inviati da uno dei suoi manager per se-

gnalare una variazione nel progetto. Dopo aver letto l’avviso, l’utente puo

segnare l’alert come read, ma se non ha aggiornato o corretto la causa che lo

ha generato l’analizzatore si accorge che il problema persiste e riaggiorna la

segnalazione che riappare all’utente. Sarebbe buona norma che l’utente do-

po avere esaminato l’alert modifichi i suoi valori facendo in modo che questo

evento non venga piu generato.

Fig. 5.25: Visualizzazione dettagli progetti per PM

Per i project manager e gli account manger, nella visione dei dettagli (Fig.

5.25) si offre la possibilita di monitorare i KPI e alcuni grafici interessanti per

ogni singolo progetto attivo. Gli indici di piu rilevanti che abbiamo deciso

di inserire sono: la data dell’utlimo ultimo consuntivo relativo al progetto

in analisi, il valore del SAL attuale, il valore del WIP nel mese corrente e

quello del mese precedente. Nella lista di progetti sulla sinistra e presente

anche un’indicatore che permette a colpo d’occhio di identificare i progetti


che presentano particolari problemi. L’indicatore puo essere di colore rosso,

nel caso il progetto presenta criticita rilevanti, arancione se presenta proble-

mi che allo stato attuale non sono critici (anche se deve essere monitorato) e

verde se risulta essere in linea con le policy aziendali. Infine, nella parte in-

feriore e stata lasciata una sezione per rappresentare i grafici dell’andamento

temporale di alcuni fattori critici. Le serie che possono essere visualizzate

sono:

• Ore consuntivate nell’ultimo mese. Permette di monitorare lo stato di

avanzamento del progetto, valutando il numero di ore spese giorno per

giorno.

• Avanzamento del SAL nell’ ultimo mese. E’ un grafico incrementale che

offre la possibilita di vigilare a livello economico lo stato del progetto.

L’area e espandibile quindi, se ce ne fosse l’esigenza, si potrebbero inserire

facilmente altri grafici.

Vediamo infine le funzionalita offerte dal gadget desktop per i capi divi-

sione (Fig. 5.25). Questo utente e responsabile delle risorse per la propria

divisione, quindi deve conoscere lo stato di tutti gli utenti. Le informazioni

sono visualizzate sono:

• Informazioni generali riguardo la risorsa nel sistema.

• La data dell’ultimo consuntivo e la quantita di ore inserite per poter

monitorare l’attivita della risorsa.

• Il numero di progetti nel quale la risorsa e allocata. In questo modo

e possibile evitare di allocare la risorsa in troppi progetti contempora-

neamente.

5.4. I client 97

Fig. 5.26: Pagina di dettaglio per i capi divisione

Il capodivisione ha, come avviene per i progetti per project manager, un’in-

dicatore che permette di visualizzare istantaneamente come e lo stato della

risorsa.

Fig. 5.27: Pagina di invio di avvisi


Per tutti i manager il gadget offre una funzionalita aggiuntiva rispetto

ai professional. Nel flayout, accanto all’icona degli avvisi, c’e un’altra icona

cliccando sulla quale i manager possono inviare avvisi a tutte le risorse as-

segnate a un progetto di loro competenza o che appartengono alla divisione

che gestiscono (Fig. 5.25). Gli avvisi possono essere utilizzati per richiamare

l’attenzione di una risorsa al rispetto di determinate policy o come mezzo

per notificare attivita di progetto.

5.4.3 Front-end mobile

Per quanto riguarda il conteso mobile, abbiamo preso come piattaforma di

riferimento Windows Phone 7.

Seppure sia la piattaforma piu giovane tra le tre presentate nel capitolo2

e al momento non supporti alcune funzionalita gia presenti nelle piattaforme

concorrenti, Windows Phone 7 e una piattaforma molto promettente. I re-

centi accordi economici siglati da Microsoft con grandi case case di telefonia

mobile, ultima delle quali Nokia, fanno presumere una diffusione su larga

scala nel breve periodo. Inoltre, la mancanza di un unico vendor hardware,

ma allo stesso tempo una serie di requisiti tecnici indispensabili, produrranno

una forte concorrenza che permettera da un lato l’abbassamento dei prezzi

e dall’altro la produzione di device diversificati per fascia di clientela, che

accelereranno ulteriormente la diffusione della piattaforma.

Le prospettive di diffusione non sono comunque state il fattore principale

di scelta. Le caratteristiche che ci hanno maggiormente convinto sono state

l’ottima integrazione con le tecnologie del framework .Net, in particolare

Silverlight, e sopratutto la nuova Metro User Interface. Inoltre, la giovane

eta della piattaforma fa si che ci siano ancora molti ambiti inesplorati che

possono dare risultati eccezionali.

5.4. I client 99

Metro UI ha uno stile molto minimalista ispirato alla segnaletica delle

grandi metropolitane di Washington, NewYork e Tokio che pero guida rapi-

damente le persone nella direzione giusta fino alle informazioni che vogliono

avere. Metro UI e progettato per essere al tempo stesso moderno, veloce e

elegante, ponendosi in forte contrasto con l’interfaccia a icone presente in

Android e iOS non cercando di riprodurre gli effetti dei materiali reali sul-

lo schermo, ma sfruttando al meglio quanto offerto dai pixel. Il risultato e

sicuramente il miglior design tra le piattaforme in circolazione e, come ac-

cennato precedentemente, abbiamo deciso di ispirarci a essa per realizzare lo

stile delle nostre nostre user interfacce.

La funzionalita primaria nel contesto mobile non e l’inserimento dei dati,

ma bensı la consultazione. Per questo motivo abbiamo deciso di privilegiare

gli aspetti di usabilita dell’interfaccia nella lettura dello stato dei progetti e

degli avvisi, limitando invece la parte di inserimento solamente all’invio.

Uno dei nuovi controlli introdotti dalla Metro UI e il Panorama, che per-

mette di visualizzare orizzontalmente informazioni e immagini che superano

i limiti fisici della dimensione dello schermo. Abbiamo adottato questo ti-

po di controllo per la pagina iniziale della applicazione per permettere agli

utenti che hanno piu ruoli in azienda di visualizzare con poche gesture tutte

le informazioni riguardanti le proprie attivita. La homepage (Fig. 5.28) puo

essere vista come un lungo muro su cui sono appese le tile degli avvisi che

interessano all’utente.

Cliccando sulle tile si apre la pagina(Fig. 5.28) con l’elenco completo

degli alert e l’utente puo vedere il dettaglio di ogni singolo avviso. Sempre

per quanto riguarda gli alert, se l’utente e un manager puo passare alla

visualizzazione di invio e digitare avvisi da mandare ad altri utenti collegati

alle sue attivita.


Fig. 5.28: Home GEDI Windows phone 7

5.4.4 Front-end gestuale

L’ambiente meeting e collaborativo si presta a particolarmente bene a in-

terazioni di tipo gestuale. Guardando ai progetti diffusi in rete in questo

ambito, ci sono gia state numerose sperimentazioni di utilizzo della periferi-

ca WiiMote come contoller per presentazioni o come strumento di interazione

a distanza.

Per quanto ci riguarda, abbiamo cercato di andare oltre queste sperimen-

tazioni e realizzare proof-of concept di un’applicazione a interfaccia puramen-

te gestuale, cioe senza alcun tipo di controller, sfruttando Kinect. La parte

di front-end in questo caso sara completamente differente da quelle viste in

precedenza in quanto e pensata per i manager che devono mostrare report,

grafici e dettagli riguardo l’andamento delle attivita ai propri clienti o nei

meeting aziendali. Inoltre, la possibilita dell’applicazione di interfacciarsi di-

5.4. I client 101

rettamente con l’architettura di back-end permette anche la visualizzazione

di dati in tempo-reale.

Questo front-end non ha la pretesa di essere completo e affidabile come gli

altri perche le librerie ufficiali per utilizzare Kinect da pc saranno rilasciate

solamente nei prossimi mesi. Offre pero un assaggio anticipato di quello

che sara il futuro dell’interazione uomo-macchina dei prossimi anni. L’essere

privato di controller e interagire liberamente con un’applicazione in grado

di riconoscere la persona che ha davanti, crea un’atmosfera quasi magica

che ha l’effetto di ridurre notevolmente le barriere culturali all’utilizzo della

tecnologia imposte dalle attuali interfacce grafiche.

Sviluppo software con Kinect

Tramite alcuni accorgimenti e possibile collegare Kinect a un normale pc,

ma purtroppo ancora non sono state rilasciate pubblicamente da Microsoft

le librerie di sviluppo e i driver per il device. L’interesse per questa nuova

tecnologia ha pero spinto le comunity opensource a sviluppare driver e librerie

software per non dover aspettare il rilascio di quelle ufficiali.

Dopo aver analizzato i vari progetti che sono partiti, abbiamo cercato

di capire con dei test quale fosse il piu valido, completo e affidabile. Alla

fine abbiamo deciso di utilizzare le librerie Open Natural Interface (OpenNI)

con i driver rilasciati da PrimeSense, societa sviluppatrice e produttrice delle

telecamere di profondita presenti in Kinect.

OpenNI e un framework molto ampio che offre interfacce di program-

mazione software per scrivere applicazioni basate sulla natural interaction.

Questo framework non esclusivamente dedicato a Kinect, anche se al mo-

mento e il principale device utilizzato. Il framework fornisce sia API di basso


livello per l’accesso diretto ai dati RAW del device, sia API di piu alto livello

che forniscono funzionalita piu avanzate come il riconoscimento del volto.

Sul piano dei sistemi operativi sono supportate le piattaforme Windows,

Mac e Linux e per la programmazione si puo utilizzare C/C++ o un wrapper

C#.

La nostra soluzione

La nostra soluzione e stata realizzata su piattaforma Windows 7 e, per sem-

plificare lo sviluppo, abbiamo deciso di mappare i movimenti della mando

dell’utente con quelli del mouse. Per riuscire a ottenere questa mappatura

abbiamo utilizzato le librerie di riconoscimento della mano messe a disposizio-

ne dal framework. Questa soluzione comporta dei ritardi nella propagazione

del movimento, ma accettabili per lo scopo dimostrativo di questa soluzione.

Analogamente agli altri front-end, l’interfaccia grafica e stata realizzata

in Silverlight e anche in questo caso e stato possibile riutilizzare gran parte

del codice gia sviluppato.

Dopo la schermata iniziale (Fig. 5.29), l’utente muovendo la mano a destra

e a sinistra puo scorrere i progetti per cui sono disponibili delle slide o dei

grafici (Fig. 5.30).

Trovato il progetto di suo interesse, spostando la mano verso il basso

l’utente puo iniziare a sfogliare le informazioni disponibili(Fig. 5.31), sempre

muovendo la mano a destra e a sinistra. Se l’utente vuole cambiare progetto

puo tornare alla schermata precedente semplicemente muovendo verso l’alto

la mano. Se invece ci sono delle informazioni particolarmente importanti, e

possibile aggiungere le slide di interesse alle note trascinandole verso il basso

e, a fine meeting, stamparle.

5.4. I client 103

Fig. 5.29: Pagina Iniziale GEDI kinect Fig. 5.30: Selezione dei progetti

Fig. 5.31: Selezione del report

Oltre al semplice movimento piano della mano, abbiamo deciso di map-

pare anche un movimento veloce in direzione del Kinect, come se si volesse


afferrare un oggetto sullo schermo, con un evento di pressione del tasto si-

nistro del mouse. Questo ci ha permesso di inserire anche una gesture per

ingrandire a tutto schermo la slide corrente della presentazione.

Per iniziare a tracciare il movimento della mano e necessario fare una

gesture di avvio muovendo velocemente la mano a destra e a sinistra, come a

voler salutare il device. Se in sala ci sono, come e plausibile per un meeting,

piu persone possono interagire con il client entro una distanza di quattro

metri.

Capitolo 6

Direzioni future di ricerca e

conclusioni

”La mente che si apre ad una nuova idea non torna mai alla dimensione

precedente.”

Albert Einstein

In questo capitolo a conclusione della trattazione del lavoro svolto ci focaliz-

ziamo sui risultati ottenuti e le prospettive di sviluppo futuro per la soluzione

realizzata nel caso di studio.

6.1 Piloting

La fase conclusiva del lavoro ha visto l’avvio di un piloting per testare le

soluzioni proposte e raccogliere feedback da parte degli utenti.

In Fig. 6.1 sono riportate nell’arco dell’anno 2010, con frequenza giorna-

liera, il numero di operazioni di inserimento dei consuntivi degli utenti.

Le policy aziendali prevedono che ogni dipendente inserisca entro le prime

settimane del mese i consuntivi delle ore lavorate in quello precedente. Le

106 Capitolo 6. Direzioni future di ricerca e conclusioni

Fig. 6.1: Grafico dei giorni di inserimento dei consuntivi distribuito in un anno

Fig. 6.2 e Fig. 6.3 evidenziano la presenza di picchi in inserimento nelle

prime settimane seguite da diminuzione in quelle successive. Tra le esigenze

percepite dall’azienda c’e quella di cercare di uniformare lungo tutto il mese

l’inserimento dei dati.

Fig. 6.2: Grafico dei giorni di inserimento dei consuntivi distribuito su sei mesi

Con la nostra soluzione vogliamo ridurre i picchi in corrispondenza delle

scadenze e cercare di distribuire in modo uniforme, o almeno con frequenza

settimanale, l’inserimento dei dati in modo da avere un quadro piu allineato

con il reale stato dell’azienda. Le interfacce sviluppate e il sistema di analisi

e notifica, garantiscono un meccanismo semplice di inserimento dei dati che

incentiva le operazioni.

I primi focus group con professional, project manager e head of division

ha dato degli ottimi feedback sul lato delle funzionalita, ma per poter vedere

6.2. Conclusioni 107

Fig. 6.3: Totale consuntivi inseriti raggruppati per giorno del mese

gli effetti complessivi dobbiamo attendere l’utilizzo intensivo e prolungato

della nostra soluzione in tutta l’azienda.

6.2 Conclusioni

Tra i obiettivi principali delle moderne aziende c’e quello della gestione e

dell’utilizzo dei dati in modo efficace. L’obiettivo che ci eravamo posti e

stato quello e riuscire a proporre una soluzione in grado di analizzare le

performance dell’azienda con una bassa latenza e di prendere decisioni in

modo tempestivo.

La soluzione che abbiamo realizzato si basa su l’utilizzo delle piu recen-

ti tecnologie di presentazione e interazione con i dati e su un’architettura

flessibile e modulare.

Le caratteristiche dell’architettura sviluppata garantiscono l’integrazione

con i sistemi aziendali preesistenti e permettono un’analisi delle performance

in modo tempestivo introducendo costi o infrastrutture contenute. La buona

modularizzazione garantisce ampia scalabilita e espandibilita, oltre a favorire


gli aspetti di manutenibilita e riuso delle caratteristiche gia introdotte da noi.

Nel complesso, il sistema risulta fortemente multi-piattaforma e multi-canale.

Il prototipo realizzato conferma la flessibilita dell’architettura e l’effettiva

efficacia della nostra proposta. Inoltre, lo studio preliminare condotto ci ha

permesso di astrarre modello di organizzazione interna di riferimento che

permette di replicare la nostra soluzione in altre aziende rispetto a quella del

caso di studio.

Nel corso del lavoro abbiamo dedicato particolare attenzione a capire le

esigenze delle persone in diversi contesti e per ognuno abbiamo scelto la

tecnologia piu adatta a soddisfare le esigenze evidenziate. Vediamo ora per

ognuno dei front-end sviluppati le caratteristiche che siamo riusciti a coprire

in riferimento al modelle descritto in 3.3.3.

Front-end desktop

Fig. 6.4: Modello di riferimento - Caratteristiche coperte dal front-end desktop

Il front-end desktop e dedicato ad un uso personale e copre molte delle

caratteristiche del modello. Tramite metafore e colori si ha un impatto visivo

6.2. Conclusioni 109

immediato sullo stato dell’azienda, ma grazie alle funzionalita avanzate e

possibile visualizzare chart e aggregare o espandere i dettagli. Le informazioni

visualizzate sono on demand e descrivono lo stato attuale e lo storico di

determinati dati.

Front-end mobile

Fig. 6.5: Modello di riferimento - Caratteristiche coperte dal front-end mobile

L’utilizzo di device mobili implica un ulteriore attenzione per la quantita

di dati scambiati. Per questo motivo si e preferito ridurre la profondita di

dettaglio e mostrare metafore e dati aggregati.

Front-end gestuale

Il prof-of-concept del front-end gestuale si concentra sugli aspetti collabora-

tivi e di visualizzazione dei dati sotto forma di grafici e indicatori aggregati.

Resta comunque possibile integrare nelle presentazioni dati provenienti on

demand dal back-end.


Fig. 6.6: Modello di riferimento - Caratteristiche coperte dal front-end gestuale

6.3 Sviluppi futuri

La soluzione realizzata e i risultati ottenuti con questo lavoro aprono la strada

a molteplici sviluppi futuri sia lato back-end che lato front-end.

6.3.1 Sviluppi futuri per il back-end

Lato back-end gli sviluppi piu interessanti si concentrano su quattro aspetti:

introduzione di nuove sorgenti di dati, l’incremento delle capacita di ana-

lisi del sistema, integrazione con altri sistemi aziendali, ampliamento dei

protocolli disponibili.

L’architettura flessibile e modulare della soluzione permette di aggiun-

gere molto facilmente nuove sorgenti di informazioni. Sviluppando nuovi

componenti per DAL dedicati alla connessione e alla gestione delle nuove

sorgenti, sarebbe possibile integrare il sistema con l’ERP aziendale o accede

alle informazioni contenute nel datawarehouse. Questi dati, per ragioni di

riservatezza delle informazioni, non sono stati potuti essere utilizzati in que-

6.3. Sviluppi futuri 111

sto lavoro di tesi, ma arricchirebbero notevolmente le capacita del sistema

facendolo diventare uno strumento ancora piu potente e completo.

Arricchendo la quantita di dati, si potrebbe anche ampliare i tipi di analisi

effettuate dal Analyzer. Per ampliare le analisi da effettuare sulle dimensioni

gia considerate e sufficiente estendere le classi gia sviluppate per l’analisi dei

progetti e delle risorse. Se invece si volesse effettuare analisi su una nuova

dimensione, ad esempio i clienti, basterebbe introdurre una nuova classe di

analisi specifica per la dimensione che estende la super classe astratta di ana-

lisi. Vista la disponibilita di un datawarehouse, si puo anche pensare di rea-

lizzare un componente che sfrutti i dati e le capacita di questo strumento per

realizzare analisi ancora piu sofisticate o di riutilizzare quelle gia impostate.

Nell’Analyzer potrebbero anche essere introdotte funzionalita che partendo

dai dati raccolti formulino previsioni future sull’andamento dell’impresa.

Il terzo interessante sviluppo futuro riguarda l’integrazione della nostra

soluzione con gli altri sistemi presenti. Per esempio, l’attuale sistema web

di inserimento dei dai potrebbe essere modificato per sfruttare anch’esso le

nuove funzionalita introdotte oppure il sistema di contabilita puo essere in-

tegrato con il sistema per inviare notifiche importanti ai manager o agli altri

dipendenti.

Infine, l’ultimo aspetto che potrebbe essere ampliato riguarda i web ser-

vice, in particolare i protocolli di comunicazione utilizzati. Negli ultimi anni

si sono sviluppati protocolli per lo scambio di informazioni piu efficienti del

protocollo SOAP, come ad esempio JSON. L’utilizzo di WCF e l’architettura

sviluppata, garantiscono la possibilita di ampliare i protocolli supportati sem-

plicemente definendo un nuovo EndPoint dedicato e riutilizzare interamente

la logica gia presente.


6.3.2 Sviluppi futuri per il front-end

Per quanto riguarda il front-end e possibile fare evolvere in futuro il sistema

in due direzioni.

La prima direzione di sviluppo e quella di ampliare le soluzioni attuali

in modo da coprire altri aspetti tra quelli descritti in 3.3.3. Le frecce e i

cerchi tratteggiati in Fig. 6.4, Fig. 6.5 e Fig. 6.6 indicano per ognuno dei

front-end le caratteristiche che potrebbero essere inserite. In particolare,

sarebbe interessante cercare di introdurre funzionalita dedicate alla visualiz-

zazione delle previsioni fatte sui dati o introdurre nuovi meccanismi realtime

di esplorazione in profondita delle informazioni. Sempre nel contesto evolu-

tivo delle attuali client, il front-end gestuale, attualmente sviluppato al solo

scopo dimostrativo, apre interessanti prospettive di utilizzo reale. Ad esem-

pio, sarebbe interessante integrare le funzionalita proposte con i principali

strumenti di presentazione diffusi in azienda o in gadget per TV.

Il secondo aspetto interessante su cui continuare a lavorare riguarda inve-

ce la possibilita di sviluppare sistemi complementari a quelli che noi abbiamo

proposto. Essendo l’architettura pensata per essere il piu possibile multica-

nale, si possono facilmente sviluppare nuovi client con front-end dedicati ad

aspetti non coperti. Per esempio sarebbe interessante sviluppare client dedi-

cati all’utilizzo su tablet o device touch di grandi dimensioni, eventualmente

con la possibilita di far collaborare piu utenti tra loro. Infine, si potrebbe cer-

care di portare gli attuali front-end su nuove piattaforme software (Android,

Mac OS, ...) o nuovi tipi di device.

Bibliografia

[1] Fred A. Jacobs Adam S. Maiga. Jit performance effects : A research

note. Advances in Accounting, incorporating Advances in International

Accounting, pages 183–189, 2009.

[2] Giuseppe Menga Amund Aarsten, Davide Brugali. Patterns for three-

tier client/server applications.

[3] Chris Anderson and Michael Wolff. The web is dead. long live the

internet. Wired, 9 2010.

[4] Apress, editor. PRO Linq - Language Inteegrated Query in C. Adam

Freeman and Joseph C. Rattz, Jr., 2010.

[5] Yusuf Bhaiji. Network Security Technologies and Solutions (CCIE

Professional Development Series). Cisco Press.

[6] Lowell Bryan. Just-in-time strategy for a turbulent world. McKinsey

Quarterly, pages 17–27, 6 2004.

[7] Microsoft Corp. Ui design and interaction guide for windows phone 7

v.2.0, 7 2010.

[8] Silvia Fragola e Alfonso Fuggetta Fabiano Cattaneo. L’impresa Just in

Time. CEFRIEL, Maggio 2010.

113

114 BIBLIOGRAFIA

[9] Jane Fraser, Lowell L. Bryan, Wilhelm Rall, and Bryan Lowell L. Ra-

ce for the World: Strategies to Build a Great Global Firm. Harvard

Business Press, 9 1999.

[10] Erich Gamma, Richard Helm, Ralph Johnson, and John M. Vlissi-

des. Design Patterns: Elements of Reusable Object-Oriented Software.

Addison-Wesley Professional, 1 edition, 11 1994.

[11] Gartner Research. Analysts Examine Latest Industry Trends During

Gartner Symposium/ITxpo, Orlando, FL, USA, 10 2010.

[12] Gartner Research. Future Wireless Trends to Be Discussed at Gartner

Wireless, Networking & Communications Summit, San Diego, CA, USA,

4 2010.

[13] Harumi Kuno Vijay Machiraju Gustavo Alonso, Fabio Casati. Web ser-

vices: concepts, architectures and application. Springer - Verlag Berlin

Heidelberg, 2004.

[14] Jason Taylor Prashant Bansode Steve Gregersen Madhu Sundararajan

Rob Boucher J.D. Meier, Carlos Farre. Improving Web Services Ser-

curity - Scenarios and Implementation Guidance or WCF. Microsoft

Corporation, 2008.

[15] Boodhoo Jean-Paul. Model-view-presenter. MSDN Magazine, 8 2006.

[16] William F. Joyce. Matrix organization: A social experiment. The

Academy of Management Journal, 29(3), 1986.

[17] Jenny Filler Karen Huhn Judith E Deutsch, Megan Borbely and Phyllis

Guarrera-Bowlby. Use of a low-cost, commercially available gaming con-

BIBLIOGRAFIA 115

sole (wii) for rehabilitation of an adolescent with cerebral palsy. Physical

Therapy, 88, 2008.

[18] R. Anthony Inman Kenneth W. Green Jr. Does implementation of a jit-

with-customers strategy change an organization’s structure? Industrial

Management & Data Systems, 106:1077–1094, 2006.

[19] J.C. Lee. Hacking the nintendo wii remote. Pervasive Computing, IEEE,

7(3):39 –45, 2008.

[20] Philip I.S. Lei and Angus K.Y. Wong. The multiple-touch user interface

revolution. IT Professional, 11:42–49, 2009.

[21] Jim Lee Paul H. Meredith, John H.Ristroph. Implementing jit: the

dimension of culture, management and human resource. 1991.

[22] D.S. Pugh. Organization Theory: Selected Readings. Penguin Books

Ltd., reprint edition, 1990.

[23] Jef Raskin. The humane interface: new directions for designing interac-

tive systems. ACM Press/Addison-Wesley Publishing Co., New York,

NY, USA, 2000.

[24] Thomas Schlomer, Benjamin Poppinga, Niels Henze, and Susanne Boll.

Gesture recognition with a wii controller. In Proceedings of the 2nd

international conference on Tangible and embedded interaction, TEI ’08,

pages 11–14, New York, NY, USA, 2008. ACM.

[25] Torben Schou and Henry J. Gardner. A wii remote, a game engine,

five sensor bars and a virtual reality theatre. In Proceedings of the 19th

Australasian conference on Computer-Human Interaction: Entertaining

116 BIBLIOGRAFIA

User Interfaces, OZCHI ’07, pages 231–234, New York, NY, USA, 2007.

ACM.

[26] Josh Smith. Model-view-viewmodel (mvvm) pattern. MSDN Magazine,

2 2009.

[27] Jan van den Ende. Computers and industrial organization: Early sources

of ’just in time’ production in the dutch steel industry. IEEE Annals of

the History of Computing, 17:22–32, 1995.

[28] Ralph Whittle. Understanding the enterprise business architecture.

BPMInstitute, 9 2005.

[29] Ralph Whittle and Conrad B. Myrick. Enterprise Business Architecture:

The Formal Link between Strategy and Results. CRC Press, 1 edition, 8

2004.

[30] James P. Womack. The Machine That Changed the World : Based on

the Massachusetts Institute of Technology 5-Million-Dollar 5-Year Study

on the Future of the Automobile. Scribner, 10 1990.

Appendice A

Tabella comparativa tra

piattaforme mobile

Mobile OS

Kernel OS X Mobile Linux Kernerl Windows CE 6

Copertura di

reteGSM GSM + CDMS GSM + CDMA

Display 3.5 inch variabile variabile

Touch Screen Capacitivo Capacitivo Capacitivo

Multitouch Sı Sı Sı

MultitaskingSı + Push Noti-

fication ServiceSı

Inserito entro

2011 + Push

Notification

Service

118 Appendice A. Tabella comparativa tra piattaforme mobile

Copia/ Incol-

laSı Sı Sı

Tastiera Solo virtuale variabile variabile

App Store App Store Android MarketWindows

Marketplace

Music Store iTunes 3rd Party Store Zune Store

Piattaforma

AdvertsingSı Sı Sı

Game App Store 3rd Party Store Xbox Live

Social

NetworkSı con App Sı con App Sı

Office Pro-

duttivity

Suite

Sı con App Google DocsOffice 2010 mo-

bilel

Browser Mobile Safari Chrome

IE8(Update a

IE9 entro il

2011)

Flash No SıInserito entro il

2011

Silverlight No No Sı

Java No Sı No

Default

Search

Spotlight per la

ricerca interna,

Google per il

web

Googlr Bing

Email Mail App Gmail App Outlook Mobile

119

Home Screen No SıSı, tile persona-

lizzabili

OS Update Sı Sı Sı

Firmware Up-

dateSı Sı Sı

Interfaccia

Personalizza-

bile

No Sı No

Cloud-Sync

ServiceMobile Me Google App My Phone 2.0

Applicazioni

Disponibili300.000+ 70.000+ 20.000+

120 Appendice A. Tabella comparativa tra piattaforme mobile

Appendice B

Database Gedi Alert

Struttura nel dettaglio del database GEDI ALERT. Le due tabelle che lo

compongono sono Alert e Tipo.

Tabella Alert

E’ la tabella che contiene tutti gli avvisi; sia quelli generati dal sistema che

quelli inviati tra utenti. La tabella qui di seguito mostra nel dettaglio l’elenco

dei campi, le loro tipologie e a cosa si riferiscono.

Tabella Tipo

Questa tabella racchiude tutte le le informazioni riguardo le tipologie di avvisi

che possono essere generati.

122 Appendice B. Database Gedi Alert

Nome campo Tipo Descrizione

ID Intero Identificativo univoco dell’avviso

Nome Varchar Nome dell’avviso. Deve descrivere in forma

sintetica ma precisa cosa rappresenta l’avviso

Descrizione Varchar Descrizione dell’avviso. E’ un’ampliamento

del nome, viene utilizzato per elencare tutti

i dettagli necessari a comprendere meglio la

natura di tale notizia.

Id Risorsa Intero Riferimento alla risorsa destinataria dell’avvi-

so. Questo campo puo assumere il valore nullo

nel caso l’evento sia generato dal sistema e sia

riferito ad un progetto anziche ad una risorsa.1

Id Progetto Intero Riferimento al progetto sul quale e stato

generato l’avviso.1

Data Creazione Date

Time

Data di creazione dell’avviso.

Id Tipo Intero Riferimento alla tabella tipo. Permette di

specificare la tipologia di Alert.

Creato Da Intero Identificativo della risorsa che ha creato l’a-

lert. Siccome anche il sistema puo genera-

re alert, questo campo puo assumere valori

negativi.

Already Read Boolean Specifica se l’avviso e stato letto dal momento

della creazione.

Tabella B.2: Campi della tabella Alert

123

Nome campo Tipo Descrizione

ID Intero Identificativo univoco del tipo di avviso

Primo Livello Intero Nome dell’avviso. Deve descrivere in forma

sintetica ma precisa cosa rappresenta l’avviso

Descrizione Varchar Descrizione dell’avviso. E’ un’ampliamento

del nome, viene utilizzato per elencare tutti

i dettagli necessari a comprendere meglio la

natura di tale notizia.

Tabella B.4: Campi della tabella Tipo

124 Appendice B. Database Gedi Alert

Appendice C

Stati di Progetto

Qui viene descritto qual’e la distinzione tra i colori dei semafori per project

manager e account manager. Semaforo rosso

• SAL non presente o non aggiornato nell’ultimo mese

• Superamento oltre il 10% dei costi o superamento di oltre e25.000 di

costi, per progetti con costo superiore a e50.000

• Superamento di oltre e5.000 dei costi, per progetti con costo inferiore

a e50.000

• Progetto gia terminato, ma con il contratto non ancora approvato dal

Cliente (il progetto e quindi ancora in uno stato precedente rispetto ad

acquisito)

• Ultimo SAL anteriore alla data di chiusura del progetto (data fine)

Semaforo giallo

• Superamento fino al 10% dei costi, fino ad un massimo di e25.000, per

progetti con costo superiore a e50.000

126 Appendice C. Stati di Progetto

• Superamento fino a e5.000 dei costi, per progetti con costo inferiore a

e50.000

Semaforo verde

• SAL aggiornato

• Progetto in linea

Nessun semaforo se lo stato del progetto non e in chiusura, acquisito o

terminato.

In caso di semaforo rosso, il PM propone e concorda con HoD, AM e DG

le azioni da effettuare, ad esempio:

• rimodulazione delle attivita future

• revisione contrattuale

• revenue aggiuntive

• follow-up del progetto in cui spostare parte dei costi in eccesso

• riuso di semilavorati e deliverable del progetto in altri progetti (ridu-

cendo di conseguenza i costi di altri progetti)

In caso di semaforo giallo, le azioni precedenti sono proposte e discusse

con HoD e AM.

la gestione delle informazioni nella just-in-time … · corso di laurea specialistica in...

Documents