L’implementazione di queste funzionalità porta automaticamente alla necessità di raggiun- gere un secondo obiettivo; esso rientra però in un contesto più tecnico. Questo contesto farà da base anche alle eventuali modifiche e miglioramenti futuri che verranno apportati alla piattaforma. La volontà dell’istituto infatti è proprio quella di continuare a supportare il software ISIN Planner, la cui crescita ha come scopo finale quello di diventare un tool in grado di effettuare delle previsioni finanziarie che possano influenzare in maniera positiva lo sviluppo dell’istituto.
Il raggiungimento di tale obiettivo risulta però essere relativamente complicato, principal- mente per un motivo.
La prima versione della piattaforma è stata implementata con l’utilizzo dei template (vedi sot- tosezione 3.2.2), questo approccio era ottimo per le esigenze iniziali che quest’ultima aveva, tuttavia l’implementazione via template non ha le caratteristiche adatte per implementare con facilità le nuove necessità dell’istituto.
Per molti anni, lo sviluppo di pagine web si è basato principalmente su tecnologie server- side1e la maggior parte delle pagine web venivano scritte con linguaggi di back-end2. Alla parte di sviluppo front-end3era principalmente delegata l’implementazione di template (mo- delli). Questa architettura però tende ad aumentare l’accoppiamento che c’è tra back-end e front-end riducendo di molto la possibilità di applicare le modifiche ad uno dei due senza doverle applicare anche sull’altro e obbliga lo sviluppatore a restringere il numero di scel- te tecnologiche per implementare l’applicativo. La domanda che ci si pone è la seguente: come mai nonostante queste limitazioni, si è continuato per molto tempo a sviluppare le pagine web con questo modello di implementazione? La prima risposta è il fatto che l’impie- go dei template è tutt’oggi molto diffuso perché permette di sviluppare applicativi web con funzionalità anche molto complesse.
Un’altra risposta, legata però al passato, risiede nei dispositivi degli utenti e nei browser web di vecchia data: le performance non erano sufficientemente alte per evitare di delegare tutta l’elaborazione al server.
Grazie allo sviluppo tecnologico, i moderni browser web hanno la capacità di effettuare compiti più complessi e questo ha automaticamente spinto il web development verso la tendenza di separare la parte di front-end da quella back-end. ([10])
Questo progetto di diploma ha sicuramente il compito di soddisfare i bisogni esposti dai quadri superiori dell’istituto, ma per poterlo fare è necessario applicare questa transizione di architettura.
4.2.1
Refactoring
Grazie all’aumento delle performance dei web browser, anche le tecnologie di front-end si sono sviluppate permettendo la nascita dei Framework Web.
Il "refactoring" è il processo attraverso il quale vogliamo condurre la piattaforma ISIN Plan- ner. Questo concetto è "una tecnica controllata per migliorare il design di un software esi- stente. La sua essenza è quella di applicare una serie di piccole trasformazioni che preser- vano il comportamento. L’effetto di tutte queste trasformazioni messa assieme è piuttosto significante. Applicandole a piccoli passi si riduce il rischio di introdurre degli errori."([11]).
L’obiettivo è quello di applicare una reimplementazione agli elementi attualmente presenti nella varie pagine, estraendoli e incapsulandoli5in componenti che possano essere riutiliz- zati per necessità future senza il bisogno di re-implementarne il funzionamento, ovviamente il tutto senza alterarne il comportamento.
Uno sviluppo orientato ai componenti permette di ottenere un disaccoppiamento più marca- to fra client e server (in questo caso tra front-end e back-end) e una minore probabilità di riscontrare dei bug grazie alla facilità con cui i componenti possono essere testati.
5
In informatica l’incapsulamento è un meccanismo per isolare un elemento limitandone l’accesso e definendone le funzionalità con le quali poter interagire dall’esterno
4.3
Metodologia Agile
Nell’ingegneria del software la metodologia agile rappresenta un metodo alternativo nella gestione di team e progetti in ambito di sviluppo del software.
Sebbene questo sia un progetto individuale, è stato deciso di seguire questo approccio di lavoro sia a scopo didattico, sia a scopo organizzativo. I vantaggi che i progetti posso- no trarre con questo metodo di lavoro sono numerosi e questa sezione ne espone una serie.
La necessità di sviluppare una nuova metodologia di lavoro è nata per molteplici motivi ([12]), motivi che le vecchie metodologie di sviluppo non erano in grado di risolvere:
• Un numero elevato di progetti interrotti dovuti a mancanza di organizzazione del lavo- ro.
• Costi di pianificazione iniziale sproporzionati: la tendenza era quella di incontrare una prima volta il committente all’inizio del progetto e una seconda volta alla fine di quest’ultimo. Questo comporta una grande pianificazione iniziale che richiede molto tempo, tempo che può essere utilizzato per realizzare il software.
• Per via del motivo visto nel punto precedente, la difficoltà nel soddisfare le esigen- ze del committente cresce perché lo sviluppatore con il tempo può farsi un’idea di implementazione differente da quella che aveva il cliente.
• Lo sfasamento tra la visione dello sviluppatore e quella del cliente causa un ritar- do in termini di consegna perché a fine progetto sono necessarie delle modifiche di correzione. Questo porta chiaramente ad un aumento dei costi.
• Difficoltà di manutenzione del software e problemi di qualità.
L’obiettivo di questa metodologia è quello di coinvolgere costantemente il cliente durante tutto il processo di sviluppo.
“L’approccio ‘a staffetta’ allo sviluppo dei prodotti ...può entrare in conflitto con gli obietti- vi di massima velocità e flessibilità. Invece, un approccio olistico o ‘rugbystico’ - in cui un
“It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.” (Charles Darwin)
Uno dei principi su cui si basa la metodologia agile è la continua analisi e revisione dei requisiti grazie alla quale il cliente collabora attivamente con gli sviluppatori. In questa ma- niera il cliente può liberamente proporre modifiche o nuovi requisiti da integrare in iterazioni successive.
Per formalizzare questi principi, i creatori di questa metodologia hanno redatto un documen- to chiamatoManifesto Agile. (vedi Appendice A)
4.3.1
Scrum
4.3.1.1 Definizione
Figura 4.1: Schema del framework Scrum (fonte: [1])
Scrum è l’approccio più popolare per lo sviluppo agile di software. La sua introduzione av- viene all’inizio degli anni novanta per gestire lo sviluppo di prodotti complessi.
"Scrum non è un processo o una tecnica per costruire prodotti ma piuttosto è un framework all’interno del quale è possibile utilizzare vari processi e tecniche. Scrum rende chiara l’ef- ficacia relativa del proprio product management e delle proprie pratiche di sviluppo così da poterle migliorare". ([14])
Ma come funziona l’approccio Scrum?
Durante il primo incontro con il committente, si discute del progetto in questione e si cerca di raccogliere quante più informazioni suirequisiti richiesti per poi suddividerli in elementi separati e ben definiti. Questi elementi finiscono nelproduct backlog che non è altro che
una lista ordinata dei requisiti ricavati nell’incontro con il cliente chiamati ancheuser story. Il Product Owner è la persona incaricata di inserire le user story nel product backlog e di assegnare una priorità ad ognuna di esse.
Ad ogni user story inoltre viene assegnata una stima attraverso degli story points. Que- ste stime vengono definite dal Team di sviluppo usando una successione di Fibonacci6 arrotondata, per indicarne lo sforzo in termini di tempo di sviluppo.
Una volta definite le user story, viene effettuato un primo meeting per definire la durata delle iterazioni di sviluppo. Queste iterazioni in Scrum sono chiamatesprint e hanno una durata fissa durante tutto l’arco di sviluppo del progetto.
All’inizio e fine di ogni Sprint il team di sviluppo si riunisce per discutere delle funzionalità implementate e per decidere quali dei requisiti presenti nel product backlog sono i più idonei per essere sviluppati nel corso dello sprint successivo. A questo proposito le stime accen- nate precedentemente tornano utili. A lungo termine è sempre più facile capire lo sforzo medio di uno sprint e quindi gli sprint vengono pianificati con più precisione. Con il passare del tempo anche le stime delle singole user story diventano più accurate permettendo di svilupparle con maggiore puntualità.
4.3.1.2 Approccio adottato
Sebbene questo sia un progetto individuale, l’utilizzo dell’approccio scrum fornisce grossi vantaggi, sia sotto l’aspetto organizzativo e di pianificazione, sia sotto l’aspetto puramente didattico.
Come visto nella sezione precedente, scrum prevede la suddivisione del progetto in itera- zioni di lavoro chiamatesprint.
All’inizio del progetto, nel corso del colloquio introduttivo con il relatore Roberto Guidi, si è discusso riguardo alla definizioni delle prime user story e della definizione dei cicli di lavoro.
Per questo progetto abbiamo deciso di effettuare degli sprint con una lunghezza di due settimane.
4.3.2
Software di pianificazione
4.3.2.1 Source Code Management Redmine
Redmine è un tool gratuito open-source per la pianificazione e gestione dei progetti tramite interfaccia web. La sua flessibilità lo rende uno dei tool più utilizzati dalla comunità degli sviluppatori.
Redmine, attraverso tutta una serie di plugin di terze parti, è un software che permette di gestire progetti basati sulla metodologia agile/scrum; esso fornisce strumenti per la piani- ficazione degli sprint e permette di effettuare il tracciamento del tempo e il controllo degli accessi basato sui ruoli.
Questo tool standard è adottato a livello istituzionale ed è stato deciso di sfruttarlo anche per organizzare e gestire le iterazioni di questo progetto.