Embed Size (px)
Citation preview
POLITECNICO DI TORINO
IV Facoltà di Ingegneria
Corso di Laurea in Ingegneria Gestionale, ICT Management
Tesi di Laurea Specialistica
Piattaforme di sviluppo per
applicazioni Web a livello Enterprise:
analisi comparativa e considerazioni
economico-organizzative
Scenari per l'avvio di una business line in Cefin Systems
Relatori:
Prof. Fulvio Corno
Prof. Carlo Cambini
Candidato:
Carlo BERGOGLIO
Marzo 2010
Sommario
I
Sommario
Il presente elaborato si pone l’obiettivo di illustrare lo scenario attuale e le tendenze del settore SaaS
(Software-as-a-Service), proponendo la valutazione di alcune piattaforme Web in ottica tecnologica,
funzionale ed economica. A tal proposito, si ringrazia l’azienda Cefin Systems Italia, che ha consenti-
to al candidato di svolgere durante lo stage gran parte delle attività di ricerca ed analisi.
Il progetto sviluppato deriva da specifiche esigenze dell’azienda, che desiderava valutare
l’opportunità di creare una nuova linea di business dedicata allo sviluppo di applicazioni Web perso-
nalizzate ed erogate totalmente in modalità SaaS. L’incarico si è articolato in due diverse aree, la
prima legata ad argomenti propriamente tecnologici, rivolti all’analisi, alla sperimentazione e alla
scelta delle soluzioni informatiche più idonee, mentre la seconda è consistita nella redazione di un
business case, con l’obiettivo di valutare la convenienza dell’investimento e le sue caratteristiche.
Al momento, il background di Cefin Systems risultava focalizzato sulla fornitura di servizi per la ge-
stione di flotte di veicoli (fleet management) attraverso supporti informatici, telematici e satellitari con
il prodotto Sateltrack, già erogato in modalità SaaS. A questo si affiancavano altri servizi, quali con-
sulenze in ambito IT, analisi di processo, analisi di fattibilità e progettazione architetturale del softwa-
re, mentre lo sviluppo di codice e il debugging veniva abitualmente demandato ad una società terza
(Krescendo Ltd). L’azienda risultava pertanto interessata a valutare l’appetibilità del mercato del sof-
tware Web-based, offrendo applicazioni B2B (Business-to-Business) personalizzate e "chiavi in ma-
no", erogate completamente secondo il modello SaaS, sul quale il personale disponeva già di ottime
competenze. Questo significava individuare le tecnologie informatiche più idonee, le eventuali strate-
gie di collaborazione con aziende partner (in particolare, la società Krescendo possedeva già una
piattaforma di questo tipo, estremamente flessibile e ben conosciuta a livello funzionale da Cefin
Systems) e la definizione delle risorse da impiegare.
L’ouput finale avrebbe supportato il management aziendale nella decisione, offrendo un giudizio sulla
convenienza all’investimento e le informazioni tecniche e gestionali utili alla definizione del progetto
esecutivo.
Ringraziamenti
II
Ringraziamenti
Il candidato desidera ringraziare tutto il team Cefin Systems, in particolare Davide Cattai, che ha
permesso l’ideazione e lo sviluppo del presente elaborato oltre che il conseguimento di
un’esperienza interessante, valorizzata dalla fiducia e dall’elevata libertà di iniziativa concessa, non
comune in molti stage aziendali. Ulteriori riconoscimenti sono rivolti all’azienda londinese Krescendo,
in particolare al team di eXtraSheet, che ha fornito supporto ed informazioni di carattere tecnico, di-
stinguendosi per competenza e disponibilità.
Si ringrazia inoltre l’Ateneo, che è stato un riferimento importante in questi cinque anni, con particola-
re riguardo a tutti i colleghi di studio e ai relatori del presente elaborato, Prof. Corno e Prof. Cambini,
che hanno seguito con disponibilità e professionalità il candidato.
Sentiti ringraziamenti sono rivolti alla famiglia, che ha supportato il candidato durante il percorso di
studi, fornendo collaborazione e suggerimenti estremamente preziosi.
Il candidato dedica il presente elaborato al nonno, Carlo Navone, recentemente scomparso.
Indice
III
Indice
SOMMARIO ................................................................................................................... I
RINGRAZIAMENTI ......................................................................................................... II
INDICE ........................................................................................................................ III
ELENCO DELLE TABELLE ........................................................................................... VII
ELENCO DELLE FIGURE ............................................................................................... IX
1 INTRODUZIONE ...................................................................................................... 1
1.1 Contesto generale.................................................................................................. 1
1.2 Il modello SaaS (Software-as-a-Service) ............................................................... 2
1.3 Le piattaforme di sviluppo ...................................................................................... 4
1.4 Obiettivi della tesi ................................................................................................... 6
2 GLI OBIETTIVI DEL PROGETTO ................................................................................. 8
2.1 L’azienda Cefin Systems Italia ............................................................................... 8
2.1.1 Presentazione generale ................................................................................................ 8
2.1.2 Il mercato di riferimento ............................................................................................... 10
2.1.3 Sateltrack ..................................................................................................................... 10
2.1.4 SaaS e Cefin Systems ................................................................................................ 15
2.2 I contenuti ............................................................................................................ 16
2.3 L’ambito applicativo ............................................................................................. 17
2.4 La piattaforma ...................................................................................................... 18
3 EXTRASHEET ...................................................................................................... 19
3.1 Panoramica di Krescendo Ltd .............................................................................. 19
3.2 Introduzione ad eXtraSheet ................................................................................. 20
3.2.1 La storia ....................................................................................................................... 20
3.2.2 Le funzionalità applicative standard ............................................................................ 21
3.2.3 L’evoluzione di eXtraSheet .......................................................................................... 23
3.3 Sviluppi e tendenze .............................................................................................. 24
3.4 Architettura Software ........................................................................................... 25
3.4.1 La piattaforma J2EE .................................................................................................... 25
3.4.2 MySQL RDBMS ........................................................................................................... 30
Indice
IV
3.4.3 Componenti e librerie Java .......................................................................................... 31
3.4.4 Resin Application Server ............................................................................................. 36
3.4.5 Client side Javascript................................................................................................... 37
3.5 Configurazione Hardware .................................................................................... 38
3.6 Processi di sviluppo e hosting .............................................................................. 39
4 LE ALTERNATIVE AD EXTRASHEET ........................................................................ 42
4.1 Commerciali ......................................................................................................... 42
4.1.1 DabbleDB .................................................................................................................... 42
4.2 Open source basati analoga tecnologia ............................................................... 45
4.2.1 WaveMaker ................................................................................................................. 45
4.2.2 Apache Click ................................................................................................................ 47
4.2.3 OpenXava .................................................................................................................... 47
4.3 Open source basati su tecnologie differenti ......................................................... 49
4.3.1 Xataface ...................................................................................................................... 49
4.3.2 VFront .......................................................................................................................... 50
5 CASI DI STUDIO .................................................................................................... 52
5.1 Applicazione standard di Data Management ........................................................ 52
5.1.1 eXtraSheet ................................................................................................................... 52
5.1.2 WaveMaker ................................................................................................................. 56
5.1.3 VFront .......................................................................................................................... 58
5.1.4 Xataface ...................................................................................................................... 64
5.2 Applicazione per questionari on-line .................................................................... 67
5.2.1 Lo sviluppo su eXtraSheet .......................................................................................... 68
5.2.2 Previsioni per le altre piattaforme ................................................................................ 70
5.3 Applicazione di Web Timesheet ........................................................................... 70
5.3.1 Personal Timesheet..................................................................................................... 71
5.3.2 Timesheet Controller ................................................................................................... 71
5.3.3 Considerazioni ............................................................................................................. 72
6 BENCHMARKING .................................................................................................. 74
6.1 Confronto dei risultati ........................................................................................... 74
6.1.1 eXtraSheet: professionale e performante ................................................................... 74
6.1.2 VFront: clone PHP di eXtraSheet ................................................................................ 75
6.1.3 WaveMaker: altamente custom e IDE Web ................................................................ 76
6.1.4 Xataface: immediato .................................................................................................... 76
6.2 Metodologia QFD ................................................................................................. 77
Indice
V
6.2.1 Requisiti utente ............................................................................................................ 78
6.2.2 Requisiti di sistema...................................................................................................... 79
6.2.3 Gerarchizzazione caratteristiche tecniche .................................................................. 80
6.2.4 Benchmarking .............................................................................................................. 83
6.3 Individuazione dei trade-off .................................................................................. 86
7 MERCATO E STRATEGIA ....................................................................................... 88
7.1 Definizione del mercato e della business idea ...................................................... 88
7.2 I potenziali concorrenti ......................................................................................... 89
7.3 I trend del settore ................................................................................................. 90
7.4 La profittabilità: analisi di Porter ........................................................................... 92
7.4.1 Grado della competitività interna ................................................................................. 92
7.4.2 Barriere all’entrata ....................................................................................................... 93
7.4.3 Potere dei fornitori ....................................................................................................... 94
7.4.4 Potere dei clienti .......................................................................................................... 94
7.4.5 Prodotti sostituti ........................................................................................................... 95
7.4.6 Conclusioni .................................................................................................................. 95
7.5 Analisi resource based ......................................................................................... 95
7.6 Strategia di marketing e sales .............................................................................. 96
7.7 Organizzazione prevista....................................................................................... 98
8 VALUTAZIONI ECONOMICHE ................................................................................ 100
8.1 Scenari selezionati ............................................................................................. 100
8.1.1 Stretta partnership con Krescendo ............................................................................ 100
8.1.2 Soluzione ponderata ................................................................................................. 101
8.1.3 Scenario autonomo ................................................................................................... 102
8.2 Piani di investimento .......................................................................................... 103
8.2.1 Investimenti hardware ............................................................................................... 103
8.2.2 Investimenti software ................................................................................................. 107
8.2.3 Servizi di hosting ....................................................................................................... 108
8.2.4 Costi di avviamento ................................................................................................... 109
8.2.5 Costi del personale .................................................................................................... 110
8.2.6 Altri oneri ................................................................................................................... 110
8.2.7 Differenze tra gli scenari ............................................................................................ 111
8.3 Analisi cash flow e profittabilità .......................................................................... 111
8.3.1 Analisi di sensitività ................................................................................................... 118
9 ANALISI DEI RISCHI E MILESTONE PROGETTUALI ................................................... 121
Indice
VI
9.1 Fattori critici del progetto .................................................................................... 121
9.2 Valutazione dei rischi ......................................................................................... 121
9.3 Macroattività e tempistiche proposte .................................................................. 126
10 CONCLUSIONI ................................................................................................ 130
10.1 Valutazione critica dei risultati ............................................................................ 130
10.2 Sviluppi futuri ..................................................................................................... 132
BIBLIOGRAFIA .......................................................................................................... 134
Elenco delle tabelle
VII
Elenco delle tabelle
Tabella 3.1 - Esempio di configurazione di una postazione di sviluppo ............................................. 41
Tabella 6.1 - Scala di priorità per i requisiti utente .............................................................................. 78
Tabella 6.2 - Requisiti Utente per la piattaforma Web ........................................................................ 78
Tabella 6.3 - Classificazione delle provided function o caratteristiche tecniche ................................. 80
Tabella 6.4 - Scala impiegata nella Matrice delle Relazioni ................................................................ 81
Tabella 6.5 - Caratteristiche tecniche più rilevanti ricavate dall'applicazione del QFD ....................... 83
Tabella 6.6 - Scala di valutazione per la copertura delle caratteristiche tecniche .............................. 84
Tabella 6.7 - Risultati del benchmarking tra le soluzioni individuate................................................... 86
Tabella 6.8 - Riepilogo risultati del Benchmarking .............................................................................. 87
Tabella 7.1 - Esempio di tariffe per progetto ad hoc di dimensioni ridotte .......................................... 97
Tabella 7.2 - Spese di marketing annue preventivate ......................................................................... 98
Tabella 8.1 - Configurazione hardware proposta per postazione di sviluppo ................................... 103
Tabella 8.2 - Esempio di configurazione hardware già disponibile sul mercato ............................... 104
Tabella 8.3 - Secondo esempio configurazione hardware già disponibile sul mercato .................... 105
Tabella 8.4 - Monitor LCD proposto .................................................................................................. 105
Tabella 8.5 - Configurazione del server interno suggerita da Krescendo ......................................... 106
Tabella 8.6 – Configurazione alternativa del server interno .............................................................. 107
Tabella 8.7 - Investimenti in software ................................................................................................ 108
Tabella 8.8 - Dettaglio del canone mensile di hosting per il server di produzione ............................ 109
Tabella 8.9 - Soluzione alternativa per l’hosting per il server di produzione ..................................... 109
Tabella 8.10 - Costi di avviamento stimati ........................................................................................ 110
Tabella 8.11 - Assunzioni relative al costo del personale ................................................................. 110
Tabella 8.12 - Prospetto costi-benefici - Scenario A ......................................................................... 113
Tabella 8.13 - Cash flow - Scenario A ............................................................................................... 114
Tabella 8.14 - Prospetto costi-benefici - Scenario B ......................................................................... 115
Tabella 8.15 - Cash flow - Scenario B ............................................................................................... 116
Tabella 8.16 - Prospetto costi-benefici - Scenario C ......................................................................... 117
Tabella 8.17 - Cash flow - Scenario C .............................................................................................. 118
Elenco delle tabelle
VIII
Tabella 8.18 - Analisi di sensitività sul tasso di rendimento richiesto ............................................... 119
Tabella 8.19 - Analisi di sensitività sui ricavi previsti......................................................................... 119
Tabella 8.20 - Analisi di sensitività sul tasso di crescita dei profitti ................................................... 120
Tabella 9.1 - Criteri considerati per l'analisi dei rischi ....................................................................... 124
Tabella 9.2 - Prospetto di analisi dei rischi di progetto ..................................................................... 125
Tabella 9.3 - Schedulazione proposta delle macroattività ................................................................ 128
Elenco delle figure
IX
Elenco delle figure
Figura 2.1 - Cefin Romania ................................................................................................................... 8
Figura 2.2 - Le società del gruppo Cefin ............................................................................................... 9
Figura 2.3 - Le funzionalità di Sateltrack ............................................................................................. 11
Figura 2.4 - Sateltrack, alcuni screenshot dell’interfaccia Web .......................................................... 12
Figura 2.5 - Sateltrack, funzionalità di reporting disponibili sull'interfaccia Web ................................ 13
Figura 2.6 - Uno schema introduttivo sul funzionamento di Sateltrack ............................................... 14
Figura 3.1 - Schema semplificato dell'architettura di eXtraSheet ....................................................... 25
Figura 3.2 - Applicazioni multilivello in J2EE ....................................................................................... 26
Figura 3.3 - Client tier (componenti lato client) in J2EE ...................................................................... 27
Figura 3.4 - Web tier in J2EE .............................................................................................................. 28
Figura 3.5 - Business tier in J2EE ....................................................................................................... 29
Figura 3.6 - Ruolo dei J2EE container ................................................................................................ 30
Figura 3.7 - Le caratteristiche del framework uView ........................................................................... 33
Figura 3.8 - L'architettura di uView ...................................................................................................... 34
Figura 3.9 - Schema dell'infrastruttura hardware di eXtraSheet ......................................................... 39
Figura 4.1 - Interfaccia Web di Dabble DB .......................................................................................... 44
Figura 4.2 - Stima del traffico mensile negli U.S. per Dabble DB ....................................................... 44
Figura 4.3 - L'architettura di WaveMaker ............................................................................................ 46
Figura 5.1 - Pagina principale di Sateltrack Admin su eXtraSheet ..................................................... 53
Figura 5.2 - Pagina di creazione di uno sheet su eXtraSheet ............................................................. 53
Figura 5.3 - Form di data-entry su eXtraSheet .................................................................................... 54
Figura 5.4 - Elenco delle liste predefinite su eXtraSheet .................................................................... 55
Figura 5.5 - Gestione delle liste predefinite su eXtraSheet ................................................................. 55
Figura 5.6 – Gestione dei gruppi di utenti su eXtraSheet ................................................................... 55
Figura 5.7 - Creazione di una vista sul database in Wavemaker........................................................ 57
Figura 5.8 - WaveMaker Visual AJAX Studio ...................................................................................... 57
Figura 5.9 - Sateltrack Admin realizzata con WaveMaker .................................................................. 58
Figura 5.10 - Configurazione delle permission sulla tabella in VFront ................................................ 60
Elenco delle figure
X
Figura 5.11 - Configurazione dei campi in VFront............................................................................... 61
Figura 5.12 - Pagina principale di Sateltrack Admin (VFront) ............................................................. 62
Figura 5.13 - Form di data-entry in VFront .......................................................................................... 63
Figura 5.14 - Grid view in VFront ........................................................................................................ 64
Figura 5.15 - Visualizzazione standard dei record in Xataface ........................................................... 66
Figura 5.16 - Xataface, form di inserimento o editing ......................................................................... 67
Figura 5.17 - Questionario (parziale) realizzato su eXtraSheet per la valutazione del personale ...... 68
Figura 5.18 - Report (parziale) relativo alle valutazioni ricevute da una divisione aziendale ............. 69
Figura 5.19 - Funzionalità di Personal Timesheet .............................................................................. 71
Figura 5.20 - Funzionalità di Timesheet Controller ............................................................................. 72
Figura 6.1 - QFD: la matrice delle relazioni ......................................................................................... 82
Figura 6.2 - Rappresentazione grafica dei risultati del Benchmarking ............................................... 86
Figura 7.1 - Performance in termini di ricavi del mercato SaaS (Gartner 2009) ................................. 92
Figura 7.2 - Organizzazione proposta per la nuova divisione ............................................................. 99
Figura 8.1 - Calcolo del VAN - Scenario A ........................................................................................ 114
Figura 8.2 - Calcolo del VAN - Scenario B ........................................................................................ 116
Figura 8.3 - Calcolo del VAN - Scenario C ........................................................................................ 118
Figura 8.4 - Break-even sui ricavi previsti ......................................................................................... 119
Figura 9.1 - Il processo di risk management ..................................................................................... 123
Figura 9.2 - Diagramma di GANTT risultante dalla schedulazione ................................................... 129
Introduzione
1
1 Introduzione
1.1 Contesto generale
Le tendenze IT sono indubbiamente orientate al Web, che ha ormai raggiunto e superato la soglia
psicologica del ―2.0‖. Social network, applicazioni ibride ―mash-up‖, E-Commerce, wiki, Open Source
e accesso con dispositivi mobili sono forse gli esempi più rilevanti delle attuali applicazioni, rendendo
il Web sempre più interattivo e fruibile ma, al contempo, ampliandone la sua complessità.
Se i casi citati risultano ben noti, non sono altrettanto evidenti, soprattutto al ―grande pubblico‖, i ri-
svolti e le nuove evoluzioni nell’ambito dei sistemi informativi aziendali, sotto gli aspetti strategici ed
operativi. L’introduzione sempre più rapida sul mercato di nuove tecnologie dell’informazione e della
comunicazione (ICT) fornisce alle imprese molteplici opportunità per supportare le proprie attività di
business, offrendo sostanziali benefici, quali incrementi di produttività, efficienza negli scambi infor-
mativi, riduzione dei costi e miglioramenti della qualità o dei livelli di servizio.
Le tecnologie Web, che condividono l’infrastruttura ed i protocolli di comunicazione di Internet, hanno
riscosso notevoli attenzioni anche nel settore business, inducendo le imprese ad investire sempre
più massicciamente in sistemi informativi Web-based (anche noti come Web-based Information
System, WBIS), considerati la nuova generazione di sistemi informativi. La notevole diffusione dei
protocolli Web consente una riduzione dei costi di infrastruttura e di manutenzione del software che
impiega queste tecnologie. Inoltre, le applicazioni che sfruttano il Web come mezzo di connessione
possono essere distribuite su più apparati hardware e possono venire condivise agevolmente da
molti utenti, riducendo al minimo i problemi di compatibilità. Per queste ragioni, molte organizzazioni
sono in fase di conversione dei propri sistemi informativi, per ricondurli ad architetture Web o per
consentirne l’integrazione con le nuove tecnologie distribuite.
Le applicazioni Web si presentano attraverso un’interfaccia grafica spesso molto standard che con-
sente agli utenti l’interazione e l’accesso a diverse fonti di dati e applicazioni. Infatti, attraverso un
comune Web-broswer, l’utente può accedere a qualunque applicazione Web e le modalità di intera-
zione (operazioni di login, utilizzo di link, compilazione di form, etc.) sono oggi altamente comuni e
standardizzate. Le difficoltà di utilizzo di un sistema informativo Web-based sono quindi estrema-
mente ridotte rispetto ad uno tradizionale, poiché risulta maggiormente user-friendly per l’utente che
è immediatamente in grado di interagire con esso: si elimina così la fase di apprendimento basilare e
l’utente può focalizzarsi direttamente sulle funzionalità specifiche dell’applicazione.
Un ulteriore aspetto che caratterizza il settore business è il probabile incremento del volume di dati:
un’analisi della società di ricerca Gartner afferma che crescerà di circa il 650% nei prossimi cinque
anni e avrà costi elevati se non gestita con tecnologie adeguate, ad esempio con la stratificazione in
Introduzione
2
più livelli (tiering) dello storage, che comporta l’archiviazione intelligente dei dati in base alla rilevan-
za e alla frequenza di consultazione.
In questo scenario, è prevista una crescita della complessità delle applicazioni Web e, al contempo,
la necessità di realizzare soluzioni in tempi ridotti, secondo il paradigma ―la tecnologia a servizio del
business‖. La conseguenza più verosimile risulterà la centralizzazione e spesso l’esternalizzazione
dello sviluppo, ricorrendo a soluzioni SaaS o, più in generale, di Cloud computing: immediate, distri-
buite, accessibili, affidabili, all-inclusive.
1.2 Il modello SaaS (Software-as-a-Service)
Le tradizionali divisioni IT aziendali sono attualmente in fase regressiva: fenomeni quali la complessi-
tà, la manutenzione e la sicurezza del software, inducono molte aziende ad esternalizzare i servizi
informatici e tecnologici, ricorrendo alle numerose soluzioni offerte da aziende specializzate. Tra
queste, viene spesso richiesta la completa gestione del sistema informativo aziendale, dallo sviluppo
alla manutenzione, rendendolo usufruibile dal cliente tramite la rete Internet. Si provvederà di seguito
a delineare pregi e difetti di tale soluzione, che probabilmente troverà sempre maggiore diffusione
nella fornitura di servizi informatici.
Il modello SaaS (Software-as-a-Service), in passato più noto con l’acronimo ASP (Application Servi-
ce Provider), è attualmente l’approccio predominante e sta riscontrando una vasta diffusione nella
fornitura di soluzioni informatiche in qualunque ambito. Infatti, la riduzione progressiva dei costi di
connessione a banda larga e i notevoli risparmi in infrastruttura hardware, spingono molti clienti bu-
siness ad adottare soluzioni ASP.
SaaS è una tecnologia che permette di accedere a soluzioni software attraverso Internet ed utilizzare
gli applicativi a fronte del pagamento di un canone. Il software offerto usando il modello SaaS è
spesso chiamato software "on demand" o software come servizio.
L’esigenza di un sistema SaaS ha avuto origine con l'aumento dei costi di software specifici che
hanno fortemente superato le capacità di spesa di attività medio-piccole. Al contempo, la sempre
maggior complessità del software ha determinato una crescita dei costi di distribuzione agli utenti fi-
nali. Attraverso il modello SaaS, le complessità e i costi di tali software possono essere ridotti sensi-
bilmente. Inoltre i problemi di aggiornamento dei software non coinvolgono più l'utente finale ma so-
no effettuati a cura del fornitore. Quest’ultimo garantisce un servizio sempre disponibile e spesso un
supporto tecnico del tipo 24 x 7 e sicurezza fisica e informatica.
Le caratteristiche principali associate al sistema SaaS sono:
1) il fornitore possiede completamente gli applicativi software e ne garantisce il funzionamento;
2) il fornitore possiede, mantiene e assicura il funzionamento dei componenti hardware e dei
server su cui sono installati gli applicativi;
Introduzione
3
3) il fornitore rende disponibili le funzionalità del software ai clienti attraverso la rete Internet e
un comune browser o eventualmente installando applicativi molto leggeri sui client (―thin
client‖);
4) la fatturazione avviene in base all’effettivo utilizzo dell’applicativo oppure secondo canoni
mensili o annuali.
I vantaggi principali che ne conseguono sono:
nessun problema di compatibilità del software client-side poiché la fruibilità tramite Web
browser non richiede alcun software da installare;
i costi del software sono distribuiti su tutti i clienti (in caso di applicazioni standard);
i fornitori possono maturare più esperienza ed efficienza rispetto ad uno staff IT aziendale;
il software è mantenuto aggiornato, sempre disponibile e gestito da esperti per ottenere le
migliori performance;
migliore affidabilità, disponibilità e scalabilità rispetto a sistemi informativi interni;
maggiore sicurezza fisica ed informatica (back-up periodici dei dati, dispositivi antincendio,
sistemi antintrusione, ecc.);
livelli di servizio prefissati sulla base dei SLA (Service Level Agreement) contrattati tra cliente
e fornitore del servizio;
costi IT interni ridotti e facilmente prevedibili per il cliente (spesso sono canoni mensili fissi),
con possibilità di re-impiegare personale e capitale per focalizzarsi su attività "core" dell'a-
zienda;
il cliente ha la possibilità di utilizzare il software da un numero illimitato di postazioni senza
costi aggiuntivi;
assistenza qualificata e garantita in modo continuativo.
Alcuni svantaggi relativi sono:
Il cliente deve generalmente accettare l'applicazione "così com'è" perché il fornitore ASP non
può realizzare soluzioni personalizzate per soddisfare le esigenze clienti specifici.
Il cliente che necessita una funzione aggiuntiva non ha alcuna garanzia che essa venga ef-
fettivamente implementata dal fornitore. Normalmente vengono sviluppate solo funzionalità
richieste da un elevato numero di clienti e facilmente standardizzabili.
L'integrazione con le altre applicazioni Legacy del cliente può risultare problematica.
Introduzione
4
1.3 Le piattaforme di sviluppo
Le piattaforme più diffuse in ambito di applicazioni Web, senza entrare per ora nei dettagli, possono
essere definite come l’insieme delle tecnologie, prevalentemente software, che permettono di svilup-
pare il software ed erogarlo tramite il canale Web.
In generale, una piattaforma comprende diversi moduli software e più linguaggi di programmazione,
poiché le odierne applicazioni Web prevedono la dinamicità (capacità di elaborazione) sia del client,
sia del server. Questa soluzione permette di migliorare l’interazione tra utente e sistema, consente
un accesso adeguato ai dati ed alle applicazioni ed è indispensabile per lo sviluppo di applicazioni
aziendali basate sugli standard Internet.
Le tecnologie di programmazione lato client sono altamente standardizzate, dovute alla necessità di
avere la massima compatibilità sui client che sono potenzialmente molto numerosi e dispongono uni-
camente di un browser Web per usufruire dell’applicazione. Per la presentazione vengono impiegati i
linguaggi di markup HTML/XHTML e il linguaggio di scripting Javascript per l’elaborazione lato client,
a cui sono talvolta affiancati componenti più complessi, quali applet Java o MS ActiveX.
Mentre le elaborazioni lato client sono spesso ridotte e con il solo scopo di aumentare le potenzialità
interattive dell’applicazione, l’elaborazione lato server è solitamente molto complessa. Le principali
alternative risultano essere:
- CGI (Common Gateway Interface): è la soluzione meno recente e consiste in un protocollo
per interfacciare un’applicazione esterna (scritta in qualunque linguaggio di programmazio-
ne) con un Web server. Al momento della richiesta dell’utente (tramite browser), il Web
server attiva l’applicazione esterna passando eventuali parametri e restituisce i risultati otte-
nuti (che devono già essere in formato Web) al client. Questo paradigma è oggi obsoleto,
poiché non prevede meccanismi di condivisione delle risorse, non esistono i concetti di ses-
sione e transazione e non vi è separazione tra elaborazione e presentazione (formattazione
―annegata‖ nel codice). CGI risulta quindi inadatto per applicazioni con molti utenti, attivi si-
multaneamente che richiedono bassi tempi di risposta.
- PHP (Hypertext Preprocessor): pur essendo un linguaggio di scripting lato server, può esse-
re paragonato ad una vera piattaforma, abbinato al Web server Apache e al database
MySQL. È largamente impiegato in qualunque genere di applicazioni Web, da semplici siti
dinamici (in cui è pressoché uno standard de-facto) ad applicazioni Enterprise. Essendo O-
pen Source (licenza PHP), sono disponibili innumerevoli estensioni, script e librerie che ren-
dono questa piattaforma altamente versatile, supportata e semplice da utilizzare.
- ASP e ASP.NET: tecnologie proprietarie Microsoft, disponibili con i server IIS (Internet Infor-
mation Services); ASP è ormai in disuso poiché utilizza linguaggi interpretati, è scarsamente
scalabile e non offre molte funzionalità richieste dalle odierne applicazioni Web. ASP.NET ri-
sulta invece più performante, è basato sul framework di Microsoft .NET, prevede la precom-
Introduzione
5
pilazione delle pagine dinamiche e fornisce ambienti di sviluppo (anch’essi proprietari) com-
pleti.
- Java Platform: la piattaforma Java (anche conosciuta come J2EE per la versione Enterprise
e J2SE per quella Standard) presenta un’architettura complessa ma è certamente
all’avanguardia per la strutturazione e lo sviluppo di applicazioni Web performanti e scalabili.
Come sarà approfondito in seguito, utilizza gli oggetti Servlet, che permettono di elaborare
una richiesta senza creare un nuovo processo, ma solo di un thread all’interno
dell’application server. Il lato presentazione viene gestito mediante le Java Server Pages
(JSP), che sono pagine HTML contenenti del codice Java che viene eseguito sulla piattafor-
ma server. La prima volta che la pagina è richiamata viene tradotto il codice sorgente Java e
la pagina viene compilata sotto forma di Servlet, memorizzata su disco e eseguita; alle suc-
cessive richieste verrà immediatamente eseguita. La piattaforma Java è distribuita quasi in-
teramente con licenza Open Source e vi sono numerosi framework e librerie disponibili con
la medesima licenza.
- Ruby on Rails: è un framework open source per lo sviluppo rapido di applicazioni Web che
utilizza il linguaggio interpretato Ruby. Implementa le moderne tecniche di sviluppo ed è
compatibile con numerosi Web server. Ha raggiunto la notorietà negli ultimi due anni grazie
alla compattezza del linguaggio e alla sua configurazione minimale.
A livello di piattaforma software, senza considerare i framework di livello superiore, non esiste una
soluzione migliore: è necessario considerare almeno quattro criteri di valutazione: scalabilità, rapidità
di sviluppo, facilità di manutenzione e disponibilità di strumenti di sviluppo. Effettuare una compara-
zione tecnica in questa sede risulterebbe superficiale e ci si limita a fornire alcune osservazioni di ca-
rattere pratico. Le piattaforme attualmente più diffuse sono PHP e Java, la prima tendenzialmente
più rivolta a progetti di dimensioni limitate mentre la seconda è più impiegata per lo sviluppo di solu-
zioni più complesse e talvolta ―mission critical‖. La piattaforma Java prevede infatti un’architettura più
articolata e lo sviluppo richiede spesso tempi e risorse superiori rispetto a PHP.
Si stima che i tempi di sviluppo in Java trovino una riduzione del 30% impiegando PHP e arrivano al
50% con Ruby on Rails. Altre fonti indicano che circa il 90% delle applicazioni Web può essere svi-
luppata più agevolmente in PHP e senza determinare differenze percepibili rispetto ad uno sviluppo
su J2EE.
In conclusione, le tecnologie attualmente più consolidate in ambito Web risultano Java e PHP;
Microsoft conserva una fetta di mercato apprezzabile anche se la piattaforma proprietaria e la limita-
ta interoperabilità ne penalizzano la diffusione; le piattaforme più recenti, quale Ruby on Rails, risul-
tano ancora scarsamente diffuse e, al momento, non richiamano le attenzioni del settore Enterprise.
Introduzione
6
1.4 Obiettivi della tesi
La presente Tesi di Laurea si propone molteplici obiettivi che risultano tuttavia classificabili in due ca-
tegorie differenti. La prima, di carattere maggiormente tecnologico, è rivolta all’individuazione delle
best practice emergenti nelle moderne applicazioni Web di classe Enterpise e la ricerca delle migliori
alternative attualmente disponibili. La seconda parte è invece destinata alla valutazione dell’impatto
economico e organizzativo sostenuto da un’impresa che volesse avviare la fornitura di alcune delle
soluzioni individuate.
Nella prima parte, si vuole indagare nel dettaglio sulla disponibilità di soluzioni che permettano lo svi-
luppo rapido (o quasi immediato) di applicazioni Web, senza inizialmente avere la necessità di svi-
luppare codice ma con la possibilità di farlo in un secondo momento, qualora le funzionalità standard
fossero insufficienti a coprire le esigenze. Si vuole quindi sondare quali siano le alternative in grado
di realizzare applicazioni di data management tramite un front-end (possibilmente anch’esso Web-
based) oppure con semplici operazioni che non richiedano competenze di programmazione avanza-
te, ma possano anche venire svolte da analisti funzionali o altre figure professionali che necessitino
di semplici applicazioni per supportare processi aziendali.
In sostanza, non si vuole condurre un’analisi sulle piattaforme software di cui al paragrafo preceden-
te, bensì ricercare e valutare soluzioni ―out of the box‖ o framework di alto livello per una rapida rea-
lizzazione di applicazioni Web, che possano tuttavia venire agevolmente personalizzate (o integrate
con moduli sviluppati completamente ad hoc) da sviluppatori più esperti con un effort contenuto.
Il presente elaborato si pone l’obiettivo di rispondere alle seguenti domande: quali sono le caratteri-
stiche e la complessità delle attuali applicazioni Web aziendali? Sono disponibili piattaforme per il
problem solving, che permettano di creare applicazioni con limitato ricorso allo sviluppo di codice?
Quali sono gli effort richiesti per commercializzare soluzioni realizzate con tali strumenti?
Il secondo genere di obiettivi è invece quello di determinare quali siano le competenze necessarie
alla creazione di una organizzazione rivolta allo sviluppo delle applicazioni Web con le migliori tecno-
logie individuate nella prima fase, se sia realmente possibile disporre di un team di sviluppo molto più
limitato. Inoltre si vuole esplicitare quali siano le esigenze e le tendenze del mercato e determinare le
caratteristiche dell’investimento, mediante la stesura di un ridotto Business Plan.
Sebbene le due componenti possano apparire disgiunte, sono in realtà interdipendenti poiché molti
aspetti legati alla scelta della piattaforma e delle soluzioni tecnologiche hanno risvolti gestionali ed
economici, influenzando, ad esempio, le caratteristiche dell’investimento e le competenze richieste al
personale; viceversa gli aspetti commerciali caratterizzano la scelta della piattaforma informatica,
che sarà effettuata in base alle caratteristiche del segmento di mercato prescelto.
Le finalità della presente tesi corrispondevano con l’opportunità offerta dall’azienda Cefin Systems
Italia, che prevedeva lo svolgimento di un progetto per la creazione una nuova Business Line in am-
bito SaaS per applicazioni Web personalizzate. La soluzione che verrà maggiormente presa in esa-
Introduzione
7
me sarà quella offerta dall’azienda Krescendo, poiché è stata studiata in dettaglio durante lo stage
del candidato, ma verranno analizzate alcune alternative, soprattutto open source.
Nel prossimo capitolo si provvederà a fornire il background dell’azienda Cefin Systems e una precisa
definizione del progetto proposto.
Gli obiettivi del progetto
8
2 Gli obiettivi del progetto
2.1 L’azienda Cefin Systems Italia
2.1.1 Presentazione generale
Cefin Systems Italia è una società del gruppo Cefin, che con circa 900 dipendenti, più di 100 milioni
di Euro di fatturato e sedi in Italia, Svizzera, Romania, Ungheria e Bulgaria costituisce una delle più
significative realtà multinazionali a capitale italiano in grado di fornire ed integrare prodotti e servizi
professionali nel settore dei veicoli industriali, commerciali e della mobilità.
Il gruppo Cefin è cresciuto in questi anni fino a diventare una delle realtà più significative a livello
mondiale nella vendita di veicoli Iveco. Il portafoglio di offerta del gruppo Cefin si estende dalla vendi-
ta di veicoli industriali e commerciali ai servizi di assistenza post-vendita ad essi collegati fino ai ser-
vizi finanziari. Recentemente le attività del gruppo hanno trovato ulteriori sbocchi anche nel settore
immobiliare e delle costruzioni con la società Cefin Real Estate.
Figura 2.1 - Cefin Romania
Le aziende principali che fanno parte del gruppo sono:
1) Cefin Bulgaria, Cefin Romania e ETS Ungheria (appartengono al settore del trasporto su
gomma e relativi servizi: vendita del veicolo e accessori, officine, servizio di assistenza
stradale, costruzione di veicoli speciali, mezzi agricoli…).
Gli obiettivi del progetto
9
2) Cefin Systems Romania e Cefin Systems Italia, le aziende ICT del gruppo. Nella sede
italiana sono accentrate le central functions, cioè le attività maggiormente strategiche e
decisionali.
3) Cefin Real Estate Romania e Cefin Real Estate Italia (operano nel settore della costruzione
immobiliare e costituiscono circa il 50% di fatturato del gruppo).
Le attività principali del gruppo sono concentrate in paesi che negli anni passati erano caratterizzati
da una elevata domanda dovuta alla situazione economica di forte crescita. I recenti sviluppi
economico-finanziari internazionali hanno determinato una crisi particolarmente accentuata nell’est
europeo, ma il gruppo Cefin ha dimostrato solidità e ottime doti manageriali per fronteggiarla, quando
invece molti concorrenti riscontravano difficoltà molto più gravi.
Figura 2.2 - Le società del gruppo Cefin
Attorno al nucleo costituito da Cefin Group orbitano anche una serie di aziende partner che commer-
cializzano i prodotti e le soluzioni del gruppo, trattenendo delle percentuali sul prezzo di vendita.
Cefin Systems è l’azienda di servizi di Information & Communication Technology del gruppo Ce-
fin, che valuta gli investimenti in tecnologia per tutto il gruppo ed è specializzata nella fornitura di ap-
plicazioni Web-based di Vehicle and Fleet Management, con il prodotto Sateltrack. Le soluzioni di
Cefin Systems sono focalizzate sulla telematica come valore aggiunto nei processi di business dei
propri clienti e di tutti gli attori della catena del valore dei veicoli industriali, commerciali ed autovettu-
re (dal costruttore del veicolo fino all’utilizzatore finale).
Gli obiettivi del progetto
10
Cefin Systems opera direttamente in Italia ed in Romania e, attraverso una rete di partner commer-
ciali, nei principali paesi dell’Europa Occidentale ed Orientale.
Mentre la società rumena è prevalentemente rivolta alla commercializzazione, supporto e assistenza
del prodotto Sateltrack, la società italiana si occupa degli aspetti strategici relativi all’evoluzione del
prodotto Sateltrack, dello sviluppo di nuove soluzioni e della fornitura di servizi di consulenza ICT.
2.1.2 Il mercato di riferimento
Cefin Systems concentra il suo core business nel fornire una piattaforma Web multi-funzionale, una
gamma di prodotti telematici d’avanguardia, soluzioni standardizzate e progetti "ad hoc". Un portafo-
glio di servizi professionali per portare efficienza nel settore dei trasporti, della logistica e della mobili-
tà veicolare.
Il prodotto Sateltrack è quindi il prodotto core dell’azienda, attraverso il quale detiene una notevole
clientela internazionale ed una reputazione altamente qualificata. I clienti principali sono business
(anche se Sateltrack è proposto a livello consumer, nella variante Sat-Family) che hanno la necessi-
tà di controllare in maniera precisa la propria flotta di veicoli. Tra di essi, vi sono società di car-rental
e car-sharing, ditte di autotrasporti, corrieri espresso e aziende che gestiscono la raccolta rifiuti con
centinaia di mezzi.
Oltre al prodotto Sateltrack, Cefin Systems offre una serie di servizi di consulenza principalmente in
ambito ICT per aziende che non dispongono delle competenze necessarie oppure desiderano affida-
re in outsourcing alcune attività. Tra di esse vi è l’analisi e la re-ingegnerizzazione di processo, il sof-
tware design, la stesura di specifiche funzionali e svariati servizi di project management.
Infine, Cefin Systems ha recentemente attivato un accordo con la società Krescendo, a cui viene già
commissionato lo sviluppo del codice per Sateltrack, per la commercializzazione del prodotto eXtra-
Sheet, di cui si parlerà in seguito, essendo parte centrale dell’elaborato.
2.1.3 Sateltrack
Sateltrack è senza dubbio il prodotto principale dell’azienda Cefin Systems. Può essere sintetica-
mente definito come un sistema per la gestione di flotte di veicoli (fleet management): è una piatta-
forma informatica basata su Internet per la raccolta, l'elaborazione, la gestione e la distribuzione di
dati di percorrenza e di funzionamento relativi ai veicoli del cliente.
Sateltrack è erogato in modalità SaaS (Software-as-a-Service) – meglio analizzata in seguito – per
consentire al cliente una riduzione degli investimenti in infrastruttura e dei costi di esercizio e manu-
tenzione a fronte di livelli di servizio concordati e personalizzabili.
Il sistema Sateltrack permette di controllare perfettamente i mezzi in termini di posizione e di dati di
percorrenza. Il principale obiettivo di un cliente di Sateltrack è quindi di monitorare lo stato e la posi-
Gli obiettivi del progetto
11
zione della flotta, talvolta anche al fine di fronteggiare furti del mezzo o di carburante (in casi di e-
mergenza è possibile creare un canale di comunicazione diretto con il device del veicolo e tracciarne
esattamente la posizione). L’utente più avanzato adotta Sateltrack per effettuare in maniera ottimale
le assegnazioni delle missioni tra i vari veicoli disponibili. Sateltrack permette di realizzare una otti-
mizzazione di processo nel settore dei trasporti, molti clienti lo adottano anche per le sue capacità di
reporting e di controllo continuo sui veicoli della flotta.
Il sistema è programmato totalmente in Java ed utilizza Open Standard e linguaggi per la program-
mazione Cross-Platform. L’intento è minimizzare la dipendenza dai produttori di software e
hardware.
Grazie ai Web Service già disponibili, la piattaforma Sateltrack è interfacciabile con i più diffusi si-
stemi ERP di gestione aziendale e con applicazioni informatiche di terze parti. La disponibilità di un
modulo cartografico evoluto consente inoltre l’interfacciamento con i database georeferenziati dei
principali fornitori globali e locali di cartografia.
Tutte le componenti della piattaforma Sateltrack sono attualmente installate su un cluster di server
Linux (Database, Application e Map Server) in esercizio presso Above Net, un centro di hosting pro-
fessionale basato nella ―Docks Area‖ di Londra, dal quale vengono erogati servizi applicativi in moda-
lità ASP (Application Service Providing).
Figura 2.3 - Le funzionalità di Sateltrack
La comunicazione con il veicolo è effettuata da un dispositivo da installarsi a bordo (device), alimen-
tato dall’impianto elettrico del mezzo ed in grado di acquisire segnali (es. avvio del motore, apertura
porte, ...); per alcuni veicoli è possibile ottenere informazioni provenienti dalla centralina: il sistema
più avanzato è quello di servirsi della rete di comunicazione CAN (Controller Area Network) del vei-
Gli obiettivi del progetto
12
colo, da cui si ricava una ampia varietà di dati quali i giri motore, la velocità istantanea, il consumo, il
carico e molte altre grandezze.
Le informazioni basilari tra cui posizione, velocità, chilometri totali e altre, riportate nel modulo di Sa-
teltrack ―Vehicle Usage‖, sono disponibili per ogni automezzo. Per le informazioni più specifiche rela-
tive a determinati sensori, raccolte nel modulo ―Vehicle Performances‖, la disponibilità dei dati è su-
bordinata alla dotazione del veicolo. Infatti praticamente ogni automezzo viene attualmente prodotto
con inclusi alcuni sensori collegati alla propria centralina elettrica. Come già preannunciato,
quest’ultima ha già predisposta un’uscita alla quale può essere interfacciato un device. Qualora non
fosse possibile il collegamento con la centralina, il cliente riceverà per il veicolo in questione sola-
mente le informazioni basilari. Inoltre, ai device più evoluti è possibile collegare fino a sette dispositivi
esterni da monitorare quali, ad esempio, sensori di temperatura o prese di forza (PTO).
Figura 2.4 - Sateltrack, alcuni screenshot dell’interfaccia Web
Gli obiettivi del progetto
13
Figura 2.5 - Sateltrack, funzionalità di reporting disponibili sull'interfaccia Web
Gli obiettivi del progetto
14
La frequenza di campionamento del device è definita durante il processo di installazione, e modifica-
bile solo tramite un intervento dell’installatore. I dati campionati vengono memorizzati in un buffer ed
inviati con una frequenza che è minore di quella di campionamento (ogni invio di dati tramite la rete
di telefonia mobile è soggetto a tariffazione).
Inoltre il device si avvale delle seguenti tecnologie:
GSM/GPRS: il device contiene una comune SIM card di un operatore telefonico del tipo machine-to-
machine, quindi non per la telefonia tradizionale ma per la trasmissione dati.
GPS: il device dispone di un ricevitore GPS integrato, permettendo la localizzazione del veicolo sfrut-
tando il sistema satellitare GPS che garantisce un errore estremamente ridotto (minore di 15 m).
Il device di bordo è programmato per effettuare determinate operazioni all’accadimento di alcuni e-
venti, ad esempio l’invio dei dati motore ogni volta che si arresta il motore del veicolo oppure l’invio
della posizione GPS ogni una determinata distanza percorsa.
Uno schema semplificato del funzionamento di Sateltrack, è il seguente:
Figura 2.6 - Uno schema introduttivo sul funzionamento di Sateltrack
Il dispositivo invia al gateway le informazioni attraverso i canali GSM; normalmente si utilizza la tec-
nologia GPRS mentre gli altri canali (GSM data-call e SMS) sono usati solo in caso di indisponibilità
(mancata copertura locale) del GPRS. Infatti quest’ultimo sistema garantisce dei costi di trasmissione
decisamente bassi (la tariffazione è in base al traffico generato).
Il gateway decodifica, analizza e trasforma le informazioni in un formato idoneo (derivato dal lin-
guaggio XML) per inviarle alla ―coda dei messaggi‖ di Sateltrack, la message queue. Ogni comuni-
cazione verrà quindi associata al veicolo corretto e i dati relativi inseriti nel DB.
Gli utenti hanno a disposizione il sito Web www.sateltrack.com e, inserendo username e password
assegnati alla stipula del contratto, accedono alle pagine Web in cui è visualizzato lo stato della flot-
ta. Tra le tante informazioni riportate, è possibile ottenere, per ogni mezzo, informazioni dettagliate e
aggiornate sulla posizione, la distanza percorsa, tempo impiegato, consumi carburante…
Gli obiettivi del progetto
15
Il prodotto Sateltrack è estremamente flessibile: a seconda del cliente si offrono, pur rimanendo
l’applicativo di base invariato, funzionalità specifiche e interfacce diverse.
Sateltrack è considerato dall’azienda un prodotto maturo ma la sua evoluzione è seguita continua-
mente. Inoltre, i clienti di Sateltrack possono disporre di un helpdesk gestito dal personale di Cefin
Systems.
2.1.4 SaaS e Cefin Systems
Cefin Systems non gestisce internamente i server di Sateltrack (es. Application/DB server) affidando-
li in Hosting ad Above Net, un Internet Data Center professionale, presso il centro nell’area Docks di
Londra (UK).
AboveNet possiede 23 data center localizzati in Nord America, Europa e Asia. Ogni data center è
collegato direttamente all'architettura globale di AboveNet, composta da una rete dedicata in fibra
ottica che si estende per il globo terrestre.
Seppur l’impegno economico per l’hosting dei server presso un centro specializzato sia notevole, Ce-
fin Systems ha adottato questa soluzione per i vantaggi e le garanzie che vengono offerte. Le princi-
pali sono le seguenti:
1) L'IDC è dotato di sistemi di protezione da intrusioni ostili con sistemi di allarme che coprono tut-
to l'edificio (tetto compreso) e di un sistema automatico di segnalazione delle anomalie. L'ac-
cesso ai locali dell'IDC è permesso solo al personale autorizzato ed è regolato attraverso pass
elettronici che permettono accessi selettivi alle varie aree.
2) L'IDC è dotato di sistemi anti-allagamento e anti-incendio, sorveglianza armata per 24 ore al
giorno, 365 giorni l'anno, impianti di stabilizzazione e di continuità dell'energia elettrica. La rete
elettrica che fornisce una potenza di 1000 Kwh è protetta da un gruppo elettrogeno e da un si-
stema di batterie ridondato, per prevenire qualsiasi interruzione.
3) L'IDC eroga servizi di back-up con frequenza giornaliera (o maggiore), in grado di assicurare al
Cliente la copia dei propri archivi di dati con disponibilità degli stessi fino a 30 giorni antecedenti,
nonché servizi di ripristino (recovery) degli archivi.
Ritornando ai servizi offerti da Cefin Systems, quanto detto in generale per SaaS rimane valido ma
sono necessarie alcune precisazioni. Sateltrack prevede la fruibilità completa attraverso browser
standard e non necessita alcuna installazione di leggeri applicativi lato client (dove viene utilizzato
esclusivamente JavaScript). La compatibilità con tutti i browser non è assicurata al 100% ma, per i
più diffusi (Internet Explorer, Mozilla Firefox e Netscape), il funzionamento del servizio è garantito.
Viene inoltre offerta la possibilità di interfacciare applicativi specifici del cliente, ad esempio attraver-
so le API XML.
Gli obiettivi del progetto
16
In merito alla fatturazione del servizio, sono previsti canoni periodici indipendenti dall’utilizzo, tipica-
mente a cadenza mensile. Infine Cefin Systems tende ad implementare anche le funzionalità specifi-
che richieste dal cliente (purché ragionevoli) e, in base alla previsione di re-impiego per altri clienti,
gli verranno fatturate in maniera variabile le spese di implementazione.
2.2 I contenuti
Al momento della presentazione del progetto, Cefin Systems evidenziava l’intenzione di avviare una
nuova linea di business dedicata allo sviluppo di applicazioni Web, costituendo un team di sviluppo
interno in grado di realizzare con rapidità le soluzioni specifiche richieste dal mercato. Sino ad ora,
l’azienda non disponeva delle competenze per lo sviluppo di software e, come avveniva per Satel-
track, si limitava a fornire le specifiche per l’implementazione alla società inglese Krescendo Ltd, con
la quale aveva instaurato una partnership consolidata. Proprio l’azienda Krescendo aveva proposto
alcuni anni prima a Cefin Systems di collaborare per la commercializzazione della piattaforma eXtra-
Sheet. Questa, pur avendo alcune affinità con Sateltrack (era sviluppata con tecnologie simili ed ero-
gata anch’essa in modalità SaaS), risultava profondamente differente, poiché consisteva in un pro-
dotto general purpose, altamente flessibile e indicata per realizzare applicazioni Web con rapidità e
senza la necessità di sviluppare codice ad hoc.
A partire dall’anno 2006, Cefin Systems aveva intrapreso l’utilizzo di eXtraSheet internamente, ad
esempio per gestire in modo intelligente i dati relativi alle installazioni dei device per Sateltrack sui
veicoli e le loro certificazioni. In seguito, ne intraprese la commercializzazione verso alcune aziende
del gruppo, principalmente a quelle operanti in Romania, con risultati positivi, anche grazie al
background del personale dell’azienda, abile nell’analisi dei processi e nella mappatura funzionale
del software che li avrebbe supportati. I vantaggi di eXtraSheet sussistevano nella rapidità di svilup-
po (che non richiedeva competenze avanzate) e setup dell’applicazione, la quale risultava di facile
utilizzo e offriva unicità dell’informazione.
Come verrà approfondito nei paragrafi seguenti, Cefin Systems riscontrava però una sistematica ne-
cessità di personalizzazione che non era più possibile soddisfare mediante la GUI di configurazione
dell’applicazione, ma richiedeva talvolta lo sviluppo di limitate porzioni di codice, che l’azienda a-
vrebbe dovuto nuovamente demandare a Krescendo.
In questo scenario, il management aziendale era consapevole che, qualora fosse aumentato il nume-
ro di progetti di quel tipo basati su eXtraSheet, sarebbe risultato difficoltoso e poco conveniente con-
tinuare a gestire le modifiche e le personalizzazioni di ogni singola applicazione: mentre per Satel-
track questo processo era agevole (enhancements e bug fixing periodici riguardavano una sola ap-
plicazione, benché molto complessa e di grandi dimensioni), non sarebbe più stato possibile con tan-
te mini-applicazioni basate su eXtraSheet ma indipendenti tra loro che talvolta richiedevano sviluppi
consistenti. Si prospettavano quindi almeno due alternative differenti se si fosse deciso di proporre
sul mercato il servizio di progettazione, implementazione ed erogazione di applicazioni Web perso-
nalizzate. La prima (e la più lineare) era quella di concordare con Krescendo una soluzione per poter
Gli obiettivi del progetto
17
disporre della piattaforma eXtraSheet e delle competenze necessarie a svolgere direttamente gli svi-
luppi personalizzati. Una seconda ipotesi, apparentemente più conveniente in termini di costi, era in-
vece abbandonare la piattaforma eXtraSheet e avvalersi di eventuali soluzioni Open Source alterna-
tive e l’acquisizione di competenze in autonomia. Una ulteriore alternativa poteva essere quella di
concordare con la società Krescendo una strategia di collaborazione più profonda, ad esempio me-
diante la creazione di un team all’interno di Krescendo dedicato allo sviluppo per Cefin Systems, ma
questa soluzione risultava più dispendiosa sia in termini economici, sia per la complessità dei flussi
informativi che le due aziende avrebbero dovuto gestire.
L’obiettivo finale risultava quindi piuttosto chiaro: investire in un’area profittevole nel segmento già
identificato, creando un team di sviluppatori dedicato alla realizzazione di applicazioni Web ad hoc, in
grado di interagire in maniera produttiva con il personale che avrebbe svolto le fasi di analisi e pro-
gettazione dell’applicativo. Il software, erogato interamente in modalità SaaS, avrebbe seguito la
tendenza generale all’esternalizzazione dei servizi IT che caratterizzava sempre più il mercato del
software. Per raggiungerlo, si doveva tuttavia esplicitare i costi e condizioni necessarie per realizzare
ricavi.
2.3 L’ambito applicativo
L’azienda era intenzionata ad avviare la fornitura di applicazioni Web personalizzate e ―chiavi in ma-
no‖, integrando dunque il servizio di consulenza e progettazione con lo sviluppo vero e proprio. Si
vogliono impiegare le migliori tecnologie al momento esistenti e abbinarle alle proprietà di affidabilità,
efficienza e sicurezza proprie delle soluzioni SaaS.
Definire l’ambito applicativo e le funzionalità che si desiderano (bisogni) dalla nuova piattaforma sof-
tware non è completamente possibile. Infatti, Cefin Systems desidera realizzare applicazioni ad hoc
mediante una piattaforma che offra elevata flessibilità per soddisfare i bisogni specifici del cliente,
non definibili a priori. In prevalenza, si vuole proporre piccoli applicativi, snelli e Web-based da af-
fiancare ai sistemi informativi di aziende medio-grandi, per soddisfare esigenze non coperte dai si-
stemi ERP standard. In alternativa, l’azienda si proponeva altresì lo sviluppo completo di sistemi in-
formativi ad hoc per PMI caratterizzate da processi specifici. Almeno inizialmente, l’azienda voleva
evitare la gestione di grandi volumi di dati bensì distinguersi per professionalità, rapida prototipizza-
zione e time-to-market molto ridotto, grazie alla piattaforma che verrà scelta. L’azienda prevede an-
che la fornitura di supporto tecnico e training del personale per l’uso delle applicazioni erogate.
È inoltre richiesta elevata modularità: dopo lo sviluppo di una soluzione, deve essere possibile la
modifica, l’adattamento e la crescita dell’applicativo nel tempo. L’erogazione dovrà essere effettuata
in modalità SaaS, senza alcun investimento (in infrastruttura interna) da parte del cliente, appog-
giandosi ad una società di Hosting professionale, che potrà anche essere la stessa che già ospita
Sateltrack.
Gli obiettivi del progetto
18
2.4 La piattaforma
La piattaforma ricercata dall’azienda è un sistema general purpose che, come eXtraSheet, permetta
la realizzazione immediata di applicazioni Web e la sua fornitura al cliente in ambiente distribuito.
Cefin Systems utilizza già la piattaforma eXtraSheet sia per uso interno che per alcuni clienti a cui
rivende l’applicazione a nome di Krescendo Ltd.
Come già anticipato, per piattaforma non si intende l’insieme delle tecnologie o dei moduli software
su cui basare le applicazioni (es. J2EE oppure .NET) bensì una soluzione già sviluppata e di più alto
livello. Le funzionalità di base desiderate dall’azienda risultavano la capacità di creare in breve tem-
po, preferibilmente mediante GUI, un front-end Web per il database (possibilmente ad elevata flessi-
bilità), alcune funzionalità di reportistica e la gestione degli utenti con relative permission. Oltre que-
ste funzionalità, era ovviamente necessario poter modificare rapidamente l’aspetto e aggiungere
nuovi moduli sviluppati ad hoc, integrati con il database (accesso diretto mediante codice SQL oppu-
re, come avviene con eXtraSheet, attraverso un modello ad oggetti specifico).
Lo studio di fattibilità richiesto da Cefin Systems riguarda quindi la ricerca di una piattaforma disponi-
bile sul mercato oppure open source che fosse facilmente estensibile tramite moduli realizzati ad
hoc, per consentire la massima personalizzazione su aree che i prodotti commerciali non sono in
grado di ricoprire.
La piattaforma richiesta doveva essere priva di moduli verticali (o settoriali) ma in grado di coprire
parte delle comuni funzionalità di un’applicazione Web, prevalentemente di carattere gestionale, in
grado di supportare il processo dell’impresa committente. In chiave innovativa, tale paradigma a-
vrebbe fornito un contributo importante sotto molteplici aspetti. Anzitutto, la flessibilità e il riuso abili-
tano uno sviluppo efficiente in tempi brevi, l’unicità dell’informazione garantisce la consistenza dei
dati condivisi sui quali avrebbero operato più moduli.
In definitiva, con la nuova piattaforma l’azienda prevede di raggiungere prestazioni notevoli, riguar-
danti sia l’efficienza nell’utilizzo delle risorse (minori tempi di sviluppo rispetto all’approccio tradizio-
nale e prevalenza di attività di alto livello) sia l’efficacia, mediante l’offerta di soluzioni competitive
sotto l’aspetto qualitativo e temporale.
eXtraSheet
19
3 eXtraSheet
3.1 Panoramica di Krescendo Ltd
Krescendo è una società nata nel 2001 con sede a Londra ma a capitale italiano, e dispone di una
filiale esclusivamente commerciale negli Stati Uniti, a New York (Manhattan). I dipendenti sono tutti
laureati in materie informatiche o ingegneria e molti hanno un’esperienza decennale o quindicennale
nel settore IT.
Krescendo sviluppa sistemi di "supporto operativo" su piattaforma Web: si tratta esclusivamente di
progetti "end-to-end", dove l’azienda cura le fasi di analisi dei requisiti, analisi di fattibilità, progetta-
zione architetturale e di dettaglio, sviluppo, deployment e, nel tempo, manutenzione e supporto tec-
nico. Il lato più tecnico dell'hosting è demandato ad una società terza.
I settori principali in cui Krescendo opera sono due: quello dei trasporti e quello delle banche d'inve-
stimento. Nel settore trasporti gestisce tre progetti pluriennali in corso:
per una società finanziaria 100% IVECO-FIAT che si occupa di leasing di veicoli industriali in
Europa Centrale e dell'Est, Krescendo fornisce un sistema di "front-office" (Credit Scoring,
Credit Approval) e "back-office" (Contratti di finanziamento);
per il gruppo Cefin operante nel settore industriale-commerciale in ambito automotive e im-
mobiliare, basato in Europa Centrale, principalmente in Romania. Per Cefin la società Kre-
scendo ha sviluppato e sta attualmente potenziando una piattaforma operativa per la gestio-
ne di tutti i flussi commerciali (ordini, gestione stock, fatturazione). La piattaforma, che gesti-
sce migliaia di transazioni giornaliere, è live dal 2005 in Ungheria, ed è in corso
l’implementazione in Romania (volumi circa 10 volte superiori rispetto all'Ungheria).
per Cefin Systems, società che progetta, supporta e commercializza il sistema Sateltrack, un
prodotto per la gestione flotte di veicoli di cui Krescendo cura esclusivamente lo sviluppo. Ta-
le sistema richiede la gestione di basi dati ad altissimi volumi, dell'ordine di milioni di record a
settimana, e relativa reportistica analitica.
Nel settore investment banking l’approccio di Krescendo è basato sulla vendita del prodotto eXtra-
Sheet e di servizi di personalizzazione e consulenza ad esso connessi. Il prodotto ed i servizi corre-
lati non sono limitati al settore bancario e l’azienda sta concentrando le proprie energie per evolvere
eXtraSheet mantenendo un focus commerciale ed utilizzare al meglio la propria rete di contatti.
Con eXtraSheet, Krescendo detiene numerosi progetti in corso, i più importanti dei quali sono:
infrastruttura per il "Service Management" in JP Morgan Investment Bank: gestione di tutte le
chiamate relative a problemi applicativi, incident management, capacity management. È es-
eXtraSheet
20
senzialmente il "back-bone" per la struttura di supporto IT del gruppo, che ha circa 2000 u-
tenti in tutte le filiali del mondo;
sistema di middle office/trade processing e risk management per BSN Capital, una società di
trading in prodotti Money Market;
gestione planning / high-level project management per i dipartimenti Technology and Opera-
tions all'interno di JPM Finance e Private Bank (due organizzazioni diverse, di circa 400 e
2000 impiegati rispettivamente).
Il filo conduttore di tutte queste iniziative funzionalmente molto diverse è un approccio tecnologi-
co/architetturale omogeneo, che permette all’azienda di trasferire facilmente risorse da un progetto
all'altro. È essenziale sottolineare che l’elevato livello di produttività è direttamente correlato alla
competenza e all'impegno professionale di tutte le risorse Krescendo.
3.2 Introduzione ad eXtraSheet
Come già anticipato, risulta difficile definire puntualmente il prodotto eXtraSheet. È però possibile
prenderlo in considerazione sotto diversi punti di vista:
1. Lato utente, si presenta (nella sua versione base) come un’applicazione Web di data-
storage. L’utente, dopo aver effettuato il login su www.eXtraSheet.com, ha sostanzialmente
la possibilità di creare Sheet (equiparabili a tabelle di un DB), definirne la struttura e gestirli
con estrema facilità, predisponendo le maschere per effettuare il data-entry, le viste, le per-
mission per altri utenti, …
2. Sotto l’aspetto tecnologico, eXtraSheet è un’applicazione Web realizzata interamente con
tecnologia Java e secondo le più moderne best-practice di programmazione Web che preve-
dono anzitutto la separazione dello ―strato presentazione‖ (template based) da quello di bu-
siness logic (code based).
3. eXtraSheet è infine definibile come una piattaforma in grado di supportare applicazioni Web
avanzate. Infatti, oltre al codice ―core‖ di eXtraSheet, sono state sviluppate (e in parte sono
in corso di sviluppo) una serie di librerie che offrono classi Java di alto livello, per di facilitare
lo sviluppo di applicazioni Web integrate che estendono le funzionalità del prodotto base.
Lo slogan commerciale di eXtraSheet punta in particolare sulla fruibilità e sulla rapidità di sviluppo:
―With eXtraSheet you can convert your locally-managed process into an instant, globally accessible,
secure system.‖
3.2.1 La storia
eXtraSheet nasce nel 2001, sviluppato da una società con sede a Londra, come un’applicazione
Web di data management, erogata totalmente in modalità SaaS, che permette di creare, gestire e
eXtraSheet
21
condividere database su Internet. Nonostante fosse ancora in fase di sviluppo, Krescendo ne intui-
sce le potenzialità e decide di acquisire l’intero progetto. L’idea di business legata ad eXtraSheet ri-
sultava più precisamente un prodotto dotato delle seguenti caratteristiche:
Time-to-Market ridottissimo: possibilità di creare un applicativo aziendale dotato di funzionali-
tà standard in poche ore.
Sviluppo/design realizzabile interamente tramite l’interfaccia Web.
Facilità estrema di adattamento all’evoluzione del progetto specifico.
Hosting dei dati e supporto compresi nella fornitura del prodotto, secondo il modello SaaS.
Garanzia di SLA (Service Level Agreement).
Download ed esportazione dei dati tramite Webquery Excel.
Possibilità di reportistica personalizzata on-line.
eXtraSheet risulta inoltre più veloce e meno costoso da implementare rispetto ad una soluzione svi-
luppata internamente ad hoc per il cliente, in quanto:
è totalmente accessibile on-line e non è necessaria alcuna installazione di hardware o sof-
tware;
il re-work sulle soluzioni esistenti è minimo;
In conclusione, il punto di forza di eXtraSheet consisteva nella capacità di fornire applicazioni Web
per la condivisione e gestione dati senza sviluppare codice, offrendo al potenziale cliente un prodotto
sicuro e affidabile, immediatamente disponibile, garantendo unicità dell’informazione e accessibilità
globale.
3.2.2 Le funzionalità applicative standard
La versione standard di eXtraSheet prevede che per ogni cliente venga creato un nuovo progetto
(project) che corrisponde ad un ambiente Web dove sono disponibili tutte le funzionalità per la ge-
stione dei dati e degli utenti con cui il cliente desidera condividere (anche solo in parte) i dati del pro-
getto. Nei successivi sottoparagrafi si descrivono le funzionalità principali
3.2.2.1 Creazione di Sheet
Uno sheet su eXtraSheet corrisponde sostanzialmente ad una tabella di un database: è necessario
definire i campi desiderati, quindi procedere alla creazione dello Sheet e all’inserimento dei dati, me-
diante un’interfaccia user-friendly. L’utente ―amministratore‖ del progetto può creare nuovi sheet tra-
mite due procedure alternative:
Definizione manuale della struttura dei fogli (metodo più accurato)
eXtraSheet
22
Inizializzazione della struttura tramite un file di testo. eXtraSheet utilizza un meccanismo in-
telligente di riconoscimento della tipologia di dati. Oltre alla creazione del foglio è anche pos-
sibile caricare direttamente i dati presenti nel file.
La struttura degli sheet può contenere anche dati complessi ed è versatile a seconda dell’uso:
Sono supportati diversi tipologie di dati (formato testo, numerico, date, URL, allegati).
È possibile condurre interviste. La differenza dai normali fogli di dati è che non viene richie-
sta l’autenticazione; inoltre i risultati non sono forniti, di default, ai partecipanti all’intervista.
Sono possibili interviste anonime che proteggono la privacy l’intervistato impedendo la visibi-
lità dall’eventuale amministratore che ne voglia tenere traccia
È possibile raggruppare le sub-entries in macroaree all’interno dello Sheet. Ad esempio, una
macroarea ―progetto e dettagli‖ può contenere le sub-entries che descrivono i vari tipi di atti-
vità facenti parte del progetto e i costi associate ad esse.
Entrate matriciali. Permette il data entry all’interno di una griglia, in cui alcuni campi sono già
prefissati. Ad esempio se gli impiegati devono tenere traccia delle ore lavorate, i campi che
possono essere fissati sono i giorni della settimana.
3.2.2.2 Reportistica e Data entry
A livello di reportistica e data entry, eXtraSheet offre le seguenti funzionalità:
Maschera Web per il data entry
Interfaccia Web standard per dati.
Possibilità di creare ed abilitare viste sui dati (scegliendo i campi da visualizzare e/o definen-
do relazioni di vario genere), che possono essere utilizzate sia per semplice filtraggio dei dati
che per la condivisione con altri utenti.
Possibilità di creare template per report personalizzati (prevalentemente realizzati dal Forni-
tore, data la specificità del linguaggio)
Webquery link per il download dinamico su fogli di MS Excel, attraverso URL speciali conte-
nenti parametri particolari. Questa funzionalità rende particolarmente agevole la programma-
zione di tool Excel che prelevano da eXtraSheet i dati necessari e li elaborano lato client.
3.2.2.3 Gestione delle liste
Al fine di semplificare la gestione dei valori predefiniti (fenomeno molto comune nelle applicazioni di
data management), eXtraSheet offre la funzionalità delle liste (List):
Liste centralizzate che possono essere utilizzate da più fogli, per limitare i valori dei singoli
campi. Questo facilita l’inserimento dei dati nei fogli da parte dell’utente e ne garantisce la
correttezza.
eXtraSheet
23
Relazioni gerarchiche multilivello tra le liste. Ad esempio ―Dipartimento‖ e ―Progetto‖ possono
essere due liste collegate; è così possibile scegliere una volta selezionato il dipartimento la
lista dei progetti che fanno parte di questo.
3.2.2.4 Accessi degli utenti
eXtraSheet permette una gestione efficiente dell’accesso da parte degli altri utenti, tramite la suddivi-
sione in gruppi. Ogni gruppo di utenti è caratterizzato dagli indirizzi e-mail degli stessi e dalle loro
permission: possono avere accesso ad uno o più fogli, in modalità completa (unrestricted) oppure so-
lo ad alcune viste (limitazione sui campi e/o sui record) ed essere autorizzati a uno o più tipo di ope-
razione (visualizzazione, modifica, eliminazione) sui propri o su tutti i record della vista.
Se i nuovi utenti non dispongono ancora delle credenziali per l’accesso ad eXtraSheet, è possibile
inviare loro le e-mail di invito, contenenti un link speciale che guiderà l’utente alla creazione del suo
nuovo account.
Esiste inoltre la possibilità di condividere il foglio con un utente senza la creazione dell’account: tra-
mite un link, è possibile l’accesso senza login in modalità intervista (survey).
eXtraSheet è quindi la soluzione ideale quando emerge il bisogno di unire le informazioni provenienti
da diverse persone che risiedono in località differenti (interne o esterne all’azienda), consolidare i ri-
sultati e condividerli con facilità. Molto spesso, le aziende che necessitano di un prodotto come e-
XtraSheet utilizzano uno spreadsheet, file condivisi oppure e-mail, riscontrando i classici problemi
(assenza di unicità, difficoltà di sincronizzazione, …) della gestione di dati operativi o direzionali.
3.2.3 L’evoluzione di eXtraSheet
Dalla sua nascita, eXtraSheet ha riscontrato un successo limitato nei primi anni, mentre dal 2007 è
cresciuto notevolmente, fino a raggiungere una notevole affermazione nell’ultimo anno, tale da indur-
re l’azienda a spostare e assumere personale per lo sviluppo e l’innovazione di eXtraSheet.
A titolo di esempio, alcuni progetti di successo su eXtraSheet risultano:
Personnel evaluation solution, per supportare i review del team/clienti e per gestire i feed-
back provenienti dal personale.
Ticket-Management/Issue tracking, per aziende con costante necessità di interazione sia
all’interno dell’azienda che con fornitori e clienti (tipicamente per gestire il supporto tecnico e
l’assistenza di prodotti informatici/telematici).
I recenti successi hanno portato l’azienda a fornire eXtraSheet a numerosi clienti, in particolare nel
settore bancario. Spesso la società offriva in abbinamento il proprio servizio di analisi e consulenza.
Sempre più emergevano due fenomeni complementari:
eXtraSheet
24
1) La transizione di eXtraSheet da semplice applicazione di data management ad un potente
strumento di problem solving, che permetteva all’azienda di vendere solutions e consulenza.
eXtraSheet diventa l’infrastruttura per risolvere i problemi di consulenza, sfruttandone la sua
flessibiltà.
2) La crescente necessità di sviluppare funzionalità ad hoc: l’efficacia di eXtraSheet nel fornire
uno strumento immediato al cliente era provata, ma solitamente necessitava di integrazioni a
posteriori. Tipicamente, quando l’applicazione era ormai a regime, il cliente segnalava la ne-
cessità di ridotte personalizzazioni, solitamente reportistica, per estendere le funzionalità
standard (ad esempio, la generazione di report di sintesi in PDF oppure l’invio di notifiche e-
mail).
L’azienda, seguendo queste linee guida molto promettenti, decise di investire nello sviluppo di un
modello ad oggetti in grado di facilitare la personalizzazione e/o l’evoluzione (mediante sviluppo di
codice) di un progetto su eXtraSheet. La nuova API per eXtraSheet offriva dunque una notevole atti-
tudine a creare applicazioni Web personalizzate da integrarsi con le funzionalità di base di eXtra-
Sheet e tali da garantire:
- Facilità di accesso/modifica ai dati conservati negli sheet, senza l’accesso diretto al
database.
- Accesso a gruppi, utenti e permission del progetto per verificare gli utenti autorizzati ad ac-
cedere all’applicazione.
3.3 Sviluppi e tendenze
Come anticipato, si prevede che il futuro sviluppo commerciale e tecnologico di eXtraSheet prosegua
per il percorso intrapreso: una piattaforma per lo sviluppo di applicazioni Web in tempi ridotti, caratte-
rizzate da elevata flessibilità, affidabilità e prestazioni, tipiche del modello SaaS.
Nell’anno 2009, la società Krescendo ha ottenuto risultati economici sorprendenti dalla vendita del
prodotto eXtraSheet, che viene sempre più erogato come servizio completo: dall’analisi del problema
del committente, all’eventuale modifica del processo e allo sviluppo e personalizzazione della solu-
zione su eXtraSheet. Il mercato sembra apprezzare tale approccio, dato che negli ultimi due anni so-
no una nicchia molto ridotta di clienti eXtraSheet continuano a richiedere esclusivamente il prodotto
―grezzo‖ e provvedono autonomamente alla configurazione e gestione.
Il management Krescendo prevede di proseguire all’estensione delle funzionalità di eXtraSheet, al
perfezionamento e al costante aggiornamento con le nuove tecnologie Web. L’obiettivo è duplice: ot-
tenere nuovi sviluppi o manutenzioni dai clienti attuali e raggiungere nuovi clienti in tutto il mondo,
puntando in particolare su professionalità e tempi di realizzazione. L’approccio di eXtraSheet non
sembra essere molto diffuso nel mercato del software online, dove prevale il riuso e la standardizza-
zione solo a livello di codice (tipicamente con librerie standard) e apparentemente meno a livello di
framework applicativi, se si escludono i content management per i siti Web.
eXtraSheet
25
3.4 Architettura Software
L’architettura software di eXtraSheet risulta piuttosto complessa, ma è interamente basata su tecno-
logie e prodotti ―open-standard‖, per garantire l’indipendenza da produttori hardware e software e di-
sporre di una soluzione cross-platform. È basata sulla piattaforma Java, Java 2 Enterprise Edition
(J2EE), che definisce anche la tipologia e le modalità di interazione con gli altri moduli software. Tra
di essi, il noto database relazionale (RDBMS) open source MySQL, l’application server open source
Caucho Resin ed una serie di librerie Java specifiche per applicazioni Web, alcune open source ed
altre di proprietà di un’azienda partner.
Figura 3.1 - Schema semplificato dell'architettura di eXtraSheet
Di seguito si propone una breve presentazione dei componenti appartenenti all’infrastruttura software
di eXtraSheet.
3.4.1 La piattaforma J2EE
eXtraSheet è interamente basato sull’architettura Java 2 Enterprise Edition, uno standard (non un
prodotto) affermato per lo sviluppo di applicazioni distribuite, utilizzando un vasto range di nuove tec-
nologie ed un modello di programmazione component-based che accresce la produttività delle appli-
cazioni in diversi modi:
Assicura flessibilità alle funzionalità desiderate, consentendo diverse possibilità di configura-
zione dell’architettura dell’applicazione. Inoltre risultano agevoli operazioni di manutenzione
poiché i singoli componenti possono essere aggiornati o sostituiti indipendentemente.
eXtraSheet
26
Garantisce ai componenti la disponibilità di servizi nell’ambiente di runtime, con la possibilità
di essere interconnnessi con altri, fornendo opportune interfacce. Ad esempio, attraverso i
deployment descriptors (file XML di configurazione) è possibile modificare i parametri
dell’ambiente di runtime senza modificare il codice dei componenti.
Permette maggiore efficienza organizzativa, poiché ciascun set di componenti può essere
associato ad un determinato team, consentendo lo sviluppo dell’applicazione in parallelo e la
focalizzazione di ogni team su competenze specifiche.
J2EE utilizza una architettura distribuita multilivello (multitiered) per le applicazioni Enterprise. La lo-
gica applicativa viene infatti divisa in più componenti, in base alla loro funzione, ognuno di essi può
essere installata su macchine diverse. L’architettura generale risulta composta da:
1. Client-tier components, eseguiti sul client.
2. Web-tier components, eseguiti sul server J2EE.
3. Business-tier components, eseguiti sul server J2EE.
4. Enterprise information system (EIS)-tier software, eseguiti sul server EIS.
Sebbene un’applicazione J2EE può consistere in 4 livelli, normalmente sono considerate a 3 livelli,
poiché sono tipicamente distribuite su tre diverse macchine: client, J2EE server e database/sistemi
legacy sul server di back-end.
La figura seguente mostra due applicazioni multilivello: la prima prevede un applicativo lato client
mentre la seconda fornisce direttamente al client i risultati in linguaggio (X)HTML, approccio oggi
predominante.
Figura 3.2 - Applicazioni multilivello in J2EE
eXtraSheet
27
Poiché J2EE è uno standard, si ha completa libertà nella scelta dell’hardware e dei tool da impiegare
per uno specifico progetto.
3.4.1.1 Client tier
Il client-tier costituisce il front-end più o meno complesso che risiede e viene eseguito sul client per
usufruire dell’applicazione. Esso inoltra le richieste al server in base alle azioni dell’utente e presenta
a quest’ultimo i risultati. J2EE prevede diverse tipologie di client:
Web Clients, risulta la soluzione più frequentemente adottata, poiché permette di realizzare i
cosiddetti thin client, che non interrogano database o eseguono algoritmi di business logic. I
Web Client sono semplicemente dei browser Web che visualizzano le pagine ricevute dal
server che sono generate dal Web tier.
Applets, componenti aggiuntivi che possono essere inclusi nelle pagine inviate al browser
utente. Consistono in piccole applicazioni che devono essere eseguite nella Java Virtual Ma-
chine installata nel browser.
Application Clients, sono applicazioni che devono essere eseguite sulle macchine client. Of-
frono tipicamente interfacce utente più avanzate (GUI), create ad esempio tramite la libreria
Swing oppure AWT e maggiori elaborazioni eseguite lato client (thick client). A differenza dei
due casi precedenti, l’applicazione accede direttamente al Business tier del sistema.
Da sottolineare la presenza di una serie di trade-off nella scelta della soluzione da adottare: più si la-
sciano funzionalità lato server, maggiore sarà la facilità di distribuzione, deploy e gestione
dell’applicazione ma si rendono necessari investimenti HW e infrastrutturali da parte del fornitore ed
il cliente avrà una percezione ridotta del sistema.
Nella figura seguente sono riassunti gli elementi che possono appartenere al Client tier.
Figura 3.3 - Client tier (componenti lato client) in J2EE
Nel caso di eXtraSheet, e comunque in tutte le soluzioni sviluppate da Krescendo, viene adottata
sempre la soluzione dei Web client, per garantire la fruibilità unicamente mediante browser Web.
eXtraSheet
28
3.4.1.2 Web tier
I componenti del Web tier consistono in una serie di strumenti in grado di produrre contenuti dinami-
ci, risultanti dalle elaborazioni a livello business logic, in risposta alle richieste dei client.
Le tecnologie offerte da J2EE risultano essere le Servlet e le Java Server Pages (JSP). Le Servlet
sono classi Java che elaborano richieste e producono risposte mentre le JSP sono file di testo che
funzionano analogamente alle servlet ma sono orientate alla presentazione, cioè a produrre l’output
per l’utente (tipicamente pagine XHTML create dinamicamente).
Come mostrato nella figura seguente, lo strato Web può includere componenti JavaBean per gestire
l’input dell’utente e inviarlo al business tier per l’elaborazione. I Java Bean sono componenti software
contenenti una classe Java, che possono venire inclusi in una pagina JSP, permettendo quindi un
ottimo incapsulamento del codice, peraltro riutilizzabile. Al programmatore quindi sarà pressoché in-
visibile la sezione di codice puro, sostituito da richiami ai metodi delle classi incluse.
Figura 3.4 - Web tier in J2EE
Nel caso di eXtraSheet, vengono utilizzate librerie specifiche contenenti Servlet facilmente riutilizza-
bili ed estensibili. Inoltre, in sostituzione delle JSP, eXtraSheet utilizza il motore di template FreeMar-
ker (meglio analizzato in seguito) che offre una tecnologia simile a JSP ma è completamente open
source e maggiormente flessibile.
3.4.1.3 Business tier
Il livello Business contiene la logica applicativa ―core‖, che elabora e risolve le specifiche problemati-
che di un dominio di business, ad esempio operazioni di banking, analisi delle vendite, …
La figura seguente mostra come gli Enterprise Bean, in esecuzione sul Business tier, gestiscono le
elaborazioni richieste, scambiando dati con il livello EIS restituendo i risultati all’applicazione client.
Più in dettaglio, esistono tre tipologie di Enterprise Bean:
1) Session bean, rappresenta una singola comunicazione con il client e viene eliminato al ter-
mine dell’interazione, rilasciando le risorse e i dati ad essa associati.
eXtraSheet
29
2) Entity bean, rappresenta dati persistenti, mantenendo lo stato su un database anche al di
fuori del ciclo di vita della applicazione e dei processi del J2EE server. Rispetto al session
bean consente accessi concorrenti da parte di più client.
3) Message-driven bean, combina caratteristiche di un session bean e di un listener Java Mes-
sage Service (JMS), permettendo ad un componente business la ricezione di messaggi a-
sincroni.
Figura 3.5 - Business tier in J2EE
3.4.1.4 EIS tier
È il livello più basso dell'architettura, che gestisce i dati memorizzati in modo permanente tramite va-
rie tecnologie, ma tipicamente con strumenti RDBMS. Questi ultimi possono supportare accessi con-
trollati attraverso le transazioni, permettendo accessi concorrenti da parte di applicazioni differenti.
Poiché un’applicazione distribuita prevede l’utilizzo di ulteriori tipi di sorgenti, inclusi sistemi legacy
che devono essere opportunamente adattati alle interfacce previste da J2EE.
Nel caso di eXtraSheet, non ovviamente presenti sistemi legacy mentre viene impiegato il database
relazionale open source MySQL.
3.4.1.5 J2EE Containers
Lo sviluppo di applicazioni multi-livello e thin-client è particolarmente complesso poiché coinvolge la
gestione di stati e transazioni, la condivisione di risorse e altre funzionalità di basso livello molto arti-
colate.
La piattaforma J2EE offre funzionalità per semplificare notevolmente tali aspetti, poiché la business
logic viene organizzata in componenti riutilizzabili ma soprattutto vengono offerti servizi sotto forma
di container per ogni tipologia di componente.
I container sono interfacce tra un componente e le funzionalità offerte dalla piattaforma di livello infe-
riore. Prima che un componente Web oppure un Enterprise Bean possa venire eseguito, deve esse-
re ―assemblato‖ in un modulo J2EE ed eseguito il ―deploy‖: il processo di assemblaggio riguarda la
specifica delle impostazioni del container per ogni componente dell'applicazione J2EE e per l'appli-
eXtraSheet
30
cazione stessa. Le impostazioni del container permettono di configurare le operazioni fornite dal
server J2EE, quali sicurezza, gestione delle transazioni e connettività.
Poiché l'architettura J2EE fornisce servizi configurabili, i componenti dell'applicazione J2EE possono
assumere comportamenti differenti in base a dove viene eseguito il deploy. Il container gestisce an-
che servizi non configurabili, quali Enterprise bean e servlet, connessioni a database o accesso alle
numerose API fornite da J2EE.
Le tipologie di container fornite da J2EE, sono le seguenti:
J2EE server: è la parte centrale di elaborazione di un sistema J2EE. Comprende I seguenti
container:
o Enterprise JavaBeans (EJB) container: gestisce l’esecuzione degli Enterprise bean
dell’applicazione J2EE.
o Web container: gestisce l’esecuzione delle Servlet e delle pagine JSP.
Application client container: gestisce l’esecuzione dell’applicazione lato client.
Applet container: gestisce l’esecuzione delle applet Java e consiste in un Web browser con-
tenente plugin Java che risiedono sul client.
Figura 3.6 - Ruolo dei J2EE container
3.4.2 MySQL RDBMS
eXtraSheet impiega il motore di database relazionale (RDBMS) MySQL, un prodotto open source
ormai consolidato, soprattutto nello sviluppo di applicazioni Web dinamiche, anche a livello Enterpri-
se. MySQL è uno dei DBMS che richiede meno risorse hardware, è ampiamente supportato dalla
Community e dispone di documentazione dettagliata. È considerato il leader tra i DBMS open sour-
ce.
eXtraSheet
31
MySQL è composto da un client con interfaccia a caratteri e da un server, entrambi disponibili per
svariati ambienti software, tra cui MS Windows e Unix. MySQL supporta pienamente il linguaggio
SQL (Structured Query Language) e dispone di numerose interfacce, tra cui ODBC e JDBC, per es-
sere utilizzato nella maggior parte dei linguaggi di programmazione.
Esistono numerosi strumenti di amministrazione e di sviluppo per database MySQL, anch’essi distri-
buiti con licenza open source. Altre caratteristiche principali di MySQL sono il supporto alle proprietà
ACID (Atomicity, Consistency, Isolation, Durability), all’integrità referenziale (per la gestione delle re-
lazioni tra tabelle differenti), alle transazioni (per il mantenimento dei dati sempre in condizioni consi-
stenti) e la crittografia delle comunicazioni in rete tra i client ed il server.
MySQL, pur non disponendo di funzionalità di warehousing o altre caratteristiche offerte da noti pro-
dotti commerciali (quali Oracle e MS SQL Server), garantisce buona scalabilità e prestazioni notevoli,
in particolare quando non è richiesto il supporto alle transazioni o all’integrità referenziale, utilizzando
la tecnologia multi-thread.
3.4.3 Componenti e librerie Java
3.4.3.1 Java Development Kit (JDK)
Per il funzionamento di un sistema basato su J2EE è anzitutto necessario installare sul server il pac-
chetto JDK (Java Development Kit), distribuito liberamente da Sun Microsystems, che comprende il
Java Runtime Environment ed una serie di strumenti per lo sviluppo.
La Java Runtime Environment è la parte centrale della piattaforma Java che permette l’esecuzione
del codice binario Java, poiché fornisce la Java Virtual Machine (JVM) e le librerie ―core‖ (Java API)
necessarie all’ambiente di produzione. Poiché la JVM è disponibile per numerose configurazioni
hardware e software (ad esempio, su PC che eseguono MS Windows oppure su Server Unix), la
piattaforma Java risulta estremamente flessibile e portabile (secondo il motto ―Write Once, Run An-
ywhere‖).
Inoltre, JDK fornisce una serie di strumenti utilizzati dagli sviluppatori, tra i quali il compilatore Java, il
loader, il generatore di file JAR e il debugger, che tuttavia non necessitano di essere installati in am-
bienti di produzione.
3.4.3.2 uView
Per le funzionalità di basso livello, eXtraSheet utilizza uView, un framework Java proprietario che of-
fre una serie di operazioni standard molto ricorrenti. uView è più propriamente una metodologia, un
framework e un toolkit per lo sviluppo di applicazioni su piattaforma J2EE. Sebbene alcune funziona-
lità siano utili a qualsiasi tipologia di applicazione, l'utilizzo principale è rivolto allo sviluppo di applica-
zioni Web server-side, fruibili dai client tramite normali browser Web.
Un'applicazione basata su uView è un programma Java a tutti gli effetti, che può a sua volta utilizza-
re altri tool e librerie. L'obiettivo principale di uView è quello di permettere allo sviluppatore di realiz-
eXtraSheet
32
zare un'applicazione in Java robusta, sicura, performante e scalabile nel minimo tempo possibile. La
struttura imposta da uView evita allo sviluppatore inutili e dispendiose scelte relative all'architettura
dell'applicazione, permettendogli di concentrarsi direttamente sulle funzionalità. Rispetto ad altri fra-
mework, non limita lo sviluppatore in un ristretto set di funzionalità e non preclude l'utilizzo di altri to-
ol.
Rimanendo nelle funzionalità di alto livello, il paradigma uView permette:
Sviluppo e deploy su medesima piattaforma
Utilizzo di strumenti di sviluppo esistenti e preferiti
Ciclo di sviluppo e testing estremamente rapido
Ambiente server leggero e veloce, che può essere installato ed utilizzato interamente sulla
postazione hardware dello sviluppatore
Facilità di verificare il ―work in progress‖ da parte di altri sviluppatori e manager
Elevato grado di separazione tra GUI e business logic
Possibilità di modificare l’aspetto grafico senza dover riavviare l’applicazione, quindi senza
effettuare una release completa.
Tra le innumerevoli funzionalità di carattere operativo disponibili in uView vi sono il supporto alla
connettività con i database, il logging delle attività e la gestione dei login, delle autenticazioni e delle
sessioni. Il framework permette la separazione tra presentation layer, basato su template, e business
logic, realizzata in codice Java.
Analizzando più in dettaglio l’architettura di uView, i componenti di un’applicazione realizzata con u-
View sono i seguenti:
1. Web browser, il client dell’applicazione. Con uView le applicazioni possono generare qua-
lunque tipologia di contenuti ma tipicamente si tratta di (X)HTML dinamico. Altre tipologie uti-
lizzabili sono XML, WML, testo o Java applet.
2. Server sul quale uView funzionerà, sia questo un Web server con l’estensione che imple-
menta le Java Servlet API (specifiche di Sun che consente al Web server di ottenere conte-
nuti da un programma Java) oppure un Web server dotato di supporto nativo per le Servlet.
La configurazione più comune è quella di utilizzare Apache Server (come Web Server) e
Caucho Resin (come Servlet Engine).
3. Java Virtual Machine (JVM), indispensabile per elaborare le servlet ed il codice di uView.
Le evoluzioni della JVM sono notevoli e sono spesso rilasciate nuove versioni da Sun. uView
è compatibile con qualunque JVM da quando le Servlet API furono rilasciate. Le attuali JVM,
dotate di ottimizzazioni sofisticate e compilazione nativa del codice offrono performance ec-
cellenti se comparate con le prime implementazioni.
eXtraSheet
33
Figura 3.7 - Le caratteristiche del framework uView
4. RDBMS, un database relazionale che si interfacci con uView. Sono stati testati Oracle e
MySQL ma è comunque garantita la compatibilità per qualunque database dotato dei driver
JDBC. In realtà la presenza di un database non è indispensabile per uView ma le funzionali-
tà di un’applicazione senza un database sono estremamente limitate.
5. Librerie software, utilizzate da uView per il suo funzionamento. Tra queste, la maggior parte
sono oggi integrate nella distribuzione della JDK. In ambiente di produzione, uView necessi-
ta dell’accesso a tali librerie, tipicamente rilasciate in formato JAR.
6. Librerie uView, tipicamente rilasciate in produzione con file .class individuali che ne facilita-
no la manutenzione rispetto alle librerie JAR.
7. Software dell’applicazione, come per le librerie Java, il codice dell’applicazione è compilato
e convertito in file binari che vengono rilasciati sul server insieme ad alcuni file di configura-
zione, tra cui quello relativo all’applicazione e alla connessione con il database.
8. Risorse dell’applicazione, tipicamente template (X)HTML, file grafici (GIF, JPEG) e altri file
statici.
eXtraSheet
34
Figura 3.8 - L'architettura di uView
I componenti sopra elencati possono essere configurati per funzionare in una ampia varietà di archi-
tetture distribuite. Alcune configurazioni possibili sono:
- Un server sul quale risiedono tutti i componenti
- Un Web server dotato di API Servlet, applicazione uView e JVM ed un secondo server dedi-
cato al RDBMS
- Un Web server, uno o più Servlet/uView/JVM server ed un database server
- Web server multipli, Servlet/uView/JVM multipli, Database server multipli
Ogni configurazione presenta pregi e difetti ma solitamente si sceglie l’architettura più semplice che
possa offrire le prestazioni desiderate.
Approfondire ulteriormente l’utilizzo di uView esula dalle finalità dell’elaborato, ma si sottolinea che la
società Krescendo dispone della documentazione dettagliata, alla quale il candidato ha fatto riferi-
mento nel corso delle attività di sviluppo. A tal proposito, l’utilizzo del framework uView è risultata
piuttosto semplice, anche grazie alle demo fornite dall’azienda, e certamente al livello di uno svilup-
patore Junior Java.
eXtraSheet
35
3.4.3.3 FreeMarker
FreeMarker è un motore di template open source, perfettamente integrato con Java. È una alternati-
va all’utilizzo delle pagine JSP per la gestione del lato presentazione poiché presenta numerosi van-
taggi. Le pagine JSP sono basate fortemente sulla sintassi Java mentre può essere necessaria una
maggiore indipendenza, specialmente se lo sviluppatore Java non coincide con quello dello strato
presentazione. Inoltre, JSP è parzialmente in contrasto con il paradigma MVC (Model-View-
Controller) che prevede la separazione della rappresentazione dei dati e metodi sui quali opera l'ap-
plicazione (Model) dalle modalità di presentazione dei risultati (View) e dai processi di interazione
con l'utente o altri elementi che possono modificare gli altri due componenti (Controller). JSP preve-
de infatti di inserire codice Java (del componente Controller) all'interno del codice (X)HTML (compo-
nente Controller).
FreeMarker si pone come una valida soluzione poiché è una tecnologia Open Source, compatibile
con Java, aderente agli standard MVC e indipendente dal tipo di file da elaborare. FreeMarker consi-
ste in una serie di librerie che, analogamente a JSP, elaborano template, sostituendo i tag speciali
nel file sorgente con dati generati dinamicamente. Rispetto a JSP, è indipendente dall'architettura
Servlet o da HTTP e sono in grado di processare qualunque tipo di file, quali X(HTML), XML, CSV,
file di testo, ...
Rispetto a JSP, FreeMarker risulta più performante poiché non necessita delle numerose librerie che
JSP richiede ogni volta a runtime.
3.4.3.4 Altre librerie
Le applicazioni create da Krescendo, inclusa eXtraSheet, utilizzano abitualmente una serie di librerie
Java (non incluse nella piattaforma Java rilasciata da Sun) prevalentemente open source, per im-
plementare funzionalità specifiche. Tra queste rientrano:
Spring Framework, nota libreria open source che fornisce una vastissima gamma di funzio-
nalità per lo sviluppo di applicazioni Web basate su J2EE.
iText: è una libreria open source per la creazione e la modifica di documenti PDF, RTF,
HTML e XML. Essendo pienamente integrata con Java, permette ad esempio di memorizza-
re il flusso di dati su un file oppure inviarli attraverso una servlet al browser Web dell’utente.
Le potenzialità della libreria sono concentrate sulla gestione dei file PDF, che permettono
anche la crittografia e la firma digitale del documento. iText è inoltre incluso in prodotti più
completi tra cui JasperReports, anch’esso utilizzato negli sviluppi di Krescendo per eXtra-
Sheet ed altri prodotti.
JFreeChart: è una libreria Java, anch’essa open source, che permette di creare agevolmente
grafici complessi a partire da serie di dati provenienti da qualunque sorgente.
L’immediatezza dell’utilizzo e la relativa flessibilità semplificano l’arricchimento di ogni gene-
re di reportistica con rappresentazioni grafiche professionali.
eXtraSheet
36
3.4.4 Resin Application Server
La società Krescendo impiega l’application server Caucho Resin Professional per l’erogazione delle
proprie applicazioni J2EE, incluso eXtraSheet.
Resin è un application server che supporta tutte le tecnologie J2EE, integrando caratteristiche di
Web server e offrendo funzionalità avanzate per sistemi Enterprise. Rispetto ai prodotti più blasonati
come Weblogic e Websphere (i principali) oppure Jboss (open source), Resin è un application server
Open source leggero e adatto per ambienti di sviluppo e, al contempo, un prodotto completo e affi-
dabile per gli ambienti di produzione (soprattutto nella versione commerciale).
Resin supporta tutte le tecnologie della piattaforma J2EE quali Servlet e JSP, EJB, JDBC, JMS (Java
Message Service), e Web Service. Inoltre gestisce Virtual host , pagine PHP, CGI in genere, e sup-
porta OpenSSL.
Per i sistemi Enterprise, che richiedono caratteristiche di robustezza, affidabilità e performance ele-
vate, la versione Resin Professional fornisce sistemi di clustering e load balancing, oltre ad un insie-
me di librerie JNI (Java Native Interface) per ottimizzare la gestione delle socket e l’accesso al file
system. Resin supporta inoltre una serie di altre feature: JSP EL (Expression Language) un linguag-
gio con sintassi semplificata per l'accesso ad oggetti e per l'utilizzo delle loro proprietà a run-time
dall'interno di pagine JSP; JCA (Java Connection Architecture); Amber, un’implementazione di Resin
della persistenza degli EJB 3.0; i protocolli Hessian e Burlap, per la connessione con i Web-services;
XTP (XML Template Pages) che permette la creazione di pagine Web tramite XML.
I concetti principali relativi alla gestione di un server Resin sono i seguenti:
Esiste un solo file xml di configurazione per il server, il resin.conf
I file di configurazione delle Web application sono il WEB-INF/Web.xml e WEB-INF/resin-
Web.xml; il primo contiene le configurazioni standard della Web application, il secondo le
configurazioni specifiche di Resin.
Ogni cambiamento nel file di configurazione (del server o della Web application) viene rileva-
to automaticamente e causa il restart del server.
Il deployment di un nuova Web application viene effettuato automaticamente aggiungendo
un file .war nella directory Webapps
Un nuovo virtual host viene aggiunto automaticamente creando una sottodirectory nella
directory host
I path vengono interpretati come assoluti se iniziano con ―/‖ altrimenti relativi alla RE-
SIN_HOME
Resin permette di aggiungere una nuova Web application o un virtual host modificando appropriata-
mente il file resin.conf. Le direttive specifiche di Resin contenute nel resin-Web.xml possono essere
inserite anche nel Web.xml, anche se questo rende questo file non standard per eventuali deploy su
altri application server.
eXtraSheet
37
Resin può essere usato come server stand-alone con funzioni di Web server e application server o in
alternativa si può usare un Web server (ad esempio Apache o IIS) come front-end per servire conte-
nuti statici e Resin come application server di back end per l’elaborazione di contenuti dinamici.
L’integrazione con Apache e IIS viene realizzata tramite un modulo plugin, che ha il compito di sele-
zionare le URL da passare all’application server, inoltrare le richieste e riprendere le risposte dal
server Resin.
3.4.5 Client side Javascript
Per usufruire di eXtraSheet, come peraltro tutte le soluzioni Krescendo, il client deve essere esclusi-
vamente dotato di un browser Web standard e nessuna installazione aggiuntiva, trovando piena con-
vergenza con la filosofia SaaS.
Il browser Web dovrà farsi carico di interpretare il codice HTML ed eseguire l’eventuale codice Java-
Script associato. Questo si rende necessario nel Web 2.0, in cui la pagina è ―reattiva‖ e implica che
siano inserite logiche (es. pulsanti associati a funzioni) ed eventuali interazioni tra browser e server.
Più precisamente avviene l’inserimento nelle pagine Web di istruzioni eseguite dal browser in lin-
guaggio Javascript da eseguirsi sul client. Poiché tale linguaggio risulta altamente diffuso e standar-
dizzato, è compatibile con tutte le piattaforme SW ed i comuni browser Web. Non sono invece previ-
sti altri componenti lato client, quali Java applet o Adobe Flash, poco diffusi e più ―pesanti‖ in termini
di dimensioni ed elaborazioni richieste.
JavaScript permette inoltre di utilizzare la tecnologia AJAX, cioè la possibilità di inoltrare delle richie-
ste asincrone al server e migliorare così il grado di interattività dell’applicazione, modificando ed ag-
giornando alcuni componenti senza caricare nuovamente l’intera pagina.
Come per il linguaggio HTML, il codice Javascript viene ignorato dall’Application Server, che conti-
nua ad interpretare solo il codice Java e, nel caso specifico, le direttive FreeMarker inserite nel tem-
plate. Il browser del client riceve quindi la pagina con codice HTML e codice Javascript, che verranno
inoltrati ai rispettivi interpreti. La pagina HTML viene immediatamente tradotta in un oggetto DOM
(Document Object Model), che facilita notevolmente l’accesso e la modifica dei componenti della pa-
gina tramite Javascript, senza gestire direttamente la complessità dell’HTML.
eXtraSheet utilizza JavaScript per le funzionalità sopra descritte avvalendosi di alcune librerie (o
framework), tra le quali:
- Prototype: è una libreria open source che offre il completo supporto ad AJAX ed alla pro-
grammazione object-oriented in JavaScript. In particolare, riguardo ad AJAX, fornisce fun-
zionalità di alto livello per gestire le interazioni tra client browser e server, fornendo un utile
livello di astrazione dai dettagli della comunicazione AJAX.
- script.aculo.us: anch’essa open source, è una libreria che permette di implementare con e-
strema facilità effetti grafici e funzionalità interattive notevoli. Alcuni esempi sono gli effetti di
eXtraSheet
38
dissolvenza, il ―drag-and-drop‖ di elementi e l’auto completamento dei form. Tali funzionalità
risulterebbero invece complesse da realizzarsi ad hoc e pressoché impossibili per program-
matori non esperti.
Sono inoltre utilizzate librerie minori (ad esempio per il calendario Web) ed altre sviluppate interna-
mente, contenenti le funzionalità più ricorrenti negli sviluppi effettuati da Krescendo.
3.5 Configurazione Hardware
eXtraSheet è un prodotto che garantisce estrema affidabilità e sicurezza al cliente poiché, oltre ad
avere un’architettura software stabile e performante, dispone di un’infrastruttura hardware potente e
ridondata.
In figura sono mostrati i principali componenti della configurazione hardware di eXtraSheet. Si ha un
server di produzione ospitato presso un centro di hosting professionale che è dotato delle seguenti
caratteristiche tecniche:
8 Core Intel Xeon 2,5 Ghz
Dischi RAID da 754GB
Memoria RAM da 16GB
Piattaforma SW: Sistema Operativo CentOS (Kernel Linux) release 5 (Final), OpenSSL
0.98b, Java 1.5.0_14, ProFTPd 1.03.01, OpenSSH_4.3p2, MySQL 5.00.45, Resin Applica-
tion Server 3.1.7.
Al server di produzione ne sono affiancati altri, talvolta condivisi con gli altri prodotti della società
Krescendo, dedicati alle operazioni di backup ed alla fornitura di servizi aggiuntivi. Tra questi vi è il
server di hot backup che contiene il mirroring del file system e dei database, con aggiornamento ora-
rio e pronto ad entrare in funzione qualora il server principale risultasse guasto. Un secondo server
(woodford) effettua la copia notturna del file system e la conserva per tempi prolungati. Il server di
disaster recovery, che risiede in una sede fisica differente dal centro di hosting principale, garantisce
una ulteriore ridondanza per offrire un elevato grado di sicurezza su dati ed applicazioni. Il server
principale interagisce inoltre con il Mail server, per inviare ad esempio le mail di notifica agli utenti di
eXtraSheet.
L’ambiente di produzione e quello di sviluppo, ossia l’IDC e gli uffici di Krescendo, interagiscono fre-
quentemente, soprattutto per i rilasci di nuovo software da parte degli sviluppatori. Questi, come sarà
approfondito in seguito, possono testare le applicazioni nel Test Server, che contiene una snapshot
sempre recente del server di produzione. In caso di risultati positivi, effettuano l’upload sul server
CVS (augustus) dal quale verrà infine effettuato il deploy in produzione.
eXtraSheet
39
Figura 3.9 - Schema dell'infrastruttura hardware di eXtraSheet
3.6 Processi di sviluppo e hosting
Come intuibile dal precedente paragrafo, la società Krescendo detiene internamente solo le posta-
zioni di sviluppo e i server di test e CVS. Questa scelta è motivata dalla notevole affidabilità e sicu-
rezza che un IDC professionale è in grado di garantire rispetto ad una gestione interna, che risulte-
rebbe meno efficiente e probabilmente richiederebbe personale dedicato.
I processi che caratterizzano lo sviluppo, il rilascio e le manutenzioni di eXtraSheet sono quindi le
operazioni effettivamente core, relegando le attività di carattere tecnico e di monitoraggio alla società
di hosting. Prima di considerare le procedure tecniche di sviluppo, è bene evidenziare quali siano i
flussi informativi che caratterizzano la fornitura del prodotto eXtraSheet ad un cliente nuovo od esi-
stente:
1) Il commerciale Krescendo contratta con il cliente le funzionalità necessarie.
2) Il commerciale, con la collaborazione di un analista Krescendo, determina le specifiche del
problema ed una soluzione. Qualora la soluzione sia implementabile direttamente tramite la
GUI di eXtraSheet, l’analista implementa immediatamente la soluzione. In caso contrario,
procede alla stesura delle specifiche funzionali e le inoltra ad uno o più sviluppatori.
3) Lo sviluppatore prende in carico le specifiche e procede allo sviluppo.
eXtraSheet
40
4) Lo sviluppatore effettua una release sul Test Server di eXtraSheet e ne verifica la correttez-
za. In collaborazione con l’analista, provvede poi ad accertare l’aderenza alle specifiche e la
funzionalità dell’applicazione.
5) Lo sviluppatore richiede la release in produzione e l’applicativo viene consegnato al cliente,
offrendo eventualmente training e supporto tecnico in caso di malfunzionamenti o bachi di
programmazione.
Esaminando in dettaglio il punto 3, lo sviluppatore di eXtraSheet, è incaricato di implementare una o
più funzionalità, creando la logica applicativa (codice Java) e la presentazione (codice HTML e Fre-
eMarker). Mentre nella tabella seguente è riportato il dettaglio della postazione di sviluppo tipica, si
osserva che gli strumenti di sviluppo di cui necessita il programmatore sono un IDE (Integrated De-
velopment Environment) per lo sviluppo in Java ed un editor HTML o di testo per la realizzazione dei
template FreeMarker. In realtà questi strumenti presuppongono la JDK (Java Development Kit) e tut-
te le librerie di uView ed eXtraSheet. Queste ultime sono gestite tramite un server CVS (installato sul
server Augustus) che permette allo sviluppatore di ottenere in tempo reale sulla propria postazione le
versioni aggiornate di tutti i sorgenti.
CVS (Concurrent Versioning System) è infatti un sistema consolidato per la gestione delle versioni,
mantenendo sincronizzato il lavoro svolto da un team di sviluppo, permettendo anche una collabora-
zione distribuita. CVS implementa un'architettura client-server: il server conserva la versione corrente
di tutti i file di progetto e la loro storia, mentre i client, che coincidono solitamente con le postazioni
degli sviluppatori, effettuano l'upload di nuovi file sul server oppure aggiornano quelli esistenti, previa
verifica di conflitti che devono essere risolti manualmente.
Ogni sviluppatore procede quindi all’implementazione delle specifiche ricevute, tipicamente realiz-
zando prima la componente di business logic in Java (basandosi sulle API di uView ed eXtraSheet)
e, quindi, la parte di presentazione in FreeMarker. Una volta completata, il programmatore compila i
sorgenti e, poiché le postazioni locali dispongono degli strumenti presenti anche in produzione (in
particolare il DBMS MySQL e l’application server Resin), effettuano un primo testing
dell’applicazione.
Al punto 4 si giunge ad effettuare una release sul Test Server, per accertarsi che le funzionalità già
testate in locale siano funzionanti anche nell’ambiente di pseudo produzione, spesso molto differenti
da quelli di sviluppo (oltre al sistema operativo, possono disporre di versioni differenti di librerie e/o
configurazioni (ad esempio del DBMS) molto varie. Per fare ciò, è necessario effettuare l’upload dei
sorgenti nel repository CVS presente su Augustus e, quindi, effettuare il rilascio sul test server Tibe-
rius attraverso lo strumento Apache Ant, un tool open source per effettuare il processo di build di
progetti Java. Il processo di build prevede la compilazione del codice Java in codice binario,
l’eventuale packaging in librerie ed il deployment sul server di destinazione.
Infine, con il punto 5 lo sviluppatore richiede al responsabile una release sul server in produzione.
Questo processo è analogo alla release sul server di test ma, per la criticità dell’operazione, solo po-
chi dipendenti dispongono dell’accesso al server.
eXtraSheet
41
Hardware features
CPU Intel Core 2 Quad 2.6 Ghz
RAM 4 GB DDR2
Hard Disk 320 GB (7200 rpm)
Monitor 2 x LCD 17’’
Networking Gigabit Ethernet network card
Optical drive DVD±RW 22x
Software configuration
O.S. MS Windows XP Professional
Java Platform JDK 1.5
Office Suite MS Office 2007 Enterprise
Java IDE Eclipse v. 3.4
Terminal emulator PuTTY v. 0.6
CVS client WinCVS v. 1.2
Web/Application server Caucho Resin v. 3.1.7
DBMS Engine MySQL v. 5.0.41
Visual MySQL Client MySQL GUI Tools v. 1.2.12
Text editor Notepad++ v. 4.0.2
Other Tools iReport v. 2.0.5 (template builder for Jasper Reports PDF)
Tabella 3.1 - Esempio di configurazione di una postazione di sviluppo
Le alternative ad eXtraSheet
42
4 Le alternative ad eXtraSheet
La ricerca delle alternative ad eXtraSheet è stata svolta dal candidato con l’obiettivo di individuare
una o più soluzioni che offrissero una piattaforma idonea a realizzare applicazioni Web con un ap-
proccio simile ad eXtraSheet.
La procedura di software selection ha seguito i seguenti principi:
1) Prova del prodotto: sono stati considerati esclusivamente i sistemi che offrissero una versio-
ne demo, tali da verificare agevolmente le funzionalità principali e le caratteristiche del pro-
dotto. Il candidato ha ritenuto che le informazioni migliori, seppur con maggior dispendio di
tempo, sono ricavabili in primo luogo provando direttamente il prodotto e analizzandolo in
base ai requisiti target.
2) Modularità e personalizzazione del prodotto: è stata prestata particolare attenzione alla scel-
ta di soluzioni espandibili, considerando che spesso i requisiti di un’azienda evolvono e mu-
tano nel tempo. È stata valutata la fattibilità di adattamenti o personalizzazioni in grado di
soddisfare i bisogni del cliente specifico.
Il processo di ricerca ha evidenziato anzitutto la limitata disponibilità di soluzioni in ambito commer-
ciale, mentre sono stati individuati ed esaminati numerosi prodotti open source che presentavano
molteplici caratteristiche disponibili out-of-the-box e avrebbero permesso lo sviluppo di funzionalità
ad hoc con particolare facilità.
4.1 Commerciali
Il panorama dei software commerciali dotati delle funzionalità ricercate da Cefin Systems risulta piut-
tosto limitato. Dopo una serie di ricerche da parte del candidato, si può concludere che è fortemente
probabile che non vi siano soluzioni commerciali simili ad eXtraSheet e offerte come prodotto. Risul-
ta essere altrettanto limitata la disponibilità di prodotti analoghi ma fornito come servizio SaaS. In
questo secondo caso è stato individuato esclusivamente un player che fornisce Dabble DB, una so-
luzione molto simile ad eXtraSheet ma fornito con un approccio commerciale differente. Si può per-
tanto affermare che Dabble DB è l’unico competitor noto di eXtraSheet.
4.1.1 DabbleDB
Dabble DB è un’applicazione Web fornita interamente in modalità SaaS dall’omonima società cana-
dese. Questa soluzione, analogamente ad eXtraSheet, permette al cliente di realizzare semplici ap-
plicazioni Web di data management utilizzando esclusivamente un Web browser.
Le alternative ad eXtraSheet
43
L’interfaccia grafica risulta particolarmente curata, intuitiva e ricca di funzionalità. Dabble DB permet-
te di creare applicazioni o viste basate su dati attraverso numerosi strumenti quali tabelle, grafici,
mappe e calendari. La visualizzazione standard mostra i dati analogamente a MS Excel, tramite ri-
ghe, colonne, formule e totali. È supportato inoltre il ―matching‖ tra dati di tabelle diverse, analoga-
mente ad un database relazionale.
Oltre al data-entry diretto, Dabble DB è in grado di importare dati nei formati Excel e CVS; altrettanto
vari i formati di esportazione che includono RSS, JSON e KML. È inoltre possibile gestire varie tipo-
logie di dati speciali, ad esempio posizioni GPS facilmente rappresentabili direttamente sulle mappe.
Dabble DB offre una API Javascript che permette di impiegare i dati in qualsiasi altra applicazione. È
possibile creare form in blog o siti Web esterni che, al momento della sottomissione da parte
dell’utente, inseriranno i dati in nuovi record di Dabble DB. Viceversa, è possibile ottenere i dati come
oggetti JSON da utilizzare ad esempio in reportistiche per siti Web. Questo permette di integrare
Dabble DB in qualunque applicazione Web senza dover coinvolgere il lato server.
Essendo un prodotto commerciale, non sono noti molti dettagli relativi alle tecnologie impiegate in
Dabble DB. È interamente scritto in linguaggio Smalltalk, utilizzando il framework Open Source Sea-
side che offre la possibilità di sviluppare applicazioni Web seguendo una serie di best-practices. Tra
queste, un particolare meccanismo di controllo di stato, il riuso e l’incapsulamento di componenti, la
separazione tra modello e presentazione e la fornitura di un IDE completo per lo sviluppo e il debug-
ging.
Alcuni screenshot relativi a Dabble DB sono disponibili in figura.
Pur essendo molto simile ad eXtraSheet, la strategia commerciale di Dabble DB si differenzia per
due aspetti principali:
1) Il prodotto è direttamente disponibile per qualsiasi utente, senza la necessità di avere un
contatto con il personale dell’azienda. È possibile effettuare la registrazione sul sito
www.dabbledb.com e si riceveranno immediatamente le credenziali per l’utilizzo del sistema
per 30 giorni.
2) Non sono forniti servizi accessori di consulenza o progettazione: al cliente viene fornito e-
sclusivamente l’ambiente Dabble DB. Non sembrano essere inoltre possibili personalizza-
zione o sviluppi ad hoc. Questa scelta è coerente con la precedente, poiché fornendo il pro-
dotto ad una clientela potenzialmente vastissima, l’azienda non potrebbe gestire efficiente-
mente tutte le richieste.
La strategia attuata per Dabble DB evidenzia che, piuttosto che rivolgersi a clienti con esigenze par-
ticolari, l’azienda è intenzionata a fornire una efficiente soluzione alle aziende che utilizzano i trad i-
zionali sistemi per la gestione dei dati (quali MS Access, MS Excel o addirittura supporti cartacei),
apportando efficienza, unicità dell’informazione e accessibilità globale. Infatti, Dabble DB è la solu-
zione ideale per creare agevolmente un database online, ma non offrendo possibilità di personaliz-
zazioni o sviluppi ad hoc, non risulta idoneo a supportare processi complessi.
Le alternative ad eXtraSheet
44
Come mostrato in figura, le stime del traffico per Dabble DB sono notevoli, dell’ordine delle decine di
migliaia visite mensili per gli U.S., probabilmente superiori ad eXtraSheet.
Figura 4.1 - Interfaccia Web di Dabble DB
Figura 4.2 - Stima del traffico mensile negli U.S. per Dabble DB
Le alternative ad eXtraSheet
45
4.2 Open source basati analoga tecnologia
In ambito Open Source è stato decisamente più agevole individuare le soluzioni alternative ad e-
XtraSheet. Infatti, la facilità nel reperire documentazione e la possibilità di effettuare test liberamente
ha consentito di selezionare numerose piattaforme e framework estremamente interessanti. Nei suc-
cessivi sottoparagrafi si riporteranno le principali, descrivendone brevemente le caratteristiche, che
possono variare notevolmente da prodotto a prodotto: alcuni forniscono esclusivamente efficienti
funzionalità per lo sviluppo rapido di applicazioni e risultano più orientate a sviluppi personalizzati,
mentre altre offrono interfacce grafiche complete e si candidano come valide alternative ad eXtra-
Sheet.
4.2.1 WaveMaker
WaveMaker è una piattaforma di sviluppo Open Source che permette di realizzare con estrema rapi-
dità applicazioni Web in Java dotate di architetture avanzate.
Le applicazioni create con WaveMaker seguono gli standard Enterprise Java, impiegando le migliori
tecnologie Open Source. Come rappresentato in figura, le principali sono:
- Spring framework, che facilita e standardizza l’implementazione di molte funzionalità tipiche
eseguite lato server.
- Dojo toolkit, una libreria JavaScript che offre molte funzionalità lato client, ad esempio com-
ponenti grafici, animazioni e interazioni AJAX.
- Hibernate, un middleware Open Source che fornisce un servizio di object-relational mapping,
cioè la gestione di un database relazionale attraverso un sistema ad oggetti Java. Il vantag-
gio principale che ne deriva è l’indipendenza dal database (l’applicazione è più portabile) e
l’automazione delle query SQL necessarie. WaveMaker risulta pertanto in grado di interfac-
ciarsi con la maggior parte dei database relazionali.
- JSON RPC (JavaScript Object Notation - Remote Procedure Call), un protocollo per lo
scambio efficiente di dati tra client e server, particolarmente impiegato per le interazioni A-
JAX.
Le alternative ad eXtraSheet
46
Figura 4.3 - L'architettura di WaveMaker
WaveMaker include il Visual Ajax Studio, un IDE anch'esso Web-based per lo sviluppo visuale di
un'applicazione tramite strumenti grafici drag-and-drop, secondo il paradigma WYSIWYG. Template
predefiniti e componenti AJAX permettono di creare un'interfaccia grafica senza sviluppare codice. È
inoltre possibile creare template personalizzati. Attraverso i Live Forms è possibile creare rapida-
mente applicazioni database CRUD (Create, Read, Update, Delete), poiché WaveMaker è in grado
di importare automaticamente schemi di database esistenti.
Sviluppare applicazioni con WaveMaker risulta inoltre particolarmente flessibile poiché viene rispetta-
to il paradigma Model-View-Controller, che prevede un’architettura efficiente e manutenibile. È inoltre
possibile integrare codice Java già esistente, interfacciarsi con Web service basati su WSDL, REST
o RSS. Il deployment è estremamente semplice, dato che WaveMaker crea file WAR standard che
possono essere utilizzati su qualunque server Java dotato del Java Development Kit 1.5 o superiore
e di un application server tra quelli più diffusi (Apache Tomcat, JBoss, WebLogic o WebSphere).
L’azienda che cura il progetto Open Source, WaveMaker Software Inc., fornisce il prodotto in tre di-
verse configurazioni:
- Con licenza Open Source (WaveMaker community edition), completamente gratuita; le appli-
cazioni generate con questa versione sono soggette alla licenza Apache.
- Con licenza commerciale, che implementa alcune funzionalità di sicurezza aggiuntive e ga-
rantisce il supporto tecnico da parte dell’azienda.
- Come servizio, installando e rendendo disponibile WaveMaker al cliente da server esterni.
L’azienda si avvale del servizio di hosting Amazon Elastic Computer Cloud.
Rispetto ad eXtraSheet, WaveMaker risulta coprire solo parzialmente le sue funzionalità. Come verrà
ribadito nella valutazione dei casi di studio, WaveMaker offre un’interfaccia che, seppur molto sem-
Le alternative ad eXtraSheet
47
plice ed intuitiva per uno sviluppatore junior, non risulta idonea ad essere consegnata al cliente finale
e talvolta nemmeno ad essere utilizzata da un analista privo di capacità di sviluppo. Inoltre, anche
per applicazioni semplici è necessario effettuarne il deploy e non possono essere configurate da per-
sonale non esperto.
La notevole potenzialità di WaveMaker che appare ancor prima di effettuare i test consiste nella pos-
sibilità di implementare con facilità la struttura di un’applicazione Web mediante interfaccia grafica,
evitando di sviluppare manualmente le funzionalità standard. Le classi ed il codice Java ottenuto po-
trà poi essere modificato ed esteso dallo sviluppatore.
4.2.2 Apache Click
Apache Click è un framework per lo sviluppo di applicazioni Web, distribuito con licenza open source
(licenza Apache), attualmente in fase di ―incubazione‖ all’interno della Apache Software Foundation.
L’uso del framework è piuttosto tradizionale se comparato a WaveMaker ma offre una serie di stru-
menti estremamente potenti. Le caratteristiche principali di Apache Click sono la semplicità e, al con-
tempo, le ottime prestazioni e la notevole scalabilità.
Click è basato sui concetti di pagine e di componenti, che permettono una valida rappresentazione
dei contenuti Web e consentono uno sviluppo rapido. Le pagine e i componenti sono sviluppate il
Java mentre i template possono essere realizzati in Velocity, FreeMarker o JSP. Click utilizza un
modello basato su eventi per l’elaborazione delle Servlet, in particolare si avvale di una singola Ser-
vlet (ClickServlet) per gestire le richieste. Al momento della ricezione di una richiesta, ClickServlet
crea un oggetto Page per elaborare la richiesta e utilizza il template per formattare i risultati.
Poiché privo di numerosi livelli di astrazione, Apache Click risulta di facile apprendimento e utilizzo,
anche grazie alla disponibilità di documentazione e tutorial.
4.2.3 OpenXava
OpenXava è un framework Open Source per lo sviluppo di applicazioni Web basate sugli standard
Java Enterprise. Quali funzionalità pressoché "out-of-the-box", OpenXava permette di realizzare mo-
duli CRUD e reportistica standard in modo estremamente agevole. Risulta tuttavia flessibile per e-
stendere le funzionalità standard e sviluppare ad hoc le caratteristiche più avanzate o specifiche.
La filosofia di OpenXava è quella di impiegare esclusivamente codice Java, eventualmente corredato
di Annotations Java o documenti XML. Le tecnologie impiegate, che presentano una complessità e-
stremamente ridotta, risultano:
POJOs (Plain Old Java Object), senza ricorso ad oggetti speciali, quali gli Enterprise Java
Bean
Le alternative ad eXtraSheet
48
Java Persistence API, un framework che permette di gestire dati provenienti da database re-
lazionali all'interno della piattaforma Java
Java Annotation, una sorta di metadati che possono essere aggiunti al codice sorgente e re-
peribili a run-time.
OpenXava permette allo sviluppatore di definire, senza la necessità di programmare, l'accesso ai da-
ti, il comportamento e le funzionalità dell'applicazione. In tal modo, molte caratteristiche standard so-
no realizzate con estrema facilità mentre il programmatore può sviluppare ad hoc nuove funzionalità
o modificare qualsiasi componente.
Il noto paradigma Model-View-Controller non viene utilizzato in favore dell'approccio business com-
ponent. Un business component è un’entità autonoma (tipicamente consiste in una classe Java) che
contiene tutte le informazioni necessarie per definire un concetto di business (ad esempio, l'opera-
zione di pagamento). In un componente business, è possibile definire:
la struttura dei dati;
le validazioni, i calcoli e le elaborazioni legate al concetto di business;
le viste e le modalità di presentazione o esportazione dei dati;
ORM (Object Relational Mapping), cioè le informazioni per convertire le tabelle di un
database in oggetti per l'applicazione Java.
Un business component non definisce tuttavia le azioni che l'utente può intraprendere nell'applica-
zione. Questo viene definito nei controller, una serie di azioni che possono essere condivise in diver-
si business component. Un'applicazione OpenXava è infine una serie di moduli: ogni modulo unisce
un componente di business con uno o più controller. Ogni modulo dell'applicazione è una funzionalità
disponibile per l’utente.
Rispetto al modello MVC, la suddivisione è di carattere funzionale ed è più efficiente quando la strut-
tura dati o la logica varia frequentemente.
OpenXava offre una elevata produttività nello sviluppo di applicazioni business e presenta una curva
di apprendimento ridotta, anche grazie alla buona disponibilità di tutorial. Le applicazioni generate
sono completamente in Java EE e l'interfaccia utente con tecnologia AJAX. è pienamente compatibi-
le con gli application server più diffusi (Tomcat, JBoss, ...).
Le alternative ad eXtraSheet
49
4.3 Open source basati su tecnologie differenti
4.3.1 Xataface
Xataface è uno strumento altamente flessibile e personalizzabile che permette di trasformare un
database MySQL in un’applicazione Web funzionale. È possibile generare form, liste e menù per
realizzare un’applicazione di data management basata sul noto database MySQL.
Pur avendo una serie di funzionalità standard che offrono già un’applicazione completa, Xataface ri-
sulta flessibile, permettendo allo sviluppatore di modificare le caratteristiche e il comportamento
dell’applicazione tramite diversi strumenti. Per le modifiche più semplici (es. creazione di una lista)
sono impiegati semplici file testuali di configurazione, mentre per personalizzazioni consistenti si u-
sano template e plugin.
Xataface è un progetto open source destinato agli sviluppatori Web e ai database administrator per
realizzare rapidamente un front-end per il database MySQL di facile utilizzo, destinato ad utenti non
esperti in ambito IT.
Rispetto ai framework Java, la potenzialità più rilevante è la semplicità di setup ed i requisiti di piatta-
forma software estremamente ridotti: è sufficiente un Web server dotato di interprete PHP (versione
4 o superiore) e il RDBMS MySQL (versione 3.23 o superiore).
Nella documentazione ufficiale, viene evidenziato che Xataface si pone l’obiettivo di coprire una ―nic-
chia‖ che non è servita da molte altre soluzioni. Xataface non è un database administrator quale
PHPMyAdmin, non una libreria-framework quale PHPCake e nemmeno un Content Management
System o un generatore di codice sebbene prelevi da ognuna di queste categorie qualche funzionali-
tà. Xataface è un framework atipico, poiché la maggior parte dei framework richiedono una sostan-
ziale componente di sviluppo per ottenere un’applicazione completa. Con Xataface è infatti possibile
creare un’applicazione di data management in pochi minuti, senza sviluppare codice. Xataface, a
sua volta, non genera codice aggiuntivo, rendendo l’applicazione manutenibile o estensibile con sv i-
luppi ad hoc.
Tra le numerose feature offerte da Xataface, si possono citare le seguenti:
1) front-end per database, realmente out-of-the-box;
2) interfaccia utente semplice ed intuitiva, estremamente semplice da ―navigare‖;
3) configurazione avanzata dell’applicazione mediante semplici file testuali;
4) sistema di autenticazione e delle permission potente e configurabile;
5) gestione dell’integrità referenziale tra le tabelle;
6) possibilità di personalizzazioni mirate osservando semplici convenzioni (es. esecuzione di
operazioni specifiche all’inserimento di un record);
Le alternative ad eXtraSheet
50
7) elevata modularità: sono disponibili numerosi moduli aggiuntivi ed è disponibile una semplice
API per realizzare i propri moduli personalizzati;
8) ampia gamma di funzionalità di editing (es. uso di widget, data grid, copia di record, upload
di file, …);
9) funzioni di ricerca semplice o avanzata;
10) esportazione dei dati nei formati RSS, XML, CSV, JSON;
11) gestione delle impostazioni internazionali
Con l’ultima release, Xataface si dimostra un prodotto maturo ed affidabile da poter essere impiegato
in ambito aziendale, in grado di garantire facilità di amministrazione e ottima manutenibilità.
4.3.2 VFront
VFront è un front-end Web based in tecnologia PHP per database MySQL o PostgreSQL. Rispetto
alle soluzioni sinora identificate, il target di VFront è più limitato e appare già un prodotto completo,
pressoché solamente da installare. VFront è un progetto open source italiano, sviluppato da una
community molto ristretta, composta perlopiù dal suo fondatore.
Seppur VFront abbia avuto origine molto recentemente, indicativamente all’inizio dell’anno 2007, è
una soluzione completa e ricca di funzionalità. Può essere utile ad enti o organizzazioni che utilizza-
no database MySQL o PostgreSQL e che debbano far accedere i propri dipendenti ai database per
la consultazione, l'inserimento o la modifica dei dati, senza sviluppare un client ad-hoc e mediante
l'uso di un semplice browser Web. L'applicazione è rivolta a chi, genericamente, necessiti di un front-
end per database installabile e configurabile con poco sforzo in tempi rapidi.
VFront può essere pensato come strumento di interfaccia per database, e svolgere alcune funzioni
come MS Access, con il vantaggio di essere consultabile in rete, direttamente dal browser. Non è
uno strumento di amministrazione di database come PHPMyAdmin, né lo sostituisce: l'interfaccia è
rivolta all'utente finale che opera sui dati. L'interfaccia di VFront è pensata quindi per utenti finali non
esperti, che possano operare sui dati in sicurezza con una interfaccia familiare ed intuitiva.
VFront è particolarmente utile quando diversi utenti o tipologie di utenti debbano accedere alle tabel-
le con differenti privilegi: grazie al sistema altamente personalizzabile dei gruppi e dei diritti è possibi-
le far accedere diversi gruppi di dipendenti solo a specifiche tabelle o viste, mostrare o nascondere
campi a determinati gruppi, impostare regole per la validazione degli input e tenere sotto controllo
l'attività sul database. VFront possiede inoltre moduli di esportazione dati, statistiche e gestione di
reportistica basata su XML, XSL e XSL-FO.
Analogamente a Xataface, VFront richiede esclusivamente un Web Server (preferibilmente Apache
HTTP Server 2.0 o superiore) dotato di interprete PHP (versione 5.0 o superiore) e del RDBMS
MySQL (versione 5.0 o superiore) oppure PostgreSQL (versione 8.0 o superiore). Sono inoltre ri-
chiesti opzionalmente ulteriori moduli per funzionalità aggiuntive, tra le quali la reportistica grafica.
Le alternative ad eXtraSheet
51
Lato client, sono supportati la maggior parte dei browser che necessitano esclusivamente la compa-
tibilità con Javascript.
Nella user guide sono presenti i seguenti principi, che hanno guidato lo sviluppo di VFront:
1. VFront non sporcherà il database creando tabelle o viste aggiuntive e non modificherà i dati
delle tabelle, a meno che non lo si effettui tramite la sua GUI. Verrà invece creato un
database di regole (o un suo schema su PostgreSQL): VFront non prende possesso del
database, ma permette di usarlo più agevolmente.
2. VFront non bypasserà le regole impostate nel database: è possibile creare nuovi vincoli più
restrittivi di quelli presenti (in termini di chiavi esterne, input accettabili, etc.), ma mai il con-
trario.
3. VFront funzionerà tanto meglio quanto più sia stata rigorosa la definizione del database.
VFront supporta la normalizzazione, le chiavi esterne, le chiavi primarie ed i commenti sulle
tabelle e sui campi.
Come già anticipato, VFront dispone di innumerevoli funzionalità di configurazione (tra cui anche la
gestione delle traduzioni delle stringhe), mentre non viene reso esplicito nulla riguardo la disponibilità
di API o alla possibilità di estensione e personalizzazione con codice sviluppato ad hoc. Essendo di-
sponibili i codici sorgente, appare comunque agevole la realizzazione di una o più interfacce per
l’integrazione di moduli esterni.
La documentazione di VFront risulta completa e dettagliata, mentre il supporto tecnico appare limita-
to poiché la community del progetto risulta poco attiva.
Casi di studio
52
5 Casi di studio
Dopo aver individuato e fornito una descrizione generale sulle alternative ad eXtraSheet, il candidato
ha provveduto a sviluppare alcune applicazioni utilizzando le diverse piattaforme, cercando di far
emergere gli aspetti distintivi di ognuna.
La maggioranza delle soluzioni sviluppate sono state commissionate da Cefin Systems, e quindi svi-
luppate prevalentemente su eXtraSheet, limitandosi a considerare in termini previsionali quale sa-
rebbe stato il grado di difficoltà nello sviluppare soluzioni analoghe con le altre piattaforme identifica-
te.
5.1 Applicazione standard di Data Management
Il caso di studio più semplice che è stato preso in esame riguarda un’applicazione standard di data
management, che richiede le funzionalità tipiche di un front-end per database. Nel caso specifico,
l’applicazione è denominata Sateltrack Admin, uno strumento in grado di registrare e conservare dati
relativi alla fornitura di Sateltrack, inseriti dagli addetti al supporto tecnico di Cefin Systems (Italia e
Romania) e una serie di partner tecnologici in tutta Europa.
5.1.1 eXtraSheet
L’implementazione su eXtraSheet era già presente e utilizzata da Cefin Systems da circa due anni.
Rispetto al progetto riportato in figura, i principali sheet risultano:
- THOR (Telematic Hardware Online Repository), dove il personale tecnico provvede alla regi-
strazione dei veicoli sui quali viene installata la periferica per Sateltrack, includendo una se-
rie di dettagli relativi alla configurazione, alla certificazione e eventuali interventi successivi.
- TTS (Ticket Tracking System), che permette la gestione di tutti i ticket relativi alle richieste di
supporto da parte dei clienti per tutti i prodotti Cefin Systems. Il personale infatti provvede al-
la registrazione di una richiesta e questa verrà poi presa in carico da altri specialisti sino a
quando non sarà risolto il problema.
Casi di studio
53
Figura 5.1 - Pagina principale di Sateltrack Admin su eXtraSheet
La creazione dell’applicazione con eXtraSheet risulta particolarmente intuitiva, e si realizza esclusi-
vamente tramite l’interfaccia grafica; come mostrato parzialmente in figura per lo sheet THOR, è suf-
ficiente specificare il tipo di campi desiderati e le loro caratteristiche. Nei dettagli di ogni campo è
possibile applicare una serie di impostazioni (es. contenuto di una lista, dimensioni della casella di
testo, limite alla lunghezza del campo, …).
Figura 5.2 - Pagina di creazione di uno sheet su eXtraSheet
Una volta completata la creazione della struttura, sono immediatamente disponibili il form di data-
entry e un’interfaccia di visualizzazione dei dati. In figura è riportata GUI di data-entry per lo sheet
THOR.
Casi di studio
54
Figura 5.3 - Form di data-entry su eXtraSheet
Le liste predefinite, impiegate ad esempio per i campi ―Service provider‖, ―Equipment type‖, ―Pro-
ducts‖ e ―Input 1‖ sono gestite nella sezione Lists, dove sono contenute tutte le liste del progetto ―Sa-
teltrack Admin‖. Nelle due figure successive sono mostrate la sezione Lists e il dettaglio per la lista
―Products‖ e la lista figlio ―Team‖: ogni prodotto ha solo determinati team disponibili.
Casi di studio
55
Figura 5.4 - Elenco delle liste predefinite su eXtraSheet
Figura 5.5 - Gestione delle liste predefinite su eXtraSheet
Figura 5.6 – Gestione dei gruppi di utenti su eXtraSheet
Casi di studio
56
5.1.2 WaveMaker
Lo sviluppo con WaveMaker viene effettuata tramite il Visual Ajax Studio, l’IDE fornito per lo sviluppo
intuitivo delle applicazioni in ottica WYSIWYG. Non è quindi possibile realizzare l’applicativo tramite
una GUI utente semplice come eXtraSheet e risulta necessaria la conoscenza dell’ambiente di svi-
luppo Wavemaker, che risulta tuttavia intuitivo e non richiede alcun sviluppo di codice.
In questa applicazione, Sateltrack Admin sono stati importati i database esistenti e configurati per
WaveMaker. Attraverso i Live Forms è quindi risultato particolarmente semplice realizzare una appli-
cazione CRUD quale è Sateltrack Admin.
Entrando nel dettaglio, dopo la lettura della User Guide di Wavemaker, i principali passi seguiti per
l’implementazione sono stati i seguenti:
1) Creazione del layout dell’applicazione, mediante l’inserimento e la configurazione di elementi
predefiniti (Centered Layout, Title Bar, Tabs, Search List Detail).
2) Importazione del database che richiede anzitutto la configurazione di un servizio database
(indicando in motore DBMS, indirizzo IP, porta, credenziali e nome del database),
l’importazione dello schema da parte di Wavemaker e quindi la creazione di una vista su di
esso (LiveView) selezionando i campi desiderati e le loro caratteristiche. In figura è rappre-
sentata la vista per THOR, dove è già possibile visualizzare l’anteprima dei risultati.
3) Creazione della LiveVariable, un oggetto che permetterà di utilizzare la vista nei componenti
di Wavemaker. È sufficiente assegnare come LiveSource la vista appena creata e svolgere
le operazioni di associazione ai componenti della pagina, ad esempio alla search box e alla
Data Grid. Infine è necessario impostare al Live Form il Dataset DataGrid.SelectedItem, in
modo da visualizzare nel form il record selezionato dall’elenco. Nella figura seguente è ripor-
tato uno screenshot che rappresenta l’aspetto dell’IDE di WaveMaker durante lo sviluppo
dell’applicazione.
4) Personalizzazione del form per facilitare l’uso da parte dell’utente e garantire la correttezza
del data-entry. Ad esempio alcuni campi sono stati impostati come liste predefinite, configu-
rate tramite la GUI di WaveMaker. Rispetto ad eXtraSheet, è stato necessario creare un
database ad hoc per ogni lista predefinita, rendendo la realizzazione più laboriosa.
5) Impostazione dei permessi di accesso, creando una apposita tabella sul database ed asso-
ciandola alla funzionalità predefinita di login fornita da Wavemaker.
Casi di studio
57
Figura 5.7 - Creazione di una vista sul database in Wavemaker
Figura 5.8 - WaveMaker Visual AJAX Studio
Casi di studio
58
L’applicazione finale è stata ultimata senza particolari difficoltà, anche se la complessità dell’IDE
Web based determinano un’affidabilità non ottimale e la necessita di piccoli re-work o riavvii del
server durante lo sviluppo, pur utilizzando la configurazione software consigliata. Inoltre la realizza-
zione con WaveMaker fornisce in output i sorgenti per effettuare il deploy su un Application Server,
che dovrà essere effettuato ogni volta che si effettuano modifiche alla struttura dell’applicazione. In
figura è riportato uno screenshot dell’applicazione Sateltrack Admin basata su WaveMaker.
Figura 5.9 - Sateltrack Admin realizzata con WaveMaker
5.1.3 VFront
VFront ha consentito di realizzare un’altra versione di Sateltrack Admin impiegando la nota coppia
PHP-MySQL. Anche in questo caso la fase formativa non è risultata particolarmente complessa: la
relativa semplicità della piattaforma ha consentito un’installazione agevole e la user guide ha fornito
le istruzioni dettagliate per l’utilizzo di VFront.
Rispetto a WaveMaker, VFront non fornisce un ambiente di sviluppo grafico di ―back-end‖ bensì un
front-end Web analogo ad eXtraSheet per la configurazione completa dell’applicazione. Risulta so-
lamente necessario realizzare lo schema del database (MySQL o PostgreSQL) tramite una query
SQL oppure uno dei tanti front-end di progettazione disponibili per i RDBMS citati: tutte le successive
operazioni sono eseguibili con VFront.
Nel caso specifico sono stati importati i database di THOR, TTS e THOR setup (una tabella per la
configurazione di un’applicazione esterna che utilizza i dati di THOR). VFront appare immediatamen-
Casi di studio
59
te un’applicazione user friendly, funzionalmente molto simile ad eXtraSheet ma maggiormente anco-
rata al database, sia come terminologia utilizzata nell’interfaccia sia per gli strumenti utilizzati (viste,
liste basate su tabelle, …).
Il sistema di permission, anch’esso out-of-the-box, risulta adeguato e prevede l’organizzazione degli
utenti in gruppi e la definizione delle regole tramite l’interfaccia grafica disponibile a tutti gli utenti
amministratori.
Le macro-fasi che hanno condotto alla realizzazione dell’applicazione sono le seguenti:
1) Creazione (o definizione) delle tabelle che si desidera gestire in VFront.
2) Creazione dei gruppi a cui si desidera assegnare gli utenti. VFront richiede infatti almeno un
gruppo per procedere con l’impostazione delle tabelle.
3) Configurazione delle tabelle tramite la GUI di VFront, che suddivide in quattro sezioni le im-
postazioni da assegnare:
a. Definizione della categorie di operazioni che l’utente potrà effettuare tramite VFront.
Tali azioni sono le tipiche permission di un database e alcune aggiuntive, in partico-
lare la possibilità di importare/esportare i dati o di inserire file allegati al record. È
possibile scegliere di impostare tali permission solo per il gruppo attualmente sele-
zionato oppure per tutti i gruppi esistenti.
b. Configurazione dei campi, specificando se deve essere visibile nel form e/o nella vi-
sione ―grid‖ e indicando per ognuno la tipologia di dati. Se il campo deve essere
scelto dall’utente tramite una lista predefinita, questa può essere impostata scriven-
do manualmente le opzioni oppure configurando una ulteriore tabella del database
dalla quale prelevare gli elementi della lista. Analogamente alle permission è possibi-
le scegliere se impostare la attuale configurazione dei campi per tutti i gruppi oppure
solo per quello corrente. Tipicamente risulta conveniente la prima scelta e, in secon-
da istanza, risulterà agevole effettuare le modifiche sugli altri gruppi (es. rendere in-
visibile un campo, modificare gli elementi di una lista per un gruppo specifico).
c. Ordinamento dei campi, impostando mediante una pratica funzionalità Javascript
l’ordine di presentazione dei campi della tabella mostrata nella scheda.
d. Impostazione di eventuali sottomaschere, per gestire le relazioni "uno a molti" e
"molti a molti". VFront propone le sottomaschere quando per un record di una tabel-
la, ci siano molti record figli: all'utente saranno visibili dalla vista scheda mediante un
box con dei pulsanti nei quali è indicato il numero di tali istanze e la possibilità di vi-
sualizzarle. Tale funzionalità non è stata impiegata in Sateltrack Admin ma si perce-
pisce l’utilità in applicazioni più complesse.
Casi di studio
60
4) Configurazione degli utenti: è possibile effettuarlo tramite l’interfaccia di VFront, che permette
anche l’invio della relativa notifica e-mail all’utente, oppure direttamente sul database (utile
ad esempio quando già si dispone di una tabella contenente gli utenti da creare).
Figura 5.10 - Configurazione delle permission sulla tabella in VFront
Casi di studio
61
Figura 5.11 - Configurazione dei campi in VFront
Il risultato ottenuto è riportato in figura: quando un utente standard (non amministratore) effettua cor-
rettamente l’operazione di login, visualizza la schermata contenente le tabelle e le viste disponibili (in
questo caso sono state create due viste di test, relative alla tabella TTS per facilitare la ricerca delle
richieste di supporto per Cefin Systems Italia).
Casi di studio
62
Figura 5.12 - Pagina principale di Sateltrack Admin (VFront)
Analizzando nel dettaglio l’interfaccia per THOR, il form generato da VFront è riportato (parzialmen-
te) in figura e presenta i campi del database, come sono stati configurati dal front-end. Si possono
notare i campi read-only (ID e response number), le liste predefinite, i campi data (dotati del pratico
calendario in Javascript) e i campi testuali che tuttavia non sono personalizzabili in termini di posizio-
ne e dimensioni (è disponibile solo la riga singola oppure il box a 10 righe).
Oltre alla classica navigazione tra i record (simile a MS Access), è utile la funzione ―Duplicate‖ che
permette di copiare un record (per modificarne solo il necessario) e la possibilità di inserire allegati
(attachments) al record.
La ricerca avviene inserendo in un nuovo form i valori desiderati e VFront fornirà i soli record che
conterranno esattamente i valori inseriti (es. ricercando sul campo vehicle model ―Iveco‖ verranno
mostrati solo i record con tale campo uguale a ―Iveco‖ e non ad esempio ―Iveco Daily‖.
L’esportazione completa dei dati è possibile nei formati CSV, HTML, ODS (OpenOffice Spreadshet)
ed XLS (MS Excel). È inoltre possibile importare dati in formato CSV tramite una procedura fraziona-
ta in 4 step.
Casi di studio
63
Figura 5.13 - Form di data-entry in VFront
Attraverso la visuale ―grid‖ sono presentati in gruppi (20 record di default) gli elementi della tabella,
con una GUI simile a MS Excel. Con un doppio click sul record viene aperta la relativa maschera di
data-entry, mentre cliccando sulle intestazioni, gli elementi (ma solo della schermata corrente) ven-
gono ordinati in base a tale campo.
Casi di studio
64
Figura 5.14 - Grid view in VFront
5.1.4 Xataface
Xataface ha permesso di realizzare un ulteriore versione dell’applicazione Sateltrack Admin, impie-
gando la stessa piattaforma di VFront (Apache Server, PHP e MySQL). Rispetto a quest’ultima, Xa-
taface appare inizialmente una soluzione più professionale ma si rivela meno ricca di funzionalità.
Come nei casi precedenti, è anzitutto necessario realizzare o importare un database esistente, e-
sclusivamente in formato MySQL. Contrariamente a VFront ed eXtraSheet, Xataface non fornisce un
front-end per la configurazione dell’applicazione da parte dell’utente amministratore ma tali procedu-
re sono da effettuarsi creando dei file testuali di configurazione. Sebbene richiedano l’accesso ai
server di produzione, queste operazioni risultano tuttavia estremamente semplici ed espletabili da
personale non tecnico.
Come nelle precedenti versioni, sono stati importati i database di THOR, TTS e THOR setup. I tempi
di setup sono risultati estremamente ridotti, probabilmente inferiori a VFront o Wavemaker e parago-
nabili a quelli di eXtraSheet. A prima vista si nota immediatamente un aspetto grafico e un layout
dell’applicazione molto simile ad eXtraSheet.
La procedura seguita per lo sviluppo con Xataface risulta la seguente:
1. Creazione (o importazione) delle tabelle che si desidera gestire in Xataface.
2. Creazione dei file di configurazione di base, in particolare il file conf.ini per le impostazio-
ni del database e il file index.php per specificare le directory di Xataface e inizializzare
l’applicazione.
Casi di studio
65
3. A questo punto l’applicazione risulta già fruibile: tutte le funzionalità di base sono abilitate e si
dispone di un front-end completo per il database configurato. Rimangono tuttavia da svolge-
re una serie di perfezionamenti indispensabili per un’applicazione Enterprise, quali la funzio-
nalità di login e la gestione delle liste predefinite.
4. Creazione delle liste predefinite e traduzione dei campi, entrambi attraverso dei file testuali.
Le liste predefinite, gestite tramite il file valuelists.ini, sono definite specificando per
ogni elemento il valore visualizzato nell’interfaccia e il corrispondente valore che verrà inseri-
to nel database. La traduzione dei campi (dal nome della colonna nel DB al nome visualizza-
to, accompagnato eventualmente una breve descrizione) sono effettuate nel file
fields.ini dove è possibile indicare numerose impostazioni per ogni singolo campo, tra
cui le regole per la validazione (dalla semplice verifica della lunghezza all’uso di espressioni
regolari). È stata riscontrata l’impossibilità di scegliere l’ordinamento di presentazione dei
campi (quantomeno in modalità out-of-the-box), funzionalità utile ma non difficile da realizza-
re ad hoc, dato che i sorgenti sono disponibili e non eccessivamente complessi.
5. Creazione di un semplice sistema di permission. Nonostante le numerose funzionalità per la
gestione dei permessi di accesso, per Sateltrack Admin sono stati implementati solamente i
due ruoli tipici, Admin e Read-only, per l’accesso all’applicazione. Per far ciò è stato neces-
sario creare una tabella ad hoc nel database, aggiungere un’impostazione di configurazione
nel file conf.ini e creare una classe PHP per la definizione delle regole, che in questo ca-
so è stata esattamente quella indicata negli esempi contenuti nella user guide di Xataface.
L’applicazione ottenuta è riportata in figura: dopo aver effettuato il login, l’utente visualizza diretta-
mente il foglio relativo ad una delle tabelle disponibili. Sono disponibili una serie di funzionalità stan-
dard, tra cui l’ordinamento in base ad una specifica colonna, la navigazione tra i record indicando il
numero di entry per pagina, l’inserimento di nuovi record, la duplicazione o la modifica di record esi-
stenti e l’importazione di nuovi record.
Casi di studio
66
Figura 5.15 - Visualizzazione standard dei record in Xataface
Nella sezione ―details‖ è disponibile la visualizzazione singola dei record, permettendo di esaminarli
più in dettaglio. Nella sezione ―find‖ si accede alle funzionalità di ricerca avanzata, potendo specifica-
re per uno o più campi i valori desiderati, anche parziali.
La funzionalità ―grid‖ permette inoltre di accedere ad una visualizzazione simile a VFront, con la pos-
sibilità di inserire nuovi record direttamente da tale interfaccia e ottenere ordinamenti su tutti i record
e non solo su quelli visualizzati al momento.
Nella figura seguente è riportato il form generato da Xataface per l’inserimento o l’aggiornamento dei
record che risulta piuttosto simile a VFront.
Casi di studio
67
Figura 5.16 - Xataface, form di inserimento o editing
Xataface risulta quindi una soluzione simile a VFront che, a fronte di una maggiore versatilità e rapi-
dità, richiede la gestione dell’applicazione tramite alcuni file di configurazione. Xataface dispone inol-
tre di API e funzionalità standardizzate per estendere con facilità l’applicazione, trasformandola da
un semplice front-end per database ad una soluzione completa.
5.2 Applicazione per questionari on-line
Il secondo caso di studio è stato svolto durante la collaborazione per lo sviluppo di un’applicazione
per un cliente di Krescendo Ltd. A causa della complessità dell’applicazione, lo sviluppo
dell’applicazione è avvenuto solo su piattaforma eXtraSheet e a causa di limiti temporali sono state
svolte solo alcune prove isolate sulle altre alternative. Di seguito si propone comunque una previsio-
ne della difficoltà e dei tempi che sarebbero stati necessari per sviluppare un’applicazione analoga
con le altre alternative a confronto.
Casi di studio
68
Il candidato è stato messo in contatto con il team della società Krescendo incaricato di sviluppare un
progetto di valutazione del personale mediante questionari di soddisfazione, affinché i manager
dell’azienda committente potessero ottenere i feedback provenienti dal personale.
5.2.1 Lo sviluppo su eXtraSheet
L’applicazione è stata interamente sviluppata su eXtraSheet ed è stata suddivisa in due moduli di-
stinti:
1) Compilazione dei questionari da parte del personale. Gli aspetti principali oggetto di analisi
sono stati:
a. Individuazione delle permission, basate sulla struttura organizzativa dell’azienda, per
stabilire ―chi deve valutare chi‖.
b. Realizzazione dei questionari su eXtraSheet, contrattazione e analisi con l’azienda
committente di sezioni, scale di valutazione e domande.
2) Generazione di reportistica di sintesi (in forma anonima), che rappresentava i punteggi e le
valutazioni aggregate, destinata ai manager o alle altre figure professionali valutate. Aspetti
fondamentali in questo ambito sono risultati:
a. Valutazione delle tipologie di reportistica necessarie e delle soluzioni più idonee (re-
port o grafici di sintesi).
b. Individuazione delle permission di accesso ai report.
Figura 5.17 - Questionario (parziale) realizzato su eXtraSheet per la valutazione del personale
Casi di studio
69
Figura 5.18 - Report (parziale) relativo alle valutazioni ricevute da una divisione aziendale
Dopo le classiche fasi di raccolta dei requisiti e stesura delle specifiche funzionali che il candidato
non ha seguito poiché non rilevanti ai fini della propria attività, è stato avviato lo sviluppo.
La prima fase è stata la predisposizione del questionario, realizzato direttamente dal responsabile
commerciale di Krescendo che seguiva il committente: tali operazioni sono state svolte con facilità,
grazie alla semplicità di eXtraSheet nel realizzare strutture dati, form di data-entry, liste di gruppi ed
utenti. Al termine di questa fase alcuni dipendenti del committente avevano già la possibilità di prova-
re l’applicazione e valutare l’adeguatezza dei questionari e della procedura di compilazione.
Durante la seconda fase, il candidato ha provveduto allo sviluppo diretto di alcune porzioni di reporti-
stica, essendo questa la componente totalmente personalizzata dell’applicazione. I report di sintesi
erano da generarsi mediante JFreeChart e JasperReports, e dovevano contenere una serie di grafici
utili a fornire indicazioni immediate sul grado di soddisfazione dei dipendenti. Tali sviluppi prevede-
vano dunque la tradizionale programmazione ad oggetti in Java (ambiente Eclipse), sfruttando
l’infrastruttura (package sviluppati ad hoc) offerta da eXtraSheet. Sono state sviluppate classi Java
per il calcolo dei risultati aggregati, per la generazione di grafici in JFreeChart e l’inserimento di que-
sti in file PDF creati mediante JasperReports. I file PDF venivano quindi generati dinamicamente e
mostrati direttamente sul browser dell’utente anziché visualizzare pagine (X)HTML.
Al termine dello sviluppo e del testing necessario è stata effettuata la release sui server di produzio-
ne di eXtraSheet, fornendo l’applicazione finale al cliente.
In conclusione, si desidera evidenziare che il bilancio in termini di effort per lo sviluppo di tale appli-
cazione è stato estremamente modesto: paragonandolo ad uno sviluppo tradizionale, ad esempio su
piattaforma J2EE con le classiche Servlet e JSP, sarebbe risultato molto più dispendioso in termini di
Casi di studio
70
tempi e quindi di costi. Nonostante la seconda fase (sviluppo di reportistica personalizzata) sia stata
comunque laboriosa ed abbia richiesto programmazione, le numerose funzionalità out-of-the-box
hanno consentito un risparmio di tempo del 40% circa rispetto ad uno sviluppo in J2EE e almeno il
20% rispetto alla piattaforma PHP.
5.2.2 Previsioni per le altre piattaforme
Le piattaforme alternative ad eXtraSheet sono state paragonate ―a tavolino‖ per stabilire se fossero
più o meno efficienti nello sviluppo di un’applicazione per la gestione dei questionari simile a quella
realizzata.
Impiegando VFront, si sarebbero ottenuti risultati molto simili ad eXtraSheet e probabilmente anche
superiori: la piattaforma dispone infatti di notevoli funzionalità di reportistica che avrebbero supporta-
to anche la creazione dei grafici con effort ridotti e con sviluppi di codice molto limitati. Ad un livello
lievemente inferiore si posizionerebbe Xataface, dotato di funzionalità valide per la creazione del
questionario ma nessuna possibilità di reportistica già disponibile.
WaveMaker sarebbe probabilmente risultata la soluzione meno indicata, data la necessità di svilup-
pare tutto ex-novo, inclusa la gestione degli utenti e dei gruppi con le relative permission, per
un’applicazione medio-piccola. Inoltre, per questa applicazione, la complessità della piattaforma
J2EE sarebbe forse eccessiva per le reali esigenze (è necessario un basso carico di elaborazione).
5.3 Applicazione di Web Timesheet
Il terzo caso di studio ha riguardato lo sviluppo di un’applicazione completa di media complessità. Si
tratta di un progetto di Timesheet Management fruibile interamente su Web, per una società di co-
struzioni immobiliari cliente di Cefin Systems. L’interfaccia Web doveva consentire ad ogni dipenden-
te dell’azienda l’inserimento del proprio timesheet giornaliero, cioè il dettaglio delle ore lavorate in
termini di ―quanto‖, ―quando‖ e ―cosa‖ (es. 6 ore, il 18/05/2009, sulla commessa ―Electrical System‖
del progetto ―Cortina Residential‖). Il personale autorizzato necessitava quindi di effettuare il monito-
raggio delle risorse umane, verificando i timesheet inseriti dai dipendenti e accedendo a reportistica
che avrebbe supportato una efficiente organizzazione del personale.
La struttura degli sheet su eXtraSheet a supporto della memorizzazione dei timesheet era già defini-
ta e utilizzata da tempo dal committente, ma risultava difficilmente gestibile, poiché scarsamente u-
ser-friendly e le operazioni di data entry erano centralizzate (tipicamente effettuate dagli addetti alla
contabilità).
Ai fini del presente elaborato, il candidato desidera sottolineare l’importanza di questa situazione,
cioè l’insufficienza nella maggior parte delle applicazioni richieste dai clienti business della sola piat-
taforma di data-management, sia questa eXtraSheet, VFront o una delle rimanenti.
Casi di studio
71
L’applicazione, eXtraSheet based, aveva quindi l’obiettivo di garantire un miglior monitoraggio dei
tempi, costi ed attività del personale, permettendo la gestione individuale dei timesheet e offrendo ai
manager report relativi ai timesheet aggregati. Le funzionalità principali sono riportate di seguito.
5.3.1 Personal Timesheet
Il modulo fruibile dal dipendente, denominato Personal Timesheet, doveva consentire l’accesso ad
un calendario interattivo (contenente interazioni di tipo AJAX), tramite il quale dichiarare le proprie
presenze: per il giorno desiderato, indicare il numero di ore lavorate su una commessa di un deter-
minato progetto, lasciando eventualmente commenti aggiuntivi. Oltre alle funzionalità di modifi-
ca/eliminazione di valori inseriti in precedenza, la pagina doveva contenere anche un report per tutto
il mese correntemente visualizzato, riportante il totale ore complessivo ed il totale ore per un deter-
minato progetto.
Figura 5.19 - Funzionalità di Personal Timesheet
5.3.2 Timesheet Controller
Per utenti con permission di controllo è inoltre disponibile una pagina contenente un report mensile,
contenente a livello giornaliero il numero totale di ore inserite dai dipendenti per ogni progetto e rela-
tiva commessa. Un’interazione di tipo AJAX permette di conoscere la ripartizione delle ore presenti in
ogni cella tra i vari dipendenti.
Casi di studio
72
Figura 5.20 - Funzionalità di Timesheet Controller
Altre funzionalità offerte dall’applicazione, che oggi è divenuta molto più di un’applicazione di Time-
sheet Management, sono ad esempio:
- KPI reports: pagine di sintesi per la valutazione dello stato di avanzamento di progetti real
estate, in particolare riguardo gli scostamenti tra costi preventivati e sostenuti.
- Project management: sistema di gestione e monitoraggio dei progetti real estate, con la pos-
sibilità da parte dei project manager di effettuare aggiustamenti riguardo le previsioni dei co-
sti, impiegando le notifiche e-mail per informare gli altri stakeholder.
5.3.3 Considerazioni
eXtraSheet ha consentito di realizzare un’applicazione Web completa in grado di supportare i calen-
dari lavorativi di centinaia di utenti. La struttura solida e le personalizzazioni attuate hanno permesso
di contenere i tempi e i re-work.
La componente personalizzata risultava in questo caso circa il 50% delle funzionalità. Gli sviluppi so-
no stati organizzati in un package ad hoc, contenente (limitatamente ai moduli di Timesheet
Management) 6 classi Java, per un totale di circa 1.600 righe di codice. Inoltre, sono stati impiegati i
template FreeMarker per il lato presentazione; un file XML contiene tutte le costanti e le impostazioni
per la configurazione dell’applicazione.
Casi di studio
73
Sono fornite le funzionalità di string management e le impostazioni internazionali, impiegando in mo-
do efficiente le tecniche predisposte per la piattaforma eXtraSheet.
Le considerazioni riguardanti le altre piattaforme oggetto del seguente elaborato possono essere co-
sì sintetizzate:
- WaveMaker risulterebbe più efficiente rispetto al caso dei questionari on-line, poiché la mag-
gior incidenza delle funzionalità custom giustificherebbe lo sviluppo ad hoc e WaveMaker ri-
sulterebbe estremamente competitivo.
- VFront e Xataface sarebbero sostanzialmente equivalenti: VFront beneficerebbe della mag-
gior completezza dell’interfaccia e della reportistica mentre Xataface permetterebbe di utiliz-
zare le API per uno sviluppo più rapido delle personalizzazioni. Quanto detto vale però dopo
aver compiuto le necessarie verifiche e adattamenti delle piattaforme ad un utilizzo profes-
sionale poiché si ribadisce che entrambe le soluzioni non sono pienamente affidabili per un
impiego di questo tipo.
In conclusione si vuole però sottolineare il problema delle performance. L’applicazione gestisce vo-
lumi di dati notevoli: centinaia di utenti che utilizzano applicazioni interfacciate con database com-
plessi (dati relativi a progetti, job order, anagrafiche dei dipendenti, presenze giornaliere, …). Indica-
tivamente si può stimare che una schermata utente del timesheet possa richiedere l’aggregazione
dei risultati di decine di query SQL. Impiegando eXtraSheet, che si avvale di livelli inferiori (si veda il
framework uView) ad elevate performance, non sono riscontrabili problemi di efficienza mentre sa-
rebbe preferibile condurre un’analisi delle performance prima di affermare che un’applicazione simile
possa essere realizzata con una delle piattaforme alternative.
Benchmarking
74
6 Benchmarking
Le comparazioni effettuate per orientare la scelta della soluzione più idonea sono basate sui casi di
studio riportati nel capitolo precedente. Nella fase valutativa, il candidato ha tenuto conto dei seguen-
ti principi di fondo:
- Struttura del sistema, in termini di implementazione e parametrizzazione, esperienza e stabi-
lità, prestazioni in presenza di dati e di flussi di lavoro crescenti, possibilità di integrazione,
manutenzione e aggiornamento, indipendenza dalla base-dati e dalla piattaforma, …
- Caratteristiche del sistema, quali flessibilità e facile generazione di report, struttura modulare
e integrata, concetti e soluzioni validi internazionalmente, principi di sicurezza e di autorizza-
zione, adeguatezza delle funzionalità Web, …
- Rischi, in particolare valutazioni e commenti reperibili sul Web riguardo la piattaforma in e-
same, eventuali garanzie di supporto tecnico, tipologia e politiche di licenza, orizzonte pre-
sumibile di prosecuzione dello sviluppo e aggiornamento da parte della società venditrice o
dalla comunità open source.
6.1 Confronto dei risultati
La prima fase di benchmarking è stata quella di confrontare le prestazioni ed i risultati ottenuti nello
svolgimento dei casi di studio che nel capitolo precedente sono stati descritti sotto l’aspetto procedu-
rale ed operativo.
Come verrà descritto in dettaglio nei sottoparagrafi successivi, si può affermare che eXtraSheet è
certamente una soluzione di riferimento nell’ambito ricercato, essendo sviluppata da una società
commerciale con obiettivi funzionali e prestazionali ben definiti. Le altre soluzioni esaminate, tutte di-
stribuite con licenza Open Source, sono state tuttavia molto sorprendenti, ognuna dotata di caratteri-
stiche peculiari e spesso ricche di funzionalità realmente paragonabili ad eXtraSheet.
6.1.1 eXtraSheet: professionale e performante
eXtraSheet è apparsa nei casi di studio una piattaforma stabile e potente. Rispetto alle altre alterna-
tive identificate si differenzia per le ottime performance nella gestione di volumi di dati consistenti e
per la disponibilità di un modello ad oggetti, sviluppato ad hoc dalla società Krescendo, orientato allo
sviluppo di personalizzazioni con estrema rapidità. Sotto l’aspetto funzionale, la piattaforma risulta
altrettanto completa, permettendo anche la progettazione e l’amministrazione dell’applicazione me-
diante interfaccia Web, senza la necessità di alcuna competenza tecnica.
I principali aspetti positivi e negativi che contraddistinguono eXtraSheet sono:
Benchmarking
75
Performance elevate
Scalabile e idoneo ad estendere un’applicazione di data management con personalizzazioni
complesse
Affidabile e professionale
Sistema complesso, richiede allo sviluppatore di conoscere la piattaforma J2EE ed è neces-
saria formazione ad hoc
Poco versatile nella creazione di piccole personalizzazioni
Licenza proprietaria, concessa da Krescendo a prezzi presumibilmente elevati
6.1.2 VFront: clone PHP di eXtraSheet
VFront è il clone di eXtraSheet su piattaforma PHP+MySQL e Open Source. L’idea di business è la
medesima e le funzionalità sono molto simili, ad eccezione della progettazione del DB che deve es-
sere effettuata esternamente. Non si può dire altrettanto per le performance e la maturità del prodot-
to, che risulta tuttavia già utilizzabile e relativamente affidabile. Con sforzi limitati è possibile aggior-
nare e sviluppare VFront per portarlo ad un livello pari ad eXtraSheet, con il vantaggio della licenza
libera e della maggior semplicità della piattaforma PHP.
Le principali osservazioni possono essere così sintetizzate:
È l’applicazione più simile ad eXtraSheet
Apparentemente ben strutturata a livello di codice
Documentazione completa, community di sviluppo italiana
Tempi di sviluppo ridottissimi, le funzionalità sono completamente out-of-the box
Nessun sviluppo di codice: amministrazione e gestione sono effettuati tramite la GUI, l’unica
operazione esterna è la progettazione del database.
Performance non molto elevate durante la fase di importazione schema e generazione dei
form
Prodotto ancora in versione beta, presenza di qualche lieve baco
String management e internazionalizzazione da verificare
Formattazione dei form di data-entry non troppo curata
Funzionalità di ricerca migliorabile
Visualizzazione grid poco raffinata (ordinamento solo sui record correnti, impossibilità di sce-
gliere il numero di record per schermata, intestazioni senza alias)
Community Open Source poco attiva
Richiede una considerevole revisione prima di essere impiegato per applicazioni Enterprise
Benchmarking
76
6.1.3 WaveMaker: altamente custom e IDE Web
Nello svolgimento dei casi di studio, Wavemaker si è rivelata una soluzione differente rispetto alle al-
tre: non fornisce un ambiente già disponibile ma richiede di sviluppare l’applicazione ex-novo. Que-
sto non si traduce tuttavia in una complessità eccessiva: è disponibile un ambiente di sviluppo visua-
le ―drag-and-drop‖ e sono forniti una serie di componenti funzionali da inserire nelle pagine Web che
richiedono una configurazione minima. È quindi possibile realizzare applicazioni Web in Java senza
scrivere codice, tramite l’IDE grafico fornito con WaveMaker, testare in tempo reale l’applicazione e,
al termine, esportare i file sorgente (o direttamente il file WAR) per effettuarne il ―deploy‖ sul server
Apache Tomcat.
Le conclusioni relative a WaveMaker risultano pertanto:
Quantità di componenti utilizzabili con minima configurazione molto elevata
Ideale per sviluppare applicazioni interamente custom
Segue il paradigma J2EE
Nessun componente out-of-the-box, il sistema di data-management deve essere sviluppato
ogni volta, ad hoc.
Affidabilità limitata, le applicazioni generate non sono sempre robuste
Performance limitate
Release piuttosto macchinose
6.1.4 Xataface: immediato
Xataface si presenta come una soluzione di data-management molto veloce e leggera.
L’installazione e il setup è estremamente rapida e la creazione di un’applicazione è particolarmente
semplice ma richiede di essere configurata mediante file di testo (es. specifiche per il DB, liste prede-
finite, controlli sui campi, …). Quest’ultima caratteristica risulta pratica per applicazioni semplici, ma
può diventare inefficiente in caso di applicazioni complesse e, in ogni caso, per essere effettuata da
non tecnici, poiché è necessario interagire con il file system del server di produzione. Xataface ri-
chiederebbe pertanto uno sviluppo ex-novo dell’interfaccia di configurazione/amministrazione.
In sintesi, gli aspetti positivi e negativi che contraddistinguono Xataface sono:
Sviluppo molto rapido e semplice
Presenza di API per lo sviluppo di personalizzazioni
Prodotto abbastanza maturo, non sono stati individuati bachi di rilievo
Nessuna GUI per la progettazione/amministrazione, effettuabili agendo direttamente sul DB
e mediante file di configurazione
Difficoltà ad amministrare applicazioni complesse mediante file testuali
Benchmarking
77
Scalabilità limitata, necessita di una verifica delle performance
Funzionalità out-of-the-box limitate
Unico DBMS supportato (MySQL)
6.2 Metodologia QFD
Il Quality Function Deployment (QFD) è un processo logico strutturato per raccogliere i bisogni ed i
desideri del cliente e trasformarli in requisiti e specifiche tecniche per il prodotto da innovare. Il meto-
do QFD è un ambiente strutturato per guidare il progettista nel riconoscimento delle aspettative del
cliente in termini di esigenze di qualità e per sviluppare (da cui il termine ―deployment‖) in modo s i-
stematico le richieste dei clienti, operazione che conduce all’ottenimento di specifiche di prodotto o di
servizio.
L’insieme organizzato di matrici è altresì detto Casa della Qualità, lo strumento per la traduzione di
bisogni ed aspettative in specifiche tecniche.
Il principale obiettivo del QFD è il superamento dei seguenti limiti propri delle fasi di progettazione:
- l'insufficiente attenzione per le esigenze dei clienti (acquisendo il fatto che la qualità va intesa
come soddisfazione dei clienti);
- la perdita delle informazioni concernenti obiettivi iniziali durante le altre fasi che caratterizza-
no il processo di sviluppo ed industrializzazione del prodotto/servizio;
- la disomogeneità delle specifiche elaborate a partire dai requisiti, sulle quali operano perso-
ne e funzioni diverse.
Una volta individuati i requisiti utente, la priorità loro attribuita ed il livello di soddisfazione attuale e,
una volta elaborate le Provided Function, il progettista si chiede, per ogni requisito espresso
dall’utente, quale/i Provided Function (che devono necessariamente essere misurabili e controllabili)
del prodotto/progetto/sistema da realizzare permettono di soddisfarlo.
Si giunge quindi alla fase di ―mapping‖ (costruzione delle corrispondenze) in cui vengono messi in
relazione le Provided Function ed i requisiti utente mediante la Matrice delle Relazioni.
Sfruttando la metodologia del QFD si procede alla sua applicazione per il sistema oggetto dello stu-
dio. Rispetto all’approccio classico, si propone tuttavia una versione differente del QFD, per ottenere
sia il predetto mapping ma realizzare anche un processo di benchmarking per ricavare una graduato-
ria o ranking di carattere orientativo tra le piattaforme software sinora considerate.
Più in dettaglio, la procedura che si propone è composta dai seguenti passi:
1) Esplicitare e prioritizzare i requisiti utente, che corrispondono in questo caso ai requisiti del
progetto richiesto da Cefin Systems.
Benchmarking
78
2) Riorganizzare i requisiti di sistema che sono comparsi durante lo svolgimento dei casi di stu-
dio e il testing delle varie piattaforme. Tali caratteristiche, pur rimanendo ad un livello di det-
taglio intermedio, permettono di valutare con maggior facilità le alternative.
3) Calcolare, mediante la matrice delle relazioni, una graduatoria delle caratteristiche tecniche
per determinare quali siano i loro livelli di importanza.
4) Realizzare una sorta di benchmarking tra le quattro alternative in esame, esprimendo un
giudizio sul livello di copertura di ognuna delle caratteristiche tecniche delineate e calcolando
un punteggio complessivo e quindi una graduatoria per le quattro piattaforme.
6.2.1 Requisiti utente
I requisiti utente sono stati ricavati dalla documentazione progettuale raccolta nella fase iniziale ed è
stata effettuata una prioritizzazione secondo le indicazioni ricevute dagli stakeholder, seguendo la
scala riportata in tabella.
Alle informazioni provenienti dagli stakeholder del progetto si aggiungono quindi altre informazioni
riguardanti i processi aziendali e le best-practice di Cefin Systems.
Priorità dei requisiti utente
1 Trascurabile
2 Preferibile
3 Importante
4 Molto importante
5 Indispensabile
Tabella 6.1 - Scala di priorità per i requisiti utente
Codice Req.
Requisito Utente Importanza
ass. Importanza
rel.
a Time to Market ridotto 5 9,62%
b Stima precisa dei tempi di realizzazione 3 5,77%
c Implementazione tramite GUI di funzionalità base 3 5,77%
d Implementazione agevole di funzionalità base 5 9,62%
e Sviluppo flessibile 4 7,69%
f Facilità di rilascio e manutenzione 4 7,69%
g Possibilità di estendere facilmente l'applicazione 3 5,77%
h Attitudine a gestire volumi di dati crescenti 3 5,77%
i Performance adeguate al Web 2.0 3 5,77%
l Interfaccia user-friendly lato utente 3 5,77%
m Possibilità di integrazione con applicazioni o database Legacy
2 3,85%
n Portabilità delle applicazioni generate 2 3,85%
o Investimento iniziale contenuto 3 5,77%
p Costi di gestione contenuti 4 7,69%
q Indipendenza dalla piattaforme HW 2 3,85%
r Indipendenza dalla piattaforme SW 3 5,77%
Totale 52 100%
Tabella 6.2 - Requisiti Utente per la piattaforma Web
Benchmarking
79
6.2.2 Requisiti di sistema
I requisiti di sistema sono solitamente impiegati dagli ingegneri del software come base di partenza
per la progettazione; tali requisiti, oltre ad aggiungere dettagli implementativi, vanno a spiegare come
i requisiti utente dovrebbero essere forniti dal sistema.
Nella ricerca dei requisiti di sistema, il candidato ha individuato diverse tipologie di Provided Function
(terminologia usata nel gergo della Casa della Qualità) e raggruppato le stesse in alcune macro-
categorie. Le Provided Function possono appartenere alle seguenti tipologie:
- Fattore umano: principalmente rivolti a determinare il livello di difficoltà per la creazione e
l’utilizzo della piattaforma, rispettivamente per il personale dell’azienda (sviluppatori ed anali-
sti) e clienti (utenti) finali.
- Funzionalità Web: permettono di definire le classi di funzionalità offerte dalla piattaforma.
- Tempi di sviluppo ed evasione: forniscono un’indicazione circa i tempi di sviluppo, poiché
sono rappresentati dai tempi medi di sviluppo e dalla quantità di funzionalità implementabili
con rapidità.
- Performance e scalabilità: impiegati per quantificare le prestazioni della piattaforma e la sua
attitudine a gestire volumi di dati o utenti crescenti.
- Manutenzioni e upgrade: offrono indicazioni circa la possibilità di estendere un’applicazione
esistente o di fornire supporto ed effettuare le modifiche necessarie in caso di malfunziona-
menti.
- Infrastruttura hardware e software: forniscono una panoramica relativa alla flessibilità e alla
libertà concesse dalla piattaforma nella scelta di componenti hardware e software.
Le Provided Function individuate sono rappresentate nella tabella che segue; considerando la natura
dei requisiti di sistema, che devono misurabili e controllabili, è stata associata un’unità di misura a
ciascuno di essi, anche se alcuni casi di carattere qualitativo, non volendo dettagliare eccessivamen-
te i requisiti di sistema.
Categoria Codice Descrizione Provided Function Unità di misura
Fattore umano
1 Competenza necessaria agli sviluppatori alta, media, bassa
2 Competenza necessaria agli analisti alta, media, bassa
3 Formazione specifica per gli sviluppatori ore
4 Formazione specifica per gli analisti ore
5 Facilità di utilizzo del prodotto finale per utenti non esper-ti
ore
Funzionalità Web
6 Livello di completezza del sistema di data-management "out-of-the-box"
alta, media, bassa
7 Grado di personalizzazione dell'interfaccia standard alta, media, bassa
8 Flessibilità nella creazione di viste o reportistica persona-lizzata
alta, media, bassa
9 Presenza di un sistema di autenticazione e di permission facilmente configurabile
si/no
Benchmarking
80
10 Presenza del motore di ricerca interno si/no
11 HTML ben formato / conformità agli standard di accessi-bilità W3C
Scala W3C
12 Protocollo impiegato per autenticazione on-line e sessio-ni private
http/https
13 Requisito minimo di banda per l'accesso alle applicazioni generate
kbps
14 Qualità dell'aspetto grafico alta, media, bassa
Tempi di
sviluppo/evasione
15 Tempo medio di sviluppo per applicazioni standard FTE
16 Tempo medio di sviluppo per applicazioni "lightly custo-mized"
FTE
17 Creazione di applicazioni di data-management intera-mente tramite GUI
si/no
18 Quantità di funzionalità "out-of-the-box" alta, media, bassa
19 Quantità di funzionalità implementabili con minime confi-gurazioni
alta, media, bassa
Performance e scalabilità
20 Maturità della piattaforma (diffusione) alta, media, bassa
21 Frequenza di nuove release alta, media, bassa
22 Scalabilità delle applicazioni (volumi di dati e/o numero utenti)
alta, media, bassa
23 Funzionalità di caching si/no
24 Performance lato utente (tempi di risposta) alta, media, bassa
25 Performance in fase di sviluppo e importazione database alta, media, bassa
Manutenzioni e Upgrade
26 Programmazione ad oggetti si/no
27 Modularità delle applicazioni generate alta, media, bassa
28 Facilità di bug-fixing in tempo reale alta, media, bassa
29 Complessità del codice generato alta, media, bassa
30 Qualità della documentazione esistente alta, media, bassa
31 Possibilità di richiedere supporto tecnico professionale si/no
32 Predisposizione allo sviluppo di funzionalità custom alta, media, bassa
33 Facilità di rilascio del codice in ambiente di produzione alta, media, bassa
Infrastruttura Hardware e
Software
34 Sistema cross-platform si/no
35 Presenza di sistemi di sicurezza (antivirus,firewall) si/no
36 Indipendenza dal database (scelta tra più DBMS) si/no
37 Licenza della piattaforma tipologia
38 Possibilità di impiego di componenti open source o free (es. O.S., IDE, DBMS)
si/no
39 Possibilità di installazione distribuita si/no
40 Grado di capacità elaborativa (CPU) e memoria RAM ri-chieste
alta, media, bassa
Tabella 6.3 - Classificazione delle provided function o caratteristiche tecniche
6.2.3 Gerarchizzazione caratteristiche tecniche
Come già anticipato, lo scopo principale del QFD in questa sede risulta la gerarchizzazione delle ca-
ratteristiche tecniche per poter effettuare un benchmarking tra le soluzioni individuate. Di seguito è
stata operata la classica fase di ―mapping‖ (costruzione delle corrispondenze) in cui vengono messi
Benchmarking
81
in relazione le Provided Function (caratteristiche tecniche) ed i requisiti utente mediante la Matrice
delle Relazioni.
Per ogni cella della matrice è necessario definire ―quanto‖ una specifica Provided Function (assimila-
bile al ―come‖) contribuisce alla soddisfazione di un particolare requisito (corrispondente al ―che co-
sa‖). Tale processo, che ha lo scopo di riempire le celle della Matrice delle Relazioni, utilizza una
scala (riportata nella tabella che segue) il cui obiettivo è rilevare l’intensità delle relazioni che suss i-
stono tra i requisiti espressi dall’utente e la capacità di soddisfacimento delle Provided Function.
Matrice delle relazioni tra Requisiti Utente e PF
9 punti Correlazione forte
3 punti Correlazione media
1 punti Correlazione debole
Tabella 6.4 - Scala impiegata nella Matrice delle Relazioni
A questo punto dell’analisi è possibile verificare il ―livello di copertura‖ fornito dal nuovo sistema ai
requisiti richiesti dall’utente, passando attraverso la mappatura rispetto alle Provided Function. Tale
livello viene calcolato a partire dalla Matrice delle Relazioni ed individua, per ogni requisito, la som-
ma dei gradi di copertura forniti dalle singole Provided Function.
I requisiti utente che vantano un valore più alto del livello di copertura coincidono spesso con i requi-
siti considerati prioritari; tali requisiti vantano un elevato grado di copertura in quanto vengono previ-
ste molteplici Provided Function, poiché la scelta di queste ultime è stata proprio guidata dalle speci-
fiche del progetto richiesto da Cefin Systems.
Benchmarking
82
Figura 6.1 - QFD: la matrice delle relazioni
Benchmarking
83
Infine, è possibile ottenere le informazioni desiderate dall’applicazione del QFD: la gerarchizzazione
delle caratteristiche tecniche. Ciò è possibile moltiplicando il vettore dei pesi dei requisiti utente (co-
stituito dalle priorità) per il vettore della Matrice delle Relazioni corrispondente a ciascuna Provided
Function. Si ottiene pertanto un unico elenco di Provided Function, ordinate per importanza in senso
decrescente. Grazie ad esso è possibile definire le caratteristiche sulle quali è necessario essere
maggiormente esigenti nella scelta della piattaforma Web. Nella seguente tabella si riportano le dieci
caratteristiche tecniche più rilevanti.
Codice Requisito di sistema Imp.
Assoluta Imp.
Relativa
16 Tempo medio di sviluppo per applicazioni "lightly customized" 140 5,86%
15 Tempo medio di sviluppo per applicazioni standard 139 5,81%
19 Quantità di funzionalità implementabili con minime configurazioni 139 5,81%
6 Livello di completezza del sistema di data-management "out-of-the-box" 129 5,40%
18 Quantità di funzionalità "out-of-the-box" 127 5,31%
17 Creazione di applicazioni di data-management interamente tramite GUI 124 5,19%
38 Possibilità di impiego di componenti open source o free (es. O.S., IDE, DBMS) 119 4,98%
37 Licenza della piattaforma 108 4,52%
29 Complessità del codice generato 92 3,85%
8 Flessibilità nella creazione di viste o reportistica personalizzata 82 3,43%
Tabella 6.5 - Caratteristiche tecniche più rilevanti ricavate dall'applicazione del QFD
Da una prima analisi della tabella sopra riportata si nota come nelle prime posizioni siano localizzati
requisiti di sistema relativi a specifiche funzionali maggiormente rilevanti per la piattaforma Web, pri-
ma tra tutte la necessità di un time-to-market minimo.. Assumono importanza notevole anche la fles-
sibilità del sistema e le tipologie di licenze che richiede, che implicano ripercussioni importanti sui co-
sti di investimento e di gestione futuri.
Risulta interessante notare come molte Provided Function collocate nelle prime posizione costitui-
scano ―fattori abilitanti‖, ovvero specifiche che presentano un elevato numero di correlazioni positive
e che rendono quindi possibile la realizzazione di molteplici funzionalità con uno sforzo ridotto.
6.2.4 Benchmarking
La procedura di benchmarking è stata condotta secondo una approccio estraneo alla metodologia
QFD, sfruttando però i risultati sinora ricavati.
Per ognuna delle caratteristiche tecniche (di cui è già noto il suo peso) è stato espresso (dal candida-
to, supportato da alcuni stakeholder di Cefin Systems) un giudizio sul livello di copertura offerto dalle
piattaforme a confronto.
L’obiettivo della valutazione è quello di evidenziare in modo chiaro le caratteristiche tecniche offerte
dalle piattaforme a confronto in termini di ―grado di disponibilità‖ in caso di caratteristiche non funzio-
nali (es. ―modularità delle applicazioni‖, ―sistema cross-platform‖) oppure in termini di qualità/quantità
delle funzionalità standard pronte all’uso per implementare la caratteristica funzionale in esame. Ciò
Benchmarking
84
consente anche di avere una prima idea delle personalizzazioni da eseguire sulla struttura della piat-
taforma, relativi a situazioni per le quali risulta necessaria la scrittura di nuovo codice o la realizza-
zione di nuove strutture dati.
Punteggio Valutazione
1 Estremamente scarso o nullo
2 Scarso
3 Sufficiente
4 Buono
5 Molto buono o ottimo
Tabella 6.6 - Scala di valutazione per la copertura delle caratteristiche tecniche
Il processo di valutazione, è stato calcolato il punteggio pesato (valutazione assoluta moltiplicata per
il peso relativo ed espresso in percentuale) e quindi il punteggio complessivo per ogni piattaforma
(dato dalla somma dei punteggi pesati sulle singole caratteristiche tecniche). Le valutazioni comples-
sive permettono quindi di stabilire una graduatoria per le quattro piattaforme.
È da sottolineare che le valutazioni sono state effettuate considerando opportunamente i versi di pre-
ferenza di ogni caratteristica tecnica. Ad esempio, una caratteristica con verso di preferenza decre-
scente quale è il tempo medio di sviluppo, è stata valutata con punteggio pari a 5 se la piattaforma
permette di raggiungere un valore molto basso, viceversa con punteggio pari ad 1 se la caratteristica
assume valori molto elevati.
Valutazioni assolute Valutazioni pesate
Cod. Requisito di sistema Imp. Ass.
Imp. Rel.
XS Wa-
vema-ker
VFront
Xa-tafa-ce
XS Wa-
vema-ker
VFront
Xata-face
16 Tempo medio di sviluppo per applicazioni "lightly customized" 140
5,86% 4 4 2 3 23,42 23,42 11,71 17,57
15 Tempo medio di sviluppo per applicazioni standard 139
5,81% 5 3 5 4 29,07 17,44 29,07 23,25
19 Quantità di funzionalità implementabili con minime configurazioni 139
5,81% 4 5 3 3 23,25 29,07 17,44 17,44
6
Livello di completezza del sistema di data-management "out-of-the-box" 129
5,40% 5 2 4 3 26,98 10,79 21,58 16,19
18 Quantità di funzionalità "out-of-the-box" 127
5,31% 4 2 4 3 21,25 10,62 21,25 15,93
17 Creazione di applicazioni di data-management inte-ramente tramite GUI 124
5,19% 5 2 5 2 25,93 10,37 25,93 10,37
38
Possibilità di impiego di componenti open source o free (es. O.S., IDE, DBMS) 119
4,98% 3 4 4 3 14,93 19,91 19,91 14,93
37 Licenza della piattaforma 108
4,52% 1 5 5 5 4,52 22,58 22,58 22,58
29 Complessità del codice generato 92
3,85% 2 1 4 4 7,70 3,85 15,39 15,39
Benchmarking
85
8 Flessibilità nella creazione di viste o reportistica per-sonalizzata 82
3,43% 4 3 5 2 13,72 10,29 17,15 6,86
27 Modularità delle applica-zioni generate 78
3,26% 5 5 3 3 16,31 16,31 9,79 9,79
22 Scalabilità delle applica-zioni (volumi di dati e/o numero utenti) 72
3,01% 5 3 3 3 15,06 9,03 9,03 9,03
32 Predisposizione allo svi-luppo di funzionalità cu-stom 72
3,01% 3 5 2 3 9,03 15,06 6,02 9,03
34 Sistema cross-platform 72
3,01% 4 4 4 4 12,05 12,05 12,05 12,05
31 Possibilità di richiedere supporto tecnico profes-sionale 70
2,93% 5 4 1 1 14,64 11,71 2,93 2,93
40 Grado di capacità elabora-tiva (CPU) e memoria RAM richieste 59
2,47% 3 3 4 4 7,40 7,40 9,87 9,87
39 Possibilità di installazione distribuita 56
2,34% 5 4 4 4 11,71 9,37 9,37 9,37
33 Facilità di rilascio del codi-ce in ambiente di produ-zione 54
2,26% 2 2 5 5 4,52 4,52 11,29 11,29
36 Indipendenza dal database (scelta tra più DBMS) 54
2,26% 4 4 3 2 9,03 9,03 6,78 4,52
30 Qualità della documenta-zione esistente 49
2,05% 3 3 5 4 6,15 6,15 10,25 8,20
24 Performance lato utente (tempi di risposta) 45
1,88% 5 3 3 3 9,41 5,65 5,65 5,65
5 Facilità di utilizzo del pro-dotto finale per utenti non esperti 41
1,71% 4 4 4 4 6,86 6,86 6,86 6,86
1 Competenza necessaria agli sviluppatori 37
1,55% 2 2 4 4 3,09 3,09 6,19 6,19
20 Maturità della piattaforma (diffusione) 37
1,55% 4 4 1 3 6,19 6,19 1,55 4,64
23 Funzionalità di caching 36
1,51% 4 1 1 2 6,02 1,51 1,51 3,01
28 Facilità di bug-fixing in tempo reale 35
1,46% 1 1 4 4 1,46 1,46 5,86 5,86
9
Presenza di un sistema di autenticazione e di per-mission facilmente confi-gurabile 34
1,42% 5 4 5 4 7,11 5,69 7,11 5,69
10 Presenza del motore di ricerca interno 33
1,38% 4 2 3 4 5,52 2,76 4,14 5,52
26 Programmazione ad og-getti 32
1,34% 5 5 3 3 6,69 6,69 4,02 4,02
3 Formazione specifica per gli sviluppatori 31
1,30% 2 2 4 4 2,59 2,59 5,19 5,19
4 Formazione specifica per gli analisti 31
1,30% 5 2 5 3 6,48 2,59 6,48 3,89
7 Grado di personalizzazio-ne dell'interfaccia standard 31
1,30% 2 4 2 3 2,59 5,19 2,59 3,89
14 Qualità dell'aspetto grafico 28
1,17% 4 4 3 3 4,68 4,68 3,51 3,51
25 Performance in fase di svi-luppo e importazione database 27
1,13% 4 2 3 3 4,52 2,26 3,39 3,39
2 Competenza necessaria agli analisti 22
0,92% 4 2 4 3 3,68 1,84 3,68 2,76
13 Requisito minimo di banda per l'accesso alle applica-zioni generate 18
0,75% 4 3 3 4 3,01 2,26 2,26 3,01
11 HTML ben formato / con- 17 0,71 3 3 3 3 2,13 2,13 2,13 2,13
Benchmarking
86
formità agli standard di accessibilità W3C
%
12 Protocollo impiegato per autenticazione on-line e sessioni private 9
0,38% 4 3 3 3 1,51 1,13 1,13 1,13
35 Presenza di sistemi di si-curezza (antivirus,firewall) 9
0,38% 4 4 4 4 1,51 1,51 1,51 1,51
21 Frequenza di nuove relea-se 3
0,13% 4 4 2 4 0,50 0,50 0,25 0,50
Totali - - 150 127 139 133 382,23 325,55 364,37 324,93
Tabella 6.7 - Risultati del benchmarking tra le soluzioni individuate
I risultati del benchmarking, che si ribadisce essere solo di carattere orientativo, forniscono un
―ranking‖ piuttosto equilibrato. Probabilmente sarebbe poco significativo utilizzare la graduatoria
grezza mentre appare opportuno suddividere le soluzioni in due classi: la prima, contenente eXtra-
Sheet e VFront e la seconda, contenente Wavemaker e Xataface. I dati ottenuti sono rappresentati
graficamente nella figura che segue.
Figura 6.2 - Rappresentazione grafica dei risultati del Benchmarking
6.3 Individuazione dei trade-off
Come spesso accade, il trade-off principale tra eXtraSheet e le altre soluzioni è quello che contrap-
pone i costi e alle performance e all’affidabilità. Infatti, eXtraSheet si differenzia dalle alternative con-
siderate perché già impiegato (e innovato) con successo da una società commerciale (Krescendo
Ltd) da alcuni anni, realizzando volumi di affari notevoli. Al contrario, le altre soluzioni Open Source
risultano meno affidabili e richiederebbero probabilmente una fase di start-up prima di essere impie-
gate nella fornitura di applicativi professionali, ma determinerebbero costi decisamente inferiori ri-
spetto ad eXtraSheet.
eXtraSheet si propone quindi come una soluzione Enterprise proprietaria pronta all’uso, per essere
commercializzata che richiederebbe una fase di start-up molto breve: sarebbe esclusivamente ne-
cessaria la formazione del personale che dovrà curarne lo sviluppo. Inoltre, eXtraSheet verrebbe
supportato dal team della società Krescendo che, soprattutto nelle fasi iniziali, risulterebbe partico-
larmente utile, offrendo supporto e assistenza ai nuovi sviluppatori.
Benchmarking
87
WaveMaker risulta l’unica alternativa identificata in ambito J2EE oltre ad eXtraSheet. La sua filosofia
è parzialmente differente da quella di eXtraSheet e dalle altre soluzioni provate, poiché ogni sviluppo
richiede un re-work, realizzando mediante la GUI le funzionalità di base (es. login, anagrafiche, form,
…) per ogni nuova applicazione. Questo approccio si rivela vincente nello sviluppo di applicazioni in-
teramente custom, dove è necessaria la massima flessibilità.
Considerando la piattaforma PHP, le due soluzioni individuate sono entrambe molto vicine alle esi-
genze del progetto. Xataface offre maggior flessibilità, è più orientata agli sviluppi custom ma è tal-
volta scomoda da configurare e offre una limitata gamma di funzionalità out-of-the-box. Al contrario
VFront è una soluzione ―turn-key‖, con una filosofia identica ad eXtraSheet e facilmente utilizzabile
dall’utente finale. L’affidabilità e la struttura risultano di media qualità ma il progetto Open Source non
sta attualmente riscontrando grandi successi.
La fase di benchmarking può concludersi con la seguente tabella, che riporta sinteticamente le carat-
teristiche di alto livello che contraddistinguono particolarmente le alternative:
Caratteristiche favorevoli Caratteristiche sfavorevoli
eXtraSheet
Affidabilità
Performance
Maturità
Costi (licenza e formazione)
Dipendenza tecnologica da Krescendo
Wavemaker Flessibilità
Programmazione visuale
Non ―out-of-the-box‖
Affidabilità
VFront ―Out-of-the-box‖
Varietà di funzionalità
Ridotta affidabilità
Maturità
Xataface Possibilità di personalizzazione Scarsa attitudine al supporto di appli-
cazioni complesse
Tabella 6.8 - Riepilogo risultati del Benchmarking
Mercato e strategia
88
7 Mercato e strategia
Finora è stato esaminato nel dettaglio l'ambito tecnologico del progetto, valutando le piattaforme ed i
processi coinvolti. Nei prossimi capitoli si provvederà invece ad approfondire l'aspetto manageriale e
strategico, altrettanto critico per il successo del progetto.
7.1 Definizione del mercato e della business idea
Il mercato d’interesse per il progetto richiesto da Cefin Systems risulta estremamente ampio. Il target
è formato da tutte le imprese di medie e grandi dimensioni che necessitano di soluzioni Web-based
personalizzate, in tempi e costi contenuti. Alla prima categoria di potenziali clienti, Cefin Systems in-
tende offrire la piattaforma prescelta per la realizzazione di sistemi informativi ad hoc, anche completi
mentre per le aziende di dimensioni più rilevanti, desidererebbe proporre applicazioni snelle per sco-
pi specifici da affiancare (ed eventualmente integrare) con i sistemi informativi esistenti.
Da quanto detto, il mercato appare piuttosto indefinito ma è possibile porre dei vincoli piuttosto preci-
si:
- Le aziende medie (o occasionalmente piccole qualora avessero processi specifici e dispo-
nessero della capacità di spesa opportuna) devono necessitare di soluzioni specifiche che
non sono disponibili sul mercato e sarebbe eccessivamente costoso realizzare ad hoc se-
condo l’approccio tradizionale.
- Le grandi aziende potenzialmente interessate alle soluzioni di Cefin Systems, dispongono
del sistema informativo aziendale, ma richiedono delle applicazioni flessibili e rapide per
soddisfare bisogni specifici e/o temporanei che il sistema informativo ordinario non è in gra-
do di supportare e lo sviluppo della personalizzazione su di esso in tempi ridotti sarebbe dif-
ficoltosa o non pertinente.
L'idea di business consiste nell'offrire al mercato un servizio completo nel settore delle applicazioni
Web di ultima generazione, proponendo soluzioni "chiavi in mano" e offerte in modalità SaaS. Tutte
le applicazioni saranno basate sulla piattaforma prescelta che consentirà di distinguersi dalla concor-
renza per tempi e costi inferiori, limitando al massimo i re-work. In questa ottica, Cefin Systems in-
tende offrire i seguenti servizi collegati:
1. analisi dei requisiti e studio di fattibilità;
2. progettazione architetturale e funzionale;
3. implementazione (impiegando la piattaforma) con sviluppo di eventuali personalizzazioni;
4. deployment e hosting;
5. formazione del personale;
Mercato e strategia
89
6. manutenzione e supporto tecnico;
7. evoluzione dell'applicazione.
I benefici riscontrabili dal cliente rispetto ad uno sviluppo curato da una software house tradizionale
risulterebbero:
Unico soggetto di riferimento che gestisce l'applicazione a 360°, non comune nel caso di sof-
tware house tradizionali che non prevedono l'hosting e talvolta la manutenzione dopo il peri-
odo di garanzia.
Rapidità di prototipizzazione, fornitura istantanea di demo operative.
Rapidità di sviluppo.
Costi di sviluppo contenuti, che permettono la realizzazione di applicazioni non convenienti
altrimenti
Elevata flessibilità in caso di future modifiche.
Performance adattabili a volumi di traffico crescenti.
A cui si aggiungono gli innumerevoli e già noti vantaggi del modello SaaS.
I mercato geografico di riferimento è principalmente quello italiano e rumeno: nel primo Cefin
Systems è nota da anni nel settore della telematica a servizio dei trasporti mentre nel secondo, oltre
alla presenza di Cefin Systems Romania, sarebbe possibile avvalersi della vasta rete di contatti di
cui dispone il gruppo Cefin in territorio romeno e, inizialmente, non si esclude la possibilità di svilup-
pare soluzioni proprio per alcune aziende del gruppo. Nel caso in cui si dovesse scegliere la piatta-
forma eXtraSheet e, dunque, una partnership più o meno stretta con la società Krescendo, sarebbe
probabile la stipula di un accordo per l’accesso, sotto determinate condizioni, ai network bancari e
consulenziali per i quali Krescendo fornisce soluzioni Web-based da molti anni.
7.2 I potenziali concorrenti
Come anticipato nella procedura di software selection in ambito commerciale, appare che non vi sia-
no molti concorrenti che dispongano di una piattaforma simile a quella ricercata. Questo significa che
tutto dipende dall’ottica di osservazione:
1) Nell’ambito del software Web-based ad hoc (su commessa) esistono numerosissime azien-
de, ed il settore presenta una concorrenza agguerrita, tale da non essere più un mercato ap-
petibile per gran parte delle nuove aziende informatiche.
2) Considerando invece il software Web-based ad hoc basato su piattaforme di alto livello in
grado di generare rapidamente applicazioni fruibili su Web, i competitor scarseggiano. Au-
spicabilmente, la motivazione potrebbe essere la particolare finezza dell’idea di business e la
difficoltà, sino ad alcuni anni fa, di realizzare sistemi tanto flessibili. D’altro canto, la notevole
incertezza e il rischio che la piattaforma riveli scarsa attitudine a soddisfare le esigenze di
Mercato e strategia
90
mercato, spingono tutti gli attori mondiali del software Web-based a concentrare le energie
su piattaforme di basso livello, assimilabili a enormi librerie o framework di programmazione,
che offrono maggiore potenza e flessibilità ma, al contempo, tempi di realizzazione superiori.
I competitor che Cefin Systems troverebbe qualora decidesse di realizzare il progetto sarebbero
Dabble DB e, nel caso non venisse instaurata la partnership per eXtraSheet, la società Krescendo.
Sotto quest’ultima ipotesi, sarebbe proprio la società londinese ad essere il principale concorrente,
avendo già commercializzato ad alcune società del gruppo Cefin applicazioni basate su eXtraSheet.
In ogni caso, vi sarebbero realmente pochissimi concorrenti che offrono soluzioni impiegando le stra-
tegie finora esposte. Il mercato che offre lo sviluppo di applicazioni Web personalizzate è estrema-
mente ―popolato‖ e lo è altrettanto quello che offre applicazioni SaaS standard. Anche effettuando
ricerche sul Web non sono invece state individuate offerte analoghe ad eXtraSheet o Dabble DB.
7.3 I trend del settore
Per reperire informazioni riguardanti la profittabilità del settore interessato dal progetto, è stata anzi-
tutto condotta una ricerca sul mercato del Software-as-a-Service, ricercando soprattutto dati previ-
sionali per gli anni successivi all’eventuale investimento effettuato da Cefin Systems. Nel caso di un
declino del settore, il progetto richiesto sarebbe stato estremamente rischioso.
La maggioranza dei report derivanti da dati analitici si focalizza più sui clienti che sui fornitori, con-
centrandosi su come le imprese esternalizzano determinate aree del comparto tecnologico, toccando
modelli quali ASP e cloud-computing, tralasciando le imprese che erogano i suddetti servizi.
I documenti utili al presente studio, risultano invece le analisi di due note società internazionali di
consulenza, il cui prezzo di accesso, però, è proibitivo. Per questi documenti, i dati contenuti nei rela-
tivi abstract sono comunque sufficienti a fornire un’idea generale.
Analisi di IDC
Il report di IDC (International Data Corporation) denominato ―Worldwide Business Analytics Software-
as-a-Service Forecast, 2008-2013‖, proposto a 4.500 $, prevede tra il 2008 ed il 2013 una crescita
del mercato SaaS caratterizzata da un CAGR (Compound Annual Growth Rate) del 22,4% a livello
globale, che è circa il triplo rispetto al mercato del software complessivo. IDC prevede inoltre che il
numero di utenti business del SaaS sarà in forte crescita mentre più prudenti sono le previsioni in
merito ai ricavi derivanti dalle vendite effettuate in tale comparto, che non riesce a guadagnare terre-
no rispetto al software tradizionale. La società di consulenza delinea i fattori che supporteranno la
crescita del mercato SaaS:
1) Ridotti investimenti in capitale, che permettono ad una divisione aziendale di sottoscrivere un
contratto SaaS impiegando budget ordinario.
Mercato e strategia
91
2) Le risorse IT aziendali sono solitamente ridotte e non c’è tempo sufficiente per realizzare,
acquistare o valutare soluzioni per problemi di business specifici.
3) Le applicazioni SaaS sono sempre più configurabili piuttosto che personalizzabili, al fine di
soddisfare al meglio le esigenze di business.
Una ulteriore analisi condotta da IDC (gennaio 2009), basata su indagini ed interviste a clienti, affer-
ma che la crisi economica provvederà ad accelerare le prospettive di crescita del settore SaaS, in
grado di fornire soluzioni ben dimensionate e chiavi in mano. Molti clienti business preferiranno infatti
utilizzare applicazioni e pagare in base all'utilizzo attuale, senza investire in capacità future. Altre in-
formazioni interessanti che emergono dallo studio sono:
Dalla fine del 2009, il 76% delle aziende statunitensi utilizzeranno almeno un'applicazione
business in modalità SaaS.
La percentuale delle aziende statunitensi che pianificano una spesa di almeno 25% del bu-
dget IT saranno il 45% nel 2010 (contro il 23% del 2008)
Mentre la domanda del SaaS è più marcata nel Nord America, lo sviluppo è ora notevole an-
che in altre zone (quali Europa e Medio Oriente), che raggiungeranno una quota del 35% sui
ricavi mondiali.
I fornitori SaaS evidenziano la tendenza a problemi di liquidità dovute ai pagamenti dilaziona-
ti dei clienti che causa talvolta difficoltà ad investimenti infrastrutturali in nuova capacità o so-
luzioni software per nuovi clienti.
Analisi di Gartner
Il secondo report è realizzato a cura della società Gartner: ―Market Trends: Software-as-a-Service,
Worldwide, 2008-2013‖ e proposto al prezzo di 2.495 $. Il CAGR stimato da Gartner per il settore
SaaS tra il 2009 e il 2013 risulta pari al 19,4%, oltre il triplo del CAGR previsto per l’intero mercato
del software, pari a 5,2%.
Analizzando un altro paper elaborato da Gartner che valuta le performance in termini di ricavi nel
mercato SaaS, si ottiene conferma della crescita del mercato del Software-as-a-Service tra l'anno
2008 e 2009 pari al 17,7% circa. Il mercato è visto in crescita costante fino al 2013, quando i ricavi
del 2009 (circa 6,5 miliardi di dollari) raddoppieranno ampiamente, raggiungendo i 14 milioni di dolla-
ri.
"L'adozione del SaaS continuerà a crescere ed evolversi soprattutto nei settori Enterprise" afferma
Sharon Mertz, research director in Gartner. "La composizione del panorama SaaS è in evoluzione
poiché i vendor continuano ad estendersi localmente, arricchire i contratti in corso e offrire sempre
più soluzioni verticali e specializzate".
Il segmento dei sistemi CCC (Content, Communication e Collaboration) e CRM (Customer Relation-
ship Management) continueranno ad avere i volumi più elevati ma tutto il settore è previsto in cresci-
ta. In figura è riportata l’analisi dei ricavi negli anni 2008-2009 suddivisi per segmenti.
Mercato e strategia
92
Figura 7.1 - Performance in termini di ricavi del mercato SaaS (Gartner 2009)
In conclusione, le previsioni per il Software-as-a-Service sono estremamente incoraggianti e non ap-
paiono ostacoli nel medio termine. Inoltre, la crescente specializzazione delle applicazioni SaaS pre-
vista dagli analisti potrebbe trovare una risposta vincente impiegando la piattaforma ricercata da Ce-
fin Systems e consentirebbe margini più elevati rispetto ai normali provider SaaS.
7.4 La profittabilità: analisi di Porter
La profittabilità del settore SaaS, con particolare riferimento al segmento interessato dal progetto, è
stata analizzata impiegando lo strumento delle cinque forze di Porter che permette di esaminare gli
aspetti rappresentativi dell’appetibilità del mercato e le azioni strategiche da intraprendersi per effet-
tuare l’ingresso.
7.4.1 Grado della competitività interna
L’analisi della competitività interna permette di dedurre se il grado di rivalità all’interno del mercato è
più o meno elevato: tanto più è alto, tanto più si riduce la profittabilità, in quanto gli attori che operano
nel mercato sono più propensi a competere per l’ottenimento dei profitti. Si riportano di seguito le ca-
ratteristiche da valutare.
Concentrazione del mercato: da quanto esaminato sinora, il numero di competitor è altamen-
te significativo se si considerano i fornitori di soluzioni SaaS mentre, restringendo il campo
alle sole aziende dotate di piattaforme simili a quella ricercata, il numero di competitor diven-
ta pressoché nullo.
Grado di differenziazione dei concorrenti: i pochi competitor (principalmente Dabble DB, e-
XtraSheet o, ipotizzando che esistano, altre piattaforme proprietarie) possono avvalersi di
Mercato e strategia
93
piattaforme piuttosto omogenee, almeno per quanto percepito dal cliente. Si può affermare
quindi che non è possibile realizzare un alto grado di differenziazione dell’offerta.
Condizioni della domanda: dai dati riportati nel paragrafo precedente, il tasso di crescita del
settore è estremamente positivo (intorno al 20%) determinando quindi una continua espan-
sione della domanda che contribuirà ad attenuare le pressioni competitive tra le imprese.
Barriere all’uscita: in generale i fornitori SaaS, non devono sostenere investimenti specifici
elevati. I componenti hardware possono essere demandati a società di hosting senza alcuna
necessità di investimento mentre il software (specie se si scelgono molti moduli open sour-
ce) non richiede investimenti eccessivi anche se nel tempo, il perfezionamento e lo sviluppo
di funzionalità potrebbe diventare un ostacolo per l’uscita del mercato.
È possibile concludere che tale forza risulta ridotta: sul mercato vi è un numero limitato di concorrenti
che, pur proponendo un servizio omogeneo, convivono con un andamento positivo della domanda e
con barriere all’uscita di media entità.
7.4.2 Barriere all’entrata
La presenza di barriere all’entrata riducono la minaccia di potenziali nuovi competitor intenzionati ad
entrare sul mercato. Più è marcata la presenza di barriere, più aumenta la profittabilità del settore.
Economie di scala e scopo: considerando la piattaforma, le economie di scala (diminuzione
del costo medio unitario di produzione) e le economie di scopo (risparmio derivante dalla
produzione congiunta di prodotti differenti con le medesime risorse) sono entrambe rilevanti.
Quindi, più la piattaforma risulta completa e performante, più i risultati sono efficaci e ottenuti
con effort ridotti.
Costi di start-up, comprendono: i costi del personale operativo che avvia le nuove attività, i
costi di assunzione e di addestramento del nuovo personale, i costi di hardware e software
ed i costi di marketing sostenuti per il lancio della nuova attività. Come affermato in prece-
denza, tali costi non sono eccessivi inizialmente ma non sono trascurabili.
Brand loyalty: si ipotizza che la fedeltà ad un fornitore SaaS sia di media entità, ma certa-
mente presente se questo si distingue per professionalità ed affidabilità.
Curva di apprendimento: l'apprendimento da parte del personale dipende da capacità perso-
nali (l’attitudine e la motivazione), da fattori endogeni (caratteristiche del lavoro) e da fattori
esogeni (condizioni al contorno). Tralasciando le capacità personali e le condizioni di contor-
no, si può affermare che la curva di apprendimento non è troppo rigida: si tratta infatti di atti-
vità di sviluppo software piuttosto standard, caratterizzate dalla classica curva ad S.
In conclusione, le barriere all’entrata sono di medio livello e permettono di mantenere una buona pro-
fittabilità.
Mercato e strategia
94
7.4.3 Potere dei fornitori
Nel caso in esame, i fornitori possono essere suddivisi in due tipologie:
1. Fornitori di ―commodity‖, cioè servizi caratterizzati da una elevata maturità e quindi con nu-
merose aziende in grado di fornirli. Tra questi, vi è certamente l’hosting dell’hardware, le te-
lecomunicazioni e, in generale, le forniture di hardware e di moduli software non ―core‖.
Questi attori dispongono di un potere estremamente ridotto nei confronti del cliente.
2. Fornitori di componenti software ―core‖, cioè fondamentali per la piattaforma prescelta. Nel
caso di eXtraSheet, il potere del fornitore Krescendo sarebbe molto elevata nei confronti di
Cefin Systems mentre scegliendo soluzioni open source il problema verrebbe pressoché e-
liminato. In ogni caso, qualunque sia la piattaforma prescelta, gli switching costs possono
essere notevoli, specie se i livelli di astrazione dal database sono numerosi.
Il potere dei fornitori è quindi da ritenersi di media entità, poiché, se tecnicamente è possibile cam-
biare fornitore (quindi piattaforma), la procedura di switch non sarebbe certamente agevole.
7.4.4 Potere dei clienti
Se gli acquirenti sono dotati di elevato potere contrattuale, i profitti del fornitore rischiano nel tempo
una sensibile riduzione. Considerando i seguenti criteri:
Concentrazione del cliente: il numero di imprese acquirenti è potenzialmente molto elevato,
di conseguenza questo aspetto non offre all’acquirente potere considerevole.
Differenziazione dell’offerta: l’offerta sul mercato risulta piuttosto omogenea, conferendo al
cliente maggior potere contrattuale.
Qualora i clienti decidessero di rivolgersi in itinere ad un’altra azienda, i costi risulterebbero
realmente consistenti. Commissionando ad una nuova azienda lo sviluppo dell’applicazione,
il cliente dovrebbe sostenere nuovamente tutte le fasi di sviluppo (analisi dei requisiti, proget-
tazione, sviluppo, testing, formazione, …). Se tuttavia questo onere può risultare ridotto im-
piegando una piattaforma simile a quelle sinora esaminate, il reale problema si presentereb-
be se il precedente sistema era già in uso: la migrazione dei dati dal precedente al nuovo
fornitore non sarebbe semplice e il primo non avrebbe interesse a svolgere la procedura con
la massima cura. Gli elevati costi di switch riducono considerevolmente il potere del cliente.
Informazioni detenute dal cliente: l’azienda cliente dovrà collaborare con il fornitore per la
comunicazione di informazioni utili al raggiungimento del mutuo obiettivo di realizzare
l’applicazione con successo. Anche questo criterio non conferisce al cliente alcuna superiori-
tà.
Mercato e strategia
95
Integrazione verticale del cliente: poco credibile la minaccia di integrazione a monte da parte
delle aziende clienti. La maggioranza non disporrebbe di know how e infrastrutture necessa-
rie e, comunque, dovrebbe sopportare gli switching costs già individuati.
In conclusione, se da un lato non esiste una differenziazione dell’offerta nel mercato, gli elevati swi-
tching cost, la ridotta concentrazione del cliente e la bassa probabilità di integrazione conferisce al
cliente un potere piuttosto esiguo.
7.4.5 Prodotti sostituti
Al momento i prodotti sostituti risultano pressoché assenti. Le alternative per un’impresa che neces-
sita di un’applicazione di business potrebbero essere il ricorso allo sviluppo classico, cioè commis-
sionando lo sviluppo di software (SaaS o tradizionale) a software house per poi installarlo presso ri-
sorse hardware proprietarie o in hosting. Questo approccio risulta tuttavia estraneo alle tendenze at-
tuali e conveniente solo in casi particolari.
Altrettanto inverosimile è la nascita a breve di soluzioni contemporaneamente flessibili e user-friendly
da permettere al cliente lo sviluppo interno di applicazioni specifiche, dopo aver comunque svolto le
fasi minimali di progettazione.
7.4.6 Conclusioni
L’analisi di Porter permette di affermare la presenza di una minaccia credibile di nuovi entranti (bar-
riere all’ingresso relativamente contenute) e di una media competitività nel settore che sono tuttavia
controbilanciate dalla inesistenza di prodotti sostituti e da un basso potere contrattuale soprattutto
per la clientela. Si può quindi concludere che il segmento di mercato è attrattivo e probabilmente ca-
ratterizzato da un buon livello di profittabilità.
7.5 Analisi resource based
Attraverso l’analisi Resource based sono stati valutati quali risorse e competenze della struttura or-
ganizzativa possano determinare un vantaggio competitivo sostenibile, ossia quali costituiscano un
punto di forza distintivo e difendibile (importanza e produzione di valore, rarità, non perfetta imitabilità
e non sostituibilità).
Nell’ambito delle risorse tangibili non vi sono particolari elementi che possano offrire un vantaggio
sostenibile. Infatti, qualunque componente hardware e tutti i servizi connessi risultano oggi ampia-
mente diffusi e accessibili a costi molto contenuti. A livello di risorse finanziarie, seppur siano neces-
sari investimenti di media entità, una buona capacità di credito o di autofinanziamento non sono par-
ticolarmente di valore nel tempo.
Mercato e strategia
96
Le risorse più importanti per Cefin Systems, qualora realizzasse il progetto in esame, risulterebbero
di due categorie:
1) Personale: un team professionale e preparato può essere la chiave vincente per differenziar-
si dalla concorrenza. È necessario disporre di dipendenti con adeguato know how, buone
capacità di analisi e sviluppo e caratterizzati da impegno e lealtà. Questo si traduce
senz’altro nella realizzazione di soluzioni professionali e affidabili, differenziandosi dai con-
correnti per la qualità dei servizi offerti.
2) Fidelizzazione del cliente e reputazione: raggiungere una buona reputazione con clienti, for-
nitori e finanziatori è estremamente importante. Questo è realizzabile puntando, oltre che
sulla customer care, sulla qualità del management, dei prodotti e dei servizi, sulla capacità di
innovazione e sulla solidità dei risultati. Se raggiunti, tali obiettivi garantirebbero all’azienda
un vantaggio competitivo sostenibile nei confronti dei competitor.
Dall’analisi emerge come le risorse umane siano la fonte primaria del vantaggio competitivo sosteni-
bile e quindi la loro gestione è da tenere in forte considerazione nell’elaborazione della strategia a-
ziendale. Puntando inoltre sulla loyalty dei clienti e sull’immagine e reputazione della società, sarà
possibile acquisire nuovi clienti oppure raggiungere clienti già serviti in passato per esigenze diffe-
renti. È però fondamentale che le suddette qualità siano ben sfruttate e coltivate in modo continuati-
vo.
7.6 Strategia di marketing e sales
In seguito allo studio del mercato e dell’idea di business in termini di potenzialità nel creare valore e
mantenere vantaggi competitivi nel tempo si giunge a valutare quali sarebbero le scelte di marketing
più idonee.
Il servizio SaaS B2B offerto da Cefin Systems è in realtà composto da una serie di servizi ben defini-
ti:
- Consulenza al cliente.
- Sviluppo della soluzione software idonea (definizione dei requisiti sulla base della fase pre-
cedente, progettazione, sviluppo e testing).
- Formazione del personale.
- Garanzia e servizio di supporto post-vendita (helpdesk tecnico).
Il servizio offerto è quindi una formula ―all-inclusive‖ che fornisce al cliente il sistema ―chiavi in mano‖,
senza alcun investimento di quest’ultimo in hardware o personale interno.
Mercato e strategia
97
La strategia di prezzo prevista è quella tipica dei servizi SaaS, che prevede una quota iniziale fissa
per lo sviluppo della soluzione e, quindi, canoni periodici (tipicamente mensili) che includono voci
quali hosting e supporto tecnico.
In particolare, la definizione operativa delle tariffe potrebbe seguire l’approccio ―costo + mark-up‖,
quest’ultimo fissato indicativamente intorno al 20÷30%. Tale strategia potrebbe risultare più com-
plessa nel caso venga scelta la piattaforma eXtraSheet, infatti, la tipologia di remunerazione dovuta
a Krescendo, potrebbe rendere più conveniente per Cefin Systems traslare alcune componenti di co-
sto dal canone periodico al prezzo iniziale richiesto al cliente o viceversa.
Indicativamente il prezzo medio di un progetto di dimensioni ridotte, ottenuto da dati storici di Cefin
Systems e Krescendo, si aggira intorno ai 5.000 € per la quota iniziale di analisi e sviluppo e circa
200 €/mese a titolo di canone periodico. In tabella è riportato un esempio.
# Subject Price Detail
1 Project Implementation 4.800,00 €
Implementation of ad-hoc application
following the Functional Specifications
agreed. Includes 1 day of training.
2 License & Support Service 150,00 € 1 Month Service fee. Support of max 1
day per month is included.
3 Optional consultancy to identify market solu-
tions to support other standard processes 1.950,00 € 3 days of Analyst
Tabella 7.1 - Esempio di tariffe per progetto ad hoc di dimensioni ridotte
Anche l’analisi sulle tempistiche necessarie per il completamento di un progetto di dimensioni ridotte
dimostra la vantaggiosità della piattaforma, che consente approssimativamente un risparmio del 40%
per applicazioni non eccessivamente complesse. A ciò conseguono importanti riduzioni in termini di
costo e quindi del prezzo finale offerto al cliente.
Non sarà da trascurare inoltre la strategia promozionale per far conoscere la competitività dei servizi
offerti con la nuova piattaforma. Anzitutto sarà necessario realizzare brochure, depliant e pubbliciz-
zare i servizi sul sito Web, fornendo eventualmente applicazioni demo liberamente accessibili.
Poiché ci si rivolge specialmente a realtà di medie dimensioni, può risultare opportuno avviare una
campagna pubblicitaria su radio locali (ad esempio della provincia di Torino), in fasce orarie appro-
priate per utenti business (ad esempio, 7:30-9:30 e 18:00-20:00). L’attività di commercializzazione
dovrà inoltre essere condotta in maniera opportuna dai commerciali di Cefin Systems, che dovranno
conoscere bene la piattaforma a livello funzionale per essere in grado di ascoltare e proporre il clien-
te con successo. Eventualmente, potrebbe essere conveniente partecipare ad alcune fiere per dif-
fondere ulteriormente le soluzioni offerte. Maggiori dettagli sono riportati in tabella.
Mercato e strategia
98
# Subject
Ammontare
annuo
1 Materiale pubblicitario 4.000 €
2 Personale dedicato 30 giorni-uomo
3 Campagne pubblicitarie 7.000 €
Tabella 7.2 - Spese di marketing annue preventivate
Per un servizio tecnologico come quello che si intende proporre, la relazione diretta con i clienti è il
fattore determinante per garantire redditività e successi duraturi. Il processo di distribuzione delle so-
luzioni sviluppate per il singolo cliente dovrà essere curato dalla figura commerciale di Cefin
Systems, che fungerà da intermediario (o interfaccia) tra il comparto tecnologico e la clientela e avrà
collegamenti diretti con il management aziendale.
7.7 Organizzazione prevista
La nuova divisione necessiterebbe di quattro figure professionali che inizialmente (oppure in caso di
progetti di dimensioni limitate) potrebbero ridursi a tre. Sono infatti necessari uno o più sviluppatori,
un project manager e una figura in grado di interagire con il cliente e, al contempo, svolgere l’analisi
dei fabbisogni e redigere le specifiche funzionali. Questa figura può inizialmente essere un analista
mentre, per progetti più complessi, sarebbe opportuno suddividere il ruolo commerciale da quello
analitico/progettuale.
Agli sviluppatori verrebbero assegnati tutti i ruoli tecnici, che spaziano tra la supervisione e la gestio-
ne delle risorse hardware in loco ed in hosting, la progettazione architetturale e lo sviluppo della so-
luzione, sulla base delle specifiche ricevute dagli analisti e, infine, l’erogazione del supporto tecnico
in caso di problemi o malfunzionamenti segnalati dal cliente.
Gli analisti coprirebbero il ruolo di studio dei requisiti del cliente e la mappatura funzionale nelle solu-
zioni erogabili tramite la piattaforma prescelta, fornendo agli sviluppatori le specifiche per
l’implementazione.
Il project manager avrebbe l’incarico di supervisionare e gestire il progetto, assicurando un adeguato
sviluppo dell’idea di business e interagendo con il management aziendale.
Il responsabile commerciale, oltre a definire insieme al project manager le strategie di marketing,
svolgerebbe operazioni di scouting (ricerca di nuovi contatti che potrebbero diventare clienti) e tutte
le attività a diretto contatto con i clienti acquisiti o esistenti (visita ai clienti, presentazioni delle solu-
zioni, dimostrazioni, gestione dell'ordine con la conseguentemente realizzazione dell’offerta commer-
ciale).
Mercato e strategia
99
Figura 7.2 - Organizzazione proposta per la nuova divisione
Valutazioni economiche
100
8 Valutazioni economiche
Dopo un’analisi rivolta ad individuare se il progetto potesse trovare riscontro positivo sul mercato, ri-
sulta necessario definire meglio quali sarebbero, sotto il profilo strategico-organizzativo, le alternative
per l’implementazione del progetto.
Poiché il numero di scenari potenziali (combinazione di scelte principalmente tecniche ed organizza-
tive) sarebbe piuttosto elevato, si è deciso di operare una selezione in base al grado di "strategic fit",
cioè il livello di coerenza tra le varie scelte per realizzare al meglio la strategia, determinando tre al-
ternative differenti tra loro ma presumibilmente concorrenziali.
Si è quindi passati a valutare i tre scenari in termini di convenienza all’investimento, pur non dispo-
nendo degli importi precisi e ricorrendo spesso a stime indicative.
8.1 Scenari selezionati
8.1.1 Stretta partnership con Krescendo
Il primo scenario proposto, d’ora in poi denominato ―Scenario A‖, è probabilmente quello maggior-
mente conservativo. Si propone infatti di consolidare la collaborazione con la società Krescendo che
detiene eXtraSheet, diventando un partner tecnico e commerciale.
Tale strategia conferirebbe a Cefin Systems un rischio molto ridotto, poiché non sono necessari in-
vestimenti eccessivi dato che verranno impiegati i server di produzione Krescendo e internamente
saranno esclusivamente necessari uno o due server di test. La fase di avviamento risulterà inoltre
piuttosto semplice, disponendo della formazione e del supporto tecnico offerto da Krescendo.
Anche a livello commerciale, gli sviluppi iniziali potrebbero essere concordati per clienti esistenti di
Krescendo e man mano che la capacità aumenta, Cefin Systems potrebbe costruire in autonomia la
propria rete commerciale. Coerentemente a questa scelta, l’investimento in personale potrebbe es-
sere altrettanto esiguo, assumendo inizialmente una sola figura di analista/sviluppatore che acquisi-
rebbe le competenze da Krescendo e diventare la figura tecnica di riferimento.
Gli aspetti chiave da definire risulterebbero invece le modalità di tariffazione, per evitare che il potere
contrattuale di Krescendo comprimesse eccessivamente i profitti di Cefin Systems, rendendo
l’investimento non più conveniente. Oltre ad un canone fisso, le tariffe potrebbero essere di varie ti-
pologie:
In base all’utilizzo del sistema, considerando ad esempio il numero di record per le applica-
zioni standard di data management mentre, per applicazioni più complesse, il numero di u-
Valutazioni economiche
101
tenti abilitati o altri indicatori che rappresentino la complessità o il traffico generato
dall’applicazione.
Royalty sulle vendite, richiedendo una percentuale sul fatturato delle applicazioni erogate a
clienti che permetterebbe una cessione del margine a Krescendo.
In ogni caso, si aggiungerebbero i costi dovuti a Krescendo qualora si richiedano sviluppi, formazio-
ne o supporto tecnico oltre limiti prefissati.
In conclusione, lo scenario A è quello che presenta un rischio molto ridotto, ma la piattaforma ed i
servizi erogati da Krescendo avrebbero costi presumibilmente elevati e, soprattutto nella fase inizia-
le, i margini sarebbero scarsamente soddisfacenti.
8.1.2 Soluzione ponderata
Alcuni svantaggi emersi nel precedente scenario possono essere compensati nel seguente, denomi-
nato ―Scenario B‖, che propone una maggior autonomia pur mantenendo la collaborazione con Kre-
scendo. Si prevederebbe infatti di concordare con Krescendo l’acquisizione della licenza di eXtra-
Sheet per il rilascio dei file binari da installarsi ed utilizzarsi su server propri. Questa soluzione porte-
rebbe quindi Cefin Systems a stipulare contratti di hosting a proprio nome e lo sviluppo di applicazio-
ni basate su eXtraSheet con maggior autonomia. Si intende comunque che lo sviluppo di eXtraSheet
―core‖ rimarrebbe in esclusiva a Krescendo che periodicamente fornirà a Cefin Systems nuove relea-
se.
Rimane invariata la facoltà delle due società di accordarsi anche per finalità commerciali, permetten-
do a Cefin Systems l’accesso alla rete commerciale Krescendo e, viceversa, a Krescendo la possibi-
lità di instaurare nuovi contatti con aziende clienti di Cefin Systems.
In termini di personale, la soluzione più idonea per questo scenario richiederebbe l’assunzione di un
dipendente full-time in qualità di responsabile tecnico e un secondo sviluppatore junior magari a
tempo parziale. In caso di necessità, Krescendo potrebbe comunque offrirsi di coprire picchi di do-
manda, offrendo i propri sviluppatori a tariffe giornaliere prestabilite.
La tariffazione più appropriata risulterebbe in questo caso un canone annuale per la licenza a cui si
sommano servizi occasionali, quali supporto tecnico straordinario e sviluppi espressamente richiesti
da Cefin Systems.
Lo scenario ibrido è dunque idoneo ad offrire maggiore autonomia a Cefin Systems, in particolare se
i volumi di vendita aumentano considerevolmente, poiché a Krescendo dovrà esclusivamente ricono-
scere la licenza sulla piattaforma. Al contrario, in caso di una stagnazione delle vendite, il costo fisso
della licenza potrebbe rendere negativa la profittabilità dell’investimento.
Valutazioni economiche
102
8.1.3 Scenario autonomo
Il presente scenario, definito come ―Scenario C‖, risulta il più rischioso in termini di investimento ini-
ziale ma, in caso di successo, potrebbe realmente diventare il più conveniente. Questi prevede infatti
di avviare uno sviluppo completamente autonomo, scegliendo una delle piattaforme Open Source
disponibili invece di eXtraSheet.
Lo strategic fit per questa opzione prevede di adottare una piattaforma Open Source ed investire ini-
zialmente il tempo necessario per portarla ad un livello idoneo alla commercializzazione. Al termine
della fase di revisione, sarebbe possibile la commercializzazione impiegando server interni e propo-
nendosi ad aziende di dimensioni limitate che richiedono applicazioni non particolarmente critiche. In
tal modo risulterebbe possibile avviare le prime vendite e, al contempo, completare i test.
Raggiunta la maturità, sarebbe quindi auspicabile esternalizzare il servizio di hosting ed erogare i
servizi con una strategia simile ad eXtraSheet.
I vantaggi del presente scenario si concretizzerebbero in seguito alla fase di avviamento, quando i
margini derivanti dalla commercializzazione non verrebbero più intaccati dalle fee dovute a Krescen-
do nei precedenti scenari. Al contempo, i possibili vincoli derivanti dalla licenza Open Source GPL
(General Public License), con la quale sono distribuite la maggior parte delle piattaforme considera-
te, non sarebbero stringenti: la distribuzione del codice sviluppato per innovare la piattaforma e rea-
lizzare soluzioni personalizzate non è richiesta se queste sono erogate in modalità SaaS e non con-
segnate al cliente per l’installazione su hardware proprio. Questo risulterebbe un vero vantaggio che
permetterebbe a Cefin Systems di proteggere gli sviluppi effettuati ed evitare l’accesso a potenziali
competitor.
La necessità di personale risulterebbe più consistente rispetto ai casi precedenti, poiché l’assenza di
un supporto tecnico qualificato potrebbe deteriorare notevolmente le performance, specie nei primi
periodi di fornitura. Si ipotizza l’impiego di uno sviluppatore senior e uno sviluppatore junior per la fa-
se di sviluppi preliminari e altri 1-2 sviluppatori a regime.
La scelta di una piattaforma diversa da eXtraSheet risulterebbe tuttavia penalizzante nella previsione
futura di internalizzare il prodotto Sateltrack, attualmente sviluppato da Krescendo condividendo gran
parte della tecnologia di eXtraSheet, a partire dal framework uView.
In sintesi, lo scenario autonomo è altamente rischioso e richiede capacità di investimento più consi-
derevoli rispetto ai precedenti ma le potenzialità sarebbero molto più rilevanti e l’investimento ver-
rebbe ricompensato tanto più rapidamente quanti saranno i nuovi clienti.
Valutazioni economiche
103
8.2 Piani di investimento
8.2.1 Investimenti hardware
Gli investimenti in infrastruttura hardware e nel software risultano l’unica ma indispensabile spesa da
effettuarsi immediatamente, ad inizio progetto. Poiché caratterizzati da bassa aleatorietà, si procede
ad una definizione piuttosto precisa di queste voci.
Riguardo gli scenari individuati, gli investimenti in infrastruttura hardware (e anche software) interna
risultano crescenti, poiché nel primo scenario saranno necessarie esclusivamente una o due posta-
zioni di sviluppo, mentre nei casi B e C sono richieste risorse aggiuntive (ulteriori postazioni e server
interni principalmente per testing e backup).
Come già individuato durante l’analisi degli strumenti impiegati dalla società Krescendo, si ipotizza
l’impiego delle seguenti risorse hardware, che sono state sovradimensionate rispetto a quelle posse-
dute dalla predetta azienda al fine di prolungare la vita delle apparecchiature stesse e garantire per-
formance superiori.
La postazione di sviluppo proposta sarebbe dotata della seguente configurazione hardware ed è una
delle soluzioni più vantaggiose considerando il rapporto performance/costi:
Q.ty Item
1 Intel Core i7 LGA1366 920 2.66GHz BOX
1 Gigabyte GAEX58UD3R S1366
1 Memory OCZ Platinum PC310666 Tri Channel DDR3 6GKit
1333MHz
1 XFX 4650 600M 512M DDR2
2 WESTERN DIGITAL CAVIAR R3 320GB 16MB WD3202ABYS
1 Cooler Master RC 690 XCALADE
1 CORSAIR 550W CMPSU550VXEU
1 Pioneer DVR216DBK Nero bulk Sata
1 Western Digital Caviar GP 1TB WD10EADS Sata2 32Mb
Tabella 8.1 - Configurazione hardware proposta per postazione di sviluppo
Il prezzo finale della configurazione riportata in tabella si aggira intorno ai 900,00 Euro, IVA inclusa,
riferito al periodo settembre 2009. Si osserva che la soluzione sarebbe basata sulla nuova genera-
zione di processori Intel i7, Quad-core, dotata di prestazioni eccezionali e quindi una previsione di
ottima durata nel tempo. Anche la qualità dei dischi è notevole ed è previsto un controller RAID con
due dischi ad alte prestazioni oltre ad un disco più capiente (Serial ATA 2 da 1 TB) per i backup. In
alternativa sarebbe possibile una configurazione basata su tecnologia AMD (ad esempio, CPU AMD
Valutazioni economiche
104
Phenom II X4 940), meno performante rispetto alla precedente ma paragonabile, che permetterebbe
di ridurre la spesa a circa 700,00 Euro.
Volendo orientarsi a soluzioni già disponibili sul mercato, quindi PC già assemblati da vendor di
componenti informatici, si può ad esempio citare quello riportato nella tabella sottostante:
PC MULTIMEDIA S Q9550 2.83GHZ+6GB+1.5TB+GTS250/1GB
DDR3+WIFI
Processore: INTEL Core2 QUAD Q9550 2.83GHz/1333/12MB cache
Memoria RAM: 6GB DDR2/800 Full Brand Kingston (3x2GB)
Hard Disk: 1.5TB 7200 rpm 32Mb cache SATA II
Scheda Madre: ASUS P5QL-E iP43
FSB1600+2xPCIE+Sata2+2xFirewire+Raid
Scheda Grafica: GeForce GTS250 1GB DDR3+DVI+TVOUT+HDMI
Masterizzatore DVD+CardReader 20in1: Dual Layer 20X 8.5GB
Scheda audio e Porte: 5.1+2xFirewire , 8xUSB2.0
Scheda WiFi: Scheda PCI interna WiFi 108Mbit
Case: Case CoolerMaster CM690 + 3 x USB2.0+Firewire su parte
superiore del case, ideale per configurazioni SLI, con 3 ventole si-
lent+Alimentatore Tecnoware PROSILENT 600W Black con ventola
14cm silent
Garanzia: 2 ANNI ON CENTER
Prezzo: 799,00 EUR (IVA inclusa)
Vendor: Computer City (http://www.computercityhw.it)
Tabella 8.2 - Esempio di configurazione hardware già disponibile sul mercato
Ricercando un sistema più performante, basato su processore Intel Core i7 e RAM DDR3, si potreb-
be scegliere quello indicato nella seguente tabella.
PC Multimedia S Core i7 860 2.8GHz+6GB+1.5TB+GTS250/1GB
DDR3+WiFi
Processore: INTEL Core i7 860 2.8GHz/1333/8MB cache/SK 1156
Memoria RAM: 6GB DDR3/1333 Full Brand Kingston (3x2GB)
Hard Disk: 1.5TB 7200 rpm 32Mb cache SATA II
Scheda Madre: GIGABYTE/ASUS P7P55D iP55+Sata II
Raidx6+eSata
Scheda Grafica: GeForce GTS250 1GB DDR3+DVI+TVOUT+HDMI
Masterizzatore DVD+CardReader 22in1: Dual Layer 22X 8.5GB
Scheda audio e Porte: Sorround 7.1+2xFirewire+14xUSB2.0+GbLan
Scheda WiFi: Scheda USB2.0 WiFi 108Mbit
Case: Case CoolerMaster CM690 + 3 x USB2.0+Firewire su parte
superiore del case, + eSata, ideale per configurazioni SLI, con 4 ven-
tole silent+Alimentatore Tecnoware PROSILENT 600W Black con
ventola 14cm silent
Valutazioni economiche
105
Garanzia: 2 ANNI ON CENTER
Prezzo: 999,00 EUR (IVA inclusa)
Vendor: Computer City (http://www.computercityhw.it)
Tabella 8.3 - Secondo esempio configurazione hardware già disponibile sul mercato
A tutte le alternative indicate si aggiungerebbero infine uno o due monitor (LCD 19’’) per ogni posta-
zione, ad esempio il modello seguente, offerto dallo stesso vendor dei PC.
SAMSUNG LCD 18.5" SM-933SN 1360x768 5ms 250 cd/m2
Modello: MSM-933SN TFT LCD 18,5" WIDE, 0,285x0.285 mm
Luminosità: 250 cd/m2
Contrasto: 1000:1
Contrasto dinamico: 50000:1
Angolo visuale: 170°/160°
Risoluzione max: 1360x768
Tempo di risposta: 5ms
Dettaglio cromatico: 16.7 milioni
Informazioni aggiuntive: alimentatore integrato, auto-
spegnimento, cornice nero smaltata, Microsoft Vista Certified
Codice prodotto:LS19CMYKFNA/EN
Prezzo: 139,00 EUR (IVA inclusa)
Vendor: Computer City (http://www.computercityhw.it)
Tabella 8.4 - Monitor LCD proposto
Considerando ora l’investimento nel server, che inizialmente è più che sufficiente in una sola unità
per tutti gli scenari proposti, è possibile seguire le indicazioni fornite da Krescendo. Il vendor abituale
della società londinese è WOC (World of Computers, con sede a Cambridge, UK), specializzato nella
fornitura di componenti hardware di classe Enterprise. La configurazione suggerita da Krescendo è
riportata in tabella.
BX80602E5520 — XEON E5520 2.26GHZ 5.86GT/S (£ 282)
S5520HC — Intel Hanlan Creek Dual Xeon Server board (£ 340)
SC5600BRP — Intel SC5600 Server chassis, 1+0 PSU (£ 508)
Valutazioni economiche
106
ST31000340NS — BARRACUDA ES.2 1TB 32MB 3.5 SATA/300
8.5MS 7200RPM (£ 125)
ST3300657SS — CHEETAH 15K.7 300GB SAS 3.5IN 3.4MS 16MB
6GBIT/S (£ 222)
SH-W163A-BL — Samsung Internal 22xDVD-RW SATA Black (£ 18)
8GB 1066 DDR3 ECC [4xKVR3-1066-ECC-2G] (£ 216)
AXX6DRV3GR — 6 Hotswap bays for SC56xx chassis (£ 78)
Total (VAT included): £ 1,789.00
Tabella 8.5 - Configurazione del server interno suggerita da Krescendo
La configurazione è in realtà decisamente sovradimensionata per le reali esigenze, soprattutto nello
scenario A, ma è consigliabile perché risulterebbe un investimento più durevole nel tempo ed in gra-
do di supportare carichi di lavoro più elevati nell’ottica di un incremento degli sviluppi e degli svilup-
patori che lavorano simultaneamente. Considerando il tasso di cambio al 01/02/2010 (rapporto
EUR/GBP = 0,8749), si avrebbe un prezzo di circa 2044,80 EUR.
Il server proposto impiega l’ultima generazione di processori Intel Xeon, serie 5500, dotate di 4 core
e cache a 3 livelli ed in grado di supportare memorie DDR3 a 800/1066/1333 MHz. Il disco Seagate
Barracuda (SATA/300) è una delle migliori soluzioni disponibili per workstation, server e sottosistemi
di memorizzazione, sviluppando prestazioni all'avanguardia e massimi livelli di potenza. Un ulteriore
disco, dotato di prestazioni eccezionali (6 Gbit/s), è il Cheetah 15K.7 che implementa la tecnologia
SAS (Serial Attached SCSI) ma può essere escluso dalla configurazione se il server è utilizzato solo
in ambiente di test. Discorso analogo per il dispositivo di Hot Swap, che consente la sostituzione dei
dischi anche a sistema avviato.
Valutazioni economiche
107
Una configurazione alternativa, già assemblata e proposta da un vendor italiano, è riportata in tabel-
la. Tale soluzione prevede una doppia CPU Intel Xeon (quad-core), ma dispone di memorie RAM
DDR2 anziché DDR3 e dischi di qualità inferiore.
PC SERVER XEON Quad Core n.2 X3230 2.66GHz x
2+8GB+2TB (2x1TB)
Processore: n. 2 INTEL XEON QUAD X3230
2.66GHz/1066/8MB/775
Memoria RAM: 8GB DDR2/800 ECC Full Brand Kingston
(4x2GB)
Hard Disk: 2Terabyte 7200 rpm 32Mb/SATAII Seagate
(2x1TB Raid 0)
Scheda Madre:ASPEN HILL LX BOXED BOARD DDR2
+CTRL SATA RAID
Scheda Grafica: Radeon X1050 128MB/1GB HM PCI-E
Masterizzatore DVD+FDD 1.44MB: Dual Layer 16X
8.5GB+FDD
Scheda audio: 16BIT integrata su mainboard
Porte: 8 x USB 2.0 + 1 x Firewire
Case: Case ANTEC TTITAN FileServer 1000W conti-
nui+4x5"1/4+6x3"1/2<
Tastiera Trust PS2, Speaker, Mouse Logitech Pilot Plus
Prezzo: 1.799,00 EUR (IVA inclusa)
Vendor: Computer City (http://www.computercityhw.it)
Tabella 8.6 – Configurazione alternativa del server interno
Si ipotizza infine un costo di manutenzione e aggiornamenti annui pari a 500,00 EUR per ogni server
e 300,00 EUR per ogni postazione di sviluppo.
8.2.2 Investimenti software
I costi del software riguardano anzitutto le postazioni dedicate allo sviluppo, mentre lato server non si
prevede di impiegare software proprietario, ad eccezione della piattaforma eXtraSheet. Tutte le piat-
taforme individuate sono infatti cross-platform e non richiedono software specifici.
Il dettaglio è riportato nella tabella che segue, senza prendere in considerazione tutti i componenti
Open Source o gratuiti che dipenderebbero soprattutto dalla piattaforma prescelta.
Nella tabella sono indicati il costo del canone (scenario A) oppure della licenza di eXtraSheet (scena-
rio B), che verranno stimati quando si prenderanno in esame gli scenari singolarmente.
Valutazioni economiche
108
Descrizione Prezzo unitario
Sistema operativo MS Windows XP Professional 125 €
Suite MS Office 2007 Enterprise 450 €
Software antivirus 90 €
Sistema operativo server CentOS (Linux) -
Piattaforma J2EE oppure PHP -
MySQL RDBMS -
Altri componenti free oppure Open Source (IDE,
Web server, tool di sviluppo, librerie, front-end, …) -
Tabella 8.7 - Investimenti in software
Si ipotizzano dei costi annui di aggiornamento o acquisto nuovo software proprietario pari a 250,00
EUR per ogni postazione o server.
8.2.3 Servizi di hosting
Le spese di hosting, che verrà demandato ad una società terza, riguardano inizialmente un server di
produzione, preferibilmente dedicato, che erogherà i servizi della nuova piattaforma. L’hosting dedi-
cato permette infatti al cliente di ―affittare‖ un intero server ottenendone il controllo completo, potendo
scegliere la configurazione hardware e software e conseguire la massima sicurezza e le migliori per-
formance.
Considerando i dati storici aziendali, il prezzo per l’hosting dedicato di un server ―Dell PowerEdge
1850‖ risulta pari a 396,00 EUR/mese. Verificando tuttavia le performance necessarie per il nuovo
server di produzione (a regime), lo stesso fornitore (Serverplan) è in grado di offrire soluzioni più po-
tenti quali il ―Dell PowerEdge 2950‖. Il server citato assicura prestazioni all'avanguardia e il giusto
equilibrio tra espandibilità interna e densità di rack con il nuovo processore Quad Core Intel Xeon
L5430, 2X6MB Cache, 2.66GHz, 1333MHz FSB. Il PowerEdge 2950 garantisce sia le elevate pre-
stazioni richieste dai clienti che la capacità dei dischi rigidi necessaria per applicazioni complesse.
Scegliendo la configurazione hardware riportata in tabella, il prezzo risulta quasi doppio rispetto al
server già in uso da Cefin Systems e pari a 706,00 EUR.
Volendo invece orientarsi su un piano di hosting più prudente, si potrebbe ad esempio stipulare il se-
guente piano di hosting con il fornitore HostingVirtuale, decisamente più economico. Si tratta di un
server sempre dedicato ma scarsamente configurabile in termini di hardware e dotato di performance
limitate ma più che idonee a soddisfare le prime richieste di applicativi sulla nuova piattaforma.
Valutazioni economiche
109
Tipologia voce Descrizione
Componente HW CPU Intel Xeon L5430, 2X6MB Cache, 2.66GHz, 1333MHz FSB
Componente HW RAM 8 GB DDR2 SDRAM 667MHz
Componente HW 4 Hard Disk 500 GB SATA2 7.200 rpm hot plug, RAID5
Servizio 4 indirizzi IP
Servizio Backup orario (500 GB)
Servizio Monitoring
Servizio Certificato SSL Geotrust
TOTALE (IVA inclusa): 706,00 EUR/mese
[Fornitore: Serverplan]
Tabella 8.8 - Dettaglio del canone mensile di hosting per il server di produzione
Tipologia Descrizione
Componente HW CPU INTEL Core 2 Quad 2,4-2,66GHz
Componente HW RAM 2 GB
Componente HW 1 Hard Disk 250 GB
Servizio Banda 10Mbps flat (2Mbps garantiti)
Servizio Firewall CISCO PIX ridondato
Servizio 2 indirizzi IP
TOTALE (IVA inclusa): 114,00 EUR/mese
[Fornitore: HostingVirtuale]
Tabella 8.9 - Soluzione alternativa per l’hosting per il server di produzione
8.2.4 Costi di avviamento
Escludendo per ora i costi del personale a regime, quelli sinora individuati rappresentano certamente
le voci evidenti e tangibili, ma ne rimane una categoria meno visibile, legata soprattutto alle fasi di
start-up della nuova piattaforma. Tali costi sono relativi a personale interno o esterno e riguardano,
ad esempio, la configurazione dei componenti hardware, l’installazione e la configurazione degli am-
bienti di sviluppo e la partecipazione ai corsi di formazione.
Inoltre sarebbe necessaria la riorganizzazione di parte degli uffici, l’adeguamento della rete azienda-
le, con eventuali movimentazioni di componenti, installazione di nuovi access point e altri apparati di
rete.
Nella valutazione dei costi di avviamento è inoltre necessario prestare attenzione alle perdite che
l’azienda dovrà sopportare, dovute alla mancata produzione da parte del personale interno che risul-
terà impegnato in attività di apprendimento e messa in opera della nuova piattaforma. Di seguito si
riporta una previsione dei costi di avviamento individuati.
Valutazioni economiche
110
Descrizione Costo unitario
Configurazione server 650 € (Krescendo senior developer - 1g)
Configurazione postazione di sviluppo 400 € (Krescendo junior developer - 1g)
Corso di formazione tecnica su eXtraSheet 4.000 € (Krescendo senior developer +
trasferta sviluppatore Cefin Systems - 5g)
Setup ufficio e configurazione LAN 450 € (dipendente Cefin Systems - 1g)
Mancata produzione da parte di personale non de-
dicato (analisti, manager, …) o inefficienze 5.000 €
Tabella 8.10 - Costi di avviamento stimati
8.2.5 Costi del personale
La valutazione dei costi del personale è stata effettuata considerando separando le figure incaricate
allo sviluppo dai dipendenti impegnati nelle altre attività. La prima categoria sarà perlopiù dedicata e,
di conseguenza, appare opportuno considerare il costo aziendale annuo. Viceversa, per le figure
commerciali e manageriali, che svolgono altre attività all’interno dell’organizzazione e, più o meno
saltuariamente, curano la commercializzazione e l’evoluzione della piattaforma e delle soluzioni ba-
sate su di essa. Per questi soggetti è quindi più opportuno valutarle in termini di ―daily fee‖ cioè il co-
sto giornaliero che l’azienda deve sostenere per impegnarli nel progetto in esame. Le quotazioni, ba-
sate su dati storici aziendali e su indicazioni del management, sono riportate in tabella.
Figura professionale Costo aziendale unitario
Sviluppatore 28.000,00 €/anno
Analyst 300 €/giorno
Project manager 350 €/giorno
Sales agent 250 €/giorno
Tabella 8.11 - Assunzioni relative al costo del personale
Qualunque sia lo scenario prescelto, sarebbero inoltre da aggiungere i corsi di formazione periodici,
che il personale tecnico dovrà seguire per ottenere aggiornamenti relativi alle tecnologie impiegate e
ai processi di sviluppo. Tale costo è stimato dal management aziendale pari a 3.000 EUR/anno, in
tutti gli scenari delineati.
8.2.6 Altri oneri
Cefin Systems dispone attualmente di alcuni locali inutilizzati che concede abitualmente in locazione
a terzi. Nel caso in cui risultasse necessario un nuovo locale per ospitare l’area tecnica del nuovo
progetto, l’azienda dovrebbe sopportare un mancato ricavo.
Inoltre, la fruizione della nuova piattaforma da parte degli utenti necessiterà del certificato digitale,
per l’autenticazione del server che eroga il servizio.
Valutazioni economiche
111
Probabilmente sarà necessario un potenziamento dell’attuale connessione alla rete Internet, soprat-
tutto se si opterà per il mantenimento (anche provvisorio) dei server internamente oppure se il team
di sviluppo crescerà nel tempo.
Infine, se la scelta cadrà sugli scenari A o B, non saranno trascurabili le trasferte effettuate dal per-
sonale coinvolto nel progetto presso l’azienda londinese Krescendo, che sarà tenuta ad aggiornare
periodicamente il nuovo partner Cefin Systems.
8.2.7 Differenze tra gli scenari
I piani di investimento proposti per gli scenari in esame sono caratterizzati dalle seguenti differenze,
già accennati nel corso dei precedenti paragrafi:
Investimenti in infrastruttura hardware interna crescenti, poiché nel primo scenario saranno
necessarie esclusivamente una o due postazioni di sviluppo mentre nei casi B e C sono ri-
chieste risorse aggiuntive (server interni principalmente per testing e backup).
I costi di hosting sono assenti nello scenario A (che sono compresi nel canone di Krescen-
do), presenti a partire dal 3° anno nel caso C (si prevede che la piattaforma non sia abba-
stanza matura nei primi anni e sia necessaria una maggior flessibilità) e presenti dal 1° anno
nel caso B (la release di eXtraSheet potrà essere installata direttamente su server esterni e
più affidabili).
I tempi (e di conseguenza i costi) previsti per gli sviluppatori interni sono crescenti nei tre
scenari, poiché man mano che aumenta l’autonomia da Krescendo è necessario un maggior
effort dal team di sviluppo. Analogamente per il supporto tecnico. Nello scenario C, inoltre,
sarà necessario un maggior investimento per il perfezionamento e l’adattamento della piatta-
forma open source, quantificato incrementando i tempi del 50% nel primo anno.
Si ipotizza un tasso di mercato per la valutazione dell’investimento pari al 5% e un tasso di
crescita dei ricavi annuo del 18%, prossimo al tasso di crescita del settore SaaS ma plausibi-
le anche per la strategia di marketing pianificata e la probabile diffusione della piattaforma.
Il ricavo iniziale presunto è differente per i tre scenari ed è massimo per il caso B, dove si i-
potizza sia possibile raggiungere subito la massima efficienza e flessibilità. Le stime proven-
gono da dati storici e dalle indicazioni ottenute dal management aziendale.
8.3 Analisi cash flow e profittabilità
Terminata l’analisi dei costi quantitativa e temporale che Cefin Systems dovrebbe sostenere per
l’attuazione del progetto, si è passati alla valutazione dei flussi di cassa (cash flow), un indicatore cr i-
tico per la sostenibilità dell’investimento. Il cash flow è la ricostruzione dei flussi monetari nell’arco
Valutazioni economiche
112
del periodo di analisi, nel caso specifico supposto pari a 5 anni, e permette di individuare il fabbiso-
gno finanziario necessario al nuovo progetto.
Nel calcolo dei flussi di cassa si è mantenuta la suddivisione tra gli scenari, utile anche per il calcolo
dei successivi indici di profittabilità dell’investimento.
Lo scenario A, quello maggiormente prudente, è stato dettagliato in termini di costi e benefici mone-
tari seguendo le considerazioni e le stime effettuate in precedenza, aggiungendo le seguenti valuta-
zioni:
Licenza eXtraSheet e supporto di Krescendo, secondo le assunzioni già effettuate di utilizzo
dei server di quest’ultima e fruizione del supporto e manutenzione necessari, stimata pari a
25.000 EUR/anno ma influenzata dai volumi e destinata a crescere negli anni successivi.
Costi del personale crescenti nel tempo, sia dovuti alla specializzazione dello sviluppatore
principale, sia all’impiego di una seconda figura con effort variabile.
Ricavi stimati per il primo anno pari a 80.000 EUR, corrispondenti a 10 progetti di ridotte di-
mensioni oppure 5 progetti di dimensioni medio-grandi. Negli anni successivi si ipotizza un
tasso di crescita dei profitti costante e pari a 18,50%.
Il dettaglio dei flussi di cassa per lo scenario A è riportato in tabella.
Valutazioni economiche
113
Tabella 8.12 - Prospetto costi-benefici - Scenario A
Proseguendo con l’analisi, si calcola il flusso di cassa annuale ed il progresso del saldo del flusso di
cassa. I risultati sono riportati in tabella.
Valutazioni economiche
114
Fiscal Year Annual
Investments/cost Annual Benefits
Annual cash in - cash out
Progress Cash in - cash out
FY 1 -106.500,00 80.000,00 (26.500,00) -26.500,00
FY 2 -100.250,00 94.800,00 (5.450,00) -31.950,00
FY 3 -108.250,00 112.338,00 4.088,00 -27.862,00
FY 4 -125.250,00 133.120,53 7.870,53 -19.991,47
FY 5 -128.250,00 157.747,83 29.497,83 9.506,36
Grand total -568.500,00 578.006,36 9.506,36 19.012,72
Tabella 8.13 - Cash flow - Scenario A
Si osserva che nei primi due anni il flusso di cassa annuo risulta negativo e solo negli ultimi due anni,
quando i ricavi stimati diventano considerevoli, il saldo cumulato diventa positivo. Il fabbisogno finan-
ziario risulta notevole e può essere giustificato solo se la profittabilità dell’investimento è notevole.
Procedendo al calcolo del VAN si ottiene un valore positivo, anche se non elevatissimo, e pari a
2.937,39 EUR. Per annullare il VAN si dovrebbe richiedere un tasso pari al 7,89%.
Figura 8.1 - Calcolo del VAN - Scenario A
Effettuando l’analisi per lo scenario B, caratterizzato dall’acquisizione della licenza di eXtraSheet e
dallo sviluppo in maggiore autonomia, si è ottenuto il piano costi-benefici riportato in tabella.
Valutazioni economiche
115
Tabella 8.14 - Prospetto costi-benefici - Scenario B
Procedendo al calcolo dei flussi di cassa, si ottengono risultati poco incoraggianti, che evidenziano
saldi negativi per tutta la durata dell’investimento, rendendolo certamente non appetibile alle condi-
Valutazioni economiche
116
zioni previste. Infatti, il costo considerevole della licenza di eXtraSheet unito al notevole effort richie-
sto in termini di personale, risulta sproporzionato rispetto ai ricavi stimati, peraltro già di buona entità.
Fiscal Year Annual
Investments/cost Annual Benefits
Annual cash in - cash out
Progress Cash in - cash out
FY 1 -159.500,00 100.000,00 (59.500,00) -59.500,00
FY 2 -148.750,00 118.500,00 (30.250,00) -89.750,00
FY 3 -150.750,00 140.422,50 (10.327,50) -100.077,50
FY 4 -152.750,00 166.400,66 13.650,66 -86.426,84
FY 5 -153.750,00 197.184,79 43.434,79 -42.992,05
Grand total -765.500,00 722.507,95 (42.992,05) -85.984,10
Tabella 8.15 - Cash flow - Scenario B
Figura 8.2 - Calcolo del VAN - Scenario B
Analizzando il terzo scenario, che prevede la scelta di una soluzione Open Source, si può prevedere
il seguente il piano costi-benefici.
Valutazioni economiche
117
Tabella 8.16 - Prospetto costi-benefici - Scenario C
Procedendo con il calcolo dei flussi di cassa, si ottengono risultati notevoli, determinando un valore
negativo solo per il primo anno e un recupero molto rapido, raggiungendo il pareggio al terzo anno e
flussi in rapida crescita negli anni successivi.
Valutazioni economiche
118
Fiscal Year Annual
Investments/cost Annual Benefits
Annual cash in - cash out
Progress Cash in - cash out
FY 1 -134.200,00 90.000,00 (44.200,00) -44.200,00
FY 2 -91.500,00 106.200,00 14.700,00 -29.500,00
FY 3 -98.500,00 125.316,00 26.816,00 -2.684,00
FY 4 -100.500,00 147.872,88 47.372,88 44.688,88
FY 5 -101.500,00 174.490,00 72.990,00 117.678,88
Grand total -526.200,00 643.878,88 117.678,88 235.357,76
Tabella 8.17 - Cash flow - Scenario C
Procedendo con il calcolo del VAN, si ottiene conferma della ottima profittabilità dell’investimento,
essendo questi pari a 90.566,12 EUR e un tasso di annullamento dello stesso pari al 57,40%. No-
nostante l’incremento dell’effort previsto per il primo anno al fine di perfezionare la piattaforma,
l’azzeramento dei costi di licenza e un valore di ricavi intermedio (rispetto agli altri due scenari) de-
termina un’ottima profittabilità dell’investimento.
Figura 8.3 - Calcolo del VAN - Scenario C
8.3.1 Analisi di sensitività
I risultati ottenuti con il calcolo del VAN sono in realtà scarsamente significativi se considerati in valo-
re assoluto, poiché una stima errata di qualche parametro potrebbe vanificare l’efficacia dell’analisi.
Per questi motivi, è stata condotta una analisi di sensitività, verificando se la profittabilità
dell’investimento è sufficientemente robusta al variare di alcuni parametri.
1) Variazione del tasso di mercato: il tasso richiesto dagli azionisti, assunto pari al tasso di mer-
cato, può in realtà essere più o meno elevato. Avendo già calcolato il tasso interno di rendi-
mento, è piuttosto semplice individuare se il VAN diventa negativo. In tabella sono riepilogati
i tassi interni di rendimento e proposti alcuni casi limite.
Valutazioni economiche
119
Descrizione Scenario A Scenario B Scenario C
TIR 7,89% -15,97% 57,40%
VAN con r=2% (rendimento medio BTP) 6.621,70 -45.189,20 105.939,67
VAN con r=5% (rendimento intermedio) 2.937,39 -47.762,87 90.566,12
VAN con r=8% (richiesti alti rendimenti) -103,55 -49.630,77 77.460,61
Tabella 8.18 - Analisi di sensitività sul tasso di rendimento richiesto
2) Variazione del ricavo iniziale stimato: tale valore è effettivamente difficile da stimare e la va-
lutazione di alcune casistiche è senz’altro interessante. Come dai dati riportati in tabella, la
convenienza del progetto si ha raggiungendo per il primo anno almeno la soglia degli 80.000
EUR di fatturato, che può essere definito come punto di break-even. In realtà, per lo scenario
B, la convenienza dell’investimento si avrebbe solo con volumi più elevati, superiori ai
100.000 EUR.
Totale ricavi (anno 1)
VAN(A) VAN(B) VAN(C)
40.000 -243.231,01 -417.015,47 -214.248,52
60.000 -120.146,81 -293.931,27 -92.322,66
80.000 2.937,39 -170.847,07 29.603,20
100.000 126.021,59 -47.762,87 151.529,05
120.000 249.105,79 75.321,33 273.454,91
140.000 372.189,99 198.405,53 395.380,76
Tabella 8.19 - Analisi di sensitività sui ricavi previsti
Dal grafico sotto riportato è inoltre evidente che i costi sono presunti costanti, infatti i costi
marginali sono pressoché nulli, poiché e buona parte dei costi del personale e della manu-
tenzione e commercializzazione della piattaforma sono costanti al variare delle vendite.
Figura 8.4 - Break-even sui ricavi previsti
3) Variazione del tasso di crescita dei profitti: anche questo parametro è in grado di influenzare
notevolmente il VAN dell’investimento. Si osserva che in questo caso la predominanza dello
scenario C è decisamente marcata, dovuta presumibilmente alla presenza di costi di messa
Valutazioni economiche
120
a punto della piattaforma solo durante il primo anno, permettendo di beneficiare della cresci-
ta negli anni successivi.
Totale ricavi (anno 1)
VAN(A) VAN(B) VAN(C)
15% -28.368,62 -87.232,88 60.255,66
20% 17.087,96 -30.074,65 111.698,07
25% 67.053,43 32.382,18 167.909,22
30% 121.537,49 100.487,26 229.203,78
35% 180.829,26 174.601,98 295.907,03
Tabella 8.20 - Analisi di sensitività sul tasso di crescita dei profitti
In conclusione, anche l’analisi condotta conferma la superiorità dello scenario C. Il risultato non con-
templa tuttavia il livello di rischiosità, che risulta essere massimo proprio nello scenario più profittevo-
le.
Analisi dei rischi e milestone progettuali
121
9 Analisi dei rischi e milestone progettuali
Dopo aver determinato anche i parametri economico-finanziari dell’investimento, in questo capitolo si
vuole fornire una serie di informazioni riguardanti gli aspetti progettuali, fornendo le linee guida per la
gestione e la pianificazione dettagliata del progetto.
9.1 Fattori critici del progetto
Gli aspetti fondamentali sui quali si consiglia concentrare l'attenzione degli stakeholder sono anzitutto
le competenze tecnologiche: il personale deve conoscere nel dettaglio la piattaforma prescelta, esse-
re in grado di sviluppare soluzioni standard e personalizzate con immediatezza e competenza. I di-
pendenti devono inoltre offrire un servizio specializzato e un supporto tecnico agile e competente.
Altrettanto importante è la qualità del management per la nuova linea di business, che deve saper
adeguarsi ad eventuali cambiamenti del mercato e sfruttare le nuove opportunità tecnologiche.
A livello organizzativo, è richiesta una interazione produttiva tra area tecnica e commerciale, con gli
analisti che si collocano in una posizione intermedia, essendo dotati di conoscenze tecnologiche ed
in grado di implementare direttamente semplici soluzioni sulla nuova piattaforma.
La strategia commerciale dovrà essere ben strutturata ed in grado di raggiungere un vasto numero di
potenziali clienti a cui dovrà essere evidenziato il vantaggio in termini di tempi, costi e affidabilità ri-
spetto ad uno sviluppo tradizionale e le ormai provate qualità vincenti del paradigma SaaS.
9.2 Valutazione dei rischi
La buona gestione di un progetto non può garantire il successo finale, ma certamente
un’amministrazione poco attenta ne determina il fallimento. I manager responsabili della pianificazio-
ne e delle tempistiche del progetto in esame devono assicurare il rispetto dei vincoli temporali e di
budget concordati con il management e questo risulta particolarmente complesso per i seguenti mo-
tivi:
1. Difficoltà di controllo: buona parte degli output non sono facilmente controllabili, poiché
l’intangibilità del prodotto software determina una difficoltà nel valutarne i progressi e gli unici
feedback di cui dispone il manager sono costituiti dalla documentazione prodotta dal perso-
nale per certificare il completamento di determinate attività.
2. Unicità del progetto: il progetto è talmente specifico da rendere difficoltose le previsioni an-
che per manager di grande esperienza, la quale può essere ulteriormente ridotta dalle rapide
evoluzioni tipiche del settore informatico.
Analisi dei rischi e milestone progettuali
122
Queste caratteristiche possono aumentare le probabilità di ritardo, di superamento del budget o di
insuccesso del progetto, rendendo necessaria una più attenta analisi del rischio.
Il project manager deve prevedere i problemi che possono sorgere e prevedere soluzioni alternative.
Il piano iniziale deve essere usato come guida, deve essere il migliore possibile rispetto alle informa-
zioni disponibili e deve migliorare man mano che il progetto evolve e/o si abbiano informazioni mag-
giori.
All’inizio del processo di pianificazione, bisogna stimare i vincoli che influenzano il progetto, quali le
tempistiche, il personale disponibile, il budget che si ha a disposizione. Oltre a questo bisogna porre
l’attenzione sui parametri del progetto come la struttura, la dimensione e la distribuzione delle fun-
zioni. Si passa poi alla definizione delle milestone ed i corrispondenti deliverable del progetto e infine
il progetto entra nel ciclo. Si stima una tempistica le cui attività vengono avviate o continuate; perio-
dicamente si revisiona il progresso del progetto e si rilevano le discrepanze con la tempistica pianifi-
cata. Essendo le stime iniziali solo ipotesi, ci sarà da aggiornare il piano originario nel corso del pro-
getto; con la disponibilità di ulteriori informazioni, si rivedono le supposizioni iniziali. Se il processo è
in ritardo potrebbero essere ricontrattate con il cliente le date di consegna del progetto e i vincoli ad
esso connessi; se la negoziazione fallisce e la tempistica non può essere rispettata si valuta una re-
visione del progetto, per trovare un approccio alternativo che soddisfi i vincoli e che rispetti le tempi-
stiche. Ovviamente in fase di pianificazione si dovrebbe tener conto di questi inconvenienti e la stima
dovrebbe essere pessimistica piuttosto che ottimistica.
Passando esplicitamente alla fase di valutazione dei rischi, intesi come eventualità che possono
compromettere o ritardare il successo del progetto, è possibile effettuare una classificazione in tre
tipologie distinte:
Project risk: rischi legati alla fase di schedule (tempistiche) del progetto o alle risorse utilizza-
te o da utilizzare;
Product risk: rischi connessi alla qualità o alle prestazioni del sistema software sviluppato e
del servizio da esso derivante;
Business risk: rischi connessi all’organizzazione.
La procedura per affrontare tali eventualità, detta risk management, coinvolge quattro differenti stadi:
1) Risk identification: identificazione della natura del rischio, riconducendolo ad almeno una del-
le tipologie esposte in precedenza;
2) Risk analysis: analisi delle conseguenze del rischio individuato nella fase precedente, deter-
minando la probabilità di accadimento e la gravità nel caso esso si verificasse. Quello che ne
dovrebbe derivare è una tabella ordinata secondo la gravità del rischio dalla quale è possibi-
le valutare quali sono i più significativi, in base alla combinazione delle probabilità di concre-
tizzazione e dei suoi effetti.
Analisi dei rischi e milestone progettuali
123
3) Risk planning: metodologia per evitare il rischio o comunque affrontarlo, qualora non sia
possibile l’eliminazione. In particolare, sono identificabili tre macro aree di strategie in ordine
preferenziale, nella cui scelta ha ruolo fondamentale l’esperienza del project manager:
a. strategie rivolte ad evitare o ridurre la probabilità di rischio;
b. strategie per minimizzazione dell’impatto del rischio;
c. piani precauzionali, intesi come soluzioni in grado di gestire il rischio che si è verifica-
to.
4) Risk monitoring: modalità di monitoraggio il rischio, per rilevare prontamente (mediante op-
portuni fattori in grado di fornire indizi) se il rischio sta per verificarsi e intervenire quindi con
attività di manutenzione.
La comprensione della scala di valori e delle attese degli stakeholder del progetto è essenziale per
un’appropriata valutazione delle potenziali conseguenze negative di un evento, cioè dell’entità del
danno associato. Benché la valutazione dell’altra componente del rischio - la probabilità della catena
di eventi negativi - dovrebbe essere più oggettiva della valutazione dell’impatto del danno, vi sono
molte situazioni nelle quali tale probabilità è influenzata dal soggetto che la valuta.
Figura 9.1 - Il processo di risk management
Come rappresentato graficamente, la gestione del rischio continua per tutta la durata del progetto:
dopo l’impostazione iniziale, la situazione è monitorata e quando nuove informazioni sono disponibili,
si analizzano nuovamente i rischi e si stabiliscono le nuove priorità.
Nello specifico del progetto richiesto da Cefin Systems, è stata condotta un’analisi dei rischi anche
se non è stato possibile determinare talune categorie di rischio con precisione, soprattutto quelle re-
lative alle aree finanziarie e contrattuali del progetto. Una seconda limitazione alla valutazione ese-
guita è legata all’incertezza relativa alle fasi esecutive del progetto, non chiaramente delineate ma
solamente ipotizzate al momento dell’analisi. Prima di mostrare il piano di analisi dei rischi effettuata
dal team di progetto si riportano i criteri considerati, sulla base della premessa teorica, per la catalo-
gazione dei rischi identificati.
Analisi dei rischi e milestone progettuali
124
Nome campo Descrizione
ID Numerazione progressiva del rischio.
RISCHIO Descrizione sintetica del rischio. Ogni eventualità che può compromettere o ritardare il successo del progetto è un rischio.
TIPOLOGIA Categoria del rischio: - project risk: rischi legati alla fase di schedule (tempistiche) del progetto o alle risor-se utilizzate o da utilizzare; - product risk: rischi connessi alla qualità o alle prestazioni del sistema software svi-luppato; - business risk: rischi connessi all’organizzazione che sta sviluppando o dovrà usare il sistema software progettato.
PROBABILITÀ La probabilità che un elemento o evento di rischio si possa effettivamente manifesta-re. La valutazione della probabilità può essere effettuata su base quantitativa (ad esem-pio su una scala 1÷10) oppure qualitativa. Di seguito una possibile scala qualitativa: - molto bassa - improbabile che si verifichi - bassa - più probabile che non si verifichi - media - probabilità uguale che si verifichi o non si verifichi - alta - più probabile che si verifichi - molto alta - improbabile che non si verifichi
IMPATTO Entità del danno che può derivare dal concretizzarsi del rischio (gravità degli effetti prodotti in termini di costi, tempi, qualità del risultato, soddisfazione del committente). La valutazione dell’impatto può essere effettuata in modo quantitativo (ad esempio su una scala 1÷10), oppure qualitativo. Di seguito una possibile scala qualitativa: - Catastrofico - Grave - Tollerabile - Insignificante
STRATEGIA DI RISK MANAGEMENT
Descrivere le azioni da intraprendere per affrontare il rischio descritto. Di solito, le risposte possibili ai rischi rientrano nelle casistiche seguenti: - evitarli: eliminare i fattori che possono ingenerare il rischio - trasferirli: cedere a terzi la gestione dell’impatto negativo del rischio - mitigarli: diminuire la probabilità o l’impatto di un evento di rischio fino a raggiunge-re una soglia accettabile - accettarli: quando i possibili rimedi sono peggiori dell’impatto negativo del rischio
RESPONSABILITÀ A chi è affidata l'eventuale azione per evitare o mitigare il rischio.
Tabella 9.1 - Criteri considerati per l'analisi dei rischi
Di seguito è mostrato il piano dei rischi relativo al progetto in esame, che sintetizza l’analisi dei rischi
effettuata, riportando per ogni rischio individuato le valutazioni della gravità ed una breve descrizione
del processo di risk management. Resta inteso che la gestione del rischio continua per tutta la durata
del progetto ed il presente piano dovrà essere ampliato, aggiornato e revisionato nel corso del pro-
getto.
Analisi dei rischi e milestone progettuali
125
Tabella 9.2 - Prospetto di analisi dei rischi di progetto
Analisi dei rischi e milestone progettuali
126
9.3 Macroattività e tempistiche proposte
La tempistica è uno degli aspetti più complessi nella gestione di un progetto: i responsabili devono
valutare il tempo e le risorse necessarie per completare le attività e organizzarle in una sequenza
coerente. La stima della tempistica viene determinata su base incerta è può essere complicata da
imprevisti; richiede la suddivisione dell’intero progetto in attività separate a cui associare le stime del
tempo previsto. Solitamente, alcune attività sono svolte in parallelo ed è necessario coordinarle e or-
ganizzare il lavoro in modo da ottimizzare le risorse del team. Una regola pratica è quella di effettua-
re le valutazioni supponendo che ogni attività non determini problemi o imprevisti, poi aumentare tale
stima per coprire difficoltà presunte ed eventualmente prendere misure precauzionali per problemi
imprevisti. Ad esempio, è possibile applicare una percentuale correttiva del 30% da aggiungere alla
stima originale per i problemi previsti e poi un ulteriore 20% per coprire quelli imprevisti. Le tempisti-
che del progetto sono solitamente rappresentate come un insieme di grafici che mostrano la divisio-
ne del lavoro, le dipendenze delle attività e l’assegnazione dello staff.
La tempistica del progetto può essere rappresentata anche attraverso l’utilizzo del diagramma di
GANTT (o diagramma a barre), che mostra il calendario del progetto, le tempistiche in cui le diverse
attività devono essere svolte e le data di partenza e di fine delle attività.
Per calcolare il tempo minimo stimato richiesto per completare il progetto si può considerare il per-
corso più lungo che comprende attività e milestone in ordine sequenziale, detto cammino critico; da
esso dipende la tempistica generale, ogni ritardo nel completamento di un’attività critica causa ritardi
al progetto ―a cascata‖ perché le attività successive non possono partire finché questa non è comple-
tata.
La schedulazione del progetto richiesto da Cefin Systems è stata effettuata mediante l’applicazione
Microsoft Project, che consente di gestire in modo efficiente attività, risorse e molti aspetti relativi alla
pianificazione di un progetto. La funzionalità fondamentale è la creazione del diagramma di GANTT
relativo al progetto, che in MS Project viene realizzato come segue:
Le barre nere indicano le macroattività, mentre quelle blu le attività di dettaglio.
Le linee grigie verticali indicano i giorni non lavorativi (weekend, festività).
Inoltre nel diagramma GANTT vengono evidenziate le milestone, ossia i momenti decisionali che
coincidono con il rilascio dei deliverable, intesi come un prodotti (o servizi) parziali di un progetto in-
dividuabile in modo effettivo, utilizzabile e riconosciuto come tale da almeno uno stakeholder.
Ad ogni attività è stata assegnata una tempistica, cioè una stima del tempo necessario al suo com-
pletamento; nella loro valutazione delle tempistiche è necessario includere alcuni margini di ritardo,
conseguenti a problemi che potrebbero verificarsi (es. malattia del personale, guasti hardware, rinvio
di riunioni con stakeholder, ritardi nelle consegne di componenti hardware e/o software).
Analisi dei rischi e milestone progettuali
127
Si è inoltre scelto di non dettagliare le singole attività, bensì di definire esclusivamente le macroattivi-
tà, con il duplice obiettivo di mantenere la visione globale e non addentrarsi nelle differenze tra gli
scenari possibili. La data di inizio del progetto ipotizzata, puramente indicativa, è il 01/03/2010.
I risultati ottenuti con MS Project sono riportati di seguito, ma sono comunque da ritenersi indicativi
per la genericità delle attività proposte e per i tempi che, in caso di altre attività aziendali a maggior
priorità, possono certamente essere posticipate o livellate con un effort maggiormente distribuito.
Le risorse interne che si ipotizzano sono le seguenti:
Management aziendale, composto dai vertici dell’azienda e coinvolti esclusivamente nelle at-
tività che richiedono poteri decisionali considerevoli.
Proposal manager, è la figura che, partendo dal presente elaborato procede alla realizzazio-
ne di una proposta per il management aziendale e collabora alla definizione del team di pro-
getto. Il suo incarico termina al momento dell’accettazione del progetto (termine della FASE
2).
Project Manager, è la figura già indicata che non supervisionerà solo il progetto di avviamen-
to della business line, ma continuerà a gestirla nelle fasi successive.
Team di progetto, è un gruppo di due/tre dipendenti incaricati di svolgere gran parte delle at-
tività tecniche, di carattere progettuale ed operativo, per condurre il progetto alla fase di av-
viamento. Le competenze richieste sono soprattutto di tipo tecnologico.
Agente commerciale/i.
Sviluppatore/i.
Analista/i.
Società Krescendo.
Analisi dei rischi e milestone progettuali
128
Tabella 9.3 - Schedulazione proposta delle macroattività
Analisi dei rischi e milestone progettuali
129
Figura 9.2 - Diagramma di GANTT risultante dalla schedulazione
Conclusioni
130
10 Conclusioni
10.1 Valutazione critica dei risultati
Il risultato finale delle attività svolte dal candidato è stato globalmente soddisfacente, sia sotto
l’aspetto formativo sia riguardo le informazioni reperite e le valutazioni condotte. Gli obiettivi che era-
no stati prefissati sono stati raggiunti, permettendo all’azienda di ottenere una panoramica circa gli
scenari alternativi e le informazioni utili a decidere se e in quale maniera avviare il progetto.
Si può certamente affermare che soluzioni di data management aventi le caratteristiche ricercate so-
no estremamente rare, ancor più se sono necessarie caratteristiche di performance ed affidabilità
ragguardevoli.
Dopo il primo periodo di utilizzo della piattaforma eXtraSheet da parte del candidato, ne è stata ap-
profondita l’architettura ed i processi di sviluppo. Questa fase ha consentito di sperimentare diretta-
mente la complessità di un sistema evoluto e particolarmente funzionale. La piattaforma J2EE e il
framework uView hanno permesso alla società londinese di sviluppare una piattaforma di alto livello
quale eXtraSheet, che fino ad alcuni anni fa era impensabile. La ricchezza di funzionalità e la facilità
di personalizzazione proiettano le soluzioni SaaS verso orizzonti molto promettenti, che potrebbero
portare le utenze business ad impiegare unicamente sistemi web-based in un futuro molto prossimo.
La piattaforma eXtraSheet mostra i risultati di una ottima competenza in ambito SaaS, non solo tec-
nologica, detenuta dalla società Krescendo: è già orientata soluzioni Enterprise e risulta semplice da
utilizzare per l’utente, che non percepisce la complessità del sistema e può effettuare molte opera-
zioni anche di amministrazione in completa autonomia.
Le soluzioni sviluppate personalmente dal candidato hanno invece riguardato applicazioni (eXtra-
Sheet-based) con gradi di personalizzazione superiore che hanno richiesto lo sviluppo di codice e la
conoscenza della piattaforma Java nel suo complesso. Le interazioni con il team della società Kre-
scendo hanno inoltre permesso di approfondire i processi interni e individuare sinergie e criticità, utili
a definire gli scenari che Cefin Systems potrebbe intraprendere qualora volesse creare la nuova li-
nea di business.
La fase successiva, che ha previsto la ricerca e lo studio di soluzioni alternative ad eXtraSheet, ha
condotto all’individuazione di numerose soluzioni. Tra queste, tuttavia, la maggior parte, pur essendo
altamente flessibili, si fermavano ad un livello inferiore rispetto a quello ricercato poiché offrivano e-
sclusivamente funzionalità a livello di programmazione e nessuna funzionalità di tipo ―out-of-the-box‖,
richiedendo lo sviluppo ex-novo di ogni nuova applicazione, mediante la stesura di codice.
Tra le soluzioni migliori, Wavemaker era fondata su una logica molto innovativa, riducendo notevol-
mente i tempi di sviluppo, ma si differenziava piuttosto da eXtraSheet, essendo una soluzione gene-
ral-purpose e dotata di performance non eccezionali.
Conclusioni
131
Le altre due piattaforme sulle quali sono stati realizzati alcuni casi di studio erano invece basate su
architetture molto diverse da eXtraSheet: fondamentalmente PHP+MySQL, caratterizzata da una ri-
dotta complessità e maggiore immediatezza. Le due alternative si sono però dimostrate ricche di
funzionalità e molto più vicine all’idea di business propria di eXtraSheet.
Anche la fase di benchmarking, seppur di carattere orientativo, ha confermato che una valida alter-
nativa ad eXtraSheet potrebbe essere proprio VFront, una soluzione Open Source, meno orientata al
settore Enterprise e con performance non paragonabili ad eXtraSheet ma potenzialmente semplice
da amministrare, ampliare e migliorare da parte dell’ipotetico nuovo team di sviluppo di Cefin
Systems.
In alternativa lo scenario che prevede la scelta di eXtraSheet, e quindi la partnership con Krescendo,
sarebbe altrettanto appetibile, offrendo vantaggi in termini di formazione, supporto e affidabilità, pur
essendo più oneroso in termini di costi dovuti a Krescendo per le licenze su eXtraSheet e/o i servizi
erogati da quest’ultima.
Analizzando l’idea di business, le potenzialità di successo per soluzioni SaaS che includono servizi di
consulenza sono notevoli, specialmente in presenza di sinergie.
Considerando l’analisi economica condotta, le prospettive del mercato SaaS risultano interessanti e
l’offerta di Cefin Systems potrebbe certamente essere appetibile per i clienti business caratterizzati
da processi non standard o esigenze specifiche. Gli aspetti da considerare per decidere se avviare il
progetto e, in caso affermativo, quale scenario preferire, sono principalmente due:
1) Volumi, indispensabili per proseguire lo sviluppo della piattaforma negli anni successivi (op-
pure corrispondere a Krescendo licenze e servizi aggiuntivi). A questo, oltre alle competenze
del personale tecnico, sono particolarmente importanti l’abilità degli agenti commerciali.
2) Seppur la scelta tra gli scenari proposti appare semplice considerando le valutazioni econo-
miche (scenario C, che offre il massimo VAN), si devono considerare altri criteri non contem-
plati nel semplice modello di valutazione dell’investimento. Infatti, la scelta di una piattaforma
Open Source e la completa autonomia espone l’azienda ad un rischio elevato, ad esempio
constatando che la piattaforma non è sufficientemente flessibile o scalabile per svolgere le
attività preventivate. Gli scenari A e B sono caratterizzati da minore aleatorietà, poiché la
piattaforma eXtraSheet è matura e la società Krescendo dispone di competenze molto avan-
zate in merito, se non altro in abito tecnologico ed eventualmente anche a livello commercia-
le si potrebbe svolgere attività di sviluppo per clienti di Krescendo, almeno nella fase di start-
up. Tra lo scenario A e B appare più conveniente la soluzione A in ogni caso ma è necessa-
rio considerare che al crescere dei volumi l’azienda Krescendo potrebbe non prestarsi più
per l’utilizzo dei propri server e delle proprie risorse interne poiché la complessità delle attivi-
tà e delle informazioni da gestire sarebbe eccessiva e richiederebbe presumibilmente il pas-
saggio allo scenario B, di tipo ―flat‖ e con maggior autonomia reciproca.
Conclusioni
132
Il risultato dell’analisi vuole quindi suggerire che, se l’azienda è disposta a sopportare un rischio più
consistente (ad esempio auto-finanziando costi extra attraverso i proventi derivanti da altre attività
aziendali caratterizzate da margini elevati) lo scenario più idoneo è certamente il C. Qualora preva-
lesse il fenomeno di ―avversità al rischio‖ e l’intenzione di investire in area profittevole con risultati
positivi ma limitati superiormente, allora le soluzioni più idonee risulterebbero quelle rimanenti: si ipo-
tizza infatti che, in caso di esito positivo dello scenario A (quello probabilmente più profittevole) i vo-
lumi diventerebbero elevati e sarebbe necessario convergere all’ipotesi B per le motivazioni già e-
sposte.
10.2 Sviluppi futuri
Il candidato ha constatato che l’obiettivo del progetto studiato è in realtà in contrasto con un altro o-
biettivo aziendale: l’internalizzazione del prodotto Sateltrack.
L’obiettivo strategico per Cefin Systems, già espresso in più occasioni, è il ritiro dell’incarico decen-
nale affidato alla società Krescendo, riguardante lo sviluppo informatico di Sateltrack. Infatti, le ineffi-
cienze inevitabilmente presenti nelle interazioni con Krescendo, preoccupano il management azien-
dale che percepisce la perdita di controllo sul prodotto core e storico per l’azienda. Tali inefficienze
riguardano principalmente i costi, i tempi di risposta e la difficoltà nella gestione dei flussi informativi
tra le due aziende.
Pur essendo un prodotto maturo, Sateltrack dispone ancora di potenzialità enormi ed è attualmente
leader sul mercato nel settore dei sistemi SaaS di fleet management, offrendo funzionalità avanzate
in grado di portare elevato valore aggiunto nella gestione delle flotte. I nuovi entrati sul mercato of-
frono soluzioni a basso costo e con modeste funzionalità, ma soprattutto non sono provvisti del
background necessario per proporre al cliente servizi di consulenza o personalizzazione di alcune
funzionalità.
Si prevede che un controllo diretto, unito a importanti innovazioni (tecnologiche o funzionali) e alla
stipula di nuovi accordi commerciali con aziende fornitrici di prodotti o servizi complementari, potreb-
be migliorare ulteriormente i volumi di vendita ed eventualmente portare allo sviluppo di nuove solu-
zioni integrate per i trasporti.
Nel contesto descritto, i contenuti del presente elaborato sarebbero estremamente utili a tale scopo,
essendo l’infrastruttura hardware e software di Sateltrack molto simile a quella di eXtraSheet. Satel-
track è senza dubbio caratterizzato da una complessità superiore poiché contempla un’infrastruttura
di comunicazioni molto più complessa e di tipo ―real-time‖, richiede capacità di elaborazione e di sto-
rage superiori, ma le tecnologie impiegate ai livelli sottostanti sono pressoché identiche. Qualora si
voglia dar priorità al presente obiettivo, molte fasi progettuali risulterebbero analoghe, mentre non si
presenterebbero più scenari alternativi, dato che Sateltrack è al 100% di proprietà Cefin Systems e
alla società Krescendo viene esclusivamente commissionato lo sviluppo.
Conclusioni
133
Sarebbe inoltre ipotizzabile una sinergia tra le due soluzioni, permettendo ad esempio di raggiungere
entrambi gli obiettivi con effort ridotti. In questo caso, gli scenari preferiti per la piattaforma Web sa-
rebbero quelli in partnership con la società Krescendo, mentre le alternative Open Source potrebbero
risultare eccessivamente eterogenee. L’investimento sarebbe comunque notevole e si consiglierebbe
di evitare parallelismi in assenza di personale dedicato esclusivamente ad uno dei due ambiti, poiché
la complessità delle due piattaforme potrebbe rendere difficilmente coordinabili le attività comuni.
Bibliografia
134
Bibliografia
Testi e pubblicazioni scientifiche
[1] Ian Sommerville, Ingegneria del software, Addison & Wesley, 2007
[2] Eric Armstrong, The J2EE™ 1.4 Tutorial, 2005
[3] Sun Microsystems, Designing Enterprise Applications with the J2EE™ Platform, Second
Edition,
http://java.sun.com/blueprints/guidelines/designing_Enterprise_applications_2e/,
[08/05/2009]
[4] DEGESYS Premium Solutions, Comparison of Oracle, MySQL and PostgreSQL DBMS,
2008
[5] O’Reilly OnLamp.com, Digg PHP's Scalability and Performance, 2006
[6] Marco Cantamessa, Il Project Management. Un Approccio Sistemico alla Gestione dei
Progetti, ISEDI, 2007
[7] Fiorenzo Franceschini, Quality Function Deployment: uno strumento progettuale per co-
niugare Qualità e Innovazione, Il Sole 24 ORE Libri, 2003
[8] Michael E. Porter, The Five Competitive Forces That Shape Strategy, Harvard Business
Review, 2008
[9] Magic Software Enterprises, Maximizing Benefits from Software-as-a-Service via Seam-
less Integration with On-Premises Applications, 2007
[10] Scott Sehlhorst, Software-as-a-Service vs. Software-as-a-Product, 2008
[11] The Sectoral e-Business Watch, ICT e tendenze dell’e-business nel 2008, 2008
Bibliografia
135
Siti Web
[12] AboveNet, http://www.above.net, [14/10/2009]
[13] Cefin Systems, http://www.cefinsystems.com, [22/09/2009]
[14] eXtraSheet, http://www.extrasheet.com, [03/08/2009]
[15] Sateltrack, http://www.sateltrack.com, [22/09/2009]
[16] Krescendo, http://www.krescendo.com, [22/09/2009]
[17] W3C, http://www.w3.org, [16/12/2009]
[18] DSC, http://www.dsc.net, [22/09/2009]
[19] Java Platform, http://java.sun.com, [04/08/2009]
[20] DabbleDB, http://dabbledb.com, [24/09/2009]
[21] Wavemaker, http://www.wavemaker.com , [20/10/2009]
[22] Xataface, http://xataface.com, [20/10/2009]
[23] VFront, http://www.VFront.org, [23/10/2009]
[24] Apache Click, http://click.apache.org, [20/10/2009]
[25] CentOS, http://www.centos.org, [22/07/2009]
[26] PHP, http://php.net, [21/07/2009]
[27] MySQL, http://www.mysql.com, [13/11/2009]
[28] Gartner, http://www.gartner.com, [22/01/2010]
