LA GESTIONE DELLE INFORMAZIONI NELLA JUST-IN

POLITECNICO DI MILANO
Facoltà 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 è importante avere una visione completa e aggiornata delle prestazioni e dell’andamento del proprio business.
La Just-In-Time Organization è 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, pianificare al meglio le strategie future e risolvere prontamente i problemi che si
presentano. L’ IT può 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 soluzione 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 nostro lavoro abbiamo ripensato queste tecnologie per adattarle alle esigenze
aziendali e fornire dispositivi al supporto delle attività di business che siano
funzionali e allo stesso tempo innovativi. Il lavoro è stato svolto all’interno di
CEFRIEL società che svolge attività di formazione e di consulenza ad alto livello tecnologico e che da anni si è indirizzata verso un modello organizzativo
”Just-In-Time” e quindi già dotata di un buon livello di informatizzazione.
I
Partendo dall’analisi dell’attuale modello di gestione delle attività aziendali e
dalle esigenze espresse dai manager, abbiamo sviluppato un sistema integrato
con gli altri già disponibili, ma che permette di raccogliere e distribuire informazioni su vari canali in tempo reale, migliorando la capacità di monitorare
lo stato di salute dell’azienda.
Ringraziamenti
Ogni minuto che passi arrabbiato perdi sessanta secondi di felicità
Albert Einstein
Desidero innanzitutto ringraziare il Professor Alfonso Fuggetta per averci
dato la possibilità di svolgere questa tesi all’interno di Cefriel.
Inoltre, ringrazio sentitamente l’Ing. Giordano Sassaroli per la disponibilità
e professionalità 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 è 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 insostituibili. Papà grazie per la tua tranquillità, disponibilità, bontà d’animo e
umiltà. 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 rinunciando 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 è entrata attivamente nella mia vita da quasi un anno ormai ma è come se ci fosse da sempre, donandomi tanta felicità 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 perché il vostro affetto mi
rimarrà per sempre nel cuore. Grazie per le ”mancette” segrete, grazie per
la vostra semplicità, comprensione e bontà.
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 umanità e disponibilità non la dimenticherò
mai. Se nei prossimi impieghi avrò dei ”padroni” antipatici mi farò 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 voglia 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
semplicità, spero che avrai tutto il successo che una persona come te merita.
Grazie Oscar, insieme abbiamo girato il ”Mondo” passando momenti indimenticabili, 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 Fabio(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 incontravano lungo la strada e mi chiedevano: ”Come và l’università ?”. Adesso
finalmente posso rispondere:”E’ finita”. E un po’ è anche merito vostro.
Giulio
Ringraziamenti
Il miglior modo per iniziare a cambiare il mondo,
è 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 semibuia e più grigia del cielo che si intravedeva dalla tapparella rotta. Certo che
come partenza non è stata delle migliori e chi avrebbe pensato che quello fosse 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 università 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 grazie, senza di voi sarebbero stati molto noiosi questi anni di università. 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’è stata solo l’università 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 caffè notturni.
Il bello dell’amicizia è che è una rete che tende ad allargarsi sempre di più
per accogliere nuove persone e molte altre meritano di essere ringraziate. Innanzitutto 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 è diventata sempre più 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 lavorando 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 è cambiata, grazie.
Arrivando a giorni più 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 Iantorno che mi ha dato l’opportunità di lavorare in Microsoft dove ho imparato
moltissimo e ho capito un po’ di più come va il modo fuori dall’università.
Infine, il ringraziamento più speciale di tutti va alla mia famiglia: alla mia
Mamma, al mio Babbo e alla mia Taty. Mi avete sempre sorretto e spinto 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 fisicamente con le loro leccornie culinarie.
Questa avventura è finita, non so cosa ci sarà domani come non lo sa nessun’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
2.1
2.2
7
La filosofia Just-In-Time . . . . . . . . . . . . . . . . . . . . .
7
2.1.1
JIT Organizations: un’azienda moderna . . . . . . . .
9
2.1.2
Informazioni nella JIT Organizations . . . . . . . . . . 12
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
3.1
27
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.3
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
Aspetti di sicurezza . . . . . . . . . . . . . . . . . . . . . . . . 49
5 Caso di Studio: CEFRIEL
5.1
5.2
5.3
53
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
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
Architettura di back-end . . . . . . . . . . . . . . . . . . . . . 63
5.3.1
Layer di accesso ai dati . . . . . . . . . . . . . . . . . . 64
5.4
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
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
5.8
Class Diagram Package CGP . . . . . . . . . . . . . . . . . . . 67
5.9
Esempio Sequence Diagram per chiamata a DAL . . . . . . . . 68
. . . . . . . . . . . . . . . . . . . . . . . 66
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
6.5
Modello di riferimento - Caratteristiche coperte dal front-end
mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.6
Modello di riferimento - Caratteristiche coperte dal front-end
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 più 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 affrontarle 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 attività interne. Con l’accelerare delle dinamiche
di mercato su scala globale, ma anche delle dinamiche interne dell’azienda,
risulta sempre più difficile essere in grado di tenere sotto controllo, in tempi
brevi, tutte le variabili in gioco.
La Just-In-Time Organization è una filosofia organizzativa che vuole massimizzare l’efficienza e l’efficacia dell’azienda nel gestire e analizzare le informazioni rilevanti per il proprio business. Per fare ciò, la JIT organizzation
si concentra su tre aspetti: l’organizzazione dell’azienda, i processi e la tecnologia. In particolare, la tecnologia può 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 rivoluzionando la tradizionale interazione tra uomo e macchina e nuovi interessanti
scenari si presenteranno nei prossimi anni. L’obiettivo della nostra ricerca è
quello di valutare in contesti diversi quale può essere un modo efficace di presentare all’utente le informazioni rilevanti di cui ha bisogno, per determinare
eventuali minacce o criticità aziendali.
1.2
Obiettivi della tesi
Obiettivo di questo lavoro è riuscire a proporre una soluzione che permetta
di analizzare le performance dell’azienda con una bassa latenza e di prendere decisioni in modo tempestivo, il tutto introducendo costi o infrastrutture
contenute e coerenti con le dimensioni dell’impresa, ma garantendo la scalabilità della soluzione nel futuro. I dati generati dal sistema devono essere il
più 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 è sfruttare in base al contesto le più recenti e innovative tecnologie. Infatti, nel corso del
lavoro abbiamo dedicato particolare attenzione a capire quali fossero le esigenze delle persone che avrebbero utilizzato il nostro sistema in tre diversi
contesti: quando l’utente è seduto in ufficio davanti al proprio PC, quando è
in mobilità e quando è in riunione con i propri colleghi o con i partner aziendali. Per ognuno di questi contesti abbiamo scelto tra le più interessanti
tecnologie disponibili, quella più adatta a soddisfare le esigenze dell’utente. Nel complesso, l’obiettivo del lavoro è quello di favorire l’inserimento,
l’aggiornamento e la visualizzazione delle informazioni tramite un sistema
multipiattaforma e multicanale.
Lo studio preliminare è iniziato con l’analisi dell’organizzazione interna
di due aziende particolarmente attente al tema di questa tesi, Microsoft Corporation(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 società hanno fatto emergere le esigenze e i problemi 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 validare il nostro lavoro. L’azienda che ha accettato di essere il nostro caso di
studio e sperimentare il nostro prototipo è il CEFRIEL, società di eccellenza
per l’innovazione, la ricerca e la formazione nel settore dell’Information &
Communication Technology, che svolge un’attività lavorativa basata su pro-
4
Capitolo 1. Introduzione
getti e che necessita di avere dati il più possibile aggiornati sullo stato di
avanzamento dei lavori, per rispettare i vincoli di tempo e di costo.
Il prototipo realizzato conferma la buona flessibilità 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 modularizzazione del prototipo, per questo motivo le future implementazioni potranno
riusare facilmente le caratteristiche già introdotte da noi.
1.3
Struttura della tesi
Questo lavoro di laurea è 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 più 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 precedente è stata calata nel contesto d’uso reale del CEFRIEL. Si descrivono 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.
6
Capitolo 1. Introduzione
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 sarà analizzato lo stato dell’arte dei due ambiti di ricerca
principali di questa tesi: la gestione efficiente di una azienda e le nuove tecnologie di interazione tra uomo e macchina. Si cercherà 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 lasciò 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 metà degli anni ’70 il JIT divenne elemento fondamentale e di successo
del Toyota Production System, tant’è 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, portò ad aumentare la produttività e la resa.Come risultato, Toyota
è 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 è un insieme di principi e pratiche orientati
al raggiungimento di un elevatissimo livello di efficienza[1] e qualità, basati
sull’idea che le imprese dovrebbero ridurre al massimo le scorte, immagazzinando solo il necessario per la produzione o la distribuzione immediata:
qualsiasi scorta di materiale, semilavorato o prodotto finito è uno spreco,
uno spreco di risorse economiche, finanziarie e un vincolo all’innovazione
continua. Più il processo è corto nella somma dei processi di progettazione
e di produzione e più l’industria con i suoi prodotti e servizi è vincente.
In pratica, si tratta di coordinare i tempi di effettiva necessità dei materiali sulla linea produttiva con la loro acquisizione e disponibilità nel segmento
del ciclo produttivo e nel momento in cui debbono essere utilizzati, ma ciò
significa che un produttore dovrebbe ricevere materie prime o parti dai suoi
fornitori poche ore prima che siano utilizzate e che il prodotto finito dovrebbe essere spedito ai clienti appena dopo la realizzazione, senza dover tenere
stock delle materie prime o prodotti finiti. Quindi, sono necessarie un certo 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 macchinari, controlli di qualità efficienti ed efficaci, e forse più 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 affidabilità, riduzione delle scorte e del lead time, ad un aumento della
qualità 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 ciò rende impossibile prevedere
con certezza in quali mercati una società sarà collocata o come essa sarà
strutturata, anche solo fra qualche anno. Il risultato è un ambiente economico
che è ricco di opportunità, ma anche segnato da un aumento sostanziale del
rischio.
In questo mercato sempre più complesso e dinamico, per un’impresa è
importante monitorare in tempi rapidi l’andamento delle proprie prestazioni perché offre la possibilità di rimanere al passo con i tempi e reagire in
modo rapido ai cambiamenti. Ciò richiede che le imprese si dotino di modelli 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 più rapidi rispetto al passato. In particolare, la variabile tempo gioca un ruolo di primaria importanza: le imprese
10
Capitolo 2. Stato dell’arte
devono essere in grado di rispondere con estrema rapidità agli stimoli esterni,
prevedendo e anticipando potenziali criticità e minacce, e valorizzando tempestivamente tutte le opportunità che si presentano loro[8]. In quest’ottica,
diventano fondamentali due aspetti della raccolta e analisi delle informazioni: la conoscenza approfondita delle dinamiche del mercato e il monitoraggio
proattivo e continuo delle performance dell’impresa stessa. Nel primo, l’analisi è incentrata su fattori esterni all’impresa, mentre nel secondo è 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] può aiutare a capire l’importanza della conoscenza in periodi di grande incertezza come quello che stiamo vivendo. Prendiamo
due corridori, uno è più veloce rispetto all’altro e ci si può aspettare che vinca
sempre su una pista piana, non importa quante volte la gara è 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 più lento abbia
percorso la pista sia di giorno che di notte, mentre il più veloce non si è
preoccupato di vedere il percorso in anticipo. Il corridore con la conoscenza
superiore sarebbe probabilmente il vincitore anche se l’altro fosse molto più
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 può 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 è quello di realizzare un’organiz-
2.1. La filosofia Just-In-Time
11
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 può essere:
The right material, at the right time, at the right place, and
in the exact amount
in questo nuovo contesto può 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 è la chiave per la creazione dell’infrastruttura abilitante alla JIT Organization, ma deve tenere conto delle principali
criticità del campo in considerazione e cercare di fornire uno strumento che
risponda a quattro requisiti di qualità delle informazioni fondamentali: Timeliness, Accuracy, Focus e Efficiency. Infatti, per prendere decisioni efficaci,
è indispensabile basarsi su informazioni allineate con l’attuale stato dell’organizzazione e quindi ottenute tramite strumenti che riducano al minimo
i tempi di latenza. Non solo il fattore tempo è importante, ottenere dati
accurati e completi è importante per ”non sbagliare rotta”, quindi l’architettura IT deve cercare di prevenire l’introduzione di dati errati e evidenziare
possibili errori. Inoltre, vista la grande quantità di informazioni che possono
essere raccolte è indispensabile avere un meccanismo di aggregazione dei dati
e identificare degli indicatori di sintesi significativi. Infine, la raccolta e l’analisi dei dati non deve introdurre un effort eccessivo rispetto alle dimensioni
12
Capitolo 2. Stato dell’arte
e alle esigenze dell’impresa, al fine di non ostacolare le funzioni primarie di
business.
Visti questi requisiti, è 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 è costituito dalle sorgenti dati
che memorizzino e gestiscono i dati, che devono essere affidabili e garantire l’accessibilità ai dati in qualsiasi istante. Visto che le sorgenti dati sono
spesso incoerenti tra loro, è indispensabile un secondo livello logico, solitamente 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, è
indispensabile non trascurare il livello di Presentation perché è ciò che fa la
differenza tra un discreto sistema e un ottimo sistema, inoltre, come sarà
evidenziato meglio in 2.2, negli ultimi anni è 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 sarà
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 è 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. Perché
2.1. La filosofia Just-In-Time
13
non rendere disponibile ai partner dell’azienda anche informazioni sullo stato
di avanzamento dei progetti condivisi?
Tutte le più moderne aziende hanno sistemi, più o meno efficaci, di reportistica 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 è spesso condivisa manualmente con i vari
partner aziendali, e questo oltre sottrarre tempo per attività più rilevanti per
l’azienda non consente di avere mai a disposizione il dato più 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, perché questo permette di avere non solo una visione accurata, completa 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, è quello
legato alla condivisione delle informazioni a tutti i livelli aziendali. Infatti, se
i top-manager riescono solitamente ad avere una buona visibilità dello stato
dell’azienda, scendendo nella piramide aziendale si perde la possibilità 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.
14
Capitolo 2. Stato dell’arte
2.2
Le tecnologie di presentazione e interazione
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 quantità di informazioni, ma poche riescono a utilizzarle
al meglio perché 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 concezione si è ripercossa sull’impostazione data alle interfacce grafiche sviluppate
usando la metafora, tuttora è 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’attenzione 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 maturità 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
più ampio device molto sofisticati.
In questa sezione passeremo velocemente in rassegna le tecnologie più
interessanti che potrebbero, in contesti diversi, venire in contro anche ai
bisogni dell’azienda.
2.2. Le tecnologie di presentazione e interazione
2.2.1
15
Tecnologie desktop
La diffusione di notebook ad alte prestazioni a prezzi sempre più accessibili e
la nascita di nuovi dispositivi mobili, ha cambiato la tradizionale definizione
di computer desktop che si basava essenzialmente sulla forma e le dimensioni del computer. Sempre più 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 continueranno a svilupparsi nei prossimi anni, soluzioni multiutente pensate per far
lavorare più 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 è 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 è
interessante per l’utente tenere costantemente sotto controllo. I widget risultano anche molto utili per eseguire velocemente operazioni brevi, per esempio
controllare se è arrivata una nuova email, che normalmente richiederebbero
l’apertura del browser o altri programmi.
I widget possono essere realizzati come una piccola pagina e utilizzare qualsiasi tecnologia supportata dai browser come, ad esempio, Flash,
16
Capitolo 2. Stato dell’arte
Fig. 2.1: Esempi di alcuni Widget installati su un PC
JavaScript o Silverlight.
Pinned Site
Il Pinning è una nuova funzionalità di Internet Explorer 9 per Windows 7 che
consente agli sviluppatori web di creare funzionalità aggiuntive che possono
essere utilizzate dalla barra delle applicazioni di Windows 7. Tra le varie
funzionalità le più rilevanti e utili sono tre: è possibile fornire notifiche, ad
esempio nuovi l’arrivo di nuovi messaggi o la pubblicazione di nuovi articoli;
è 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,
è quello,grazie ai Pinned Site, di poter accedere direttamente ai loro siti
preferiti e, da loro punto di vista, i siti che implementano queste funzionalità
possono, secondo alcune stime, incrementare le loro visite fino al 50%.
2.2. Le tecnologie di presentazione e interazione
17
Fig. 2.2: Esempi di Pinned Site
Microsoft Surface
Microsoft Surface è 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 più 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 è 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.
18
Capitolo 2. Stato dell’arte
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 mobilità e web. I dispositivi mobili stanno avvicinando
sempre più a veri e propri computer, con una quantità incredibile di capacità
di elaborazione e una notevole disponibilità di banda. La qualità dell’esperienza 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 lanciò ufficialmente il primo iPhone,
anche il mondo mobile è sempre più contraddistinto dalle tecnologie touchscreen. Come è stato evidenziato in [12] questo trend diventerà dominate nel
2011 con oltre il 60% dei dispositivi mobili venduti in Europa Occidentale e
in Nord America che implementerà un’interfaccia touch-screen. Le aziende
produttrici andranno presto anche oltre e spingendosi fino a sviluppare inter-
2.2. Le tecnologie di presentazione e interazione
19
facce multitouch, per garantire la miglior esperienza d’uso possibile all’utente
e il massimo in fatto di competitività. L’utilizzo di applicazioni dedicate per
i dispositivi mobili permette di sfruttare al meglio le caratteristiche (touchscreen, 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 è la piattaforma sviluppata da Apple dedicata al mondo mobile, in particolare 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 è stata la prima piattaforma che ha mostrato quello che una applicazione mobile ben realizzata
potrebbe fare per migliorare l’esperienza dell’utente. Come tale, l’interfaccia utente(Fig.2.4) di iOS è totalmente incentrata sulle App, la schermata
iniziale è un elenco a scorrimento di applicazioni e il messaggio che vuole
trasmettere è chiaro:C’è un App per tutto o quasi.
Il risultato è che la maggior parte degli utenti finali si ritrova con pagine
e pagine di applicazioni, ma è 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:
20
Capitolo 2. Stato dell’arte
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 è la prima release del nuovo sistema operativo Microsoft
per il mondo mobile, è al contrario della scelta di Apple, Microsoft ha deciso
di rendere disponibile il proprio OS a vari produttori di device e di concentrarsi solo sulla parte software, imponendo però dei requisiti hardware minimi
molto elevati.
Windows Phone 7 è stato da poco lanciato e, anche se in questo momento
ha il più piccolo ecosistema di applicazione, ha l’unica UI che sta creando
2.2. Le tecnologie di presentazione e interazione
21
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 è incentrato sui
bisogni della persona e non sulle applicazioni.
Fig. 2.5: Windows Phone 7
È possibile scaricare tutte le applicazioni che si desidera, ma la schermata
iniziale di Windows Phone 7 permette di focalizzarsi solo su alcune informazioni 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 contenitore. Ad esempio, l’hub immagini racchiude in un’unica live tile i contenuti
provenienti da più applicazioni di photo sharing.
L’idea di Microsoft è quella di enfatizzare le azioni e non le applicazioni
specifiche. Windows Phone 7 non rende decine di applicazioni immediatamente accessibili, optando invece per dare agli utenti gli strumenti per per-
22
Capitolo 2. Stato dell’arte
sonalizzare la propria esperienza sulla schermata Home con le informazione
che vogliono tenere sempre sott’occhio. Naturalmente, quando l’utente vuole
può accedere alla lista completa delle applicazioni con un semplice tocco e
scorrere l’elenco, ma questo elenco non può essere ordinato ed è una semplice lista, in questo modo l’utente si sente cosı̀ limitato da importare nella
schermata iniziale le cose importanti. La Home ha una quantità limitata di
spazi, perché più si aggiungono tile, più l’user-esperience diventa degradante
in quanto si deve scorrere sempre di più per vedere le applicazioni.
Windows Phone 7 si caratteristica anche per un interessante integrazione con i servizi e i giochi Xbox Live e per il futuro è prevista anche un
integrazione con i giochi che sfruttano Kinect.
Android
Android è la piattaforma open source dedicata al mondo tablet e dispositivi 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 dalle forme più diverse e l’utilizzo in vari contesti anche non legati al mondo
mobile(dispositivi per la cucina,...).
Android è una sorta di ibrido dei due sistemi descritti in precedenza,
e probabilmente sarà rivista completamente con la prossima major release.
Android ha una Home(Fig.2.6) come Windows Phone 7 in cui è possibile
inserire shortcut alle applicazioni e anche widget interattivi per tenere sott’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
2.2. Le tecnologie di presentazione e interazione
23
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 riadattate anche a contesti aziendali, per questo motivo, è interessante analizzare brevemente quelle più innovative che hanno rivoluzionato il modo di
interagire tra uomo e macchina e hanno ridefinito l’idea stessa di videogioco.
Nintendo Wii
Nintendo Wii è la console per videogiochi prodotta da Nintendo con peculiarità molto interessanti che gli hanno permesso di essere la prima a rivoluzionare il modo di giocare con un videogames casalingo introducendo il
movimento fisico dell’utente.
24
Capitolo 2. Stato dell’arte
Fig. 2.7: Wii mote e Wii sensor bar
La sua caratteristica più distintiva è il controller senza fili, il Wiimote(Fig.2.7) crasi di Wii e Remote, che reagisce alle forze vettrici e all’orientamento rispetto allo spazio tridimensionali, attraverso il sistema di accelerometri e giroscopi presente al suo interno, e invia le informazioni alla console
tramite Bluethooth. Il controller è il maggiore distacco dagli ultimi venti anni di design di console, noto anche come free hand controller, utilizza
un approccio differente da quello tradizionale nel tentativo di risultare interessante per un pubblico più vasto. Il Wiimote ha la forma di un comune
telecomando da televisione e viene tenuto in una sola mano e, essendo simmetrico, è ugualmente utilizzabile da destri e mancini. Il controller tramite un
dispositivo ottico posto ad una delle sue estremità interagisce con la Sensor
Bar (Fig.2.7) rendendo possibile il suo utilizzo come sistema di puntamento
sullo schermo della TV.
2.2. Le tecnologie di presentazione e interazione
25
Il risultato ottenuto dalla Nintendo è senza dubbio stato rivoluzionario:
l’utente semplicemente tenendo il mano il controller e muovendolo può interagire con i giochi, il tutto con estrema naturalezza e semplicità. Questo
tipo di interazione è stato per alcuni anni esclusiva prerogativa di questa
console, ma recentemente è stato introdotto anche nella Sony PlayStation 3
e, in maniera più evoluta e ancora più rivoluzionaria, nella Microsoft Xbox
360.
Il grande successo ottenuto dalla console e il suo concept innovativo, ha
spinto anche molte comunità 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 device 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)è dotato
di telecamera RGB, doppio sensore di profondità 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 più 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 già giocato.
26
Capitolo 2. Stato dell’arte
Fig. 2.8: Kinect
A dicembre 2010 la società Prime Sense, compagnia israeliana da tempo 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 Microsoft, 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 profondità di Kinect e sono basati
sulle API di OpenNI (Open Natural Interactions). OpenNI permette di catturare 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 già accaduto per la Wii, la tecnologia di Kinect è stata utilizzata per
molti progetti di ricerca non legati al gaming o all’entertainment. Recentemente, Microsoft ha anche dichiarato che entro il 2011 la periferica Kinect
sarà 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, è necessario
partire da un modello organizzativo di riferimento. In questo capitolo, sarà
definito il modello che è stato estratto studiando l’organizzazione interna
di Microsoft, del Cefriel e, indirettamente, dei loro clienti. Partendo dal
modello di riferimento, saranno poi evidenziate le criticità 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, fatturato, e la dispersione geografica delle sue strutture. Nel corso del tempo, sono
stati proposti sia modelli di Flat Organization sia di Hierarchical organization, ma negli ultimi anni le aziende di maggiore successo si sono orientate
verso modelli ibridi che garantiscono sia maggiore efficienza e efficacia sia
maggiore flessibilità.
In particolare, nelle organizzazioni in cui si lavora per lo più in modo
parallelo e concorrente su progetti complessi e ampi, si è 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 unità 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 è molto ampia, per aerea geografica. In questo modo, ogni divisione è specializzata
ad assolvere particolari funzioni aziendali ed è guidata da un Head of Division(capodivisione). Lo head of division è responsabile della gestione quotidiana 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 riferimento richiede risorse con competenze specifiche dai diversi dipartimenti. Il
compito del project manager sarà, in questo caso, di tipo prettamente progettuale, 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’unità organizzativa appositamente formata si scioglie e i suoi membri sono
destinati a nuovi incarichi.
In questo sistema, ogni membro di una divisione può essere assegnato
ad un singolo progetto o a più progetti, tutti da portare avanti in modo
parallelo. Ogni risorsa quindi, riporterà il proprio stato di avanzamento lavori
direttamente al project manager e non al head of division. Ciò significa che
ogni membro di un team risponderà a due (o anche più) manager e sarà,
in effetti, egli stesso membro di due (o più) team. L’appartenenza a più
30
Capitolo 3. Proposte per l’impresa Just in Time
squadre, pertanto, potrebbe comportare anche un ruolo differente di volta in
volta ed una responsabilità 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 è una figura focalizzata sulla realizzazione dei
progetti, l’account manager è una persona che è responsabile della gestione delle vendite e della relazione con particolari clienti, solitamente i più
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 meglio a tali esigenze, in modo che il cliente non decida di cambiare partner.
A seconda delle dimensioni della società, l’account manager può gestire un
unico cliente o può avere un portfolio di clienti.
Il resource manager è una figura simile al head of division, ma con una
visibilità 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 è sempre presente in azienda e può essere sostituita dando maggiori
responsabilità ai head of division.
Uno dei vantaggi di una struttura a matrice è l’utilizzo efficiente delle
risorse, specialmente di quelle con competenze più pregiate, che non possono
esser utilizzate a pieno soltanto da un progetto, ma possono essere occupate
pienamente lavorando su più progetti. Piuttosto che duplicare funzioni, come dovrebbe essere fatto in una struttura semplice, le risorse sono condivise
con elevata flessibilità, derivante dalla possibilità di gestire le risorse umane
a seconda delle necessità 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 essere 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 altre divisioni favorisce la cross-fertilizzazione di idee. Infine, l’organizzazione
a matrice è anche la più flessibile quando ci sono cambiamenti di esigenze di
business o di priorità e alcune ricerche mostrano come questo tipo di organizzazione 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 è che le relazioni di riporto
sono complesse e alcune persone potrebbero riportare contemporaneamente
a un capodivisione e uno o più project manager. Inoltre, la duplice linea di
comando determina condizioni di potenziale conflittualità tra responsabili di
funzione e responsabili di progetto che rende indispensabile una forte comunicazione e cooperazione tra capi divisione e project manager per organizzare
al meglio il tempo delle risorse.
La qualità delle informazioni e la velocità con cui vengono scambiate diventano fondamentali per il funzionamento dell’organizzazione. Per riuscire
a creare un impresa JIT che rispetti i requisiti descritti nel capitolo precedente 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:
32
Capitolo 3. Proposte per l’impresa Just in Time
un dominio comune a cui tutte le iniziative strategiche sono collegate[28][29].
In particolare, l’EBA deve consentire l’allineamento strategico e l’integrazione dei processi aziendali con l’architettura enterprise al fine di migliorare le
capacità 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, può
evidenziare la necessità di rivedere o definire nuovi processi che tengano conto anche della produzione di dati necessari al monitoraggio
dell’andamento dell’azienda e della loro qualità. I nuovi processi devono considerare le caratteristiche peculiari di ogni divisione, facilitando la raccolta dei dati con meccanismi semplici che non incidano
negativamente sull’efficienza del processo.
Information Management: L’elevata quantità di dati e informazioni raccolti a livello di processo devono essere organizzati e gestiti definendo
mappe concettuali e modelli che definiscano le relazioni tra gli elementi
facilitandone l’usabilità e la condivisione.
People & Organization: L’aspetto che più di altri incide ed è indispensabile per realizzare un’impresa JIT è l’organizzazione e la motivazione
delle persone. Se sull’organizzazione è già stata dedicata la sezione precedente, è bene soffermarsi anche sull’importanza delle persone. Come
ci è stato confermato dalle interviste fatte, la presenza di tool e architetture 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’importanza 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 concreti, come la scarsità o la poca qualità 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 experience sono elementi che disincentivano gli utenti dall’utilizzo e diventano scuse per la scarsa attenzione alla qualità delle informazioni,
causando gravi inefficienze e problemi nel monitoraggio aziendale.
Il nostro lavoro, si concentra in particolare su questo elemento della Enterprice 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 è stata posta nel coniugare usabilità e accessibilità delle informazioni con strumenti multicanale che sfruttino al meglio le potenzialità dei device di nuova
generazione.
3.3
Informazioni rilevanti
Il requisito fondamentale per un’impresa Just-In-Time è 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 aggiunte molte altre caratteristiche che migliorano ulteriormente l’efficienza e
l’efficacia dell’impresa.
Per prima cosa, è consigliabile che i meccanismi che portano le informazioni verso l’utente seguano approcci di tipo push anziché pull, cioè cerchino
di prevenire le esigenze e fornire in anticipo le informazioni di cui la persona
34
Capitolo 3. Proposte per l’impresa Just in Time
può 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 qualità delle informazioni che vengono
trasmesse in azienda, si possono sfruttare dei profili, generati automaticamente o configurati dall’utente stesso, che permettono di personalizzare i
dati trasmessi in base chi li dovrà utilizzare e al fine per cui i dati sono
richiesti.
Se il processo è stato accuratamente progettato, è possibile raccogliere
una grande quantità di dati sui processi aziendali, ma affinché questi dati si
trasformino in informazioni utili è necessario definire degli indicatori sintetici,
KPI, che siano in grado di dare una prospettiva generale sullo stato dell’azienda. Questa capacità 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 è
la capacità 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’architettura IT, e delle soluzioni specifiche, per la Just-In-Time Organization. In
particolare, si deve notare che come tutti i processi di sviluppo è un processo
ciclico che tende ad arricchire di funzionalità 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 è quello di considerare come punto di
partenza il dato. Infatti, in molti casi, partendo dalla struttura dei dati, non
è possibile realizzare una architettura completa e efficiente poiché in realtà il
vero focus deve essere posto sugli utenti. Considerando come punto di parten-
3.3. Informazioni rilevanti
35
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 è invece fortemente incentrato sull’utente e parte proprio dall’individuazione e classificazione degli utilizzatori del sistema. Una
volta individuati gli attori in gioco, si passa a un’attenta analisi degli obiettivi di business di ognuno di loro e dei possibili usi che faranno della soluzione
finale. Dagli obiettivi di business è possibile capire quali indicatori di business 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 può 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 più efficace bisogna realizzare soluzioni pensate per gli specifici device che saranno utilizzati per la
visualizzazione.
36
Capitolo 3. Proposte per l’impresa Just in Time
3.3.1
Gli utenti
Come già 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: è 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 può anche essere
utilizzatore delle informazioni, ma solo relative alla sua persona.
Project Manager(PM): è 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 è un professional assegnato
al progetto. Il PM interagisce con il sistema principalmente per fare
operazioni di analisi, ma è anche a sua volta una sorgente di dati ad
esempio nei confronti degli account manager e dei head of division.
3.3. Informazioni rilevanti
37
Account Manager (AM): è 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): è a capo di una divisione all’interno dell’azienda. Deve approvare la richiesta di risorse provenienti dal PM ed è
interessato principalmente al lato finanziario della gestione della divisione.
Resouce Manager (RM): ha un focus simile ai HoD, ma con una visione
che va oltre la singola divisione. Il suo compito principale è ottimizzare
l’allocazione delle risorse.
3.3.2
Scenari d’uso
Tipicamente è 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 mobilità e in riunione con i propri colleghi
o con partner aziendali.
La situazione tipica è quella di un dipendente, che nel suo ufficio di fronte
al suo PC, ha la necessità 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 è comunque necessario
capire quali tra questi strumenti possono rendere i suoi compiti più facili e
veloci.
Spesso un dipendente si trova a compiere spostamenti per il suo lavoro, ma
ha la necessità 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
38
Capitolo 3. Proposte per l’impresa Just in Time
aspetti sono però critici e devono essere affrontati in questo contesto. Il primo
aspetto riguarda è la criticità 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 è quello dei meeting aziendali e
dei contesti collaborativi, dove si ha l”esigenza di esporre e presentare risultati, offerte tecnologiche e dettagli di progetto. In questo contesto, l’aspetto
più significativo è la facilità 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 potrebbero 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, può trovarsi a lavorare
principalmente in due contesti: da solo o con altre persone. Il primo caso
è quello più semplice e comune e la maggioranza dei software in commercio
sono pensati per questo contesto. In realtà, in azienda è 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.
3.3. Informazioni rilevanti
39
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 può incidere fortemente sulla velocità di sviluppo, ma anche sulla
capacità di integrare e riutilizzare i componenti già presenti.
Sui diversi device si possono sviluppare tool diversi (portali, widget, strumenti di reportistica,...) ognuno dei quali finalizzati a obiettivi diversi e
conseguentemente progettati per soddisfare requisiti diversi.
Le soluzioni sviluppate possono avere modalità di visualizzazione dei dati che vanno dalla più sintetica metafora, sole se l’azienda va bene fulmini e
pioggia in caso di problemi, al datasheet con funzioni di aggregazione e esplo-
40
Capitolo 3. Proposte per l’impresa Just in Time
sione per visualizzare i dati completi di una tabella di un report. Tra questi
due estremi sono presenti un’infinità di stili e modelli di visualizzazione intermedi 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 è il fattore tempo. Questo fattore è particolarmente
importante perché può diventare un aspetto dannoso per il sistema e un requisito vincolante e discriminante per tutta l’architettura. Ad esempio, è
inutile che il sistema sia progettato per realizzare analisi realtime quando le
informazioni generate vengono utilizzate per prendere decisioni settimanali. 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 disponibilità con il minor tempo possibile.
Il modello di analisi qui proposto, sarà 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 potrà 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 già 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 ricavare le informazioni e, nel caso in cui l’azienda fosse dotata di datawarehouse
e strumenti di reportistica già collaudati, il sistema prevederà 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 ciò c’è 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 è 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 è dovuto ai seguenti motivi:
• Maggiore garanzia di sicurezza per ciò che riguarda i dati aziendali.
Infatti, la suddivisione tra business layer e data layer permette l’accesso
44
Capitolo 4. Architettura del Sistema
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 attualmente presenti risulta più immediata e semplice perché ogni componente è nettamente separata dagli altri. Inoltre, in caso di errori è 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 è di tipo aperto, cioè non si lega in modo particolare
ad un tipo di client, garantendo la flessibilità 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 è il
Data Access Layer(DAL).
L’applicazione dovrebbe potere accedere a ogni singola informazione aziendale 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 già disponibili
in azienda. Il layer dei dati si occupa anche di uniformare i dati provenienti
4.2. Modello three tier
45
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 è costituito dal Business Logic Layer(BLL)
che implementa tutta la logica del sistema. Il BBL è costituito da tre componenti fondamentali: SecurityManager, InfromationManager, AlertManager.
L’InfromationManager gestisce il recupero delle informazioni e offre metodi per l’inserimento di dati. InfromationManager gestisce anche il recupero
di dati già elaborati e provenienti da uno strumento di reportistica esterno o
da un datawarehouse.
AllertManager è il componente che permette di creare e smistare ai diversi
utenti avvisi riguardanti informazioni di suo interesse.
Il SecurityManager implementa le funzionalità di autenticazione degli
utenti e di gestione delle sessioni di lavoro interfacciandosi con il repository degli utenti. Le caratteristiche di sicurezza che questo componente deve
garantire sono dettagliate in 4.3.
L’analisi dei dati riveste un ruolo sempre più determinate e anche le aziende, che fino a pochi anni fa si concentravano per lo più 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
46
Capitolo 4. Architettura del Sistema
informazioni provenienti dalle diverse fonti. Le informazioni, nelle loro varie
declinazioni(report, contact, task,...), vengono analizzate da ProjectsAnalyzer per rilevare il livello di importanza e l’utente interessato. Per ogni
categoria di utilizzatore è 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 avvisi che vengono recapitati all’utente. Un esempio di analisi interessante per
i manager può 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 backend del sistema permette di avere una soluzione molto flessibile e facilmente
estensibile.
Sfruttando il protocollo HTTP e incapsulando i messaggi secondo il protocollo 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 accedere 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 è la possibilità di collegare tra loro più servizi riutilizzando le funzionalità già implementate. Per esempio, tramite web service
l’azienda può decidere di integrare il nostro sistema con quello contabile per
verificare i giorni lavorati dai dipendenti e segnalare irregolarità.
4.2. Modello three tier
4.2.3
47
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 più 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 è indispensabile sviluppare client
dedicati al tipo di device utilizzato per riuscire a sfruttare a pieno le potenzialità di questi strumenti, garantendo la maggiore semplicità d’uso per
l’utente. Questa scelta implica lo sviluppo e il mantenimento di client molto
diversi tra loro, ma questo aspetto non è comunque critico.
Un primo fattore da considerare è il mercato: negli ultimi anni l’apparizione di device sempre più evoluti, semplici e interattivi ha spinto a ripensare
il normale concetto di fruizione di un servizio, in particolar modo dell’utilizzo del web. Fino a qualche anno fa, il principale meccanismo per rendere
disponibile la fruizione di un servizio era la realizzazione siti web e applicazioni utilizzabili tramite browser perché garantiscono un buon livello di
inter-operabilità 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 famiglie 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-
48
Capitolo 4. Architettura del Sistema
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 è che concentrando tutta
la logica dell’applicazione nella parte di back-end, si può mantenere e sviluppare agevolmente il codice che gestisce le operazioni core della piattaforma,
senza modificare minimamente i client. Inoltre, mantenere la logica indipendente 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, è 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 informazioni in qualsiasi situazione si trovino ad operare. Le tecnologie descritte
nel 2 possono essere utili a questo scopo.
4.3. Aspetti di sicurezza
4.2.4
49
Considerazioni
L’architettura cosı̀ presentata è molto agile e flessibile, in particolare possiamo vedere come sia semplice agganciarsi ad altre fonti di dati sia interne che
esterni all’azienda. Per garantire ottime prestazione, scalabilità e affidabilità
il back-end potrebbe essere sviluppato sfruttando un servizio di Cloud Computing. Utilizzando semplici thin-client per i vari device sarà possibile accedere ai dati dai dispositivi fissi e portatili più 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 contenere un modulo per la gestione della sicurezza che rispetti determinate
caratteristiche.
In ogni sistema la sicurezza è sempre uno dei punti critici, poiché spesso
viene mal progettata e ritenuta di secondo piano rispetto all’obiettivo effettivo per cui il sistema è pensato: tale problema è poco rilevante solo per piccole
applicazioni non destinate alla interazione tra sistemi eterogenei complessi o
all’ambito aziendale. Al crescere della complessità e dell’importanza del sistema 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.
Confidenzialità: Con confidenzialità si intende la protezione dei dati e
delle informazioni scambiati tra un mittente e uno o più destinatari, impedendo a terzi di venirne in possesso o di essere capaci dei comprenderne il
50
Capitolo 4. Architettura del Sistema
significato. Risulta però difficile impedire che le informazioni e i dati vengano
in possesso di persone estranee alla comunicazione, perché ciò comporterebbe
l’utilizzo di un canale di trasmissione sicuro che però nella maggior parte dei
casi non è utilizzabile perché 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 sistema che garantisce la confidenzialità, una terza parte che entri in possesso
delle informazioni scambiate tra mittente e destinatario, non è in grado di
ricavarne alcun contenuto informativo intelligibile.
Integrità: Con integrità si intende la protezione dei dati e delle informazioni 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 integrità vi è quindi la possibilità di verificare con assoluta certezza se un dato
o una informazione sono rimasti inalterati nel loro contenuto durante la loro
trasmissione.
Disponibilità: Con disponibilità 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 caratteristica, tipica della progettazione di impianti informatici, risulta molto
interessante anche lato software quando si deve gestire l’interazione sicura
tra ‘gruppi’ di utenti: ciò comporta spesso scambio di informazioni per garantire la sicurezza e l’integrità dei dati inviati nel gruppo e perciò 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 più approfondita analisi merita il requisito di autenticazione, che si lega trasversalmente con il paradigma CIA. Con tale termine,
derivante dalla parola greca authentes (autore), si è soliti definire un processo che permette di verificare la presunta identità di un interlocutore di una
comunicazione o del creatore di un documento. Definire in modo univoco l’identità di un utente, o di un’altro sistema, e riconoscerlo è 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 è soliti raggruppare i metodi di autenticazione in tre
paradigmi: One-way(il più diffuso), uno solo dei due interlocutori si identifica
verso l’altro, che si presume avere una identità 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 autenticazione possibili è 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 più 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
52
Capitolo 4. Architettura del Sistema
e utilizzate nel caso di studio. Fin da ora è bene però chiarire che una
buona gestione dell’autenticazione degli agenti che interagiscono nel sistema
è 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 è 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 è stato applicato e integrato in un
caso reale, in particolare l’azienda con la quale abbiamo lavorato è CEFRIEL.
Grazie a questa collaborazione siamo riusciti a comprendere al meglio i problemi 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 già 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 ricerca e la formazione nel settore dell’Information & Communication Technology.
Suo obiettivo primario è rafforzare i legami tra università e imprese attraverso 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 realtà dei processi industriali, per innovare o
realizzare nuovi prodotti e servizi.
CEFRIEL è oggi una società consortile i cui soci sono il Politecnico di
Milano, l’Università degli Studi di Milano, l’Università degli Studi di MilanoBicocca, l’Università degli Studi dell’Insubria, la Regione Lombardia e 15
aziende multinazionali operanti nel settore ICT e dell’editoria multimediale. CEFRIEL è parte attiva dell’ICT Institute, la recente istituzione del
Politecnico di Milano nata per coordinare e promuovere le iniziative dell’Ateneo per la formazione, ricerca e innovazione nel settore delle tecnologie
dell’informazione e della comunicazione.
Visto il contesto altamente tecnologico in cui opera, CEFRIEL è già dotato di un sistema informativo in cui integrare la nostra soluzione. Altra
caratteristica che fa del CEFRIEL un candidato ideale è che il suo business
principale si sviluppa grazie a progetti, che quindi devono essere gestiti nella
maniera più 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
5.1.2
55
Il modello organizzativo
L’attività lavorativa in CEFRIEL è incentrata sui progetti. Ogni dipendente
aziendale ha il compito di fare evolvere un progetto il più velocemente possibile secondo le esigenze del cliente, l’organizzazione dell’azienda perciò si
sviluppa nel rispetto di questo obiettivo.
Cefriel è suddiviso in quattro divisioni: Digital Interaction & Visual Experience (DI), Digital Enterprise & Information Systems (DE), Digital Platforms & Pervasive ICT (DP) e Digital Knowledge & Education (DK). Questa
divisione rafforza il livello qualitativo dei progetti e rende più efficaci i tempi
di esecuzione, aspetto fondamentale per una società come questa.
I principali ruoli ricoperti in Cefriel sono quattro: Head of Division, Account 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 occupano 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 project manager, sono responsabili di progetto, ma con riferimento diretto a
un particolare cliente. L’account manager è di solito il collegamento tra il
cliente è l’insieme di progetti che sono sviluppati per esso. Infine, la figura 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
56
Capitolo 5. Caso di Studio: CEFRIEL
per la figura di resource manager che viene sostituita in termini di responsabilità dalle altre figure presenti.
5.1.3
Il sistema di controllo e gestione progetti
Come è già stato più volte sottolineato, in ogni azienda è fondamentale monitorare lo stato di avanzamento dei lavori in atto e per fare ciò è indispensabile
partire dai dati inseriti dai lavoratori. In particolare nelle aziende incentrate
sullo sviluppo di progetti, ha un ruolo determinante l’inserimento dei consuntivi, cioè quante ore ogni professional ha lavorato sui progetti a cui è
assegnato.
In CEFRIEL, a dimostrazione della particolare attenzione per il tema
trattato, era già presente un sistema per il controllo e la gestione dei progetti
sviluppato ad hoc alcuni anni fa dallo stesso CEFRIEL. Il sistema si è evoluto
col tempo cercando di migliorare costantemente sia dal punto di vista delle
funzionalità che da quello della semplicità 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 modifica 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 già
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 possibilità di
avere ancora più 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 attività 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 periodicamente nell’arco della giornata) dei dati provenienti da CGP DB.
• CGP DW: è il datawarehouse dell’azienda. Questo database contiene
lo storico e il sintetico delle informazioni provenienti da CGP DB. Inoltre 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.
58
Capitolo 5. Caso di Studio: CEFRIEL
Inoltre CEFRIEL è dotato di un’altro server sul quale è situata la Web
Application che attualmente viene usata per il controllo di gestione. La
Web Application è ospitata su un Web Server IIS. Sulla stessa macchina è
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 evidenziato i principali casi d’uso per le tipologie di utente presenti in CEFRIEL.
Per ogni tipologia di utente è 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 è frutto di un sondaggio fatto all’interno dell’azienda e
indica quindi le priorità 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 dell’azienda. Ogni utente, deve per prima cosa loggarsi al sistema e solo dopo
essere stato riconosciuto può accedere alle informazioni aziendali. Un professional assegnato a uno o più progetto deve eseguire determinate attività
suddivise in task e periodicamente deve consuntivare, cioè riportare nel sistema le ore impiegate per eseguire i compiti assegnategli. Complessivamente le
ore effettivamente lavorate devono essere maggiori o uguali a quelle indicate dal contratto del professional e quindi deve poter verificare facilmente di
aver inserito i dati in modo completo. Dalle nostre analisi è emerso che un
bisogno molto comune per le aziende è 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 è necessario soddisfare per un professional c’è anche la possibilità 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 scenari più 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 più 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 attività da compiere e controllare se ci sono
avvisi urgenti che gli riguardano.
60
Capitolo 5. Caso di Studio: CEFRIEL
La tabella (Tabella 5.1) riassume schematicamente la rilevanza delle di-
verse attività in abito mobile e desktop.
Attività
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 project manager dell’azienda, naturalmente essendo anche un professional eredita tutte le attività evidenziate precedentemente. Il project manager si
differenzia dal professional per le funzioni di management, quindi necessita
di informazioni più elaborate generate aggregando da dati semplici che permettano una visione dello stato di avanzamento dei progetti. I primi due
dati da tenere in considerazione sono l’andamento del SAL, cioè i costi del
progetto, e del WIP, cioè di quanto valore è già stato sviluppato rispetto al
valore complessivo del progetto. L’altro aspetto di interesse per il project
manager è l’andamento dei consuntivi perché 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 può dipendere dal fatto che uno o più
dipendenti non hanno ancora inserito i propri consuntivi e quindi il costo
delle ore uomo lavorate non è ancora stato aggiunto. Infine, diversamente
dal professional, il project manager deve avere la possibilità 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 priorità di un’azione 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 particolare nel contesto mobile e meeting sono rilevanti gli aspetti di visualizzazione
dello stato dei progetti. Per quanto riguarda la possibilità di inviare avvisi
agli utenti resta comunque rilevante nel contesto mobile, ma non in quello
meeting.
62
Capitolo 5. Caso di Studio: CEFRIEL
Attività
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 attività che può svolgere l’account manager sono simili a quelle del project manager, infatti, i due utenti sono differenziati principalmente dal tipo
di progetti al quale fanno riferimento: gli account manager hanno visibilità 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 divisioni. Rispetto a un project manager, il HoD si focalizza principalmente sullo
stato di allocazione delle proprie risorse e sulla quantità di ore consuntivate. Naturalmente, in quanto manager anche il capodivisione ha la possibilità
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 ambito 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
Attività
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 è basata su piattaforma Windows, abbiamo deciso di implementare tutta la parte di back-end
64
Capitolo 5. Caso di Studio: CEFRIEL
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’utilizzo di questo framework ha permesso di adottare una serie di accorgimenti
che garantiscono un’ottima flessibilità ed espandibilità del sistema.
5.3.1
Layer di accesso ai dati
L’attuale sistema Controllo Gestione Progetti (CGP) è 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 è 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 libertà di sviluppo dei due sistemi.
5.3. Architettura di back-end
65
Fig. 5.6: Schema ER di GEDI ALERT
GEDI ALERT è schematicamente molto semplice in quanto deve contenere soltanto l’elenco degli avvisi che circolano nel sistema e la loro priorità.
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 può
capire l’organizzazione interna di DAL: il layer è composto dalla classe statica
GediDataLayerConnector e dai package Alert e CGP.
L’elemento principale del package Alert è 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 è strutturato analogamente al package ALERT e contiene
le classi per l’accesso e la gestione di CGP DB, ma poiché le azioni che si
possono voler eseguire su questo database sono più complesse e più 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 consuntivo. 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-
66
Capitolo 5. Caso di Studio: CEFRIEL
Fig. 5.7: Class Diagram DAL
tsManager è 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 informazioni 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).
5.3. Architettura di back-end
67
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 accessibili e instanziabili dall’esterno, ma è 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, poiché non
ha visibilità della struttura implementativa, non avrà nessuna ricaduta sulle
modifiche effettuate. Questa struttura risulta molto utile per esempio se si
68
Capitolo 5. Caso di Studio: CEFRIEL
volesse modificare il database utilizzato o se si volesse collegare nuove basi
di dati al sistema, garantendo cosı̀ massima flessibilità e manutenibilità.
Fig. 5.9: Esempio Sequence Diagram per chiamata a DAL
Il Sequence diagram in Fig. 5.9 mostra come avviene una comune chiamata 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 base di dati chiede alla classe GediDataLayerConnector di generare il manager
per il BusinessDB. Una volta generato IBusinessDBManager può richiedere 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 è la possibilità
di sfruttare a pieno la tecnologia LINQ[4].
5.3. Architettura di back-end
69
La maggior parte dei programmi scritti oggi manipola in un modo o nell’altro dati, e spesso questi dati vengono memorizzati in database relazionali.
Eppure c’è 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, come il completamento automatico del codice. Dopo due decenni, l’industria
ha raggiunto un punto stabile nell’evoluzione delle tecnologie di programmazione orientati agli oggetti (OO) e i programmatori danno per scontato
caratteristiche come classi, oggetti e metodi. Guardando la generazione attuale e quella successiva, è diventato quindi evidente che la prossima grande
sfida nella tecnologia di programmazione è quello di ridurre la complessità
di accesso e l’integrazione di informazioni che non sono nativamente definita
usando la tecnologia OO. Le due più comuni fonti di informazioni non-OO
sono i database relazionali e XML.
Piuttosto che aggiungere funzionalità relazionali o specifiche per XML
ai linguaggi di programmazione, il progetto LINQ utilizza un approccio più
generale che implica l’aggiunta di funzionalità di query generiche che si applicano 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, analisi 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-
70
Capitolo 5. Caso di Studio: CEFRIEL
te le informazioni in memoria, non solo informazioni provenienti da fonti
esterne. LINQ utilizza una sintassi simile a SQL, ma, oltre ai vantaggi già
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 è 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 spinto a utilizzare LINQ, evidenziamo quali sono gli altri vantaggi particolarmente significativi e utili nel conteso CEFRIEL:
• Transaction: ogni interrogazione LINQ viene eseguita automaticamente in un contesto transazionale, ma che può essere implementato anche
manualmente.
• Standard query: Linq offre una metodologia standard per eseguire query, questo può 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 già
sviluppate.
5.3. Architettura di back-end
5.3.2
71
Layer logico
Il secondo livello che andiamo ad analizzare nel dettaglio è quello della logica
applicativa. Trovandosi nel mezzo tra Presentation Layer e Data Layer, il
compito di BLL è quello di fornire ai client un mezzo semplice per accedere
a dati che normalmente richiederebbero interrogazioni complesse.
Un’alto ruolo che svolge la logica è quello di mantenere la sessione attiva
per ogni singolo utente che effettua la chiamata. Nel momento in cui avviene 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
complessità e l’esigenza di mantenerla indipendente dal resto del sistema, è
stato deciso di realizzare un componente separato che potesse essere gestito
e sviluppato in modo autonomo.
Il BLL è costituito da tre componenti principali che permettono di fornire
servizi verso l’esterno: SecurityManager, ProjectStateManager, AlertManager (Fig. 5.10).
Il SecurityManager è sviluppato tramite due classi che implementano la
funzionalità di autenticazione degli utenti, Access Validator, e quella di identificazione 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 può eseguire 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 funzionalità configurate per quel ruolo. La scelta di
dividere le funzionalità tra queste due classi permette di gestire facilmente
l’integrazione con i sistemi aziendali, ad esempio l’active directory di dominio,
72
Capitolo 5. Caso di Studio: CEFRIEL
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 è il componente dedicato alla gestione degli avvisi che
permette agli utenti di inserire nuove segnalazioni e recuperare quelle già
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
5.3. Architettura di back-end
73
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 relativo metodo della logica. La logica verifica se l’utente ha già eseguito altre
operazioni e, se è ancora presente una sessione valida, recupera le informazioni dell’utente. Se invece non è 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.
74
Capitolo 5. Caso di Studio: CEFRIEL
DataContract
Un DataContract è un accordo formale tra un servizio e un client che descrive
astrattamente i dati da scambiare. Per comunicare, non è 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
5.3. Architettura di back-end
75
AlertContract definisce i dati che rappresentano un singolo alert.
ConsuntiviContract rappresenta la struttura di un oggetto consuntivo.
AllocazioneContract rappresenta le informazioni di una singola allocazione 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 è il contratto che racchiude le informazioni un’attività
di progetto. Contiene al suo interno la lista dei TaskContract relativi
ai task associati alla attività.
ProgettoContract racchiude la definizione di tutte le informazioni rilevanti
di un progetto, tra cui la lista AttivitaContract relativi alle attività
presenti per il progetto.
RisorsaContract è il contratto che definisce quali informazioni di una risorsa vengono passate tra server e client. Contiene la lista dei ConsuntiviContract riferiti ai consuntivi inseriti.
SALContract contiene i parametri rilevanti per lo Stato Avanzamento Lavori.
WIPContract contiene i parametri rilevanti per il valore di Work In Progress.
SerialGraphicalContract è la struttura più generale in grado di contenere
delle serie di dati da potere visualizzare come grafico nel client.
76
Capitolo 5. Caso di Studio: CEFRIEL
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 funzionalità
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 può in alcuni casi essere particolarmente
onerosa dal punto di vista prestazionale, sopratutto per il DBMS, il processo del tool di analisi è 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 è 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’azienda. 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
5.3. Architettura di back-end
77
risorsa. Se il totale è minore di quello richiesto viene inviato alla risorsa
e ai suoi manager un alert di alta priorità, dove si segnala il ritardo nella
consuntivazione.
• Ore inserite dal professional nella settimana precedente. Vincolo analogo al precedente, ma su intervallo settimanale. Questo avviso è meno rilevante di quello precedente dal punto di vista di contabilità, ma
permette all’utente di controllare se è 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 è 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 progetto emessa possono essere generati due avvisi. Il primo, più importante,
viene generato se è già trascorsa la data in cui doveva essere emessa una
78
Capitolo 5. Caso di Studio: CEFRIEL
fattura. Il secondo, meno critico, permette di segnalare che è si sta avvicinando il giorno in cui il responsabile dovrebbe emettere la fattura.
Il numero di giorni entro il quale segnalare questo alert è 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 è separato dal resto del
sistema. La classe AnalisiThread si occupa delle operazioni preliminari che
però 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 esegui. Questa struttura rende molto semplice l’implementazione di una nuova
5.3. Architettura di back-end
79
classe di analisi, ad esempio che si appoggi a un datawarehouse, o specializzare ulteriormente le due classi di analisi già implementate, ad esempio
per inserire nuovi tipi di analisi sui dati delle risorse. Molto semplicemente,
è 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 già 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
80
Capitolo 5. Caso di Studio: CEFRIEL
contenuto in BLL. I metodi esposti dal servizio sono raggruppati in due interfacce, IProject e IAlert, che riuniscono rispettivamente le chiamate riferite
allo stato dei progetti e le chiamate dedicate alla gestione degli alert. L’utilizzo delle interfacce permette lato client un uso più ordinato delle chiamate
al web service.
Le interfacce esposte sono implementate in due diversi modi tramite le
classi IWAService e HTTPSService. IWAService è l’implementazione web
service che sfrutta le caratteristiche dellaIntegrated Windows Authentication
per gestire l’acceso al sistema. Questa implementazione è molto utile in
contesti dove la piattaforma di riferimento è Windows. HTTPSService è
invece l’implementazione che sfrutta HTTPS come protocollo di trasmissione
e l’Access Validator presente in BLL per gestire gli accessi. HTTPSService è
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 può scegliere di pubblicare
solamente uno dei due.
La scelta di realizzare due soluzione diverse vuole permettere di lasciare
grande libertà 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 è
facilitata dall’utilizzo di Windows Communication Foundation (WCF).
WCF è un sottosistema applicativo che risolve tutta una una serie di
problemi comuni nella comunicazione tra applicazioni fornendo supporto sia
5.3. Architettura di back-end
81
per protocolli standard come SOAP, ma anche altri tra i più 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, interoperabilità 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 più
disparate. Le applicazioni basate su WCF sono in grado di lavorare con altri
software in esecuzione in una grande varietà di contesti(Fig. 5.15):
• Applicazioni basate su altre tecnologie, come Java EE application server, che supportano i servizi Web standard. Queste applicazioni pos-
82
Capitolo 5. Caso di Studio: CEFRIEL
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 è caratterizzato da tre componenti principali (Fig.
5.16): una classe di servizio che implementa uno o più metodi; un processo
host in cui il servizio viene eseguito; uno o più 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 sarà per utilizzo
esclusivo all’interno della rete aziendale, mentre la seconda è 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
5.3. Architettura di back-end
83
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 Information Service (IIS) 7.0 per garantire maggiori performance, sicurezza e
affidabilità.
5.3.5
Sicurezza del sistema
L’aspetto della sicurezza del sistema è 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 più immediato
possibile da fruire. Per questo motivo, abbiamo sfruttato il più possibile
gli strumenti di autenticazione offerti da IIS come la Integrated Windows
Authentication per sistemi operativi Windows. Per il dispositivo mobile,
si è voluto lasciare ampia libertà di evoluzione verso sistemi non basati su
piattaforma Microsoft e si è 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 validità delle credenziali e restituisce una conferma di avvenuta
autenticazione. Tali informazioni sono ricercate e recuperate nell’Active Directory, il quale contiene l’elenco degli account registrati nel dominio. Nel
caso di IWA è stato possibile sfruttare a pieno il modulo per il controllo già
presente in IIS, mentre per la FA abbiamo implementato un componente ad
hoc.
84
Capitolo 5. Caso di Studio: CEFRIEL
Integrated Windows Authentication
Integrated Windows Authentication è il sistema di autenticazioni preferito 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 è che l’utente non deve inserire altre credenziali oltre a quelle che ha già inserito per accendere il device.
Inoltre, la IWA non invia le password dell’utente o altre informazioni sensibili al server, ma si limita a comunicare l’username della persona che vuole
accedere al sistema.
In Fig.5.17 è 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 Controller, il quale è 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 ripassa il messaggio al client. Il client decifra il messaggio e se il messaggio
è lo stesso di quello originale il servizio è valido e il client procede con la
connessione. Il protocollo Kerberos non solo permette di utilizzare la Windows Authentication, ma controlla la mutua autenticazione di client e server
prima dello scambio di messaggi.
5.3. Architettura di back-end
85
Fig. 5.17: Integrate Windows Authentication (Kerberos v5)
Se a livello di autenticazione il protocollo precedentemente descritto è
altamente prestazionale, non vale lo stesso per quanto riguarda i requisiti
cardine del modello CIA in quanto non fornisce nessuna delle tre caratteristiche richieste. In realtà, questa mancanza dei requisiti CIA non è un
problema, in quanto l’ambiente entreprise nel quale è collocata l’architettura
è ritenuto sufficientemente sicuro per garantire i requisiti di Confidenzialità,
Integrità e Disponibilità. L’uso di questo meccanismo di autenticazione per
interagire dall’esterno dell’azienda è invece fortemente sconsigliato, a meno
che non venga prima instaurata una VPN.
86
Capitolo 5. Caso di Studio: CEFRIEL
Form Authentication
La Form Authentication è il classico sistema di autenticazione che prevede
l’inserimento del nome utente e della password utilizzando delle caselle di
testo e che è spesso utilizzato nelle pagine web perché garantisce sicurezza
e allo stesso tempo semplicità per l’utente. Naturalmente, poiché 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 più comune, e che anche noi abbiamo deciso di adottare, è
la cifratura del messaggio. In particolare si è utilizzato il protocollo HTTPS,
cioè 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 verificabile dal client (Vedi Fig. 5.18) per garantire le policy di sicurezza minime
per rispettare vincoli del modello CIA. Non avendo a disposizione un certificato 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 ambiente sicuro come quello enterprise. E’ comunque consigliabile l’utilizzo di un
certificato firmato da una certification authority.
In questo contesto il meccanismo di autenticazione è differente dal precedente. Inizialmente si ha la negoziazione fra le parti dell’algoritmo da utilizzare 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 validità delle credenziali è affidato all’Access Validator
(vedi Fig. 5.5), che verifica se l’utente che ha richiesto l’accesso al servizio
è registrato come utente di dominio nell’Active Directory e che la password
inviata è corretta.
Il vantaggio di questa soluzione è che può 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 è rilevante, bisogna anche riuscire a rappresentarle in modo efficace e soprattutto in modo intuitivo per l’utilizzatore[20].
Il livello presentazione è 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 più possibile la logica contenuta
nei client, semplificando lo sviluppo di soluzioni per dispositivi diversi. Tra le
88
Capitolo 5. Caso di Studio: CEFRIEL
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 requisiti dei propri utenti, serve è una piattaforma che renda facile costruire
interfacce usando semplici modelli di progettazione. Per questo abbiamo deciso di utilizzare come linguaggio di sviluppo nuovamente il framework .NET
e in particolare Silverlight 4.0, che fa parte di Windows Presentation Foundation (WPF) . Gli aspetti che ci hanno spinto a scegliere questa tecnologia
sono principalmente tre:
• Possibilità di realizzare interfacce altamente interattive e complesse,
ma allo stesso tempo intuitive.
• Possibilità di adottare in modo efficiente il pattern di sviluppo ModelView-View-Model (MVVM), che garantisce il massimo del riutilizzo del
codice.
• Disponibilità della tecnologia tutti e tre i contesti di interesse.
5.4.1
Pattern MVVM
Da quando si è cominciato a creare interfacce utente software, ci sono stati
vari pattern di progettazione per contribuire a rendere più facile lo sviluppo.
Ad esempio, il Model-View-Presenter (MVP), variante del pattern per
eccellenza per molti anni Model-View-Controller, ha goduto di popolarità su
diverse piattaforme di programmazione. Quello che si vede sullo schermo è 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 attività simili.
Partendo da questo modello è stato poi proposto il Presentation Model
(PM) pattern[15], simile a MVP, ma che presenta in più 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 è il Model-View-ViewModel
(MVVM) pattern[26], specializzazione del più generale modello PM, per il framework .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 ciò che l’utente vede sullo
schermo. Idealmente, il code-behind di una vista contiene solo il costruttore,
ma in alcuni casi, può contenere codice di logica di interfaccia che implementa
un comportamento visivo che è 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 utilizzerà 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-
90
Capitolo 5. Caso di Studio: CEFRIEL
mento a una View, ma è la View che si lega a una proprietà 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 perché
basta impostare il ViewModel come DataContext della View a cui si vuole
associare. Se i valori delle proprietà del ViewModel cambiano, i nuovi valori sono propagati automaticamente alla View tramite il Data Binding(Fig.
5.19). Quando l’utente fa clic su un pulsante nella vista, il comando associato 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 metodi 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 è
collocato completamente lato back-end (Fig. 5.20).
L’aspetto più importante di WPF che rende facile utilizzare MVVM è
l’infrastruttura di data binding che permette con una semplice associazione,
e implementazione dell’interfaccia INotifyPropertyChanged, di rimuovere la
necessità 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 è un modello molto popolare anche perché le classi ViewModel
sono facili da testare. In un certo senso, View e Unit Test sono solo due tipi
di consumatori del ViewModel. La possibilità 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.
92
Capitolo 5. Caso di Studio: CEFRIEL
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 generalmente sviluppate per eseguire un singolo task. Il vantaggio di queste applicazione è la possibilità di averle sempre sott’occhio e a portata di click sul
desktop, garantendo cosı̀ l’immediatezza che stavamo cercando.
Il gadget Windows è composto principalmente da tre viste: la Home
principale che anche la parte sempre visibile quando il gadget è 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 avvio. 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
Fig. 5.22: Gedi Gadget
93
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 è la possibilità di creare istanze
differenti per il singolo oggetto. Per l’utente che ricopre due (o più) ruoli
all’interno dell’azienda è 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 può essere
ancorato stabilmente in primo piano e ne può essere regolata l’opacità.
Il gadget è 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 manutenibilità del codice.
La home si caratterizza per lo stile basato sui Tile, in cui ogni rettangolo rappresenta una tipologia di avviso che può interessare l’utente. I tile
contengono un’icona che rimanda alla tipologia di avviso, il nome del tipo di
94
Capitolo 5. Caso di Studio: CEFRIEL
avviso e il numero di alert di quella categoria. La lista e l’aspetto dei singoli tile è completamente personalizzabile tramite i settings. Quando l’utente
vuole inserire dei dati o leggere degli avvisi può semplicemente cliccare sul
tile corrisponde. Per tutti i ruoli aziendali la struttura iniziale a tile è 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 è 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) è possibile controllare i
progetti, le attività, i task e allocazioni su cui l’utente è allocato e può visualizzare, inserire e modificare le ore consuntivate. Nella parte bassa, è
rappresentato il grafico delle ore consuntivate nell’ultimo mese per il progetto selezionato o per tutti i progetti su cui il professional è allocato. Ogni
utente ha anche la possibilità, 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 segnalare una variazione nel progetto. Dopo aver letto l’avviso, l’utente può
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 dopo avere esaminato l’alert modifichi i suoi valori facendo in modo che questo
evento non venga più 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 possibilità di monitorare i KPI e alcuni grafici interessanti per
ogni singolo progetto attivo. Gli indici di più 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 è presente
anche un’indicatore che permette a colpo d’occhio di identificare i progetti
96
Capitolo 5. Caso di Studio: CEFRIEL
che presentano particolari problemi. L’indicatore può essere di colore rosso,
nel caso il progetto presenta criticità rilevanti, arancione se presenta problemi 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 inferiore è 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 possibilità di vigilare a livello economico lo stato del progetto.
L’area è espandibile quindi, se ce ne fosse l’esigenza, si potrebbero inserire
facilmente altri grafici.
Vediamo infine le funzionalità offerte dal gadget desktop per i capi divisione (Fig. 5.25). Questo utente è 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 quantità di ore inserite per poter
monitorare l’attività della risorsa.
• Il numero di progetti nel quale la risorsa è allocata. In questo modo
è possibile evitare di allocare la risorsa in troppi progetti contemporaneamente.
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’indicatore che permette di visualizzare istantaneamente come è lo stato della
risorsa.
Fig. 5.27: Pagina di invio di avvisi
98
Capitolo 5. Caso di Studio: CEFRIEL
Per tutti i manager il gadget offre una funzionalità aggiuntiva rispetto
ai professional. Nel flayout, accanto all’icona degli avvisi, c’è un’altra icona
cliccando sulla quale i manager possono inviare avvisi a tutte le risorse assegnate 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 attività 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 più giovane tra le tre presentate nel capitolo2
e al momento non supporti alcune funzionalità già presenti nelle piattaforme
concorrenti, Windows Phone 7 è una piattaforma molto promettente. I recenti 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 permetterà 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
età 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 però guida rapidamente le persone nella direzione giusta fino alle informazioni che vogliono
avere. Metro UI è 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 sullo schermo, ma sfruttando al meglio quanto offerto dai pixel. Il risultato è
sicuramente il miglior design tra le piattaforme in circolazione e, come accennato precedentemente, abbiamo deciso di ispirarci a essa per realizzare lo
stile delle nostre nostre user interfacce.
La funzionalità primaria nel contesto mobile non è l’inserimento dei dati,
ma bensı̀ la consultazione. Per questo motivo abbiamo deciso di privilegiare
gli aspetti di usabilità 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 è il Panorama, che permette di visualizzare orizzontalmente informazioni e immagini che superano
i limiti fisici della dimensione dello schermo. Abbiamo adottato questo tipo di controllo per la pagina iniziale della applicazione per permettere agli
utenti che hanno più ruoli in azienda di visualizzare con poche gesture tutte
le informazioni riguardanti le proprie attività. La homepage (Fig. 5.28) può
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 può vedere il dettaglio di ogni singolo avviso. Sempre
per quanto riguarda gli alert, se l’utente è un manager può passare alla
visualizzazione di invio e digitare avvisi da mandare ad altri utenti collegati
alle sue attività.
100
Capitolo 5. Caso di Studio: CEFRIEL
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 interazioni di tipo gestuale. Guardando ai progetti diffusi in rete in questo
ambito, ci sono già state numerose sperimentazioni di utilizzo della periferica WiiMote come contoller per presentazioni o come strumento di interazione
a distanza.
Per quanto ci riguarda, abbiamo cercato di andare oltre queste sperimentazioni e realizzare proof-of concept di un’applicazione a interfaccia puramente gestuale, cioè senza alcun tipo di controller, sfruttando Kinect. La parte
di front-end in questo caso sarà completamente differente da quelle viste in
precedenza in quanto è pensata per i manager che devono mostrare report,
grafici e dettagli riguardo l’andamento delle attività ai propri clienti o nei
meeting aziendali. Inoltre, la possibilità 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 perché le librerie ufficiali per utilizzare Kinect da pc saranno rilasciate
solamente nei prossimi mesi. Offre però un assaggio anticipato di quello
che sarà 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 è 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 però 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 più valido, completo e affidabile. Alla
fine abbiamo deciso di utilizzare le librerie Open Natural Interface (OpenNI)
con i driver rilasciati da PrimeSense, società sviluppatrice e produttrice delle
telecamere di profondità presenti in Kinect.
OpenNI è un framework molto ampio che offre interfacce di programmazione software per scrivere applicazioni basate sulla natural interaction.
Questo framework non esclusivamente dedicato a Kinect, anche se al momento è il principale device utilizzato. Il framework fornisce sia API di basso
102
Capitolo 5. Caso di Studio: CEFRIEL
livello per l’accesso diretto ai dati RAW del device, sia API di più alto livello
che forniscono funzionalità più avanzate come il riconoscimento del volto.
Sul piano dei sistemi operativi sono supportate le piattaforme Windows,
Mac e Linux e per la programmazione si può utilizzare C/C++ o un wrapper
C#.
La nostra soluzione
La nostra soluzione è stata realizzata su piattaforma Windows 7 e, per semplificare 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 disposizione 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 è stata realizzata
in Silverlight e anche in questo caso è stato possibile riutilizzare gran parte
del codice già sviluppato.
Dopo la schermata iniziale (Fig. 5.29), l’utente muovendo la mano a destra
e a sinistra può 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 può iniziare a sfogliare le informazioni disponibili(Fig. 5.31), sempre
muovendo la mano a destra e a sinistra. Se l’utente vuole cambiare progetto
può tornare alla schermata precedente semplicemente muovendo verso l’alto
la mano. Se invece ci sono delle informazioni particolarmente importanti, è
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 mappare anche un movimento veloce in direzione del Kinect, come se si volesse
104
Capitolo 5. Caso di Studio: CEFRIEL
afferrare un oggetto sullo schermo, con un evento di pressione del tasto sinistro 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 è 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 è plausibile per un meeting,
più 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 focalizziamo 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 giornaliera, 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’è 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 più 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 funzionalità, 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’è quello della gestione e
dell’utilizzo dei dati in modo efficace. L’obiettivo che ci eravamo posti è
stato quello è 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 più recenti 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 scalabilità e espandibilità, oltre a favorire
108
Capitolo 6. Direzioni future di ricerca e conclusioni
gli aspetti di manutenibilità e riuso delle caratteristiche già introdotte da noi.
Nel complesso, il sistema risulta fortemente multi-piattaforma e multi-canale.
Il prototipo realizzato conferma la flessibilità 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 più 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 è 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 funzionalità avanzate è
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 quantità
di dati scambiati. Per questo motivo si è preferito ridurre la profondità di
dettaglio e mostrare metafore e dati aggregati.
Front-end gestuale
Il prof-of-concept del front-end gestuale si concentra sugli aspetti collaborativi 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.
110
Capitolo 6. Direzioni future di ricerca e conclusioni
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 più interessanti si concentrano su quattro aspetti:
introduzione di nuove sorgenti di dati, l’incremento delle capacità di analisi del sistema, integrazione con altri sistemi aziendali, ampliamento dei
protocolli disponibili.
L’architettura flessibile e modulare della soluzione permette di aggiungere 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 capacità del sistema
facendolo diventare uno strumento ancora più potente e completo.
Arricchendo la quantità di dati, si potrebbe anche ampliare i tipi di analisi
effettuate dal Analyzer. Per ampliare le analisi da effettuare sulle dimensioni
già considerate è sufficiente estendere le classi già 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 analisi. Vista la disponibilità di un datawarehouse, si può anche pensare di realizzare un componente che sfrutti i dati e le capacità di questo strumento per
realizzare analisi ancora più sofisticate o di riutilizzare quelle già impostate.
Nell’Analyzer potrebbero anche essere introdotte funzionalità 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 funzionalità introdotte oppure il sistema di contabilità può essere integrato con il sistema per inviare notifiche importanti ai manager o agli altri
dipendenti.
Infine, l’ultimo aspetto che potrebbe essere ampliato riguarda i web service, in particolare i protocolli di comunicazione utilizzati. Negli ultimi anni
si sono sviluppati protocolli per lo scambio di informazioni più efficienti del
protocollo SOAP, come ad esempio JSON. L’utilizzo di WCF e l’architettura
sviluppata, garantiscono la possibilità di ampliare i protocolli supportati semplicemente definendo un nuovo EndPoint dedicato e riutilizzare interamente
la logica già presente.
112
6.3.2
Capitolo 6. Direzioni future di ricerca e conclusioni
Sviluppi futuri per il front-end
Per quanto riguarda il front-end è possibile fare evolvere in futuro il sistema
in due direzioni.
La prima direzione di sviluppo è 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 funzionalità dedicate alla visualizzazione delle previsioni fatte sui dati o introdurre nuovi meccanismi realtime
di esplorazione in profondità delle informazioni. Sempre nel contesto evolutivo delle attuali client, il front-end gestuale, attualmente sviluppato al solo
scopo dimostrativo, apre interessanti prospettive di utilizzo reale. Ad esempio, sarebbe interessante integrare le funzionalità 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 invece la possibilità di sviluppare sistemi complementari a quelli che noi abbiamo
proposto. Essendo l’architettura pensata per essere il più possibile multicanale, si possono facilmente sviluppare nuovi client con front-end dedicati ad
aspetti non coperti. Per esempio sarebbe interessante sviluppare client dedicati all’utilizzo su tablet o device touch di grandi dimensioni, eventualmente
con la possibilità di far collaborare più utenti tra loro. Infine, si potrebbe cercare 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 threetier 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. Race 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. Vlissides. 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 services: 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 Sercurity - 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 jitwith-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 interactive systems. ACM Press/Addison-Wesley Publishing Co., New York,
NY, USA, 2000.
[24] Thomas Schlömer, 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
GSM
GSM + CDMS
GSM + CDMA
Display
3.5 inch
variabile
variabile
Touch Screen
Capacitivo
Capacitivo
Capacitivo
Multitouch
Sı̀
Sı̀
Sı̀
Copertura di
rete
Sı̀ + Push NotiMultitasking
Inserito
entro
2011
Push
+
Sı̀
fication Service
Notification
Service
118
Appendice A. Tabella comparativa tra piattaforme mobile
Copia/ IncolSı̀
Sı̀
Sı̀
Tastiera
Solo virtuale
variabile
variabile
App Store
App Store
Android Market
la
Windows
Marketplace
Music Store
iTunes
3rd Party Store
Zune Store
Sı̀
Sı̀
Sı̀
App Store
3rd Party Store
Xbox Live
Sı̀ con App
Sı̀ con App
Sı̀
Sı̀ con App
Google Docs
Piattaforma
Advertsing
Game
Social
Network
Office
ProOffice 2010 mo-
duttivity
bilel
Suite
Browser
Mobile Safari
Chrome
IE8(Update
a
IE9
il
entro
2011)
Inserito entro il
Flash
No
Sı̀
2011
Silverlight
No
No
Sı̀
Java
No
Sı̀
No
Googlr
Bing
Gmail App
Outlook Mobile
Spotlight per la
Default
ricerca interna,
Search
Google
per
il
web
Email
Mail App
119
Sı̀, tile personaHome Screen
No
Sı̀
lizzabili
OS Update
Sı̀
Sı̀
Sı̀
Sı̀
Sı̀
Sı̀
No
Sı̀
No
Mobile Me
Google App
My Phone 2.0
300.000+
70.000+
20.000+
Firmware Update
Interfaccia
Personalizzabile
Cloud-Sync
Service
Applicazioni
Disponibili
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’avviso. Questo campo può assumere il valore nullo
nel caso l’evento sia generato dal sistema e sia
riferito ad un progetto anziché ad una risorsa.1
Id Progetto
Intero
Riferimento al progetto sul quale è stato
generato l’avviso.1
Data Creazione
Date
Data di creazione dell’avviso.
Time
Id Tipo
Intero
Riferimento alla tabella tipo.
Permette di
specificare la tipologia di Alert.
Creato Da
Intero
Identificativo della risorsa che ha creato l’alert. Siccome anche il sistema può generare alert, questo campo può assumere valori
negativi.
Already Read
Boolean Specifica se l’avviso è 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’è 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 già terminato, ma con il contratto non ancora approvato dal
Cliente (il progetto è 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 è 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 attività 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 (riducendo di conseguenza i costi di altri progetti)
In caso di semaforo giallo, le azioni precedenti sono proposte e discusse
con HoD e AM.