Studio di fattibilit per l'adozione e l'implementazione di un sistema open source di digital...

Università degli Studi di Padova

DIPARTIMENTO DI MATEMATICA

CORSO DI LAUREA IN INFORMATICA

Studio di fattibilità per l’adozione el’implementazione di un sistema open source

di digital signage

Tesi di laurea

Relatore

Prof. Paolo Baldan

Laureando

Jacopo Moronato

ANNO ACCADEMICO 2013-2014

Jacopo Moronato: Studio di fattibilità per l’adozione e l’implementazione di un sistemaopen source di digital signage, Tesi di laurea, c© Giugno 2014.

Sommario

Il presente elaborato si prefigge di illustrare l’attività di stage svolta dal laureandoJacopo Moronato presso l’azienda Ne-t by Telerete Nordest.

Verranno descritti in maniera approfondita metodologie adottate, approcci e risultatiottenuti nelle varie fasi che si sono susseguite durante l’esperienza lavorativa.L’obiettivo principale dell’attività di stage era la redazione di uno studio preliminaresui sistemi open source di digital signage esistenti, allo scopo di evidenziarne caratte-ristiche, peculiarità e problematiche, ed in modo da ottenere una raccomandazionesul sistema qualitativamente migliore, in previsione di una futura adozione dellostesso da parte dell’azienda.

Il digital signage è una forma di pubblicità nella quale i contenuti vengono veicolati aldestinatario tramite schermi elettronici strategicamente posizionati. Per raggiungereuna destinatario preciso l’informazione può essere automaticamente alterata tramiteuna varietà di fattori, come ad esempio l’orario. Gli schermi elettronici possonoriprodurre testi, immagini, animazioni o video con o senza suono.

Per una maggiore leggibilità dell’elaborato verranno adottate le seguenti convenzionitipografiche:

∗ gli acronimi, le abbreviazioni e i termini ambigui o di uso non comune menzio-nati vengono definiti nel glossario, situato alla fine del documento;

∗ corsivo per i termini in lingua straniera o facenti parte del gergo tecnico;

∗ grassetto per i termini di particolare rilevanza in un particolare contesto;

∗ font typewriter per identificare i nomi di classi, metodi o file.

iii

Indice

1 Introduzione 11.1 Il progetto di stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Principali problematiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Strumenti utilizzati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Prodotto ottenuto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Organizzazione del testo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Strategia aziendale 52.1 L’azienda ospitante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Generalità e descrizione . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Prodotti e servizi offerti . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Assetto societario e partnership . . . . . . . . . . . . . . . . . . . . 7

2.2 Origine e motivazioni del progetto di stage . . . . . . . . . . . . . . . . . 82.3 Vincoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 Il software open source e l’adozione in azienda . . . . . . . . . . 92.4 Prospettive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5 Il tutor aziendale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6 Pianificazione delle attività di stage . . . . . . . . . . . . . . . . . . . . . . 10

3 Studio del dominio 113.1 Il digital signage: concetti, dinamiche e regole generali . . . . . . . . . . 11

3.1.1 Le tipologie di sistemi . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.2 Generalità sul funzionamento . . . . . . . . . . . . . . . . . . . . . 14

3.2 Il digital signage nel contesto aziendale . . . . . . . . . . . . . . . . . . . 153.2.1 Il sistema in uso in Telerete . . . . . . . . . . . . . . . . . . . . . . 173.2.2 Rivisitazione dei vincoli . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 Definizione del processo di analisi delle soluzioni open source . . . . . 203.3.1 Lo strumento: checklist per la valutazione dell’adeguatezza . . 223.3.2 Dettaglio dei requisiti del sistema di gestione . . . . . . . . . . . 23

4 Ricerca delle soluzioni open source di digital signage 274.1 Metodologia adottata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2 Tecnologie coinvolte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2.1 Oracle VM VirtualBox . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2.2 Ubuntu Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2.3 Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2.4 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

v

vi INDICE

4.2.5 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2.6 Microsoft Windows Server . . . . . . . . . . . . . . . . . . . . . . . 294.2.7 Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2.8 Microsoft .NET Framework . . . . . . . . . . . . . . . . . . . . . . . 294.2.9 ASP.NET MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3 Il software Xibo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3.1 Configurazione del prodotto . . . . . . . . . . . . . . . . . . . . . . 314.3.2 Verifica dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4 Il software Concerto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.4.1 Configurazione del prodotto . . . . . . . . . . . . . . . . . . . . . . 344.4.2 Verifica dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.5 Vodigi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.5.1 Configurazione del prodotto . . . . . . . . . . . . . . . . . . . . . . 374.5.2 Verifica dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.6 Conclusione dell’attività di valutazione . . . . . . . . . . . . . . . . . . . . 40

5 Specifica tecnica del prodotto Xibo 415.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2 Variazione degli obiettivi del progetto di stage . . . . . . . . . . . . . . . 425.3 Il protocollo di comunicazione client-server . . . . . . . . . . . . . . . . . 42

5.3.1 Introduzione ai web service . . . . . . . . . . . . . . . . . . . . . . 425.3.2 Il web service utilizzato in Xibo . . . . . . . . . . . . . . . . . . . . 445.3.3 Esempio di funzionamento . . . . . . . . . . . . . . . . . . . . . . . 45

6 Test del prodotto Xibo 476.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.2 Configurazione dell’ambiente di test . . . . . . . . . . . . . . . . . . . . . 486.3 Descrizione del processo di registrazione del client di test . . . . . . . . 496.4 Pianificazione ed esito dei test . . . . . . . . . . . . . . . . . . . . . . . . . 52

7 Analisi critica del lavoro di stage 597.1 Consuntivo finale e obiettivi raggiunti . . . . . . . . . . . . . . . . . . . . 597.2 Conoscenze acquisite e preparazione accademica . . . . . . . . . . . . . 617.3 Valutazione personale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Glossario 63

Acronimi 67

Bibliografia 69

Elenco delle figure

2.1 Logo di Ne-t by Telerete Nordest srl . . . . . . . . . . . . . . . . . . . . . . 5

3.1 Esempio di sistema stand-alone . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Esempio di sistema web-based . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 Esempio di sistema client-server . . . . . . . . . . . . . . . . . . . . . . . . 14

3.4 Fotografia di un totem multimediale presenti ad Abano Terme . . . . . 16

3.5 Pannello di controllo del gestore palinsesti di Telerete . . . . . . . . . . . 19

4.1 Logo del prodotto Xibo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2 Home page dell’interfaccia di gestione di Xibo . . . . . . . . . . . . . . . 31

4.3 Logo del prodotto Concerto . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.4 Home page dell’interfaccia di gestione di Concerto . . . . . . . . . . . . 34

4.5 Logo del prodotto Vodigi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.6 Home page dell’interfaccia di gestione di Vodigi . . . . . . . . . . . . . . 37

5.1 Schema di funzionamento del web service SOAP . . . . . . . . . . . . . . 44

6.1 Applicazione Xibo Client Options, scheda “Xibo Settings” . . . . . . . . . 50

6.2 Applicazione Xibo Client Options, scheda “Register Display” . . . . . . . 50

6.3 Vista “Display” nel pannello di amministrazione di Xibo . . . . . . . . . 51

6.4 Concessione della licenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.5 Creazione del layout di default . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.6 Definizione del layout Totem_Pedrocchi_noWeb . . . . . . . . . . . . . . . 53

6.7 Definizione del layout Totem_Pedrocchi_noWeb . . . . . . . . . . . . . . . 53

6.8 Esecuzione del Test 8 Totem_Pedrocchi_noWeb . . . . . . . . . . . . . . . . 57

vii

viii ELENCO DELLE TABELLE

Elenco delle tabelle

2.1 Assetto societario di Ne-t by Telerete Nordest Srl . . . . . . . . . . . . . . 7

3.1 Elementi di valutazione dell’adeguatezza della soluzione . . . . . . . . . 223.2 Requisiti funzionali obbligatori . . . . . . . . . . . . . . . . . . . . . . . . . 233.3 Requisiti funzionali desiderabili . . . . . . . . . . . . . . . . . . . . . . . . 253.4 Requisiti funzionali opzionali . . . . . . . . . . . . . . . . . . . . . . . . . . 263.5 Requisiti di qualità desiderabili . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1 Informazioni principali sul prodotto Xibo . . . . . . . . . . . . . . . . . . 304.2 Verifica dei requisiti funzionali obbligatori in Xibo . . . . . . . . . . . . . 324.3 Verifica dei requisiti funzionali desiderabili in Xibo . . . . . . . . . . . . 324.4 Verifica dei requisiti funzionali opzionali in Xibo . . . . . . . . . . . . . . 324.5 Verifica dei requisiti di qualità desiderabili in Xibo . . . . . . . . . . . . . 334.6 Informazioni principali sul prodotto Concerto . . . . . . . . . . . . . . . . 334.7 Verifica dei requisiti funzionali obbligatori in Concerto . . . . . . . . . . 354.8 Verifica dei requisiti funzionali desiderabili in Concerto . . . . . . . . . . 354.9 Verifica dei requisiti funzionali opzionali in Concerto . . . . . . . . . . . 354.10 Verifica dei requisiti di qualità desiderabili in Concerto . . . . . . . . . . 364.11 Informazioni principali sul prodotto Vodigi . . . . . . . . . . . . . . . . . 364.12 Verifica dei requisiti funzionali obbligatori in Vodigi . . . . . . . . . . . . 384.13 Verifica dei requisiti funzionali desiderabili in Vodigi . . . . . . . . . . . 384.14 Verifica dei requisiti funzionali opzionali in Vodigi . . . . . . . . . . . . . 394.15 Verifica dei requisiti di qualità desiderabili in Vodigi . . . . . . . . . . . . 39

6.1 Test 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.2 Test 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.3 Test 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.4 Test 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.5 Test 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.6 Test 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.7 Test 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.8 Test 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7.1 Consuntivazione delle attività di stage . . . . . . . . . . . . . . . . . . . . 59

Capitolo 1

Introduzione

Il presente capitolo introduce il progetto di stage descrivendo brevemente gli obiettivi,le problematiche incontrate, le soluzioni adottate e il prodotto ottenuto. Vieneinoltre presentata l’organizzazione dell’elaborato.

1.1 Il progetto di stage

Lo studio di fattibilità1 è uno degli elementi chiave che costituisce il processo diingegneria dei requisiti. Sia che si tratti di sviluppo di un nuovo prodotto softwareo di un progetto di riutilizzo di un sistema esistente, il processo di ingegneria deirequisiti dovrebbe sempre iniziare con uno studio di fattibilità. L’input dello studioè un insieme di requisiti preliminari definiti dall’azienda, una descrizione generaledel sistema e di come si vuole che supporti i processi aziendali, mentre il risultatodovrebbe essere un rapporto che indica se vale o meno la pena continuare con le fasisuccessive del progetto.

Il progetto di stage, oggetto della discussione nel presente elaborato, consiste nellarealizzazione dello studio di fattibilità finalizzato all’implementazione di un sistemagestionale di digital signage, il quale permette la visualizzazione di palinsesti sudisplay e totem multimediali.

Tale sistema gestionale doveva essere scelto a partire da un insieme di soluzioniesistenti e già disponibili sul mercato, per cui scopo principale dell’esperienza di stageè stato quello di selezionare dal suddetto insieme il prodotto migliore dal punto divista della qualità, in modo da fornire tutti gli elementi di valutazione necessari perconsentire all’azienda di prendere una decisione riguardo alla realizzazione operativadel progetto di adozione.

L’adeguatezza delle soluzioni ricercate è stata valutata secondo criteri semplici ecomprensibili: la copertura delle funzionalità secondo le necessità degli utenti, l’ade-guatezza con le piattaforme hardware e la compatibilità con le piattaforme software

1Ian Sommerville. Ingegneria del software, Ottava edizione. Addison-Wesley, 2007.

1

2 CAPITOLO 1. INTRODUZIONE

facenti parte l’infrastruttura di digital signage dell’azienda, l’usabilità del prodotto ela sua affidabilità. Tali criteri sono stati definiti facendo riferimento agli standard2 chedescrivono i modelli di qualità del software, e anche riferendosi al dominio applicativoe al contesto in cui il prodotto andrebbe ad inserirsi: quello di un’azienda che giàopera nel settore del proximity marketing e che fornisce servizi di segnaletica digitaletramite l’utilizzo di un sistema sviluppato ad-hoc.

1.2 Principali problematiche

Lo stage è sostanzialmente parte di un più ampio progetto che mira al riuso di unasoluzione software esistente.

L’approccio al riuso sta prendendo sempre più piede nelle attività di sviluppo delsoftware; il vantaggio evidente derivante dal riutilizzo del software, ma non l’unico,è la riduzione dei costi di sviluppo: deve essere specificata, progettata, implementatae convalidata un quantità inferiore di componenti.

Tuttavia esistono anche costi e problemi derivanti dall’utilizzo di questo approccio,problemi affrontati durante il lavoro di stage e di seguito descritti.

1. Lo studio di fattibilità per un progetto di riuso si basa sulla valutazione deicosti e dei benefici che questa attività può produrre, quindi è necessario va-lutare sia la fattibilità tecnologica che gli aspetti economici e di mercato. Perquestioni di tempo l’attività di stage ha affrontato gli aspetti riguardanti l’ade-guatezza (tecnologica) delle soluzioni, tralasciando la verifica della convenienzaeconomica.

2. Risulta molto costoso controllare se un componente, o un intero sistema, siaadatto al riutilizzo in una particolare situazione, e testarlo per assicurarnel’affidabilità. É anche vero che la possibilità di accedere al codice sorgentedelle soluzioni ricercate (vedi il capitolo 2.3 - Vincoli) dovrebbe essere sfruttataper realizzare attività di analisi e convalida più approfondite. La soluzioneadottata nei confronti del problema è partita dall’assunzione che i prodottiricercati, data la loro affermata presenza sul mercato delle soluzioni di digitalsignage, godessero già di un grado di affidabilità sufficiente. Sono quindi statipresi in considerazione aspetti riguardanti la copertura delle funzionalità e deirequisiti necessari, effettuando prove dinamiche sulla base di appositi strumentidi controllo definiti in partenza (vedi il capitolo 3.3.1 - Lo strumento: checklistper la valutazione dell’adeguatezza), ed espandendo ulteriormente tali attivitàdefinendo un insieme finito di casi provati sulla soluzione scelta (capitolo 6 -Test del prodotto Xibo).

3. I componenti oggetto del riuso devono essere ricercati, compresi e a volteadattati per lavorare in un nuovo ambiente. A maggior ragione la definizione di

2Sito internet di riferimento per lo standard ISO/IEC 25010:2011 (sostituisce lo standard ISO/IEC9126:2001). URL: http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=35733.

http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=35733


1.3. STRUMENTI UTILIZZATI 3

un progetto di riuso di un intero sistema dovrebbe comprendere l’identificazionedell’architettura del sistema stesso, fino ad arrivare alla specifica delle suecomponenti. Il problema in questo caso può nascere dal fatto che non semprerisulta semplice recuperare le informazioni sull’architettura e il funzionamentodi un sistema sviluppato e mantenuto da terzi. La disponibilità del codicesorgente sicuramente semplifica questa attività, ma il mancato impiego disoluzioni progettuali e architetturali adeguate (adottate durante l’attività disviluppo del software), così come l’assenza di qualunque tipo di documentazionetecnica, può comunque rallentarne seriamente il procedere. L’attività di stageprevedeva questa attività, che però non si è svolta secondo quanto pianificato(vedi il capitolo 5 - Specifica tecnica del prodotto Xibo).

1.3 Strumenti utilizzati

Per la realizzazione del progetto di stage sono stati utilizzati i concetti espressi nelladisciplina dell’ingegneria del software, in modo da ottenere un prodotto finale diqualità e che ne rispettasse i principi. Non sono stati utilizzati strumenti e/o tecnologieparticolari, questo per la tipologia di stage scelto. L’esperienza lavorativa ha permessocomunque di incontrare e valutare, seppur non approfondendo nel dettaglio, lediverse tecnologie adottate dagli sviluppatori per l’implementazione delle soluzionianalizzate, cercando al contempo di comprendere le ragioni di una particolare sceltapiuttosto che di un’altra.

1.4 Prodotto ottenuto

Il prodotto ottenuto dettaglia l’attività di analisi e comprensione del dominio e laverifica dell’adeguatezza delle soluzioni ricercate. Il documento, che nella pratica èriassunto dal presente elaborato, illustra le caratteristiche funzionali e tecniche dellasoluzione scelta e analizza le possibili alternative rispetto alla soluzione individuata.Identifica il software Xibo come il prodotto qualitativamente migliore tra quelli ana-lizzati, ne mette in mostra le peculiarità e ne spiega il funzionamento ad alto livello.Infine, tenta di dimostrarne l’adeguatezza tramite l’analisi della copertura funzionalee dei principali casi di utilizzo.

Dal punto di vista personale e visto l’esito dello studio, si ritiene Xibo un prodottoadeguato e candidato per una futura, possibile adozione e integrazione nelle attivitàe processi aziendali. Per quanto osservato in precedenza, i risultati ottenuti in questaesperienza di stage andrebbero ulteriormente integrati e approfonditi.

4 CAPITOLO 1. INTRODUZIONE

1.5 Organizzazione del testo

Il secondo capitolo descrive il contesto aziendale, il progetto dello stage e i suoiobiettivi prefissati, la pianificazione delle attività di stage.

Il terzo capitolo approfondisce le tematiche e i concetti legati al digital signage,descrive e analizza il contesto aziendale e definisce i processi di verifica utilizzatinell’attività di ricerca e analisi delle soluzioni open source.

Il quarto capitolo descrive nel dettaglio l’attività di ricerca delle soluzioni opensource e ne riporta le conclusioni.

Il quinto capitolo spiega le problematiche affrontate nella realizzazione della speci-fica del sistema selezionato e defunge da introduzione dell’elaborato.scrive illavoro effettuato.

Il sesto capitolo descrive l’attività di test effettuata sul prodotto selezionato.

Nel settimo capitolo viene effettuata un’analisi critica del lavoro di stage.

Capitolo 2

Strategia aziendale

In questo capitolo viene descritto il contesto aziendale, il progetto dello stage, gliobiettivi prefissati e la sua pianificazione.

2.1 L’azienda ospitante

2.1.1 Generalità e descrizione

Figura 2.1: Logo di Ne-t by Telerete Nordest srl

[email protected]

Ne-t by Telerete Nordest Srl è una società di servizi per le telecomunicazioni, l’Informationand Communication Technology (ICT) e le tecnologie per la mobilità urbana.La mission dell’azienda è quella di promuovere e supportare l’impiego delle nuovetecnologie per rendere le città accessibili, sicure e a misura d’uomo. Ne-t svolge daoltre 15 anni attività di progettazione, realizzazione ed esercizio di sistemi integratiper la sicurezza, la sorveglianza, la mobilità, la connettività e l’accesso ai servizi, conspecifica attenzione al cittadino, agli enti e alle aziende dedicati al suo servizio.

5

www.ne-t.it

[email protected]

6 CAPITOLO 2. STRATEGIA AZIENDALE

2.1.2 Prodotti e servizi offerti

Di seguito sono presentate le principali aree di business in cui l’azienda opera e gliannessi servizi offerti:

TelecomunicazioniRealizza reti Intranet/Extranet, soluzioni LAN/MAN/WAN, si dedica alla pro-gettazione tecnica, strutturale e grafica di siti e applicazioni web. Come InternetService Provider (ISP) progetta e implementa soluzioni di connettività utiliz-zando i canali e le tecnologie di comunicazione più adeguate alle esigenze delcliente, fornendo tecnologie wired (xDSL, fibra ottica, ecc.) e wireless (WiFi, Wi-Max, ecc.). Offre inoltre servizi di housing, hosting, security e disaster recoverypresso la propria web farm.

Servizi di web call/contact centerSupporta i propri clienti tramite consulenza, organizzativa e tecnologica, perla messa a punto di strumenti di comunicazione quali call center e web callcenter, centro prenotazioni musei/mostre, infoline (sanzioni amministrative,ZTL, trasporto pubblico ecc.), campagne informative e promozionali, anagrafecanina.

Progetti integratiSviluppa soluzioni software personalizzate, dedicando particolare attenzioneall’implementazione di applicazioni informatiche di supporto alla Pubblica Am-ministrazione e alle aziende. Si dedica alla progettazione e integrazione ditecnologie in ambito urbano: videosorveglianza, ZTL, autovelox e parcheg-gi, sistemi di info-mobilità e gestione delle flotte, sistemi di comunicazioneistituzionale, pagamenti mobile.

Ricerca e sviluppoStudia e progetta nuove tecnologie da impiegare nelle aree di business in cuiopera l’azienda. Ne-t propone, prevalentemente a laureandi, progetti di stageche spaziano tra i settori di informatica, telecomunicazioni, mobilità, marketinged economia.

Ne-t fornisce inoltre servizi di consulenza per ottimizzare i processi organizzativi eservizi a supporto dell’intero ciclo di vita della soluzione adottata, ed è in grado diassicurare assistenza post-vendita e servizi di manutenzione ai clienti in modalità24hx365.L’azienda ha ottenuto la certificazione di qualità secondo le norme Vision 2000(ISO 9001:2000), al fine di garantire ai propri clienti prodotti e servizi di qualità inmiglioramento continuo.

2.1. L’AZIENDA OSPITANTE 7

2.1.3 Assetto societario e partnership

I soci principali di Ne-t by Telerete Nordest Srl sono:

Tabella 2.1: Assetto societario di Ne-t by Telerete Nordest Srl

APS Holding Spa 66,56%

Padova Attiva Srl 13,67%

Etra Spa 10,04%

CVS Spa 5,98%

Camera di Commercio I.A.A. di Padova 3,71%

Acegas-APS Spa 0,03%

Altri 0,01%

Ne-t si avvale della partnership di altre aziende:

Telecom Italia Spa 1 per quanto riguarda gli smart service che rientrano nel pianodi e-government per lo sviluppo di tecnologie ICT innovative, volte a renderepiù efficiente la Pubblica Amministrazione;

Retelit Spa 2 con la quale supporta i propri clienti tramite consulenza, organizza-tiva e tecnologica, per la messa a punto di strumenti di comunicazione qualicall center e web call center, servizi automatici di prenotazione monumenti emanifestazioni;

Infracom Spa 3 con la quale collabora per la fornitura di tecnologie con e senza fili;

Infocert Spa 4 con la quale collabora per la fornitura di soluzioni di firma digitale,posta elettronica certificata, gestione documentale, conservazione sostitutiva efatturazione elettronica;

Fujitsu Technology Solutions 5 con la quale è in grado di offrire prezzi econo-micamente vantaggiosi per il ricambio e l’integrazione delle flotte di perso-nal computer aziendali, riducendo al massimo i costi di acquisto, gestione emanutenzione.

1Sito internet di Telecom Italia Spa. URL: http://www.telecomitalia.com/tit/it/innovation/hot-topics/scenarios/smart-services.html.

2Sito internet di Retelit Spa. URL: http://www.retelit.it/.3Sito internet di Infracom Spa. URL: http://www.infracom.it/it/chi-siamo/profilo.4Sito internet di Infocert Spa. URL: http://www.infocert.it/abouts/view/Profilo_

aziendale.5Sito internet di Fujitsu Technology Solutions. URL: http://www.fujitsu.com/it/about/.

http://www.telecomitalia.com/tit/it/innovation/hot-topics/scenarios/smart-services.html


http://www.retelit.it/

http://www.infracom.it/it/chi-siamo/profilo

http://www.infocert.it/abouts/view/Profilo_aziendale


http://www.fujitsu.com/it/about/


2.2 Origine e motivazioni del progetto di stage

Il progetto nasce dalla necessità di disporre di un sistema che sia in grado di sup-portare, o che si possa adattare rapidamente, a future estensioni e/o modifiche allastrategia d’azienda per quanto riguarda il settore del proximity marketing, più preci-samente nell’ambito del digital signage.Il sistema in uso in Telerete Nordest é stato sviluppato ex-novo internamente all’a-zienda. Come accennato in precedenza, esso è in grado di soddisfare pienamente leesigenze attuali, ma non sarebbe in grado di rispondere positivamente a esigenze escenari futuri. Ulteriori dettagli in questo senso verranno forniti nel prossimo capitolo,si noti comunque che lo scopo non è quello di effettuare una reingegnerizzazione delsistema in uso.

L’obiettivo che ci si propone è quello di invididuare una soluzione che:

∗ possa sostituirsi al sistema utilizzato e permetta quindi all’attuale circuito didigital signage di funzionare in maniera corretta;

∗ sia in grado di adattarsi a future espansioni della rete di segnaletica digitale,e rappresenti quindi il miglior compromesso tra copertura dei requisiti e costinecessari all’implementazione delle funzionalità mancanti.

Il progetto di stage quindi prevede:

∗ lo studio del dominio applicativo, lo studio del sistema attuale, dei vincolitecnologici, delle assunzioni e dei bisogni più o meno esplicitati;

∗ la definizione dei requisiti che il prodotto selezionato dovrà cercare di soddisfare;

∗ la ricerca di prodotti software per il digital signage presenti sul mercato eun’approfondita attività di analisi e di confronto degli stessi, la stesura delrapporto conclusivo dello studio di fattibilità con l’indicazione del prodottomigliore;

∗ lo studio dell’architettura del prodotto selezionato e la stesura del documentodi specifica tecnica;

∗ la pianificazione ed esecuzione di test che siano il più possibile pertinenti ad uncontesto d’utilizzo reale.

2.3 Vincoli

L’azienda non ha posto particolari vincoli per la realizzazione del progetto di stage.Per quanto riguarda l’attività di ricerca dei prodotti presenti sul mercato, il vincoloimposto è che la scelta iniziale debba prendere in considerazione solamente queiprodotti che presentino licenza d’uso di tipo open source.

2.4. PROSPETTIVE 9

2.3.1 Il software open source e l’adozione in azienda

Il termine open source applicato ad una soluzione software si riferisce ad un softwarei cui autori, più precisamente i detentori dei diritti, ne permettono e favoriscono illibero studio e l’apporto di modifiche da parte di sviluppatori indipendenti: questomeccanismo è realizzato tramite l’applicazione di apposite licenze d’uso.

I principali motivi che spingono all’impiego di soluzioni open source sono cosìriassumibili:

∗ l’abbattimento dei costi relativi alle licenze e ad eventuali aggiornamenti deiprodotti. Si tratta del motivo principale, ma non l’unico, che dovrebbe favorirel’attenzione dell’azienda verso questo mondo;

∗ l’utilizzo di consolidati standard di mercato come formati di file e di dati, racco-mandazioni World Wide Web Consortium (W3C), specifiche di interoperabilitàaperte invece che proprietarie e un maggiore allineamento a normative in temadi neutralità tecnologica. In questo modo è auspicabile una maggiore inte-grazione con altri prodotti e soluzioni già utilizzati, anche se commerciali erealizzati da produttori differenti;

∗ il codice sorgente è sottoposto a continue revisioni e miglioramenti da parte diuna solitamente ampia comunità di sviluppatori che agiscono senza scopo dilucro. Ne consegue una maggiore qualità ed efficienza della soluzione;

∗ l’accesso al codice sorgente permette di conoscere in maniera approfondital’infrastruttura e l’architettura utilizzata dall’applicazione, e ne consente inoltrel’estensione, l’implementazione e personalizzazione delle funzionalità in basealle esigenze dell’azienda.

2.4 Prospettive

Una volta completato lo stage, il prodotto raccomandato potrà essere preso in con-siderazione per un’eventuale acquisizione da parte dell’azienda. In tal caso sarànecessario definire e pianificare una opportuna strategia di adozione, in modo chel’introduzione del prodotto nel contesto aziendale avvenga minimizzando i rischiconnessi e senza particolari stravolgimenti.

2.5 Il tutor aziendale

Durante il periodo di svolgimento del progetto di stage il ruolo di tutor aziendale è af-fidato al Dott. Andrea Rampado, che ricopre i ruoli di analista software e sviluppatorepresso Ne-t by Telerete Nordest Srl.


2.6 Pianificazione delle attività di stage

Sulla base di quanto descritto nella sezione 2.2 - Origine e motivazioni del progettodi stage è stato pianificato il piano di lavoro che identificava e definiva le attività dacompletare, in ordine cronologico e con le rispettive tempistiche preventivate. Taliattività vengono riportate di seguito:

STUDIO DEL DOMINIO

- Analisi dell’ambiente operativo, del contesto d’uso e delle problematicheannesse.

- Studio del prodotto aziendale: tecnologie utilizzate e funzionalità imple-mentate. Effettuare una analisi di tipo comparativo tra le caratteristichedel prodotto in uso e le nuove esigenze espresse.

- Sulla base degli studi e delle ricerche sino a qui effettuati, individuare iprincipali fattori su cui si basa la valutazione di adeguatezza delle soluzioniopen source da ricercare.

- Determinare i requisiti del prodotto software ideale. Una volta completatal’identificazione dei requisiti, effettuare la suddivisione degli stessi (funzio-nali, di sistema, di vincolo) e assegnare le priorità (opzioni, desiderabili,obbligatori).

RICERCA DELLE SOLUZIONI OPEN SOURCE

- Analisi e valutazione delle soluzioni open source esistenti: configurazione,studio delle caratteristiche e delle tecnologie utilizzate, valutazione dellacopertura dei requisiti.

- Redazione del rapporto conclusivo in cui si indica la soluzione qualitativa-mente migliore.

SPECIFICA TECNICA

- Studio dell’architettura del prodotto selezionato e stesura del documentodi specifica tecnica.

- Analisi di eventuali implementazioni e correzioni da effettuare sul prodottoselezionato, con annessa stima dei tempi e costi.

TEST

- Definizione e pianificazione dei test.

- Configurazione dell’ambiente di prova.

- Configurazione, installazione e test del prodotto in un contesto operativoe di utilizzo reali.

Capitolo 3

Studio del dominio

L’analisi del dominio è una della attività che costituiscono l’analisi e concorrono alladefinizione delle specifiche di un sistema.Lo scopo dell’analisi del dominio è quello di comprendere a fondo i concetti, ledinamiche, le regole generali che definiscono il dominio applicativo in cui il sistemasoftware dovrà essere impiegato, ovvero il cui software dovrà agire. Normalmentel’analisi del dominio precede l’analisi dei requisiti, poiché solo avendo compreso afondo il contesto in cui il sistema dovrà operare è possibile stabilire quali siano lecaratteristiche che il sistema deve esibire per integrarsi in quel contesto in modo piùefficace.

3.1 Il digital signage: concetti, dinamiche e regolegenerali

Il digital signage1, anche nota in Italia come segnaletica digitale, è una forma dicomunicazione di prossimità i cui contenuti vengono veicolati ai destinatari tramitedisplay elettronici, videoproiettori e totem multimediali strategicamente posizionatiin luoghi pubblici, nei punti vendita o all’interno di edifici.

Il contenuto mostrato sui display può spaziare dal semplice testo ad immaginistatiche, arrivando fino a video con o senza audio. É possibile creare contenutiaudiovisivi multimediali, da semplici bacheche a scorrimento orizzontale fino a videoposter che appariranno sui display trasformandosi in comunicazioni qualitativamenteparagonabili a quelle televisive.

I contenuti possono essere gestiti da programmi applicativi, attraverso un personalcomputer o altre apparecchiature, permettendo al singolo o al gruppo di lavoro unamodifica veloce ed efficiente.

Rispetto alle forme tradizionali di pubblicità e informazione, il digital signage presentadiversi vantaggi:

1Digital Signage su Wikipedia. URL: http://it.wikipedia.org/wiki/Digital_signage.

11

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

12 CAPITOLO 3. STUDIO DEL DOMINIO

∗ trasforma spazi dal contenuto statico in un flusso di informazioni dinamichefacilmente modificabile e adattabile a diverse tipologie di impiego;

∗ garantisce un miglior rapporto qualità/prezzo rispetto ai tradizionali cartellonipubblicitari;

∗ introduce il concetto di multimedialità dell’informazione, permettendo di com-binare diversi tipi di media e organizzarli nello spazio a disposizione secondonecessità;

∗ consente una comunicazione diretta e mirata, in grado di adeguarsi alle carat-teristiche dell’ambiente in cui viene diffusa così come ai suoi destinatari.

Il digital signage può essere utilizzato per molteplici scopi:

∗ informativi, ad esempio fornendo informazioni sui voli, sulle condizioni mete-reologiche o sui tempi di attesa nel caso di utilizzo dei trasporti pubblici;

∗ promozionali, ad esempio fornendo informazioni sui prodotti, i saldi, le offertee le promozioni in corso all’interno di negozi o centri commerciali;

∗ enfatizzare l’esperienza del cliente, per esempio in un ristorante attraverso ladimostrazione della preparazione di una ricetta;

∗ influenzare il comportamento del cliente, ad esempio orientandolo verso areedifferenti di un centro commerciale.

3.1.1 Le tipologie di sistemi

A seconda del grado di distribuzione e delle tecnologie utilizzate, si distinguono treprincipali tipologie di soluzioni. Da questo punto in poi si assume come soluzione diriferimento l’architettura client-server, la quale viene brevemente presentata in 3.1.1 -Soluzione client-server.

Soluzione stand-alone

La messa in opera di questa soluzione è molto semplice, come mostrato in Figura 3.1:consiste di un display e di un riproduttore multimediale (si tratta generalmente di unpersonal computer) che permette il controllo dei contenuti visualizzati sul display. Ilcomputer non è collegato ad alcuna rete. Nuovi contenuti possono essere inseriti nelsistema tramite l’utilizzo di periferiche di archiviazione removibili (ad esempio, unapenna USB).

Un sistema stand-alone di digital signage è in grado di riprodurre e visualizzarecontenuti in base ad un palinsesto nella sostanza di tipo statico: i contenuti caricatisono fissati, a meno che l’amministratore non si presenti caricandone degli altri.

3.1. IL DIGITAL SIGNAGE: CONCETTI, DINAMICHE E REGOLE GENERALI 13

Figura 3.1: Esempio di sistema stand-alone

Soluzione web-based

In questa tipologia di soluzione (vedi Figura 3.2), i contenuti visualizzati su un displaypossono essere facilmente gestiti dall’amministratore che sia in grado di accedere,anche per via remota, al computer responsabile della riproduzione sul suddettodisplay.

Figura 3.2: Esempio di sistema web-based

Si tratta di una soluzione scalabile, dato che la riproduzione dei contenuti vieneeseguita localmente permettendo così a ciascun display di visualizzare informazionispecifiche.


Soluzione client-server

Questa soluzione (vedi Figura 3.3) prevede la presenza di un server centrale cheorganizza, gestisce e distribuisce i contenuti ai riproduttori multimediali (i client)facenti parte del sistema.

L’amministratore è in grado di accedere tramite browser web all’interfaccia digestione, la cui applicazione è installata sul server, anche in collegamento remoto.Questo approccio è particolarmente adatto nel caso in cui il sistema sia composto daun ampio numero di display geograficamente distribuiti, e che non necessariamentevisualizzano le stesse tipologie di contenuti.

I contenuti multimediali, così come le informazioni relative ai palinsesti e ai clinetsolitamente vengono gestisti all’interno di un database. L’interfaccia di gestioneconsente il recupero e la manipolazione delle informazioni in maniera semplice etrasparente all’utente amministratore.

Figura 3.3: Esempio di sistema client-server

3.1.2 Generalità sul funzionamento

Il digital signage si è sviluppato a partire dagli anni ’70, dove video preregistrativenivano proiettati mediante l’utilizzo di videoregistratori e televisori disposti neisingoli punti vendita. La forma odierna permette invece di scegliere la rete Internetcome mezzo di distribuzione dei contenuti pubblicitari e informativi, in abbinamentoa soluzioni software e hardware per la gestione del processo.

Come accennato in precedenza una soluzione client-server di digital signage è compo-sta da vari elementi, software e hardware, che consentono di predisporre i contenutie di pianificare la loro distribuzione e visualizzazione sulla rete di display.

3.2. IL DIGITAL SIGNAGE NEL CONTESTO AZIENDALE 15

Il processo complessivo può essere suddiviso in tre fasi distinte: la gestione deicontenuti, la distribuzione degli stessi alle periferiche e, infine, la visualizzazionesulla rete di display.

Attraverso l’applicazione centralizzata è possibile aggiornare e variare i contenuti diqualsiasi display e personalizzare, in qualsiasi momento, le informazioni visualizzatesu ogni singolo display o gruppo di display distribuiti sul territorio. L’aggiornamentopuò avvenire in tempo reale oppure può essere pianificato in anticipo mediante ladefinizione dei palinsesti.

Il software di gestione dei contenuti permette la creazione di layout, in modo dasuddividere l’area del display in più settori e, per ognuno di essi, programmare lavisualizzazione di un contenuto differente. É pertanto possibile che informazioniprovenienti da sorgenti multimediali completamente diverse fra di loro vengano vi-sualizzate simultaneamente. Al termine della fase di composizione delle informazionicomplessive da visualizzare, il contenuto così creato viene salvato e reso disponibileper la distribuzione.

I contenuti creati vengono associati al singolo display, o a gruppi di display, e aduna specifica programmazione, in modo da definire i giorni della settimana e gli oraridi visualizzazione, formando così un palinsesto. Il server trasferisce i contenuti aivari display che fanno parte della rete di digital signage tramite una connessioneHyperText Transfer Protocol (HTTP).

Solitamente l’applicativo di gestione consente pure il monitoraggio dell’impianto,tramite cui è possibile visualizzare lo stato di aggiornamento della rete di displayin termini di palinsesti, evidenziando eventuali anomalie rilevate durante l’invio diquesti ultimi.

3.2 Il digital signage nel contesto aziendale

La soluzione adottata in Ne-t by Telerete Nordest Srl è di tipo client-server. La retedi digital signage consta di un singolo server, collocato nella web farm dell’azienda,mentre i client si diversificano in totem multimediali e display (entrambi aventiriproduttori multimediali incorporati).

I totem multimediali (Figura 3.4), sette in totale, sono dislocati in aree differenti:due agli ingressi dello storico Caffè Pedrocchi, uno dei luoghi simbolo della città diPadova; uno all’esterno in Piazza Garibaldi; quattro presenti nella zona pedonale diAbano Terme, comune della provincia di Padova. I 32 monitor sono invece collocatialle pensiline delle fermate del tram che attraversa la città.

La comunicazione tra i client e il server avviene sfruttando la rete in fibra otticagià presente a Padova e utilizzando la tecnologia WiFi: il tutto consente di distribuiree diffondere servizi audio (come musica, messaggi radiofonici) oppure video (comefilmati, notiziari, trasmissioni di eventi che si svolgono in altre zone della città).

I totem e i display vengono utilizzati per veicolare:

∗ informazioni sui servizi erogati dal comune e/o dalla provincia in cui sonodislocati;


Figura 3.4: Fotografia di un totem multimediale presenti ad Abano Terme

∗ informazioni di tipo pubblicitario e promozionale;

∗ notizie di pubblica utilità, quali: traffico, andamento della borsa, previsionimetereologiche, eventi programmati, ecc.;

Per la visualizzazione dei palinsesti vengono utilizzati due layout differenti, cia-scuno associato ad una tipologia di display:

Totem multimediali - risoluzione 768 x 1366 pixel, rapporto d’aspetto 9:16

- area dedicata ai contenuti pubblicitari: 768 x 1024 pixel, rapporto diaspetto 3:4

- area dedicata alla visualizzazione di un pagina web/feed RSS: 768 x 342pixel

Monitor tram - risoluzione 1080 x 1920 pixel, rapporto di aspetto 9:16

- area dedicata alle previsioni di arrivo del tram: 1080 x 488 pixel

- area dedicata ai contenuti pubblicitari: 1080 x 1200 pixel, rapporto diaspetto 9:10

- area dedicata alla visualizzazione di una pagina web/feed RSS: 1080 x232 pixel


3.2.1 Il sistema in uso in Telerete

L’applicazione sviluppata è un software 100% web based erogato in modalità Softwareas a Service (SaaS). Comprende il servizio di hosting applicativo presso il data centerdi Ne-t by Telerete Nordest, e la realizzazione di un sistema di regia centralizzatoaccessibile tramite connessione Internet o Intranet che permette la distribuzione dicontenuti multimediali.

Tecnologie utilizzate e architettura del sistema

L’architettura realizzata è di tipo client-server. Il server è composto da una applica-zione web gestionale basata sui framework Spring2, Hibernate3, JAXB24, linguaggioXSLT5 e due web service (per approfondimenti, vedi il capitolo 5.3.1 - Introduzioneai web service) che permettono l’autenticazione, lo scaricamento e l’aggiornamentodei palinsesti da parte dei display (client).

Il sistema gestisce i formati di immagine più conosciuti, pagine HTML locali e remote,filmati e feed RSS. Il sistema è stato realizzato in modo modulare, le tipologie dicontenuti multimediali da distribuire sono implementate da componenti Java indi-pendenti che si occupano della generazione automatica dei file e del codice da inviareai client appartenenti al sistema informativo.

Il client è un applicativo Java che si occupa di effettuare giornalmente le richieste discaricamento completo del palinsesto ed esegue ogni minuto l’eventuale scaricamentodegli aggiornamenti. Le funzionalità relative alla visualizzazione dei contenuti deldisplay sono delegate al browser web installato sul dispositivo. I contenuti vengonoscaricati in formato compresso per permettere un uso inferiore della banda e miglio-rare le performance del sistema.

Il gestionale realizzato è un sistema di regia che può gestire contenuti multimedialidi tipo immagine e video. I contenuti multimediali che successivamente possonoessere impiegati per la definizione dei palinsesti vengono inseriti all’interno di unarchivio remoto sempre accessibile, questo per facilitare e accelerare l’inserimentodei palinsesti stessi.L’organizzazione che è stata scelta è quella classica del palinsesto televisivo: perpianificare la trasmissione di un contenuto è necessario specificare la data e l’oradi inizio trasmissione e la data e l’ora di fine trasmissione. Questa struttura è statascelta in quanto base per tutti i generi di gestione legati al tempo. Il sistema permettedi specificare un palinsesto differente per raggruppamento di monitor. Il sistema èin grado di distribuire correttamente i contenuti in quanto tutti i client effettuanoun’autenticazione prima di scaricare il palinsesto.

2Sito internet di riferimento per la tecnologia Spring. URL: http://www.springsource.org/.3Sito internet di riferimento per la tecnologia Hibernate. URL: http://www.hibernate.org/.4Sito internet di riferimento per la tecnologia JAXB. URL: http://jaxb.java.net/.5Sito internet di riferimento per la tecnologia XSLT. URL: http://www.w3.org/TR/xslt.

http://www.springsource.org/

http://www.hibernate.org/

http://jaxb.java.net/

http://www.w3.org/TR/xslt


Funzionalità dell’interfaccia di gestione

L’utente può accedere alle seguenti sezioni principali:

∗ il pannello di controllo, che permette la gestione dei palinsesti relativi ai gruppidi display;

∗ la gestione dell’archivio, che visualizza l’archivio dei contenuti caricati e nepermette l’inserimento;

∗ la sezione amministrazione, che permette l’accesso al logging delle operazioni,la creazione di account multipli per l’utilizzo del gestionale e l’abilitazione deisistemi informativi alla ricezione dei palinsesti.

Il pannello di controllo, come si può vedere in Figura 3.5 è progettato come unainterfaccia a schede, che permette innanzitutto di selezionare il gruppo su cui sivogliono effettuare le modifiche.

Una volta selezionato il gruppo viene automaticamente visualizzato il relativopalinsesto: è una tabella nella quale vengono indicati i contenuti multimediali pro-grammati, ciascuno con il proprio ordine di riproduzione, una data di inizio e unadata di fine riproduzione, e la durata (che corrisponde al numero di secondi in cui ilcontenuto viene mostrato). É possibile caricare un contenuto esistente (già presentenell’archivio) e inserirlo nel palinsesto, così come è possibile eliminare un contenutoprogrammato. La pubblicazione del palinsesto modificato avviene tramite la pressionedell’apposito pulsante.

Il pannello di gestione dell’archivio visualizza in forma tabellare i contenuti inseriti,e le relative informazioni associate: categoria, altezza e larghezza, durata, creatoree data di creazione (inserimento). Per inserire un nuovo contenuto nell’archivio ènecessario selezionare la tipologia (immagine o video), specificarne il nome, la duratae le dimensioni (altezza e larghezza in pixel).

Il contenuto è successivamente modificabile, nel senso che è possibile sostituirel’elemento multimediale senza andare a modificare le informazioni: questo consenteun aggiornamento diretto di tutti i palinsesti che lo hanno in programma, senzaandare ad effettuare la opportune modifiche su ciascuno di essi.

I limiti del sistema

L’interfaccia di gestione è limitata alle funzionalità descritte in precedenza, di conse-guenza per tutto il resto si deve intervenire mettendo mano al codice dell’applicativo.Ad esempio, per far sì che si possa gestire un nuovo gruppo di monitor tramite l’in-terfaccia grafica fornita, è necessario effettuare le seguenti modifiche a livello dicodice:

∗ creazione del gruppo;

∗ associazione del monitor al gruppo;

∗ modifica dell’interfaccia di gestione per visualizzare del nuovo gruppo inserito;


Figura 3.5: Pannello di controllo del gestore palinsesti di Telerete

∗ modifica del controller dei palinsesti per creare pacchetti di aggiornamento peri display differenziati per gruppo;

∗ modifica del web service che permette lo scaricamento dei palinsesti, in mododa identificare a partire dalla login o dal token: il monitor, il gruppo e quindi ilpacchetto di aggiornamenti corretto.

Anche eventuali modifiche ai layout dei palinsesti richiederebbero interventi e modifi-che sul software.

3.2.2 Rivisitazione dei vincoli

Sulla base delle informazioni acquisite, dapprima durante lo studio introduttivo suldigital signage, e in seguito durante l’analisi del sistema utilizzato in azienda, sonostati rivisti i vincoli precedentemente presentati nella sezione 2.3 - Vincoli.

La scelta iniziale dovrà quindi prendere in considerazione solamente quei prodottiche soddisfano i seguenti requisiti:

∗ il prodotto deve presentare licenza d’uso di tipo open source;

∗ l’architettura del sistema deve essere di tipo client-server, con il server chepermette la gestione centralizzata dei contenuti e dei palinsesti. L’applicazione


di gestione deve essere erogata in modalità di Software as a Service (SaaS),con hosting da effettuare presso i web server dell’azienda;

∗ il gestionale deve essere accessibile e fruibile da browser web attraverso la reteInternet;

3.3 Definizione del processo di analisi delle soluzioniopen source

Se la ricerca di soluzioni che soddisfano i vincoli appena presentati ha avuto successo,è necessario avviare un’analisi di tipo comparativo tra le caratteristiche di ciascunasoluzione individuata e le esigenze dell’azienda, in modo da poter quantificare in chemisura ciascuna soluzione risponda a tali esigenze.Innanzitutto sono stati individuati i tre principali fattori che influenzano in manierapiù o meno decisiva il processo di valutazione6. Si distinguono:

∗ i fattori applicativi;

∗ i fattori tecnologici;

∗ le caratteristiche di qualità dell’applicazione;

Fattori applicativi

Il principale fattore di carattere applicativo che condiziona la selezione del software èla copertura funzionale: tale fattore indica il livello di copertura dei requisiti indivi-duati da parte delle funzioni messe a disposizione dall’applicazione. É indubbiamenteuno dei fattori di maggior peso ai fini della valutazione di adeguatezza della soluzione.In fase di definizione delle esigenze è necessario che l’azienda indichi in manierachiara ed esplicita le funzioni applicative di cui vuole disporre, precisandone anche lapriorità.

Per condurre efficacemente l’analisi della copertura funzionale è necessario sceglierein modo adeguato il livello di definizione delle funzioni. Un eccessivo livello diastrazione può infatti condurre ad una analisi superficiale della copertura funzionale,così come un livello troppo dettagliato può richiedere tempi inaccettabili in fase distudio iniziale.

6CNIPA (Centro Nazionale per l’Informatica nella Pubblica Amministrazione). Linee guida per ilriuso delle applicazioni informatiche nelle Amministrazioni pubbliche. URL: http://www2.cnipa.gov.it/site/it-it/Attivit%C3%83%C2%A0/Riusabilit%C3%83%C2%A0_del_software_nella_PAC/Metodologia/Linee_guida_per_un_progetto_di_riuso/.

http://www2.cnipa.gov.it/site/it-it/Attivit%C3%83%C2%A0/Riusabilit%C3%83%C2%A0_del_software_nella_PAC/Metodologia/Linee_guida_per_un_progetto_di_riuso/



3.3. DEFINIZIONE DEL PROCESSO DI ANALISI DELLE SOLUZIONI OPEN SOURCE21

Fattori tecnologici

I fattori di carattere tecnologico misurano l’eventuale impatto che può avere l’adozio-ne della nuova soluzione selezionata sulle infrastrutture dell’azienda.

É necessario verificare l’adeguatezza e la compatibilità delle piattaforme esisten-ti, sia hardware che software. A questo proposito vengono di seguito elencate lecaratteristiche dei dispositivi client utilizzati da Telerete Nordest:

∗ processore Intel Atom N270, 1.6 Ghz;

∗ memoria RAM DDR2, massimo 2 GB;

∗ porta Ethernet 10/100/1000Base-TX, due porte RJ-45;

∗ sistema operativo installato: Windows XP Embedded;

∗ sistemi operativi supportati: Windows 7, Linux;

Importante è quindi la verifica della compatibilità dell’applicativo client su sistemaoperativo Windows XP Embedded.

Le caratteristiche di qualità dell’applicazione

Questi fattori misurano la qualità dell’applicativo. La differenza concettuale con ifattori descritti precedentemente risiede nel fatto che i fattori di qualità sono intrinse-camente legati al prodotto e sostanzialmente indipendenti dal contesto in cui vieneutilizzato.

Una delle caratteristiche più evidenti in un software di qualità è certamente il grado diaffidabilità. Una definizione di affidabilità è la seguente: l’affidabilità (reliability) èla probabilità che il software esegua operazioni senza guasti (failure) in un ambientestabilito per un intervallo di tempo stabilito.

L’affidabilità è legata alla presenza e distribuzione dei malfunzionamenti, allacapacità di mantenere livelli predeterminati di prestazioni anche in presenza dimalfunzionamenti o utilizzi scorretti del prodotto, alla capacità di ripristino delprodotto e di recupero delle informazioni rilevanti.Altra caratteristica di un software di qualità è la buona usabilità, intesa come grado dicomprensibilità dei concetti del prodotto, come facilità relativa al suo apprendimento,come intuitività e semplicità di utilizzo. Può essere valutata ad esempio sulla basedella presenza, del livello di aggiornamento e della qualità della documentazionetecnica dell’applicazione.


3.3.1 Lo strumento: checklist per la valutazione dell’adeguatez-za

La valutazione di adeguatezza delle soluzioni ricercate si baserà sull’analisi dei fattoriprecedentemente elencati. A ciascun fattore viene associato un peso su una scala divalutazione, e una o più metriche. La Tabella 3.1 riporta il riepilogo dei fattori davalutare ai fini dell’adeguatezza delle soluzioni ricercate, ne fornisce una indicazionedi rilevanza e ne indica le metriche.

Tabella 3.1: Elementi di valutazione dell’adeguatezza della soluzione

Fattore Tipologia Rilevanza Descrizione Metriche

Coperturafunzionale

Applicativo Molto alta Livello di coperturadei requisiti

% di requisitisoddisfatti

Adeguatezzapiattaformehardware

Tecnologico Media Indica la misura in cuipossono essere utiliz-zate le piattaforme esi-stenti per la soluzioneselezionata

Livello di riutilizzodelle piattaformeesistenti (si vedanole caratteristiche deiclient)

Compatibilitàpiattaformesoftware

Tecnologico Media Indica la misura in cuipossono essere utiliz-zati gli ambienti e lelicenze esistenti

Livello di riutilizzodelle infrastrutturesoftware esistenti

Affidabilità Qualità Media La probabilità che ilsoftware esegua ope-razioni senza guasti inun ambiente stabilitoper un intervallo ditempo stabilito

Rispondenza dell’af-fidabilità dichiarataalle proprie esigenze

Usabilità Qualità Alta Grado di comprensibi-lità del prodotto

Disponibilità e quali-tà della documenta-zione tecnicaDisponibilità e quali-tà della documenta-zione per la formazio-ne


3.3.2 Dettaglio dei requisiti del sistema di gestione

Sono riportati nelle Tabella 3.2, Tabella 3.3, Tabella 3.4, Tabella 3.5 i requisiti delsistema di gestione. Per identificare univocamente i requisiti si utilizzano degliidentificativi che seguono il seguente schema:

TipoPriorità-ID

dove

Tipo è il tipo di requisito e va scelto tra:

- Fx: requisito funzionale dove x identifica uno dei seguenti sotto-requisiti:

– F: funzioni– D: dati

- Qx: requisito di qualità dove x identifica uno dei seguenti sotto-requisiti:

– U: usabilità– P: portabilità– E: estendibilità

Priorità :

- OB: obbligatorio

- DE: desiderabile

- OP: opzionale

ID : un identificativo numerico.

Requisiti funzionali

Tabella 3.2: Requisiti funzionali obbligatori

Codice Descrizione requisito

FFOB-1 Il sistema deve fornire funzionalità per la gestione deicontenuti. L’utente deve essere in grado di:- visualizzare l’elenco dei contenuti caricati nella libreria;- caricare un nuovo contenuto nella libreria;- eliminare un contenuto presente nella libreria;- modificare il contenuto, in particolare poter sostituirel’elemento multimediale.


FDOB-1 Il sistema deve gestire i seguenti contenuti:- formati immagine: JPEG (estensione .jpg), GIF (esten-sione .gif)- formati video: Flash Video (estensione .flv), MPEG-4(estensione .mp4)- pagine HTML locali, pagine HTML remote, feed RSS.

FFOB-2 Il sistema deve fornire funzionalità per la gestione deilayout.L’utente deve essere in grado di:- visualizzare l’elenco dei layout creati;- definire un nuovo layout specificandone le dimensioni;- eliminare un nuovo layout precedentemente inserito;- modificare il layout selezionato e le informazioni ad essoassociato.

FFOB-3 Il sistema deve fornire uno strumento per la progettazionedei layout.L’utente deve essere in grado di:- visualizzare l’aspetto grafico del layout selezionato;- inserire un contenuto presente in libreria all’interno dellayout;- eliminare un contenuto inserito in precedenza;- gestire posizione e dimensione di ciascun contenutoinserito.

FFOB-4 Il sistema deve fornire funzionalità per la gestione deiclient.L’utente deve essere in grado di:- visualizzare l’elenco dei client connessi;- aggiungere un nuovo dispositivo client;- eliminare un dispositivo client aggiunto in precedenza;- modificare le informazioni associate al dispositivo clientselezionato.

FFOB-5 Il sistema deve fornire funzionalità per la gestione di grup-pi di dispositivi client.L’utente deve essere in grado di:- visualizzare l’elenco dei gruppi creati;- aggiungere un nuovo gruppo di client;- gestire i client appartenenti al gruppo selezionato;- eliminare un gruppo di client aggiunto in precedenza;- modificare le informazioni associate al dispositivo clientselezionato.


FFOB-6 Il sistema deve fornire funzionalità per la gestione deipalinsesti.L’utente deve essere in grado di:- visualizzare l’elenco dei palinsesti programmati;- aggiungere un nuovo palinsesto;- eliminare un palinsesto aggiunto in precedenza;- modificare il palinsesto selezionato e le informazioni adesso associate;- assegnare un palinsesto a client e gruppi di client e pia-nificarne l’esecuzione;- rimuovere un palinsesto assegnato in precedenza a cliente gruppi di client.

FFOB-7 Il sistema fornisce funzionalità per la gestione degli utenti:- visualizzazione della lista degli utenti che possono acce-dere al sistema;- creazione di un nuovo utente;- definizione e modifica dei permessi assegnati all’utenteselezionato;- eliminazione di un utente creato in precedenza.

FFOB-8 Il sistema fornisce funzionalità per la gestione di gruppidi utenti:- visualizzazione dei gruppi di utenti creati;- creazione di un nuovo gruppo di utenti;- definizione e modifica dei permessi assegnati al grupposelezionato;- gestione degli utenti appartenenti al gruppo selezionato;- eliminazione di un gruppo creato in precedenza.

Tabella 3.3: Requisiti funzionali desiderabili


FFDE-1 Il sistema fornisce funzionalità per il reperimento e la visualizzazionedi informazioni sullo stato dei client.

FFDE-2 Il sistema offre funzionalità per la gestione di modelli di layout.L’utente deve essere in grado di:- visualizzare i modelli creati;- creare un layout a partire da un modello esistente;- creare un nuovo modello di layout;- eliminare un modello di layout creato in precedenza.


Tabella 3.4: Requisiti funzionali opzionali


FFOP-1 Il sistema offre funzionalità per la gestione remota dei client e gruppidi client.

Requisiti di qualità

Tabella 3.5: Requisiti di qualità desiderabili


QUDE-1 L’interfaccia è internazionalizzata (in particolare, è disponibile lalocalizzazione in lingua italiana).

QUDE-2 E’ fornito un manuale d’uso o un help contestuale che faciliti lacomprensione dell’interfaccia da parte dell’utente.

QUDE-3 Sono disponibili funzionalità per la ricerca di oggetti all’interno diuna pagina.

Capitolo 4

Ricerca delle soluzioni open source didigital signage

In questo capitolo viene descritta dettagliatamente l’attività di ricerca ed analisi deiprodotti di digital signage che soddisfano i vincoli descritti nei capitoli precedenti.

4.1 Metodologia adottata

La procedura adottata richiede innanzitutto l’installazione e configurazione di ciascunprodotto da valutare, che a sua volta include la verifica dei requisiti hardware esoftware necessari per il funzionamento delle componenti client e server. In seguito siprocede con la verifica dei requisiti definiti nel capitolo 3.3.2 - Dettaglio dei requisitidel sistema di gestione.

4.2 Tecnologie coinvolte

4.2.1 Oracle VM VirtualBox

Oracle VM VirtualBox è un software di virtualizzazione per sistemi con architettura a32 e a 64 bit che nel corso degli anni ha ottenuto il favore del pubblico soprattuttograzie al fatto di essere una delle poche soluzioni di livello professionale ad essererilasciata a titolo gratuito.

Sviluppato inizialmente da Innotek, ed in seguito portato avanti prima da SunMicrosystem e successivamente da Oracle, VirtualBox permette di creare macchinevirtuali che operano in modo indipendente rispetto al sistema ospitante e possono es-sere utilizzate per gli scopi più disparati; è ad esempio possibile utilizzare le macchinevirtuali per la realizzazione di ambienti di testing o di sviluppo pronti all’uso.

VirtualBox supporta Windows, GNU/Linux e Mac OS X come sistemi operativi host,ed è in grado di eseguire Windows, GNU/Linux, OS/2 Warp, BSD come ad esempio

27

28CAPITOLO 4. RICERCA DELLE SOLUZIONI OPEN SOURCE DI DIGITAL SIGNAGE

OpenBSD, FreeBSD e infine Solaris e OpenSolaris come sistemi operativi guest.

La versione utilizzata è la 4.3.0.

4.2.2 Ubuntu Server

Ubuntu Server Edition è una versione del noto sistema operativo Linux e basato suDebian utilizzato in ambito server. Le caratteristiche:

∗ performante: è progettato per i server aziendali, ogni suo singolo elemento èprogrammato per integrarsi alla perfezione sulla macchina ospitante;

∗ sicuro: ad installazione completata Ubuntu Server non presenta alcuna portaaperta verso l’esterno e contiene solo il software necessario per un server sicuro;

∗ integrato: permette l’autenticazione da qualsiasi sistema client che sia Linux,Mac OS o Windows.

La versione utilizzata è la 12.04 LTS.

4.2.3 Apache

L’httpd server di Apache Software Foundation (chiamato anche semplicemente Apa-che), costituisce il software più diffuso nell’ambito dei web server. Lo sviluppo, iniziatonel 1994, ha trasformato un progetto embrionale, nato presso l’NCSA, nel migliorweb server oggi a disposizione.

Alcune delle caratteristiche principali sono:

∗ funzionamento in una moltitudine di sistemi operativi;

∗ tecnologia libera, che permette la contribuzione della comunità allo sviluppo eal bugfixing;

∗ approccio modulare alle estensioni, che consente il supporto a numerosissimilinguaggi di programmazione;

∗ altissima configurabilità, sia delle funzioni di base, sia dei moduli.

La versione utilizzata è la 2.2.

4.2.4 MySQL

Mysql è il database relazionale open source più diffuso. Otto tra i primi dieci siti webpiù visitati al mondo, tra cui Google, utilizzano MySQL.

Alcune tra le sue caratteristiche principali, che ne hanno decretato la massimadiffusione, sono:

∗ portabilità;

4.2. TECNOLOGIE COINVOLTE 29

∗ scalabilità garantita dall’uso di thread e dal supporto di più processori;

∗ semplicità d’uso;

∗ licenza libera.


4.2.5 PHP

PHP (acronimo ricorsivo di “PHP: Hypertext Preprocessor”) è un linguaggio di pro-grammazione interpretato, originariamente concepito per la programmazione dipagine web dinamiche.

Oggi è principalmente utilizzato per interrogare un database e di interfacciare unapagina Web con i dati in esso contenuti. Una delle soluzioni che si sono imposte persemplicità di utilizzo, qualità del codice, diffusione è l’accoppiata con MySQL.


4.2.6 Microsoft Windows Server

Windows Server rappresenta il marchio di una linea di sistemi operativi per sistemiserver rilasciato da Microsoft Corporation. Le caratteristiche:

∗ supporta tutte le tecnologie web più recenti;

∗ maggiori performance grazie alle ottimizzazioni in tempo reale;

∗ le ultime versioni supportano le tecnologie di cloud computing.

La versione utilizzata è la 2012.

4.2.7 Microsoft SQL Server

SQL Server è il database relazionale prodotto da Microsoft. Fornisce funzionalità dilivello aziendale e di semplice uso per la gestione dei dati di una vasta gamma diapplicazioni di database, con tempi di attività e livelli di sicurezza affidabili.


4.2.8 Microsoft .NET Framework

Il .NET Framework è la parte centrale della tecnologia .NET di Microsoft. È l’ambienteper la creazione, la distribuzione e l’esecuzione di tutti gli applicativi che supportano.NET siano essi servizi web o altre applicazioni.

La versione utilizzata è la 3.5.1.


4.2.9 ASP.NET MVC

Si tratta di un framework sviluppato da Microsoft e utilizzato per la creazione diapplicazioni web.


4.3 Il software Xibo

Figura 4.1: Logo del prodotto Xibo

Tabella 4.1: Informazioni principali sul prodotto Xibo

Sito web ufficiale http://xibo.org.uk

Tipo di licenza open source GNU AGPL v31

Versione analizzata 1.4.2

Tecnologia lato server PHP e MySQL su server Apache

Tecnologia lato client .NET Framework

Xibo è una soluzione open source per il digital signage, che permette la gestionecentralizzata tramite un pannello di amministrazione accessibile da browser web(vedi Figura 4.2), ed è distribuita su una rete locale o rete Internet verso uno o piùclient connessi ad un dispositivo di visualizzazione.

L’applicativo server è utilizzato per l’upload dei contenuti, la realizzazione di layout,la definizione dei palinsesti e la programmazione degli stessi su uno o più display,oltre a varie funzioni di tipo amministrativo.Ciascuno dei client facenti parte del sistema può avere il suo personale palinsesto,con il relativo layout e gli annessi contenuti multimediali. L’applicativo si occupadi effettuare le richieste di scaricamento completo del palinsesto ed esegue ad ogniintervallo di tempo prestabilito lo scaricamento degli aggiornamenti. É inoltre previstoun meccanismo di caching dei palinsesti, in modo che il client riesca a riprodurre icontenuti anche in assenza di collegamento di rete.

1Sito internet di riferimento per la licenza GNU AGPL v3. URL: http://www.gnu.org/licenses/agpl-3.0.html

http://xibo.org.uk

http://www.gnu.org/licenses/agpl-3.0.html


4.3. IL SOFTWARE XIBO 31

Figura 4.2: Home page dell’interfaccia di gestione di Xibo

4.3.1 Configurazione del prodotto

Componente server

∗ Creazione di una macchina virtuale tramite VirtualBox, ed installazione delsistema operativo guest Ubuntu Server 12.04 LTS

∗ installazione del server LAMP (Apache+MySQL+ PHP) seguendo le indicazionifornite al link http://wiki.ubuntu-it.org/Server/LampVirtualBox

∗ Modifica del campo upload_max_filesize nel file /etc/php5/apache2/php.iniper permettere il caricamento di file di dimensioni maggiori fino a 200 MB2

∗ Installazione della componente Xibo Server, secondo le indicazione fornite allink http://wiki.xibo.org.uk/wiki/Install_Guide_Xibo_Server

∗ Accesso all’interfaccia di gestione da browser web: IP-SERVER/xibo

Componente client

∗ Installazione e configurazione del software necessario per il corretto funziona-mento della componente client: NET Framework 3.5 SP1, Flash Player, K-LiteCodec Pack Basic (per la riproduzione dei vari formati video)

∗ Installazione e configurazione della componente client (su sistema operativoWindows XP SP3)

∗ Configurazione del client e registrazione presso il server (vedere a tal propositoil capitolo 6.3 - Descrizione del processo di registrazione del client di test).

2https://answers.launchpad.net/xibo/+faq/510

http://wiki.ubuntu-it.org/Server/LampVirtualBox

http://wiki.xibo.org.uk/wiki/Install_Guide_Xibo_Server

IP-SERVER/xibo

https://answers.launchpad.net/xibo/+faq/510


4.3.2 Verifica dei requisiti

Tabella 4.2: Verifica dei requisiti funzionali obbligatori in Xibo


FFOB-1 SODDISFATTO

FDOB-1 SODDISFATTO

FFOB-2 SODDISFATTO

FFOB-3 SODDISFATTO

FFOB-4 SODDISFATTO

FFOB-5 SODDISFATTO

FFOB-6 SODDISFATTO

FFOB-7 SODDISFATTO

FFOB-8 SODDISFATTO

Tabella 4.3: Verifica dei requisiti funzionali desiderabili in Xibo


FFDE-1 SODDISFATTO

FFDE-2 SODDISFATTO

Tabella 4.4: Verifica dei requisiti funzionali opzionali in Xibo


FFOP-1 NON SODDISFATTO

4.4. IL SOFTWARE CONCERTO 33

Tabella 4.5: Verifica dei requisiti di qualità desiderabili in Xibo


QUDE-1 PARZIALMENTE SODDISFATTO


QUDE-3 SODDISFATTO

4.4 Il software Concerto

Figura 4.3: Logo del prodotto Concerto

Sito web ufficiale https://www.concerto-signage.org/

Tipo di licenza open source GNU GPL v2.03

Versione analizzata 1.9.3

Tecnologia lato server PHP + MySQL su server Apache

Tecnologia lato client /

Tabella 4.6: Informazioni principali sul prodotto Concerto

Concerto è una soluzione open source per il digital signage, progettata per facilitarela condivisione delle informazioni in comunità ampie e distribuite.

La gestione centralizzata avviene tramite un consueto pannello di amministrazioneaccessibile da browser web (vedi Figura 4.4).

Caratteristica unica di Concerto è che la visualizzazione di un certo contenutoin un certo dispositivo client è soggetta ad un meccanismo di sottoscrizione: ilcontenuto aggiunto dall’utente ad un feed (una sorta di raccolta virtuale dei contenutimultimediali) viene inviato e inserito nella coda di moderazione, dove può venireapprovato o rifiutato. Se approvato, il contenuto viene inserito nella lista dei contenutiche i dispositivi client iscritti al feed possono visualizzare.

Il player di Concerto può essere un qualsiasi browser web impostato per la visua-lizzazione a schermo pieno.

3Sito internet di riferimento per la licenza GNU GPL v2. URL: http://www.gnu.org/licenses/gpl-2.0.html

https://www.concerto-signage.org/

http://www.gnu.org/licenses/gpl-2.0.html



Figura 4.4: Home page dell’interfaccia di gestione di Concerto


Componente server

∗ Creazione di una macchina virtuale tramite VirtualBox, ed installazione delsistema operativo guest Ubuntu Server 12.04 LTS

∗ installazione del server LAMP (Apache+MySQL+ PHP) seguendo le indicazionifornite al link http://wiki.ubuntu-it.org/Server/LampVirtualBox

∗ Modifica del campo upload_max_filesize nel file /etc/php5/apache2/php.iniper permettere il caricamento di file di dimensioni maggiori fino a 200 MB4

∗ Installazione della componente Concerto Content Server

∗ Accesso all’interfaccia di gestione da browser web: IP-SERVER/concerto

Componente client

Non ci sono requisiti specifici per l’installazione, è sufficiente infatti la presenza di unqualunque browser web. Una volta effettuata la registrazione del client, basta quindiaccedere all’indirizzo http://SERVER/concerto/screen/?mac=MAC-ADDRESS,dove SERVER è l’indirizzo della macchina che ospita il Content Server, e MAC-ADDRESSè l’indirizzo MAC dell’interfaccia di rete del dispositivo client.

4https://answers.launchpad.net/xibo/+faq/510

http://wiki.ubuntu-it.org/Server/LampVirtualBox

IP-SERVER/concerto

http://SERVER/concerto/screen/?mac=MAC-ADDRESS

https://answers.launchpad.net/xibo/+faq/510

4.4. IL SOFTWARE CONCERTO 35


Tabella 4.7: Verifica dei requisiti funzionali obbligatori in Concerto


FFOB-1 SODDISFATTO

FDOB-1 PARZIALMENTE SODDISFATTO

FFOB-2 NON SODDISFATTO


FFOB-4 SODDISFATTO


FFOB-6 SODDISFATTO

FFOB-7 SODDISFATTO

FFOB-8 PARZIALMENTE SODDISFATTO

Tabella 4.8: Verifica dei requisiti funzionali desiderabili in Concerto


FFDE-1 NON SODDISFATTO


Tabella 4.9: Verifica dei requisiti funzionali opzionali in Concerto




Tabella 4.10: Verifica dei requisiti di qualità desiderabili in Concerto


QUDE-1 NON SODDISFATTO



4.5 Vodigi

Figura 4.5: Logo del prodotto Vodigi

Sito web ufficiale http://vodigi.codeplex.com/

Tipo di licenza open source GNU GPL v2.05

Versione analizzata 6.0

Tecnologia lato server ASP.NET MVC 4 e SQL Server

Tecnologia lato client .NET Framework

Tabella 4.11: Informazioni principali sul prodotto Vodigi

Vodigi è una soluzione open source per il digital signage interattivo.La configurazione standard riguarda l’installazione di Vodigi Administrator (ve-

di Figura 4.6) su un web server Windows (Windows Server 2008 o 2012), men-tre l’applicazione client Vodigi Player è installata in ciascuna delle piattaforme divisualizzazione.

L’applicazione Vodigi Player comunica con il web server Vodigi e scarica i propripalinsesti e contenuti multimediali; ogni client visualizza i propri schermi in accordocon i palinsesti a lui assegnati. Il media è riprodotto dall’hard disk locale, così dapermettere la visualizzazione dei contenuti anche in assenza di connessione di retetra client e server.

5Sito internet di riferimento per la licenza GNU GPL v2

http://vodigi.codeplex.com/

4.5. VODIGI 37

Figura 4.6: Home page dell’interfaccia di gestione di Vodigi


Componente server

∗ Creazione di una macchina virtuale tramite VirtualBox, ed installazione delsistema operativo guest Microsoft Windows Server 2012

∗ Installazione e configurazione di Internet Information Services (IIS) sul si-stema guest: vedere a tal proposito il pdf Vodigi - IIS Setup Guide -Windows Server 2012 fornito al linkhttp://vodigi.codeplex.com/documentation

∗ Installazione e configurazione di Microsoft SQL Server 2012 sul sistema guest:vedere a tal proposito il pdf Vodigi - SQL Server 2012 Express SetupGuide fornito al link http://vodigi.codeplex.com/documentation

∗ Installazione di Microsoft ASP.NET MVC4

∗ Installazione e configurazione della componente server Vodigi Administrator,secondo le istruzioni fornite nel pdf Vodigi – Vodigi Administrator –Setup Guide – Windows Server 2012 – ver 6.0 al linkhttp://vodigi.codeplex.com

∗ Accesso all’interfaccia di gestione da browser web: IP-SERVER/soVodigiWeb/Login

http://vodigi.codeplex.com/documentation

http://vodigi.codeplex.com/documentation

http://vodigi.codeplex.com

IP-SERVER/soVodigiWeb/Login

IP-SERVER/soVodigiWeb/Login


Componente client

∗ Creazione di una macchina virtuale tramite VirtualBox, ed installazione delsistema operativo guest Microsoft Windows 7

∗ Installazione e configurazione di NET Framework v4.5 sul sistema guest

∗ Installazione e configurazione della componente client Vodigi Player, secondole istruzioni fornite nel pdf Vodigi ver 6.0 - Vodigi Player - DeviceConfiguration Guide - Windows 7 al link http://vodigi.codeplex.com

∗ Configurazione del client e registrazione presso il server


Tabella 4.12: Verifica dei requisiti funzionali obbligatori in Vodigi



FDOB-1 PARZIALMENTE SODDISFATTO





FFOB-6 SODDISFATTO



Tabella 4.13: Verifica dei requisiti funzionali desiderabili in Vodigi


FFDE-1 SODDISFATTO




4.5. VODIGI 39

Tabella 4.14: Verifica dei requisiti funzionali opzionali in Vodigi



Tabella 4.15: Verifica dei requisiti di qualità desiderabili in Vodigi



QUDE-2 SODDISFATTO

QUDE-3 SODDISFATTO


4.6 Conclusione dell’attività di valutazione

Dall’attività di analisi è emerso che il software Xibo è il prodotto che più si adattaalle esigenze espresse e implicite, ai vincoli e ai bisogni dell’azienda.

Le ragioni della scelta:

∗ soddisfa in maniera del tutto completa i requisiti obbligatori definiti per l’inter-faccia di gestione;

∗ sia la componente server che la componente client risultano facilmente installa-bili e configurabili;

∗ è la soluzione open source più conosciuta nell’ambito del digital signage;

∗ per il motivo di cui appena sopra, è continuamente mantenuto, sviluppato esupportato dagli sviluppatori e dalla comunità;

∗ è presente documentazione tecnica ufficiale (manuali di installazione e d’uso),sebbene non sia del tutto completa;

Il prodotto Concerto è stato scartato per la scarsa copertura dei requisiti definitiper il sistema centralizzato di gestione. Evidentemente il prodotto in questione èpiù adatto a situazioni ed esigenze di complessità inferiori sia per quanto riguardal’infrastruttura di digital signage, sia per quanto riguarda la gestione dei contenuti.

Inoltre la versione analizzata non è più manutenuta attivamente. Attualmente èin corso di sviluppo una seconda versione, ma non essendo stata rilasciata in formastabile, essa non è stata tenuta in considerazione in questa analisi.

Durante l’analisi del prodotto Vodigi è risultato evidente che il prodotto fosse piùadatto a quelle situazioni in cui l’utente interagisce con il display (che deve evidente-mente trattarsi di uno schermo sensibile al tocco) per selezionare e visualizzare leinformazioni desiderate. Ciò non rispecchia le esigenze dell’azienda, anche in virtùdi uno scarso supporto di contenuti multimediali: il sistema è in grado di gestireelementi multimediali di tipo audio, video e immagine.

Capitolo 5

Specifica tecnica del prodotto Xibo

Questo capitolo spiega le problematiche affrontate nella realizzazione della specificadel sistema selezionato e descrive il lavoro effettuato.

5.1 Metodologia

Trattandosi di un prodotto sviluppato da terzi, e vista la mancanza di documentazioneche definisse nel dettaglio l’architettura del prodotto e i vari componenti, si sarebbedovuta intraprendere la strada del reverse engineering.

Il reverse engineering è un’attività che consente di ottenere specifiche e informazionisul design di un sistema a partire dal suo codice, attraverso processi di estrazione edastrazione di informazioni. I processi di reverse engineering si basano quindi su duefasi fondamentali:

estrazioneAnalisi del codice o di altri artifatti software, allo scopo di ottenere informazionirelative al sistema analizzato. Particolarmente utili sono quegli strumenti ingrado di estrarre informazioni da un codice sorgente qualsiasi, nota che sia lagrammatica del linguaggio di programmazione.

astrazioneSi esaminano le informazioni estratte e si cercano di astrarre diagrammi, oviste, ad un più alto livello di astrazione (ad esempio i diagrammi di progetto,architetturali, del dominio dei dati). I processi di astrazione non sono com-pletamente automatizzabili poichè necessitano di conoscenza ed esperienzaumana.

I processi di reverse engineering vengono svolti per raggiungere in genere i seguentiobiettivi:

41

42 CAPITOLO 5. SPECIFICA TECNICA DEL PRODOTTO XIBO

∗ obiettivi di cambiamento, ovvero generare un prodotto rinnovato medianteinterventi di migrazione, modernizzazione, modularizzazione;

∗ obiettivi di comprensione, ovvero aumentare la conoscenza posseduta su undeterminato prodotto software.

5.2 Variazione degli obiettivi del progetto di stage

Dopo una attenta analisi della situazione e delle problematiche, si è deciso di noncompletare l’attività di analisi dell’architettura del prodotto Xibo e di dedicarsi alsolo studio del modello di comunicazione adottato tra la componente server e lacomponente client (si veda a tal proposito la successiva sezione 5.3). Le motivazionia supporto di questa decisione vengono di seguito riportate:

∗ il reverse engineering è un’attività in genere dispendiosa, sia in termini di tempoche di risorse. Visto il poco tempo rimasto a disposizione dalla termine dellostudio di fattibilità alla conclusione dell’esperienza di stage, si è deciso di daremaggiore priorità alla successiva attività di test del prodotto;

∗ il linguaggio PHP, tramite cui è sviluppata la componente server di Xibo, è unlinguaggio non completamente object-oriented. Questo fatto potrebbe rallentarel’attività di reverse engineering;

∗ la scarsa conoscenza da parte del sottoscritto della tecnologia .NET Framework,alla base dell’applicativo client.

5.3 Il protocollo di comunicazione client-server

5.3.1 Introduzione ai web service

In Xibo la comunicazione tra la componente server e i client facenti parte del sistemaavviene attraverso un web service che, tramite lo scambio di messaggi attraversoil protocollo SOAP, permette a ciascun client di ottenere dinamicamente tutte leinformazioni di cui ha bisogno per riprodurre il palinsesto e i contenuti multimedialiin esso definiti. Alcuni dei vantaggi che è possibile ottenere con l’utilizzo dei webservice:

∗ permettono l’interoperabilità tra diverse applicazioni software implementate sudiverse piattaforme hardware;

5.3. IL PROTOCOLLO DI COMUNICAZIONE CLIENT-SERVER 43

∗ utilizzano standard e protocolli open. Un web service comunica utilizzandotecnologie open come XML e HTTP: il primo è utilizzato come formato ditrasporto e di archiviazione dei dati, mentre HTTP consente la trasmissione e loscambio delle informazioni tra le macchine presenti nella stessa rete. I protocollie il formato dei dati è, ove possibile, disponibile in formato testuale, cosa chene rende più facile la comprensione e l’utilizzo da parte degli sviluppatori;

∗ mediante l’uso di HTTP per il trasporto dei messaggi i web services non necessi-tano, normalmente, che vengano effettuate modifiche alle regole di sicurezzautilizzate come filtro sui firewall;

∗ possono essere facilmente utilizzati, in combinazione l’uno con l’altro ed indi-pendentemente da chi li fornisce e da dove vengono resi disponibili per formareservizi integrati e complessi;

∗ consentono il riutilizzo di infrastrutture ed applicazioni già sviluppate e sono(relativamente) indipendenti da eventuali modifiche delle stesse.

Il funzionamento di un web service è il seguente: l’applicazione centralizzata met-te a disposizione un’interfaccia software, descritta in un formato automaticamenteelaborabile, il Web Services Description Language (WSDL), che espone all’esternoi servizi messi a disposizione. Utilizzando tale interfaccia i client possono interagirecon l’applicazione stessa attivando le operazioni descritte nell’interfaccia (servizi orichieste di procedure remote) tramite appositi messaggi di richiesta: tali messaggidi richiesta sono racchiusi in una “struttura” SOAP, formattati secondo lo standardXML, e vengono a loro volta incapsulati e trasportati tramite i protocolli del web(solitamente HTTP).

Il WSDL è un formato XML utilizzato per permettere ai client che vogliono “consumare”il web service di conoscere tutti i servizi e le operazioni esposte dal servizio stesso.Un tipico documento WSDL è composto dai cinque elementi principali:

types definisce i tipi di dati utilizzati dal web service;

message definisce un messaggio. Ciascun messaggio è composto da più parti checorrispondono alla lista dei parametri passati ad una funzione;

portType definisce le operazioni che il web service può effettuare e i messaggi chesono coinvolti in ciascuna operazione. Ogni operazione può essere di quattrotipi: one-way (si riceve un messaggio ma non si manda alcuna risposta), request-response (si riceve una richiesta e si manda una risposta), solicit-response (sipuò inviare una richiesta e si attende una risposta), notification (si può inviareuna richiesta e non si attende per una risposta);

binding definisce il formato dei dati e il protocollo concreto per ciascuna operazione;

service definisce il punto di collegamento al web service.


SOAP (inizialmente acronimo di Simple Object Address Protocol) è un protocolloleggero creato per lo scambio di informazioni tra sistemi software distribuiti in unarete di computer. Utilizza HTTP come protocollo di trasporto, ma non è limitatoné vincolato ad esso. Un messaggio SOAP è a tutti gli effetti un documento XMLcontenente i seguenti elementi:

envelope (richiesto) è l’elemento radice, identifica il documento XML come unmessaggio SOAP;

header (non richiesto) contiene informazioni a supporto del messaggio vero eproprio, che possono servire al destinatario del messaggio;

body (non richiesto) contiene le informazioni vere e proprie.

5.3.2 Il web service utilizzato in Xibo

XMDS è il servizio SOAP eseguito dall’applicazione Xibo Server per comunicarecon i client. XMDS è descritto dal file xmds.wsdl, il cui contenuto può esserevisualizzato accedendo all’indirizzo http://IP.XIBO.SERVER/xmds.php?wsdl.La comunicazione è di tipo solicit-response, ovvvero il client invia il messaggio eattende la risposta del client prima di procedere.Quando il client invia il messaggio, ilweb service recupererà le informazioni richieste dal database e le invierà in rispostaal client (Figura 5.1).

Figura 5.1: Schema di funzionamento del web service SOAP

Di seguito vengono presentate, ad un livello astratto, le operazioni descritte al-l’interno del file. In virtù del tipo di comunicazione adottata, ciascuna operazione è

http://IP.XIBO.SERVER/xmds.php?wsdl

5.3. IL PROTOCOLLO DI COMUNICAZIONE CLIENT-SERVER 45

costituita da due messaggi: una richiesta da parte del client (request) e una rispostada parte del server (response).

RegisterDisplay(serverKey, hardwareKey, displayName, version)

- response: ActivationMessage (string)

RequiredFiles(serverKey, hardwareKey, version)

- response: RequiredFilesXml (string)

GetFile(serverKey, hardwareKey, filePath, fileType, chunkOffset,chuckSize, version)

- response: file (base64Binary)

Schedule(serverKey, hardwareKey, version)

- Response: ScheduleXml (string)

RecieveXmlLog(serverKey, hardwareKey, xml, version)

- Response: success (boolean)

SubmitLog(version, serverKey, hardwareKey, logXml)


SubmitStats(version, serverKey, hardwareKey, statXml)


MediaInventory(version, serverKey, hardwareKey, mediaInventory)


GetResource(serverKey, hardwareKey, layoutId, regionId, mediaId,version)

- Response: resource (string)

5.3.3 Esempio di funzionamento

1. Lato client si effettua la registrazione del dispositivo, questo passo permette dinotificare al server la presenza di un nuovo client.Il client quindi si connettee chiama RegisterDisplay: se il display è già registrato (già presente nelsistema), l’operazione ritorna il messaggio “Display is active and ready tostart”; se il display è stato appena aggiunto, la funzione ritorna il messaggio“Display added and is awaiting licensing approval from an Administrator”. Inquesto caso l’utente deve concedere l’autorizzazione al display dall’interfacciadi amministrazione (per ulteriori informazioni si veda la procedura descrittanel capitolo 6.3 - Descrizione del processo di registrazione del client di test).


2. Il client invia un messaggio RequiredFilesRequest, il web service elaborala richiesta e ritorna una stringa contenente il documento XML. Il documentodescrive tutti i contenuti multimediali richiesti da inserire nei layout assegnatial client. Un esempio della struttura viene presentata di seguito. Ogni elementofile ha un attributo type: il valore media indica che si tratta di un elemen-to multimediale, il valore layout identifica un file che descrive il layout inquestione.

Codice 5.1: blablabla<?xml version ="1.0"?><files >

<file type="media" path="6.jpg" id="6" size="" md5=""/><file type="media" path="8.jpg" id="8" size="" md5=""/><file type="layout" path="1" md5="0781 e57843b9fe70759b9950427873"/><file type="media" path="7.jpg" id="7" size="" md5=""/><file type="media" path="8.jpg" id="8" size="" md5=""/><file type="media" path="6.jpg" md5="" size=""/><file type="layout" path="2" md5="ef74f46cd4844676494863f84dab25"/><file type="blacklist"/>

</files> �3. Il client esamina il documento XML e, per ciascun elemento file, invia un

messaggio GetFileRequest. Il web service elabora la richiesta e invia i filerichiesti al client. Il client invia un messaggio ReportInventoryRequest perpermettere al server di aggiornare la lista dei file gestiti dal client in questione.

4. Concorrentemente il client invia un messaggio ScheduleRequest, il webservice elabora la richiesta e ritorna il documento XML. Il documento descrivei layout assegnati al client. Un esempio della struttura viene presentata diseguito: ogni elemento layout ha attributi che identificano il periodo e l’ordinedi visualizzazione.

Codice 5.2: blablabla<?xml version ="1.0"?><schedule >

<layout file="1" fromdt="2050 -12 -31 00:00:00" todt="2050 -12 -3100:00:00" scheduleid=""/><layout file="2" fromdt="2008 -12 -08 08:00:00" todt="2008 -12 -11

21:19:00" scheduleid="1"/></schedule > �

5. Il client avvia la riproduzione dei layout. Per ogni layout riprodotto, il clientinvia un messaggio SubmitStatsRequest per permettere al server di ottenerele statistiche aggiornate sui file gestiti dal client in questione.

Capitolo 6

Test del prodotto Xibo

In questo capitolo viene illustrata l’attività di test effettuata sul prodotto Xibo.

6.1 Metodologia

L’attività di test è stata pianificata per provare la bontà del prodotto in un contestooperativo e di utilizzo reali, i cui vincoli e condizioni sono di seguito specificati:

∗ è auspicabile che l’applicativo client di Xibo possa essere installabile e confi-gurabile su sistema operativo Windows XP Embedded, sistema presente neidispositivi di visualizzazione appartenenti all’infrastruttura di digital signage diTelerete Nordest Srl;

∗ il client risiede in una macchina differente dal server, non sono quindi ammessesoluzioni di virtualizzazione (come quelle utilizzate nella fase di analisi);

∗ è auspicabile che il sistema sia in grado di distribuire i contenuti e i palinsestiverso i client anche in condizioni di rete non continuata. Si assume quindi cheil client non sia sempre raggiungibile (per motivi tecnici e/o di infrastruttura direte).

Sono stati quini eseguiti test pratici atti a verificare il comportamento del prodotto difronte a situazioni “critiche” descritte in precedenza, visto che comunque la maggiorparte delle funzionalità sono state testate durante l’attività di analisi dei prodottiricercati(vedere il capitolo 4.3 - Il software Xibo).

47

48 CAPITOLO 6. TEST DEL PRODOTTO XIBO

6.2 Configurazione dell’ambiente di test

Vista la mancata possibilità di utilizzare uno dei dispositivi realmente appartenentialla rete di digital signage dell’azienda, si è deciso di utilizzare un’apposita macchinadi test, i cui requisiti hardware sono i seguenti:

∗ processore Intel Pentium Dual-Core E5700 @ 3.00 Ghz

∗ memoria RAM 2 GB

∗ scheda video Intel G45/G43 Express

∗ monitor con risoluzione 900x1600 (rapporto di aspetto 9:16)

Si è resa inoltre necessaria la creazione di una immagine di Windows XP Embedded ad-hoc per la suddetta macchina di test. Essendo infatti tale sistema operativo Windowsuna versione ridotta del più noto Windows XP Professional, non dispone di quella chesi potrebbe chiamare una immagine di installazione standard. Deve essere appuntoutilizzato un apposito toolkit, denominato Windows Embedded Studio, per creare unambiente Windows XP Embedded personalizzato contenente soltanto le funzionalitàdi cui la macchina necessita.

I requisiti per l’utilizzo del toolkit prevedono che il computer su cui viene installatoil sistema di sviluppo di Windows Embedded debba avere installato uno dei seguentisistemi operativi: Windows Server 2003/2008, Windows XP/Vista/7. Questo per-ché è necessario utilizzare un programma apposito, TAP, per ricavare i dati relativiall’hardware della macchina. Il tool genererà un file con estensione .pqm necessarioper la corretta generazione dell’immagine del sistema operativo.

I passi effettuati per ottenere una macchina di test pronta per l’installazione diXibo, e con Windows XP Embedded a bordo, sono qui riassunti:

1. installazione di Windows Embedded Studio, che include:

- Component Designer, strumento utilizzato per generare i componenti;

- Target Designer, strumento utilizzato per generare configurazioni e creareimmagini del sistema operativo embedded;

- Component Database Manager, strumento di gestione del database deicomponenti;

- Target Analyzer per la generazione del file .pqm;

- il database contenente i componenti che è possibile includere nella confi-gurazione;

2. esecuzione dell’utility TAP (Target Analyzer Probe) per la generazione del filedevices.pqm

3. avvio dell’utility Component Designer, importazione del file devices.pqm esalvataggio nel file device.sld

4. avvio dell’utility Component Database Manager e importazione del file device.sldnel database dei componenti;

6.3. DESCRIZIONE DEL PROCESSO DI REGISTRAZIONE DEL CLIENT DI TEST 49

5. avvio dell’utility Target Designer e creazione di un nuovo file di configurazione,selezione della componente “devices”, selezione dei template “Advanced Set TopBox” e “Network Attached Storage”, “Retail Point Of Sale Terminal”, “Windows-based Terminal Professional”;

6. creazione della build di Windows XP Embedded;

7. copia della build nel disco rigido della macchina di test;

8. avvio della macchina di test, completamento dell’installazione e configurazionedi Windows XP Embedded;

9. installazione dei driver per il corretto funzionamento della scheda video.

Si è quindi proceduto con l’installazione e configurazione della componente client,come descritto nel capitolo 4.3.1 - Configurazione del prodotto. L’installazione delclient è molto semplice: il software, una volta installato, creerà due link/istanze nelmenu Start di Windows. Un’istanza lancia il programma vero e proprio mentre l’altra(Xibo Client Options) lancia il menu dove sarà possibile configurare/personalizzarealcuni parametri relativi al funzionamento del software stesso.

6.3 Descrizione del processo di registrazione del clientdi test

Il menu di configurazione dell’applicativo Xibo Client Options propone diverse schedee diversi parametri per ciascuna scheda. Nella prima scheda (Figura 6.1) sono inparticolare configurabili:

∗ l’URI relativo all’installazione di Xibo, ovvero la directory in cui è stata installatala parte server;

∗ la chiave, che è un parametro scelto dall’amministratore e serve per effettuarel’hand-shaking con il server: qualsiasi client che volesse connettersi al serverdovrà specificarne la chiave;

∗ la cartella locale ove risiederanno gli elementi multimediali che il client prelevadal server quando verifica la presenza di nuovi palinsesti;

∗ la frequenza in secondi con la quale il client si collega al server;

∗ la chiave unica generata automaticamente e direttamente dal client.

Successivamente nella seconda scheda (Figura 6.2) si deve procedere alla deno-minazione e registrazione del client/display. Questa operazione notifica al serverl’esistenza del client.

Una volta effettuata la registrazione, in pochi istanti vengono mostrati i risultati e laconferma di effettuata richiesta di approvazione licenza (aggiunta display e la relativaattesa di approvazione da parte dell’amministratore del sistema). L’approvazione


Figura 6.1: Applicazione Xibo Client Options, scheda “Xibo Settings”

Figura 6.2: Applicazione Xibo Client Options, scheda “Register Display”

della licenza e quindi l’abilitazione del client alla ricezione dei contenuti è effettuatolato server dal pannello di amministrazione.

6.3. DESCRIZIONE DEL PROCESSO DI REGISTRAZIONE DEL CLIENT DI TEST 51

Una volta effettuata con successo la richiesta di approvazione della licenza da partedel client è necessario abilitarla dal pannello di amministrazione sul server. Recandosinel menu in “Management -> Display” è visibile l’elenco e lo stato dei vari display(client) attivi o in attesa di attivazione come in Figura 6.3.

Figura 6.3: Vista “Display” nel pannello di amministrazione di Xibo

In questo caso basterà clicca il pulsante “Edit” in corrispondenza al client daattivare, impostare la licenza display su “Yes” e salvare (Figura 6.3). Ora la licenzadel player appare abilitata e quindi il player ha l’autorizzazione a connettersi al servere prelevare contenuti e palinsesti.

Figura 6.4: Concessione della licenza


6.4 Pianificazione ed esito dei test

Per la pianificazione dei test sono state adottate le seguenti linee guida e specifiche:

∗ per simulare l’assenza di connessione tra client e server, nella parte server siesegue il comando sudo /etc/init.d/network stop che “spegne” tutte leinterfacce di rete attive nel server stesso;

∗ un layout di default: viene mostrato quando non ci sono layout programmati oquando si effettuano cambiamenti ai layout programmati (ed è quindi necessarioattendere lo scaricamento dei nuovi elementi multimediali). Il layout di defaultcreato (Figura 6.5) consiste di 2 regioni di risoluzione 450x400 pixel, ciascunacontenente una immagine fissa;

∗ l’applicativo client visualizza una splash screen nel momento in cui non c’ènulla da visualizzare, nemmeno il layout predefinito. Essa si può modificarelato client tramite l’applicazione Xibo Client Options;

∗ sono stati creati i seguenti layout:

– layout Totem_Pedrocchi_noWeb (Figura 6.6), consiste di una regione dirisoluzione 450x600 pixel contenente una timeline di sei immagini didurata variabile;

– layout Totem_Pedrocchi_full (Figura 6.7), consiste di due regioni. La primaregione ha risoluzione 450x600 pixel e contiene una timeline sei immaginidi durata variabile, la seconda regione ha risoluzione 450x200 e contienepagina web di prova con durata fissata a 30 secondi (si aggiorna ogni 30secondi);

Figura 6.5: Creazione del layout di default

6.4. PIANIFICAZIONE ED ESITO DEI TEST 53

Figura 6.6: Definizione del layout Totem_Pedrocchi_noWeb

Figura 6.7: Definizione del layout Totem_Pedrocchi_noWeb


Di seguito verranno elencati i test con il relativo esito ottenuto:

Tabella 6.1: Test 1

Pre-condizioni Il client è registrato correttamente presso ilserver, il client è stato avviato per la primavolta ed è in modalità offline (la connessionerisulta assente). E’ stato assegnato il layout didefault. Nessun layout programmato

Input -

Output atteso Il client visualizza la splash screen

Esito POSITIVO

Tabella 6.2: Test 2

Pre-condizioni Il client è registrato correttamente presso il ser-ver, il client è in modalità online per la primavolta. E’ stato assegnato il layout di default.Nessun layout programmato

Input -

Output atteso Il client scarica correttamente e visualizza illayout di default

Esito POSITIVO


Tabella 6.3: Test 3

Pre-condizioni Il client è registrato correttamente presso il ser-ver, il client è in modalità online e visualizza illayout di default. Nessun layout programmato

Input Simulata assenza di connessione tra client eserver

Output atteso Il client continua a visualizzare il layout didefault

Esito POSITIVO

Tabella 6.4: Test 4


Input Programmazione del layout To-tem_Pedrocchi_noWeb (durata 5minuti)

Output atteso Il client esegue il palinsesto e a fine esecuzionemostra il layout di default

Esito POSITIVO

Tabella 6.5: Test 5

Pre-condizioni Il client sta visualizzando il layout To-tem_Pedrocchi_noWeb


Output atteso Il client continua ad eseguire il palinsesto peril periodo indicato, e a fine esecuzione mostrail layout di default

Esito POSITIVO


Tabella 6.6: Test 6

Pre-condizioni Un layout è in programmazione e il client lovisualizza correttamente

Input Viene cancellata la programmazione delsuddetto layout

Output atteso Il client interrompe la visualizzazione e mostrail layout di default

Esito POSITIVO

Tabella 6.7: Test 7


Input Programmazione del layoutTotem_Pedrocchi_full

Output atteso Il client esegue il palinsesto e a fine esecuzionemostra il layout di default

Esito POSITIVO

Tabella 6.8: Test 8

Pre-condizioni Il client sta visualizzando il layout To-tem_Pedrocchi_full


Output atteso La regione contenente i contenuti scaricabilicontinua ad essere visualizzata correttamen-te. Osservazione del comportamento per laregione atta a mostrare il contenuto web

Esito POSITIVO, il tentativo di caricamento della pa-gina in assenza di connessione provoca un mes-saggio informativo di “navigazione cancellata”(Figura 6.8)


Figura 6.8: Esecuzione del Test 8 Totem_Pedrocchi_noWeb

Capitolo 7

Analisi critica del lavoro di stage

In questo capitolo verranno esposte le considerazioni personali riguardanti il progettodi stage e il lavoro in esso svolto.

7.1 Consuntivo finale e obiettivi raggiunti

Gli obiettivi definiti in 2.6 - Pianificazione delle attività di stage sono stati soddisfattisolo parzialmente, dato che non sono riuscito a completare la stesura del documentodi specifica tecnica del prodotto Xibo.

É sufficiente osservare la Tabella 7.1 per capire il motivo principale. La fase diricerca e analisi delle soluzioni open source ha richiesto più tempo del previsto,semplicemente per una errata considerazione della mole di lavoro necessaria perportare a compimento la suddetta attività. Questo, unitamente ai rimanenti motivispoegati nel capitolo 5.2 - Variazione degli obiettivi del progetto di stage, spiega ladecisione presa.

Tabella 7.1: Consuntivazione delle attività di stage

Attività Preventivo Consuntivo

STUDIO DEL DOMINIO 50 50

STUDIO DI FATTIBILITÁ 120 180

SPECIFICA TECNICA 48 16

TEST 90 60

Inoltre l’attività di stesura dello studio di fattibilità è più complessa di quello che sipossa credere. La realizzazione dello studio prevede infatti:

59

60 CAPITOLO 7. ANALISI CRITICA DEL LAVORO DI STAGE

1. l’analisi della situazione attuale: il contesto dello studio, l’individuazione dellaproblematica e la definizione delle esigenze da soddisfare, la descrizione dellasituazione attuale del sistema informativo, l’identificazione dei vincoli e ladefinizione dei requisiti di progetto;

2. la verifica dell’adeguatezza delle soluzioni ricercate: l’analisi della coperturafunzionale, la possibilità del riuso di componenti hardware e software;

3. l’analisi del rischio: l’individuazione dei fattori di rischio legati all’adozione inazienda della soluzione proposta, e la definizione delle modalità di gestione delrischio;

4. la soluzione proposta: le motivazioni della scelta e la specifica tecnica dellasoluzione;

5. analisi dei costi e benefici: l’individuazione e la valorizzazione delle principalivoci di costo, l’esplicitazione delle metriche utilizzate, la stima dell’impegnodelle risorse umane, la stima dei costi di impianto e di esercizio, valutati conriferimento all’intero ciclo di vita dell’applicativo;

6. raccomandazioni per la fase realizzativa.

Manca, in questa esperienza di stage, una stima economica dei costi di adozione emessa in esercizio del prodotto raccomandato. Stima che avrebbe dovuto includereanche una comparazione, sempre dal punto di vista economico, del processo diadozione rispetto ad un eventuale scelta di adeguamento e reingegnerizzazione dellasoluzione attualmente in uso in Telerete Nordest srl.

Questa attività non avrebbe però trovato spazio in questa esperienza di stage,semplicemente per un mera questione di tempo: quel tipo di analisi economica com-parativa avrebbe comportato uno studio approfondito dell’architettura del “sistemaTelerete”, cosa che a sua volta mi avrebbe portato a intraprendere un periodo inizialedi formazione sulle tecnologie, a me del tutto sconosciute, alla base del sistema digestione dell’infrastruttura di digital signage.

Sarebbe comunque auspicabile che questa attività di analisi dei costi e beneficivenisse portata a termine prima di una qualsiasi decisione presa dall’azienda riguardoall’adozione del prodotto Xibo.

A parte questa considerazioni, l’attività di analisi e le prove effettuate sul prodottoXibo hanno dimostrato un elevato grado di maturità del prodotto stesso.

A conclusione dell’esperienza di stage posso quindi affermare che è stato raggiuntol’obiettivo principale di ottenere una sorta di raccomandazione del prodotto qualitati-vamente migliore tra quelli oggetto dell’attività di ricerca e analisi.

7.2. CONOSCENZE ACQUISITE E PREPARAZIONE ACCADEMICA 61

7.2 Conoscenze acquisite e preparazione accademica

Lo svolgimento dello di stage mi ha permesso di utilizzare i dettami, i principi e lemetodologie applicati nel corso di Ingegneria del Software per la realizzazione delprogetto didattico di sviluppo di un’applicazione ex-novo, e di rielaborarli in mododa essere utilizzabili nelle attività che costituiscono il processo di adozione di unsoftware esistente.

Sebbene non abbia arricchito in maniera pesante il bagaglio delle conoscenze acquisi-te per le tecnologie utilizzate e incontrate, l’esperienza di stage mi ha permesso diconoscere in maniera approfondita un tema che sta prendendo sempre più piede nelnostro Paese, anche a seguito dei recenti interventi normativi, con impatto soprattuttosulla Pubblica Amministrazione, e con obiettivo il contenimento della spesa pubblica:gli enti pubblici hanno l’obbligo di valutare anche software open source tra le possibiliscelte tecnologiche nei loro bandi di gara.

Viene ribadita l’importanza della metodica applicata al sistema di lavoro come condi-zione necessaria alla buona riuscita del progetto, e la fondamentale importanza diuna buona fase di analisi del problema in esame prima di poter stimare e definiretempi e modalità per la sua soluzione.

7.3 Valutazione personale

Sebbene durante l’esperienza del progetto di stage si sia presentata qualche difficoltà,sono comunque soddisfatto del lavoro svolto e dell’esperienza acquisita. Lo svolgimen-to di uno stage presso esterno è un’esperienza sicuramente utile per l’avvicinamento almondo del lavoro, e per toccare con mano le dinamiche aziendali e le problematiche,talora impreviste, che possono sorgere.

Glossario

Analisi dinamica consiste nell’esecuzione di prove, su un insieme finito di casi, checomportano esecuzione del software in oggetto. 2, 63

Architettura software è l’organizzazione fondamentale di un sistema, definita daisuoi componenti, dalle relazioni reciproche tra i componenti e con l’ambiente, ei principi che ne governano la progettazione e l’evoluzione (def. presente nellostandard IEEE 1471-2000). 8, 63

Browser in informatica, è un programma che consente di usufruire dei servizi diconnettività in Internet, o di una rete di computer, e di navigare sul World WideWeb. 14, 63

Calcolo distribuito è un campo dell’informatica che studia i sistemi distribuiti. Unsistema distribuito consiste in tanti e autonomi computer che comunicanoattraverso una rete. I computer interagiscono tra loro al fine di raggiungere unobiettivo comune. Un software eseguito in un sistema distribuito è chiamatoprogramma distribuito, e la programmazione distribuita è il processo di scritturadi tali software. 12, 63

Cloud computing in informatica si indica un insieme di tecnologie che permettono,tipicamente sotto forma di un servizio offerto da un provider al cliente, dimemorizzare, archiviare e/o elaborare dati (tramite CPU o software) grazieall’utilizzo di risorse hardware/software distribuite e virtualizzate in rete inun’architettura tipica client-server. 29, 63

Database in informatica indica un archivio dati, o un insieme di archivi ben struttu-rati, in cui le informazioni in esso contenute sono strutturate e collegate tra lorosecondo un particolare modello logico (relazionale, gerarchico, reticolare o aoggetti) e in modo tale da consentire la gestione/organizzazione efficiente deidati stessi e l’interfacciamento con le richieste dell’utente attraverso i cosiddettiquery language (query di ricerca o interrogazione, inserimento, cancellazione,aggiornamento ecc.) grazie a particolari applicazioni software dedicate (DBMS),basate su un’architettura di tipo client-server. 14, 63

Database relazionale indica un database management system basato sul modellorelazionale. Il modello relazionale è un modello logico di rappresentazione ostrutturazione dei dati di un database implementato su sistemi di gestione dibasi di dati (DBMS), detti perciò sistemi di gestione di basi di dati relazionali

63

64 Glossario

(RDBMS). Si basa sulla teoria degli insiemi e sulla logica del primo ordine ed èstrutturato intorno al concetto matematico di relazione (detta anche tabella).Per il suo trattamento ci si avvale di strumenti quali il calcolo relazionale el’algebra relazionale. 28, 63

Disaster recovery in informatica ed in particolare nell’ambito della sicurezza infor-matica, si intende l’insieme delle misure tecnologiche e logistico/organizzativeatte a ripristinare sistemi, dati e infrastrutture necessarie all’erogazione di servi-zi di business per imprese, associazioni o enti, a fronte di gravi emergenze chene intacchino la regolare attività. 6, 64

E-government il sistema di gestione digitalizzata della pubblica amministrazione, ilquale, unitamente ad azioni di cambiamento organizzativo, consente di trattarela documentazione e di gestire i procedimenti con sistemi informatici, grazieall’uso delle tecnologie dell’informazione e della comunicazione (ICT), alloscopo di ottimizzare il lavoro degli enti e di offrire agli utenti sia servizi piùrapidi, che nuovi servizi. 7, 64

Feed è un’unità di informazioni formattata secondo specifiche (di genesi XML) sta-bilite precedentemente. Ciò per rendere interoperabile e interscambiabile ilcontenuto fra le diverse applicazioni o piattaforme. Il più comune è ora Atom; ilprimo è stato RSS. Un flusso è usato per fornire agli utenti una serie di contenutiaggiornati di frequente. I distributori del contenuto rendono disponibile il feede consentono agli utenti di iscriversi. 16, 64

Firewall in informatica, nell’ambito delle reti di computer, è un componente passivodi difesa perimetrale di una rete informatica, che può anche svolgere funzioni dicollegamento tra due o più tronconi di rete, garantendo dunque una protezionein termini di sicurezza informatica della rete stessa. 43, 64

Framework In informatica, e specificatamente nello sviluppo software, è un’ archi-tettura logica di supporto su cui un software può essere progettato e realizzato,spesso facilitandone lo sviluppo da parte dello sviluppatore. 17, 64

Grammatica è una struttura astratta che descrive un linguaggio formale in modopreciso, è cioè un sistema di regole che delineano matematicamente un insieme(di solito infinito) di sequenze finite di simboli (stringhe) appartenenti ad unalfabeto anch’esso finito. 41, 64

Hosting in informatica si definisce come un servizio di rete che consiste nell’allocaresu un server web le pagine web di un sito web, rendendolo così accessibile dallarete Internet e ai suoi utenti. 6, 64

Housing consiste nella concessione in locazione ad un utente di uno spazio fisico,generalmente all’interno di appositi armadi detti rack, dove inserire il server, diproprietà del cliente. Tipicamente i server vengono ospitati in webfarm o datacenter in cui si garantisce un’attenta gestione degli aspetti hardware, softwareed infrastrutturali. 6, 64

Glossario 65

HTTP è il protocollo usato come principale sistema per la trasmissione d’informazionisul web ovvero in un’architettura tipica client-server. Le specifiche del protocollosono gestite dal World Wide Web Consortium (W3C). 67

ICT indica l’insieme dei metodi e delle tecnologie che realizzano i sistemi di trasmis-sione, ricezione ed elaborazione di informazioni. 67

Ingegneria dei requisiti l’insieme di attività necessarie per il trattamento sistematicodei requisiti. Un requisito è una condizione necessaria a un utente per risolvereun problema o raggiungere un obiettivo prefissato. 1, 65

ISP in informatica e telecomunicazioni è una struttura commerciale o un’organiz-zazione che offre agli utenti (residenziali o imprese), dietro la stipulazione diun contratto di fornitura, servizi inerenti a Internet, i principali dei quali sonol’accesso a Internet e la posta elettronica. 67

Processo è un insieme di attività correlate e coese che trasformano ingressi in uscitesecondo regole fissate, consumando risorse nel farlo (def. presente nel glossarioISO 9000:2005. 1, 65

Proximity marketing è una tecnica di marketing che opera in un determinato ter-ritorio sfruttando tecnologie di comunicazione di tipo visuale e mobile perpromuovere la vendita di prodotti e servizi. Questa tecnica di marketing nonagisce su un target di utenti ben definito, ma sulle persone che si trovano inuna determinata area e siano vicine a un dispositivo atto a instaurare una co-municazione; in pratica una versione moderna della distribuzione di volantini.2, 65

Qualità insieme delle caratteristiche di un’entità (prodotto, processo, servizio) chene determinano la capacità di soddisfare esigenze espresse e implicite (def.presente in ISO 9000:2005). 1, 65

Rapporto d’aspetto (immagine) indica il rapporto matematico tra la larghezza el’altezza di un’immagine. 16, 65

Risoluzione (grafica) indica la precisione con la quale possibile rappresentare l’im-magine stessa su monitor. La risoluzione viene definita in pixel. 16, 65

SaaS è un modello di distribuzione del software applicativo dove un produttoredi software sviluppa, opera (direttamente o tramite terze parti) e gestisceun’applicazione web che mette a disposizione dei propri clienti via internet. 67

Scalabilità nelle telecomunicazioni, nell’ingegneria del software, in informatica e inaltre discipline, si riferisce, in termini generali, alla capacità di un sistema di“crescere” o diminuire di scala in funzione delle necessità e delle disponibilità.Un sistema che gode di questa proprietà viene detto scalabile. L’uso più tradi-zionale si riferisce alla scalabilità di carico, ovvero la capacità di un sistemadi incrementare le proprie prestazioni se a tale sistema vengono fornite nuoverisorse (per esempio, nel caso del software, maggiore potenza di processore oprocessori aggiuntivi). 13, 65

66 Glossario

Smart service definisce un insieme di strategie di pianificazione urbanistica teseall’ottimizzazione e all’innovazione dei servizi pubblici così da mettere in rela-zione le infrastrutture materiali delle città con il capitale umano, intellettualee sociale di chi le abita grazie all’impiego diffuso delle nuove tecnologie dellacomunicazione, della mobilità, dell’ambiente e dell’efficienza energetica, al finedi migliorare la qualità della vita e soddisfare le esigenze di cittadini, imprese eistituzioni. 7, 65

Totem multimediale detto anche chiosco o punto informativo, è principalmente uncomputer disponibile all’uso pubblico. Vista questa libertà di utilizzo, general-mente i totem sono dotati di sistemi di protezione e molto frequentemente sonopreimpostati in modo da visualizzare solo una serie di informazioni predetermi-nate. I computer all’interno dei totem multimediali sono protetti da strutture talida renderne impossibile la rimozione o la modifica delle impostazioni. Inoltrele strutture sono robuste e impermeabili, così da rendere sicuro l’uso anche inambienti esterni. Quelli moderni sono spesso dotati di schermo touchscreen. 1,65

Virtualizzazione in informatica si riferisce alla possibilità di astrarre le componentihardware, cioè fisiche, degli elaboratori al fine di renderle disponibili al softwarein forma di risorsa virtuale. Tramite questo processo è quindi possibile installaresistemi operativi su hardware virtuale; l’insieme delle componenti hardwarevirtuali prende il nome di macchina virtuale e su di esse può essere installato ilsoftware come, appunto, i sistemi operativi e relative applicazioni. 27, 66

Web farm indica una serie di server collocati in un unico ambiente in modo dapoterne centralizzare la gestione, la manutenzione e la sicurezza. 6, 66

W3C è un’organizzazione non governativa internazionale che ha come scopo quellodi sviluppare tutte le potenzialità del World Wide Web. Al fine di riuscire nelproprio intento, la principale attività svolta dal W3C consiste nello stabilirestandard tecnici per il World Wide Web inerenti sia i linguaggi di markup che iprotocolli di comunicazione. 67

XML è un linguaggio di markup, ovvero un linguaggio marcatore basato su unmeccanismo sintattico che consente di definire e controllare il significato deglielementi contenuti in un documento o in un testo. 43, 66

Acronimi e abbreviazioni

HTTP HyperText Transfer Protocol. 15

ICT Information and Communication Technology. 5

ISP Internet Service Provider. 6

SaaS Software as a Service. 17

W3C World Wibe Web Consortium. 9

67

Bibliografia

Riferimenti bibliografici

Pubblica Amministrazione), CNIPA (Centro Nazionale per l’Informatica nella. Lineeguida per il riuso delle applicazioni informatiche nelle Amministrazioni pubbliche.URL: http://www2.cnipa.gov.it/site/it-it/Attivit%C3%83%C2%A0/Riusabilit%C3%83%C2%A0_del_software_nella_PAC/Metodologia/Linee_guida_per_un_progetto_di_riuso/ (cit. a p. 20).

Sommerville, Ian. Ingegneria del software, Ottava edizione. Addison-Wesley, 2007(cit. a p. 1).

Riferimenti a siti web

Digital Signage su Wikipedia. URL: http://it.wikipedia.org/wiki/Digital_signage (cit. a p. 11).

Sito internet di Fujitsu Technology Solutions. URL: http://www.fujitsu.com/it/about/ (cit. a p. 7).

Sito internet di Infocert Spa. URL: http://www.infocert.it/abouts/view/Profilo_aziendale (cit. a p. 7).

Sito internet di Infracom Spa. URL: http://www.infracom.it/it/chi-siamo/profilo (cit. a p. 7).

Sito internet di Retelit Spa. URL: http://www.retelit.it/ (cit. a p. 7).

Sito internet di riferimento per la licenza GNU AGPL v3. URL: http://www.gnu.org/licenses/agpl-3.0.html (cit. a p. 30).

Sito internet di riferimento per la licenza GNU GPL v2. URL: http://www.gnu.org/licenses/gpl-2.0.html (cit. alle pp. 33, 36).

Sito internet di riferimento per la tecnologia Hibernate. URL: http://www.hibernate.org/ (cit. a p. 17).

Sito internet di riferimento per la tecnologia JAXB. URL: http://jaxb.java.net/(cit. a p. 17).

Sito internet di riferimento per la tecnologia Spring. URL: http://www.springsource.org/ (cit. a p. 17).

69












http://www.retelit.it/







http://jaxb.java.net/



70 BIBLIOGRAFIA

Sito internet di riferimento per la tecnologia XSLT. URL: http://www.w3.org/TR/xslt (cit. a p. 17).

Sito internet di riferimento per lo standard ISO/IEC 25010:2011 (sostituisce lo stan-dard ISO/IEC 9126:2001). URL: http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=35733 (cit. ap. 2).

Sito internet di Telecom Italia Spa. URL: http://www.telecomitalia.com/tit/it/innovation/hot-topics/scenarios/smart-services.html (cit. ap. 7).







Studio di fattibilit per l'adozione e l'implementazione di un sistema open source di digital...

Documents

Transcript of Studio di fattibilit per l'adozione e l'implementazione di un sistema open source di digital...