Metodologie e tecnologie a supporto nello sviluppo di ...Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica tesi di laurea specialistica Metodologie e tecnologie a supporto

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica tesi di laurea specialistica

Metodologie e tecnologie a supporto nello sviluppo di applicazioni mobile di tipo Enterprise Anno Accademico 2012/2013 Relatore Ch.mo prof. Marcello Cinque correlatore Ch.mo ing. Dennis Alessio Guidotti candidato Francesco Godino matr. 885/000481

[Dedica]

III

Indice Introduzione 6 Capitolo 1. titolo capitolo 1 12 1.1 titolo paragrafo 15 1.2 titolo paragrafo 23 1.2.1 titolo paragrafo 25 1.2.2 titolo paragrafo 32 1.2.3 titolo paragrafo 35 1.3 titolo paragrafo 36 1.3.1 titolo paragrafo 38 Capitolo 2. titolo capitolo 2 42 2.1 titolo paragrafo 42 2.1.1 titolo paragrafo 44 2.2 titolo paragrafo 46 2.2.1 titolo paragrafo 49 2.2.2 titolo paragrafo 53 2.2.3 titolo paragrafo 62 2.3 titolo paragrafo 70 2.3.1 titolo paragrafo 72 Conclusioni 196 Sviluppi futuri 198 Bibliografia 199

Metodologie e tecnologie a supporto nello sviluppo di applicazioni mobile di tipo enterprise

4

Introduzione

La continua evoluzione ed innovazione delle tecnologie connesse al web sta trasformando

profondamente il modo con cui gli utenti condividono le informazioni. I dati che vengono

scambiati vengono acceduti in misura sempre maggiore in mobilità indipendentemente dal

tempo e dal luogo; la mole di dati che viene prodotta e che viaggia nel web sta

aumentando, sia a livello di quantità che di complessità. Nuove tecnologie innovative

vengono lanciate sul mercato con cadenza sempre maggiore, andando ad ampliare i modi

con cui le informazioni vengono scambiate. Il volano delle recenti e delle future

innovazioni legate al web è rappresentato dal mobile computing, attraverso l'utilizzo in

costante aumento di smarphone e tablet. Queste 2 tipologie di dispositivi hanno creato, o

in alcuni contesti ampliato, servizi e tecniche a supporto degli utenti per la condivisione di

informazioni su scala globale. Grazie all'utilizzo di sensori sempre più complessi ma di

facile utilizzo e attraverso il paradigma orientato alle applicazioni, gli utenti riescono a

comunicare informazioni in tempo reale di diverso tipo. Ad esempio, utilizzando

un'applicazione di messaggistica istantanea, un utente può condividere su un social

network la sua posizione attraverso il sensore gps, collegandola a dati strutturati aggiuntivi

prodotti dall'applicazione, aumentando la semantica dell’informazione prodotta. L'insieme

di queste innovazioni che permettono un ruolo sempre più attivo degli utenti all'interno del

web sta portando al passaggio dal web 2.0 al 3.0. Il primo è un termine utilizzato per

indicare uno stato dell' evoluzione del World Wide Web, rispetto alla condizione


5

precedente in cui le pagine web erano statiche, cioè senza possibilità di interagire con esse

in maniera interattiva. Si indica come Web 2.0 l'insieme di tutte quelle applicazioni online

che permettono uno elevato livello di interazione tra il sito web e l'utente come i blog, i

forum, le chat, i wiki, le piattaforme di condivisione di media come Flickr, Youtube,

Vimeo, i social network come Facebook, Myspace, Twitter, Google+, Linkedin,

Foursquare, ecc. (Wikipedia). Questo livello di interazione tra utente e pagine web è

ottenuto attraverso l’utilizzo di tecnologie come AJAX, il cui acronimo è asynchronous

JAVASCRIPT and XML, HTML, CSS, e plugin creati ad hoc per aumentare il livello di

user experience delle applicazioni web, ad esempio JavaFX, Microsoft Silverlight o Adobe

Flex. Il Web 3.0 non ha una definizione univoca, perché con questo termine si tende ad

inglobare una serie di tecnologie, linguaggi, strumenti volti ad estendere il modo di

accedere e di ricercare informazioni e risorse del web. Principalmente la visione di questo

tipo di web è incentrata sulla strutturazione e semantica delle informazioni accessibili, sia

dagli utenti che dalle macchine. Attraverso una serie di linguaggi e tecnologie, come

XML, RDF, OWL, SPARQL si consente di utilizzare il web come archivio di dati

strutturati ai quali poter accedere da remoto. Avviene il passaggio da pagina web a risorsa

del web, con cui si intende qualsiasi dato strutturato accessibile, sia da utente che da

macchina. Il maggiore impatto di questa evoluzione consiste nell’ottenere un nuovo livello

di integrazione e di interoperabilità delle applicazioni, rendendo i dati disponibili

attraverso “link”, o attraverso API ( Application programming interface ) standardizzate;

inoltre attraverso questa ristrutturazione dell’accesso al web è possibile interrogare ed

accedere alle informazioni attraverso applicativi gestiti da intelligenza artificiale, al fine di

poter ottenere informazioni nascoste dalla elaborazione dei dati, attraverso algoritmi di

data mining. Queste trasformazioni del web e delle tecnologie ad esso connesse, è stato in

parte assimilato dalle realtà enterprise, ma può essere ampliato il loro utilizzo per favorire

la crescita di valore dell'azienda o aumentare l'efficienza dei processi interni. Il web e le

sue innovazioni può essere utilizzato in tutti i settori aziendali, principalmente per

relazionarsi a clienti, partner e propri dipendenti. Le tecnologie che sono in relazione

diretta con l’evoluzione del web che consentono grandi benefici se introdotte nelle attività


6

aziendali sono diverse; questa tesi è focalizzata sulle tecnologie mobile e lo sviluppo di

applicativi con un approccio multipiattaforma e multidevice. Le aziende che stanno

introducendo il mobile nel business aziendale devono relazionarsi con un contesto in

continua evoluzione, sia come tipologie di device, sia come sistemi operativi. Questa

condizione comporta un aumento dei costi di sviluppo e di manutenzione se si intendono

sviluppare applicazioni che devono essere eseguite su diversi sistemi operativi.

Nel capitolo 1 vengono presentate le tecnologie che possono apportare grossi benefici

qualora introdotte in azienda, soffermando l’attenzione sul contesto e le tecnologie mobile.

All’interno dell’insieme dei dispositivi mobile viene condotta un’analisi di mercato

incentrata sul tablet, il quale secondo le previsioni diverrà il punto di riferimento del

mercato mobile del futuro, sia in ottica consumer che business.

Nel capitolo 2 vengono analizzati i sistemi operativi mobile IOS, Android e Windows 8

(Windows RT), i 3 sistemi operativi che secondo le previsioni si divideranno il mercato

mobile in futuro.

Nel capitolo 3 vengono analizzati i diversi approcci e tecnologie per perseguire uno

sviluppo multipiattaforma e multidevice. Al fine di individuare la tecnologia da utilizzare

in base ad un contesto di utilizzo di riferimento, viene utilizzata una metodologia di scelta

multicriterio a supporto della decisione denominata Analytic Hierarchy Process.

Nel capitolo 4 viene mostrato il processo di sviluppo di un’applicazione commissionata da

Poste Italiane realizzata con la tecnologia di sviluppo ibrida. Vengono trattare le fasi di

analisi dei requisiti e di progettazione.

Nel capitolo 5 è trattata la fase di sviluppo del codice dell’applicativo per la piattaforma

Windows 8, scelta da Poste Italiane come piattaforma di riferimento da cui partire per lo

sviluppo. Al termine della realizzazione dell’applicazione viene analizzato

quantitativamente il beneficio apportato dalla tecnologia ibrida per un successivo porting

su piattaforma Android.

Infine vengono presentate le conclusioni del lavoro svolto e gli sviluppi futuri, riguardanti

lo sviluppo multipiattaforma di applicazioni mobile di tipo Enterprise.


7

Capitolo 1 Web,mobile e lʼutilizzo in azienda

In questo capitolo verranno presentate le principali tecnologie connesse al web che

potenzialmente possono portare maggiori benefici se utilizzate in azienda, sia quelle già

introdotte sul mercato sia quelle che verranno lanciate a breve. Verrà focalizzata

l'attenzione sui device mobili, in particolare il tablet. Attraverso un'analisi del mercato

attuale e delle previsioni future di questo tipo di dispositivo verrà mostrato che il tablet

diventerà il dispositivo principale nel contesto del mobile computing, sia a livello

customer che business.

1.1. Le tecnologie del web: opportunità per le aziende

Il web è diventato uno dei mezzi di comunicazione preferito dalle aziende, inoltre

costituisce la prima scelta per clienti, business partners, investitori, e altri parti interessate.

Esso è diventato pervasivo nelle vite di tutte le persone, sia a livello professionale che

personale. Vengono proposte alcune interessanti caratteristiche del web odierno:

• L’accesso ai contenuti da parte degli utenti viene realizzato in maniera contestuale,

utilizzando regole e meccanismi per ottenere informazioni sul comportamento e gusti,

selezionando dinamicamente quali dati presentare e come presentarli; esempi d’uso di

questa caratteristica sono portali come Youtube o Amazon, che in base all’interazione nel

tempo del singolo utente con il sistema riescono a fornire delle proposte che rispecchiano i

suoi gusti


8

• Utilizzo crescente delle tecnologie mobile per accesso al web, attraverso l’utilizzo di

smartphone e tablet e delle relative applicazioni, le quali sono sviluppate con diversi

approcci. Alle tecnologie native si stanno affiancando HTML5 e ibride( html incapsulato

in un involucro nativo )

• Esperienza utente avanzata offerta dalle applicazioni web, attraverso l’utilizzo di

HTML5, Cascading Style Sheets 3 (CSS3). L’evoluzione di questi standard permette di

non dover ricorrere a plug-in creati ad hoc per i web browser , come Flash o JavaFx, per

ottenere un’esperienza utente ricca, cioè con elementi grafici complessi ed avanzati e

l’interazione vicina a quella offerta dagli applicativi desktop

• Sviluppo di un’ottica Cloud-centric per la fornitura di diversi tipi di servizi ICT, in

cui attraverso il web viene realizzato l’interfacciamento tra utenti e servizi, sia per la

fruizione che per la gestione

• Sviluppo del social computing, cioè l’interazione tra utenti e condivisione di

informazioni avviene attraverso piattaforme social, creando la possibilità di generare

comunità su diversi tipi di tematiche

• Introduzione di nuove features in tutti i web browser, che sta generando una

frammentazione del mercato, fin’ora dominato da Internet Explorer.(Dati 2012

frammentazione browser)

• Aumento degli investimenti nel web delle aziende in termini di digital marketing

• In molte regioni del mondo il web sta creando forti cambiamenti a governi,

economie e norme sociali; alcuni esempi sono la diffusione delle informazioni attraverso i

social network nelle guerre civili dei paesi arabi e l’utilizzo del web come uno dei

principali canali per la propaganda politica nelle elezioni presidenziali negli Stati Uniti

d’America

L’espansione e le continue innovazioni delle tecnologie connesse al web offrono alle

aziende nuove opportunità per introdurlo nelle attività connesse a tutti i livelli della

piramide di Antony (http://it.wikipedia.org/wiki/Piramide_di_Anthony). L’utilizzo del

web è inoltre orizzontale rispetto alle diverse categorie dei processi di business delle


9

aziende; può essere introdotto all’interno di processi legati al Custom Relationship

Management ( CRM ), ai processi produttivi e ai processi manageriali. Il web risulta già

essere perno delle strategie di molte aziende nei rapporti con i clienti. Le caratteristiche di

ubiquità e di incremento delle possibilità offerte grazie alle tecnologie innovative,

accrescono l’utilità del web e lo rendono lo strumento più appropriato per l’interazione

dell’azienda con i clienti, partners e dipendenti. Nonostante il web sia stato introdotto da

tempo nelle aziende per adempiere a specifici scopi, ad esempio il marketing, ci sono

diverse opportunità di utilizzo delle diverse tecnologie connesse ad esso; il loro utilizzo

può apportare un impatto considerevole in termini di miglioramento dei Key performance

indicator (KPI) di molti processi aziendali, fino a essere un attore importante nel

cambiamento strutturale dell’azienda, ad esempio attraverso l’estrazione e l’analisi dei

dati provenienti dal web un’azienda può decidere di modificare il proprio business o di

espanderlo verso nuovi mercati e nuovi prodotti. Particolarmente efficace può essere

l’utilizzo del web attraverso i dispositivi mobili, come smartphone e tablet, grazie alle

innovazioni apportate in termini di user experience e features fornite. Questi tipi di

dispositivi offrono l’accesso a una serie di servizi innovativi peculiari dei diversi sistemi

operativi mobile attraverso un’interazione con l’utente intuitiva; l’uso del paradigma

orientato alle applicazioni mobile, che consiste di avere a disposizione una serie di

applicazioni che forniscono pochi servizi verticali per rispondere a specifici requisiti,

connesso all’interazione con molti sensori specifici dei dispositivi mobili( GPS, compasso,

camera, accelerometro, altimetro), incrementa la loro importanza e utilità all’interno delle

attività aziendali. L’incremento nell’uso del paradigma orientato alle applicazioni mobile

deve portare le aziende a prendere in considerazione nelle proprie strategie di sviluppare

applicazioni da distribuire attraverso i market ufficiali delle diverse piattaforme e

attraverso altri meccanismi. L’insieme delle tecnologie connesse al web è ampio ed

eterogeneo, e grazie agli sforzi degli organismi che si occupano di standardizzarne l’uso e

l’accesso alla rete globale,( esempio W3C, world wide web consortium ), è possibile

costruire sistemi distribuiti complessi che riescono ad interoperare ed essere integrati.

Grazie alla standardizzazione e alla crescita costante dell’interesse da parte di utenti ed


10

aziende, sul mercato vengono proposte tecnologie innovative ogni giorno. Vengono

descritte alcune delle tecnologie connesse al web che possono offrire importanti benefici

se introdotte nelle aziende. Tra quelle proposte sono presenti alcune emergenti, altre

mature e altre che verranno lanciate sul mercato in futuro:

• Social analitics: Con questo termine vengono individuate un insieme di applicazioni

che hanno lo scopo di misurare, analizzare e interpretare i dati provenienti

dall’acquisizione di informazioni relative alle interazioni delle persone con i social

networks, esempio Facebook e Google+. Queste attività si sono sviluppate come

specializzazione delle applicazioni relative al web analitics. Quest’ultimo consiste

nell’analisi dei dati che vengono trasmessi attraverso il web finalizzata a ottenere

informazioni per migliorare l’esperienza utente dei canali online delle aziende e

ottimizzare gli investimenti in digital marketing. Le applicazioni di social analitics sono

meno mature di quelle del web analitics. I vendors di queste tecnologie forniscono la

possiblità alle aziende di analizzare e carpire il significato nascosto connesso ai dati che

transitano sui social networks. Dati di interesse possono essere informazioni personali

delle persone, gusti e comportamenti inerenti ai prodotti e al brand interessato. Il loro

volume e l’eterogeneità dei tipi di dati prodotti attraverso diversi meccanismi, ad esempio

cliccando su un “mi piace” o su un “+1”, unità alla rapida evoluzione di queste

piattaforme, rendono le analisi complesse da realizzare. Le opportunità per le aziende

nell’utilizzo di queste tecnologie consistono nella capacità di monitorare, scovare e

predire. Attraverso il monitoraggio dei dati che transitano sui social networks è possibile

ad esempio riuscire a capire la reputazione di un’azienda e dei suoi prodotti, oppure capire

le necessità delle persone per anticipare il mercato lanciando nuovi prodotti. Queste

applicazioni possono essere integrate con applicazioni di Business Intelligence o di

Marketing Automation.

• Web Real-time Communications: questa tecnologia, il cui acronimo è WebRTC,

è in stato di draft nel processo di standardizzazione delle tecnologie web connesse ad

HTML5 realizzato dal W3C. Essa è un framework open-source che permetterà di

effettuare comunicazioni real-time attraverso i web browser. Questa tecnologia è stata


11

rilasciata nel Giugno 2011 dall’Ericsson Labs, ed è supportata da Google, Mozilla,

Firefox, Opera e Microsoft. Il gruppo di lavoro che sta continuando lo sviluppo di questa

tecnologia vuole definire un set di protocolli per facilitare le comunicazioni attraverso i

web browser. Le aziende possono utilizzare questa tecnologia, una volta matura, per

realizzare applicazioni web real-time scalabili e con poca latenza. Attraverso questa

tecnologia possono essere realizzate pagine web che vengono utilizzate come oggetti di

comunicazioni all’interno di processi di workflow, e-commerce e altri processi aziendali.

Altro utilizzo utile all’interno delle aziende legato al contesto delle videoconferenze è la

possibilità di creare nel browser una connessione video real-time con un altro device che

supporta WebRTC o un server WebRTC attraverso il procotollo RTP(acronimo e piccola

definizione ).

• Public Web Apis: attraverso l’uso di queste semplici interfacce software si possono

esporre dati, interi processi di business e funzionalità applicative, basandosi sui principi

dell’architettura Web-oriented( WOA ). Le aziende fornendo queste Api possono

espandere la loro offerta di servizi attraverso siti web di terze parti o applicazioni mobile,

e ottenere una connessione B2B facilitata, migliorando l’integrazione con i propri partners.

È possibile raggiungere un elevato numero di clienti grazie alla diffusione delle Api

attraverso il web, il mobile e le piattaforme social. I benefici per le aziende nell’ esporre

servizi attraverso queste interfacce sono la possibilità di aumentare l’interoperabilità e

l’integrazione dei processi e i servizi esposti con partner B2B attraverso il web.

• Big data: I big data sono un insieme di dati di grandi dimensioni, che vengono

creati con frequenza elevata e sono eterogenei. Essi necessitano di essere gestiti in modo

efficiente, e attraverso forme innovative di elaborazione sfruttarne le informazioni che

sono contenute il cui accesso deve essere quanto più possibile disponibile in breve tempo.

La necessità di gestire grossi volumi di dati eterogenei ha fatto emergere un insieme di

soluzioni hardware e software innovative per l’accesso,la lettura, la presentazione e

l’analisi. Esempi di sorgenti di big data sono le tecnologie utilizzate dalle aziende a livello

operativo, il logging in internet, social media e sorgenti streaming. In termini di volume


12

invece, la crescita delle tecnologie mobile sta generando l’incremento della mole dei dati,

dovuta al fatto che l’accesso alla rete è consentito sempre più in mobilità, rispetto al

recente passato basato sull’accesso tramite desktop e laptop. L’approccio innovativo che si

sta cercando di perseguire è la gestione integrata di tutte le tipologie di dati, a differenza

della visione odierna che prevede l’integrazione solo di alcuni tipi di dati,a causa delle

limitazioni tecnologiche. Le tipologie dei dati da dover integrare ed analizzare vanno da

dati completamente destrutturati fino a documenti interamente strutturati. Si intende

sviluppare tecniche innovative che effettuino l’elaborazione dei big data in stream e non

solo attraverso processi batch, e che permettano di accedere ai dati in diverse maniere, ed

esempio non solo in modo tabulare o testuale. Le aziende che producono grossi volumi di

dati nei loro processi di business e hanno difficoltà nel gestire la memorizzazione e

l’accesso alle informazioni contenute, possono sfruttare le soluzioni proposte dai vendors

al fine di migliorare la qualità delle analisi di tutti i dati prodotti sia azienda che attraverso

il web, come ad esempio i dati provenienti dai social media e portali commerciali.

• Mobile web application: Questo tipo di applicazioni client server possono essere

accedute da qualsiasi dispositivo mobile con un web browser. Attraverso l’uso di HTML e

AJAX ( Asinchrous javascript and xml ) , e sfruttando le features introdotte nel processo

di standardizzazione di HTML5, offrono un’usabilità ed una user experience molto vicine

a quelle ottenute attraverso l’uso di plug-in ad hoc creati per le RIA (rich internet

application), come Flex, Silverlight e JavaFx. Le aziende possono offrirle in parallelo o in

maniera esclusiva alle applicazioni mobile native, per essere accessibili da tutti i

dispositivi mobile. La necessità delle aziende di utilizzare le applicazioni web mobile è il

voler raggiungere il maggior numero possibile di clienti, indipendentemente dal sistema

mobile che essi adottano. L’uso delle mobile web application permette di gestire la

frammentazione del mercato mobile, composto da diversi sistemi operativi, che è in

continua evoluzione. L’unica problematica da gestire nello sviluppo di questo tipo di

applicazioni consiste nel diverso supporto fornito alle features di HTML5 da parte dei

browser. La diffusione del rendering engine web kit nei browser mobile permetterà di

minimizzare questa criticità nella portabilità completa delle mobile web application.


13

• HTML5: è la nuova versione dello standard HTML in corso di standardizzazione da

parte del consorzio W3C. Attraverso questa nuova versione, insieme a javascript e CSS3,

si vuole fornire un insieme di caratteristiche innovative ai siti web. In questo modo si

possono ottenere usabilità e user experience avanzate senza dover ricorrere a software di

terze parti da installare nel browser, come nel caso delle RIA (Rich Internet Application).

HTML5 è un insieme di features, ognuna delle quali può essere utilizzata isolata o

connessa ad altre per ottenere dei benefici specifici nelle applicazioni web. Esempi di

utilizzo sono inserimento di audio e video tramite tag, uso di web sockets, web workers,

ecc… Essendo il processo di standardizzazione ancora in corso, le specifiche definite

possono subire cambiamenti, ma aspettare la maturazione completa dello standard

potrebbe essere un errore per le aziende che vogliono utilizzare HTML5 nelle proprie web

application. I browser stanno fornendo un supporto crescente allo standard, guidato dai

dispositivi mobile e a seguire le piattaforme desktop. I benefici dell’uso di HTML5 da

parte delle aziende consistono nel fornire applicazioni web, sia mobile che desktop, per

clienti partners o dipendenti che possono valersi delle nuove specifiche per incrementare

le caratteristiche da fornire, in termini di usabilità e user experience.

• Semantic web: Il web semantico è una definizione creata per indicare l’accesso alle

risorse del web in maniera leggibile dalle macchine. Attraverso l’uso di diverse tecnologie

a supporto si vuole passare ad un web basato su documenti a un web basato su dati, che

possono essere ricercati ed acceduti tramite l’aggiunta di metadati che ne descrivono la

struttura e il contenuto. Le tecnologie utilizzate per aggiungere informazioni semantiche ai

dati del web permettono di definire proprietà e relazioni tra le informazioni prodotte.

Anche se standardizzare il processo e le tecnologie per creare il web semantico non è

facile, la diffusione dei social networks e dei social tagging utilizzati in face book,

Youtube, Twitter, e altri può portare ad una facilitazione e una velocizzazione della

creazione di questa nuova visione del web. Gli utenti del web aggiungono tags semantici

sia in maniera diretta che indiretta, aggiungendo links ad altre risorse e siti per qualsiasi

cosa vogliono comunicare, o aggiungendo commenti a topics o discussioni sui social

networks . I benefici per le aziende che il web semantico può portare sono diverse. Poter


14

condividere informazioni attraverso il web in maniera leggibile ed interpretabile dalle

macchine permette di aumentare l’interoperabilità della applicazioni e dei siti web,

potenziare la ricerca automatizzata di informazioni nella rete globale, effettuare ricerche

efficaci basate su contenuto. Attraverso l’uso del tagging dei dati basato su vocabolari, le

ontologie del web semantico permettono di creare concetti sofisticati, creare relazioni tra

sistemi sulla base di insiemi di dati che non sono esplicitamente definiti, migliorando la

qualità della gestione dei contenuti, l’accesso alle informazioni, l’interoperabilità tra i

sistemi e l’integrazione dei database.

• Cloud computing: Esso consiste nel fornire come servizio l’accesso e l’utilizzo di

risorse IT scalabili e configurabili, che vengono distribuite attraverso tecnologie web. Le

aziende attraverso il modello di servizio del cloud possono aumentare “on the fly” capacità

e possibilità di utilizzo delle risorse IT, sia software che hardware in base al servizio

acquistato. Esistono diverse configurazioni di servizi basati sul cloud a cui le aziende

possono accedere in base alle esigenze del proprio business: software as a service,

infrastracture as a service e platform as a service.

• Software as a service: con questo termine di indica un modello di distribuzione di

software applicativo basato sul cloud il cui vendor permette l’accesso tramite il web a un

numero elevato di clienti attraverso infrastrutture e tecnologie di back-end multiutente e

scalabili. Questo approccio permette ai clienti, che possono essere sia clienti customer che

aziende esterne, di poter usufruire dell’applicazione senza costi iniziali di acquisto di

hardware e licenze software; per i Vendor delle applicazioni gestite in cloud questa

struttura permette una gestione centralizzata dell’applicazione, diminuendo i costi di

manutenzione e supporto ai clienti.

• Infrastructure as a service: con questo termine si indica l’accesso on-demand a

capacità di calcolo offerte come servizio da un service provider. Può essere utilizzato dalle

aziende per sostituire l’acquisto di server e data center propri con l’accesso in remoto

attraverso le tecnologie web o reti private alle risorse richieste. Le risorse risiedono in

remoto e sono accedute in maniera configurabile e condivisa. Alcuni scenari d’uso di

questo tipo di servizio sono: Web hosting, utilizzo di grosse risorse di calcolo necessari in


15

determinati software, utilizzo dell’infrastruttura per sviluppo e test. Gli scenari più maturi

in cui viene utilizzato questo tipo di servizio sono l’hosting di siti web o di applicazioni

web-based, e l’utilizzo dell’infrastruttura come back-end di applicazioni mobile. I

maggiori benefici nell’adozione di questo tipo di servizio sono la riduzione dei costi

nell’accesso a risorse IT, soprattutto per le piccole e medie aziende, sia per l’acquisto che

viene gestito in dipendenza con le proprie esigenze che per la manutenzione dei sistemi

che viene gestita dal service provider.

• Platform as a service: Con questa definizione di servizio si intende l’offerta alle

aziende di capacità di calcolo e di un ampio range di applicazioni che forniscono alle

aziende servizi di infrastruttura per sviluppare, testare, implementare e gestire le

applicazioni aziendali senza i costi e la complessità associati all'acquisto, la

configurazione, l'ottimizzazione e la gestione dell'hardware e del software di base. La

piattaforma viene distribuita tramite un approccio cloud-centric. I benefici per le aziende

nell’uso di questo servizio sono una maggiore interoperabilità e integrazione dei processi e

dei dati all’interno dell’azienda che vengono gestiti da applicazioni sviluppate sulla

piattaforma con l’ausilio di meccanismi di interazione e cooperazione; inoltre vengono

diminuiti i costi di manutenzione e gestione di hardware e software.

• WOA: L’architettura orientata al web è un sottotipo dell’architettura orientata ai

servizi (SOA) che sfrutta ampiamente le tecnologie web. Essa enfatizza il concetto della

generalità delle interfacce attraverso l’uso di cinque costrutti: l’identificazione delle

risorse (ad esempio utilizzando uniform resource identifier [URI]), manipolazione delle

risorse attraverso una loro rappresentazione (esempio utilizzando metodi HTTP), uso di

messaggi auto-descrittivi (esempio uso dei tipi Multipurpose Internet Messaging

Extensions [MIME] ), hypermedia come motore per gestire lo stato delle applicazioni

(esempio links) e la neutralità dell’applicazione. Questo tipo di architettura viene spesso

riferita come rapresentational state transfer (REST). L’architettura WOA ha dominato le

implementazioni user-to-application (U2A) per anni. Essa è usata di frequente per

comunicazioni internet di tipo B2B, ed è stata utilizzata con successo in alcuni casi per

comunicazioni intraenterprise application-to-application (A2A). Alcune aziende hanno


16

scelto questo tipo di architettura in aggiunta o in sostituzione dei Web Services. I maggiori

benefici che le aziende possono ottenere dall’utilizzo di questo tipo di architettura sono un

significativo incremento della condivisione ed estendibilità dei servizi offerti dalle aziende

attraverso il web enfatizzando la neutralità rispetto alle applicazioni delle interfacce e

l’accesso orientato agli hypermedia; inoltre questo approccio permette di velocizzare

maggiormente l’integrazione tra le applicazioni, diminuire i costi e sforzi nelle modifiche

di applicazioni e sistemi ed aumenta la riusabilità dei servizi.

• MADP: Mobile application development platforms sono delle piattaforme che

forniscono una serie di servizi integrati per gli sviluppatori di applicazioni mobile. Esse

forniscono servizi per progettazione, codifica, integrazione, testing, pubblicazione, e la

gestione delle applicazioni mobile di tipo business-to-consumer ( B2C ), business-to-

business ( B2B ) e business-to-employee ( B2E ). I vendors di queste piattaforme

rilasciano di solito toolkit nativi, web e cross-platform. Questo tipo di piattaforme

rappresentano l’evoluzione e la convergenza di mobile consumer application platforms (

MCAP ) e mobile enterprise application platforms ( MEAP ). I benefici per le aziende

nello sviluppo di applicazioni con queste piattaforme sono la possibilità di incrementare la

produttività in caso di applicazioni per i dipendenti aziendali, o aprire l’azienda a nuove

opportunità di business sul canale mobile, sia in via di applicazioni web che applicazioni

native o ibride. In entrambi i casi il fattore determinante nella convenienza di utilizzare

queste piattaforme è legato alla rapida diffusione di smatphone e tablet nei prossimi anni.

All’interno di questo insieme di tecnologie che le aziende possono acquisire e inserire

nelle proprie attività e infrastrutture, si nota che molte di queste tecnologie sono

strettamente connesse al contesto mobile. Il suo sviluppo, in termini di dispositivi

acquistati e di innovazioni che vengono introdotte con elevata frequenza, lo rende uno tra i

maggiori settori su cui le aziende possono investire al fine di incrementare guadagni,

aumentare l’efficienza dei processi e far evolvere e sviluppare l’insieme di attività che

possono migliorare con l’approccio mobile. Il mobile odierno è incentrato sul paradigma

app-oriented, ossia sullo sviluppo di applicativi mobile per poter fornire servizi e


17

funzionalità in qualsiasi settore aziendale e in tutti i tipi di interazioni: B2B, B2C e B2E.

Un’azienda che vuole in questo momento investire nel mobile e nello sviluppo di

applicativi a supporto delle proprie attività , deve gestire la frammentazione del mercato

sia dei dispositivi che dei sistemi operativi. Questa duplice frammentazione comporta un

aumento dei costi di sviluppo e di manutenzione nel tempo delle applicazioni mobile

multipiattaforma, cioè se l’azienda vuole fornire applicativi che siano eseguibili su un

vasto numero di piattaforme, sia hardware che software. Un’azienda che intende realizzare

applicativi multipiattaforma deve quindi identificare i dispositivi hardware da utilizzare

come punto di riferimento nello sviluppo delle applicazioni , e identificare i sistemi

operativi che intende supportare. Di seguito viene proposta un’analisi di mercato

incentrata sul tablet, che secondo stime di settore diventerà in futuro il dispositivo più

utilizzato in ambito mobile, e un’analisi delle caratteristiche dei sistemi operativi mobile

IOS e ANDROID che attualmente detengono le fette più grandi del mercato dei sistemi

operativi mobile; in questa analisi viene descritto anche Windows 8, sistema operativo

della Microsoft che con un approccio innovativo cerca di integrare il contesto mobile e

quello desktop, fattore importante che permette un’integrazione del lavoro in mobilità e da

ufficio.

1.2. Il tablet

Il tablet è, in ordine cronologico, l’ultimo tipo di device introdotto nel mercato mobile

dopo il laptop, il netbook e lo smartphone. Esso è stato prodotto inizialmente dalla Apple

con sistema operativo IOS, ma in poco tempo questo dispositivo è stato proposto da

diversi vendors su diversi sistemi operativi. Le sue caratteristiche peculiari sono uno

schermo che varia tra i 7 e i 10 pollici di tipo touchscreen, attualmente quasi sempre

capacitivo, e una potenza di calcolo mediamente superiore a quella degli smartphone (ad

eccezione di smartphone di ultima generazione di fascia alta del mercato ); ulteriori

caratteristiche hardware che vengono aggiunte, come il gps o la fotocamera, variano in

base al modello e alla fascia di mercato. Secondo Gartner lo schermo di un tablet, per

essere definito tale,deve essere di almeno 7 pollici. Rispetto ai PC portatili i tablet

presentano migliori caratteristiche di portabilità anche grazie ad una maggiore durata della


18

batteria, d’altro canto,però, possono risultarne meno performanti in alcune specifiche

attività e mancare di qualche caratteristica. Per quanto riguarda la connettività si trovano

in commercio tablet dotati di sola connessione WiFi ed altri dotati di sim telefonica, che

ne consente la connessione 3G e, in taluni casi, anche la possibilità di effettuare/ricevere

telefonate ed SMS. La caratteristica principale del tablet è abbinare quindi una elevata

mobilità l’utilizzo del display e della esperienza touch nelle applicazioni, che usufruendo

delle dimensioni dello schermo sufficientemente grandi e dei sensori, permettono di

ottenere scenari di utilizzo innovativi. Il tablet quindi può essere utilizzato sia come

dispositivo multimediale e di consumo, sia come strumento di lavoro. In quest’ultimo

contesto si stanno introducendo delle features aggiuntive, come la docking station, che

permettono una migliore adattabilità del tablet in ambito lavorativo.

1.2.1. Storia

Nonostante il tablet sia stato lanciato sul mercato con risultati vincenti nel 2010, la sua

concezione risale alla fine degli anni ottanta, quando la penna e lo schermo tattile, già

presenti nei calcolatori e pc fissi, riescono ad essere inseriti in dispositivi portatili grazie

all’evoluzione dei microprocessori e soprattutto delle batterie. Nel 1968, il ricercatore

Alan Kay dal centro Xerox PARC stava lavorando su un progetto che assomigliava molto

al tablet odierno: il Dynabook. Inizialmente questo era pensato come dispositivo per

bambini, ma non riuscì a conquistare il mercato. Nel 1994, 30 anni dopo il Dynabook, la

Fujitsu lancia il tablet Stylistic, il primo ad offrire Windows 95 come sistema operativo.

Verrà utilizzato dai presidenti del G7 all’incontro di

Halifax nel 1995.Negli stessi anni l’azienda DEC creò il

tablet Lectrice, dedicato a leggere i file di testo. Nel 2000

viene presentato il tablet dell’azienda 3Com con il

nome di Audrey (Figura 1). Questo dispositivo era

pensato per la navigazione su internet con antenna e

Figura 1: iPad

Figura 2: Tablet Audrey


19

tastiera wireless. Il 7 novembre 2002 la Microsoft presenta ufficialmente i tablet pc e il

nuovo sistema operativo Windows XP Tablet Pc Edition, versione potenziata di Windows

XP Professional, che consente l’inserimento dei dati non solo da manoscritto ma anche

tramite voce. Nel 2003 Arrivano i tablet Intel Centrino; tutti i principali produttori di pc

hanno almeno un tablet a listino, mancano solo Dell e Sony; il prezzo medio è superiore ai

2000 euro, non sono esposti o in vendita in nessun negozio fisico, è quasi impossibile

vederli e testarli prima dell’acquisto. Il destino dei tablet è destinato a cambiare quando

nel 2010 Apple lancia l’iPad, il primo tablet ad aver ricevuto un successo incredibile,

superando tutte le previsioni, vendendo decine di milioni di pezzi (Figura 2). Il device di

Apple ha dato l’avvio alla moderna scalata al successo mondiale dei tablet.

1.3. Analisi di mercato

Il quadro generale del mercato , sia dektop che mobile, dal 2007 (data di produzione

dell’IPhone) ad oggi si è evoluto in maniera radicale. Nel periodo in cui venivano prodotti

i primi tipi di smartphone i Pc avevano la posizione di leader come device

nell’information tecnology, con Microsoft quasi monopolista nei sistemi operativi, Intel

leader nel mercato dei microprocessori e HP aveva acquisito da poco il ruolo di leader

nella vendita dei Pc sostituendo la Dell, venendo insidiato solo dai vendors asiatici nella

fascia bassa di mercato. L’apparizione dei primi tablet non aveva destato alcun interesse.

Apple, dopo il rischio di fallimento negli anni 90, stava crescendo, praticamente senza

concorrenti, con l’iPod e con il sistema software e commerciale iTunes costruito attorno

ad esso; stava inoltre recuperando terreno con il Mac nella fascia alta dei PC. Nokia

regnava incontrastata (con circa il 40% su scala mondiale) nel mercato dei cellulari e in

quello in fase di sviluppo degli Smartphone, ove RIM, con il suo Blackberry, si era

ritagliata una nicchia nel settore business. I social network erano apparsi da qualche anno

all’orizzonte, ma la loro popolarità non era ancora esplosa. Il cloud computing esisteva

ma, tranne poche eccezioni, si era ancora a livello di progetti di ricerca (ICT4Executive).


20

1.3.1. Analisi device mobili

Smartphone e tablet sono i protagonisti dell’attuale successo del mercato mobile: secondo

i dati forniti da Gartner, società multinazionale leader mondiale nella ricerca e analisi nel

campo dell’information tecnology, nel secondo trimestre del 2012 sono stati 153.9 milioni

gli smartphone venduti, in crescita del 42.1% rispetto ai 108.3 milioni di unità dello scorso

anno; per quanto riguarda i tablet, invece, sono state 388.950 le unità vendute, in crescita

del 90.5% rispetto alle 204.150 unità nello stesso trimestre dello scorso anno. Questi

ultimi dati sono stati resi noti da SIRMI, società di Consulenza, Ricerche e Analisi di

Mercato, specializzata nel settore della digital technology, che ha da poco pubblicato i

risultati sul monitoraggio dei dati relativi all’andamento del secondo trimestre del 2012:

come rappresentato nella Tabella 2, il mercato dei Client evidenzia, rispetto al

corrispondente trimestre del 2011, un incremento complessivo del 4% circa

(corrispondenti a circa 1.485.000 unità vendute) nonostante quasi tutte le tipologie di

prodotto registrino un trend negativo, con la peggiore performance a carico dei Netbook (-

68,3%). Registrano un incremento solo le vendite di tablet (+90%) e NoteBook

professionali (+6%)

Unità consegnate

Unità consegnate

Variazione % Quote % Quote % Q2.11 Q2.12 Q2.11 Q2.12 DT Consumer 109.000 92.550 -15,10% 7,60% 6,20% DT professional 255.900 242.810 -5,10% 17,90% 16,30% NB consumer 392.200 390.250 -0,50% 27,50% 26,30% NB professional 287.000 304.100 6,00% 20,10% 20,50% Netbook 164.300 52.100 -68,30% 11,50% 3,50% Tablet 204.150 388.950 90,50% 14,30% 26,20% Thin client 5.400 5.290 -2,00% 0,40% 0,40% Totale PC Client 1.427.350 1.485.120 4,00% 100,00% 100,00%

Tabella 1: Analisi di mercato PC Client Q2.12 (SIRMI)

Stando alle previsioni Gartner (Figura 4), i tablet continueranno ad avere un ruolo

dominante, in termini di unità vendute e tassi di crescita, nel mercato client anche nel

futuro. Si stima infatti che nel 2016 questi device raggiungeranno a livello mondiale oltre

le 300 milioni di unità vendute, di poco inferiore a quelle dei mobile pc (327 milioni).


21

12%

24%

14%

50%

Mercato client 2016 (W.E.)

Desk-‐based PC

Mobile PC

Ultramobile Notebook

Tablet

Figura 4: Gartner. Previsioni mercato client europeo

Figura 5: Gartner. Quote di mercato dei dispositivi nel mercato europeo 2016

Lo sviluppo del mercato mobile, con la diffusione di smartphone e tablet, congiuntamente

allo sviluppo della banda larga e del wifi, contribuiranno alla crescita del traffico internet

mobile, che, stando alle previsione fornite da Cisco, crescerà entro il 2016 di ben 18 volte,

raggiungendo un volume dati annuale di 130 exabyte (1018 byte). Nel 2011, il 22% del

traffico IP è stato originato da dispositivi diversi da pc, ma entro il 2016 tale quota

crescerà fino al 31%. Nel 2011 solo il 6% del traffico internet consumer è stato originato

da dispositivi diversi da pc, ma entro il 2016 tale quota crescerà al 19% (con un CAGR del


22

2011 2016 MBs per month MBs per month

4,3 108

71 266

150 2576

750 2880

517 4223

2131 6942

Non SmartphoneM2M

SmartphoneE-‐Book Reader

TabletLaptop

0,61,3

2,4

4,2

6,9

10,8

0

2

4

6

8

10

12

2011 2012 2013 2014 2015 2016

Exabytes per month

Exabytes per month

26%). Il traffico proveniente da dispositivi wireless supererà il traffico proveniente da

dispositivi cablati entro il 2016, raggiungendo il 61% del traffico IP, in aumento rispetto al

45% del 2011.

Figura 6: Global mobile data traffic (CISCO)

Figura 7: Previsioni traffico IP 2016 (CISCO)

1.3.2. Sistemi operativi mobile

Stando ai dati pubblicati da IDC, Tabella 3, sul monitoraggio del mercato Mobile1,,

Android e iOS dominano il mercato dei sistemi operativi mobile, detenendo

congiuntamente oltre l’80% del mercato. Leader di mercato è Android che detiene il 59%

del mercato con un venduto complessivo di 89.9 milioni di device, registrando una crescita

del 145% rispetto al primo trimestre di un anno fa. Segue iOS, con 35.1 milioni di unità 1 Worldwide Quarterly Mobile Phone Tracker di IDC


23

vendute, e in termini di share il sistema operativo di Apple cresce da 18.3% al 23%.

Symbian è il sistema operativo che ha marcato il declino più forte nell’ultimo anno

(risultato generato soprattutto dalla decisione di Nokia di passare da Symbian a Windows

phone); in calo anche la domanda dei dispositivi Blackberry. Linux continua a mantenere

in modo stabile la sua presenza limitata sul mercato, grazie soprattutto al supporto di

Samsung per Bada. Windows phone/Windows mobile non ha ancora trovato la sua strada

per emergere, ma il 2012 potrebbe essere l’anno della svolta, soprattutto grazie alla

collaborazione Nokia-Windows e al lancio di Windows 8.

Sistema Operativo Unità consegnate Unità consegnate

Variazione % Quote % Quote %

Q1.11 Q1.12 Q1.11 Q1.12 Android 36,70 89,9 145,0% 36,1% 59,0% iOS 18,60 35,1 88,7% 18,3% 23,0% Symbian 26,40 10,4 -60,6% 26,0% 6,8% BlackBerry OS 13,80 9,7 -29,7% 13,6% 6,4% Linux 3,20 3,5 9,4% 3,1% 2,3% Windowd phone7/ windows mobile 2,60 3,3 26,9% 2,6% 2,2% Other 0,30 0,4 33,3% 0,3% 0,3% TOTAL 101,6 152,3 49,9% 100,0% 100,0%

Tabella 2: IDC.Analisi di mercato sistemi operativi mobile 2012

1.3.3. Mercato tablet

Il mercato dei tablet è caratterizzato da un tasso di crescita della domanda molto elevato, e

da una cadenza in termini di innovazione, modelli e specifiche hardware che vengono

prodotti altrettanto elevata. Dall’ultimo rapporto fornito dalla Gartner, emergono dati

interessanti sul mercato dei tablet e sulle prospettive di vendita negli anni a venire. Dal

grafico sottostante (Figura 8) si può notare come nel corso del 2011 il mercato abbia

subito un incremento del 341% rispetto all’anno precedente raggiungendo le 59.870 unità

vendute, dato quest’ultimo destinato quasi a raddoppiarsi nel 2012, stando alle previsioni,


24

41%

53%

4% 2% 0%

Android

iOS

Windows

QNX

other

2012

con un’ulteriore incremento del 233%. Un mercato in continua espansione, con elevati

tassi di crescita, che si stima raggiunga le 306.584 unità di device venduti nel 2016.

Figura 8: Gartner. Previsioni di vendita dei tablet

Figura9: Gartner. Quote di mercato sistemi operativi mobili 2012

Stando alle previsioni di Gartner il mercato è destinato a cambiare nel prossimo futuro:

com’è graficamente rappresentato in Figura 10, si stima che nel 2016 iOS sia destinato a

perdere la sua posizione dominante, leader di mercato diverrà Android, con il 51% dei

dispositivi venduti, in crescita le quote del sistema operativo Windows.


25

Figura 10: Gartner. previsioni quote di mercato sistemi operativi mobili 2016

Figura 3: Confronto quote di mercato sistemi operativi mobile 2012/2016

1.4. I tablet in azienda

In Italia cresce sempre di più il numero dei lavoratori che, esercitando la loro attività lavorativa in mobilità,

necessità di accedere/produrre informazioni aggiornate attraverso l’utilizzo di dispositivi

mobili; le diverse categorie possono essere supportate da soluzioni specifiche di mobile

business. Le soluzioni mobile hanno un impatto pervasivo su tutta la catena del valore di

un’impresa, potenzialmente molte sono le attività migliorabili attraverso l’utilizzo di una


26

soluzione mobile. I benefici che queste soluzioni possono portare sono spesso

incredibilmente rilevanti; ne sono una significativa dimostrazione i valori degli indicatori

di redditività di questi investimenti: i tempi di ritorno molto brevi (spesso inferiori

all’anno) e indicatori di profittabilità molto alti. Tra i motivi per cui le aziende stanno

transitando verso il mobile ci sono la possibilità di ridurre i costi, il maggior controllo del

business, la riduzione dell’uso della documentazione cartacea nelle attività aziendali e un

aumento dell’efficacia e dell’efficienza delle forze lavoro sul campo. Cresce sempre più il

numero delle aziende che decide di introdurre dispositivi tablet all’interno

dell’organizzazione. A confronto con i “tradizionali” device mobili (Notebook, Netbook,

e Smartphone) i tablet coniugano diverse caratteristiche fondamentali della mobility

applicata al business: elevata portabilità, buona capacità di visualizzazione e potenza di

calcolo. I tablet, inoltre, si differenziano dagli altri device mobili anche per alcune

peculiarità innovative in grado di influenzare la user experience: introducono una modalità

di fruizione radicalmente diversa, abilitata all’utilizzo di schermi moultitouch, che

stravolge le tradizionali interfacce uomo-macchina (basate su tastiere e mouse); sono

“always on”, sempre disponibili e con tempi di accensione pressoché istantanei. Anche in

Italia, come testimoniato dal più recente studio della School of Management del

Politecnico di Milano sul tema della mobility, i professionisti dell’Information Technology

sembrano apprezzare queste caratteristiche del tablet, scommettendo sempre di più sul loro

futuro in azienda. Questi i risultati dello studio condotto su 230 CIO delle principali

aziende italiane: come rappresentato dal grafico in Figura , ad oggi oltre la metà dei CIO

italiani ha già introdotto in azienda dispositivi tablet (56%) e se ne ritiene soddisfatto,

mentre tra i CIO che ancora non li hanno adottati la maggioranza si dimostra intenzionata

a farlo; tra le motivazioni che hanno portato i pochi CIO (7%) ad essere reticenti

all’introduzione dei dispositivi vi sono l’assenza di personale in mobilità da supportare o

la mancata necessità nel proprio business, o la recente conclusione di progetti che

prevedano l’introduzione di altri device.


27

7%

25%

12%56%

I dispositivi tablet sono già stati introdotti nella sua azienda?

No, nessuna intenzione per ora

Verranno adottati nel medio lungo/periodo

Verranno adottati nel breve periodo

Già introdotto

Figura 12: Tablet in azienda (School of Management del Politecnico di Milano)

Confrontando i risultati con quelli ottenuti dall’edizione 2011della ricerca (Figura 13) si

rileva che il numero dei CIO che ha introdotto in azienda un dispositivo tablet è cresciuto

dal 47% al 56%, e soprattutto che la dimensione di chi non ha intensione di adottarne si è

ridotta drasticamente. Se nel 2011 un CIO su quattro si era dichiarato “disinteressato

all’adozione”, a poco più di 6 mesi di distanza i disinteressati sono scesi a meno di 1 su

10. Tra coloro che lo scorso anno si dicevano intenzionati a introdurre “a breve” o “nel

medio periodo” un tablet in azienda, oltre la metà è già passata dalle parole ai fatti dotando

il personale aziendale di tali dispositivi.


28

28%7%

15%

25%

10%12%

47% 56%

2011 2012No, nessuna intenzione per ora Verranno adottati nel medio/lungo periodoVerranno adottati nel breve periodo Già introdotto

Figura 13: Confronto risultati indagine 2011/2012 (School of Management del Politecnico di Milano)

E’ interessante notare, al fine di sottolineare la rapidità evolutiva di tale mercato, come le

esigenze, le opinioni, le scelte siano notevolmente cambiate: infatti, analizzando le nuove

risposte delle aziende che solo un anno fa si dichiaravano disinteressate all’acquisto dei

tablet, il 23% ha dichiarato di aver cambiato idea e di aver già adottato un dispositivo

tablet, il 45% ha rivisto le proprie scelte e si dichiara intenzionato all’acquisto , solo il

32% resta sulla sua posizione di scarsa utilità di tali dispositivi nella propria azienda (

Figura 14).

Figura 14: Risposte 2012 dei CIO che nel 2011 si erano mostrati disinteressati all'adozione di tablet in azienda


29

Il settore enterprise sta affrontando la transizione verso il mobile business in un intervallo

di tempo inferiore a qualsiasi altra recente tecnologia comparsa sul mercato. Questa rapida

transizione comporta rischi dovuti all’acquisizione di tecnologia che può non essere

matura rispetto a problematiche come gestione tempi e costi di sviluppo, formazione del

personale IT, esigenze e caratteristiche dei dipendenti, regole per la gestione della privacy,

rischi sulla sicurezza dei dati aziendali. Nonostante queste incertezze gli investimenti fatti

dalle aziende nelle tecnologie mobile sono cresciuti e continueranno a crescere nei

prossimi anni. Come emerso nel report del 2011 dell’Osservatorio del Politecnico di

Milano le figure professionali in azienda maggiormente coinvolte in questo cambiamento

si confermano gli executive e i C-level, dal momento che il 65% già utilizza questi

dispositivi, mentre il 33% li utilizzerà in futuro. Percentuali più basse interessano le altre

tipologie professionali: il personale di vendita è in parte già equipaggiato (29% dei casi),

ma soprattutto è destinato a ricevere un pc/tablet in futuro (65%); ancora più basse le

percentuali dei manutentori, infatti un 13% è già fornito e un 40% in attesa di diventarlo

nel breve-medio periodo. Lo stesso studio ha cercato di rilevare eventuali fenomeni in atto

di sostituzione/cannibalizzazione tra i dispositivi mobili utilizzati in azienda. Quasi 9 CIO

su 10 (88%) ritengono che i tablet andranno ad affiancarsi a gli Smartphone, riducendo il

ruolo di questi ultimi a specifiche applicazioni mobili (2 CIO su 10 ritengono addirittura

che per l’accesso a queste specifiche applicazioni mobili i tablet ridurranno in modo

significativo il ruolo degli Smartphone).


30

Figura 15: Tablet vs Smartphone (School of Management del Politecnico di Milano)

Se nel caso degli Smartphone i CIO si aspettano un affiancamento con i tablet, nel caso di

Notebook emerge la previsione di un’effetto sostituzione; quasi il 90% dei CIO intervistati

ritiene che i tablet, con riferimento ad alcune tipologie di dipendenti, prenderanno il posto

dei pc portatili.

Figura 14: Tablet vs pc portatili (School of Management del Politecnico di Milano)


31

1.5. Bring your own device

La crescita del mercato mobile e la diffusione dei dispositivi mobile nel settore enterprise,

sta portando negli ultimi anni a device mobili dalla doppia veste: personali da una parte e

professionali dall’altra; un unico dispositivo, di proprietà del personale aziendale o

concesso loro in dotazione dalle aziende stesse, utilizzato sia per attività lavorative sia per

esigenze personali. Tale fenomeno, noto come BYOD (acronimo di Bring Your Own

Device) ha una notevole incidenza sulla sicurezza dei servizi informatici aziendali con il

rischio di mettere a repentaglio informazioni riservate. Il BYOD cambierà lo scenario

dell'enterprise mobility e i CIO sono chiamati a strutturare strategicamente le policy di

gestione di questi dispositivi per minimizzare i rischi legati ai problemi di sicurezza

derivanti dall'uso improprio degli stessi sulle reti e all'interno dei sistemi aziendali. Il

BYOD spinge quindi i responsabili IT a ricercare una possibilità di equilibro tra

abilitazione e flessibilità da un lato e necessità di controllo e sicurezza dall'altro. La

Symantec, azienda californiana nota per la produzione di software destinati alla protezione

dei pc da attacchi informatici, ha commissionato uno studio ad Astraricerche per cercare di

capire abitudini e intenzioni di oltre mille dipendenti e collaboratori di aziende italiane di

medie e grandi dimensioni (da 100 ad oltre 2500 addetti). E’ emerso come molte delle

aziende in esame non abbiano stilato delle policy per regolare l’utilizzo dei dispositivi

mobili da parte dei dipendenti; in alcuni casi, inoltre, si tenta di estendere le regole relative

ai dispositivi desktop anche a quelli mobili, senza tener conto delle necessità specifiche di

questo secondo ambito.

Questi i punti più significativi della ricerca(Figura 19):

• Tra i 1.062 intervistati poco più della metà, il 54,2% ha ricevuto richiesta di

installare un software antivirus sul proprio dispositivo personale o su quello concesso in

dotazione, e solo nel 37,1% dei casi con l’obbligo di tenerlo aggiornato. Una parte di

coloro che sono lasciati liberi di decidere, sceglie di sua iniziativa di affidarsi ad un

antivirus, ma il 28,1% evita di scaricarlo o, se lo fa, dimentica di eseguire gli

aggiornamenti.

• A poco più di un quarto dei lavoratori (25,9%) viene richiesta l’impostazione di una


32

password a salvaguardia dei dati in caso di furto o smarrimento, e il 15,2% del campione è

stato invitato a non consentire l’uso dei dispositivi ad altre persone

• Nel 56,7% dei casi l’istallazione di app mobili è consentita senza alcun limite; solo

il 18.1% delle aziende vieta l’aggiunta di applicazioni al sistema rispetto a quelle

eventualmente preinstallate, mentre il 15% dei dispositivi viene configurato in modo da

impedirlo (Figura 21).

• Per quanto riguarda l’istallazione di app circa un terzo degli intervistati (38% in

relazione a device di proprietà e 30,9% per quelli concessi in utilizzo dall’azienda) è solito

scaricare applicazioni anche dagli store non ufficiali e, rispettivamente nel 9% e 16% dei

casi, è disposto ad eseguire il jailbreak per rimuovere eventuali limitazioni del sistema e

installare l’elemento desiderato.

Figura 19: Regole e sistemi di protezione imposti dall'azienda nell'uso di dispositivi personali e aziendali


33

Figura 5: Le applicazioni sui dispositive personali e aziendali utilizzati per accedere al sistema informative aziendale

Symantec sottolinea come app store non ufficiali e il jailbreak sono tra le principali cause

di minacce e malware sui dispositivi mobili. Dalla stessa analisi emergono anche dati

relativi ai comportamenti del personale aziendale al manifestarsi di un guasto, di una

violazione, di furto o smarrimento del dispositivo (Figura 21); anche in questo caso le

reazioni dei singoli risentono dell’insufficienza di indicazioni precise da parte delle

aziende.

Figura 21: I comportamenti in caso di gravi rischi per la sicurezza dei dispositivi personali e aziendali utilizzati per accedere al sistema informativo aziendale


34

Al manifestarsi di un problema che metta a rischio la sicurezza dei dati aziendali il 38.6%

degli intervistati cercherebbe supporto rivolgendosi al responsabile IT della propria

azienda. Dietro la tendenza a non chiedere aiuto al personale specializzato aziendale si

celano diversi motivi: il 32,7% dei lavoratori dichiara di non volersi sentire in difetto, il

20% pensa invece che al manifestarsi del danno potrebbe esser troppo tardi per poter

riparare; il 19,4% ammette di temere sanzioni disciplinari; seguono il 13,3% di coloro che

temono sanzioni economiche e la stessa percentuale di chi ritiene che la propria azienda

non abbia le competenze per risolvere il problema, infine si registra un 11,2% che si

dichiara preoccupato di un’invasione della privacy. Le aziende che praticano BYOD

devono disporre di policy per la sicurezza dinamiche e flessibili. Le policy per il mobile

devono essere costantemente aggiornate, in modo da poter affrontare e gestire nuove

problematiche emergenti e nuovi trend dovuti alla costante innovazione. Riportando

quanto dichiarato da Symantec, elemento fondamentale nell’elaborazione di policy

aziendali è la comunicazione ai dipendenti con aggiornamenti continui.


35

Capitolo 2 Analisi sistemi operativi mobile

Il mercato offre attualmente diverse alternative per quanto riguarda i sistemi operativi,

dall’analisi condotta su 162 CIO italiani risulta che meno di un CIO su 4 dichiara di aver

identificato un unico sistema operativo di riferimento per il futuro (Figura ) lasciando

quindi la porta aperta anche ad altri sistemi (e relativi dispositivi). Il 70% dei CIO afferma

di aver già identificato due (29%) o più (41%) sistemi operativi di riferimento, mentre solo

il 7% di non aver ancora scelto.

Figura 17: La scelta dei sistemi operativi mobile nel settore enterprise


36

Figura 6: I sistemi operativi mobile nel settore mobile

Anche nel mercato enterprise dei sistemi operativi mobili Apple iOS rappresenta, ad oggi,

la scelta decisamente più diffusa; tuttavia nel prossimo futuro questa situazione sembra

destinata a modificarsi. La natura evolutiva del mercato dei tablet, in cui sono entrati

ulteriori players, non potrà che portare a un’offerta sempre più diversificata, che

consentirà e richiederà di valutare con maggiore consapevolezza quale sia il tablet e il

sistema operativo più adatto per le specifiche esigenze dell’utente business da supportare e

per quelle dell’organizzazione. Inoltre i fenomeno del BYOD ( Bring Your Own Device)

potrebbe avere trend di crescita significativi, non compatibili con un approccio “chiuso” al

mondo dei sistemi operativi per tablet. In questo mercato oltre Google (con Android) e ad

Apple (con iOS), soprattutto in ambito business, nel futuro potranno giocare un ruolo

primario anche player come RIM (con QNX) e Microsoft (con Windows 8): il primo

facendo leva sulla penetrazione raggiunta nel mondo enterprise con altri dispositivi, e il

secondo perché vuole realizzare una crescente convergenza tra i dispositivi tradizionali

(notebook, e in generale desktop) e nuovi device mobili, in modo da poter, da una parte,

potenzialmente facilitare il porting di software tradizionali in ambiente mobile e,

dall’altra, incentivare la diffusione sul mercato facendo leva sulla user experience degli

utenti. Un tema sicuramente importante legato all’introduzione dei tablet in azienda è

quello della sicurezza dei dati presenti in questi device mobili. Infatti, l’elevata portabilità


37

dei tablet li espone al rischio di furti e/o smarrimenti più frequenti, rispetto a quanto

poteva accadere con i notebook. Per affrontare questo problema, più della meta dei CIO

intervistati intende orientarsi verso architetture web-based per applicazioni mobili,

evitando così di memorizzare in locale, sul dispositivo, dati aziendali sensibili che restano

così accessibili solo da remoto e tramite autenticazione. E’ essenziale per le aziende

dotarsi di una strategia di sicurezza solida, affiancata da un programma di

sensibilizzazione e informazione degli utenti. Uno studio2 condotto da Trend Micro in

collaborazione con Altimeter Group, Enterprise Mobility Foundation e Bloor Research

evidenzia i livelli di adeguatezza delle piattaforme mobili in fatto di utilizzo delle stesse in

ambito enterprise; valutandole sulla base di più fattori, fra cui la sicurezza integrativa,

sicurezza applicativa, autenticazione, cancellazione sicura dei dati, firewall del dispositivo,

virtualizzazione e altri ancora. Il sistema operatvo mobile più sicuro è risultato essere

Blackberry, seguono iOS e infine Windows phone e Android.

Dalle analisi effettuate emerge che il mercato dei tablet è in continua evoluzione e che

nelle aziende c’è incertezza se scegliere un unico sistema operativo di riferimento sul

quale sviluppare ed utilizzare le applicazioni aziendali o optare per un approccio

multipiattaforma. I tre sistemi operativi mobile per tablet sui quali verrà effettuata

un’analisi comparativa sono Android, Windows 8 e IOS, i quali nelle previsioni effettuate

da Gartner saranno in futuro i 3 sistemi operativi che si divideranno il mercato. Mentre

IOS e Android sono stati sviluppati principalmente per un uso in mobilità, Windows 8

vuole creare una rottura sulla divisione tra user experience e lavoro in mobilità e in

ufficio, fornendo un sistema operativo che permetta un utilizzo integrato e uniformato dei

due approcci. Questa caratteristica innovativa può permettere alla Microsoft di acquisire

fette consistenti di mercato nel settore business, di cui Apple è attualmente il leader di

mercato.

2 “Enterprise Readiness of Consumer Mobile Platforms”


38

2.1. Android

Il sistema operativo Android è stato ufficialmente presentato il 5 novembre 2007

dall’Open Handset Alliance, associazione istituita ufficialmente lo stesso anno.

Quest’ultima, capeggiata da Google, è formata da 35 membri (tra i quali operatori

telefonici, produttori di device, produttori di semiconduttori, compagnie di sviluppo

software e di commercializzazione) con lo scopo di creare standard open source per

dispositivi mobili. La piattaforma fa il suo ingresso nel mercato degli smarthphone

nell’ottobre del 2008, l’anno successivo del lancio dell’ Iphone, ma al contrario del suo

principale competitor lo scopo di Android è di abbracciare una gamma quanto più vasta di

terminali. Grazie alla sua natura open source e alla versatilità, oggi questo sistema

operativo è il più diffuso in ambito mobile, coprendo tutte le fasce di mercato di device

con caratteristiche eterogenee.

2.1.1. Caratteristiche tecniche

Android viene rilasciato con licenza Apache, una licenza di software libero scritta dalla

Apache Software Foundation (ASF) che ne consente l’utilizzo per ogni finalità. La

distribuzione, modifica e vendita sono consentite purché si specifichi con un’informativa

che si è utilizzato del software sotto questa licenza, preservando il diritto d'autore e

l’esclusione di responsabilità nelle versioni modificate. Il sistema operativo oltre alle

funzioni di base come la creazione e schedulazione dei processi, provvede a fornire tutte le

risorse del dispositivo, come la fotocamera, i dati GPS, le funzioni Bluetooth, funzioni di

telefonia e le connessioni di rete. L’architettura a livelli di Android permette di espandere

facilmente le funzionalità del sistema, in questo modo si riescono a supportare tecnologie

innovative come ad esempio l’NFC (Near Field Comunication), il riconoscimento

facciale, dell’impronta digitale e la firma biometrica. Le applicazioni che girano sul

sistema Android sono di diversi tipi; esistono una serie di applicazioni preinstallate tra cui

telefono, email, agenda, browser web, e contatti, accessibili sia direttamente come

applicazioni utente che indirettamente se richiamate dalle altre applicazioni. Le

applicazioni create dagli sviluppatori possono essere vendute tramite il market ufficiale, il

Google Play Store o distribuite attraverso siti di terze parti. Gli sviluppatori possono


39

contare su strumenti di sviluppo compatibili con la maggior parte dei sistemi operativi

desktop, comprendenti un framework SDK scritto in linguaggio Java, un simulatore di

dispositivo virtuale (ADT) e un editor visuale che utilizza XML per la creazione delle

interfacce grafiche. Grazie a questi tool in pochi anni il market ufficiale di Android si è

popolato di tantissime applicazioni e ad oggi è arrivato a contarne più di 600.000.

2.1.2. Versioni e compatibilità

Il 28 Giugno 2012 è stato presentato il dispositivo che supporta l’ultima versione del

sistema operativo Android 4.1, denominata Jelly Bean. Quest’ultima versione prosegue il

cammino intrapreso il 19 ottobre 2011, data in cui è stata presentato Android 4.0 Ice

Cream Sandwich, con il quale si è deciso di adottare un’unica versione di sistema

operativo sia per tablet che per smartphone. La versione di Android utilizzata per i tablet

era la 3.0 Honeycomb, tuttavia nel mercato sono presenti maggiormente dispositivi, sia

smartphone che tablet, che montano la versione precedente 2.3 Gingerbread. Il sito

ufficiale di Android riporta come sono distribuite le versioni di Android fra i dispositivi in

commercio e mostra che la versione 2.3 Gingerbread è diffusa con una percentuale che

sfiora il 60%, segue Ice Cream Sandwich, uscita nell’ottobre del 2011, con una

percentuale inferiore al 24%, mentre Jelly Bean conta appena l’1,8% dei dispositivi che lo

supportano (Dati raccolti durante la prima metà di ottobre 2012).

Figura 22: Distribuzione percentuale delle versioni della piattaforma Android


40

Uno dei fattori che porta le versioni più recenti a penetrare lentamente nel mercato è

dovuto al fatto che ciascun produttore di hardware deve aderire a delle specifiche di

compatibilità per rilasciare firmware corrispondenti a una versione specifica. Ogni

versione di Android e delle relative API viene corredata da un documento dove vengono

definite le specifiche di compatibilità, non opzionali, alle quali bisogna aderire. Questa

condizione garantisce il funzionamento del sistema operativo su dispositivi con

caratteristiche hardware molto diverse. Per effettuare un aggiornamento a una versione

successiva è necessario attendere il rilascio del firmware che supporti tutte le API

aggiornate e molto spesso succede che gli aggiornamenti Android avvengano in maniera

più rapida rispetto allo sviluppo dei firmware da parte delle case produttrici. Per quanto

riguarda le applicazioni, per esse è prevista una compatibilità definita “in avanti”, cioè

saranno compatibili con il 100% dei dispositivi che montano il sistema operativo target

dell’applicazione, e con tutte le versioni future; mentre la compatibilità con i dispositivi

che montano versioni precedenti di Android non è garantita. Quindi una volta aggiornato il

sistema, tutte le applicazioni installate continuano a funzionare, mentre non è detto che un’

applicazione sviluppata per versioni più recenti sia supportata da tutti i terminali in

circolazione.

2.1.3. Sicurezza

Mettere al sicuro da codice o utilizzo malevolo una piattaforma aperta richiede un robusto

impianto di sicurezza; esso è stato progettato su più strati per garantire un elevato livello di

flessibilità. La sicurezza del sistema operativo si basa sull’affidabilità fornita dal kernel

Linux, nucleo della piattaforma Android. Questo tipo di kernel è utilizzato principalmente

in contesti sensibili alla sicurezza, diventando riferimento di molte aziende e professionisti

che operano su questa tematica. Android ne estende le caratteristiche, implementando un

sistema operativo che disciplina in maniera stringente le comunicazioni tra le applicazioni;

le risorse associate ad ogni applicazione sono isolate, come ad esempio i file, la memoria,

il tempo di CPU e i dispositivi utilizzati, come fotocamera o bluetooth. Per realizzare

questo, la piattaforma si basa su un sistema di autorizzazioni, un meccanismo di

isolamento dei processi e l’abilità di rimuovere durante l’esecuzione i programmi


41

potenzialmente insicuri. Di default, le applicazioni non possono interagire tra loro e hanno

accesso limitato al sistema operativo. Oltre agli strumenti di protezione offerti dal kernel,

che identifica e isola le risorse di un’applicazione, esiste un ulteriore livello di sicurezza:

tutte le applicazioni, incluse quelle native, cioè quelle sviluppate con il sistema operativo,

girano in una Sandbox. Ciò vuol dire che vengono eseguite in un contesto protetto, con

una parte dedicata del filesystem, in cui possono scrivere i dati privati. Poiché la Sandbox è

gestita dal sistema operativo, tutti gli strati software oltre il kernel, vengono eseguiti

all'interno di questo contesto. Questo meccanismo rende il sistema intrinsecamente sicuro,

ma la filosofia di Google, che consiste nel dare massima autonomia all’utente rispetto alle

personalizzazioni sul dispositivo, impatta sulla sicurezza. Infatti il sistema espone

all’utente in maniera esplicita quali sono gli intenti delle applicazioni al momento

dell’installazione e l’utente ha la possibilità di accettare o meno le richieste relative alle

risorse che verranno utilizzate a tempo di esecuzione. In questo modo si presuppone che

l’utente sia perfettamente consapevole delle operazioni autorizzate, cosa non sempre vera

per tutte le tipologie di utilizzatori. Oltre a questa criticità ci sono fattori legati alla

distrazione e alla non sufficiente esperienza. Molte applicazioni possono provenire anche

da canali non ufficiali solitamente terreno fertile di software malevoli. Una delle cause dei

problemi di sicurezza di Android consiste proprio nell’esistenza di questi market non

controllati, anche se molti malware provengono proprio dal Google Play Store; infatti si è

manifestata la difficoltà nell’automatizzare i processi di verifica delle applicazioni. A

queste motivazioni si affianca anche il fatto che Android è open-source, ciò permette di

conoscere nel dettaglio la struttura interna del sistema operativo e delle eventuali falle e

ciò rende più semplice per gli aggressori mascherare le applicazioni. Altri fattori sono la

facilità con cui si può accedere al developer account del Market, per il basso costo di

iscrizione e i pochi controlli. Infine l’assenza di meccanismi pre-installati per la sicurezza

rende opportuna l’istallazione di software antivirus, ma ciò è completamente a discrezione

dell’utente.

2.1.3.1. Problemi legati alla sicurezza

Nonostante la robustezza della piattaforma, nel corso del 2011 Android è risultato uno tra i


42

sistemi operativi mobile meno sicuri, sollevando diverse critiche sulle sue difese e sui

sistemi di prevenzione attuati. Il report trimestrale della Intel McAfee relativo al primo

trimestre 2012 mostra che l'interesse criminale nella piattaforma mobile ha subito un

significativo incremento e che circa l’87% sulla totalità dei malware mobile registrati nei

database erano relativi al sistema operativo Android. In particolare per questa piattaforma

si è assistito a un incremento del 1.650% di software nocivi presenti nei database,

passando da 400 malware memorizzati nel quarto trimestre 2011 a circa 7.000 nel primo

del 2012. Nel secondo trimestre del 2012 la piattaforma Android ha coperto la quasi la

totalità dei malware mobile rilevati e continua a registrare una forte crescita come si può

vedere in Figura 23.

Figura 23: Malware Android rilevati (andamento 2011/2012)

Tra i malware maggiormente diffusi troviamo quelli provenienti da mercati terzi, anche se

non mancano quelli provenienti dal mercato Android ufficiale. MacAfee tra le tipologie di

malware più diffuse menziona principalmente quelle legate all'adware mobile, che

consiste in finestre pubblicitarie che appaiono durante l’esecuzione di un programma.

Questo tipo di pubblicità, usata legalmente per sostenere i costi di giochi o applicazioni,

viene utilizzata in false versioni di applicazioni popolari normalmente a pagamento, che

vengono offerte gratuitamente con lo scopo di ingannare l’utente. Queste applicazioni,

spesso illegali, contengono questo tipo di advertising al loro interno al fine di dirottare gli

utenti su link a pagamento o pubblicitari. In questo modo non si riduce necessariamente la


43

sicurezza degli utenti, ma li si espone a messaggi aggressivi che possono essere veicolo di

ulteriori problemi. Un’altra tipologia di malware segnalati dalla società McAfee sono i

trojan backdoor, cioè applicazioni che utilizzano una escalation di privilegi per installare

ulteriori applicazioni dannose sul dispositivo o inviare messaggi a tariffa maggiorata. Tra i

trojan più pericolosi vengono menzionati quelli che riescono a ottenere i privilegi per

manipolare il sistema, alcuni esempi sono malware che saturano la memoria ROM del

dispositivo, che inviano informazioni personali ad un server centrale e che addirittura

istaurano delle vere e proprie botnet, cioè fanno si che il terminale sia controllato da

remoto da un’altra entità attraverso la rete. Nel secondo trimestre del 2012 sono stati

individuati dei pacchetti che hanno l’apparenza di aggiornamenti di sistema per i

dispositivi Android, scaricabili da siti di terze parti, ma che contengono software nocivo e

nuovi malware che sfruttano account di social network fittizi per controllare il dispositivo

infettato. Durante il rilascio di una nuova versione del proprio antivirus, anche la società

Sophos Mobile Security ha effettuato uno studio sui malware più diffusi sulla piattaforma

Android confermando la tendenza che vede tra i primi quelli che imitano applicazioni a

pagamento, con il 63,4% di presenze nel totale dei campioni rilevati, seguiti dai vari tipi di

trojan più o meno pericolosi. TrendMicro, azienda giapponese impegnata nello sviluppo di

software anti malware, segnala che sono sempre di più le applicazioni presenti nel Play

Store contenenti codice malevolo che potrebbe danneggiare la sicurezza del dispositivo e

quindi degli utenti che lo utilizzano. Secondo la casa del noto antivirus lo store di Google

sarebbe passato in soli sei mesi ad ospitare dalle 5.000 applicazioni potenzialmente

pericolose nel primo trimestre del 2012 alle 20.000 nel secondo trimestre del 2012. In

particolare sono stati individuati 17 software malevoli scaricati oltre 700.000 volte prima

di essere rimossi dal market ufficiale. Attualmente Google sta cercando di arginare il

fenomeno, incrementando i controlli e istituendo regolamentazioni più rigide per chi

pubblica la propria applicazione nel Google Play Store. Inoltre nel febbraio 2012 è stato

annunciata l'introduzione di Bouncer, un nuovo strumento per rendere più sicuro il market.

Il tool effettua una scansione dettagliata delle applicazioni per rilevarne malware, spyware

o trojan nascosti. Questo ulteriore livello di sicurezza è stato oggetto di analisi da parte


44

della Trustwave's SpiderLabs che ha presentato lo studio alla Black Hat information

security conference di Las Vegas. La società ha rilevato che la soglia tolleranza di

Bouncer è molto alta, costatando come il sistema sia facilmente aggirabile e come sia

possibile superare la barriera di controlli facendo penetrare comunque software malevolo.

Android 4.1 Jelly Bean, l’ultima versione di Android, presenta passi avanti sulla sicurezza

migliorando il sistema di crittografia. Si è introdotto il supporto per la tecnologia ASLR

(Address Space Layout Randomization), che rende casuale la memorizzazione delle

strutture dati in Android. Questa casualità elimina delle vulnerabilità, rendendo più

difficile l’accesso agli hackers, in quanto risulta più ostico insediare codici malevoli, visto

che non si può prevedere dove verranno memorizzati i dati. Tuttavia risulta indispensabile

per gli utenti prestare particolare attenzione alle misure di sicurezza consigliate, come

l’istallazione e l’aggiornamento di software di protezione antivirus, l’effettuare le security

patch e il consentire i download solo da fonti attendibili.

2.2. Windows 8

Windows 8, il nuovo sistema operativo di Microsoft è stato presentato al pubblico il 26

Ottobre 2012. Tale sistema supporta sia pc desktop che tablet; esso inoltre si integra con la

versione sviluppata per smartphone, in modo da abbracciare in un unico ecosistema tre

diverse piattaforme. Esso è disponibile in quattro edizioni: Windows 8, Windows 8 Pro,

Windows 8 Enterprise e Windows RT,quest’ultimo sviluppato per supportare i processori

ARM (Advanced RISC Machine). L’edizione di Windows Phone 8, nome in codice

Apollo, sarà riservata unicamente agli smartphone. Microsoft con questo nuovo sistema

operativo vuole intraprende la sfida di unificare l’esperienza utente per ogni tipologia di

dispositivo. Infatti, una delle novità più rilevanti è l’adozione dell’interfaccia Metro,

prerogativa fino a questo momento solo degli smarthphone con Windows Phone. che viene

adesso estesa agli altri dispostivi L’interfaccia è composta di live tiles, icone simili a

mattonelle che, oltre a eseguire un'applicazione con un clic o un tocco su di esse,

visualizzano al loro interno dati aggiornati in tempo reale, senza dover necessariamente

avviare l'applicazione. Le tiles possono essere personalizzate e ridimensionate per

caratterizzare la schermata rispetto alle esigenze dell’utente. Oltre alla grafica, Windows 8


45

e Windows Phone condividono lo Store, negozio virtuale per l’acquisto/download di

software compatibili, una piattaforma per lo scambio di messaggi tra utenti Windows, il

servizio SkyDrive, per memorizzare e sincronizzare file su cloud e altre features

introdotte che permettono una maggiore integrazione ed interoperabilità tra piattaforma

desktop e mobile.


Windows è stato sviluppato per essere utilizzato su diversi tipi di architetture hardware;

diffuso su processori Intel e AMD (Advanced Micro Devices), tramite la versione 8

verranno supportati anche processori ARM, microprocessori diffusi nei dispositivi portatili

come tablet e smartphone, che permettono di ottimizzare l’uso della batteria

consentendone il risparmio energetico. Della nuova versione Windows 8, l’interfaccia

Metro costituisce l’aspetto più innovativo, perché cambia il modo con cui gli utenti

possono interagire col sistema, indipendentemente dal dispositivo. Viene supportata sia

l’interazione touchscreen che quella desktop con mouse e tastiera, mentre il classico menù

Start viene eliminato e sostituito dalla schermata Start. Quest’ultima è accessibile tramite

la nuova barra dei menù detta Charms che appare negli angoli dello schermo da qualunque

applicazione aperta in Windows. La barra Charms contiene una griglia scorrevole di tiles

che consentono di accedere alle applicazioni in stile Metro o ritornare al desktop

tradizionale dove vengono eseguite le applicazioni legacy, cioè sviluppate secondo

l’approccio già esistente su Windows. Nella schermata Start, inoltre, si possono

visualizzare tutte le applicazioni installate, sia Metro che classiche. Il passaggio tra

ambiente desktop e mobile è consentito solamente nei dispositivi che non dispongono dei

processori ARM, cioè i processori X86. Questa differenza è dovuta al fatto che con lo

sviluppo di Windows 8, si è creato un nuovo sistema operativo, Windows RT, più snello e

capace di supportare i device arm-based. Nei dispositivi in cui è presente Windows RT,

l’ambiente desktop non è presente e le applicazioni che vengono eseguite sono create

appositamente per l’architettura sottostante. Nei dispositivi con processore X86 come

desktop, laptop e tablet ibridi, ossia tablet con processore X86 che montano il sistema

operativo Windows 8 che permettono un utilizzo sia in mobilità che da desktop, per


46

ottenere l’integrazione tra i 2 ambienti, sia nell’interfaccia utente che nel tipo di

applicazioni che possono essere eseguite, si ricorre a un runtime denominato WinRT, da

non confondere con il sistema operativo Windows Rt. Questo strato software di

interfacciamento permette di eseguire applicazioni Metro su dispositivi X86. In Figura 24

è mostrata l’architettura software del sistema operativo Windows 8 per device X86:

Figura 24: Architettura software Windows 8 su device X86

Microsoft ha voluto creare questo nuovo sistema operativo per supportare i tablet e

inserirsi nel mercato in competizione con Google e Apple. Anche se ci sono tablet con

processori X86, come ad esempio il Samsung Slate 7, l’obiettivo di Microsoft con

Windows RT è supportare i device ARM con un sistema operativo mobile, come Android

e IOS, che riesca però a supportare l’utente con strumenti di lavoro peculiari di Windows,

come Office. Per questo pacchetto di software è stata rilasciata una versione per Windows

RT. Le applicazioni Metro che vengono eseguite sia su Windows RT che Windows 8

grazie alle api del runtime WinRT, a differenza delle applicazioni classiche eseguite

nell’ambiente desktop hanno per default un'unica finestra senza riquadri e barre degli

strumenti che riempiono lo schermo. Questo stile di user experience, detto immersive,

supporta diverse origini di input, come tocco, penna e mouse e tastiera; esso usa riquadri al

posto delle icone e include nuovi tipi di barre degli strumenti e di opzioni delle

applicazioni. Questa scelta grafica viene riprodotta in tutte le applicazioni Metro e nella


47

stessa interfaccia utente del sistema operativo. Le applicazioni Metro possono inoltre

condividere in maniera semplice i dati attraverso un nuovo protocollo di comunicazione

basato su un modello di contratti fra applicazioni che, oltre a facilitare lo scambio di

informazioni, inserisce un ulteriore livello di sicurezza da rispettare. I contratti fra le

applicazioni sono un nuovo strumento introdotto da Microsoft che semplifica e rende più

efficace la comunicazione fra le applicazioni in stile Metro. Esistono diversi tipi di

contratti per realizzare scenari di condivisione anche ampi e complessi fra due

applicazioni che abbiano implementato lo stesso contratto. Ad esempio i contratti di

condivisione consentono di scambiare dati e file in formati diversi e personalizzabili senza

conoscere nulla dell’applicazione di destinazione, i contratti di tipo ricerca consentono agli

utenti di eseguire ricerche nei contenuti di un'applicazione da qualsiasi posizione in

Windows e di visualizzarli all’interno dell’applicazione stessa. I contratti “selettore file”

permettono agli utenti di accedere al contenuto di un'applicazione da un'altra in

esecuzione, ciò consente ad esempio di sfogliare la galleria dei media all’interno di

un’altra applicazione. Le applicazioni Metro sono implementabili scegliendo tra più tipi di

linguaggi di programmazione supportati fra cui HTML5 e javascript, linguaggi

ampiamente utilizzati non solo nel mondo Microsoft ma anche in quello web e mobile. In

questo modo si incoraggiano gli sviluppatori a creare nuove applicazioni grazie all’utilizzo

di linguaggi web-based, permettendo a programmatori esperti in tecnologie web di poter

sviluppare applicazioni Metro riutilizzando quindi le loro conoscenze in un ambito

diverso.


Come riportato il sito dedicato a Windows 8 Release Preview, il sistema funziona con lo

stesso hardware su cui è possibile eseguire Windows 7, cioè necessita di un processore di

almeno un gigahertz (GHz), ram di 1 GB (32 bit) o 2 GB (64 bit),disco rigido di 16 GB

(32 bit) o 20 GB (64 bit) e scheda grafica Microsoft DirectX 9 con driver WDDM

(Windows Display Driver Model). Inoltre bisogna avere un tablet o un monitor che

supporta il multitouch per poter utilizzare le funzionalità touchscreen, una risoluzione

dello schermo di almeno 1024 x 768 pixel per eseguire le applicazione in stile metro e


48

accedere al Windows Store e per utilizzare la funzione di ancoraggio fra le app occorre

una risoluzione dello schermo di almeno 1366 x 768 pixel. Il sito riporta anche che la

compatibilità con le applicazioni istallate nelle precedenti versioni desktop di windows

dovrebbe essere garantita mentre le applicazioni Metro non sono retrocompatibili, cioè

possono essere eseguite solo da Windows 8. Sui processori ARM, l'edizione RT di

Windows 8 non supporta l'esecuzione, l'emulazione o la portabilità delle esistenti

applicazioni desktop x86/x64.

2.2.3. Sicurezza

Per quanto riguarda la sicurezza, con Windows 8 si introducono importanti novità. Ad

esempio con la nuova versione di Windows Defender, che era stato inizialmente creato per

proteggere il sistema Windows dagli spyware, si aggiungeranno anche funzionalità

antivirus. Gli spyware a differenza dei virus, che comprendono tutti i malware installabili

su un dispositivo, sono programmi creati esclusivamente per monitorare l’attività on-line

degli utenti e trasmettere le informazioni a una organizzazione che le utilizzerà per trarne

profitto senza consenso. Il programma, quindi, oltre a rilevare gli spyware, verificherà

anche la presenza di virus, monitorando lo stato dei software di protezione esistente e

intervenendo in caso di pericolo di sicurezza. Un'altra novità importante è Windows To

Go, una nuova funzionalità esclusiva dell'edizione Enterprise di Windows 8 che consente

di effettuare l'avvio del sistema operativo da dispositivi di memorizzazione di massa USB,

come unità flash e dischi fissi esterni, contenenti Windows 8, i programmi, le impostazioni

e i file dell'utente. Windows To Go è rivolto alle imprese: è infatti stato progettato per

consentire agli amministratori di fornire agli utenti una versione di Windows 8 su

immagine che rifletta il desktop aziendale, permettendo al personale contingente di

accedere all'infrastruttura informatica solo attraverso le impostazioni presenti nel

dispositivo di memorizzazione di massa e quindi diminuendo l’esposizione del sistema a

rischi di sicurezza. Secure Boot è una nuova funzione che i produttori di schede madri

dovranno integrare nei propri prodotti che montano Windows 8. Il suo funzionamento

consiste nell’impedire l’avvio di software non autorizzato, sia esso un malware che un

sistema operativo non certificato. Lo SmartScreen Filter è una ulteriore protezione per gli


49

utenti che consiste in un filtro per applicazioni non certificate, programmi malevoli o link

che portano a siti di phishing. Il filtro lavora con dei valori hash che il programma crea nel

filesystem locale per identificare le applicazioni. Questi valori vengono inviati a Microsoft

per controllare tramite un database che siano sicuri. E’ stato introdotto, inoltre, anche un

sistema di sandboxing, che permette di isolate tra di loro e dallo stesso Windows 8 tutte le

applicazioni Metro incrementandone la sicurezza. Le applicazioni Metro si possono

reperire dallo Store di Windows, concepito per contenere nel futuro tutte le applicazioni

ufficiali targate Microsoft. La procedura di pubblicazione di una applicazione per

Windows 8 consiste in una serie di passaggi per ottenere l’account da sviluppatore e la

certificazione da parte di Microsoft, ciò per garantire massima sicurezza e standard

qualitativi elevati. La compatibilità con le applicazioni desktop tradizionli però non

garantisce che i dispositivi non vengano infettati da malware progettati per le versioni

precedenti di Windows. Non esiste portabilità dei virus, invece, sui dispositivi ARM che

non consentono l’esecuzione delle applicazioni tradizionali su Windows 8.

2.3. IOS

IOS è un sistema operativo che supporta principalmente dispositivi mobile come

tablet,smartphone e lettori multimediali; è sviluppato e distribuito dalla Apple. La sua

prima versione è stata rilasciata sul mercato nel 2007. Il sistema operativo è progettato e

realizzato per supportare solo dispositivi prodotti dalla Apple, a differenza di altri sistemi

operativi come Windows 8, Windows RT e Android, quindi non è possibile l’installazione

su altri dispositivi mobile realizzati da altri vendors. IOS è stato sviluppato a partire dall’

OS X, sistema operativo Unix-based prodotto sempre dalla Apple per i propri sistemi

desktop. Con esso IOS condivide alla base il core sviluppato dalla Apple nel 2000,

denominato Darwin, un sistema operativo open source costruito a partire dal kernel XNU.

Grazie allo sviluppo di questo sistema operativo, prima sugli smartphone e poi sui tablet, e

del modello di business e di sviluppo delle applicazioni native, che il mobile si è evoluto

nello stato in cui si trova attualmente. Il paradigma app-oriented, ossia sviluppare

un’applicazione che deve soddisfare pochi requisiti specifici ma che sia interattiva e con

una avanzata user experience, è stato lanciato sul mercato dalla Apple con l’ecosistema


50

costituito dal sistema operativo, Itunes, software di gestione e riproduzione di contenuti

multimediali, e lo store dal quale scaricare le applicazioni. A settembre 2012 lo store

ufficiale di IOS conta più di 700000 applicazioni. L’utente interagisce con le applicazioni

e il sistema operativo attraverso gesti delle dita come swiping, tapping, e pinching, i quali

grazie allo schermo capacitivo multitouch e l’utilizzo di sensori come accelerometro e

giroscopio permettono un’interazione con la piattaforma interattiva,dinamica e adattabile a

diversi scenari di utilizzo, sia in ambito consumer che enterprise.


L’architettura software di IOS costruita sopra il core Darwin è strutturata in 4 abstraction

layer:

1- Core OS Layer: contiene le caratteristiche di basso livello sulle quali si poggiano le

altre tecnologie; attraverso l’utilizzo di una serie di frameworks, come ad esempio

Accelerate, Core Bluetooth, External Accessory, Generic Security Services, Security e

System, vengono offerti agli strati superiori una serie di servizi, che di rado però

vengono acceduti direttamente dagli sviluppatori di applicazioni.

2- Core Services Layer: contiene i servizi fondamentali di sistema che vengono utilizzati

da tutte le applicazioni. Le tecnologie principali consistono in:

• Icloud Storage: introdotto in IOS 5, è un servizio che permette alle applicazioni di

creare dati e documenti in maniera ubiqua, cioè vengono salvati su una struttura

centralizzata e il loro accesso è consentito in maniera uniforme da tutti i dispositivi

Apple, sia desktop che mobile. Ciò permette agli utenti di poter vedere ed editare

dati senza utilizzare funzionalità di sincronizzazione o di trasferimento espliciti, e

di ottenere una copia remota dei dati in caso di perdita del dispositivo.

• Automatic Reference Counting: introdotto in IOS 5, è una features a livello di

compilazione che semplifica il processo della gestione del ciclo di vita degli

oggetti del linguaggio nativo Objective-C.

• Data Protection: introdotto in IOS 4, è un servizio che permette alle applicazioni di

lavorare con dati sensibili degli utenti sfruttando tecnologie di criptazione presenti

di determinati dispostivi. Una volta che un file è definito protetto viene salvato dal


51

sistema in un formato criptato. Se il dispositivo è bloccato il contenuto del file è

inaccessibile sia all’applicazione che lo ha creato sia ad eventuali intrusi. Viene

rilasciata una chiave per decriptare il file all’applicazione quando il dispositivo

viene sbloccato dall’utente.

• Grand Central Dispatch: introdotto in IOS 4, è una tecnologia a livello di sistema

operativo che permette di eseguire task all’interno di un’applicazione. Esso utilizza

una combinazione di features core con un modello di programmazione asincrono

per ottenere un’alternativa conveniente ed efficiente all’utilizzo dei thread.

• SQLite: è una libreria che permette l’utilizzo di un database leggero ed incluso

all’interno delle applicazioni senza dover ricorrere ad un processo server esterno.

3- Media Layer: questo livello contiene tecnologie per manipolare grafica, audio e video.

Il loro scopo è fornire servizi per permettere di sviluppare applicazioni ricche dal

punto di vista multimediale in maniera semplice.

4- Coca Touch Layer: questo livello contiene i frameworks fondamentali per costruire le

applicazioni IOS. Esso definisce l’infrastruttura base e fornisce il supporto per le

tecnologie chiave come multitasking, touch-based input, push notification, gesture

recognizers, peer-to-peer services,ed altri servizi di alto livello

Una delle features più importanti introdotte dalla versione 4 del sistema operativo è il

multitasking. Esso prima della versione 4 era limitato a un ristretto numero di applicazioni

già incluse al rilascio del sistema operativo. Il suo utilizzo è permesso tramite 7 API che

vengono utilizzate in backgound:

1 Background Audio: Un’applicazione che sta eseguendo contenuti audio o video può

continuare l’esecuzione dei contenuti multimediali in background

2 Voice over IP: Un’applicazione Voip può essere sospesa e viene associata ad un

servizio che monitora la socket, in modo che quando arriva una chiamata

l’applicazione viene ripristinata come attiva.

3 Background location: attraverso servizi che vengono eseguiti in background viene

monitorata la posizione dell’utente, utilizzata dalle applicazioni attive.

4 Push notifications: tecnologia che utilizza una connessione IP costantemente aperta per


52

inviare notifiche dal server al client in modo asincrono, senza utilizzare il polling dal

client

5 Local notifications: le applicazioni possono programmare notifiche locali in momenti

predeterminati

6 Task completion: l’applicazione può richiedere al sistema tempo extra per completare

un determinato task

7 Fast app switching: Un’applicazione che non esegue codice può essere rimossa dalla

memoria centrale in qualsiasi momento

Nella versione 5 di IOS sono state introdotte altre 3 API aggiuntive:

8 Newsstand: Le applicazioni possono scaricare dati dalla rete in background

9 External Accessory: ad intervalli regolari le applicazioni possono comunicare con

accessori esterni per scambiare dati

10 Bluetooth Accessory: ad intervalli regolari le applicazioni possono comunicare con

accessori Bluetooth per scambiare dati


La versione attuale di IOS è la sesta, lanciata sul mercato il 12 settembre 2012. Non tutti i

dispositivi hardware possono essere aggiornati da una versione alla successiva del sistema

operativo. IOS supporta diversi tipi di dispositivi i quali sono denominati IDevices. Essi

includono l’IPhone, unico dispositivo smartphone che viene supportato da IOS, IPod

Touch, simile all’IPhone ma senza modulo hardware per effettuare le chiamate, ed infine

l’IPAD tablet. Gli aggiornamenti alle versioni successive del sistema operativo avvengono

tramite ITunes, ed a partire dalla versione 5 attraverso firmware-over-the-air, cioè

attraverso la rete cellulare oppure Wifi. I passaggi da una versione alla successiva del

sistema operativo tendono ad essere rilasciate una volta l’anno. Gli aggiornamenti dei

device hardware avvengono periodicamente, lanciando sul mercato una nuova versione del

dispositivo con migliorie hardware, sia a livello di componentistica che di features.

Esistono 6 generazioni di IPhone, 5 di IPod Touch e 4 di IPad; a quest’ultimo

recentemente è stata affiancata una versione ridotta da 8 pollici. L’ultima versione di IOS

supporta diversi tipi di device, come IPhone 3GS, IPhone 4, 4s, IPad 2, 3 e IPod Touch 4.


53

Il livello di features supportate però non è omogeneo, e per poter utilizzare le ultime

caratteristiche introdotte da IOS 6, come Siri, FaceTime over 3g ed altre occorre avere le

ultime versioni hardware dei dispositivi. Questo continuo aggiornamento nella

caratteristiche sia hardware che software delle piattaforme Apple, porta ad avere problemi

di retro compatibilità delle applicazioni, le quali non garantiscono che se un’applicazione

viene sviluppata su una versione del sistema operativo possa essere eseguita su una

versione precedente. Gli sviluppatori quando sviluppano un’applicazioni possono scegliere

il sistema operativo target, ed utilizzare le api di quella versione.

2.3.3. Sicurezza

Come riportato dall’articolo prodotto dalla Symantec del 2011 A Window into mobile

device security, IOS basa la sua sicurezza su 5 livelli distinti:

1- Traditional Access Control: controllo dell’accesso basato su password per accedere al

sistema.

2- Application Provenance: è un approccio in cui un’applicazione viene associata

all’identità dell’autore attraverso una firma digitale. Gli sviluppatori di applicazioni

per device Apple, sia consumer che enterprise, devono registrarsi e pagare un

abbonamento annuale. In seguito alle applicazioni viene applicata la firma, e prima di

venir distribuita sullo store ufficiale o attraverso canali interni per le applicazioni

enterprise, viene effettuato un processo di certificazione. Per le applicazioni aziendali

orientate alla forza lavoro delle aziende, viene aggiunta una ulteriore misura di

sicurezza, un certificato specifico che viene installato sul dispositivo e senza il quale

l’applicazione non può funzionare. Se il certificato viene rimosso o scade

l’applicazione non può più funzionare.

3- Encryption: salvataggio dei dati in maniera criptata in modo da prevenire perdita di

dati dovuti a smarrimenti o furti del device. È utilizzato un sistema ibrido di

criptazione; viene prima utilizzata un sistema hardware AES-256 per criptare tutti i

dati salvati sulla memoria flash del device. Poi i dati più sensibili come email e dati

personali vengono criptati da un livello aggiuntivo.

4- Isolation: le applicazioni vengono limitate nell’accesso a dati sensibili o funzionalità di


54

sistema sul dispositivo. Le applicazioni sono isolate, non possono modificare

dati,logica,ecc… di altre applicazioni. Un’applicazione non può avere accesso al

kernel del sistema operativo e non può ottenere il root-level del dispositivo.

5- Permissions-based access control: Ogni applicazione deve esplicitamente dichiarare le

funzionalità e le risorse del sistema a cui vuole accedere e viene impossibilitata ad

allargare il proprio scope. Ogni volta che un’applicazione intende accedere a

determinate risorse di sistema viene richiesta l’esplicita approvazione dell’utente. Altre

invece vengono definite una volta e vengono accedute sempre.


55

Capitolo 3 Tecnologie a supporto per lo sviluppo multipiattaforma su

sistemi mobile tablet

Lo sviluppo multipiattaforma in ambito mobile consiste nella produzione di software

progettato per supportare dispositivi diversi sia per caratteristiche hardware che sistemi

operativi. Questo processo si avvale di tecnologie e strumenti specifici e consente di

scrivere programmi che si adattano automaticamente o con sforzo minimo al contesto in

cui vengono eseguiti. L’esigenza di riuscire a sviluppare un applicativo di questo tipo è

sentita particolarmente in ambito enterprise grazie ai potenziali vantaggi che si possono

avere in termini di riduzione dei tempi e costi per realizzare e mantenere il prodotto. Infatti

negli ultimi anni la rapida evoluzione dei dispositivi mobili e la frammentazione del

mercato mobile, sia per quanto riguarda sistemi operativi che tipologie di terminali con

caratteristiche differenti, ha portato alla crescita dei costi di sviluppo e di mantenimento

delle applicazioni mobile che devono supportare diverse piattaforme.

3.1. Caratteristiche dei framework di sviluppo ed esigenze aziendali

Le aziende che vogliono produrre un’applicazione di tipo business che possa supportare

diversi tipi di terminali mobili devono gestire la frammentazione del mercato mobile, sia

per dispositivi che per sistemi operativi. In questo momento le principali piattaforme sul

mercato sul quale è possibile sviluppare applicazioni mobile enterprise sono iOS, Android,

RIM, Windows Phone, Windows 8, Windows RT, Nokia. Questo comporta il dover creare


56

una strategia per poter pianificare il modo con cui approcciarsi al multipiattaforma, in base

alle esigenze aziendali, relative ai dispositivi da supportare e ai requisiti dell’applicazione,

in modo tale da contenere i costi di sviluppo e manutenzione . Infatti sviluppare e

mantenere codice multiplo per diverse piattaforme è diventato complicato e costoso. I

possibili approcci che possono essere adottati sono numerosi ed eterogenei,ognuno con

proprie peculiarità, e nessuno è finora diventato lo standard de facto nello sviluppo

multipiattaforma in ambito mobile. La maturazione della standardizzazione di HTML5 nei

prossimi anni permetterà di utilizzare questo insieme di tecnologie open source per lo

sviluppo web come punto di riferimento nella realizzazione di siti web e web application

avanzate. Con il termine HTML5 si indica un’evoluzione dello standard che fa parte della

famiglia delle tecnologie web aperte. Esso tramite un insieme di API (application

programming interface ) innovative ed un markup potenziato permette di creare

applicazioni sul web avanzate senza ricorrere a software di terze parti, usati tramite plug-

in nei browser (esempio Flash o JavaFx). L’innovazione che verrà portata riguarderà

l’aspetto grafico e l’ interazione con l’utente, al fine di ottenere una user experience ricca,

simile a quella fornita dalle applicazioni native. HTML5 potrà essere utilizzato anche nello

sviluppo multipiattaforma di applicazioni che risiedono interamente sui dispositivi mobile

e desktop. Questa possibilità è fornita dallo sviluppo di diverse specifiche innovative, che

permetteranno di utilizzare nuove features, come audio e video in maniera nativa, oppure

l’accesso ai sensori dei dispositivi mobile tramite Javascript. Nel mercato attuale dello

sviluppo multipiattaforma nel settore mobile sono stati realizzati vari tool di supporto allo

sviluppo, ognuno dei quali offre features adatte a determinati contesti ma non a tutti, e che

quindi devono essere analizzati per poter scegliere il framework che fornisce le

performance migliori, in base all’ esigenza dell’applicazione da realizzare e le specifiche

richieste aziendali.

Le caratteristiche che i diversi tool possono fornire sono:


57

1- Ambiente di sviluppo intergrato: poter seguire tutto il ciclo di sviluppo all’interno

dello stesso ambiente di sviluppo, dalla scrittura del codice fino alla distribuzione

2- Componenti grafici per creazione dell’interfaccia utente: vengono messi a diposizione

una serie di widget e aiuti per costruire l’interfaccia dell’applicazione e la logica di

business connessa

3- Librerie aggiuntive: vengono messe a disposizione librerie aggiuntive tramite le quali

facilitare lo sviluppo di alcune funzionalità (esempio librerie per invio dati a web

service tramite chiamate AJAX)

Nello sviluppo di applicazioni multipiattaforma, è necessario analizzare i vari benefici

offerti dai determinati framework di sviluppo, per permettere all’azienda di indirizzarsi

verso uno in particolare che maggiormente si allinea con le indicazioni dei requisiti dell’

applicativo e le esigenze aziendali:

1- Numero di piattaforme da supportare: se un’azienda non avesse bisogno di raggiungere

il maggior numero di utenti e quindi si volesse focalizzare nello sviluppo di un numero

ristretto di piattaforme, potrebbe scegliere di sviluppare l’applicazione in maniera

nativa effettuando un successivo porting. In alternativa, qualora vi fosse l’esigenza di

rendere disponibile il software su più sistemi operativi si potrebbe sviluppare un sito

web mobile raggiungibile da tutte le piattaforme

2- Ciclo di vita del software: se un’azienda volesse sviluppare un software con un ciclo di

vita lungo, dovrà scegliere se gestire i costi di manutenzione in base al cambiamento

dei device e dei sistemi operativi, o voler creare un ambiente che permetta

l’adattabilità del software con poco effort

3- Costi di sviluppo: sviluppare codice nativo è più costoso di sviluppare codice in

ambiente web, e gli sviluppatori su tecnologie web sono più reperibili con un minor

costo degli sviluppatori specializzati su una piattaforma specifica, esempio Android;

ciò è dovuto al fatto che le tecnologie web sono mature e conosciute da diversi anni e

meno verticali rispetto alle tecnologie native utilizzate su un determinato sistema


58

operativo mobile. Queste ultime sono specializzate sul particolare ambiente di

sviluppo e sono state create soltanto nell’ arco degli ultimi 5 anni quindi persone

specializzate sono minori in numero.

4- User experience: rendere un’applicazione uguale per ogni piattaforma può essere

difficoltoso se si vogliono ottenere determinati scenari di interazione

5- Qualità dell’interfaccia utente: in base alla tecnologia di sviluppo si possono ottenere

interfacce utente più o meno avanzate con elementi grafici complessi, bisogna quindi

capire quanto l’interfaccia utente sia importante nell’applicazione

6- Accesso alle risorse dei device: l’accesso ai sensori dei dispositivi mobili e alle relative

interfacce per il loro utilizzo è dipendente dalla tecnologia che viene utilizzata nello

sviluppo delle applicazioni; ci sono casi in cui l’ accesso è bloccato, altri in cui è

parzialmente concesso e altri in cui si può accedere senza limitazioni alle features

offerte dai sensori e dal sistema operativo.

7- Performance: l’accesso alla capacità elaborativa del processore del dispositivo mobile

può essere più o meno efficiente in base alla tecnologia scelta; infatti ci sono

tecnologie che accedendo alle risorse del device in maniera nativa sono più

performanti in scenari complessi rispetto alle altre, ad esempio casi in cui le interfacce

grafiche son ricche di elementi. Ciò è dovuto al fatto che nelle tecnologie non native si

utilizzano strati software intermedi, ad esempio per creare gli elementi grafici avanzati,

o in fase di esecuzione devono interpretare il codice prodotto convertendolo in codice

nativo, e ciò fa calare sensibilmente le prestazioni dell’ applicazione.

Molte di queste esigenze sono in contrasto tra loro, e quindi non esiste al momento una

tecnologia che permetta una soluzione ottima che massimizzi i benefici di tutte le

componenti, ma esistono diverse soluzioni “sub-ottime” tra cui poter scegliere.

3.2. Approcci allo sviluppo multipiattaforma

Attualmente gli approcci che permettono di sviluppare un software multipiattaforma sono


59

diversi, ognuno con determinate caratteristiche a livello architetturale, prestazionale,

tipologia di processo di sviluppo adottato, strumenti a disposizione per la realizzazione e

livello di usabilità raggiungibile.

I tipi di applicazione attualmente esistenti nello sviluppo mobile possono essere

categorizzati in 5 insiemi:

Applicazioni native: sono realizzate per una specifica piattaforma con un SDK, software

development kit, ossia un framework di sviluppo con un IDE (ambiente di sviluppo )

integrato e strumenti per debugging ed emulazione.

Applicazioni web mobile: sono applicazioni server-side, costruite con una qualsiasi

tecnologia lato server per la logica di business (PHP, ASP.NET, ecc..) e per creare la

pagina di cui viene eseguito il rendering lato client sul browser. Queste applicazioni

possono fornire un aspetto più vicino a quello nativo tramite tool aggiuntivi (esempio

Jquery Mobile) che si fondono con le tecnologie web (HTML5, CSS, e JAVASCRIPT),

per visualizzare i contenuti e gestire la logica applicativa lato client. In questo tipo di

applicazioni possono esserci più contesti di utilizzo, in base alle tecnologie che possono

essere integrate nello sviluppo.

Applicazioni ibride: come le applicazioni native, vengono installate sul device e vengono

lanciate dal menu del sistema operativo, ma sono sviluppate con le tecnologie web in

aggiunta al codice nativo. Le applicazioni ibride girano in un contenitore nativo e vengono

eseguite come applicazioni native dal sistema operativo. Le pagine web che ne

costituiscono l’ interfaccia grafica sono renderizzate da un componente software,

denominato webkit, rendering engine che fornisce all’interfaccia anche i controlli del

browser, ma a differenza di quello fornito come applicazione nativa, questo viene eseguito

all’interno dell’applicazione ibrida. Lo scopo del web kit è interpretare e visualizzare a

video le pagine html e processare localmente il codice javascript. Uno strato software

intermedio che fa da bridge software permette di accedere tramite invocazioni di funzioni

javascript ai sensori del device, come ad esempio l’accelerometro o il giroscopio, e alle

funzionalità del sistema operativo altrimenti inaccessibili; questo accesso infatti al

momento è molto limitato per motivi di sicurezza nelle applicazioni web mobile che


60

utilizzano solo HTML5 e javascript, che possono accedere solo a un limitato numero di

sensori, ad esempio il GPS. Tramite l’ utilizzo del web kit e delle tecnologie html5 e

javascript è possibile eseguire lo stesso codice creato durante lo sviluppo su diversi sistemi

operativi, dovendo modificare solo il contenitore. Ciò consiste nel produrre l’applicazione

nativa eseguibile che conterrà le pagine html e il codice javascript, e sviluppare ad-hoc il

software intermedio tra javascript e le funzioni native del sistema operativo o adottarne

uno già sviluppato da terze parti.

Custom Container: con queste tecnologie si possono creare applicazioni tramite un

linguaggio proprietario e inserirle in un contenitore customizzato che viene eseguito nel

dispositivo. Il codice prodotto deve essere interpretato a tempo di esecuzione, e

l’interprete che si occupa di farlo può essere inserito nel contenitore o essere installato a

parte sul dispositivo. Nel secondo caso per far funzionare l’applicazione è richiesta

l’installazione dell’interprete. In entrambe le casistiche l’interprete a tempo di esecuzione

si occupa di convertire il linguaggio dell’applicazione in quello della piattaforma

sottostante

Cross-Compilation: con queste tecnologie si producono applicazioni trasformando il

codice scritto con un linguaggio di programmazione di origine proprietario in codice

nativo per le piattaforme di riferimento che sono supportate. Attraverso l’uso di funzioni

sviluppate ad-hoc da richiamare viene mappato il linguaggio di origine nel linguaggio di

destinazione per la specifica piattaforma per la quale creare il codice nativo equivalente

che fornisce le funzionalità richieste.

Oltre a questo insieme di tecnologie di sviluppo sono presenti sul mercato diverse

soluzioni che permettono lo sviluppo e la gestione di applicazioni mobile di tipo business

attraverso una piattaforma integrata, che fornisce una serie di servizi aggiuntivi a

pagamento. Questo tipo di soluzioni vengono denominate MEAP (mobile enterprise

application platform ).

Alcune delle caratteristiche più importanti sono:

1- Prevedono la presenza nella piattaforma di un server che fornisce funzionalità di


61

aggiornamenti OTA (over the air) e di memorizzazione dei dati privati delle

applicazioni mobile ad esso connesse

2- Forniscono funzionalità di gestione e monitoraggio dei dispositivi

3- Forniscono funzionalità di connessione con sistemi di back-end, per facilitare l’accesso

ai dati di CRM, ERP e altri tipi

4- I vendors forniscono spesso applicazioni preconfezionate che si interfacciano con

soluzioni software enterprise note, esempio SAP ERP o Oracle Financials

5- Forniscono meccanismi di sincronizzazione tra i dispositivi mobile e i sistemi di back-

end

Il motivo principale della presenza di tante tecnologie e della frammentazione del mercato

per lo sviluppo multipiattaforma è rappresentato dall’attesa da parte delle aziende della

standardizzazione di HTML 5. Infatti, esso ha lo scopo principale di unificare e di

standardizzare tutte le tecnologie web-oriented, permettendo inoltre l’utilizzo delle risorse

hardware dei device attraverso invocazioni dirette, non passando attraverso bridge o

soluzioni alternative create ad-hoc. Il processo di standardizzazione è ancora in corso e la

data definita per la fine dei lavori dal W3C (World Wide Web Consortium), consorzio a

cui compete la standardizzazione di tecnologie in ambito web, è genericamente fissata per

il 2014. Le aziende leader del mercato web, come ad esempio Google, Facebook ed

Adobe, nell’attesa hanno virato verso lo sviluppo multipiattaforma acquisendo aziende (ad

esempio Adobe ha acquisito Nitobi) oppure utilizzando tool esistenti (ad esempio

Facebook ha utilizzato per una release della propria applicazione mobile una versione

modificata di Apache Cordova, engine per costruire applicazioni multipiattaforma).

3.3. Analisi tecnologie per lo sviluppo multipiattaforma

Per sviluppare applicazioni multipiattaforma è possibile percorrere più strade, ognuna con

caratteristiche e strumenti peculiari, che permettono di massimizzare determinati fattori a


62

discapito di altri, e che quindi devono essere analizzate per poter scegliere l’approccio da

utilizzare in base alle caratteristiche richieste dall’applicativo e dalle esigenze aziendali.

3.3.1. Tecnologie di sviluppo native

Lo sviluppo di un’applicazione con tecnologia nativa produce un’applicazione per

dispositivi mobili che fornisce una o più funzionalità per uno specifico sistema operativo e

uno specifico firmware del dispositivo, quindi non può essere eseguita su un altro sistema

operativo. Per poter eseguire l’applicazione sviluppata per una piattaforma su un altro

sistema operativo è necessario effettuare un porting, ossia un nuovo sviluppo completo

dell’applicazione, partendo dai requisiti. Un’applicazione nativa è un’immagine binaria

eseguibile che viene installata sul dispositivo attraverso 2 modi: tramite l’accesso allo

store ufficiale o piattaforme proprietarie in ambiente enterprise, oppure attraverso le

tecnologie dei device, mobili o cablate, per trasferire dati (wifi, internet, usb, bluetooth,

IRDA). Il processo di sviluppo di un’applicazione nativa è molto simile per tutte le

piattaforme, come viene mostrato in Figura 25:

Figura 25: Processo di sviluppo con tecnologia nativa

Il processo di produzione dell’ applicativo parte scrivendo il codice sorgente, al quale

vengono aggiunti i riferimenti alle risorse da utilizzare (es. immagini). Il codice prodotto

tramite un ambiente di sviluppo integrato viene compilato e collegato alle librerie


63

utilizzate già esistenti, producendo in uscita il codice binario eseguibile, che viene inserito

in un package insieme alle risorse che devono essere accedute in locale dall’applicazione.

Il package viene distribuito in un formato installabile su una delle piattaforme di

distribuzione esistenti per il sistema operativo di riferimento. Tutti i sistemi operativi

principali utilizzano strumenti integrati di sviluppo, con i quali vengono realizzate, testate,

e distribuite le applicazioni:

IOS: sviluppo tramite Objective-C; il codice viene prodotto attraverso l’ ambiente di

sviluppo Xcode; in uscita dal packager viene creato un file “.app” da distribuire sull’apple

store.

Android: sviluppo codice tramite Java, C, C++,C# (gli ultimi tre linguaggi sono però

sconsigliati perché hanno bisogno di strumenti a pagamento);il codice viene prodotto

tramite l’ android sdk, intergrato interamente nell’ IDE eclipse tramite plug-in ad-hoc; in

uscita dal packager viene creato un file “.apk” che viene distribuito nel market android.

Blackberry: sviluppo codice tramite Java, il codice è prodotto tramite sdk blackberry,

integrato interamente in eclipse tramite pluging ad-hoc; in uscita dal packager viene

prodotto un file “.cod” distribuito nell’ application store.

Windows Phone: sviluppo codice tramite c#,c++, vb.net; il codice viene prodotto tramite

sdk integrato in visual studio; in uscita dal packager viene prodotto un file “.xap” da

distribuire nello windows phone market.

Windows 8: sviluppo codice tramite 2 approcci distinti: Html5,Css3, e Javascript per

creare applicazioni Metro Style, particolari tipi di applicazioni che differiscono da quelle

desktop principalmente per aspetto grafico (esempio ampio utilizzo delle Tiles , widget

grafici introdotti da Windows Phone ) e tipo d’interazione con l’ utente (perché sono

indirizzate verso il mondo mobile dei tablet); seconda possibilità tramite C#, Visual Basic


64

e XAML, o C++ e XAML (XAML è un linguaggio di markup basato su XML) per

sviluppo di applicativi Metro, o tramite gli stessi linguaggi senza l’ utilizzo di XAML per

applicativi desktop. In entrambi gli approcci si utilizza come ambiente di sviluppo Visual

Studio. Una volta lanciato sul mercato il nuovo sistema operativo windows e la

controparte mobile, lo store verrà unificato, in modo tale che ogni device Microsoft possa

accederci senza differenze.

Nonostante il processo di sviluppo sia uguale, i framework utilizzati nello sviluppo

producono codice ed eseguibili differenti, richiedendo conoscenze da parte degli

sviluppatori molto specializzate e verticali dell’ sdk di riferimento col quale sviluppano il

codice. Questo fattore comporta un aumento dei costi per effettuare porting

dell’applicazione e per gestire la manutenzione delle diverse versioni sui diversi sistemi

operativi.

I principali benefici dati dalla scelta di sviluppare l’applicazione in maniera nativa e

supportare il multipiattaforma tramite porting sono:

1- l’applicazione viene sviluppata utilizzando librerie proprietarie fornite dal sistema

operativo producendo un file eseguibile che non utilizza strati software intermedi per l’

esecuzione ottenendo prestazioni migliori in scenari complessi, soprattutto quando l’

interfaccia grafica è ricca di elementi interattivi.

2- l’utilizzo delle librerie proprietarie per avere l’accesso completo a tutti i sensori offerti

dal dispositivo, permette di creare applicazioni molto complesse e che si adattano a

scenari d’uso particolari ed avanzati, un esempio l’autenticazione tramite

riconoscimento della retina di un essere umano tramite la fotocamera del dispositivo.

3- accesso ai servizi offerti dalle applicazioni built-in, che vengono prodotte e fornite

insieme al sistema operativo, che possono fare da tramite con le API di basso livello

per un utilizzo più immediato di gruppi di funzionalità di base , esempio l’ accesso alla

lista dei contatti memorizzati sul dispositivo.

4- usabilità e user experience peculiari in base al sistema operativo di riferimento, cioè l’

interazione con l’ applicazione viene progettata anche in base alle scelte del sistema


65

operativo e del dispositivo, esempio il numero di tasti fisici presenti, unico per IOS e

variabili per dispositivi Android.

Un aspetto importante tra quelli citati è l’interazione dell’ applicazione con le risorse

hardware del device, cioè l’ insieme dei sensori messi a disposizione dello sviluppatore ,

che permettono di creare applicazioni smart, complesse e creative. L’ interazione con le

API del sistema operativo avviene direttamente, come mostrato in Figura 26:

Figura 26: Accesso ai sensori applicazioni native

L’ insieme della API offerti da ogni sistema operativo mobile sono schematizzabili a strati

(Figura 27):


66

Figura 27: Integrazione sistema operativo applicazioni native

Le applicazioni native possono quindi accedere alle risorse del sistema operativo e

hardware del device attraverso l’ invocazione di 2 tipologie di API:

API di basso livello per accedere a funzionalità base del sistema operativo , come

l’accesso e il controllo dei sensori, che permettono di realizzare funzionalità più specifiche

e che richiedono una maggiore scrittura di codice applicativo da parte degli sviluppatori

API di alto livello che permettono l’ accesso più immediato a funzionalità di maggiore

livello di astrazione, invocabili anche tramite richiesta ad applicazioni Built-in

3.3.2. Applicazioni Web mobile

Le applicazioni web mobile, sono una categoria di applicazioni client server che vengono

accedute tramite utilizzo di un applicativo browser. Vengono sviluppate principalmente

tramite tecnologie web, utilizzando quindi lato client html, css, javascript, mentre lato

server possono essere utilizzati diversi tipi di linguaggi di programmazione per fornire la

logica di business e accesso ai servizi e ai dati di back-end aziendali. Le combinazioni che

si possono ottenere tra tecnologie web e l’accesso alle risorse dei dispositivi mobile hanno

generato una serie di scenari di utilizzo:

• Websites: sono portali web raggiungibili da tutti i tipi di device, sia mobile che


67

desktop; permettono l’ identificazione del tipo di dispositivo mediante informazioni

reperibili dal browser, e che adattano l’ interfaccia utente per migliorare la fruibilità in

base alle caratteristiche del device. Per permettere questo i portali hanno una versione

desktop e una mobile raggiungibili attraverso la medesima URL, o attraverso URL

diverse tramite reindirizzamento alla versione mobile del sito.

• Web apps che interagiscono con applicazioni built-in: questi tipi di applicazioni

permettono di accedere a informazioni del device tramite l’ interazione con le

applicazioni Built-in per permettere una migliore interattività ; un esempio di scenario

d’ uso è l’ utilizzo dell’ applicazione Qrcode per poter essere indirizzati alla pagina

web di descrizione di un prodotto

• Web apps con interfaccia grafica avanzata: sono applicazioni web mobile che

tendono ad avere un aspetto grafico e un’ interazione con l’ utente abbastanza vicina a

quella fornita dalle applicazioni native, permettendo di installare sul device il

collegamento al server in modo da sembrare come un’applicazione installata sul

device; un esempio di applicazione web è quella realizzata per YouTube

• Web apps interamente scritte con html 5 e javascript: esse permettono l’ accesso ad

alcune features del sistema operativo tramite API, esempio uso di librerie grafiche per

disegnare o l’accesso a informazioni del gps per la geolocalizzazione, e possono essere

eseguite in modalità offline, cioè possono essere utilizzabili anche senza essere

connessi al server tramite la rete, attraverso l’uso di nuovi strumenti di caching e di

memorizzazione persistente forniti dalle nuove specifiche di HTML5.

3.3.2.1. Uso di HTML5 nelle Enterprise web application

Il settore enterprise può beneficiare dell’evoluzione di HMTL e delle altre tecnologie web

per creare web application di tipo business che possano supportare diversi tipi di

dispositivi e sistemi operativi. In ambito enterprise le applicazioni che vengono accedute

in mobilità devono poter supportare sia dispositivi desktop che mobile. Questo comporta

un problema di portabilità del software dovuto al differente supporto di HTML5 dei

diversi tipi di browser che vengono utilizzati in ambito aziendale, che tra desktop e mobile

sono numerosi. Il principale collo di bottiglia fino al primo quadrimestre del 2009 è stato


68

Internet Explorer 6, leader del mercato in ambito desktop per il settore enterprise, che

forniva un supporto quasi nullo a HTML5 (http://netmarketshare.com).

Nei successivi anni grazie allo sviluppo di HTML5 guidato dalla forte ascesa dai

dispositivi mobile, smartphone e tablet, il supporto dei diversi tipi di browser desktop è

migliorato e allo stato attuale il gap tra quelli più compatibili con lo standard e quelli meno

si è assottigliato. In Figura 28 è mostrato il supporto dei browser a HTML5 relativo al

periodo precedente al lancio di Internet Explorer 9 redatto da Gartner.

Figura 28: Compatibilità browser HTML5 4Q2009

Per poter essere sicuri che la propria applicazione sia eseguita allo stesso modo sui diversi

tipi di browser è consigliabile scegliere prima i target di riferimento e verificare che le

funzionalità che si vogliono utilizzare siano supportate. Per reperire dati aggiornati sul

supporto dei vari tipi di browser, sia desktop che mobile, ad HTML5 ci sono diversi siti in


69

rete che riportano statistiche aggiornate, esempio:

• http://www.html5test.com/

• http://html5accessibility.com/

• http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5)

• http://findmebyip.com/litmus

Nonostante al momento il mondo desktop e mobile possano essere visti come un unico

insieme di applicativi che accedono alle web application enterprise, considerazioni

riportate nelle le analisi di mercato e sul BYOD svolte nei capitoli precedenti permettono

di vederli separati e scegliere di dare maggiore attenzione ai dispositivi come smatphone e

tablet come target degli applicativi. In questo modo è possibile ottenere comportamenti

maggiormente uniformi dalle web application grazie al maggiore supporto dei device

mobili ad HTML5.

La scelta di sviluppare applicativi tramite HTML5 deve essere fatta conoscendo i punti di

forza e le limitazioni che al momento lo standard possiede. Tutte le caratteristiche che

HTML5 fornisce e che verranno aggiunte durante il processo di standardizzazione, hanno

lo scopo di aggiungere features al web; questo significa offrire nuovi elementi e API che

permettano agli sviluppatori di creare applicazioni con un’ esperienza interattiva e

avanzata indipendentemente dalla piattaforma su cui vengono eseguite. Nel contesto

desktop RIA ( Rich Internet Application ) plug-in per browser permettono di creare

applicazioni web avanzate, ma che non possono raggiungere il mondo mobile, perché non

installabili. Le maggiori features di HMTL5 che possono essere usate dagli sviluppatori

sono:

• Messaggi cross-document: possibilità di far comunicare pagine tra loro attraverso

domini diversi

• Canvas: possibilità di generare elementi grafici 2D e 3D attraverso Javascript

(possibile uso disegnare la propria firma in una pagina web)

• Audio: possibilità di effettuare lo streaming di contenuti audio dalle web application

• Video: possibilità di effettuare lo streaming di contenuti video dalle web application


70

• Drag and drop: possibilità di spostare graficamente elementi all’ interno di una

pagina (funziona ampiamente usata nelle applicazioni desktop)

• Applicazioni web offline: consente di effettuare la memorizzazione tramite caching

dell’ applicazione, potendo continuare ad utilizzare l’applicazione anche se la

connessione non è disponibile

• Eventi Server-Sent: possibilità di ricevere notifiche di tipo push dal server, evitando

di effettuare il polling lato client tramite javascript; questo permette un minore

ritardo all’arrivo di aggiornamenti e minore traffico scambiato in rete

• Web Storage: definisce il modo di salvare in modo persistente dati strutturati in

locale lato client

• Forms Avanzate: definizione di nuovi tipi di input per le form e meccanismi per

facilitare la validazione dei campi

• Web Workers: possibilità di eseguire script in background che vengono eseguiti in

isolamento dalla schermata principale

• Geolocalizzazione: definisce come ottenere informazioni sulla geolocalizzazione

dell’utente nella pagina web, attraverso diverse fonti come ad esempio indirizzo IP,

connessione alla rete wireless, cella a cui il dispositivo è connesso o attraverso il

sensore GPS del dispositivo

• Web Sockets: defisce il modo con cui creare un meccanismo di comunicazione

bidirezionale tra client e server

• CSS3: definisce nuove features a supporto del Cascading Style Sheet, tecnica

utilizzata per aggiungere stili alle pagine web

Il sito http://html5demos.com/ fornisce un insieme di showcase sulle potenzialità di

HTML5, che in base al browser utilizzato possono essere supportate o meno. Le

limitazioni di HTML5 con cui le aziende devono al momento confrontarsi nello sviluppo

di applicazioni web di tipo business per dispositivi mobile sono:

1- Performance: Molte delle funzionalità innovative introdotte da HTML5 possono creare

problemi di performance nelle web application, soprattutto quando vengono utilizzati


71

elementi grafici avanzati e streaming video

2- Tempi lunghi per completare la standardizzazione: Il W3C ( World Wide Web

Consortium) impiegherà ancora diversi anni per completare la standardizzazione (al

momento sul sito viene indicato 2014 come data di completamento) e durante questo

lasso di tempo HTML5 potrebbe subire modifiche nelle sue specifiche. Questo fattore

può portare i vendors dei browser a non adottare HTML5 totalmente come standard,

creando possibili problemi allo sviluppo multipiattaforma da gestire in fase di sviluppo

delle web application enterprise

3- Accesso ai sensori dei dispositivi mobile: nonostante HTML5 permetta una migliore

user experience delle applicazioni web attraverso le sue features innovative, al

momento attuale della standardizzazione esso non può accedere alla maggior parte

delle caratteristiche hardware dei dispositivi mobili, mentre le applicazioni mobile di

tipo nativo hanno un accesso totale a queste risorse

Ron Perry, CIO di Worklight, progetto della IBM per lo sviluppo di applicazioni

enterprise mobile, riporta su un articolo in rete che le tecnologie ibride sono un passaggio

fondamentale nel processo che porterà HTML5 a poter accedere alle risorse dei dispositivi

mobili. In Figura 29 è mostrato come avviene l’ interazione di un’applicazione web

mobile basata su HTML5 con il sistema operativo:


72

Figura 29: Accesso ai sensori HTML5 web application

Questo tipo di applicazioni sono eseguite all’ interno di un rendering engine, denominato

webkit, che costruisce la pagina web sullo schermo del device, e si occupa di comunicare

col sistema operativo attraverso delle chiamate API. Come si vede in figura molte delle

caratteristiche hardware del device sono inaccessibili , di colore rosso, altre sono

parzialmente accessibili, di colore rosa, e quelle verdi sono totalmente accessibili. Grazie

al lavoro del W3C in futuro HTML completerà la sua standardizzazione, e potrà accedere

attraverso le API alle risorse del device mobile, qualunque esso sia, diminuendo

ulteriormente il gap con le applicazioni mobile di tipo nativo.

3.3.3. Applicazioni ibride

Definire ibrido un oggetto, vuol dire crearlo attraverso la fusione di risorse eterogenee o di

diverso tipo. Nel caso di applicazioni mobile ibride avviene la fusione tra tecnologie web e

tecnologie native del sistema operativo. Un’applicazione ibrida è realizzata attraverso lo

sviluppo di codice tramite tecnologie web, usate nei siti web e nelle loro implementazioni

mobile, che viene incapsulato all’interno di un container nativo sul device mobile. Quindi

è una fusione di tecnologie web e ambiente di esecuzione nativo. Le applicazioni ibride


73

sfruttano la capacità da parte dei dispositivi mobile di poter renderizzare a video contenuti

prodotti con le tecnologie Web.

Attraverso una webview control (componente software supportato dalla maggior parte dei

dispositivi mobili) vengono integrati contenuti Web all’interno delle applicazioni native.

L’interfaccia utente costruita con HTML viene mostrata a pieno schermo, usando per la

sua visualizzazione un rendering engine browser denominato WEBKIT.

Esso è utilizzato in tutti i sistemi operativi mobile, eccetto Windows phone 7 e la futura

versione di Windows che continuerà ad utilizzare l’engine Trident. Il codice HTML e

javascript vengono eseguiti all’interno di un involucro nativo. La caratteristica principale

delle applicazioni ibride è l’accesso alle risorse hardware del device mobile attraverso uno

strato software che si occupa di fare da bridge software tra le API javascript e le API

native che governano i vari sensori.

Questa caratteristica non è consentita alle applicazioni web mobile a causa di limitazioni

basate sulla sicurezza che possono essere superate solo grazie alla standardizzazione di

HTML5. Lo strato software può essere realizzato ad-hoc per ogni sistema operativo,ma

esistono attualmente tool che realizzano lo strato per diversi sistemi operativi, permettendo

di sviluppare l’applicazione in html ed eseguirla come applicazione nativa per diverse

piattaforme. In Figura 30 viene mostrato come avviene l’interazione tra applicazione

ibrida e le risorse del device sfruttando lo strato software che fa da ponte, che permette

l’accesso ad un insieme di features messe a disposizione dal sistema operativo:


74

Figura 30: Accesso ai sensori applicazioni ibride

Il funzionamento di un’applicazione ibrida avviene tramite l’interazione di 2 parti:

Parte nativa dell’applicazione, che ha libero accesso a tutte le API di basso livello del

sistema operativo e quelle di alto livello, potendo comunicare con le app built-in

Parte Web dell’ applicazione, eseguita dal rendering engine, incapsulata nella parte nativa

e non nel browser del device, che può accedere alle funzionalità offerte da html 5 e

javascript.

Il collegamento tra le 2 parti viene realizzato attraverso lo strato bridge software.

I principali benefici di questo approccio sono:

• Accesso alle risorse del device

• Scrittura di codice con tecnologie web

• Scrittura del codice una volta e riutilizzarlo per sviluppare applicazioni

multipiattaforma che supportano gran parte delle piattaforme mobile

• Possibilità di utilizzo in modalità completamente offline, senza uso di caching di

HTML5

• Distribuzione attraverso i vari Stores delle piattaforme mobile

Le applicazioni ibride possono essere sviluppate in 3 modi:

1- Mettere i contenuti su un server e caricarli in base alle richieste dell’applicazione,


75

perdendo quindi la possibilità di avere l’applicazione offline e incrementando la

latenza per reperire i dati dal server

2- Inserire i contenuti all’interno dell’applicazione impacchettandoli insieme al codice

compilato e quindi accessibili in modalità offline, anche senza l’utilizzo del caching

HMTL5.

3- Un mix dei 2 modi, reperendo i dati dal server tramite chiamate AJAX , tecnologia

che riduce il traffico dati sulla rete nella comunicazione col server, andando a

recuperare solo il payload generato dall’ interazione dell’ utente con l’interfaccia

grafica e non i dati per generare le pagine

3.3.3.1. Phonegap

Phonegap è una tecnologia applicativa che permette di creare un contenitore nativo nel

quale eseguire un’applicazione mobile sviluppata attraverso linguaggi web come HTML,

Javascript, CSS. Il core della tecnologia è open source. Esso è utilizzato come strumento

di sviluppo di client mobile da diverse piattaforme mobile di sviluppo come ViziApps,

Worklight, Convertigo e appMobi. Nel 2011 Adobe acquisisce Nitobi Software,

sviluppatore di Phonegap, e rende disponibile l’accesso al software dal suo ambiente di

sviluppo Dreamweaver. Attraverso l’utilizzo del componente software web view,

utilizzato anche dal sistema operativo per il browser built-in, è possibile creare

l’interfaccia grafica dell’applicazione e le interazioni con essa basandosi sulle tecnologie

web per renderizzare i contenuti html ed elaborare le richieste utente di tipo navigazione,

interazione, manipolazione dell’interfaccia utente attraverso javascript. Phonegap fornisce

un set di api javascript che permettono l’accesso a funzionalità del sistema operativo

sottostante e l’accesso ai sensori del dispositivo attraverso invocazione da codice

javascript. Le api fornite supportano un ampio numero di sistemi operativi

(http://phonegap.com/about/feature). Il funzionamento delle api consiste in 2 parti: una

parte javascript da invocare e una nativa che si occupa di eseguire la funzionalità richiesta.

Phonegap si occupa di gestire la comunicazione tra le 2 parti dell’invocazione. Una volta

prodotto il codice dell’applicazione, esso viene distribuito come un archivio applicativo

binario in base al sistema operativo target. Ad esempio per IOS viene creato un file .IPA,


76

per Android un .APK, per Windows phone un .XAP. Attraverso l’utilizzo di phonegap è

possibile riutilizzare il codice dell’applicativo per le piattaforme supportate, dovendo solo

sviluppare il contenitore nativo.

3.3.4. Custom Container

Sviluppare un’applicazione tramite le tecnologie denominate Custom Container permette

di creare applicazioni mobile native potendo usare sia tecnologie web che un linguaggio di

programmazione e strumenti proprietari; il codice prodotto viene inserito in un container

nativo customizzato. Questo container svolge la funzione di virtual machine, cioè mappa il

codice prodotto in fase di sviluppo sulla piattaforma del dispositivo sul quale viene

eseguito. Il custom container che fa da interprete è richiesto per ogni piattaforma mobile

supportata. Viene data la possibilità di creare un’applicazione sia con il runtime incluso

nel package dell’applicazione nativa, sia senza ed usare il runtime in maniera separata; in

questo caso esso deve essere già installato sulla piattaforma sulla quale eseguire

l’applicativo. In Figura 31 è presentato lo stack applicativo della tecnologia:

Figura 31: Stack applicativo custom container

I vantaggi offerti dallo sviluppo di applicazioni attraverso questo tipo di tecnologia

consistono in:

1- Accesso ai sensori del device e ai servizi del sistema operativo attraverso le api fornite

dal framework ed estensioni native


77

2- Il numero di piattaforme nelle quali un’applicazione può essere eseguita, dipende solo

da quante vengono supportate dal runtime

3- Qualità dell’ambiente di sviluppo e del container, che permettono in maniera integrata

di sviluppare e testare l’applicazione senza l’uso degli SDK (Software Development

Kit ) nativi

4- Il contenitore customizzato risiede sul dispositivo e può accettare aggiornamenti OTA

che bypassano il controllo degli stores, diminuendo i tempi di aggiornamento

5- Riuso di codice e strumenti per produrre applicazioni per diverse piattaforme

6- L’elevata qualità dei tool a supporto rendono la manutenzione meno onerosa

7- Possibilità di essere distribuite attraverso i vari Stores delle piattaforme mobile

3.3.4.1. Adobe AIR

Adobe Air è un runtime che permette lo sviluppo di Rich Internet Application, attraverso

linguaggi web standard (HTML,Javascript,CSS ) e proprietari (actionscript), il cui codice

può essere riutilizzato incapsulandolo in applicazioni native per diverse piattaforme, sia

mobile che desktop. Le piattaforme mobile supportate sono: IOS, Android, RIM su device

tablet. Il runtime di Air fornisce una piattaforma e un framework per supportare diversi

sistemi operativi. Attraverso l’utilizzo del runtime è possibile sviluppare le applicazioni

multipiattaforma senza dover interessarsi del sistema operativo sottostante, visto che il

target del codice è il runtime che fa da interprete, ossia converte a tempo di esecuzione il

linguaggio prodotto nel processo di sviluppo in quello utilizzabile dal processore del

sistema operativo di riferimento. Attraverso l’uso di tecnologie web, sia open che

proprietarie (Flash o Flex), è possibile sviluppare applicazioni web come native senza

dover utilizzare il codice specifico per ogni sistema operativo mobile. In figura 32 è

riportato lo stack applicativo di Air:


78

Figura 32: Stack applicativo di Adobe Air

Per lo sviluppo di applicativi mobile, viene creato un file .air che contiene il codice

dell’applicazione, il quale viene eseguito dal componente runtime. Il runtime fornisce

meccanismi di bridging tra HTML/JS e Flash, inoltre permette di invocare servizi del

sistema operativo sottostante in maniera trasparente attraverso le api fornite. Le api built-

in fornite permettono di utilizzare determinati servizi del sistema operativo e consentono

l’accesso a un subset di features di basso livello del dispositivo, come gps e accelerometro.

Qualora gli sviluppatori necessitino di ulteriori features e servizi è possibile sviluppare

delle api aggiuntive denominate native extensions. Queste sono librerie che contengono

codice nativo creato ad-hoc che viene wrappato in API actionscript. Un esempio di

utilizzo è quello di inserire la vibrazione del dispositivo. In figura 33 sono riportate le

interazioni tra le native extensions, l’Air runtime e il dispositivo.


79

Figura 33: architettura native extension

3.3.5. Cross-compilation

Attraverso l’uso delle tecnologie denominate Cross-compilation si può sviluppare

un’applicazione nativa scrivendo il codice in un linguaggio proprietario, che viene

convertito in fase di compilazione nel linguaggio nativo per la piattaforma target. È

richiesta una Cross-compilation per ogni piattaforma che si vuole supportare. Questo tipo

di tecnologie forniscono una serie di API indipendenti dalla piattaforma che invocano le

API native dello specifico sistema operativo. Le API fornite da queste tecnologie si

integrano in maniera profonda con le caratteristiche e le capacità native delle piattaforme

supportate. Questo comporta un accesso maggiore alle features del dispositivo ma una

espansione del framework su diverse piattaforme onerosa, perché devono essere sviluppate

un nuovo set di API per ogni piattaforma che si intende supportare. I maggiori benefici

dati dallo sviluppo con queste tecnologie sono:

1- Sviluppo del codice dell’applicativo con linguaggi familiari agli sviluppatori (esempio

Javascript, C#, Java)

2- Le API fornite permettono un maggiore accesso alle caratteristiche e ai sensori del

dispositivo, potendo fornire quindi una esperienza utente vicina alle applicazioni

native


80

3- Creazione e interazione con le interfacce utente attraverso controlli nativi migliorano

l’esperienza utente

4- Gli sviluppatori possono usare un unico linguaggio di programmazione nello sviluppo

e poter distribuire l’applicazione per più piattaforme

5- Le applicazioni sviluppate possono essere distribuite attraverso i vari Stores delle

piattaforme mobile

3.3.5.1. Titanium appcelerator

Titanium è un framework open source utilizzato per poter sviluppare applicazioni native

per desktop e mobile usando tecnologie web come javascript, html, e css. Questo

framework utilizza in maniera combinata API javascript e codice nativo specifico della

piattaforma sulla quale viene eseguita l’applicazione. Esso permette un riutilizzo del

codice per la parte core dell’applicativo, e attraverso l’uso di codice specifico per una

piattaforma (attraverso invocazione delle API proprietarie) permette di ottenere

performance e user experience vicine a quelle native. Quindi esso non utilizza un

approccio “write once, run everywhere” ma uno del tipo “write once, adapt everywhere”,

soprattutto per la parte legata all’interfaccia utente che deve essere adattata in base alla

piattaforma target. Il funzionamento del framework è basato sulla combinazione del

codice javascript prodotto con le API proprietarie fornite che sfruttano il codice nativo per

ogni piattaforma supportata; durante la compilazione viene settata la piattaforma di

destinazione, viene analizzato e preprocessato il codice javascript e precompilato in un set

di simboli risolti in base all’utilizzo delle API di titanium. La mappatura dipende dalla

piattaforma target; ad esempio su IPhone avviene una mappatura tra le API titanium e un

file .o che è stato compilato per l’architettura ARM. Una volta eseguito il mapping viene

invocato il compilatore nativo fornito dall’SDK della piattaforma target che produce il

codice binario. Il codice javascript che si occupa dell’application logic e del codice

dinamico (esempio la modifica real time dell’interfaccia utente a seguito di un evento )

viene inserito all’interno del file binario dell’applicazione nativa e viene interpretato a

runtime dall’interprete basato sull’engine Webkit che viene invocato durante l’avvio

dell’applicazione. L’interprete si occupa di agganciare il codice javascript che viene


81

caricato come un oggetto inline con gli oggetti nativi della piattaforma sottostante. Il

mapping viene effettuato in maniera stringente uno ad uno. In questo modo le API

titanium permettono di fare da bridge per l’accesso diretto alle features native, tra cui gli

elementi nativi della UI, senza l’utilizzo del componente web view, e i sensori del

dispositivo. La comunicazione con le features native viene effettuata direttamente senza

conversione del codice javascript in codice proprietario della piattaforma, ad esempio

Object-C o Java. In figura 34 viene mostrata l’architettura del framework.

Figura 34: Stack applicativo di Titanium

Le Api titanium coprono molte delle features dei sistemi operativi supportati; ci sono però

altri servizi e caratteristiche che non sono direttamente supportate. Il framework offre la

possibilità di estendere le funzionalità attraverso moduli opzionali nativi ove ci sia la

necessità di supportare una specifica feature o ad esempio per riutilizzare una libreria

nativa già esistente. Il processo per sviluppare un modulo nativo su titanium prevede 4

passaggi:

1- Definizione della funzionalità da esporre e come essa viene invocata dal codice

javascript, quindi si definisce l’API del modulo


82

2- Creazione del progetto con gli strumenti dell’SDK nativo per realizzare il modulo

3- Implementazione dell’API

4- Build, test, debug

3.4. Confronto tecnologie di sviluppo multipiattaforma

Tutti i tipi di approcci allo sviluppo e le tecnologie utilizzabili per realizzare applicazioni

mobile multipiattaforma in ambiente enterprise hanno punti di forza e di debolezza. La

scelta della tecnologia da adottare può dipendere da diversi fattori, come le esigenze

aziendali e i requisiti dell’applicativo da realizzare. Possono essere applicati diversi criteri

e metodologie, ma la loro applicazione deve adattarsi al contesto di riferimento che può

richiedere una valutazione diversa o aggiuntiva. Viene presentata una metodologia di

supporto alla decisione denominata Analytic Hierarchy Process (AHP), utilizzata per

confrontare sotto diversi driver le tecnologie di riferimento scelte.

3.4.1. Analytic Hierarchy Process (AHP)

Per determinare quale tra le diverse tecnologie di sviluppo è più opportuno utilizzare viene

di seguito illustrato e applicato un modello di scelta multi criterio, non essendo possibile

utilizzare un metodo di ottimizzazione a causa della numerosità e diversità dei fattori che

influenzano la decisione. L’analisi multi criterio per scopo decisionale (MCDA multi

criteria decision analysis) è una disciplina orientata a supportare il decisore qualora si

trovi a operare con valutazioni numerose e conflittuali,consentendo di ottenere una

soluzione di compromesso in modo trasparente. I metodi di analisi multi criterio

supportano il decisore nella fase di organizzazione e sintesi di informazioni complesse e

spesso di natura eterogenea. Tali metodi, elaborando informazioni note e giudizi espressi

dal decisore, consentono di determinare una decisione di compromesso ( best compromise

solution/decision), permettendo dunque al decisore di selezionare l’alternativa più

coerente con la propria struttura di preferenza. In particolare, tra le diverse metodologie

MCDA, viene applicata l’ Analytic Hirarchy Process AHP.

L’AHP consente di assegnare una priorità ad una serie di alternative decisionali, mettendo

in relazione valutazioni di tipo qualitativo e quantitativo, altrimenti non direttamente

confrontabili , e combinando scale multidimensionali di misure in una singola scala di


83

priorità.(Saaty,1980:Figueira,2005)

L’AHP affronta il processo di valutazione attraverso tre fasi:

1- Scomposizione gerarchica del problema

2- Giudizi comparati attraverso confronti a coppie delle alternative ad ogni livello della

gerarchia

3- Ricomposizione gerarchica, sintesi delle priorità e verifica di consistenza

Nella prima fase, definito l’obiettivo generale, si individuano i driver (e possibili

sottocriteri che vanno a formare l’albero decisionale) che lo influenzano e le alternative tra

le quali scegliere quella che ottiene il miglior punteggio globale. Si struttura il problema

in una gerarchia.

Figura 33: Gerarchia piramidale dell'AHP, applicato per individuare la tecnologia di sviluppo di un’applicazione di riferimento

L’albero decisionale mostra graficamente la struttura dell’applicazione del metodo che

consiste nel valutare l’importanza di ogni driver in relazione all’obiettivo e ogni

alternativa in relazione ai diversi driver.

Il passo successivo è quello di comparare i vari elementi di ogni livello della gerarchia

partendo dalle foglie dell’albero. Per stabilire le priorità tra i vari elementi di ciascun

livello della gerarchia rispetto al nodo superiore si utilizza la tecnica del confronto a


84

coppie. Da questo confronto si può stabilire il grado di importanza di un elemento rispetto

ad un altro, entrambi appartenenti allo stesso livello. I risultati dei confronti a coppie

vengono aggregati in forma matriciale. Si definisce quindi la matrice dei confronti a

coppie, in cui il generico elemento aij è una stima della dominanza del primo elemento (i)

rispetto al secondo (j). Le valutazioni possono essere sia di tipo qualitativo che

quantitativo. Per determinare i valori dei coefficienti aij occorre utilizzare la scala

semantica di Saaty (Tabella 5), che mette in relazione i primi nove numeri interi con

altrettanti giudizi che esprimono, in termini qualitativi, i possibili risultati del confronto. In

caso di misure quantitative vengono utilizzati i dati ricavati di ogni elemento per la fase

successiva di sintesi e ranking.

Tab.5: Scala semantica di Saaty

I dati contenuti nelle matrici dei confronti a coppie sono utilizzati per derivare l’ordine

delle priorità tra gli elementi di ciascuna matrice, ovvero una scala di valori che esprime la

preferenza finale delle alternative confrontate rispetto al criterio di riferimento.

Per ottenere il ranking locale relativo allo i-esimo livello della gerarchia viene calcolato

l’autovettore della matrice effettuando l’elevamento a potenza della matrice e sommando

gli elementi di ogni riga. Il vettore risultante viene normalizzato in base alla somma di tutti

gli elementi dello stesso vettore. Ognuno di questi vettori delle priorità esprime le priorità

locali degli elementi rispetto all’elemento posto a livello superiore; per ottenere le priorità

globali, cioè per ottenere un ordinamento globale delle alternative rispetto all’obiettivo

finale, si procede per aggregazione e confronto dei criteri posti a livello superiore.

L’ordinamento globale si ottiene mediante la somma pesata dei vettori delle priorità locali

delle diverse alternative, in cui i pesi sono rappresentati dai pesi attribuiti a ciascun driver.

1 i ugualmente importante rispetto a j 3 i leggermente più importante del criterio j 5 i più importante rispetto a j 7 i molto più importante rispetto a j 9 i estremamente più importante di j

2,4,6,8 giudizi intermedi o di compromesso


85

I pesi globali rappresentano il risultato finale della valutazione in quanto consentono di

effettuare un ranking di preferenza: un’alternativa sarà tanto più preferibile quanto

maggiore è il suo peso globale.

3.4.2. Applicazione del metodo

Le tecnologie che vengono messe a confronto su diversi criteri legati allo sviluppo di

applicazioni enterprise sono: nativa , web application, cross-compiled, custom container e

ibrida. I confronti che vengono effettuati tra le diverse tecnologie sono realizzati sui

seguenti driver:

• Portabilità: il numero di piattaforme supportate da una determinata tecnologia.

Tecnologie con elevata portabilità favoriscono politiche aziendali di tipo BYOD e

impattano maggiormente sulla diminuzione dei costi di sviluppo quando il numero di

piattaforme aumenta.

• Accesso ai sensori: la capacità di una tecnologia di accedere ai sensori del dispositivo

Le tecnologie che forniscono un alto livello di integrazione con le risorse hardware

delle diverse piattaforme supportate permettono di sviluppare applicazioni utilizzabili

in un vasto range di scenari di utilizzo, risultando maggiormente flessibili.

• Integrazione Applicazioni: è la possibilità di un’applicazione sviluppata con una

determinata tecnologia di interagire con le altre eseguite sul sistema operativo,

attraverso l’uso di protocolli di comunicazione e servizi del sistema operativo. Le

tecnologie con un alto livello di integrazione si adattano meglio a scenari in cui sono

presenti diverse applicazioni che devono cooperare per realizzare una macro attività o

necessitano di particolari servizi del sistema operativo

• Aggiornamento funzionalità: Le risorse necessarie in termini di tempi e costi per

aggiungere o modificare le funzionalità di un’applicazione multipiattaforma sviluppata

con una determinata tecnologia. Un’applicazione facile da aggiornare permette di

lavorare su un unico codice per le diverse versioni del software in un unico ambiente

di sviluppo integrato.

• Performance: il comportamento dell’applicazione realizzata con una determinata

tecnologia a fronte di un uso intenso delle risorse di calcolo del dispositivo. Le


86

situazioni più critiche sono rappresentate dalla presenza nell’interfaccia utente di

elementi grafici avanzati o elaborazione di grafica 3D o algoritmi complessi; altro

fattore da considerare è come le prestazioni degradano rispetto ad eventi come tocco o

zoom.

Dopo aver definito i driver sui quali effettuare i confronti delle diverse tecnologie, in base

alle specifiche del contesto in cui deve essere sviluppata l’applicazione è necessario

definire le priorità. Viene presentato uno scenario sul quale applicare il metodo AHP:

un’azienda vuole realizzare un’applicazione a supporto di una figura professionale che

opera in mobilità con mansioni principalmente di sales force, coprendo diverse attività

nell’orario di lavoro. L’applicazione deve poter essere eseguita sul dispositivo dell’addetto

in maniera indipendente dalla piattaforma sottostante e deve poter eseguita sia se il

dispositivo è aziendale che privato. Il numero di piattaforme da supportare deve essere

elevato per permettere di perseguire una politica di BYOD. L’azienda ha comunque

individuato un sottoinsieme di piattaforme di riferimento per le fasi di sperimentazione del

progetto. Le diverse versioni delle applicazioni dovranno avere un elevato grado di

integrazione con il sistema operativo su cui vengono eseguite, dovendo interagire con le

altre applicazioni già risiedenti sul sistema. È richiesto inoltre la possibilità dell’accesso a

determinati servizi e sensori del sistema operativo, in particolare Gps, local storage, e il

funzionamento offline. L’azienda intende utilizzare in futuro caratteristiche specifiche di

determinati tipi di dispositivi, come la possibilità di sfruttare la firma biometrica nel

processo di dematerializzazione dei contratti.

Sulla base dello scenario descritto le priorità attribuite ai diversi driver sono state:

1°.Portabilità: la portabilità è il driver più importante per le esigenze del progetto, le

piattaforme da supportare devono essere numerose ed è richiesto la facilità di adattare

l’applicazione all’evoluzione delle piattaforme.

2°.Integrazione applicazioni: l’integrazione e la collaborazione tra le diverse applicazioni,i

servizi offerti dal sistema operativo e le applicazioni built-in è richiesta per poter eseguire

le macroattività in maniera agevole.

3°.Aggiornamento: L’applicazione deve essere facilmente aggiornabile e modificabile in


87

tutte le versioni per le diverse piattaforme supportate.

4°.Accesso ai sensori: L’accesso ai sensori e ai servizi del sistema operativo è richiesto

principalmente per l’accesso al gps, lettura di codice a barre e la memorizzazione locale

per il funzionamento offline. In futuro è richiesta la possibilità di supportare la firma

biometrica.

5°.Performance: L’interfaccia utente non deve essere particolarmente complessa, in modo

da aumentarne l’usabilità, garantendo una esperienza utente accettabile.

In base alle considerazioni fatte è possibile compilare la tabella sottostante come previsto

dal metodo AHP

Tabella 6: Confronto a coppie dei driver

Per ogni driver scelto è necessario dare una valutazione qualitativa rispetto alle tecnologie

di sviluppo. In seguito viene presentata una valutazione dei pesi assegnati ad ogni

tecnologia rispetto ai driver individuati. Per far questo sono state utilizzate informazioni

provenienti da documenti prodotti dalla Gartner, una società di analisi specializzata in

assessment tecnologico e di mercato del settore IT, articoli ricercati in rete e prove

effettuate su prototipi realizzati ad-hoc per testare i diversi driver. I diversi test sono stati

svolti realizzando come demo una rubrica che sia capace di interfacciarsi con i sensori del

dispositivo, in particolare vibrazione e gps, focalizzando le prove su aspetti legati alla

portabilità e facilità di aggiornamento. Per ogni famiglia di tecnologie si è scelta una

soluzione di riferimento che rappresentasse meglio gli aspetti rilevati dalla letteratura. Le

tecnologie scelte sono HTML5 per la web application, Phonegap e un bridge realizzato ad

Portabilità Accesso ai sensori

Costi di aggiornamento

Integrazione applicazioni

Performance

Portabilità 1,00 7,00 2,50 1,67 9,00

Accesso ai sensori 0,14 1,00 0,33 0,20 2,00


0,40 3,00 1,00 0,50 4,00


0,60 5,00 2,00 1,00 7,00

Performance 0,11 0,50 0,25 0,14 1,00


88

hoc per l’ibrido, Adobe Air per il custom container e Titanium per il cross compiled. Le

piattaforme sulle quali sono state testate le diverse versioni della demo sono Windows 8 e

android 4.0; i dispositivi utilizzati sono stati tablet per il sistema android e un pc desktop

per windows 8, sul quale è stata sviluppata la demo come applicazione win32. Di seguito

vengono riportate le valutazioni finali emerse per ogni driver.

3.4.2.1. Portabilità

• Nativa: le applicazioni native non sono portabili, per ogni piattaforma che si vuole

supportare bisogna sviluppare un porting. Esso viene effettuato utilizzando strumenti

di sviluppo, tecnologie, e linguaggi specifici forniti dall’SDK della piattaforma target

• Cross-compiled: La portabilità delle applicazioni cross-compiled dipende dal supporto

dei framework alle diverse piattaforme. Estendere la portabilità è oneroso a causa dello

sviluppo delle numerose api da realizzare. Lo sviluppo del software con questa

tecnologia permette il riuso quasi totale del codice per le varie piattaforme, dovendo

adattarlo nei casi in cui bisogna accedere a caratteristiche specifiche di una piattaforma

(esempio uso della firma biometrica). Oltre al riuso del codice si possono usare gli

stessi strumenti, tecnologie e linguaggi per le diverse piattaforme da supportare, ma

potrebbe essere necessario l’uso degli SDK nativi per le fasi di packaging, testing e

deploying dell’applicativo

• Custom Container: le applicazioni Custom Container sono portabili in maniera simile

alle Cross-compiled, dipendono dal numero di piattaforme supportate dall’interprete

del custom container. Viene utilizzato lo stesso codice e gli stessi strumenti per lo

sviluppo dell’applicazione per le diverse piattaforme. Per supportare specifiche

features di una piattaforma in particolare è necessario adattare il codice, potendo però

contare su strumenti a supporto efficaci.

• Ibrida: le applicazioni ibride offrono una buona portabilità. Può essere usato lo stesso

codice e strumenti per sviluppare le applicazioni multipiattaforma. In pratica vengono

supportate tutte le piattaforme che possono gestire i controlli e la presentazione con le

tecnologie web embedded, cioè integrate nell’applicazione nativa, attraverso i vari

SDK. Strumenti nativi possono essere necessari per le fasi di packaging, testing, e


89

distribuzione dell’applicazione.

• Applicazioni web mobile: le applicazioni web mobile offrono la portabilità migliore di

tutte le tecnologie. Un’applicazione può supportare qualsiasi piattaforma che ha un

Web browser. Bisogna però in fase di sviluppo pensare a gestire la frammentazione dei

browser e il loro supporto alle tecnologie web, soprattutto HTML5 e CSS3. Non sono

necessarie le tecnologie native nello sviluppo, anche se strumenti nativi possono essere

necessari per la fase di testing (esempio uso di simulatori).

La sperimentazione ha permesso di costatare che il codice sviluppato tramite html, css e

javascript sia supportato da tutte le piattaforme utilizzate. L’applicazione realizzata con

questa tecnica ha però mostrato limitazioni per quanto riguarda la vibrazione che non è

realizzabile e l’utilizzo del GPS non supportato da tutti i browser. Per quanto riguarda le

tecnologie ibride è immediato riutilizzare il codice web prodotto e integrare la vibrazione e

il gps attraverso il bridge, sia creato ad-hoc che tramite Phonegap. Per quanto riguarda

Adobe air è stato possibile importare il codice web all’interno del un pacchetto air da far

eseguire dal contenitore ma questo approccio non permette l’accesso ai sensori per la

vibrazione e il GPS. Si è effettuato un porting verso la tecnologia Actionscript che

supporta il flex framework, nel quale è possibile utilizzare librerie aggiuntive per accedere

ai sensori del dispositivo. In questo modo è stato possibile realizzare l’applicazione

completa delle sue funzionalità. Il framework inoltre consente di esportare il pacchetto

nativo per i sistemi operativi mobile come Ios, Android e blackberry senza la necessità di

istallare il contenitore separatamente. Su piattaforme desktop come windows è necessario

installare l’air runtime separatamente. In base a queste considerazioni è stata fatta la

seguente valutazione.


90

Tabella 77: Confronto a coppie delle diverse alternative in relazione al driver "Portabilità"

3.4.2.2. Integrazione applicazioni

• Web-application: le web application non hanno possibilità di interagire con le

applicazioni sviluppate con tecnologia nativa e non possono utilizzare servizi di

storage offerti dal sistema operativo.

• Ibrido: le applicazioni ibride supportano parzialmente l’integrazione con le altre

applicazioni, ad esempio sono supportate alcune applicazioni built-in come il

calendario.

• Cross-compiled: Attraverso le api offerte da questa tecnologia è permesso l’uso di

molte funzionalità del sistema operativo di riferimento. E’ consentito l’accesso e la

comunicazione con tutte le applicazioni built-in, ma la comunicazione fra applicazioni

non è supportata completamente. È possibile estendere le funzionalità attraverso i

moduli nativi.

• Custom-container: le features accessibili sono quelle più comuni e condivise da tutti i

sistemi operativi quindi l’integrazione con le altre applicazioni non è offerto dalla

tecnologia se si utilizzano tecnologie web aperte. Attraverso l’uso del framework Flex

e il linguaggio actionscript è possibile utilizzare diverse api ed estensioni native per

accedere ai servizi del sistema operativo.

• Nativo: l’integrazione con le altre applicazioni è supportata completamente attraverso

l’uso delle API fornite dalle diverse piattaforme.

Oltre a queste considerazioni sono emerse dai test effettuati le limitazioni delle tecnologie

di riferimento rispetto al nativo. Mentre la web application attraverso l’html 5 consente di

Nativo Cross compiled

Custom Container

Ibrido Web application

Nativo 1,00 0,17 0,17 0,13 0,11

Cross compiled 6,00 1,00 1,00 0,50 0,20

Custom Container 6,00 1,00 1,00 0,50 0,20

Ibrido 7,50 2,00 2,00 1,00 0,67

Web application 9,00 5,00 5,00 1,50 1,00


91

accedere solo al GPS, l’ibrido sia con phone gap che con un bridge customizzato

permettono sia la geolocalizzazione che l’accesso ai sensori come la vibrazione. Preclusa è

invece la possibilità di utilizzare il protocollo di comunicazione tra le applicazioni offerto

sia da Android che da Windows implementato dal sistema operativo. Per il bridge

customizzato è necessario scrivere del codice nativo che integri queste funzionalità

mancanti. Per adobe air valgono le stesse cosiderazioni, il toolset non offre la possibilità di

utilizzare questa caratteristica specifica del sistema operativo ma mette a disposizione

degli strumenti che consentono di implementare delle librerie aggiuntive utilizzando

codice nativo che si integrano con il flex framework. Anche Titanium preclude questa

possibilità ma consente di integrare in codice nativo all’interno dell’applicazione.

In base a queste considerazioni sono stati dai i seguenti pesi:

Tabella 88: Confronto a coppie delle diverse alternative in relazione al driver "Portabilità"

3.4.2.3. Aggiornamento funzionalità

• Nativa: Le applicazioni multipiattaforma sviluppate con tecnologia nativa forniscono

le peggiori prestazioni in termini di aggiornamento delle funzionalità. Supportare

diverse piattaforme comporta lo sviluppo di codice nativo unico per ognuna,

utilizzando quindi linguaggi, strumenti e tecnologie peculiari, il che comporta il riuso

di codice e strumenti poco attuabile. Aggiungere nuove funzionalità ad una

applicazione comporta lavorare a diverse versioni del codice.

• Cross-compiled: sviluppare applicazioni multipiattaforma con le tecnologie cross-

compiled permette il riuso del codice e degli strumenti di sviluppo, dovendo adattare


Custom Container Ibrido Web application

Nativo 1,00 1,43 2,00 2,00 9,00

Cross compiled 0,70 1,00 1,67 1,67 7,00


Ibrido 0,50 0,60 1,00 1,00 5,00

Web application 0,11 0,14 0,20 0,20 1,00


92

ed estendere il codice relativo all’interfaccia grafica e alle funzionalità del sistema

operativo che non vengono supportate dalle api built-in fornite dal framework.

• Custom-container: sviluppare applicazioni multipiattaforma con le tecnologie custom

container comporta un buon risparmio in termini di costi e tempi di aggiornamento e

modifiche, potendo riutilizzare lo stesso codice e gli stessi strumenti per le diverse

versioni dell’applicazione. Per funzionalità del sistema operativo e sull’uso dei sensori

che non sono coperte dalle api fornite dal framework, è necessario sviluppare

l’estensioni native per ogni piattaforma da supportare.

• Ibrida: Queste tecnologie permettono un buon risparmio in termini di costi di

aggiornamento, grazie al significativo riuso del codice e l’utilizzo di tecnologie

conosciute e mature, che permettono di abbassare i costi. Un fattore da tenere in

considerazione risulta essere l’utilizzo delle tecnologie native per le fasi di packaging,

testing e distribuzione.

• Applicazioni web mobile: le applicazioni che vengono sviluppate tramite le tecnologie

web hanno il maggiore impatto sui costi di aggiornamento in ambito multipiattaforma.

Infatti avendo la maggiore portabilità e l’utilizzo di una singola versione del codice per

tutte le piattaforme, riescono ad abbassare i costi e i tempi per effettuare modifiche e

nuove funzionalità.

Per le tecnologie sperimentate è stato costatato come la web application e l’ibrido si

possono aggiornare ed estendere in maniera simile in quanto entrambe utilizzano

tecnologie web per la logica di business dell’applicativo e lo strato di presentazione.

Tecnologie come Adobe Air consentono di scrivere codice una volta per tutte le

piattaforme ed eventualmente importare librerie già sviluppate se si intende supportare

diversi sistemi operativi con una determinata funzionalità, come ad esempio la vibrazione.

Con il framework Titanium l’aggiornamento deve tenere conto delle specifiche api del

sistema operativo da supportare. Titanium offre una serie di api comuni a tutte le

piataforme supportate che coprono le funzionalità comuni, se è necessario accedere a una

libreria specifica bisogna riscrivere la porzione di codice che implementa tale funzione per


93

il sistema operativo scelto.

Le valutazioni effettuate sono le seguenti:

Tabella 9: Confronti a coppie delle diverse alternative in riferimento al driver “integrazione applicazioni”

3.4.2.4. Accesso ai sensori

• Nativo: con questo approccio si ha la massima integrazione con le caratteristiche

specifiche sia del sistema operativo che del device. Si ha l’accesso a tutti i sensori e/o

alle API di basso livello che ne consentono l’accesso.

• Cross-compiled: questa tecnologia permette di sfruttare la maggior parte delle

funzionalità caratteristiche delle piattaforme supportate. Essendo l’integrazione nativa

molto profonda e specifica il supporto è limitato a due o tre piattaforme di riferimento.

Poiché la tecnologia sfrutta una serie di API per accedere alla piattaforma di

destinazione non tutte le funzionalità sono esposte, ad esempio se si vuole includere

l’utilizzo della firma biometrica. Il codice che accede ad una caratteristica specifica di

una piattaforma deve essere scritto per tutte le piattaforme da supportare, non potendo

riutilizzare il codice prodotto.

• Custom-container: l’applicazione ha bisogno di un contenitore nativo per ogni

piattaforma supportata, i tool di sviluppo offrono degli strumenti che consentono di

accedere a determinate features, coprendo solo un sottoinsieme di capacità native,

quelle comuni fra le diverse piattaforme, ad esempio il gps. Per accedere ai sensori non

forniti dalle api built-in è necessario sviluppare le estensioni native per ogni



Nativo 1,00 0,20 0,14 0,14 0,11

Cross compiled 5,00 1,00 0,33 0,33 0,20


Ibrido 7,00 3,00 1,00 1,00 1,00

Web application 9,00 5,00 3,00 1,00 1,00


94

piattaforma supportata.

• Ibrido: in questa tipologia di applicazioni il bridge fornisce ha un accesso limitato alle

specifiche funzionalità della piattaforma sottostante. Sono supportate le funzionalità

più comuni del dispositivo come il GPS o la fotocamera. Per aumentare il supporto ai

sensori è possibile creare estensioni native per il bridge di terze parti come quello

fornito da Phonegap, o sviluppare il codice per il bridge creato ad-hoc.

• Web-Application: L’accesso ai sensori tramite HTML5 e javascript ai sensori e ad

alcune applicazioni built-in è limitato, soprattutto per ragioni di sicurezza.

La sperimentazione ha evidenziato come l’accesso ai sensori sia maggiormente supportato

dalla tecnologia cross compiled che implementa di default caratteristiche specifiche dei

device che montano i sistemi operativi di cui si forniscono le api. L’ibrido espone tutti i

sensori comuni ai vari device come mostra la documentazione di Phonegap; creando il

bridge ad-hoc è possibile accedere a tutti i sensori del dispositivo attraverso invocazioni

del codice nativo. Adobe air supporta quasi tutte le caratteristiche più comuni come il GPS

e la camera, mentre per la vibrazione è stato necessario importare una libreria esterna

fornita da Adobe specifica per il sistema Android.

Le valutazioni effettuate sono le seguenti:

Tabella 10: Confronto a coppie tra le diverse alternative in relazione al driver "Accesso ai sensori"



Nativo 1,00 1,25 2,00 1,67 9,00

Cross compiled 0,80 1,00 1,67 2,50 3,33


Ibrido 0,60 0,40 2,00 1,00 5,25

Web application 0,11 0,30 0,33 0,19 1,00


95

3.4.2.5. Performance

• Nativo: questo approccio fornisce le performance migliori in quanto consente sia di

utilizzare i controlli nativi dell’SDK per ogni piattaforma che di creare interfacce

molto complesse sfruttando le librerie grafiche native.

• Cross-compiled: grazie alla profonda integrazione offerta dalle API dedicate ad ogni

specifica piattaforma si riescono a ottenere delle interfacce simili a quelle native e

buone performance.

• Custom-container: i tool offerti dalle tecnologie custom permettono di creare

interfacce anche elaborate ma spesso lontane da quella che è la user experience che

l’utente si aspetta da una determinata piattaforma. L’interpretazione del codice a

runtime del contenitore può ridurre le performance dell’applicazione soprattutto

quando sono richieste interfacce grafiche avanzate.

• Ibrido: In questa modalità l’interazione con l’utente è quella offerta dalle tecnologie

web che grazie a strumenti e framework integrabili riescono a dare un’esperienza

utente gradevole e vicina al nativo. L’overhead dovuto al motore grafico che

renderizza le pagine html all’interno dell’applicazione non garantisce buone

prestazioni quando si richiedono interfacce complesse.

• Web-application: l’interazione è quella offerta dalle possibilità dell’html5 e delle

tecnologie web ed eventualmente dall’utilizzo di framework come jquery mobile per

una user experience più accattivante. Le prestazioni , come per l’ibrido, sono legate

alla complessità dell’interfaccia e alla velocità del browser.

In fase di sperimentazione l’interfaccia sviluppata con le tecnologie web è stata riutilizzata

nella versione ibrida e custom container. La stessa interfaccia è stata riportata

nell’applicazione Adobe Air ed è stata renderizzata dal contenitore. Per realizzare la stessa

interfaccia con il flex framework è stato necessario effettuare un porting dell’html nel

linguaggio di markup di Adobe, con prestazioni dell’interfaccia grafica identiche. I pesi

dati alle varie tecnologie sono i seguenti:


96

Tabella 11: Confronto a coppie tra le diverse alternative in relazione al drive "Performance"

Dopo aver effettuato tutti i confronti tra le diverse alternative per ogni driver e confrontato

i driver rispetto all’obiettivo, sono stati prodotti gli autovettori per ogni matrice.

Effettuando la sintesi dei dati locali attraverso somme pesate è stato possibile ottenere un

autovettore totale, il quale normalizzato permette di ricavare un ranking globale delle

diverse alternative in base ai pesi ottenuti dalle valutazioni locali. La tabella 12 mostra i

risultati complessivi:

Tabella 12: Rankig globale delle alternative

Osservando la colonna dei risultati della somma pesata è possibile ottenere il ranking

globale in cui in ordine decrescente è consigliato l’utilizzo di web application, ibrido,

custom container, cross-compiled, nativo.

Conclusioni Le alternative nello sviluppo di applicazioni mobile multipiattaforma di tipo enterprise



Nativo 1,00 1,43 2,50 2,50 3,33

Cross compiled 0,70 1,00 1,43 2,50 3,33


Ibrido 0,40 0,40 0,50 1,00 1,00

Web application 0,30 0,30 0,40 1,00 1,00

Portabilità Accesso ai sensori



Performance Risultato della somma pesata

Peso 42,9% 6,5% 16,8% 29,7% 4,1% Nativo 3% 33% 3% 35% 35% 15,88% Cross compiled

13% 27% 10% 27% 27% 18,06%

Custom Container

13% 14% 22% 17% 19% 16,04%

Ibrido 25% 20% 27% 17% 11% 22,28%

Web application

45% 5% 39% 4% 9% 27,74%


97

sono numerose, ognuna offre servizi e strumenti per poter perseguire una politica di

sviluppo di applicazioni che possano supportare più piattaforme e più dispositivi; nessuna

di quelle individuate permette di massimizzare i benefici di tutti i driver individuati,

dovendo quindi ricorrere a valutazioni complessive che tengano conto dei diversi

comportamenti dei framework e delle tecnologie di sviluppo. È stato scelto l’AHP come

metodo di supporto alla decisione per individuare la tecnologia con cui realizzare

un’applicazione enterprise perché permette di utilizzare nel calcolo dei ranking locali

grandezze quantitative e qualitative e di poterle sintetizzare insieme; inoltre permette di

poter velocemente cambiare i valori assegnati nei confronti, in caso di modifiche fatte da

valutazioni aggiuntive o cambiamenti settati da attori esterni come committenti del

progetto software. Analizzando il ranking finale della tabella 12, la tecnologia di sviluppo

consigliata dalla metodologia è la web application. Nel capitolo successivo verranno

presentate considerazioni aggiuntive che non sono state incluse nella elaborazione dei dati

dell’AHP, che porteranno alla selezione della tecnologia per la realizzazione di un

applicativo software per un progetto reale commissionato da Poste Italiane.


98

Capitolo 4 Implementazione di unʼapplicazione con la tecnologia individuata: Analisi e progettazione

Introduzione Nel capitolo 3 sono state analizzate e confrontate le diverse tecnologie individuate per

supportare lo sviluppo multipiattaforma di applicazioni mobile enterprise. Tutte le

tecnologie scelte forniscono servizi peculiari che tendono a massimizzare determinati

benefici, non fornendo prestazioni ottimali in altri. Per poter effettuare un’analisi

comparativa che tenga conto delle prestazioni globali delle diverse alternative proposte è

stato utilizzato il metodo AHP. Questo metodo, utilizzando confronti a coppie di tipo

qualitativo e analisi quantitative, permette di produrre un ranking globale delle alternative,

rispetto al problema di selezione della tecnologia da adottare per la realizzazione di un

software, le cui caratteristiche sono riportate nel capitolo 3. L’applicazione del metodo ha

prodotto un ranking in cui la tecnologia che fornisce le migliori prestazioni complessive

risulta essere la web application. Una volta determinata la scelta consigliata, verrà

analizzata sulla base di un progetto reale di consulenza commissionato da Poste Italiane;

questo progetto aggiunge determinati vincoli che non sono stati inseriti nelle valutazioni

del metodo AHP, per mantenere una maggiore astrazione sulle caratteristiche

dell’applicazione target. Una volta scelta la tecnologia di sviluppo che possa supportare

tutti i vincoli del progetto, verrà presentato lo sviluppo dell’applicazione. In questo

capitolo sono trattati l’analisi dei requisiti software e la progettazione.


99

4.1. Requisiti dell’applicazione

Per poter effettuare la scelta della tecnologia di sviluppo, viene contestualizzato il ranking

fornito dal metodo AHP con le richieste dell’applicazione denominata AGENDA ASI.

I requisiti di alto livello dell’applicazione sono i seguenti:

L’applicazione da realizzare fa parte del progetto del postino telematico. Attraverso questa

nuova figura denominata ASI (articolazione servizi innovativi) Poste Italiane intende

recapitare in itinere servizi già offerti e nuovi a valore aggiunto, presso il domicilio dei

clienti, sia customer che business. L’applicazione AGENDA ASI si colloca come

applicazione di tipo sales force automation; essa deve permettere all’asi di poter prendere

appuntamenti o di riceverli dal centro distribuzione a cui è assegnato; l’asi tramite

l’applicazione può accedere ai dati dell’appuntamento, del cliente, tra cui anagrafica e

storico degli incontri precedenti. Al termine dell’appuntamento l’asi effettua la chiusura

inviando i dati al server centrale del centro distribuzione per la memorizzazione. Il valore

aggiunto di questa applicazione consiste nel poter tenere traccia dei servizi offerti e

venduti al cliente utili per la loro analisi da parte di applicazioni di business intelligence e

analitiche lato back-end. Inoltre attraverso lo storico l’asi può tenere traccia degli incontri

passati col cliente al fine di prepararsi meglio per l’appuntamento successivo, in modo tale

da aumentare l’efficacia nella vendita e nella proposizione dei servizi offerti da Poste

Italiane.

L’applicazione deve poter essere eseguita su sistemi Windows 8 ed Android 4.0,

rispettivamente su tablet Samsung Slate 7 business ed Olipad Graphos. Il suo utilizzo in

mobilità è garantito dall’utilizzo di una sim Poste Mobile per il traffico dati da rete 3G. Per

l’accesso al server di back-end per invio e ricezione dei dati dell’applicazione deve essere

utilizzato un componente software che verrà fornito per funzionalità di Gateway per

l’accesso alla VPN di Poste Italiane, al fine di accedere al server di back-end. Al momento

il componente è sviluppato per Windows 8 per applicazioni Win32.

L’applicazione deve poter funzionare anche in casi di assenza di rete, memorizzando i dati

in locale, che verranno trasmessi una volta che il segnale viene ripristinato, sia in modo

sincrono che asincrono.


100

4.2. Scelta della tecnologia di sviluppo

Analizzando i requisiti di alto livello e i vincoli a cui sottostare nello sviluppo

dell’applicazione, è stato verificato se la web application, tecnologia consigliata

dall’applicazione del metodo AHP, soddisfi tutte le richieste del software. È emerso

dall’analisi che la web application non risulta aderente a tute le richieste e vincoli imposti

dai requisiti dell’applicazione. In particolare lo sviluppo di una web application non è

fattibile per i seguenti motivi:

1- Poste Italiane non fornisce un server web dal quale caricare al primo avvio i contenuti

web per la parte di presentazione e di logica dell’applicazione che vengono poi

memorizzati in cache; inoltre non potendo utilizzare il protocollo http per le richieste

delle pagine web non è possibile utilizzare feature di HTML5 per la memorizzazione

in locale come indexed DB e local storage.

2- È necessario utilizzare il componente nativo per effettuare l’accesso alla VPN di poste

italiane; da javascript non è possibile effettuare la comunicazione con essa senza

bridge software.

3- In ottica di BYOD l’applicazione da sviluppare deve essere fornita di meccanismi di

controllo dell’accesso dell’utente e dell’applicazione; Poste Italiane per ottenere questo

controllo non intende utilizzare web services per l’autenticazione, ma fornisce

attraverso una piattaforma enterprise di gestione delle applicazioni meccanismi per

installare le applicazioni e controllarne l’accesso, sia in termini di utenti che di

dispositivi. Per questo motivo la web application non può essere utilizzata perché non

installabile sul dispositivo.

Avendo riscontrato che la web application non può essere sviluppata è stata scelta come

tecnologia di sviluppo l’approccio ibrido, il quale risulta nel ranking globale al secondo

posto e riesce a soddisfare tutti i vincoli dell’applicazione. In particolare è stato scelto di

sviluppare un bridge ad hoc che comunichi con il sistema operativo sottostante,

utilizzando per la parte di presentazione e logica applicativa HTML5 e javascript, e


101

implementare nativamente le funzionalità per la comunicazione con il componente nativo

e la memorizzazione in locale dei dati dell’applicazione. Con questo approccio il codice di

presentazione e logica verrà riutilizzato per le 2 piattaforme, dovendo sviluppare per ogni

piattaforma il codice per creare il contenitore nativo e le funzionalità native.

4.3. Analisi dei requisiti funzionali e non funzionali del software

Partendo dalla specifica del progetto sono state realizzate una serie interviste e riunioni

presso la sede di Poste Italiane con i committenti e diversi stakeholders connessi al

progetto, al fine di poter ricavare i casi d’uso dell’applicazione. In figura 34 è riportato il

diagramma dei casi d’uso dell’applicazione:

Figura 34: Casi d’uso

Dall’analisi dei casi d’uso e attraverso feedback del committente, è stata prodotta la lista

dei requisiti funzionali e non funzionali dell’applicativo. Una volta raccolti i requisiti è

stato realizzato un documento di SRS (software requirements specification) del progetto

software Viene di seguito riportata la lista dei titoli dei requisiti funzionali:

1- Login


102

2- Visualizza appuntamenti in agenda

3- Creazione appuntamento

4- Creazione nuovo cliente con appuntamento

5- Mostra dettagli appuntamento

6- Visualizza storico cliente

7- Mostra dati cliente

8- Mostra anagrafica completa cliente

9- Sposta appuntamento

10- Chiusura appuntamento

11- Aggiorna agenda

12- Annulla appuntamento

Per ogni caso d’uso è stato utilizzato il modello proposto da Martin Fowler per modellare

le interazioni dell’utente con il sistema software. Di seguito sono riportati 2 casi d’uso

realizzati:

Visualizza agenda

Contesto: Il postino accede all’agenda odierna e visualizza tutti gli appuntamenti divisi per

fascia oraria. Qualora volesse, può visualizzare gli appuntamenti relativi ad un altro giorno

Attore primario: Postino ASI

Precondizioni: L’ASI ha effettuato il login in maniera corretta

1. Il sistema presenta l’agenda con gli appuntamenti per la data attuale suddivisi per

fascia oraria. Gli appuntamenti da effettuare sono contrassegnati con il colore verde, quelli

conclusi con il colore grigio, mentre gli appuntamenti che devono essere approvati dalla

centrale operative sono di colore giallo

Se al passo 2 il postino vuole visualizzare un altro giorno:

1.a. Il postino seleziona un giorno diverso da quello attuale

1.b. Il sistema presenta l’agenda con gli appuntamenti del giorno scelto

Postcondizioni: nessuna

Visualizza appuntamento

Contesto: Il postino visualizza le informazioni relative a un appuntamento selezionandolo


103

dall’agenda

Attore primario: Postino ASI

Precondizioni: E’ stato eseguito il caso d’uso Visualizza agenda

1. Il postino seleziona l’appuntamento da visualizzare

2. Il sistema presenta i dati relativi all’appuntamento: nome del cliente, luogo

dell’appuntamento, tipo di servizio, categoria di servizio, tipologia di cliente e le per

eventuali note

Postcondizioni: nessuna

Terminata la stesura dell’SRS è stato confrontato ed integrato con quello realizzato dai

committenti, al fine di validare la fase di analisi e raccogliere i requisiti del software.

4.4. Progettazione del software

Dopo aver ottenuto la validazione dell’SRS dal committente è stata effettuata la

progettazione del software attraverso diagrammi UML ( Unified Modeling Language ),

utilizzati per realizzare il diagramma delle classi e i diagrammi di sequenza. Il primo viene

utilizzato per creare un modello di alto livello di astrazione del dominio, al fine di

analizzare le entità logiche coinvolte all’interno dell’applicazione; il terzo per modellare il

comportamento dinamico delle entità ottenute dal diagramma delle classi.

Nel diagramma della classi il dominio è stato analizzato ed astratto in maniera statica

attraverso una sere di entità logiche; esse sono state modellate con il paradigma ad oggetti

attraverso la creazione di classi e relazioni tra esse. Di seguito è riportato il class diagram

realizzato:


104

Figura 35: Diagramma delle classi

Le classi individuate sono:

Agenda Asi: si occupa di gestire le richieste dell’utente andando a creare o modificare gli

oggetti Appuntamento, Cliente, Storico e Servizio. Interagisce con la classe comunicatore

per inviare le richieste al server e al database

Appuntamento: gestisce le informazioni del modello sugli appuntamenti che il postino

segna e riceve in agenda

Cliente: gestisce le informazioni del modello sui clienti con cui il postino prende gli

appuntamenti

Storico: gestisce le informazioni del modello sullo storico relativo agli incontri passati del

postino con i clienti


105

Servizio: gestisce le informazioni del modello sui servizi che il postino offre ai clienti

durante gli appuntamenti

Comunicatore: gestisce le comunicazioni tra l’agenda e il server e tra l’agenda e il

database.

Per modellare le interazioni dinamiche tra gli oggetti nell’esecuzione dei diversi requisiti

funzionali sono stati realizzati i diagrammi di sequenza. In seguito vengono riportati alcuni

di quelli realizzati per l’applicazione:


106

Figura 36: Diagramma di sequenza: Visualizza agenda


107

Figura 37: Diagramma di sequenza: Aggiorna Agenda


108

Figura 38: Diagramma di sequenza: Nuovo Appuntamento

Conclusioni In questo capitolo è stato analizzato il contesto e i requisiti software di un’applicazione

mobile multipiattaforma commissionata da Poste Italiane. Sulla base dei vincoli

dell’applicativo è stata scelta la tecnologia ibrida per realizzare l’applicazione, posta al

secondo posto nel ranking AHP ma che permette di soddisfare tutti i vincoli imposti dal

progetto. Sono stati presentati alcuni dei modelli realizzati in fase di progettazione del

software che verranno utilizzati in fase di realizzazione dell’applicazione, che verrà

trattata nel capitolo successivo.


109

Capitolo 5 Implementazione di unʼapplicazione con la tecnologia individuata: Sviluppo codice e analisi a posteriori della tecnologia utilizzata

Introduzione In questo capitolo verrà analizzato il processo di realizzazione del codice partendo dalla

progettazione del software. Il progetto da realizzare fa parte di uno più grande, che Poste

Italiane sta costruendo intorno alla figura del Postino Telematico. Esso consiste in una

serie di applicazioni da realizzare principalmente per piattaforma Windows 8, le quali

saranno sperimentate sul campo al fine di validarne l’efficacia e l’efficienza prima della

messa in esercizio a regime. Questo contesto va a particolarizzare il processo di codifica

dell’applicazione, collegandolo con le fasi di analisi dei requisiti e di progettazione. Infatti

le due fasi precedenti, riportate nel capitolo 4, non sono state effettuate con un processo di

sviluppo Waterfall; ciò significa che non sono state chiuse completamente prima di

passare alla fase di codifica e testing dell’applicazione, ma è stato adottato un approccio

agile allo sviluppo. Questo approccio di sviluppo è stato necessario in quanto essendo in

un progetto innovativo di sperimentazione, i requisiti non sono ben delineati fin dalla

partenza del progetto; ciò significa che partendo dall’SRS validato sono state apportate

modifiche minori ad esso, comportando un adeguamento del modello di progetto e della

struttura del codice in maniera dinamica.

5.1. Processo agile adottato


110

Essendo l’applicazione una parte di un progetto innovativo composto da numerosi

elementi, con requisiti che hanno subito modifiche nel corso dello sviluppo, il processo di

sviluppo adottato è stato di tipo agile. Questo processo consiste principalmente in una

serie di iterazioni complete da realizzare su un sottoinsieme di requisiti dell’applicazione,

al fine di realizzare l’applicativo software in maniera incrementale e iterativa. Ogni

iterazione prevede fasi di analisi dei requisiti, progettazione, codifica, testing e

validazione. Esistono diverse metodologie che fanno parte della famiglia dei processi agili,

ognuna con una implementazione propria dei principi su cui si fonda questo tipo di

processo di sviluppo. Per la realizzazione dell’applicazione AGENDA ASI non è stato

adottato in maniera ferrea nessuno dei processi definiti all’interno dell’insieme delle

metodologie agili. Le caratteristiche principali dello sviluppo adottato dell’applicazione

sono state:

1- Condivisione e collaborazione: il team che si è occupato dello sviluppo del codice è

composto da 2 persone, le quali si sono divise il lavoro per proseguire in parallelo lo

sviluppo, ma allo stesso tempo si sono confrontate ed supportate nello sviluppo

dell’intera applicazione. In questo modo tutto il team era a conoscenza del codice

prodotto, in modo da poter apportare all’occorrenza cambiamenti in maniera efficace

2- Feedback del committente: partendo dalle fasi e documenti prodotti di analisi e

progettazione, sono stati implementati in diverse iterazioni piccoli subset di requisiti,

ordinati temporalmente per importanza, i quali sono stati validati oppure modificati

con il committente , attraverso una serie di riunioni e contatti tramite mail, al fine di

massimizzare la sua soddisfazione

3- Iterazioni brevi: Per poter validare l’evoluzione dello sviluppo e rispondere in

maniera tempestiva a modifiche dei requisiti da parte del committente sono state

realizzate iterazioni brevi, fatte validare dal cliente, attraverso l’uso di mock-up per la

parte di interfaccia utente e test a livello utente, realizzati dal vivo presso il cliente.

Nelle figura seguenti vengono mostrati alcuni dei mock-up realizzati:


111

Figura 39:Mock-up: schermata Visualizza Agenda

Figura 40:Mock-up: schermata Anagrafica Completa

5.2. Implementazione codice dell’applicativo


112

Sulla base delle richieste del committente l’applicazione è stata realizzata prima per

piattaforma Windows 8, dalla quale fare il porting verso il sistema Android sfruttando il

riutilizzo del codice già implementato. L’involucro nativo nel quale inserire il codice

HTML5 e javascript è costituito da un’applicazione del tipo Windows forms realizzata con

linguaggio di programmazione C#. Attraverso questo tipo di applicazione è possibile

accedere alle api grafiche per la costruzione dell’interfaccia utente; queste api sono poste

sopra il framework .NET e hanno accesso alle api Win32 del sistema operativo. Per

“embeddare” il codice HTML con cui è stata realizzata l’interfaccia grafica si è utilizzato

un componente denominato WebBrowser, che permette di utilizzare il rendering engine

utilizzato da Internet Explorer; attraverso il suo utilizzo viene caricato il codice HTML e

Javascript salvato in locale e sono abilitati i controlli web che permettono di navigare

attraverso le pagine, elaborare il codice javascript per rendere dinamica l’interfaccia

grafica ed effettuare le richieste AJAX al server. Per poter implementare la progettazione

orientata agli oggetti sono stati utilizzati pattern architetturali per poter utilizzare il codice

Javascript con il modello orientato agli oggetti. Per poter gestire la complessità

dell’applicazione e favorire la parallelizzazione dello sviluppo del codice è stato

implementato un pattern Model-View-Controller. Questo tipo di pattern architetturale è

molto diffuso nello sviluppo in applicazioni event-driven con interfacce utente grafiche.

Esso si basa sulla separazione dei compiti delle diverse classi, che si dividono in:

1- Classi Model: permettono l’accesso ai dati utili dell’applicazione

2- Classi View: visualizzano i dati del model e si occupano dell’interazione con l’utente,

inviando richieste al controller

3- Classi Controller: si occupano di ricevere le richieste dell’utente provenienti dalle

View, invocare il model per accedere e modificare i dati dell’applicazione e invocare

le class View per modificare l’interfaccia utente a seguito di aggiornamenti ricevuti

dalle richieste fatte al model.

Per poter realizzare questo pattern è stata realizzata una struttura dei contenuti web

chiamata single-page application. Essa consiste nel realizzare tutta l’interfaccia grafica in


113

una singola pagina html caricata all’avvio dell’applicazione; questa pagina viene

modificata nel contenuto in seguito ad aventi generati dall’utente, attraverso metodi

Javascript che vanno dinamicamente a modificare il DOM della pagina html per poter

creare le diverse schermate dell’applicazione. I contenuti html e javascript che vengono

caricati dinamicamente sono recuperati attraverso chiamate ajax su risorse salvate in locale

sul dispositivo. Tutte le funzionalità di interazione con l’utente e di modifica degli

elementi html delle schermate sono state realizzate con l’ausilio della libreria Jquery e di

diversi plug-in gratuiti reperibili in rete. Per effettuare l’autenticazione dell’ASI ed il

collegamento alla VPN di Poste Italiane attraverso rete 3G, è stata utilizzata una dll

(Dynamic-link library) rilasciata da PosteMobile che viene invocata durante il login

nell’applicazione; la comunicazione tra codice Javascript e C# viene realizzata attraverso

un oggetto javascript denominato window.external che si occupa di effettuare

l’invocazione dei metodi C# dal javascript, di passare i parametri ai metodi invocati e di

memorizzare gli eventuali dati di ritorno negli oggetti javascript. Questo meccanismo è

stato utilizzato anche per le invocazioni a funzionalità di memorizzazione permanente dei

nel database locale dell’applicazione client. Il database utilizzato è Sqlite. Esso permette di

utilizzare un database di tipo ACID che può essere incorporato in applicazioni senza

necessità di configurazioni, installazioni e processi in background da attivare. Esso ha

diverse caratteristiche interessanti; nonostante presenti anche diversi limiti le

caratteristiche richieste dall’applicazione nella memorizzazione in locale dei dati ben si

prestano all’utilizzo di questo tipo di database. Per la comunicazione col il server di back-

end sono state realizzate delle invocazioni a web services remoti invocati attraverso il

protocollo http utilizzando l’architettura REST (Representational state transfer) del server.

Questo tipo di architettura permette di invocare funzionalità remote e servizi offerti da

server attraverso il protocollo http e i suoi metodi GET,POST,PUT,DELETE. Attraverso

le URL (Uniform Resource Locator) alle risorse sul server, utilizzando un determinato

metodo nell’header http è possibile accedere e modificare lo stato di tali risorse. Le

convenzioni dell’architettura REST indicano che i metodi connessi ad una risorsa da

utilizzare sono:


114

GET: per recuperare i dati della risorsa sul server

POST: per creare una risorsa sul server

PUT: modificare una risorsa sul server

DELETE: cancellare una risorsa sul server

Durante la fase di sviluppo del codice il server su cui invocare i servizi non era stato

implementato; attraverso una serie di riunioni è stato possibile strutturare insieme alla

società a cui è stato commissionato la realizzazione dei servizi un ICD (interface contract

definition ); attraverso la stesura di questo documento, che fornisce i dettagli sulla

composizione delle richieste e delle risposte REST, è stato possibile realizzare il server per

i test della comunicazione in locale, in attesa dello sviluppo del server da utilizzare in

esercizio. Il formato di interscambio dei dati scelto è stato Json (JavaScript Object

Notation).

5.3. Analisi a posteriori della tecnologia ibrida

Per quantificare il beneficio apportato dall’uso della tecnologia ibrida nella realizzazione

dell’applicazione AGENDA ASI in ottica multipiattaforma, si è analizzato il codice

realizzato, attraverso la metrica delle LOC (line of code), al fine di determinare l’effort

richiesto per effettuare l’adattamento su piattaforma Android; per il conteggio è stato

scelto di selezionare le EXLOC (istruzioni eseguibili) e le DDLOC (istruzioni

dichiarative). Il codice dell’applicazione è stato suddiviso in 2 parti, codice realizzato con

tecnologie web e codice nativo realizzato in C#. Il primo è stato utilizzato per creare

l’interfaccia grafica e la logica di business dell’applicazione, il secondo è stato utilizzato

per costruire l’involucro nativo e per realizzare le funzionalità native utilizzate dal codice

Javascript. In tabella XXX sono riportati i dati sulle linee di codice dei 2 insiemi:

N° di righe di codice HTML - JAVASCRIPT 3287

N° di righe di codice C# 568

Tabella 13: numero di righe di codice dell’applicazione Windows 8

Attraverso l’analisi di questi dati è possibile effettuare una previsione dell’effort

necessario per adattare l’applicazione realizzata per piattaforma Windows 8 su Android. Il

codice da riscrivere è la parte nativa dell’applicazione. Quindi per questa applicazione è


115

possibile riutilizzare l’85% del codice prodotto, costituito dalla parte realizzata con le

tecnologie web. Il numero di righe di codice da realizzare attraverso il linguaggio Java su

piattaforma Android è molto simile a quello del C#. Il codice da realizzare sulla

piattaforma Android consiste nel creare l’involucro, configurare il componente webview

che si occupa di renderizzare le pagine HTML, abilitare l’eleborazione del linguaggio

Javascript per poter modificare l’interfaccia grafica dinamicamente ed invocare le

funzionalità native. Per le funzionalità native di accesso al database e di gateway verso la

VPN di Poste Italiane, verranno utilizzati rispettivamente Sqlite, disponibile nativamente

sulla piattaforma Android, e un componente sviluppato ad-hoc. Allo stato attuale può

essere richiesto un effort aggiuntivo dovuto alla non completa compatibilità delle

specifiche HTML5 e alle librerie Jquery sui diversi rendering engine utilizzati dai sistemi

operativi mobile. Questo lavoro tenderà in futuro a diminuire con il crescere del supporto

ad HTML5 e con la possibile convergenza dei rendering engine verso il Webkit. Di

seguito sono mostrate 2 screenshot a scopo dimostrativo dell’interfaccia grafica

dell’applicazione su 2 diversi dispositivi e sistemi operativi, uno con Windows 8 e l’altro

con Android 4.2:

Figura 41: Interfaccia grafica applicazione su Samsung Slate 7 (Windows 8)


116

Figura 42: Interfaccia grafica applicazione su Nexus 7 (Android 4.2)

Per realizzare l’applicazione demo eseguibile su piattaforma Android è stato riutilizzato

interamente il codice HTML5 e Javascript, creando il contenitore nativo, al quale è stato

aggiunto un modulo fake per simulare le richieste sul database, al fine di testare la

compatibilità del codice web prodotto con il rendering engine Webkit.

Conclusioni In questo capitolo è stato mostrato la realizzazione del codice applicativo per

l’applicazione AGENDA ASI su piattaforma Windows 8. Terminato il lavoro sono stati

raccolti i dati per poter quantificare il beneficio ottenuto dalla scelta della tecnologia

ibrida, che consente il riutilizzo del codice intorno all’85%. In questo modo per poter

eseguire il porting su diverse piattaforme, ad esempio Android, IOS, Windows RT, RIM, è

necessario produrre il codice con il linguaggio di sviluppo nativo che copre il 15% del

codice complessivo, al quale aggiungere eventuale codice nella parte web per gestire la

non uniformità al supporto dello standard HTML5 e alle librerie Jquery utilizzate.


117

Conclusioni e sviluppi futuri Il lavoro svolto in questa tesi si è focalizzato sulle tecnologie e le metodologie a supporto

nello sviluppo di applicazioni mobile multipiattaforma di tipo Enterprise. Nel mercato

mobile sia i customer che le aziende si stanno muovendo sempre più verso un ottica

mobile, guidata dalla continua innovazione di questo contesto. Inoltre la disponibilità dei

dati, delle comunicazioni, attraverso social network e applicazioni dedicate, delle

applicazioni in mobilità, sta trasformando il modo con cui vengono utilizzate le risorse IT

in azienda. All’interno di questa evoluzione i dispositivi che porteranno i maggiori

benefici del lavoro in mobilità saranno secondo le previsioni i tablet. Le aziende li stanno

introducendo in diversi settori e business process interni. Analizzando le previsioni di

mercato dei sistemi operativi mobile e le strategie aziendali sull’adozione di un

determinato sistema operativo di riferimento, è emerso che in futuro ci sarà

frammentazione e incertezza sul numero dei sistemi operativi da utilizzare per eseguire le

applicazioni da sviluppare a supporto delle attività aziendali; inoltre in grandi aziende

politiche di BYOD favoriscono la proliferazione di dispositivi e sistemi operativi diversi.

In questo contesto identificare una tecnologia a supporto dello sviluppo multipiattaforma e

multidevice permette di contenere i costi di produzione e di manutenzione delle

applicazioni mobile. Sono state identificate diverse soluzioni e tecnologie, ognuna con

determinati servizi che massimizzano i benefici su determinati driver, a discapito di altri.

Per poter selezionare la tecnologia da utilizzare bisogna analizzare il contesto di utilizzo,

basandosi sui requisiti dell’applicazione e sulle richieste dell’azienda committente. Per la

fase di selezione è stata utilizzata una metodologia di scelta multicriterio a supporto della

decisione. Sulla base dei risultati ottenuti e delle richieste aziendali relative ad


118

un’applicazione da sviluppare, è stata scelta la tecnologia ibrida. È stata quindi sviluppata

un’applicazione per Windows 8 con la tecnologia individuata. Sono stati analizzati i

benefici della scelta effettuata andando a quantificare il codice prodotto che può essere

riutilizzato per successive versioni dell’applicazione per altri sistemi operativi; l’85% del

codice prodotto può essere riutilizzato, andando a riscrivere il restante 15% con i linguaggi

nativi per ogni sistema operativo si intende supportare. A questo codice si deve aggiungere

un eventuale porzione di codice da adattare dovuta al non uniforme supporto verso

HTML5 e le librerie Jquery, fornito dai rendering engine delle diverse piattaforme

software. Questo intervento adattativo nel tempo si prevede tendi a diminuire grazie alla

standardizzazione delle specifiche di HTML5 e alla convergenza dei diversi sistemi

operativi verso il rendering engine Webkit.

Gli sviluppi futuri prevedono la realizzazione del porting su piattaforma Android

dell’applicazione utilizzando la tecnologia ibrida. Al termine dello sviluppo verranno

analizzati a posteriori i dati sul reale riutilizzo del codice e dell’effort richiesto per

effettuare l’adattamento dell’applicazione. Verranno inoltre monitorate le evoluzioni delle

diverse tecnologie a supporto dello sviluppo multipiattaforma al fine di ottenere dati

aggiornati per il confronto delle prestazioni offerte sui driver individuati. Ad esempio per

inizio 2013 sono previsti da parte dei framework Titanium Appcelerator e Adobe Air il

supporto alle piattaforme RIM e Windows 8, andando ad incrementare notevolmente la

portabilità di un’applicazione realizzata con queste tecnologie.


119


120

Bibliografia

[1] [Autore] [anno] “[titolo]”



Documents

Metodologie e tecnologie a supporto nello sviluppo di ...Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica tesi di laurea specialistica Metodologie e tecnologie a supporto