ISIN Planner Studente/i Ivan Pavic Relatore Roberto Guidi Correlatore Patrick Ceppi Committente ISIN - Information Systems and Networking Institute Corso di laurea Ingegneria Informatica Modulo M00009 Progetto di diploma Anno 2019 Data 4 settembre 2019
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
ISIN Planner
Studente/i
Ivan Pavic
Relatore
Roberto Guidi
Correlatore
Patrick Ceppi
Committente
ISIN - Information Systems andNetworking Institute
D.4 Esempio di Single File Component in Vue.js . . . . . . . . . . . . . . . . . . . 110
D.5 Esempio di Single File Component in Vue.js . . . . . . . . . . . . . . . . . . . 111
D.6 Esempio di utilizzo delle direttive Vue . . . . . . . . . . . . . . . . . . . . . . 112
D.7 Ciclo di vita di un istanza Vue . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
ISIN Planner
1
Abstract
ISIN Planner
2 Abstract
L’istituto di ricerca Information Systems and Networking Institute (ISIN) è parte integrante
della Scuola Universitaria Professionale della Svizzera Italiana (SUPSI) e con i suoi 40
impiegati e 3 Mio di CHF in progetti di ricerca (dato risalente al 2011), come ogni azienda
di queste dimensioni, richiede grandi sforzi in ambito organizzativo per poter funzionare
correttamente.
A questo proposito nel corso del 2018 è stata sviluppata una piattaforma chiamata ISIN
Planner nata con l’intento di semplificare la gestione della pianificazione dei dipendenti e
dei progetti dell’istituto.
Questa tesi di Bachelor ha avuto quale scopo quello di introdurre tutta una serie di funziona-
lità, frutto della nascita di nuove esigenze, atte a facilitare l’estrapolazione di dati complessi
utili a livello finanziario e amministrativo.
Per poterle implementare è stato necessario attuare un cambiamento di architettura ed in-
trodurre una serie di nuove tecnologie. I risultati ottenuti adempiono i bisogni espressi dal
committente e forniscono dei nuovi strumenti per l’analisi statistica delle risorse, permetten-
do di ottimizzarne l’utilizzo. Con l’architettura implementata inoltre ISIN Planner ha ottenuto
la possibilità di essere supportata a lungo termine.
La nuova versione della piattaforma fa da ottimo punto di partenza per la realizzazione di
un tool che non punta solo ad offrire una vasta quantità di funzionalità; esso mira anche a
diventare un mezzo attraverso cui poter effettuare previsioni che possano influenzare posi-
tivamente un’ulteriore crescita e sviluppo dell’istituto.
The Research Institute Information Systems and Networking Institute (ISIN) is an integral
part of the University of Applied Sciences of Southern Switzerland (SUPSI) and with its 40
employees and 3 million CHF in research projects (data from 2011), like any company of
this size, requires great administrative efforts in order to function properly.
In this regard, during 2018 a platform called ISIN Planner was developed with the aim of
simplifying the planning management of the employees and projects of the institute. The
purpose of this Bachelor’s thesis was to introduce a whole series of functionalities to facilitate
the extrapolation of complex data useful at a financial and administrative level.
In order to implement them, it was necessary to develop a change of architecture and
introduce a series of new technologies.
The obtained results meet the needs expressed by the client and provide new tools for the
statistical analysis of resources, allowing to optimize their usage. With the implemented ar-
chitecture ISIN Planner has also obtained the possibility to be supported in the long term.
The new version of the platform is an excellent starting point for the development of a tool
that not only aims to offer a wide range of features, but also aims to become an instru-
ment through which to make predictions that can positively influence further growth and
development of the institute.
ISIN Planner
3
Progetto Assegnato
ISIN Planner
4 Progetto Assegnato
ISIN Planner
5
Introduzione
Questo documento è stato redatto con lo scopo di esporre quali sono state le metodologie di
lavoro e le tecnologie utilizzate per risolvere le necessità esposte dal committente di questo
progetto. Il rapporto percorre in maniera cronologica le diverse fasi di sviluppo partendo da
una prima parte di analisi dello stato iniziale del progetto e dei problemi da risolvere, pas-
sando poi ai vari approcci che sono stati utilizzati per implementare le funzionalità richieste
e analizzando infine i risultati ottenuti.
Il Capitolo 1 illustra per quale motivo è stato svolta questa tesi e in particolare viene conte-
stualizzata la circostanza in cui è nata la necessità di sviluppare una piattaforma di questo
genere. Questo capitolo ha quale obiettivo quello di dare al lettore tutte le informazioni ri-
levanti riguardo l’istituto di ricerca ISIN per facilitare la comprensione dei motivi che hanno
portato quest’ultimo a richiedere delle nuove funzionalità.
Il Capitolo 2 espone tutte queste problematiche in maniera più dettagliata, al fine di indivi-
duare tutti i compiti che si è stati chiamati a risolvere.
In un prima parte questo capitolo chiarisce quali sono gli elementi che potrebbero favorire
una maggiore crescita dello sviluppo dell’istituto, mentre nella seconda espone per quale
motivo questi elementi sono difficilmente integrabili nella versione corrente della piattaforma.
Il Capitolo 3 tratta dello stato dell’arte. Questo capitolo è fondamentale per capire più accu-
ratamente le basi dalle quali questo progetto è partito e per capire quali sono gli elementi
che erano già presenti all’inizio dell’implementazione di quest’ultimo. Inoltre in questo ca-
pitolo vengono trattate anche le tecnologie che sono state utilizzate per la prima versione
della piattaforma e vengono brevemente spiegati i motivi per cui esse siano state scelte.
Il Capitolo 4 espone l’approccio che è stato applicato per risolvere le varie problematiche co-
me anche le varie tecniche di progettazione che sono state usate per una corretta gestione
del tempo e dei cicli di sviluppo di questo software.
Il Capitolo 5 tratta dei risultati ottenuti. Questa sezione del rapporto mostra tutte le funzio-
nalità che sono state aggiunte e tutti i vantaggi che queste hanno portato.
Il Capitolo 6 riprende i problemi iniziali e analizza i risultati ottenuti sulla base dell’approccio
che è stato applicato per risolverli.
ISIN Planner
6 Introduzione
ISIN Planner
7
Capitolo 1
Motivazione e contesto
ISIN Planner
8 Motivazione e contesto
1.1 Motivazione
Questo progetto è stato svolto come tesi di Bachelor per il corso di laurea di Ingegneria
Informatica presso la Scuola Universitaria della Svizzera Italiana (SUPSI) – Dipartimento
Tecnologie Innovative (DTI).
Ogni studente, al termine del proprio percorso formativo, è tenuto a scegliere un progetto
appartenente al ramo dell’informatica da svolgere nell’arco di 8 settimane. Lo sviluppo di
tale progetto, a seconda dell’argomento e del tipo di lavoro scelto, consiste nell’applicare
i concetti appresi nei diversi corsi e moduli frequentati durante la formazione. Questi con-
cetti comprendono anche una corretta gestione del progetto, la stesura di un rapporto e la
presentazione di quest’ultimo di fronte ad una commissione.
1.2 Contesto
1.2.1 ISIN
Questo progetto è stato commissionato dall’istituto di ricerca ISIN (Institute for Information
Systems and Networking). L’ISIN è un istituto fondato ufficialmente nel dicembre del 2007.
Nel corso dell’anno successivo è stato costituito come fusione di tutta una serie di unità
di ricerca già esistenti all’interno del Dipartimento Tecnologie Innovative della SUPSI. L’o-
biettivo di questo istituto è quello di sviluppare e mantenere competenze legate all’ICT1 e
di fare da supporto ai corsi di Bachelor e Master della Scuola Universitaria Professionale
della Svizzera Italiana. L’istituto mira anche allo scambio di conoscenza con le aziende del
territorio svizzero nell’ambito di progetti di ricerca applicata. L’ISIN vanta inoltre numerose
collaborazioni con altre università nazionali e internazionali.
Fin dalla sua nascita, l’istituto ha avuto una grande crescita in termini di risorse umane,
progetti e ricerca applicata. Nel 2011 è stata raggiunta la quota di 40 impiegati e 3 Mio di
CHF in progetti di ricerca. ([5])
1.2.1.1 Struttura organizzativa
ISIN è suddiviso principalmente in due settori: il settore delle aree di applicazione e il settore
delle aree di ricerca. Ogni area è coordinata da una persona con esperienza nel campo
in questione; essa ha il compito di mantenere e sviluppare contatti con potenziali partner
interni o esterni all’istituto.
1Information and Communications Technology: Indica l’insieme delle tecnologie che consentono iltrattamento e lo scambio delle informazioni in formato Digitale.
ISIN Planner
9
Il primo settore è incentrato principalmente su aspetti di tipo applicativo ed il suo obiettivo
è quello di dare visibilità all’istituto per mantenere attiva la crescita e rendere più facile
l’interazione con i partner in ambito IoT2.
Il secondo settore invece è incentrato sulla ricerca ed è suddiviso in aree il cui obiettivo è
mantenere aggiornate le competenze scientifiche dell’istituto e di mantenere e sviluppare
relazioni con organizzazioni accademiche ICT esterne.
Questo settore è suddiviso nelle seguenti aree di ricerca:
• Software and data engineering
• Audio visual processing and Immersive Multimedia
• Semantic and Multimedia Systems
• Cybersecurity
• Complex networks and pervasive communication
Nell’ambito dei progetti di ricerca i dipendenti vengono suddivisi in Team di sviluppo. Ogni
team lavora a progetti legati a una o più aree di ricerca.
Come già accennato, ISIN è parte integrativa della Scuola Universitaria Professionale della
Svizzera Italiana, per questo motivo molti dei dipendenti di questo istituto oltre a lavorare in
ambito di ricerca, ricoprono il ruolo di insegnanti universitari.
1.2.1.2 Finanziamento dei progetti
I progetti a cui lavora l’istituto ISIN vengono finanziati in tre differenti modi:
• Finanziamento interno:
I progetti che rientrano in questa categoria vengono commissionati e finanziati com-
pletamente dall’istituto stesso.
• Mandato:
Questo tipo di finanziamento comprende tutti i progetti che vengono commissionati
da aziende/partner esterni. In questo caso i costi vengono sostentuti dai committenti
stessi.
• Ente di finanziamento esterno:
Molti dei progetti di ricerca vengono supportati da enti di finanziamento esterni. L’isti-
tuto ISIN ottiene i fondi da tre principali organizzazioni ([6]):
2Internet of Things: neologismo che descrive un ramo dell’informatia in cui gli oggetti fisici sono collegati allarete Internet e permettono di unire il mondo reale con quello virtuale.
ISIN Planner
10 Motivazione e contesto
– Innosuisse, agenzia per la promozione dell’innovazione3: essa si occupa di
mettere in contatto imprese e università e di finanziare le start-up. Questa agen-
zia fa parte dell’ufficio federale della formazione professionale e della tecnologia
del Dipartimento federale dell’economia.
– Commissione Europea: contribuisce in modo significativo alla cooperazione tra
i partner accademici ed industriali nella regione europea. Essa è composta da
una serie di programmi quadro di ricerca (PQR, al momento all’ottava generazio-
ne) che rappresentano il principale strumento dell’Unione Europea per attuare la
politica comunitaria in materia di scienza e innovazione. La Svizzera è mem-
bro a pieno titolo dei programmi quadro, in particolare l’istituto ISIN partecipa ai
programmi Eurostar, H2020 e Interreg.
– Fondo nazionale svizzero per la ricerca scientifica (SNF): Il Fondo naziona-
le svizzero per la ricerca scientifica è la più importante istituzione svizzera per
la promozione della ricerca scientifica. Su mandato della Confederazione pro-
muove tutte le discipline, dalla filosofia alla biologia fino alla nanoscienza e alla
medicina.
1.2.2 Piattaforma esistente
L’elevato numero di dipendenti, l’ampio ventaglio di aree di competenza, la didattica e i dif-
ferenti metodi di finanziamento, richiedono grandi sforzi sia dal lato amministrativo sia da
quello organizzativo. Per poter coordinare al meglio tutti questi elementi è nata quindi la
necessità di implementare un software in grado di gestire le varie pianificazioni legate al
personale e al finanziamento dei progetti nella maniera più efficiente e chiara possibile. Una
gestione facilitata e più trasparente permette ai quadri superiori del’istituto di documentare
e pianificare il lavoro con più efficienza, massimizzando l’utilizzo delle risorse disponibili. La
presenza di un software flessibile che sia in grado di conciliare tutti i dati citati in precedenza
porta grossi vantaggi sia in termini di tempo sia in termini di impiego dei fondi.
Al fronte di questi bisogni, nel corso del 2018 è stata implementata una prima versione del-
la piattaforma ISIN planner, un’applicazione web in grado di semplificare la pianificazione
contabile dell’istituto.
3Commissione per la tecnologia e l’innovazione: organo della Confederazione Svizzera incaricato dipromuovere l’innovazione fondata sulla scienza
ISIN Planner
11
Capitolo 2
Problema
ISIN Planner
12 Problema
2.1 Fattori chiave
In un istituto di ricerca, come d’altronde in qualsiasi altra azienda, la gestione corretta del
budget e delle risorse a disposizione è fondamentale per assicurare un buon funzionamento
dell’infrastruttura.
Il budget in particolare è un fattore che può influenzare numerose scelte in ambito aziendale
e può avere un peso non indifferente sia dal punto di vista della pianificazione sia dal punto
di vista del controllo.
La piattaforma esistente offre uno strumento per la pianificazione delle ore lavorative dei
dipendenti e il monitoraggio delle spese sui progetti di ricerca, tuttavia non è presente una
visuale sufficientemente ampia e chiara di tutti questi dati, il che rende spesso molto difficile
il reperimento di informazioni interessanti nell’ottica di investimenti su progetti futuri.
Il problema principale risiede dunque nel dover effettuare tutte le analisi e nel dover estrarre
le statistiche a mano, questo ovviamente richiede del tempo prezioso che potrebbe essere
investito per altri scopi.
Il sistema di visualizzazione attuale dei fondi investiti nei vari progetti dunque non è suffi-
cientemente esplicativo e non esistono delle funzionalità in grado di mettere a confronto i
progetti fra loro per fare in modo di estrapolare delle statistiche rilevanti. Lo stesso discorso
può essere applicato per la pianificazione e l’inserimento dei ricercatori nei vari progetti. En-
trambi questi fattori hanno un ruolo molto importante in termini di crescita dell’istituto poiché
la maggior parte dei costi di un centro di ricerca, in particolar modo nell’ambito dell’informa-
tica, derivano dai salari che sono attribuiti ai ricercatori coinvolti nei progetti di ricerca.
Sebbene siano già presenti ottime funzionalità per la pianificazione del lavoro, si vuole fare
in modo di migliorare questo software per gestire al meglio i dati presenti, rendendoli più
interessanti soprattutto dal punto di vista analitico. L’istituto ha la necessità di avere una
piattaforma di gestione che faciliti l’individuazione di un punto di bilanciamento tra tutti gli
elementi citati sopra in maniera automatica. Essi hanno tutti un impatto che non bisogna
trascurare in merito allo sviluppo e la crescita futura dell’istituto.
2.2 Estensibilità della piattaforma
Fin dalla sua fondazione, l’istituto è cresciuto notevolmente sia in termini di risorse umane
sia in termini economici, per questo motivo anche la piattaforma che ne gestisce i dati deve
e dovrà subire un espansione.
La piattaforma ISIN planner è composta da elementi grafici che non sono sufficientemente
flessibili per poter essere adattati a future esigenze. È necessario effettuare un refactoring1
1In ingegneria del software è una tecnica per ristrutturare delle porzioni di codice senza però modificarne ilcomportamento esterno.
ISIN Planner
13
per poter riutilizzare questi elementi anche in contesti differenti fra loro.
Come già discusso nella sezione precedente, la necessità di introdurre nuove funzionalità
che possano organizzare la grande quantità di dati in strutture più esplicative è sempre
maggiore. Queste ultime permetterebbero di organizzare i dati dando la possibilità di filtrare
le informazioni in base a diversi tipi di parametri attraverso cui poter effettuare analisi più
accurate in tempi molto più ristretti.
Le tecnologie che sono state utilizzate per sviluppare la prima versione di questa piattafor-
ma sono tutt’oggi presenti in molte applicazioni e utilizzate da una grande quantità di svi-
luppatori. Esse sono state scelte perché molto idonee ai compiti che la piattaforma doveva
inizialmente assolvere.
L’istituto però vuole estendere la piattaforma al fine di ottenere un tool che permetta anche
di fare analisi economiche, e a lungo termine, dia la possibilità di effettuare delle previsioni.
Con la nascita di queste nuove necessità da parte dei quadri superiori dell’istituto, è stato
necessario rivedere la parte tecnica e pensare all’impiego di un approccio di sviluppo più
moderno in grado di facilitare l’aggiunta di queste nuove funzionalità.
Suddividendo l’interfaccia in componenti2 indipendenti fra loro è possibile avere tutta una
serie di vantaggi che il software della versione attuale della piattaforma non fornisce:
• Lo sviluppo di componenti indipendenti ne facilita il riutilizzo. Questo è utile soprattutto
quando si lavora nel contesto di applicazioni web dove spesso e volentieri capita di
riutilizzare gli stessi elementi in pagine diverse.
• Il design di tutte le pagine dell’applicazione rimane uniforme.
• Con il passare del tempo, l’aggiunta di funzionalità avviene in maniera sempre più
rapida perché è possibile estendere componenti già esistenti senza dover ripartire
sempre da capo.
• Essendo indipendenti, i componenti sono molto più facili da testare, assicurando una
buona qualità del codice e una minore esposizione ai bug3.
2In ambito informatico un componente è un pezzo di software indipendente dal resto del codice3Errore nella scrittura del codice di un programma che porta al malfunzionamento e aumenta la vulnerabilità
ad attacchi informatici
ISIN Planner
14 Problema
ISIN Planner
15
Capitolo 3
Stato dell’arte
ISIN Planner
16 Stato dell’arte
3.1 Piattaforma ISIN Planner
La piattaforma ISIN planner è un’applicazione web creata dal centro di ricerca ISIN nel cor-
so del 2018 per poter far fronte a tutte le problematiche che possono nascere in fase di
pianificazione dei progetti, gestione dei dipendenti e analisi dei costi. Il software esistente è
basato sul framework Spring. La parte di interfaccia grafica invece si appoggia ai linguaggi
classici usati nel web development: HTML, CSS e Javascript. Ciò che permette alle due
architetture della piattaforma di comunicare e scambiare i dati è il template engine Thyme-
leaf ([7]). L’utilizzo di queste tecnologie è risultato essere l’approccio ideale per sviluppare
le funzionalità che la versione attuale della piattaforma doveva esporre.
3.2 Ambienti di sviluppo
3.2.1 Spring Framework
Spring è uno dei più popolari framework open source in linguaggio Java nato con l’intento
di diminuire la complessità necessaria per sviluppare applicazioni web. Questo framework
è definito come uno dei più completi per molteplici motivi ([8]):
• Utilizzo di Plain Old Java Objects (POJOs):
I POJO sono oggetti Java ordinari, non oggetti speciali. Questo significa che un POJO
non è legato a nessuna restrizione diversa da quelle della specifica del linguaggio
Java. Grazie a questo fattore, Spring non necessità dei container specifici come ad
esempio gli application server, bensì è sufficiente un servlet container come Tomcat.
• Modularità:
Nonostante l’elevato numero di pacchetti che mette a disposizione, Spring grazie alla
sua modularità permette di utilizzare solo quelli che sono necessari allo sviluppo del
proprio applicativo web.
ISIN Planner
17
• Testing:
Questo framework è molto adatto alle grandi realtà aziendali perché ha un ambiente
basato su IoC1(Inversion of Control) e Dependency Injection2 i quali garantiscono
grande versatilità nel momento in cui è richiesta l’implementazione di test di unità.
• Fornisce una grande quantità di strumenti:
Spring è molto versatile perché permette di fornire l’accesso ai database, gestire le
dipendenze, progettare applicazioni con architetture Model-View-Controller3 (MVC),
ecc
• AOP (Aspect Oriented Programming):
Assieme all’IoC, questa tecnica di programmazione rappresenta una delle caratteri-
stiche fondamentali del framework. AOP è un modulo nativo di Spring e permette di
isolare i cross-cutting concerns4 in moduli ben distinti e separati, facilitando il lavoro
in fase di testing.
• Transaction management:
Spring si occupa di gestire le transazioni5 effettuate sui database dell’applicazione se-
condo le proprietà ACID. Nell’ambito dei database, queste sono le proprietà che deve
rispettare un transazione per poter essere portata a termine correttamente: Atomicità,
Consistenza, Isolazione e Durabilità. ([9])
• Container:
Spring è di fatto un container wrapper (modulo software che ne "riveste un altro) di
applicazioni che si occupa anche di gestirne il ciclo di vita.
1Principio architetturale basato sull’ inversione del flusso di sistema rispetto alla programmazione tradizionalein cui è lo sviluppatore a definirne la logica.
2È una specifica implementazione di IoC che permette di invertire il processo di risoluzione delle dipendenze.3Architettura software usata in particolare nella programmazione ad oggetti. Permette di isolare i tre strati
principali di un applicazione per fare in modo che alla modifica di uno, non sia necessario modificare anche glialtri.
4Sono comportamenti trasversali di un’applicazione che si ripercuotono su più elementi(parti di codice)5Una transazione è tutta una serie di azioni che vengono effettuate su un database rappresentate come una
singola unità.
ISIN Planner
18 Stato dell’arte
3.2.2 Thymeleaf
Thymeleaf è un template engine server-side che può lavorare sia in ambienti web sia in
ambienti stand-alone6.
È molto adatto per fornire pagine web basate su XHTML/HTML5. Thymeleaf si posiziona a
livello di View nelle applicazioni progettate con architettura Model-View-Controller, come ad
esempio quelle basate sul framework Spring trattato nella sottosezione 3.2.1.
Il suo grande vantaggio è appunto il fatto che fornisce un’integrazione completa con il
framework Spring facilitandone l’utilizzo e l’integrazione in progetti già esistenti.
Figura 3.1: Ruolo di un template engine
Il compito di un template engine è quello di fornire delle pagine web basate su modelli:
per capire meglio il concetto è sufficiente pensare che i dati vengono recuperati dalla parte
applicativa e forniti sotto forma di modello alla parte di interfaccia. Tutto ciò che è presente
nel modello viene inserito in posizioni prestabilite in quest’ultima. ISIN Planner dunque
sfrutta Thymeleaf per iniettare i dati all’interno delle pagine che vengono mostrate all’utente,
permettendo di separare il layer dei dati dal layer di visualizzazione offrendo un ambiente di
sviluppo più dinamico. I meccanismi di Thymeleaf rendono molto semplice la manipolazione
dei dati garantendo la separazione tra il livelli dell’MVC come mostrato in Figura 3.1.
6È un oggetto o software in grado di funzionare in maniera indipendente senza l’ausilio di oggetti o softwareaggiuntivi
ISIN Planner
19
3.3 Funzionalità
In questa sezione vengono analizzate le funzionalità che l’attuale versione della piattaforma
espone. In particolare si entra più in dettaglio in merito alle entità che sono state riprodotte
sulla base di ciò che è presente nella realtà. Oltre all’approfondimento di questi concetti,
vengono mostrate le pagine che l’interfaccia della piattaforma mette a disposizione al fine di
capire quali sono effettivamente gli strumenti di pianificazione esistenti.
3.3.1 Autenticazione e autorizzazione
La piattaforma fornisce un meccanismo di autenticazione attraverso username e password,
non è però presente una distinzione basata sui ruoli degli utenti. Infatti al momento la
piattaforma offre l’accesso solamente a 4 utenti (i quadri dell’istituto), tutti con ruolo di
amministratori.
È necessario implementare un sistema di login che sia in grado di distinguere il ruolo dell’u-
tente facendo in modo di mostrare solo i dati rilevanti ad esso, salvaguardando così sia la
privacy degli altri utenti sia i dati sensibili legati ai progetti dell’istituto.
Entrando più in merito agli scopi per cui è stata creata la piattaforma, si vuole fare in mo-
do che gli utenti amministratori abbiano la possibilità di poter vedere tutti i dati relativi ai
dipendenti e di pianificarne le ore lavorative senza alcune restrizioni.
D’altro canto un utente con privilegi base, un dipendente, non deve avere la possibilità di
effettuare tali azioni ma deve solamente poter vedere le proprie pianificazioni mensili per
avere una panoramica del lavoro di cui è stato incaricato.
Attualmente l’unico modo per poter comunicare il piano di lavoro ad un utente base è attra-
verso un pulsante il quale apre una finestra di dialogo per inviare un’email con le relative
pianificazioni. Ovviamente sarebbe molto più immediato se il dipendente stesso avesse la
possibilità di verificare da solo tutte queste informazioni.
3.3.2 Gestione dei progetti
Uno dei compiti principali della piattaforma è quello di permettere la gestione dei progetti ai
quali lavora l’istituto.
ISIN Planner permette di salvare nuovi progetti e modificare i progetti già presenti indicando
diversi parametri: titolo, codice, data di inizio e di fine, budget, tipo progetto, cliente, STT e
matching funds.
3.3.2.1 Codice progetto
Il codice progetto, insieme al tipo progetto, è un indicatore utilizzato per distinguere i progetti
fra loro. Questo codice viene utilizzato in ambito contabile e viene assegnato una volta che
il progetto viene approvato. In particolare il codice progetto viene definito all’interno di un
ISIN Planner
20 Stato dell’arte
programma istituzionale di contabilità (utilizzato esternamente dall’aministrazione SUPSI),
il cui scopo è quello di automatizzare i processi finanziari legati all’istituto. Il codice di un
progetto è univoco e tramite esso è possibile registrare e recuperare tutte le azioni contabili
legate ad un determinato progetto.
ISIN Planner prevede anche la gestione delle ore di assenza, ore di malattia, ore di con-
gedo, ore di infortunio e ore di vacanza. Ognuno di questi tipi di assenza è rappresentato da
un’entità "Progetto" alla quale viene assegnato il codice corrispondente a quello presente
nello strumento di contabilità.
Il codice progetto ha quindi lo scopo di distinguere i progetti e di fare da collegamento tra la
piattaforma di pianificazione (ISIN Planner) e la piattaforma contabile (strumento istituziona-
le di contabilità). Questo collegamento è importante perché i dati presenti nei due software
devono combaciare per poter mettere in relazione le ore pianificate con le ore effettivamente
svolte da ogni dipendente.
È importante sottolineare il fatto che ISIN Planner non è un tool di contabilità, di fatto esso
fa da supporto al sistema istituzionale di contabilità.
3.3.2.2 Tipi progetto
Durante l’inserimento di un nuovo progetto nella piattaforma, è necessario indicare a quale
tipo progetto esso corrisponde.
Come già discusso in precedenza, l’istituto ISIN beneficia dell’aiuto di alcune agenzie che
mettono a disposizione i propri fondi per sostenere lo sviluppo e la crescita della tecnologia.
In Svizzera e in Europa esistono numerose agenzie che forniscono mezzi finanziari alle
aziende per promuovere l’innovazione nell’interesse dell’economia e della società. (vedi
sottosottosezione 1.2.1.2)
Il parametro "tipo progetto" permette di capire qual’è l’ente finanziario che supporta il pro-
getto.
3.3.2.3 SST
Questo parametro di tipo booleano indica che il progetto in questione ha un budget inferio-
re ai 15’000 CHF. Si è deciso di utlizzare un parametro perchè la creazione di un codice
apposito avrebbe creato un overhead.
A partire dal 2019 i progetti che rientrano in questa categoria non fanno più l’uso di questo
parametro ma vengono tutti assegnati a un codice standard.
3.3.2.4 Matching funds
I matching funds rappresentano una porzione delle ore di lavoro previste in un determinato
planning (vedi sottosottosezione 3.3.4.3) per un determinato progetto. Questo parametro
ISIN Planner
21
booleano indica se il progetto ha ore di matching funds oppure no. Le ore matching funds
servono solamente a scopo organizzativo per i progetti non sovvenzionati al 100%. Se il
progetto le prevede, la quantità effettiva di ore matching funds viene specificata nei planning.
3.3.3 Pagina dei progetti
La pagina dei progetti, come mostrato nella pagina seguente in Figura 3.2, è struttura-
ta su tre colonne, dove ogni colonna rappresenta un periodo(mese/anno) di lavoro con le
rispettive ore lavorative.
I periodi lavorativi vengono mostrati sull’arco di tre mesi (come il numero di colonne) ed
è possibile andare avanti o indietro di un periodo premendo il corrispettivo pulsante. Per
ogni progetto, in un dato periodo, viene mostrata una lista delle risorse che lavorano o
lavoreranno ad esso. Rispettivamente ad ogni risorsa, in un dato periodo, corrisponde una
barra di progresso che mostra la percentuale di impiego per quel periodo di lavoro e la
percentuale di impiego per il progetto in cui essa è coinvolta. In fondo ad ogni colonna è
inoltre mostrato il totale delle ore pianificate, cioè la somma delle ore pianificate per ogni
risorsa per il dato periodo.
ISIN Planner
22 Stato dell’arte
Figura 3.2: Pagina principale della piattaforma che mostra la lista dei progetti
ISIN Planner
23
3.3.4 Gestione delle Risorse e Team di sviluppo
Oltre ai progetti, ISIN Planner permette di gestire la pianificazione dei propri dipendenti e
permette di suddividerli in Team di sviluppo. Come già discusso nella sottosezione 1.2.1, i
Team di sviluppo generalmente lavorano a progetti legati a campi informatici differenti.
Quando viene commissionato un progetto di una determinata area, è il Team di sviluppo
competente che se ne occupa. I Team dunque hanno competenze in determinate aree,
tuttavia non sono vincolati solo ad esse. Può infatti capitare che per questioni di carico di
lavoro un Team prenda un progetto che non è direttamente legato alla sua area di compe-
tenza.
A livello di dipendenti esiste un’altra variabile di cui la piattaforma deve tenere conto.
L’istituto è parte integrante della Scuola Universitaria Professionale della Svizzera Italiana,
molti dei suoi dipendenti infatti oltre al ruolo di ricercatori ricoprono anche quello di inse-
gnanti. Questo fa capire che la piattaforma deve essere in grado di pianificare il lavoro
considerando anche questo fattore.
3.3.4.1 Periodi
In ISIN Planner il periodo è rappresentato dalla coppia mese/anno. La pianificazione del
lavoro avviene per periodi e la quantità di ore mensili che una risorsa deve effettuare è
direttamente proporzionale alla sua percentuale di lavoro in quel determinato periodo.
ISIN Planner
24 Stato dell’arte
3.3.4.2 Duty-sheet
Figura 3.3: Modale per l’inserimento di un nuovo duty-sheet
Il duty-sheet di un dipendente è l’elemento base necessario per pianificare un periodo lavo-
rativo. Il duty-sheet descrive qual’è la percentuale di impiego del dipendente in questione e
qual’è il suo costo orario. I dipendenti dell’istituto spesso hanno dei contratti che variano di
mese in mese, per questo motivo anche la loro percentuale d’impiego può cambiare. Infine
il duty-sheet indica anche la quantità di ore di insegnamento e misc7 previste.
7ore utilizzate per lavori alternativi
ISIN Planner
25
3.3.4.3 Planning
Figura 3.4: Modale per l’inserimento di un nuovo planning
Il planning rappresenta l’unità più piccola in termini di pianificazione dei periodi di lavoro di
un dipendente. È possibile inserire i planning solamente dopo aver definito il duty-sheet.
Il planning descrive in quale periodo una determinata persona deve lavorare ad un deter-
minato progetto. L’insieme di tutti i planning di un periodo rappresenta la mole di lavoro
mensile che una risorsa deve sostenere. I dati presenti nel planning sono i seguenti: titolo
del progetto, periodo lavorativo (mese/anno), le ore di lavoro (specificabili anche i formato
percentuale) e la quantità di ore matching funds (vedi sottosottosezione 3.3.2.4) se il pro-
getto specificato le prevede. I matching funds possono essere specificati sia in percentuale
sia in ore.
ISIN Planner
26 Stato dell’arte
3.3.4.4 Pianificazione del lavoro
Ogni risorsa ha una pagina dedicata all’interno della piattaforma in cui è presente una vi-
sualizzazione molto simile a quella vista nella Figura 3.2. Anche in questo caso la pagina
è suddivisa in 3 colonne dove ogni colonna rappresenta un periodo lavorativo. Le colonne
sono popolate con una barra di progresso che mostra i dati del duty-sheet della risorsa, i
suoi planning e le ore ancora disponibili, come mostrato in Figura 3.5.
Appena sotto la barra di progresso vengono rappresentati gli stessi dati sotto forma di lista
per facilitarne la lettura. La lista mostra inoltre il tasso di impiego rispetto alla percentuale
di lavoro della risorsa in questione, questo dato è importante per verificare se sono state
pianificate sufficienti ore.
Il calcolo della percentuale totale di impiego del periodo avviene considerando tutti i plan-
ning e i dati all’interno del duty-sheet. Come visto nella Figura 3.4, all’inserimento di un
nuovo planning è possibile specificare se la quantità da pianificare è espressa in ore oppure
in percentuale. Al momento è presente un bug: quando alcuni planning sono espressi in
ore, mentre altri sono espressi in percentuale, il calcolo non viene effettuato correttamen-
te perché le pianificazioni inserite attraverso la percentuale non vengono convertite in ore,
sfasando il risultato.
Figura 3.5: In dettaglio: la pianificazione di un periodo per la risorsa "Nome Cognome"
ISIN Planner
27
Figura 3.6: Pagina di una risorsa
ISIN Planner
28 Stato dell’arte
Premendo su uno degli elementi della barra di progresso oppure direttamente sulle ore
presenti nella lista, è possibile inserire o modificare i duty-sheet e i planning attraverso le
stesse modali viste in Figura 3.3 e Figura 3.4.
Come si può vedere nella Figura 3.6 la parte inferiore della pagina mostra una tabella che
riassume tutti i planning assegnati al dipendente. Essa dà anche la possibilità di eliminarli.
La piattaforma offre anche una pagina riassuntiva di tutte le risorse dell’istituto (vedi Figu-
ra 3.7).
Premendo sulla riga di una delle risorse vengono visualizzate le stesse liste di pianificazione
viste in Figura 3.5.
ISIN Planner
29
Figura 3.7: Pagina riassuntiva delle risorse
ISIN Planner
30 Stato dell’arte
Anche per i Team sono presenti delle pagine dedicate (vedi Figura 3.8). In ognuna di esse
è mostrata una tabella con le risorse sulle righe e i periodi sulle colonne. Le colonne della
tabella si estendono sull’arco di un anno e permettono di muoversi in avanti o indietro di
altrettanto. La tabella è popolata con il tasso di impiego delle risorse rispetto alla percentuale
d’impiego. Come già specificato in precedenza, questo tasso è molto utile per capire se per
una data risorsa le ore pianificate sono sufficienti o insufficienti.
Figura 3.8: Pagina dei Team di sviluppo
ISIN Planner
31
3.3.4.5 Export
Per poter permettere l’utilizzo delle pianificazioni anche in altri contesti (ad esempio nel tool
istituzionale di contabilità, in Excel, ecc), ISIN Planner permette di esportare i dati in formato
.csv. Per farlo esistono due modi:
• Pagina di Export: Attraverso la pagina di export è sufficiente specificare il periodo
desiderato con il formato "mese.anno". La piattaforma genera il file .csv in cui è pre-
sente la lista di tutti i planning per il periodo inserito. Per i progetti con matching funds
vengono visualizzate due entry.
• E-mail: Nella pagina mostrata in Figura 3.6 accanto ad ogni periodo è presente un
piccolo pulsante ( ). Una volta premuto viene aperta una finestra del client mail in
base al sistema in uso.
Questa funzionalità di fatto è utilizzata per condividere le pianificazioni con i dipendenti
poiché al momento non è presente un sistema di login basato sui ruoli degli utenti.
(vedi sottosezione 3.3.1)
ISIN Planner
32 Stato dell’arte
ISIN Planner
33
Capitolo 4
Approccio al problema
ISIN Planner
34 Approccio al problema
Questo capitolo effettua un analisi riguardo alla metodologia di lavoro e le tecnologie che
sono state scelte per soddisfare i bisogni che ha evidenziato il committente del progetto. Co-
me già accennato nel Capitolo 2, questa tesi di Bachelor mira a raggiungere principalmente
2 obiettivi, citati e approfonditi nelle sezioni seguenti.
4.1 Introduzione di funzionalità analitiche
Il primo obiettivo rappresenta la priorità di questo progetto e consiste nell’implementare tutta
una serie di componenti in grado di visualizzare la grande mole di dati della piattaforma da
punti di vista alternativi. Si vuole fare in modo che l’analisi dei dati possa portare dei benefici
in tutte le fasi che caratterizzano un progetto: in fase di pianificazione, in fase di implemen-
tazione, quando possono esserci dei cambiamenti rispetto alla pianificazione iniziale e in
fase di verifica dei risultati, quando i progetti sono giunti al termine ed è necessario capire in
quale modo è stato speso il capitale e come sono state impiegate le risorse a disposizione.
Tutte queste informazioni possono avere un grande impatto sull’istituto e possono essere la
base per studiare delle strategie che ottimizzino e aumentino gli introiti di quest’ultimo.
La piattaforma ha quale scopo quello di prendere gli elementi presenti nella realtà e di
riprodurli fedelmente in un sistema pìù accessibile e automatizzato. Le modifiche che si
vogliono introdurre devono seguire questa filosofia, in compenso si ottiene un software che
riproduce fedelmente tutti gli scenari che avvengono nella realtà.
Le funzionalità richieste dai quadri superiori dell’istituto consistono nello sviluppare una se-
rie di diagrammi, come ad esempio grafici a torta o curve, attraverso i quali sia possibile
filtrare i dati in base a determinati parametri. Anche le tabelle forniscono un senso logico ai
dati e una via più immediata per individuare delle caratteristiche fra un gruppo di elemen-
ti. L’aspetto estetico della loro rappresentazione e le informazioni visualizzate ovviamente
variano in base alle necessità dell’istituto e a seconda dei dati da estrapolare per ottenere i
risultati più utili possibile.
4.2 Cambiamento di architettura
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.
ISIN Planner
35
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-
side1 e la maggior parte delle pagine web venivano scritte con linguaggi di back-end2. Alla
parte di sviluppo front-end3 era 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.
Un Framework Web permette di sviluppare applicazioni con design responsive4 basate su
componenti(vedi sezione 2.2).
1Un programma è server-side quando esegue completamente sul server ed è raggiungibile dal client, il qualerichiede i dati di cui necessita, attraverso la rete.
2La parte che elabora i dati e permette il funzionamento delle interazioni tra utente e interfaccia3La parte visibile all’utente, con la quale può interagire4Un’applicazione responsive è capace di adattarsi su qualsiasi dispositivo, sia esso un computer o uno
smartphone. I contenuti sono impaginati in strutture a griglia con proporzioni adattabili senza la perdità diinformazioni.
ISIN Planner
36 Approccio al problema
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 incapsulandoli5 in 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.
5In informatica l’incapsulamento è un meccanismo per isolare un elemento limitandone l’accesso edefinendone le funzionalità con le quali poter interagire dall’esterno
ISIN Planner
37
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
team cerca di coprire la distanza come un’unità, passandosi la palla a vicenda – può servire
meglio gli odierni requisiti di competitività.” ([13])
Il software viene prodotto con brevi e regolari iterazioni di sviluppo. Ogni iterazione vie-
ne usata per implementare una piccola funzionalità del programma. Il rilascio frequente di
nuove versioni del prodotto da al cliente la possibilità di vedere la crescita del progetto che
ha richiesto e di correggerne eventualmente l’aspetto e il funzionamento.
ISIN Planner
38 Approccio al problema
“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 chiamato Manifesto 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 sui requisiti richiesti per poi suddividerli in elementi
separati e ben definiti. Questi elementi finiscono nel product backlog che non è altro che
ISIN Planner
39
una lista ordinata dei requisiti ricavati nell’incontro con il cliente chiamati anche user 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 chiamate sprint 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 chiamate sprint.
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.
Per un progetto di durata relativamente corta come questo (8 settimane), questa è sembrata
la lunghezza più corretta.
La scelta deriva anche dal bisogno dell’istituto ISIN (committente del progetto) di avere un
rilascio di una nuova versione della piattaforma a intervalli regolari per poter monitorare
l’avanzamento dei lavori.
Questo può portare un grosso beneficio sotto un punto di vista molto importante: l’otteni-
mento di un feedback in merito alle funzionalità introdotte e la possibilità di correggerle in
tempi molto corti all’inizio dello sprint successivo.6In matematica indica una successione di numeri interi in cui ciascun numero è la somma dei due precedenti
ISIN Planner
40 Approccio al problema
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.
ISIN Planner
41
4.4 CI/CD
Figura 4.2: Processo di sviluppo di un progetto basato su CI/CD
Nell’ingegneria del software la Continuous Integration/Continuous Delivery è una pratica
molto diffusa, basata sull’automatizzazione dell’esecuzione di script per minimizzare l’intro-
duzione di errori durante il rilascio di un’applicazione. La metodologia che impone il proces-
so CI/CD si concentra su cicli continui di building, testing e deployment del codice in piccole
iterazioni diminuendo la possibilità di sviluppare codice su versioni precedenti affette da bug
o malfunzionamenti. ([15]).
La CI/CD si sposa bene con la metodologia Agile/SCRUM, proprio per questo motivo.
La volontà di implementare questo processo di integrazione automatizzata viene dal de-
siderio dei quadri superiori dell’istituto ISIN di partecipare attivamente allo sviluppo della
piattaforma con l’obiettivo di poter integrare man mano le funzionalità nel loro processo pro-
duttivo e di analisi.
Questo progetto di Bachelor prevede il rilascio di una grande quantità di nuove funzionalità
ed ha la necessità di basarsi su una metodologia di lavoro come questa.
Nella fase iniziale si vuole quindi mettere in piedi una struttura CI/CD che automatizzi tutte
quelle fasi di controllo attraverso cui il codice deve passare prima di arrivare al cliente. Inoltre
adottando la CI/CD l’interazione con il committente diviene più semplice e il feedback viene
ottenuto in maniera immediata dando così la possibilità di applicare eventuali miglioramenti
alle versioni rilasciate.
ISIN Planner
42 Approccio al problema
4.5 Continuous Integration
Figura 4.3: Diagramma di flusso della Continuous Integration (fonte: [2])
La Continuous Integration può essere rappresentata con un ciclo composto da principal-
mente 3 elementi: implementazione, building7 e testing.
Il suo obiettivo è quello di assicurare allo sviluppatore di avere una versione funzionante del
software prima ancora di rilasciarla al cliente.
I Team di sviluppo che adottano questo processo di sviluppo innanzitutto si affidano a un
server di controllo del codice sorgente, anche detto strumento di controllo versione
distribuito.
Il compito di questo server è quello di mantenere una copia del codice sorgente di un pro-
getto per fare sì che tutti gli sviluppatori di un Team abbiano un punto di accesso all’ultima
versione del progetto.
Tutte le volte che uno sviluppatore deve apportare delle modifiche, effettua una copia locale
del software presente sul server. Per fare ciò utilizza un sistema di gestione del codice
sorgente (ad esempio Git, [16]). Un sistema di gestione del codice sorgente tiene tutti i file
di un progetto all’interno di un repository8 e fornisce i meccanismi per accedere, copiare,
modificare e cancellare tali file.
7In informatica questo processo viene usato per trasformare i file del codice sorgente in un applicazioneeseguibile.
8Simile a un database.
ISIN Planner
43
Una volta ottenuta la copia, lo sviluppatore può apportare tutte le modifiche necessarie
per implementare la funzionalità desiderata. Ovviamente questa operazione va ad altera-
re ciò che era presente nell’ultima versione del codice presente sul repository. Poichè la
Continuous Integration impone che tutte le nuove funzionalità devono essere testate prima
di essere rilasciate, lo sviluppatore deve assicurarsi di implementare i test di ciò che ha
sviluppato.
I test hanno numerosi vantaggi tra cui quello di descrivere le funzionalità e i comportamenti
che deve avere l’applicazione. Inoltre essi permettono ad altri sviluppatori di verificare se le
funzionalità che hanno introdotto hanno alterato il lavoro di qualcun’altro.
Prima di poter effettuare un commit9 dei propri cambiamenti, lo sviluppatore deve assicu-
rarsi di effettuare due operazioni. La prima è l’esecuzione del building e del testing sulla sua
macchina locale. Una volta che si assicura che il codice è funzionante passa alla seconda
operazione che consiste nell’aggiornare nuovamente il proprio codice con quello presen-
te nel repository. Questo viene fatto perchè può darsi che un’altro sviluppatore abbia già
introdotto delle nuove funzionalità.
A questo punto lo sviluppatore ripete la fase di building e testing in locale per assicurarsi
che le modifiche di qualcun’altro non abbiano avuto influenza su ciò che ha implementato.
Qual’ora si presentino degli errori, deve ripetere il processo appena citato.
Una volta che le due versioni sono sincronizzate, è possibile effettuare il commit.
A questo punto entra in gioco un altro elemento. Il server di integrazione continua (la
prossima sezione entra più in dettaglio in merito al server di integrazione continua scelto
per questo progetto).
Questo server reagisce ai cambiamenti effettuati sul server di controllo del codice sorgente
ed esegue il processo di building e testing in maniera automatizzata dando un feedback
riguardo all’eventuale presenza di errori. Anche in questo caso è importante correggere gli
errori per poter rimettere in funzione la pipeline10.
Anche se il processo di Continuous Integration può sembrare complicato e macchinoso,
una volta che viene instaurato all’interno di un’azienda i benefici che porta sono moltepli-
ci. Esso infatti porta gli sviluppatori a lavorare in maniera sincronizzata e a piccoli passi,
riducendo la quantità di bug e aumentando la velocità con cui essi vengono risolti poichè
saltano all’occhio immediatamente. ([17])
9Operazione che aggiorna la versione presente sul repository.10Insieme di passaggi collegati ed eseguiti in sequenza.
ISIN Planner
44 Approccio al problema
4.5.1 Team City
Il software usato da questo progetto per l’implementazione della Continuous Integration è
Team City. TeamCity è un server pensato appositamente per l’integrazione continua delle
applicazioni ed è capace di gestirne il build management. Il server di Teamcity (vedi "Conti-
nuous Integration Server" in Figura 4.3) è collegato direttamente con il server di versioning
della nostra applicazione e può essere configurato per reagire alle modifiche apportate dallo
sviluppatore. I motori di TeamCity, detti Build Agents, sono coloro che eseguono i build-
steps configurati dall’utente. I Build Steps rappresentano la serie di comandi da eseguire
per installare le dipendenze, testare e rilasciare un’applicazione per renderla disponibile
al cliente. Questo processo corrisponde esattamente all’automatizzazione dei passaggi
menzionati nella sezione 4.5. I Build Agents sono di fatto dei pezzi di software installati e
configurati separatamente dal Server di TeamCity, sulla stessa macchina del server oppure
su una macchina separata. I Build Agents si occupano di controllare il codice sorgente e di
eseguire il processo di build. Ogni Build Agent esegue al massimo un processo di build alla
volta.
Figura 4.4: Esempio di processo di build configurato per un’applicazione web.
Gli script definiti nei Build Steps corrispondono ai comandi utilizzati per buildare, testare e
rilasciare un’applicazione. Le tecnologie che stanno alla base di questi comandi sono spie-
gate nelle prossime sezioni.
ISIN Planner
45
Figura 4.5: Pagina principale di TeamCity che mostra un processo di build completato consuccesso per la piattaforma ISIN Planner.
ISIN Planner
46 Approccio al problema
4.6 Continuous Delivery
La Continuous Delivery è una disciplina nello sviluppo software in cui il programma viene
implementato facendo in modo di poter essere rilasciato in qualsiasi momento. ([18])
La Continuous Delivery è ottenibile integrando continuamente il software; il processo su
cui si basa viene eseguito solamente dopo che i passaggi della pipeline di Continuous In-
tegration, incaricati di fare il building e il testing vengono completati senza errori. (vedi
Figura 4.2)
La sezione 4.4 mostra chiaramente il posizionamento della Continous Delivery rispetto
quanto spiegato nella sezione 4.5.
Questa disciplina di sviluppo porta due grossi benefici:
• Rischi ridotti in fase di rilascio: Combinando CI e CD, la quantità di modifiche
ad ogni rilascio è minima, questo diminuisce la probabilità di riscontrare problemi e
aumenta la facilità con cui risolverli.
• Feedback: Rilasciando costantemente nuove versioni accessibili al cliente, permet-
te di ottenere numerosi feedback. Quest’ultimi aiutano lo sviluppatore a capire se il
lavoro che sta svolgendo va in direzione o meno di ciò che si è prefissato il cliente.
ISIN Planner
47
4.6.1 Docker
Docker è un progetto open-source utilizzato da molti sviluppatori per implementare, rilascia-
re ed eseguire con facilità le applicazioni in ambienti sandbox11.
Il grosso vantaggio di Docker è quello di permettere ai propri utenti di impacchettare le
proprie applicazioni insieme a tutte le dipendenze necessarie per eseguirle, in un’unità
standardizzata per lo sviluppo di software chiamata container. ([19])
Usando Docker, gli sviluppatori sono in grado di ottenere dei deploy completamente portabili
su qualsiasi piattaforma. La facilità di configurazione dei container docker ha permesso alle
aziende di sviluppo software di velocizzare ulteriormente il processo di Continuous Integra-
tion / Continuous Delivery.
La prima versione della piattaforma ha già una pipeline configurata su TeamCity per ef-
fettuare la build e il testing attraverso Docker. Per questo motivo è stato deciso di continuare
ad utilizzarlo per il processo di CI/CD di questo progetto.
Come spiegato nella sezione 4.2, questo progetto di diploma mira ad effettuare una tran-
sizione di architettura e quindi di estrarre la parte di interfaccia dal back-end delegando
l’elaborazione di quest’ultima direttamente al browser web dell’utente.
Per questo motivo, avendo due parti distinte, l’obiettivo è quello di aggiornare la pipeline di
TeamCity per supportare il processo di building e di testing attraverso Docker anche per le
parti di interfaccia estratte e re-implementate. Facendo così viene mantenuta l’automatizza-
zione del processo di CI/CD.
Per maggiori informazioni riguardo al funzionamento di Docker, leggere l’Appendice B.
11Ambiente che permette di isolare programmi o applicazioni per effettuare dei test.
ISIN Planner
48 Approccio al problema
4.6.2 Kubernetes
Kubernetes (abbreviato K8s) è una piattaforma open-source, portabile ed estensibile per
la gestione di servizi basati su container che mira a facilitarne la configurazione e l’auto-
mazione. I servizi e gli strumenti che mette a disposizione sono supportati su larga scala.
([20])
La necessità da parte dei quadri superiori dell’istituto di seguire il processo di espansione
apportato in questo progetto di diploma, ha portato il bisogno di instaurare un’infrastruttura
in grado di rilasciare le nuove versioni dela piattaforma in maniera automatica e controllata.
Come visto nella sezione sottosezione 4.6.1, i container sono un ottimo modo per im-
pacchettare ed eseguire le proprie applicazioni in maniera indipendente dalla piattafor-
ma/sistema operativo su cui si trovano.
Ma kubernetes quale ruolo ha in questo contesto?
I container, come qualsiasi altro programma o processo, a volte riscontrano dei problemi
che possono interromperne inaspettatamente l’esecuzione.
In ambienti di produzione, in cui il cliente si aspetta di avere un programma sempre fun-
zionante, questo genere di problemi non devono presentarsi e devono essere gestiti per
assicurare che non ci siano periodi prolungati di inattività.
A questo proposito Kubernetes fornisce un framework per eseguire e mantenere sistemi
distribuiti in modo resiliente. ([20]).
La scelta di utilizzare K8s per l’implementazione della Continuous Delivery deriva dal fat-
to che la SUPSI è già in possesso di un server Kubernetes e il committente ha richiesto che
quest’ultimo venisse sfruttato per rilasciare le nuove funzionalità implementate in questa tesi
di bachelor.
Per maggiori dettagli riguardo al funzionamento di K8s, leggere l’Appendice C.
ISIN Planner
49
4.7 Tecnologie Web
Questo progetto di diploma mira all’introduzione di tecnologie web più avanzate per fa-
vorire l’aggiunta di estensioni e miglioramenti futuri alla piattaforma ISIN Planner. (vedi
sezione 2.2.
4.7.1 NPM - Node Package Manager
Node Package Manager è il software registry open-source più grande del mondo, contiene
più di 800’000 pacchetti di codice. Npm viene utilizzato dagli sviluppatori open-source per
condividere il proprio codice e molte aziende lo hanno adottato per gestire i propri ambienti
di sviluppo. ([21])
Questo progetto sfrutta la capacità di npm di gestire e scaricare le dipendenze necessarie
al funzionamento della parte front-end.
4.7.1.1 Node.js
Node.js è un ambiente di esecuzione costruito su misura per Javascript in grado di generare
il contenuto di pagine dinamiche, gestire l’apertura, la creazione, la modifica e l’eliminazione
di file lato server, gestire i dati di un database, ecc.
Spesso e volentieri un client potrebbe avere bisogno di accedere ad un file che si trova
sul server, per farlo manda una richiesta a quest’ultimo. Node.js rimane in ascolto di eventi
di questo genere ed è capace di interagire con il file-system di un server per recuperare il
contenuto di un file e restituirlo al client. Il vantaggio di Node.js è quello di agire in maniera
asincrona. ([22])
ISIN Planner
50 Approccio al problema
Originariamente Node.js quindi era stato creato con lo scopo di gestire l’ambiente di back-
end delle applicazioni.
Con il passare del tempo gli sviluppatori hanno riconosciuto il suo potenziale ed hanno
iniziato ad usarlo per creare degli strumenti che possano aiutarli nell’automazione della ge-
stione locale dei pacchetti. Per poter condividere, scaricare e installare tutti questi pacchetti,
è nato npm.
4.7.1.2 package.json
Per poter utilizzare npm è necessario scaricare e installare Node.js. Una volta che l’inter-
faccia da linea di comando è funzionante, è sufficiente digitare il comando npm init il quale
avvia una guida interattiva per la creazione del file package.json.
Questo file descrive il progetto e fa da file di configurazione.
In esso vengono definite le dipendenze/librerie che necessita il progetto per poter funzionare
correttamente. Esso permette di definire degli script che facilitano l’esecuzione di comandi
come building, testing, ecc. :
Figura 4.6: Esempio di package.json
Una volta creato e definito il package.json, per scaricare e installare le dipendenze è suffi-
ciente eseguire il comando npm install.
ISIN Planner
51
4.7.2 Webpack
Visto il potenziale di crescita di questa piattaforma e di conseguenza l’elevato numero di
moduli da essa usati, è stato deciso di introdurre le funzionalità offerte da Wepback.
Webpack è un module bundler, quali sono le funzionalità che fornisce?
Figura 4.7: Processo di boundling di webpack
Con l’avvento di Framework web come Vue.js, React.js, ecc., la popolarità di webpack è
cresciuta. Il motivo di questa crescita è dovuto al fatto che tali framework comportano la
creazione di molti moduli con una grande quantità di file javascript e css.
Soprattutto in progetti di grandi dimensioni, la difficoltà a gestire un numero alto di moduli au-
menta. Il programmatore è costretto ad importare tutti i moduli e i fogli di stile manualmente
in tutte le pagine in cui ha intenzione di usarli.
Grazie a webpack, questo non è più necessario perché esso è in grado di raccogliere tutti
i moduli utilizzati dal progetto, detti anche entries, e di impacchettarli in un singolo file,
chiamato output. (vedi Figura 4.7)
Il file di output poi può essere incluso nelle pagine della propria applicazione web per sfrut-
tare le funzionalità dei moduli che sono stati impacchettati.
ISIN Planner
52 Approccio al problema
Per indicare a webpack qual’è il percorso in cui deve cercare le entries e qual’è il percorso in
cui deve salvare l’output, è possibile definire un file di configurazione (solitamente chimato
webpack.config.js):
Figura 4.8: Esempio di file di configurazione per webpack
Per impacchettare i moduli poi è sufficiente eseguire il seguente comando:
Figura 4.9: Comando da eseguire per impacchettare i moduli di un progetto
ISIN Planner
53
4.7.3 Vue.js
Vue.js è un progressive framework12 nato per sviluppare interfacce utente e SPAs13 (Single-
Page Applications). A differenza di altri framework monolitici14, Vue è pensato per essere
adottato in maniera incrementale: la libreria principale alla base di questo framework si foca-
lizza esclusivamente sul livello di view ed è facilmente integrabile con altre librerie o progetti
già esistenti. ([23])
Il committente del progetto ha imposto quale requisito quello di utilizzare Vue.js poiché esso
viene già utilizzato dai Team di sviluppo dell’istituto. In passato inoltre era già stato imple-
mentato un prototipo della piattaforma realizzato completamente con questo framework.
Vue.js è stato pensato per essere integrato con una grande semplicità in progetti esistenti.
Questo è dovuto in parte anche grazie all’ottima curva di apprendimento, poiché l’utilizzo di
Vue richiede conoscenze di base dei linguaggi HTML, CSS e Javascript.
Inoltre, come visto nella sezione 2.2, lo scopo della piattaforma è quello di estrarre gradual-
mente tutti gli elementi di interfaccia dal back-end e di effettuare un refactoring basato sulla
programmazione orientata ai componenti fino ad ottenere una netta separazione tra back-
end e front-end.
Vue.js fornisce dei meccanismi che facilitano l’implementazione di componenti le cui funzio-
nalità sono efficacemente isolabili e testabili. Questo permette di diminuire l’accoppiamento
complessivo del codice, favorendo la riusabilità dei componenti grafici e diminuendo la pro-
babilità di introdurre dei bug.
Per entrare maggiormente in dettaglio riguardo alla semplicità di integrazione del framework
Vue.js, e capire in che modo integrarlo all’interno di un progetto Spring esistente, leggere
l’Appendice D.
12Con alta flessibilità di estensione attraverso altre librerie Javascript.13Applicazione web pensata per essere consultata su una singola pagina.14Un framework monolitico include tutte le funzionalità necessarie a risolvere casì comuni di sviluppo di
applicazioni web.
ISIN Planner
54 Approccio al problema
4.7.3.1 Vuetify e bootstrap-vue
Vuetify è un framework front-end realizzato appositamente per Vue.js, esso fornisce tutta
una serie di componenti material design come bottoni, tabelle, input, ecc. Material Design è
un linguaggio visuale creato da Google che denisce tutta una serie di principi per il design
di interfacce con effetti e transizioni di profondità quali illuminazione e ombre. Si è deciso di
utilizzare questo framework poichè fornisce un sistema di layout molto intuitivo che facilita il
posizionamento dei componenti e favorisce la compatibilità con i dispositivi mobile.
I componenti realizzati da questo framework garantiscono grande flessibilità e possono es-
sere modificati a piacere in base al contesto in cui li si usa. I componenti di Vuetify sono
implementati rispettando i vincoli del Material Design.
Material Design è un linguaggio visuale creato da Google che definisce tutta una serie di
principi per il design di interfacce con effetti e transizioni di profondità quali illiminazione e
ombre. ([24])
Per non stravolgere il design e soprattutto per semplificare il processo di refactoring del-
la piattaforma, alcuni degli elementi dell’interfaccia esistente verranno estratti e riprodotti
con la libreria bootstrap-vue. Essa supporta gli stessi componenti di Bootstrap 4 e lo stesso
sistema di layout. Inoltre integra tutte le funzionalità delle direttive Vue, questo permette di
sfruttare tutti i vantaggi del suo eco-sistema.
I componenti di bootstrap-vue sono stati implementati per essere reattivi e forniscono tutta
una serie di effetti grafici molto gradevoli che possono essere utilizzati per modernizzare la
piattaforma e fornire un’esperienza utente più accattivante e interattiva.
ISIN Planner
55
4.7.4 Highcharts
Vista l’esigenza dell’istituto ISIN di estendere la piattaforma attraverso componenti grafici di
carattere analitico, assieme al relatore Roberto Guidi, è stato deciso di integrare la libreria
Highcharts.
Highcharts è una libreria scritta in Javascript la cui prima versione risale al 2009. Il suo
scopo è quello di offrire un metodo semplice per arricchire le applicazioni web con grafici
interattivi. Essa fornisce una grande varietà di diagrammi, curve, spline, grafici a torta,
scatter plot, box plot, ecc., per ogni esigenza e complessità dei dati.
Npm espone un pacchetto che facilita l’utilizzo di Highcharts in applicazioni basate su Vue.
Questo pacchetto è chiamato highcharts-vue, esso crea un’istanza di Highcharts utilizzabile
sotto forma di elemento html in un qualsiasi componente Vue. Questo elemento html ha
una prop chiamata options che aggetta un oggetto; all’interno di questo oggetto è possibile
specificare molteplici opzioni che definiscono l’aspetto del grafico che si vuole utilizzare.
([25])
L’idea è quella di implementare dei componenti Vue che facciano da wrapper15 ai diversi tipi
di grafici Highcharts. I componenti devono essere dotati di props che permettano un facile
accesso ai vari diagrammi e che ne facilitino la modifica sia per quanto riguarda il design
(colori, stile, ecc.) sia per quanto riguarda le funzionalità (attivazione/disattivazione elementi
visibili, valori massimi e minimi per gli assi dei grafici, ecc.).
15In questo caso si intende un componente che avvolge le funzionalità di un altro per renderlo più accessibile.
ISIN Planner
56 Approccio al problema
ISIN Planner
57
Capitolo 5
Risultati
ISIN Planner
58 Risultati
Il seguente capitolo illustra le funzionalità che sono state realizzate nel corso di questa tesi
di Bachelor. Le varie sezioni cercano di descrivere quanto fatto e mettono a confronto le
vecchie funzionalità con quelle nuove, in particolare per queste ultime vengono evidenziati i
vantaggi che hanno arricchito la piattaforma. L’accento viene posto sull’impatto dei benefici
che ha prodotto questo lavoro.
ISIN Planner
59
5.1 Configurazione CI/CD
La configurazione della pipeline di CI/CD sul server TeamCity è composta da sette step
visibili in Figura 5.1.
Figura 5.1: Pipeline di CI/CD del progetto ISIN Planner
• Il processo di build inizia installando le dipendenze necessarie della parte di front-end.
• Il build agent esegue un passo di build che consiste nell’impacchettare tutti i moduli
attraverso webpack al fine di ottenere un modulo unico.
• Viene eseguito il testing della parte di front-end.
• Build del back-end.
• Testing del back-end. Una volta completato questo passaggio si è sicuri che l’appli-
cazione è stata testata e che non si sono presentati degli errori. Si passa quindi al
deploy.
• Il sesto step si occupa di effettuare la build delle immagini docker.
• Il settimo step effettua il login al docker registry ed effettua un push delle immagini.
• L’ottavo e ultimo step imposta il file di configurazione di Kubernetes ed effettua l’ag-
giornamento del pod che esegue il container in cui è contenuta l’ultima versione
dell’applicazione.
ISIN Planner
60 Risultati
5.2 Nuove funzionalità
5.2.1 Autenticazione basata sul ruolo
Come visto nella sottosezione 3.3.1, l’istituto ISIN ha richiesto la possibilità di sfruttare un
meccanismo di login basato sul ruolo degli utenti.
Per poter implementare tale funzionalità, sono state sfruttate in gran parte le configurazioni
che erano già presenti nel progetto. Spring permette agli sviluppatori di creare applicazioni
web le cui risorse sono protette dal framework Spring Security. Spring Security viene confi-
gurato creando una classe java (nel caso della piattaforma WebConfiguration) che estende
la classe WebSecurityConfigurerAdapter. Questa classe espone una serie di metodi di
cui è possibile effettuare l’override. Questi metodi permettono di specificare tutta una serie
di configurazioni, tra cui la configurazione per la web security. Il metodo attraverso il quale si
definiscono le regole di accesso e autenticazione è configure(HttpSecurity ), esso definisce
quali percorsi URL devono essere protetti e quali no. La versione iniziale della piattaforma
faceva uso di questo metodo, ma non poneva alcun limite a livello di autenticazione. Tutti i
tipi di utenti autenticati infatti avevano accesso a tutti i contenuti.
Per ovviare a questo problema, il metodo configure della classe WebConfiguration è stato
modificato come mostrato in figura
Figura 5.2: Modifiche apportate al metodo configure
Come si può vedere, tutti gli endpoint della piattaforma che non dovrebbero essere accessi-
bili ad utenti normali, adesso richiedono che l’utente loggato abbia il ruolo di amministratore.
ISIN Planner
61
A livello di visualizzazione, gli utenti non amministratori devono avere accesso solamen-
te alla loro pagina di pianificazione (vedi Figura 3.6) e tutti i pulsanti che permettono ad un
amministratore di modificare il Dutysheet e il Planning di un determinato periodo devono
essere disabilitati.
Per fare ciò è innanzitutto stato necessario modificare il controller che fornisce l’accesso alla
pagina home della piattaforma (percorso: "/", vedi Figura 5.3).
Il metodo mappato per le richieste a questo percorso ottiene il ruolo dell’utente sfruttando
la funzione getAuthentication() della classe Authentication di Spring Security e in base al
valore ottenuto lo redireziona alla pagina corretta.
Figura 5.3: Redirezione della pagina home alla pagina dei progetti se l’utente èamministratore, altrimenti su quella del dipendente (risorsa)
Per disabilitare i pulsanti invece è stata sfruttata un’altra funzionalità di Spring Security, il tag
authorize accessibile attraverso i template dell’applicazione, il quale permette di verificare
direttamente via HTML se l’utente loggato è amministratore oppure no (vedi Figura 5.4).
Figura 5.4: Esempio di utilizzo del tag authorize
5.2.2 Dashboard delle statistiche di progetto
La prima di tutta una serie di funzionalità richieste legate alla necessità di trasformare la
piattaforma in un tool analitico oltre che di pianificazione, è stata la creazione di una dash-
board che mostri una serie di grafici legati all’utilizzo del budget e delle ore di un determinato
progetto.
ISIN Planner
62 Risultati
Come già menzionato diverse volte, la versione iniziale della piattaforma aveva principal-
mente come compito quello di fare da strumento di pianificazione delle ore dei dipendenti
e di fornire alcune pagine di resoconto attraverso cui visualizzare con maggiore dettaglio le
pianificazioni e le spese derivanti dai progetti.
Tuttavia questo tipo di visualizzazione non è sufficientemente dettagliato per dare un’idea
dell’andamento generale delle ore di un progetto e del budget impiegato in esso, rendendo
spesso difficile l’individuazione di problemi dovuti a pianificazioni sovra/sotto dimensionate,
errori di inserimento, ecc.
I quadri superiori dell’istituto hanno quindi richiesto l’implementazione di una dashboard di
statistiche dedicata ad ogni progetto in cui poter vedere dei grafici che mostrino l’andamento
del budget e delle ore pianificate.
Essa è accessibile sia dalla lista dei progetti, vedi sottosezione 3.3.2 (il pulsante è stato
aggiunto a fianco di ognuno dei progetti nella lista), sia dalla pagina dedicata ai singoli
progetti (vedi Figura 5.5)
ISIN Planner
63
Figura 5.5: Pagina di un progetto con il pulsante che porta alla dashboard delle statistiche
ISIN Planner
64 Risultati
La Dashboard mostra i dati relativi al progetto e dà la possibilità di scegliere il grafico da
visualizzare attraverso le schede Budget e Hours.
Figura 5.6: Dashboard delle statistiche di progetto
ISIN Planner
65
5.2.2.1 Ritaglio economico e surplus rate
Per capire in quale modo l’istituto è in grado di determinare se i costi di un progetto sono
stati sovra dimensionati oppure no e quindi se un progetto è stato pianificato correttamente
al fine rimanere nei limiti del budget, vengono introdotti i concetti di ritaglio economico e
surplus rate.
Il ritaglio economico è un termine usato in ambito commerciale per definire la differenza tra
due importi.
Come visto nella sottosottosezione 1.2.1.2, l’istituto ISIN è supportato da tutta una serie di
enti di finanziamento i quali offrono i propri fondi per sostenere i progetti di ricerca.
Solitamente quando viene accordato un progetto, vengono definiti tre valori di riferimento: Il
budget totale del progetto, la quantità di ore previste e la percentuale di auto-finanziamento
che determina a quanto corrisponde lo sforzo economico che l’istituto deve mettere di suo.
La somma dei costi di tutti i dipendenti coinvolti in un progetto di ricerca (per tutto l’arco
della sua durata), equivale alle spese effettive (si esclude i costo del materiale di lavoro)
dell’istituto, per quel progetto.
A livello di istituto, i costi di un dipendente per un dato periodo di lavoro e un dato progetto,
vengono calcolati moltiplicando le ore di lavoro che egli ha effettuato per la sua tariffa oraria.
La tariffa oraria di un dipendente varia in base al ruolo che egli ricopre.
Un altro valore molto importante è la tariffa media dell’ente di finanziamento; essa viene
calcolata dividendo il budget e le ore totali accordate.
Grazie a tutte queste variabili, l’istituto può calcolare il ritaglio economico di un progetto,
il quale è sostanzialmente la differenza tra il costo che si ottiene moltiplicando le ore pia-
nificate per la tariffa media dell’ente e il costo che si ottiene moltiplicando le ore pianificate
applicando la tariffa SUPSI/ISIN.
Un dato di questo genere tuttavia non dà un idea chiara di ciò che rappresenta, per questo
motivo viene calcolato il surplus rate, che è una percentuale che permette ai quadri superiori
dell’istituto di capire in quale modo è stata effettuata la pianificazione di un determinato
progetto.
Il surplus rate viene calcolato dividendo il ritaglio economico per il costo calcolato attraverso
la tariffa media dell’ente, esso è un indicatore che permette di tenere sotto controllo la
pianificazione dei progetti e determinare se essa è corretta oppure no.
Un costo sovra-dimensionato può portare a superare il budget totale previsto dall’ente di
finanziamento, viceversa, un costo sotto-dimensionato può portare l’istituto a non raggiun-
gerlo. L’importanza di tenere sotto controllo il surplus-rate permette di capire se il budget è
stato pianificato correttamente.
ISIN Planner
66 Risultati
5.2.2.2 Trend del budget
Figura 5.7: Grafico che mostra i trend del budget
Questo grafico mostra una serie di curve che descrivono l’utilizzo del budget lungo tutto l’ar-
co del progetto: utilizzo del budget (rispetto tariffa SUPSI/ISIN), utilizzo del budget (tariffa
SUPSI/ISIN) senza ore matching funds (visualizzata se il progetto ne ha), utilizzo del bud-
get (rispetto tariffa media), ritaglio economico, ritaglio economico senza ore matching funds
(visualizzata se il progetto ne ha).
Come già spiegato nella sottosottosezione 5.2.2.1, il ritaglio economico è un valore che se
preso singolarmente, non è in grado di fornire sufficienti informazioni. Tuttavia, come mo-
strato in Figura 5.7, se questo valore viene calcolato su tutto l’arco del progetto, è possibile
capire in che modo sono state distribuite le ore pianificate.
L’oscillazione del ritaglio economico è facilmente individuabile in una rappresentazione di
questo genere ed è facile capire quali sono gli eventuali periodi critici in cui è necessario
rivedere la pianificazione delle ore dei dipendenti.
Un’altra funzionalità supportata da questo grafico è quella di poter focalizzare la visualiz-
zazione sull’arco dei singoli anni. Nella parte in alto a sinistra del grafico sono presenti i
bottoni che permettono di effettuare questa operazione (vedi Figura 5.8)
ISIN Planner
67
Figura 5.8: Zoom rispetto all’anno 2019
Per implementare questo grafico è stata sfruttata la libreria Highcharts (sottosezione 4.7.4).
Per poterla utilizzare, è sufficiente creare un’istanza. Durante la sua creazione, questa
istanza accetta come argomento un oggetto.
Il grafico è wrappato da un componente Vue chiamato Chart, il quale espone le seguenti
props per modificare l’aspetto del grafico:
• titolo
• source: percorso attraverso cui richiedere i dati
• currentDate: permette di modificare la posizione della linea tratteggiata verticale che
mostra la data corrente
• seriesTitle: array di stringhe contenente i titoli delle curve)
• seriesColors: array di stringhe contenente i colori delle curve
• xAxisTitle, yAxisTitle
• xAxistType, yAxisType: stringa usata da highcharts per capire il tipo di dato rappre-
sentato sugli assi, il valore di default è datetime.
• xTickInterval, yTickInterval: valore di un’unità sugli assi x e y
• xAxisMin, yAxisMin
• yAxisMax, yAxisMax
ISIN Planner
68 Risultati
Queste props sono mappate direttamente all’oggetto contenente le opzioni dell’istanza di
highcharts wrappata dal componente.
Per poter accedere ai dati, il componente effettua una richiesta http, la cui risposta è un
oggetto json contenente la lista punti per tracciare il grafico.
A livello di implementazione, nel back-end è stato aggiunto l’endpoint attraverso il quale il
componente Chart richiede i dati. Per quanto riguarda le entità, le modifiche sono state
abbastanza contenute.
L’entità "Progetto" inizialmente era dotata solamente del budget totale. Per poter effettua-
re tutti i calcoli mostrati nell’esempio è stato necessario aggiungere i campi Hours e Self
financing rate. Questi campi sono specificabili all’interno della modale di creazione di un
progetto.
5.2.2.3 Trend delle ore
Figura 5.9: Zoom rispetto all’anno 2019
L’istituto ha richiesto di realizzare anche un grafico da includere nella Dashboard di statisti-
che del progetto che mostri l’andamento dell’utilizzo delle ore, utile per monitorare il residuo
delle ore per un determinato periodo del progetto.
Per realizzare questo grafico è stato riutilizzato il componente Chart menzionato nella sot-
tosottosezione 5.2.2.2. L’unica differenza è il percorso attraverso il quale viene effettuata la
richiesta http per ottenere i dati.
ISIN Planner
69
5.2.3 Categoria progetto
La versione attuale della piattaforma presenta un grande limite in merito alla distinzione dei
vari progetti.
La sottosottosezione 3.3.2.2 tratta dei tipi progetto e sottolinea che essi sono sfruttati per
individuare il tipo di finanziamento dei progetti. Una distinzione di questo genere talvolta
però non è sufficiente, soprattutto quando si vuole raggruppare i progetti in gruppi più gene-
rici. La piattaforma ad esempio non permette di distinguere i progetti di ricerca dai progetti
di tipo amministrativo (nei quali vengono inserite le ore di malattia, vacanza, ecc.). Tutti i
progetti infatti vengono mostrati in una lista che non è possibile filtrare in questo modo.
Per poter porre rimedio a questa problematica, il committente del progetto ha richiesto di
implementare un sistema che faciliti la distinzione dei progetti, in particolare nei seguenti
gruppi: Progetti di ricerca, Preparazione progetti e Amministrazione.
A questo proposito è stato pensato di aggiungere un livello di astrazione in più per quanto
riguarda la descrizione dei progetti: le categorie.
Per non andare ad alterare in maniera troppo invadente la struttura dati, è stato deciso di
mappare i tipi progetto esistenti a queste categorie, facendo così la logica che era stata
prevista inizialmente rimane intatta e con lei anche tutte le funzionalità già presenti. Il van-
taggio che si ottiene è quello di poter distinguere i progetti non più solo in base al loro tipo
ma anche attraverso la loro categoria.
A livello più tecnico, l’aggiunta di una mappatura di questo genere comporta la creazione di
una relazione many-to-many. È stato deciso di adottare questo tipo di relazione per fare
in modo che una categoria possa essere mappata a più tipi progetto e viceversa un tipo
progetto possa essere mappato a più categorie.
Figura 5.10: Relazione tra tipo progetto e categoria
ISIN Planner
70 Risultati
I tipi progetto e le categorie sono state mappate volutamente nel database in maniera
permanente, senza dare la possibilità all’utente di modificarne la relazione.
Facendo così, nel momento della creazione del progetto quando viene scelto il tipo progetto,
senza che l’utente se ne renda conto, il progetto viene classificato automaticamente anche
nella categoria corrispondente al tipo progetto selezionato.
Nella prima versione della piattaforma, i tipi progetto Assenze, Amministrazione e Prepa-
razione progetti non erano presenti, sono stati aggiunti per poterli mappare alle categorie
corrispondenti. Qualora un giorno fosse necessario suddividere ulteriormente i tipi appena
citati, è sufficiente crearne dei nuovi e mapparli alla stessa categoria.
ISIN Planner
71
5.2.4 Main Dashboard
Uno degli scopi più rilevanti di questo progetto di diploma è stato quello di espandere la
piattaforma ISIN Planner per fare in modo che essa non faccia più solamente da strumento
di pianificazione ma anche di analisi.
Oltre alla Dashboard per le statistiche legate ai singoli progetti, l’istituto ISIN ha esposto la
necessità di avere una Main Dashboard attraverso la quale poter avere accesso a tutta una
serie di componenti grafici che forniscano degli strumenti attraverso cui poter estrapolare
statistiche di confronto fra progetti e dipendenti.
È importante sottolineare che l’implementazione di questa funzionalità è avvenuta completa-
mente attraverso componenti Vue. Questo per forzare il cambiamento di architettura trattato
nella sezione 4.2. Lo sviluppo e il funzionamento di questi componenti verranno analizzati
con maggiore dettaglio nelle prossime sezioni.
5.2.5 Dashboard annuale
Il direttore dell’istituto ISIN ha espresso la necessità di una sezione nella Main Dashboard
che possa mostrare alcune statistiche annuali legate all’istituto.
In particolare è stato presentato il bisogno di implementare un grafico a torta che mostri la
distribuzione delle ore dei progetti in base alla loro categoria e una piccola sezione in cui
fosse possibile vedere le entrate e le uscite totali dell’istituto. La Dashboard annuale inoltre
deve poter permettere di filtrare i dati per anno e per team di sviluppo.
A livello di implementazione la dashboard annuale è rappresentata da un componente Vue
chiamato AnnualDashboard che fa da componente padre ad altri quattro componenti. I primi
due rappresentano le due sezioni menzionate nel paragrafo precedente. Gli altri due invece
rappresentano i drop-down menu attraverso i quali è possibile impostare i filtri richiesti dal
committente.
Al caricamento della Main Dashboard, la Dashboard annuale viene sempre popolata con
i dati filtrati rispetto all’anno corrente (il filtro per team è disattivato ed è impostato su All),
vedi Figura 5.11.
ISIN Planner
72 Risultati
Figura 5.11: Dashboard annuale, notare i filtri di default
ISIN Planner
73
5.2.5.1 Filtri: anno e team
Per filtrare i dati presenti nella Dashboard annuale, sono stati implementati due drop-down
menu sfruttando la libreria Vuetify (vedi sottosezione 4.7.3). Il primo permette di filtrare la
Dashboard attraverso l’anno mentre il secondo permette di filtrarla per team di sviluppo. È
possibile combinare i due filtri a piacere.
Il primo filtro viene popolato richiedendo tutti i periodi di lavoro che sono stati inseriti nel
database, il suo valore di default è impostato sull’anno corrente.
Il secondo filtro invece viene popolato con tutti i team di sviluppo. In questo caso il valore
di default corrisponde al valore "All", questo significa che le statistiche vengono mostrate
rispetto a tutte le persone che lavorano per l’istituto ISIN. Altrimenti, selezionando uno dei
team, i progetti e le ore di didattica considerati sono tutte quelle che coinvolgono le persone
che fanno parte del team selezionato. (vedi Figura 5.12)
Figura 5.12: Filtri della Dashboard annuale
ISIN Planner
74 Risultati
5.2.5.2 Entrate e uscite dell’istituto
Figura 5.13: Componente che mostra le entrate e le uscite dell’istituto
La prima funzionalità richiesta da visualizzare nella Dashboard annuale è un resoconto delle
entrate e uscite totali dell’istituto.
Le uscite dell’istituto sono calcolate nel modo seguente: