UNIVERSITÀ DEGLI STUDI DI PARMA
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
UNIVERSITÀ DEGLI STUDI DI PARMA
Dipartimento di Matematica e Informatica
Corso di laurea in Informatica
Interfacce a Programmi Complessi in
Ambito Web e Mobile
Interfaces to Complex Programs for Web and Mobile
Studente: Relatore:
Petrone Veronica Destri Giulio
Anno Accademico 2015 - 2016
1
Ringraziamenti Nel 2012 ho intrapreso questo nuovo percorso di formazione e da allora sono passati 4 anni di duro e intenso lavoro, ma alla fine sono riuscita ad arrivare a questo magnifico traguardo della mia carriera. Sono uscita dalle superiori come perito informatico e ho continuato il ramo per perfezionare e migliorare la mia esperienza in maniera esponenziale in questo campo meraviglioso sempre pieno di sviluppi e sorprese. Ora vorrei poter ringraziare tutti coloro che mi sono stati accanto in tutti questi anni. Ringrazio i miei genitori Vincenzo e Rosaria perché mi hanno dato la possibilità di realizzare questo sogno moralmente, ma sopratutto economicamente. Un ringraziamento particolare al mio amore Alessandro che mi ha accompagnato dalle superiori fino ad oggi dandomi sempre la forza di combattere e farmi alzare ogni volta che qualcosa mi abbatteva. Un grazie speciale a Lamine, la persona che che mi è stata maggiormente accanto in questi ultimi 3 anni, condividendo momenti di felicità e difficoltà superati sempre insieme. Abbiamo sudato duramente ma allo stesso tempo si è creata un’amicizia splendida, un pilastro fondamentale che mi ha dato sempre tanta forza e sostegno migliorando il mio modo di pensare e lavorare. Vorrei anche ringraziare i miei amici che hanno dovuto subire i miei noiosi sfoghi universi- tari e mi hanno sempre aiutato in caso di bisogno: Sara, Poggi, Giuliana, Michela, Ilenia, Ilaria R. e tanti altri, troppi da poter essere elencati tutti. Ci sono delle persone che vorrei ringraziare con il cuore in mano perché sono davvero molto importanti per me, sono come parte della mia famiglia fin da quando sono nata e vorrei ringraziarli per essermi stati vicini sempre nel bene e nel male sostenendomi in tutto e per tutto: Zia Pina, Annamaria, Grazia, Carlo, Ilaria C. e Francesca. È doveroso ringraziare chi mi ha spinto per arrivare a questo traguardo come Prof. Di Nunzio, Prof. Lori e Prof.ssa Lando che mi hanno riempito la testa esaltando tutte le mie qualità e facendomi capire che sarei potuta arrivare dove sono ora. Infine un doveroso grazie al Prof. Ing. Giulio Destri per avermi dato la possibilità di collaborare e svolgere lo stage formativo presso l’azienda SiGrade SPA, potendo realizzare questo progetto per arricchire il mio bagaglio culturale sulla realizzazione di un software ben costruito e che si affacci al mondo responsiveness il quale oggi prende sempre più piede. Sicuramente questo traguardo non è una fine ma un’altra tappa della vita raggiunta che spero mi dia un grande inizio nel mondo del lavoro.
Indice
Struttura del testo 5
1 Introduzione 6
1.1 Il mondo del software bancario e dei servizi italiano . . . . . . . . . . . . . . 6
1.2 Il contesto multipiattaforma . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Le necessità per il futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 L’evoluzione verso il mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Il ciclo di vita del software 12
2.1 I modelli tradizionali dello sviluppo software e il suo ciclo di vita . . . . . . 12
2.1.1 I modelli tradizionali dello sviluppo software . . . . . . . . . . . . . . 12
2.1.2 Il suo ciclo di vita . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 I limiti dei processi di sviluppo del software . . . . . . . . . . . . . . . . . . 18
2.3 La necessità di ridurre i tempi di sviluppo . . . . . . . . . . . . . . . . . . . 19
2.4 Automazione della produzione del software . . . . . . . . . . . . . . . . . . . 21
3 Il Framework di SiGrade 22
3.1 Lo sviluppo dipartimentale object-oriented . . . . . . . . . . . . . . . . . . . 23
3.2 SiTemplateMVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 jQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2 ASP.NET MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Architettura SiTemplateMVC . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Integrazione con mondo mobile: front-end web responsive . . . . . . . . . . 26
4 Attività operativa 27
4.1 AngularJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.1 Che cos’è AngularJS? . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.2 Le principali caratteristiche di AngularJS . . . . . . . . . . . . . . . 28
4.1.3 Comunicazione tra Client e Server . . . . . . . . . . . . . . . . . . . 34
4.2 Integrazione di AngularJS in SiTemplateMVC . . . . . . . . . . . . . . . . . 35
4.2.1 Nuova Architettura SiTemplateMVC . . . . . . . . . . . . . . . . . . 35
4.2.2 Struttura architetturale delle View . . . . . . . . . . . . . . . . . . . 35
4.2.3 Le View prima dell’integrazione di AngularJS . . . . . . . . . . . . . 36
4.2.4 Responsive Web Design . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.5 AngularJS e Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.5.1 Le nuove View dopo la loro integrazione . . . . . . . . . . . 40
4.2.5.1.1 Menu e Footer . . . . . . . . . . . . . . . . . . . . 45
4.2.5.1.2 Diagramma di Navigazione . . . . . . . . . . . . . 47
4.3 Generatore di codice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.1 Test su più device . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5 Conclusioni e Sviluppi futuri 49
2015 - 2016 4 Veronica Petrone
Struttura del Testo La tesi è suddivisa in 5 capitoli, ognuno dei quali è dedicato ad una tematica specifica. Nel primo capitolo viene descritto come il mondo del software bancario si è evoluto negli anni cercando di capire le sue necessità per il futuro per quanto riguarda il contesto multi- piattaforma e l’evoluzione verso il mobile. Nel secondo capitolo, applicando quanto visto nel primo, sono definiti i modelli fonda- mentali dei meccanismi per realizzare in modo ottimale la progettazione di un software. Inoltre viene anche descritto come velocizzare la produzione del software rispettando i tem- pi di sviluppo necessari per il cliente. Nel terzo capitolo viene spiegato il Framework SiTemplateMVC dell’azienda dove il tiro- cinio è stato svolto. L’attenzione è posta solo a descrivere brevemente l’architettura di tale Framework ed alcune delle tecnologie usate durante il suo sviluppo. In più viene precisato per quale motivo è necessario avere un’applicazione che si integri nel mondo mobile con un front-end web responsive. Nel quarto capitolo, partendo da quello precedente, ho esposto il mio contributo sul la- voro svolto durante lo stage. Ho preso il progetto già trasformato nella sua parte back-end come descritto nella Tesi di Lamine Ndiaye e mi sono occupata di modificare la parte front- end usando AngularJS e Bootstrap in modo da avere un’applicazione con un’interfaccia a programmi complessi in ambito web e mobile. Ho accennato in breve le caratteristiche di AngularJS e spiegato come può essere incorporato in SiTemplateMVC, quindi ho fatto una descrizione dettagliata per la trasformazione delle interfacce del sito in modo che possa adattarsi su qualsiasi tipo di device. Ho spiegato l’importanza del generatore di codice usato durante il lavoro, marcando quali sono i suoi vantaggi e per quale motivo viene usa- to, e infine ho effettuato i vari test sui diversi dispositivi. Nel quinto capitolo, ho descritto come il lavoro svolto abbia arricchito il mio bagaglio culturale, i vantaggi che ho ottenuto, la lezione appresa durante lo svolgimento del tirocinio e i possibili sviluppi futuri per il miglioramento del progetto su cui ho lavorato. 2015 - 2016 5 Veronica Petrone
1 Introduzione
Il mondo del software bancario ha attraversato una lunga evoluzione negli ultimi 50 anni,
nonostante l’avvento di nuove tecnologie e linguaggi di programmazione, oltre il 90% degli
istituti di credito europei si sono affidati e si affidano ancora tutt’ora al COBOL come
linguaggio di sviluppo delle loro principali procedure IT. Da questo punto di vista il CO-
BOL non è da considerarsi in via di estinzione, anzi si potrebbe dire che nonostante la sua
longevità sia il caposaldo del maggior numero di transazioni a livello mondiale. Quindi
gli istituti bancari non intendono allontanarsi da questo linguaggio perché il solo pensiero
di dover elaborare nuove procedure bancarie, abbandonando così COBOL, spaventa tutti
i principali manager bancari. Con il crescere esponenziale delle nuove tecnologie le ban-
che sono costrette ad "abbandonare" l’idea di avere tutto basato sul COBOL, integrando
nuovi linguaggi di programmazione per aggiungere le nuove funzionalità, migliorando nel
contempo la sicurezza e le infrastrutture IT. I servizi di ultima generazione forniti dagli
istituti bancari italiani sono di vari tipi come l’Home Banking, il Mobile Banking, Internet
Banking, Smart Web, ecc. Infatti secondo l’ultimo rapporto ISTAT "Cittadini e tecno-
logie", l’utilizzo di tali servizi è aumentato molto tra il 2013 e il 2016, cioè la quota di
utenti che ha utilizzato Internet per usufruire di servizi bancari online (37,4%) ha avuto
un incremento di +4,5 punti percentuali. Ciò è spiegabile soprattutto con l’introduzione
di nuovi applicativi, che oltre ad interessare le banche già esistenti, hanno permesso la
nascita di banche totalmente virtuali che permettono al cliente di operare direttamente sul
proprio conto corrente 24 ore su 24, senza bisogno di figure intermediarie.
In questo contesto si inserisce questa Tesi, il cui obiettivo specifico è di trasformare
un software bancario, orientato alla fruibilità attraverso web e realizzato a partire dal
Framework Jquery, con uno dei migliori Framework di ultima generazione ed integrare tale
software con il mondo mobile o web responsive. Per fare ciò il punto di partenza è stata
un’analisi approfondita del software esistente, in modo da capire meglio come integrare il
nuovo Framework, per non cambiare o riscrivere completamente il progetto già realizzato.
Una parte del progetto della Tesi è stata creata utilizzando un generatore di codice già
a disposizione, per velocizzare i tempi di sviluppo e permettere l’uso del codice per altri
eventuali progetti futuri.
1.1 Il mondo del software bancario e dei servizi italiano
Banche e Assicurazioni si confermano i primi investitori in nuove tecnologie in Italia, rap-
presentando circa un quarto della domanda ICT complessiva. Eppure, restano ancora da
cogliere grandi opportunità di innovazione e miglioramento dell’efficienza. La chiave per
uscirne può essere soltanto una sorta di alleanza tra: i responsabili ICT, il Business e il
sistema dei fornitori, chiamati ad una maggiore collaborazione.
L’attuale assetto del sistema bancario e finanziario italiano è frutto di un complesso
processo che ne ha in pochi anni trasformato la struttura, con l’obiettivo di una maggiore
integrazione nel mercato europeo. Le tappe principali di questo percorso, iniziato nei primi
anni ’90, sono la riforma della normativa di settore, culminata con l’adozione dei due Testi
unici della Banca e della Finanza, che stabiliscono le finalità dell’attività di vigilanza, le
2015 - 2016 6 Veronica Petrone
privatizzazioni, avviate alla fine del 1993, con la trasformazione in società per azioni delle Banche pubbliche, un forte consolidamento e la progressiva apertura all’estero del sistema. Il settore Finance rappresenta da sempre una voce di spesa importante del mercato ICT italiano, con le grandi Banche tra i primi investitori in nuove tecnologie nel nostro Paese. Nello specifico, il settore Finance ha rappresentato nel 2014 in Italia il 24% della spesa ICT complessiva. Il sistema informativo della banca sta fronteggiando un impegnativo processo evolutivo dovuto ai nuovi servizi, alle nuove tendenze di mercato, all’avvento del cloud computing e delle altre tecnologie CAMS (cloud, analytics, mobile e social). Il panorama sta velocemente evolvendo verso l’interconnessione e l’esternalizzazione spinta con infrastrutture e architetture più performanti e flessibili. Il cloud computing rappresenta il nuovo modello di utilizzo e di distribuzione delle risorse ICT e propone soluzioni concrete ai problemi di flessibilità e complessità del sistema informativo. Il settore bancario sta muovendo i primi passi nell’adozione del cloud computing, capitalizzando anni di esperienza su temi quali la virtualizzazione e la sicurezza. Le banche italiane investono molto sulla tecnologia. Nonostante la crisi, la strategia è chiara: con l’ICT si possono generare nuovi profitti e migliori economie di scala. L’ICT è il fattore abilitante per eccellenza [12], secondo le banche è un importante elemento di cambiamento. Ed è la nuova leva demografica, che si sta facendo strada, che ha un rapporto differente con la tecnologia: più profondo e ’nativo’, oltre che più ricco. Il mondo bancario italiano negli ultimi anni ha monitorato l’evoluzione del canale Internet e Mobile e si è attivato rapidamente. Il software bancario ha subito una lunga evoluzione negli ultimi 50 anni ed è ancora in evoluzione, sopratutto per tutti gli istituti di credito che da anni a questa parte offrono numerosi servizi web, ciò comporta una fase di reingegnerizzazione di tutti i processi di gestione. Ci si affida a dei software creati da entità esterne, specializzate in ICT, in modo tale da avere maggior affidabilità e sicurezza del software. 1.2 Il contesto multipiattaforma Lo sviluppo multipiattaforma in ambito mobile consiste nella produzione di software pro- gettato per supportare dispositivi diversi sia per caratteristiche hardware che per sistemi operativi. Questo processo si avvale di tecnologie e strumenti specifici e consente di scri- vere programmi che si adattano automaticamente o con sforzo minimo al contesto in cui vengono eseguiti. L’esigenza di riuscire a sviluppare un applicativo di questo tipo è sentita particolarmente in ambito enterprise grazie ai potenziali vantaggi che si possono avere in termini di riduzione dei tempi e costi per realizzare e mantenere il prodotto. Infatti negli ultimi anni la rapida evoluzione dei dispositivi mobili e la frammentazione del mercato mobile, sia per sistemi operativi sia per tipologie di terminali con caratteristiche hardware differenti, ha portato alla crescita dei costi di sviluppo e, soprattutto, di mantenimento delle applicazioni mobile che devono supportare diverse piattaforme. Le aziende che vogliono produrre un’applicazione di tipo business che possa supportare diversi tipi di terminali mobili devono gestire la frammentazione del mercato mobile, sia per dispositivi sia per sistemi operativi. In questo momento le principali piattaforme sul mercato sulle quali è possibile sviluppare applicazioni mobile enterprise sono iOS, Android, Windows Phone, Windows 7, Windows 8, Windows 10. Questo comporta il dover creare 2015 - 2016 7 Veronica Petrone
una strategia per poter pianificare il modo con cui approcciarsi al multipiattaforma, in
base alle esigenze aziendali, relative ai dispositivi da supportare e ai requisiti dell’applica-
zione, in modo tale da contenere i costi di sviluppo e manutenzione. Infatti sviluppare e
mantenere codice multiplo per diverse piattaforme è diventato complicato e costoso. I pos-
sibili approcci che possono essere adottati sono numerosi ed eterogenei, ognuno con proprie
peculiarità, e nessuno è finora diventato lo standard nello sviluppo multipiattaforma in am-
bito mobile. La maturazione della standardizzazione di HTML5 ci permette di utilizzare
questo insieme di tecnologie open source per lo sviluppo web come punto di riferimento
nella realizzazione di siti web e web application avanzate. Con il termine HTML5 si indica
un’evoluzione dello standard che fa parte della famiglia delle tecnologie web aperte. Esso
tramite un insieme di API (application programming interface) innovative ed un markup
potenziato permette di creare applicazioni sul web avanzate senza ricorrere a software di
terze parti, usati tramite plugin nei browser (esempio Flash o JavaFx). Con esso si ha
avuto un’innovazione sull’aspetto grafico e sull’interazione con l’utente, in modo da otte-
nere una user experience ricca, simile a quella fornita dalle applicazioni native. HTML5
può essere utilizzato anche nello sviluppo multipiattaforma di applicazioni che risiedono
interamente sui dispositivi mobile e desktop. Questa possibilità è fornita dallo sviluppo
di diverse funzionalità innovative in HTML5, che permettono di utilizzare nuove caratte-
ristiche, come audio e video in maniera nativa, oppure l’accesso ai sensori dei dispositivi
mobile tramite Javascript. Nel mercato dello sviluppo multipiattaforma nel settore mobile
sono stati realizzati vari tool di supporto allo sviluppo, ognuno dei quali offre caratteri-
stiche adatte a determinati contesti ma non a tutti, e che quindi devono essere analizzate
per poter scegliere il Framework che fornisce le performance migliori, in base all’ esigenza
dell’applicazione da realizzare e le specifiche richieste aziendali.
Attualmente gli approcci che permettono di sviluppare un software multipiattaforma so-
no diversi, ognuno con determinate caratteristiche a livello architetturale, prestazionale,
tipologia di processo di sviluppo adottato, strumenti a disposizione per la realizzazione e
livello di usabilità raggiungibile.
I tipi di applicazione attualmente esistenti nello sviluppo mobile possono essere catego-
rizzati in 5 insiemi:
• Applicazioni native: sono realizzate per una specifica piattaforma con un SDK,
software development kit, ossia un Framework di sviluppo con un IDE integrato e
strumenti per debugging ed emulazione.
• Applicazioni web mobile: sono applicazioni server-side, costruite con una qualsia-
si tecnologia lato server per la logica di business (PHP, ASP.NET, ecc..) e per creare
la pagina di cui viene eseguito il rendering lato client sul browser. Queste applica-
zioni possono fornire un aspetto più vicino a quello nativo tramite tool aggiuntivi
(esempio Jquery Mobile, AngularJS) che si fondono con le tecnologie web (HTML5,
CSS, BOOTSTRAP e JAVASCRIPT), per visualizzare i contenuti e gestire la logica
applicativa lato client. In questo tipo di applicazioni possono esserci più contesti di
utilizzo, in base alle tecnologie che possono essere integrate nello sviluppo.
2015 - 2016 8 Veronica Petrone
• Applicazioni ibride: come le applicazioni native, vengono installate sul device e
vengono lanciate dal menu del sistema operativo, ma sono sviluppate con le tecnolo-
gie web in aggiunta al codice nativo. Le applicazioni ibride girano in un contenitore
nativo e vengono eseguite come applicazioni native dal sistema operativo. Le pagine
web che ne costituiscono l’interfaccia grafica sono renderizzate da un componente
software, denominato webkit, rendering engine che fornisce all’interfaccia anche i
controlli del browser, ma a differenza di quello fornito come applicazione nativa,
questo viene eseguito all’interno dell’applicazione ibrida. Lo scopo del webkit è in-
terpretare e visualizzare a video le pagine html e processare localmente il codice
javascript. Uno strato software intermedio che fa da bridge software permette di
accedere tramite invocazioni di funzioni javascript ai sensori del device, come ad
esempio l’accelerometro o il giroscopio, e alle funzionalità del sistema operativo altri-
menti inaccessibili; questo accesso infatti al momento è molto limitato per motivi di
sicurezza nelle applicazioni web mobile che utilizzano solo HTML5 e JAVASCRIPT,
che possono accedere solo a un limitato numero di sensori, ad esempio il GPS. Trami-
te l’utilizzo del web kit e delle tecnologie HTML5 e JAVASCRIPT è possibile eseguire
lo stesso codice creato durante lo sviluppo su diversi sistemi operativi, dovendo mo-
dificare solo il contenitore. Ciò consiste nel produrre l’applicazione nativa eseguibile
che conterrà le pagine html e il codice javascript, e sviluppare ad-hoc il software
intermedio tra javascript e le funzioni native del sistema operativo o adottarne uno
già sviluppato da terze parti.
• Custom Container: con queste tecnologie si possono creare applicazioni tramite un
linguaggio proprietario e inserirle in un contenitore customizzato che viene eseguito
nel dispositivo. Il codice prodotto deve essere interpretato a tempo di esecuzione,
e l’interprete che si occupa di farlo può essere inserito nel contenitore o essere in-
stallato a parte sul dispositivo. Nel secondo caso per far funzionare l’applicazione è
richiesta l’installazione dell’interprete. In entrambe le casistiche l’interprete a tempo
di esecuzione si occupa di convertire il linguaggio dell’applicazione in quello della
piattaforma sottostante.
• Cross-Compilation: con queste tecnologie si producono applicazioni trasformando
il codice scritto con un linguaggio di programmazione specifico anche di altre piat-
taforme in codice nativo per le piattaforme di riferimento che sono supportate dal
convertitore. Attraverso l’uso di funzioni sviluppate ad-hoc da richiamare viene map-
pato il linguaggio di origine nel linguaggio di destinazione per la specifica piattaforma
per la quale creare il codice nativo equivalente che fornisce le funzionalità richieste.
1.3 Le necessità per il futuro
Considerando quello che è successo negli ultimi venti anni a livello di tecnologia, pro-
viamo ad immaginare quello che accadrà nei prossimi venti, non possiamo che pensare
ad un’accelerazione dell’evoluzione tecnologica, con impatti sempre più forti, forse anche
inimmaginabili, sul modo di lavorare. Proprio per questo, l’ICT si sta affermando sempre
2015 - 2016 9 Veronica Petrone
più come leva strategica anche in ambito Bancario. Nelle Banche possiamo osservare che
alcuni modelli di business sono costruiti attorno ad Internet, ai call-center e alle banche
online. Naturalmente ciascuna banca ha il suo modello, ma in ogni caso ormai l’ICT è
diventata una leva strategica che permette di perseguire e superare i fattori critici di suc-
cesso. La tecnologia è sempre più presente nell’attività operativa della banca; infatti, molte
attività di interazione con il cliente sono ormai demandate a strumenti tecnologicamente
avanzati come ATM intelligenti, cash dispenser, Internet, ecc. A questo punto però c’è
addirittura da chiedersi se l’allineamento dell’ICT al business sia una strategia sufficiente
per un mondo in continua evoluzione, in cui l’innovazione tecnologica è diventata sempre
più rapida e dirompente.
La maggior parte di Istituti Bancari italiani ha ben chiaro quali sono i campi in cui investire
in futuro:
• Digitalizzazione;
• Innovazione;
• Multicanalità integrata;
• Maggior efficienza delle infrastrutture.
Sono queste la priorità nei programmi d’investimento in tecnologia delle banche ita-
liane, insieme al costante adeguamento alle normative nazionali ed europee e all’ulteriore
potenziamento dei sistemi di sicurezza. Le ottiche di investimenti per il futuro cambiano
aspetti concreti della vita della banca di tutti i giorni grazie alla tecnologia: dallo sportello,
mentre crescono sempre più i canali diretti come l’internet banking e i contact center, al
mobile banking e il ruolo dei social network anche su processi e operazioni. Quindi diventa
sempre più importante la gestione documentale senza carta e l’evoluzione di tutto il conte-
sto attorno al quale ruota il funzionamento del back office delle banche. Infine, cambiano
anche le attività di supporto, tra le quali la più classica è ovviamente l’organizzazione e ge-
stione delle risorse umane, che con la tecnologia informatica vede una radicale evoluzione.
Nuove competenze, nuove specializzazioni necessarie anche al funzionamento della nuova
cultura innovativa delle banche.
1.4 L’evoluzione verso il mobile
La rapidissima evoluzione delle tecnologie dell’informazione e della comunicazione ha mo-
dificato radicalmente le nostre abitudini determinando drastici cambiamenti del nostro stile
di vita. Attività che assorbivano molto del nostro tempo - oggi vera risorsa scarsa - sono
divenute ora semplici e rapide e la connessione perenne ci consente di svolgerle indipen-
dentemente dal luogo nel quale ci troviamo. Svegliati dall’allarme impostato sul nostro
cellulare, consultiamo le notizie della mattina dal nostro tablet. Durante il tragitto verso il
lavoro utilizziamo il nostro smartphone per accedere ai social network, comunicare con gli
amici tramite instant messaging, consultare la nostra casella di posta o ascoltare musica. Il
nostro lavoro si svolge prevalentemente tramite strumenti informatici ed è stato facilitato
2015 - 2016 10 Veronica Petronedall’avvento degli strumenti di comunicazione digitali che rendono immediato lo scambio di informazioni annullando di fatto le distanze. Dal nostro dispositivo possiamo consultare la cartella sanitaria, la posizione pensionistica, la situazione dei nostri investimenti, il saldo di conto corrente e disporre bonifici, comunicare con enti pubblici, effettuare prenotazioni e qualsiasi tipo di acquisto. I meriti dell’evoluzione o meglio della rivoluzione digitale non sono limitati alla semplificazione della nostra vita ma consistono in una vera e propria otti- mizzazione dell’agenda quotidiana, nella diffusione dell’informazione che accresce le nostre conoscenze e capacità di valutazione e nella tempestività con la quale possiamo agire. Dopo un’iniziale diffidenza, negli ultimi anni gli investitori italiani hanno aderito sempre più numerosi all’offerta di servizi di trading e banking online, determinando un cambia- mento radicale nelle abitudini in questo settore. In questo campo l’innovazione tecnologica, anzichè ridurre il livello di servizio rendendolo standardizzato ed impersonale, ha ridotto i tempi finora dedicati ad attività a basso valore aggiunto ed i conseguenti costi, consen- tendo di prestare sempre maggiore attenzione a questioni più rilevanti. La pervasività dell’evoluzione digitale non poteva pertanto che apportare benefici anche nel campo del private banking. La solida tradizione e l’elevato livello del servizio offerto dalle banche ai clienti privati trovano ora un supporto negli strumenti messi a disposizione dall’evoluzione digitale, che hanno semplificato e reso più efficiente il rapporto tra la banca ed il cliente, cogliendo appieno le nuove opportunità tecnologiche, di semplificazione e di interazione che stanno profondamente rivoluzionando la nostra società. L’interazione con il proprio consu- lente è stata resa più fluida grazie all’utilizzo da parte del private banker di mobile device per l’illustrazione delle proposte di investimento, delle caratteristiche del portafoglio e del- l’andamento dei mercati. L’introduzione della Firma Digitale nell’ambito di un servizio di web advisory consente di fruire in mobilità dei servizi di consulenza finanziaria avanzata: il Cliente ha piena libertà di tempi e luoghi per valutare le proposte di investimento ed attivare - con pochi e semplici passaggi - l’eventuale fase implementativa delle decisioni condivise, anche in un momento successivo all’incontro con il proprio consulente. Anche la conservazione e consultazione della documentazione sottoscritta digitalmente sono age- volate dalla totale eliminazione dei supporti cartacei. Tutto il processo è caratterizzato da elevati livelli di sicurezza, grazie alla Firma Digitale ed ai rigorosi protocolli in materia adottati dalla banca. L’interazione umana resta insostituibile ma l’avvento del digitale ne aumenta il valore li- berando tempo di qualità dedicato all’analisi, alla comprensione e al confronto. Il mobile banking rappresenterà un tassello fondamentale per il futuro della distribuzione di servi- zi bancari. La diffusione dell’utilizzo di internet in mobilità rappresenta, infatti, uno dei trend più importanti di questi anni, soprattutto in Italia, e una delle sfide strategiche per il futuro dell’industria bancaria, abilitando processi di vendita/gestione delle transazioni in concomitanza con il manifestarsi del bisogno del cliente. Il mobile banking sta rac- cogliendo un interesse crescente da parte della popolazione italiana: secondo i dati della "School of Management" del Politecnico di Milano, le app più scaricate dagli utenti mobile sono proprio quelle del settore bancario/finanziario, seguite dal settore viaggi/trasporti e telecomunicazioni. Secondo il "4◦ Osservatorio sul mobile banking" dell’ABI, il 100% delle banche intervistate (campione rappresentativo del 50% del totale attivo del settore) offre 2015 - 2016 11 Veronica Petrone
oggi almeno un’app per smartphone e il 77% propone anche un’app per tablet. Proprio il mobile banking è indicato come uno dei canali sui quali nel breve periodo saranno effettua- ti maggiori investimenti. Secondo il rapporto AbiLab del Politecnico di Milano "Mobile banking: un’app per tutti" tra il 2014 e il 2015 il numero di clienti che accedono ai servizi bancari tramite smartphone e tablet è cresciuto dell’82% in Italia, raggiungendo i 4,4 milioni di clienti. Nel 2014 sono state scaricate in media 8.800 app bancarie al giorno, il 17% in più rispetto al 2013. I giudizi degli utenti sulle app bancarie sono più che positivi, con un apprezzamento che raggiunge più di 4 stelle su 5 quindi la maggior parte delle banche sta sviluppando applicazioni ad-hoc per specifici servizi, come i pagamenti trami- te smartphone, il portafoglio elettronico, l’operatività sui mercati, l’assistenza clienti, ma anche per specifici segmenti di clientela. 2 Il ciclo di vita del software Il software ha ormai decenni di vita. I primi calcolatori programmabili entrarono nel mer- cato negli anni ’50. Oggi il software è pervasivo, non solo nei sistemi informativi di aziende ed organizzazioni [12], ma anche entro le automobili (centraline), gli elettrodomestici, i sistemi industriali, ecc; in generale nella maggior parte degli strumenti che determinano la nostra vita di ogni giorno. Ciò nonostante ancora oggi esistono tante problematiche legate allo sviluppo di software, che troppo spesso richiede tempi più ampi o costi maggiori di quanto preventivato. Inoltre il software non è un prodotto "statico" che, una volta com- pletato rimane costante ma, nella maggior parte dei casi, si deve evolvere nel tempo perché cambiano i presupposti che ne hanno richiesto la creazione[5]. 2.1 I modelli tradizionali dello sviluppo software e il suo ciclo di vita 2.1.1 I modelli tradizionali dello sviluppo software Nei modelli tradizionali, lo sviluppo software avviene attraverso una successione di fasi differenti, l’output di ogni fase costituisce l’input della successiva. Si tratta di modelli ite- rativi che, solitamente, prevedono che una fase non possa iniziare se prima non è terminata quella che la precede. Il modello tradizionale per eccellenza è il modello a cascata (Wa- terfall) la cui prima formale descrizione è riportata in un articolo del 1970 di Winston W. Royce. La prima definizione del modello a cascata appare invece in uno scritto del 1976 di Thomas E. Bell e T.A. Thayer. Questo modello ha origine in industrie manifat- turiere ed edili, settori altamente strutturati nei quali modifiche in corsa al prodotto sono fattibili, ma a costi molto elevati. Ovvio pertanto che venga posto il massimo rigore sulle fasi di analisi e progettazione. Dal momento che, agli albori dello sviluppo software, non erano stati "pensati" modelli atti allo scopo, non si fece altro che mutuare questo modello iterativo in uso nelle imprese manifatturiere ed implementarlo nello sviluppo software. Il modello prevede fasi successive: Raccolta ed analisi requisiti, Design, Implementazione, Integrazione, Test, Installazione e Manutenzione. 2015 - 2016 12 Veronica Petrone
Figura 1: Grafico del modello a cascata Le regole di implementazione del modello a cascata stabiliscono che una buona percen- tuale del tempo dedicato al progetto deve essere investito nelle fasi di raccolta ed analisi dei requisiti. Tipicamente viene investito il 20-40% del tempo a disposizione nelle fasi di Raccolta ed Analisi dei requisiti ed in quella di design. Il 30-40% viene dedicato alla fase di implementazione ed integrazione, il resto del tempo è dedicato a test ed instal- lazione. L’idea centrale è che il tempo investito precocemente per assicurare che tutti i requisiti vengano correttamente rispettati comporta notevoli benefici in seguito. In termini monetari, prevenire un bug durante una delle fasi iniziali (Requisiti o Design) comporta uno sforzo economico enormemente minore rispetto al risolverlo durante una fase avanzata come ad esempio Implementazione o Test (dalle 50 alle 200 volte più oneroso). Pertanto la metodologia rigorosa di sviluppo a cascata stabilisce che una fase non possa iniziare se quella che la precede non è completa al 100%. Sulla base del modello a cascata sono nati altri modelli che ne condividono le linee guida, seppur con variazioni più o meno leggere, quali, ad esempio, la possibilità di ritornare alla fase precedente o addirittura alla fase di Design, qualora emergano criticità durante la fase in corso, tali da ostacolarne il progresso. 2015 - 2016 13 Veronica Petrone
Figura 2: Modello modificato con possibilità ritorno a fase precedente Nel suo waterfall final model, W. Royce illustrò che il feedback raccolto durante la fase di Test, potrebbe evidenziare problemi tali da raccomandare un ritorno alla fase di Design ed, eventualmente, da questa alla Raccolta o all’Analisi dei requisiti, qualora sia necessaria una rivisitazione dei requisiti per risolvere questi problemi. Figura 3: Modello modificato, con possibile ritorno alle fasi di Design ed Analisi dei requisiti 2015 - 2016 14 Veronica Petrone
2.1.2 Il suo ciclo di vita Con il termine "ciclo di vita" del software ci si riferisce alle fasi attraversate d a un progetto software durante la sua evoluzione, dall’idea iniziale alla manutenzione. Il risultato finale è il prodotto software stesso, accompagnato da tutta la documentazione ad esso associata. Vengono elencate e descritte le fasi comprese nella struttura base di un progetto software: • Raccolta dei requisiti • Analisi • Progettazione • Implementazione • Test • Installazione in produzione • Manutenzione (ordinaria ed evolutiva) Raccolta dei requisiti ed analisi Il progetto inizia con la fase di raccolta dei requisiti. In questa fondamentale fase vengono adottate e combinate tra loro diverse tecniche volte ad "estrarre dalla mente del cliente o del committente tutto ciò che il progetto software dovrà fare". Il "Manuale dell’Anali- sta" [14] definisce questa fase come requirement elicitation, che può essere svolta con una combinazione di 12 metodi diversi quali ad esempio: Interviste, Osservazioni sul campo, Gruppi di Lavoro, ecc. Il termine elicitazione è mutuato dalla psicologia e significa "tirare fuori" informazioni, in questo caso, mediante domande o altri comportamenti stimolanti. Alla fase di raccolta requisiti segue quella di analisi. Fase estremamente importante, in quanto un errore commesso a questo punto può avere ripercussioni molto serie sul risultato finale. A seconda delle dimensioni del progetto l’analisi può essere svolta in toto all’inizio, oppure iterativamente durante il processo. A seconda del modello di sviluppo che viene adottato, l’analisi può essere ripetuta o meno durante il ciclo di vita del software. L’obiettivo della fase di analisi è la descrizione completa e formalizzata, con un livello di dettaglio adeguato di tutto ciò che il sistema deve fare (requisiti funzionali), dell’ambiente in cui dovrà operare (requisiti non funzionali) e dei vincoli che dovrà rispettare. Notare che la descrizione specifica cosa il sistema dovrà fare, non il come (modello a scatola nera). Queste descrizioni vengono raccolte in documenti chiamati documenti di specifica, brevemente specifiche. La fase di progettazione (Design) Partendo dall’output della fase di analisi, che deve essere preciso e privo di ambiguità, la fase di progettazione definisce le istruzioni operative per la realizzazione del progetto (dettagli implementativi). Le istruzioni devono avere il giusto livello di dettaglio ed essere 2015 - 2016 15 Veronica Petrone
Figura 4: Impatto degli errori fatti in fase di raccolta delle specifiche sulle fasi successive. raccolte in documenti opportunamente strutturati. Pertanto, la progettazione di un’ap- plicazione è composta dalle attività per individuare la soluzione implementativa migliore rispetto agli obiettivi funzionali, a quelli non funzionali ed ai vincoli. Queste attivitá possono essere di varia natura, possono essere svolte in tempi e modi diversi in base all’ap- proccio seguito, ma in generale aiutano progettisti e team di sviluppo a prendere decisioni importanti, spesso di natura strutturale. Il risultato della progettazione è la definizione dell’architettura del sistema, intendendo con questo termine l’organizzazione strutturale del sistema stesso, che comprende i suoi componenti software, le proprietà visibili ester- namente di ciascuno di essi (l’interfaccia dei componenti) e le relazioni fra le parti. In analisi, requisiti e struttura del sistema sono rappresentati in forma astratta e (teorica- mente) indipendente dalla tecnologia. La progettazione tiene conto anche di tutti i fattori relativi all’utilizzo di una tecnologia concreta e quindi, a differenza dell’analisi, la proget- tazione non può essere svolta indipendentemente dalla tecnologia utilizzata. Durante la progettazione devono anche essere definiti tutti gli aspetti necessari per una implemen- tazione non ambigua. Uno strumento molto usato nella progettazione è il diagramma di flusso, oppure la sua evoluzione UML activity diagram. Entrambi gli strumenti servono a realizzare la scomposizione delle attività da compiere in elementi sempre più piccoli che possano essere facilmente implementati con opportuni insiemi di istruzioni del linguaggio di programmazione scelto. La fase di implementazione (Coding) La scrittura del codice sorgente può essere svolta con molti strumenti, il più semplice dei quali è l’editor di file ASCII di base (notepad, gedit, vi, emacs, ecc...). Per la complessità che i moderni linguaggi ad oggetti richiedono però tale approccio è troppo poco produttivo. Dovendo infatti garantire il rispetto di tempi stretti, è necessario disporre di tutte le funzio- ni di facilitazione integrate entro un unico strumento per la scrittura del codice sorgente. Un Integrated Development Environment (IDE), è un software che aiuta i programma- tori nello sviluppo del codice. Normalmente consiste in un editor di codice sorgente, un 2015 - 2016 16 Veronica Petrone
compilatore e/o un interprete, un tool di building automatico, e (solitamente) un debugger. Ormai sempre più spesso è integrato con sistemi di controllo di versione (SVN o GitHub, ad esempio), con sistemi di gestione delle dipendenze da librerie esterne (Maven, ad esem- pio) e con uno o più tool per semplificare la costruzione di una GUI. Alcuni IDE, rivolti allo sviluppo di software orientato agli oggetti, comprendono anche un navigatore di classi, un analizzatore di oggetti e un diagramma della gerarchia delle classi. Sebbene siano in uso alcuni IDE multi-linguaggio, come Eclipse, NetBeans e Visual Studio, generalmente gli IDE sono rivolti ad uno specifico linguaggio di programmazione. La scrittura del codice sorgente, per quanto spesso poco considerata, rimane comunque la fase fondamentale di ogni progetto informatico. L’analisi e la progettazione possono essere state svolte al me- glio, ma, se il codice viene scritto male, l’applicazione risultante avrà problemi e funzionerà male. Facendo un’analogia nell’ambito dell’ingegneria civile, è chiaro che anche il progetto più bello, se i pilastri non sono fabbricati bene, se i mattoni non sono posati con accura- tezza o se i materiali impiegati sono di scarso pregio, darà origine ad un edificio di pessima qualità. Anche per questo, metodologie di programmazione più moderne tendono a fare diventare la fase di scrittura del codice quella principale in tutto il progetto informatico. Durante la stesura del codice ha luogo anche il primo debugging, ossia la rimozione degli errori di sintassi e degli errori più evidenti, come la mancata inizializzazione di variabili, che possono compromettere la compilazione o il funzionamento del programma. Gli IDE più moderni hanno ottimi sistemi di live debug. Tendono ad evidenziare in tempo reale, oltre al codice che inevitabilmente porterà ad errori di compilazione, anche frammenti di codice inutili, blocchi ripetuti, inizializzazioni di variabili non necessarie, ecc. La fase di Test Una volta che il programma è stato completato o comunque può iniziare a funzionare, occorre verificare che il suo funzionamento sia conforme a tutte le specifiche che erano state stabilite nella fase di analisi. Questo è lo scopo fondamentale della fase di test. Gli errori che portano al non rispetto delle specifiche sono di solito molto più insidiosi da scoprire rispetto a quelli che vengono trovati durante il debugging. Non sono errori di sintassi, ma errori logici e concettuali, come, per esempio, lo scrivere il segno ’+’ invece del segno ’-’ entro un algoritmo che richieda la sottrazione e non la somma. La fase di test prevede quindi di verificare il comportamento effettivo del programma rispetto a quello previsto e di segnalare le differenze di comportamento ai programmatori che dovranno procedere alla ricerca e all’eliminazione delle cause di tali differenze. I modelli di sviluppo software più moderni pongono l’accento sulla fase di test, anteponendola in alcuni casi alla fase di sviluppo e prevedendo l’esistenza di suite di test eseguite automaticamente durante la build ed il packaging del progetto, allo scopo di ridurre il più possibile il rischio di regressione. La fase di avvio ed entrata in produzione Dopo il test, raggiunto un livello sufficiente di qualità, il programma può entrare in pro- duzione. Questo termine ha un significato diverso secondo il tipo di programmi in rea- lizzazione. Per i programmi destinati alla vendita presso il pubblico, o alla distribuzione 2015 - 2016 17 Veronica Petrone
se gratuiti, questa fase rappresenta il rilascio sul mercato, fisico (negozio), virtuale (e-
commerce, download) o mobile (PlayStore, AppStore) che sia. Per i programmi realizzati
specificatamente per un cliente (i cosiddetti "programmi custom"), questa fase rappresenta
l’installazione ed il collaudo presso la sede del cliente che li ha richiesti. In ultimo, per
le applicazioni web (siti di e-commerce, portali, gaming-on-line, ecc) rappresenta l’instal-
lazione ed il collaudo su uno o più server web (Apache, Tomcat, IIS, ecc) ed il tuning di
questi ultimi. Al termine di questa fase i programmi iniziano la propria vita operativa,
durante la quale svolgono il compito previsto nel contesto per cui sono stati progettati, che
può proseguire anche per molti anni.
La fase di Manutenzione
Durante la vita operativa possono verificarsi necessità di interventi correttivi o di aggiorna-
mento sui programmi, che prevedono nuove fasi di progettazione, implementazione e test.
Tali interventi correttivi sono raggruppabili in due distinte famiglie:
• Manutenzione ordinaria, l’insieme di interventi correttivi necessari per via di
errori sfuggiti ai test o dovuti al funzionamento del programma in condizioni non
previste durante la sua progettazione, come ad esempio il funzionamento su Windows
8 di un programma nato per Windows XP;
• Manutenzione evolutiva, l’insieme di interventi di variazione od arricchimento
delle funzioni del programma per via di nuove necessità operative del programma
stesso; un esempio è l’aggiornamento continuo dei programmi gestionali per stare
aggiornati rispetto alle normative fiscali. In generale, comunque, ogni programma
durante la sua vita è soggetto a interventi evolutivi e correttivi. Solo una piccola
percentuale di programmi non viene più toccata dopo il rilascio.
2.2 I limiti dei processi di sviluppo del software
Gli attuali processi di sviluppo purtroppo hanno ancora dei limiti, i processi a Cascata
riscontrano già problemi alle prime verifiche concrete al termine della fase di test. Il
processo evolutivo invece fornisce solo una soluzione parziale ai problemi del modello a
cascata per cui elimina gli errori nei requisiti ma non riduce la distanza temporale per
il completamento del ciclo di sviluppo. La pianificazione dei progetti condotti in modo
iterativo è più complessa. Il piano di un processo iterativo evolve durante tutta la durata
del progetto stesso, e richiede un controllo sistematico degli avanzamenti. Un punto cruciale
per il successo di un progetto iterativo è la collaborazione sistematica tra committenti e
gruppi di progetto. Un processo di sviluppo software per eliminare i propri limiti deve
possedere alcune caratteristiche fondamentali per il suo sviluppo, più precisamente un
processo software deve essere:
Comprensibile: capire perché si è scelto di seguire un modello di sviluppo piuttosto
che un altro;
Visibile: a che punto si è giunti nello sviluppo, seguendo i dati precedentemente
riportati sulle documentazioni di ciascuna fase del ciclo di vita del software;
2015 - 2016 18 Veronica Petrone Supportabile: il processo deve essere supportato dagli strumenti che si decide di
utilizzare per lo sviluppo del software;
Accettabile: da coloro i quali si accingono a realizzarlo;
Robusto: al punto di essere flessibile ai cambiamenti che potrebbero influenzare lo
sviluppo del software;
Rapido: nel produrre il software desiderato, ma quest’ultima caratteristica potrebbe
scontrarsi con la visibilità stessa del processo software;
2.3 La necessità di ridurre i tempi di sviluppo
Esistono le "Metodologie Agili" con le quali i team di sviluppo software sono in grado
di ridurre sensibilmente il rischio di non rispetto dei tempi e/o di commettere errori di
interpretazione dei requisiti, organizzando il proprio lavoro in piccole iterazioni, chiamate
sprint, della durata di poche settimane (tipicamente 2-3) che permettono il rilascio del
software in modo incrementale. Con il termine "Metodologie Agili" ci si riferisce ad una
serie di metodologie di sviluppo software, ispirate dal "Manifesto Agile", impiegate per
superare i limiti emersi dal modello tradizionale "a cascata". Quindi grazie a queste meto-
dologie i progetti software di entità medio-grande possono essere suddivisi in tanti progetti
di dimensioni più piccole, aventi ciclo di vita proprio, rilascio in produzione compreso,
lavorabili nell’ambito di un singolo periodo-unità di lavoro (sprint). Agile non è, in se, un
processo caratterizzato da regole, ma è un insieme di linee guida che vengono poi imple-
mentate dalle diverse metodologie.
Tra le più comuni citiamo:
X RAD - Sviluppo rapido d’applicazione
Questo metodo detto in inglese Rapid Application Development (RAD), definito da
James Martin all’inizio degli anni ’80, consiste in un ciclo di sviluppo corto basato
su 3 fasi: Inquadramento, Design e Costruzione, in un tempo ideale di 90 e di 120
giorni massimo.
X DSDM
Il Dynamic Software Development Method (DSDM) è stato attuato basandosi sul
metodo RAD per riempire alcune sue lacune, soprattutto offrendo un canovaccio che
consideri l’insieme del ciclo di sviluppo. I principi sulla quale si basa tale metodo
sono:
– Un coinvolgimento degli utilizzatori
– Uno sviluppo interattivo e crescente
– Una frequenza di consegna elevata
– L’integrazione dei test in ogni tappa
– L’accettazione dei prodotti consegnati dipende direttamente dalla soddisfazione
dei bisogni
2015 - 2016 19 Veronica PetroneX UP - Unified Process
Il metodo di Processo Unificato (UP) è un processo di sviluppo interattivo e crescente,
il che significa che il progetto è diviso in fasi molto brevi alla fine di ognuna delle
quali viene rilasciata una nuova versione migliorata. Si tratta di una procedura
basata sulla creazione di modelli UML per la descrizione dell’architettura software
(funzionale, software e hardware) e l’elaborazione di casi d’utilizzo che permettano
di descrivere i bisogni e le esigenze degli utenti.
X XP - eXtreme Programming
Il metodo XP definisce alcune pratiche che permettono di sviluppare un software nelle
condizioni ottimali mettendo il cliente al centro del processo di sviluppo, in stretta
relazione con il cliente. L’eXtreme Programming è basato soprattutto sui seguenti
concetti:
– Le equipe di sviluppo lavorano direttamente con il cliente su dei cicli molto brevi
da una a due settimane massimo.
– Le consegne della versione del software arrivano molto presto e ad una frequenza
elevata per massimizzare l’impatto dei feedback utenti.
– L’equipe di sviluppo lavora in totale collaborazione, le persone intervengono
anche sul codice scritto da altri e, spesso, lavorano in coppia sullo stesso codice
– La codifica è provata e ripulita durante tutto il processo di sviluppo.
– Alcuni indicatori permettono di misurare l’avanzamento del progetto per l’ag-
giornamento del piano di sviluppo.
2015 - 2016 20 Veronica PetroneIn definitiva, queste sono le principali differenze tra sviluppo Tradizionale e Agile Program-
ming:
Agile Waterfall
Architettura infomale ed incrementale Architettura molto documentata e com-
pletata prima dell’inizio del coding
La ownership del codice è condivisa tra gli Ogni sviluppatore è responsabile di una
sviluppatori determinata area
Integrazione continua Integrazione fatta alla fine o a tappe
predeterminate
Focalizzato sul completamento delle storie Focalizzato sul completamento di mo-
(funzionalità) in piccole iterazioni (sprint) duli (parti dell’architettura) a scadenze
prefissate
Ben ingegnerizzato (TDD, XP, design Non necessariamente ingegnerizzato
patterns, ecc.)
Pochi processi e documentazione Molti processi e documentazione
Sviluppatori cross-competenti, ben infor- Pochi architetti/sviluppatori hanno la vi-
mati su tutte le tecnologie impiegate sione di insieme, le altre figure professio-
nali sono molto specializzate
Ruolo principale: sviluppatori Ruoli principali: Architetti e sviluppatori
Open door policy: gli sviluppatori sono in- Solo pochi sviluppatori ed alcuni architetti
coraggiati a rivolgersi al business ed al ma- possono rivolgersi al business. E principal-
nagement in qualsiasi momento. Il punto mente prima dell’inizio dello sviluppo e/o
di vista di tutti deve essere considerato alle scadenze prefissate (milestones)
2.4 Automazione della produzione del software
L’automazione del collaudo del software consiste nello sviluppo di apposito software che
interagisce con il software da collaudare senza bisogno dell’intervento di un operatore uma-
no, e fornisce all’utente un rapporto di qualità. Il risultato del processo di automazione
del collaudo è il "collaudo automatizzato". Se invece il collaudo del software consiste nel-
l’utilizzo del prodotto quasi come se fosse la normale operatività di tale sistema software,
si parla di "collaudo manuale". Tra questi due estremi si possono avere varie posizioni
intermedie, in cui parte del lavoro è automatizzato, ma è sempre richiesta la presenza del
collaudatore. In tali casi, si parla di "collaudo parzialmente automatizzato" o di "collaudo
semi-automatizzato".
Nel collaudo manuale, tipico del software interattivo, il collaudatore utilizza il software
come farebbe l’utente, ma cercando di attivare il maggior numero possibile di funzioni e le
configurazioni più variegate. Quando il collaudatore constata un comportamento inatteso,
ne prende nota e prosegue a collaudare altre funzionalità.
2015 - 2016 21 Veronica PetroneNel collaudo automatico, il collaudatore può usare due tecniche di base:
1. Scrive a mano del software di collaudo.
2. Esegue il software da collaudare in un ambiente di collaudo che registra le operazioni
dell’utente.
La prima tecnica richiede che il collaudatore sia un programmatore che conosca l’architet-
tura interna del software da collaudare. Il software di collaudo, tipicamente scritto in un
linguaggio ad altissimo livello, può interagire con il software da collaudare in vari modi:
• chiamando direttamente le singole routine di tale software;
• chiamando le routine esportate (ossia pubblicate) da un modulo;
• inviando al programma da collaudare dei messaggi di comunicazione tra processi;
• lanciando il programma da collaudare in una modalità in cui riceve due file, uno dal
quale legge i dati di input, e l’altro nel quale scrive i dati di output.
Qualunque sia la tecnica di comunicazione adottata, quando il software da collaudare
risponde, il programma di collaudo confronta le risposte ottenute con i risultati attesi.
In caso di differenza, viene generato un resoconto. La tecnica della registrazione delle
operazioni dell’utente può essere attuata anche da un collaudatore che non sa programmare
o che non conosce l’architettura interna del software da collaudare. Ha tuttavia due notevoli
inconvenienti:
• C’è un’alta probabilità che, quando il software da collaudare viene modificato, le
registrazioni siano improprie, e quindi da rifare.
• L’ambiente di collaudo non fornisce strumenti automatici per determinare se il soft-
ware ha il comportamento atteso.
Questa tecnica è indicata per collaudi solo parzialmente automatizzati, in quanto è sempre
necessario che il collaudatore verifichi visivamente se il software si comporta come dovreb-
be. Solitamente, l’automazione del collaudo viene effettuata dopo aver sviluppato una
procedura di collaudo manuale. L’introduzione dell’automazione nelle prove di collaudo
è un processo costoso ed è da considerarsi un’aggiunta e non una sostituzione del collau-
do manuale. L’investimento può tuttavia fornire un ritorno economico nel lungo termine,
sia in quanto consente di effettuare il collaudo di regressione a basso costo, sia in quanto
consente la tecnica di sviluppo software detta "sviluppo guidato dal collaudo" (Test Dri-
ven Development). Un settore di ricerca attivo è quello sulle generazione automatica dei
requisiti di prova (test cases).
3 Il Framework di SiGrade
Negli sviluppi delle soluzioni personalizzate, SiGrade ricerca l’eccellenza attraverso la co-
noscenza e l’uso di architetture, sistemi, linguaggi e best practice, da un lato per facilitare
la system integration ed al contempo abbattere l’utilizzo di potenza elaborativa, dall’altro
per rendere le proprie applicazioni sempre più "orientate all’utenza".
2015 - 2016 22 Veronica PetronePuoi anche leggere
