ISIN Planner - tesi.supsi.ch

ISIN Planner

Studente/i

Ivan Pavic

Relatore

Roberto Guidi

Correlatore

Patrick Ceppi

Committente

ISIN - Information Systems andNetworking Institute

Corso di laurea

Ingegneria Informatica

Modulo

M00009 Progetto di diploma

Anno

2019

Data

4 settembre 2019

i

Questo lavoro viene sottomesso

a parziale requisito

per il conseguimento del

BACHELOR IN INGEGNERIA INFORMATICA

SCUOLA UNIVERSITARIA PROFESSIONALE

DELLA SVIZZERA ITALIANA

DIPARTIMENTO TECNOLOGIE INNOVATIVE

MANNO, SVIZZERA

ISIN Planner

ii

ISIN Planner

iii

Indice

Abstract 1

Progetto Assegnato 3

Introduzione 5

1 Motivazione e contesto 7

1.1 Motivazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2 Contesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2.1 ISIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2.1.1 Struttura organizzativa . . . . . . . . . . . . . . . . . . . . . 8

1.2.1.2 Finanziamento dei progetti . . . . . . . . . . . . . . . . . . . 9

1.2.2 Piattaforma esistente . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Problema 11

2.1 Fattori chiave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Estensibilità della piattaforma . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Stato dell’arte 15

3.1 Piattaforma ISIN Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Ambienti di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.1 Spring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2.2 Thymeleaf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3 Funzionalità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3.1 Autenticazione e autorizzazione . . . . . . . . . . . . . . . . . . . . . 19

3.3.2 Gestione dei progetti . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3.2.1 Codice progetto . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3.2.2 Tipi progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.2.3 SST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.2.4 Matching funds . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.3 Pagina dei progetti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.4 Gestione delle Risorse e Team di sviluppo . . . . . . . . . . . . . . . . 23

ISIN Planner

iv INDICE

3.3.4.1 Periodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3.4.2 Duty-sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3.4.3 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3.4.4 Pianificazione del lavoro . . . . . . . . . . . . . . . . . . . . 26

3.3.4.5 Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4 Approccio al problema 33

4.1 Introduzione di funzionalità analitiche . . . . . . . . . . . . . . . . . . . . . . 34

4.2 Cambiamento di architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.1 Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3 Metodologia Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3.1.1 Definizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3.1.2 Approccio adottato . . . . . . . . . . . . . . . . . . . . . . . 39

4.3.2 Software di pianificazione . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3.2.1 Source Code Management Redmine . . . . . . . . . . . . . . 40

4.4 CI/CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.5 Continuous Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.5.1 Team City . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.6 Continuous Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.6.1 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.6.2 Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.7 Tecnologie Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.7.1 NPM - Node Package Manager . . . . . . . . . . . . . . . . . . . . . . 49

4.7.1.1 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.7.1.2 package.json . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.7.2 Webpack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.7.3 Vue.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.7.3.1 Vuetify e bootstrap-vue . . . . . . . . . . . . . . . . . . . . . 54

4.7.4 Highcharts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5 Risultati 57

5.1 Configurazione CI/CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.2 Nuove funzionalità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2.1 Autenticazione basata sul ruolo . . . . . . . . . . . . . . . . . . . . . . 60

5.2.2 Dashboard delle statistiche di progetto . . . . . . . . . . . . . . . . . . 61

5.2.2.1 Ritaglio economico e surplus rate . . . . . . . . . . . . . . . 65

5.2.2.2 Trend del budget . . . . . . . . . . . . . . . . . . . . . . . . 66

5.2.2.3 Trend delle ore . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.2.3 Categoria progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

ISIN Planner

v

5.2.4 Main Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.2.5 Dashboard annuale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.2.5.1 Filtri: anno e team . . . . . . . . . . . . . . . . . . . . . . . . 73

5.2.5.2 Entrate e uscite dell’istituto . . . . . . . . . . . . . . . . . . . 74

5.2.5.3 Grafico a torta della distribuzione delle ore . . . . . . . . . . 75

5.2.6 Tabella di utilizzo del budget dei progetti . . . . . . . . . . . . . . . . . 77

5.2.7 Tabella surplus rate dei progetti . . . . . . . . . . . . . . . . . . . . . . 79

5.2.8 Tabella Risorse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.3 Reimplementazione dei componenti . . . . . . . . . . . . . . . . . . . . . . . 81

5.3.1 Progress bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.3.2 Lista dei Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.3.3 Visualizzazione dei Matching Funds . . . . . . . . . . . . . . . . . . . 82

5.3.4 Menu laterale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6 Conclusione 89

A Manifesto Agile 93

B Docker 97

B.1 Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

B.2 Dockerfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

B.3 Immagini Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

B.4 Condivisione delle immagini . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

C Kubernetes 101

C.1 Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

C.2 Pod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

C.3 Nodo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

C.4 kubectl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

C.5 Oggetti Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

D Vue 107

D.1 L’istanza radice di Vue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

D.2 Single File Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

D.3 Direttive, Properties e ciclo di vita di un componente . . . . . . . . . . . . . . 112

ISIN Planner

vi INDICE

ISIN Planner

vii

Elenco delle figure

3.1 Ruolo di un template engine . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Pagina principale della piattaforma che mostra la lista dei progetti . . . . . . . 22

3.3 Modale per l’inserimento di un nuovo duty-sheet . . . . . . . . . . . . . . . . 24

3.4 Modale per l’inserimento di un nuovo planning . . . . . . . . . . . . . . . . . 25

3.5 In dettaglio: la pianificazione di un periodo per la risorsa "Nome Cognome" . . 26

3.6 Pagina di una risorsa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.7 Pagina riassuntiva delle risorse . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.8 Pagina dei Team di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1 Schema del framework Scrum (fonte: [1]) . . . . . . . . . . . . . . . . . . . . 38

4.2 Processo di sviluppo di un progetto basato su CI/CD . . . . . . . . . . . . . . 41

4.3 Diagramma di flusso della Continuous Integration (fonte: [2]) . . . . . . . . . . 42

4.4 Esempio di processo di build configurato per un’applicazione web. . . . . . . . 44

4.5 Pagina principale di TeamCity che mostra un processo di build completato

con successo per la piattaforma ISIN Planner. . . . . . . . . . . . . . . . . . . 45

4.6 Esempio di package.json . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.7 Processo di boundling di webpack . . . . . . . . . . . . . . . . . . . . . . . . 51

4.8 Esempio di file di configurazione per webpack . . . . . . . . . . . . . . . . . . 52

4.9 Comando da eseguire per impacchettare i moduli di un progetto . . . . . . . . 52

5.1 Pipeline di CI/CD del progetto ISIN Planner . . . . . . . . . . . . . . . . . . . 59

5.2 Modifiche apportate al metodo configure . . . . . . . . . . . . . . . . . . . . . 60

5.3 Redirezione della pagina home alla pagina dei progetti se l’utente è ammini-

stratore, altrimenti su quella del dipendente (risorsa) . . . . . . . . . . . . . . 61

5.4 Esempio di utilizzo del tag authorize . . . . . . . . . . . . . . . . . . . . . . . 61

5.5 Pagina di un progetto con il pulsante che porta alla dashboard delle statistiche 63

5.6 Dashboard delle statistiche di progetto . . . . . . . . . . . . . . . . . . . . . . 64

5.7 Grafico che mostra i trend del budget . . . . . . . . . . . . . . . . . . . . . . 66

5.8 Zoom rispetto all’anno 2019 . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.9 Zoom rispetto all’anno 2019 . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.10 Relazione tra tipo progetto e categoria . . . . . . . . . . . . . . . . . . . . . . 69

ISIN Planner

viii ELENCO DELLE FIGURE

5.11 Dashboard annuale, notare i filtri di default . . . . . . . . . . . . . . . . . . . 72

5.12 Filtri della Dashboard annuale . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.13 Componente che mostra le entrate e le uscite dell’istituto . . . . . . . . . . . . 74

5.14 Grafico a torta della distribuzione delle ore . . . . . . . . . . . . . . . . . . . 75

5.15 Ridimensionamento del grafico a torta . . . . . . . . . . . . . . . . . . . . . . 76

5.16 Tabella di utilizzo del budget dei progetti . . . . . . . . . . . . . . . . . . . . . 77

5.17 Tabella surplus rate dei progetti . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.18 Tabella delle risorse (mese corrente) . . . . . . . . . . . . . . . . . . . . . . . 80

5.19 Tabella delle risorse (anno corrente) . . . . . . . . . . . . . . . . . . . . . . . 80

5.20 Refactoring effettuato sulle progress bar dei dipendenti . . . . . . . . . . . . . 81

5.21 Refactoring effettuato sulle liste dei planning dei dipendenti . . . . . . . . . . 82

5.22 Menu laterale che è stato rimosso, è visibile anche la barra di navigazione

superiore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.23 Nuova barra di navigazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.24 Code coverage della versione iniziale, la media corrisponde al 15.3% . . . . . 86

5.25 Code coverage del back-end della versione finale, la media corrisponde al

63.6% . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.26 Code coverage del front-end della versione finale, la media corrisponde al

96.6% . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

B.1 Struttura di un ambiente Docker . . . . . . . . . . . . . . . . . . . . . . . . . 97

B.2 Esempio di Dockerfile (fonte: [3]) . . . . . . . . . . . . . . . . . . . . . . . . . 98

B.3 Esempio di build di un’applicazione . . . . . . . . . . . . . . . . . . . . . . . 99

B.4 Esempio di esecuzione di un’applicazione accessibile via http://localhost:4000 99

B.5 Esempio di condivisione di un immagine su Docker Hub . . . . . . . . . . . . 100

C.1 Architettura di un sistema Kubernetes . . . . . . . . . . . . . . . . . . . . . . 102

C.2 Architettura di un sistema Kubernetes . . . . . . . . . . . . . . . . . . . . . . 103

C.3 Contenuto di un file di configurazione per K8s (fonte: [4]) . . . . . . . . . . . . 104

C.4 Esempio di un file .yaml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

C.5 Esempio di creazione di un deployment tramite file .yaml . . . . . . . . . . . 106

D.1 Interfaccia basata su Vue.js rappresentata in una struttura ad albero . . . . . 108

D.2 Creazione dell’istanza Vue radice . . . . . . . . . . . . . . . . . . . . . . . . 108

D.3 Esempio di inserimento dell’istanza radice in una qualsiasi pagina della piat-

taforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

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


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


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


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


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


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


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


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


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


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


“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


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


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


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


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


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


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


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


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


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:

Uscite = stipendi − didattica − vacanze + infortunio + malattia + congedi

Le entrate invece:

Entrate = stipendi dei progetti di ricerca

Il componente Vue realizzato per questa funzionalità si chiama PresentationCard, ed è stato

implementato semplicemente attraverso le v-card della libreria Vuetify.

Come per gli altri componenti, viene effettuata una richiesta http al back-end il quale effettua

i calcoli visti sopra e li ritorna sottoforma di json.

ISIN Planner

75

5.2.5.3 Grafico a torta della distribuzione delle ore

Figura 5.14: Grafico a torta della distribuzione delle ore

Questo grafico mostra la percentuale di ore per le seguenti categorie: Progetti di ricerca,

Preparazione progetti, Amministrazione e Didattica.

Per effettuare il calcolo delle percentuali, viene considerato il filtro degli anni e dei team e

viene sfruttata l’implementazione delle categorie trattata nel sottosezione 5.2.3. La quantità

di ore dei Progetti di Ricerca viene calcolata considerando le ore di tutti i planning dei progetti

che rientrano nella categoria omonima, lo stesso avviene per la categoria Amministrazione.

Per quanto riguarda le spicchio legato alle ore di Preparazione progetti, oltre alle ore dei

progetti che rientrano in questa categoria, su volontà dell’istituto, in esso vengono incluse

anche le ore di matching funds.

Infine, per le ore di didattica, siccome esse sono contenute nei duty-sheet e non sono quindi

classificabili attraverso una categoria, è necessario prima ricavare tutti i dutysheet e succes-

sivamente sommarne tutte le ore di didattica.

Questo componente è stato realizzato in una maniera molto simile a quello della sotto-

sottosezione 5.2.2.2. Si tratta di un wrapper di un’istanza di highcharts e attraverso le props

è possibile modificarne l’aspetto.

ISIN Planner

76 Risultati

Il componente in questione si chiama Pie ed espone le seguenti props:

• title

• source: percorso della fonte dei dati

• currentDate

• plotBackgroundColor: sfondo del grafico

• plotBorderWidth: bordo del grafico

• plotShadow: ombra del grafico

• allowPointSelect: attiva/disattiva la selezione degli spicchi

• dataLabelsEnabled: attiva/disattiva la legenda degli spicchi presente sotto al grafico,

attraverso cui è possibile ridimensionare la torta

L’istituto ha richiesto di poter ridimensionare le percentuali visibili sul grafico attivando e

disattivando gli spicchi. Questa funzionalità è implementata direttamente da highcharts ed

è possibile attivarla e disattivarla attraverso la prop dataLabelsEnable.

Selezionando uno degli spicchi dalla legenda presente sotto al grafico, le percentuali ven-

gono automaticamente ridimensionate rispetto al nuovo totale, come mostrato in figura

Figura 5.15.

Figura 5.15: Ridimensionamento del grafico a torta

ISIN Planner

77

5.2.6 Tabella di utilizzo del budget dei progetti

Figura 5.16: Tabella di utilizzo del budget dei progetti

Una delle funzionalità mancanti nella piattaforma attuale è una tabella che fornisca un

accesso facilitato ai dati riguardanti le spese dei progetti.

In particolare l’istituto ISIN ha richiesto l’implementazione di una tabella che permetta di

risalire in maniera immediata al budget totale dei progetti e alle spese annuali che derivano

dalle pianificazioni.

Oltre a questo l’istituto ha espresso il desiderio di poter avere la possibilità di effettuare

dei top-down macro plannings dei progetti.

Questa funzionalità consiste nel poter specificare delle stime riguardo alle spese annuali del

progetto ed è stata esplicitamente richiesta dal committente per poter monitorare con più

semplicità le pianificazioni dei progetti che vengono effettuate dai team di sviluppo, poiché

non sempre è facile tenere conto dell’occupazione dei dipendenti, delle loro pianificazioni,

ecc.

A inizio progetto il direttore deve fornire all’amministrazione le stime annuali riguardanti la

ripartizione del budget, si vuole fare in modo che egli possa tenere conto delle stime che

definisce, perché a fine anno, esse vengono confrontate con ciò che è stato effettivamente

speso e sulla base di questa differenza, viene effettuato un ridimensionamento del budget.

A livello di implementazione, il componente realizzato è stato soprannominato ProjectTable-

View e fa da wrapper al componente Vuetify v-data-table. Le v-data-table sono componenti

che facilitano la creazione di tabelle dati e forniscono meccanismi di ricerca e ordinamento.

Le props esposte sono le seguenti:

• title

ISIN Planner

78 Risultati

• dataSource: percorso della fonte dei dati

• headerSource: percorso della fonte dei dati relativi all’header

• estimatesSource: percorso della fonte dei dati relativi alle stime

• thresholdActive: attivazione/disattivazione delle soglie sulla colonna "total"

• thresholds: array contenente le soglie

• thresholdColors: array contenente i colori da mostrare in base alle soglie

ISIN Planner

79

5.2.7 Tabella surplus rate dei progetti

Figura 5.17: Tabella surplus rate dei progetti

Come già visto nella sottosottosezione 5.2.2.1, il surplus rate è un valore che permette di

monitorare l’andamento dei costi di un progetto al fine di capire se le pianificazioni sono

state effettuate correttamente.

L’istituto ha richiesto l’implementazione di una tabella che mostri una lista di tutti i progetti

con il relativo surplus rate (calcolato rispetto all’ultimo periodo pianificato).

I surplus rate inoltre devono essere evidenziati con un colore che varia in base a delle soglie.

Queste soglie sono state fornite direttamente dal direttore dell’istituto e sono mappate ai

seguenti colori:

−2 ≥ surplus ≥ 2 rosso

−2 ≥ surplus ≥ −1 e 1 ≤ surplus ≤ 2e giallo

−1 ≤ surplus ≤ 1 verde

A livello di implementazione è stato riutilizzato lo stesso componente creato per la tabella

di utilizzo del budget dei progetti (vedi sottosezione 5.2.6). La differenza sostanziale risiede

nei dati passati attraverso le props: le props dataSource e headerSource sono state modi-

ficate per richiedere i dati dall’endpoint del back-end che si occupa di effettuare i calcoli dei

surplus. Per attivare la funzionalità delle soglie è stata messa a true la prop thresholdActive,

mente per indicare il valore delle soglie e i relativi colori, è stato sufficiente specificarli in due

array passati rispettivamente alla prop thresholds e thresholdColors.

ISIN Planner

80 Risultati

5.2.8 Tabella Risorse

Figura 5.18: Tabella delle risorse (mese corrente)

Figura 5.19: Tabella delle risorse (anno corrente)

L’ultimo strumento di analisi implementato per la Main Dashboard è la tabella delle risorse.

Il direttore dell’istituto ISIN ha richiesto lo sviluppo di due tabelle contenenti la lista di tutti

i dipendenti dell’istituto da cui poter rilevare i seguenti dati: il tasso d’impiego rispetto alla

percentuale d’impiego, la percentuale d’impiego, le ore di ricerca, le ore di preparazione

progetti, le ore di didattica e le ore di matching funds.

La prima tabella mostra i dati relativi al periodo di impiego corrente, mentre la seconda ta-

bella mostra i dati relativi all’anno corrente, in questo caso il tasso e la percentuale d’impiego

vengono calcolate effettuato una media sull’arco di tutto l’anno.

ISIN Planner

81

Anche in questo caso il componente utilizzato è lo stesso visto nella sottosezione 5.2.6, la

differenza risiede nei valori passati alle props del componente, in questo caso sono stati

modificate solamente le props che indicano al componente da dove deve reperire i dati: le

props dataSource e headerSource.

Per selezionare quale dei due grafici visualizzare è sufficiente scegliere una delle due

schede presenti nella parte in alto a sinistra del componente (Figura 5.18).

5.3 Reimplementazione dei componenti

Come visto nella sezione 2.2, il refactoring di questa piattaforma avverrà in maniera graduale

e l’obiettivo finale è quello di ottenere una netta separazione tra front-end e back-end.

Per quanto riguarda questo progetto di diploma, si è deciso di iniziare questo processo

estraendo le funzionalità legate ai dipendenti dell’istituto con l’obiettivo di reimplementar-

le e ottenere una pagina come quella vista in Figura 3.6 composta completamente da

componenti indipendenti dal back-end.

5.3.1 Progress bar

Figura 5.20: Refactoring effettuato sulle progress bar dei dipendenti

Il primo elemento che si è deciso di reimplementare è la barra di progresso vista preceden-

temente in figura Figura 3.5 e discussa nella sottosottosezione 3.3.4.2.

Il nuovo componente è stato realizzato attraverso la libreria bootstrap-vue la quale è stata

pensata per wrappare e riprodurre fedelmente le funzionalità fornite da Bootstrap 4.

Poiché questa barra di progresso nella versione iniziale della piattaforma era interattiva,

cliccando sui vari settori infatti era possibile aprire le modali di modifica dei planning e dei

duty-sheet, è stato necessario implementare gli stessi eventi e ricreare le stesse modali

attraverso Vue.

Le modali a livello di design sono state riprodotte in maniera fedele quelle in Figura 3.4 e Fi-

gura 3.3, inoltre per fare in modo che i click sulla barra di progresso fossere in grado di aprire

le rispettive modali, è stato implementato il meccanismo di eventi trattato nell’Appendice D.

ISIN Planner

82 Risultati

Grazie al modularità di Vue.js questa progress bar è stata inserita anche nella pagina che

mostra la lista delle risorse (Figura 3.7) senza dover essere adattata in alcun modo perchè

completamente indipendente da ciò da cui è circondata.

5.3.2 Lista dei Planning

Figura 5.21: Refactoring effettuato sulle liste dei planning dei dipendenti

Sempre nella pagina dei dipendenti, appena sotto la barra di progresso di cui è stata spie-

gata la reimplementazione nella sezione precedente, è presente una lista dei planning che

facilita la lettura dei dati di un determinato periodo. Per rendere più leggibili i dati, essa è

stata ricreata e rivista a livello grafico.

Gli eventi che precedentemente venivano scatenati premendo sulla quantità delle ore per

aprire le modali di modifica dei planning e i dutysheet, sono stati riprodotti e legati alle modali

reimplementate, con lo stesso meccanismo spiegato nella sezione precedente.

5.3.3 Visualizzazione dei Matching Funds

Guardando con maggiore dettaglio la Figura 5.21, è possibile notare che la nuova lista di

planning oltre che le ore dei di lavoro sui progetti, mostra anche le ore di matching funds

previste (sia in ore che in percentuale).

5.3.4 Menu laterale

In accordo con il relatore, è stato deciso di eliminare il menu laterale presente nella ver-

sione iniziale della piattaforma per fare più spazio al contenuto delle pagine. Alcuni degli

ISIN Planner

83

elementi presenti in questo menu erano già presenti nella barra di navigazione superiore,

quelli che invece non lo erano sono stati spostati in essa. La differenza è mostrata nelle

figure Figura 5.22 e Figura 5.23.

ISIN Planner

84 Risultati

Figura 5.22: Menu laterale che è stato rimosso, è visibile anche la barra di navigazionesuperiore

ISIN Planner

85

Figura 5.23: Nuova barra di navigazione

ISIN Planner

86 Risultati

5.4 Testing

Come visto nella sezione 4.4, il testing ricopre un ruolo fondamentale nel processo di

integrazione e rilascio continuo del software.

La versione iniziale della piattaforma è stata implementata senza un appropriato numero

di test di unità (vedi Figura 5.24), questo fattore aumenta la possibilità che in essa siano

presenti dei bug e soprattutto fa crescere la probabilità di introdurne di nuovi.

Figura 5.24: Code coverage della versione iniziale, la media corrisponde al 15.3%

A questo proposito è stato deciso di implementare i test durante l’arco di tutto il progetto man

mano che venivano coinvolte le classi non testate. Il risultato ottenuto, visibile in Figura 5.25,

è una percentuale di copertura del codice nettamente superiore a quella iniziale.

Figura 5.25: Code coverage del back-end della versione finale, la media corrisponde al63.6%

ISIN Planner

87

Per quanto riguarda la parte di front-end, tutte le funzionalità dei componenti sono state

testate, ottenendo un code coverage medio pari al 96.10%, vedi Figura 5.26.

Figura 5.26: Code coverage del front-end della versione finale, la media corrisponde al96.6%

ISIN Planner

88 Risultati

ISIN Planner

89

Capitolo 6

Conclusione

Questo progetto di diploma ha avuto quale obiettivo quello di estendere la piattaforma di

gestione utilizzata per organizzare e mantenere tutti i dati legati ai dipendenti e ai progetti

dell’istituto ISIN.

La piattaforma ISIN Planner è stata progettata per fare fronte a tutte le difficoltà che si

presentano in fase di pianificazione e organizzazione del lavoro, tuttavia nel corso del tempo

il committente si è reso conto della presenza di alcune nuove esigenze.

La problematica più grande è stata identificata nella difficoltà di raccogliere dati importanti

per effettuare analisi che possano migliorare la creazione dei piani di lavoro attraverso i quali

ottimizzare i ricavi ottenuti dai singoli progetti.

La causa di questo problema risiede nell’assenza di strumenti idonei per l’estrapolazione di

statistiche legate all’utilizzo del budget dei progetti e l’impossibilità di effettuare un confronto

diretto tra i dati.

Per questo motivo è stata espressa l’esigenza di estendere la piattaforma di pianificazione

facendo in modo che essa ricopra anche il ruolo di strumento di analisi.

Le tecnologie e le scelte tecniche che sono state fatte hanno permesso di ottenere una

maggiore flessibilità e modularità, facilitando così l’aggiunta delle funzionalità richieste dal-

l’istituto. Attraverso un approccio orientato ai componenti l’interfaccia è diventata più modu-

lare e tutti gli elementi presenti in essa funzionano in maniera indipendente. Dal punto di

vista tecnico questa metodologia di sviluppo ha semplificato il lavoro dal punto di vista del

testing, diminuendo drasticamente la probabilità di introdurre dei bug.

Un altro fattore che ha giocato un ruolo importantissimo è l’implementazione del processo

di CI/CD.

La prima versione della piattaforma presentava già l’automatizzazione degli step a livel-

lo di Continuous Integration, tuttavia con la separazione tra back-end e front-end è stato

necessario estenderla e vista la volontà del committente di partecipare attivamente all’im-

ISIN Planner

90 Conclusione

plementazione della nuova versione, è stata introdotta la Continuous Delivery.

Questi aspetti tecnici hanno permesso di sviluppare e soddisfare tutte le esigenze richieste

dal committente e di ottenere una nuova versione della piattaforma ISIN Planner orientata

anche all’analisi.

Grazie al cambiamento di architettura adottato, la piattaforma è stata predisposta per un’in-

tegrazione facilitata di nuove funzionalità.

L’ottica futura in cui si vuole muovere il committente è quella di estendere ulteriormente la

piattaforma al fine di ottenere un tool che possa gestire anche aspetti legati alla previsione

e la nuova versione di ISIN Planner è sicuramente un ottimo punto di partenza.

ISIN Planner

91

Bibliografia

[1] pyxis tech.com. The scrum framework. https://pyxis-tech.com/en/

agile-approaches/, 2019.

[2] redhat.com. Continuous integration: A “typical” process. https://developers.

redhat.com/blog/2017/09/06/continuous-integration-a-typical-process/,

2019.

[3] docker.com. Containers. https://docs.docker.com/get-started/part2/, 2019.

[4] thockin. kubeconfig files. https://github.com/zecke/Kubernetes/blob/master/

docs/user-guide/kubeconfig-file.md, 2019.

[5] ISIN-SUPSI. History and mission. http://www.supsi.ch/isin_en/istituto/

storia.html.

[6] SUPSI. Enti di finanziamento. http://www.supsi.ch/dti/ricerca/

enti-di-finanziamento.html.

[7] thymeleaf.org. Thymeleaf. https://www.thymeleaf.org/, 2019.

[8] Pivotal Software. Spring framework. https://spring.io/projects/

spring-framework.

[9] Michael Kifer Philip M. Lewis, Arthur Bernstein. In Database and Transaction

Processing, july 2001.

[10] Medium Corporation. Split stack development: A model for mo-

dern applications. https://medium.com/@MentallyFriendly/

split-stack-development-a-model-for-modern-applications-d7b9abb47bd5.

[11] Martin Fowler (with Kent Beck). In Refactoring - Improving the Design of Existing Code,

volume 2, Novembre 2018.

[12] Prof. Sandro Pedrazzini [email protected]. Introduzione alla progettazione

agile nello sviluppo software. Scuola Universitaria Professionale della Svizzera Italiana,

Manno (CH), February 2019.

ISIN Planner

https://pyxis-tech.com/en/agile-approaches/

https://pyxis-tech.com/en/agile-approaches/

https://developers.redhat.com/blog/2017/09/06/continuous-integration-a-typical-process/

https://developers.redhat.com/blog/2017/09/06/continuous-integration-a-typical-process/

https://docs.docker.com/get-started/part2/

https://github.com/zecke/Kubernetes/blob/master/docs/user-guide/kubeconfig-file.md

https://github.com/zecke/Kubernetes/blob/master/docs/user-guide/kubeconfig-file.md

http://www.supsi.ch/isin_en/istituto/storia.html

http://www.supsi.ch/isin_en/istituto/storia.html

http://www.supsi.ch/dti/ricerca/enti-di-finanziamento.html

http://www.supsi.ch/dti/ricerca/enti-di-finanziamento.html

https://www.thymeleaf.org/

https://spring.io/projects/spring-framework

https://spring.io/projects/spring-framework

https://medium.com/@MentallyFriendly/split-stack-development-a-model-for-modern-applications-d7b9abb47bd5

https://medium.com/@MentallyFriendly/split-stack-development-a-model-for-modern-applications-d7b9abb47bd5

92 BIBLIOGRAFIA

[13] Hirotaka Takeuchi e Ikujiro Nonaka. The New New Product Development Game,

Gennaio 1986.

[14] Scrum.org. What is scrum? https://www.scrum.org/resources/what-is-scrum,

2019.

[15] GitLab. Introduction to ci/cd. https://docs.gitlab.com/ee/ci/introduction/,

2019.

[16] Scott Chacon. Git –fast-version-control. https://git-scm.com/, 2019.

[17] Martin Fowler. Continuous integration. https://martinfowler.com/articles/

continuousIntegration.html, settembre 2000.

[18] Martin Fowler. Continuousdelivery. https://martinfowler.com/bliki/

ContinuousDelivery.html, agosto 2014.

[19] docker.com. Get started with docker. https://www.docker.com/get-started, 2019.

[20] kubernetes.io. What is kubernetes. https://kubernetes.io/docs/concepts/

overview/what-is-kubernetes/, 2019.

[21] npmjs.com. About npm. https://docs.npmjs.com/about-npm/, 2019.

[22] nodejs.dev. Introduction to node.js. https://nodejs.dev/, 2019.

[23] vuejs.org. Comparison with other frameworks. https://vuejs.org/v2/guide/,

2019.

[24] Google. Introduction. https://material.io/design/introduction/#, 2019.

[25] highcharts.com. The options object. https://www.highcharts.com/docs/

getting-started/how-to-set-options, 2019.

[26] Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Mar-

tin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian

Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas.

Manifesto per lo sviluppo agile di software, 2001.

[27] Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham

Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern

Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Tho-

mas. I principi sottostanti al manifesto agile. https://agilemanifesto.org/iso/it/

principles.html.

[28] docker.com. What is a container. https://www.docker.com/resources/

what-container, 2019.

ISIN Planner

https://www.scrum.org/resources/what-is-scrum

https://docs.gitlab.com/ee/ci/introduction/

https://git-scm.com/

https://martinfowler.com/articles/continuousIntegration.html

https://martinfowler.com/articles/continuousIntegration.html

https://martinfowler.com/bliki/ContinuousDelivery.html

https://martinfowler.com/bliki/ContinuousDelivery.html

https://www.docker.com/get-started

https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/

https://docs.npmjs.com/about-npm/

https://nodejs.dev/

https://vuejs.org/v2/guide/

https://material.io/design/introduction/#

https://www.highcharts.com/docs/getting-started/how-to-set-options

https://www.highcharts.com/docs/getting-started/how-to-set-options

https://agilemanifesto.org/iso/it/principles.html

https://agilemanifesto.org/iso/it/principles.html

https://www.docker.com/resources/what-container

https://www.docker.com/resources/what-container

93

Appendice A

Manifesto Agile

ISIN Planner

94 Manifesto Agile

Nel 2001 un gruppo di sviluppatori si è riunito per discutere e creare una metodologia alter-

nativa di sviluppo del software. Questi sviluppatori hanno capito l’importanza di creare un

modello in cui ogni iterazione nel ciclo di sviluppo può trarre informazioni utili dalle iterazioni

precedenti. Il risultato di questa discussione ha generato un approccio più flessibile, effi-

ciente e orientato al lavoro di gruppo:

"Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare

lo stesso. Grazie a questa attività siamo arrivati a considerare importanti:

Gli individui e le interazioni più che i processi e gli strumenti

Il software funzionante più che la documentazione esaustiva

La collaborazione col cliente più che la negoziazione dei contratti

Rispondere al cambiamento più che seguire un piano

Ovvero, fermo restando il valore delle voci a destra, consideriamo più importanti le voci

a sinistra."([26])

Per poter applicare le affermazioni citate nel manifesto agile è necessario rispettare i 12

principi del Software Agile ([27]):

• La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da

subitoe in maniera continua.

• Accogliamo i cambiamenti nei requisiti, anche a stadi avanzati dello sviluppo. I pro-

cessi agili sfruttano il cambiamento a favore del vantaggio competitivo del cliente.

• Consegniamo frequentemente software funzionante, con cadenza variabile da un paio

di settimane a un paio di mesi, preferendo i periodi brevi.

• Committenti e sviluppatori devono lavorare insieme quotidianamente per tutta la du-

rata del progetto.

• Fondiamo i progetti su individui motivati. Diamo loro l’ambiente e il supporto di cui

hanno bisogno e confidiamo nella loro capacità di portare il lavoro a termine.

• Una conversazione faccia a faccia è il modo più efficiente e più efficace per comuni-

care con il team ed all’interno del team.

• Il software funzionante è il principale metro di misura di progresso.

• I processi agili promuovono uno sviluppo sostenibile. Gli sponsor, gli sviluppatori e gli

utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.

ISIN Planner

95

• La continua attenzione all’eccellenza tecnica e alla buona progettazione esaltano

l’agilità.

• La semplicità - l’arte di massimizzare la quantità di lavoro non svolto - è essenziale.

• Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-

organizzano.

• A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e

adatta il proprio comportamento di conseguenza.

ISIN Planner

96 Manifesto Agile

ISIN Planner

97

Appendice B

Docker

B.1 Containers

Figura B.1: Struttura di un ambiente Docker

Gli ambienti sandbox in Docker vengono chiamati container, ma che cosa sono in realtà?

Un Docker container garantisce l’isolamento dell’applicazione che è stata impacchettata

in esso. Questo significa che quest’ultima può eseguire con lo stesso comportamento,

indipendentemente dall’infrastruttura hardware e dal sistema operativo su cui essa si trova.

I Docker container dunque sono un’astrazione a livello di applicazione, infatti più container

possono eseguire sullo stesso sistema operativo poiché ognuno di essi esegue in un pro-

cesso isolato.

I container hanno tre caratteristiche ([28]) importanti grazie alle quali si sono diffusi in

molteplici contesti:

• Standard: Docker ha creato uno standard industriale per i container, facendo in modo

che questi diventino portabili ovunque.

ISIN Planner

98 Docker

• Leggeri: I container eseguono tutti sullo stesso sistema operativo, aumentando di

molto l’efficienza dei server come anche i costi che essi comportano.

• Sicuri: Le applicazioni che eseguono in un container sono più sicure e Docker forni-

sce le capacità di isolamente più forti dell’industria.

B.2 Dockerfile

Il Dockerfile definisce che cosa vogliamo mettere all’interno dell’ambiente di esecuzione

di un container. Per poter comunicare con le interfacce di rete e il disco, essendo che il

container è completamente isolato, è necessario effettuare una mappatura con l’ambiente

esterno e specificare quali sono esattamente i file che vogliamo copiare nel container.

Figura B.2: Esempio di Dockerfile (fonte: [3])

B.3 Immagini Docker

Una volta definito il Dockerfile è possibile buildare il file stesso per ottenere un’immagine

Docker. Le immagini Docker possono essere comparate a dei pacchetti che contengono la

nostre applicazioni. Docker permette di avere più versioni di una stessa immagine.

La versione più recente dell’applicazione viene automaticamente salvata con il tag "latest".

ISIN Planner

99

Figura B.3: Esempio di build di un’applicazione

A livello pratico le immagini Docker possono essere utili in fase di implementazione di un

progetto in cui vogliamo avere più versioni dello stesso applicativo per scopi di backup o per

poter comparare le versioni fra loro.

Una volta buildata, l’immagine può essere eseguita attraverso il seguente comando, il qua-

le mappa la porta fisica (4000) a quella virtuale (80, precedentemente configuarata nel

Dockerfile) del container:

Figura B.4: Esempio di esecuzione di un’applicazione accessibile via http://localhost:4000

B.4 Condivisione delle immagini

Docker mette a disposizione una piattaforma, più precisamente, un registry di condivisio-

ne delle immagini chiamato Docker Hub. Esso è la dimostrazione dell’ampia portabilità di

Docker.

Docker Hub non è l’unico registry presente in rete, esistono numerosi registry a pagamento

e gratuiti come ad esempio: JFrog Bintray, ProGet, Quay.io, ecc. Un registry di fatto è un

server contenente una raccolta di repository1, i quali a loro volta contengono una raccolta di

Docker images. Innanzitutto per poter pubblicare immagini su un registry è necessario regi-

strarsi e ottenere un profilo utente. Il profilo utente permette di creare molteplici repository

sui quali pubblicare e condividere le proprie immagini. Questi sono i comandi da eseguire

per condividere un’immagine:

1Repository: si tratta di un ambiente per la gestione dei dati.

ISIN Planner

100 Docker

Figura B.5: Esempio di condivisione di un immagine su Docker Hub

ISIN Planner

101

Appendice C

Kubernetes

ISIN Planner

102 Kubernetes

Kubernetes spesso viene anche definito un orchestratore, questo perché fornisce tutta una

serie di funzionalità atte a gestire il ciclo di vita di applicazioni containerizzate:

• Load-balancing: Se il traffico di rete verso un container è troppo alto, K8s è in grado

di distribuirlo per aumentare la stabilità.

• Orchestrazione dell’archiviazione: K8s permette di montare automaticamente si-

stemi di archiviazione su scelta dell’utente.

• Distribuzioni e rollback automatici: È possibile configurare K8s per fare in modo di

automatizzare la creazione e la rimozione dei container

• Gestione automatizzata delle risorse: È possibile specificare la quantità di CPU e

memoria RAM necessaria per ogni container. In questo modo K8s può adattarsi e

gestire meglio le decisioni in merito all’allocazione delle risorse.

• Self-healing: K8s è in grado di riavviare i container che non funzionano a dovere ed

è capace di pubblicarli solamente quando sono pronti.

• Sicurezza: K8s permette di salvare e gestire dati sensibili come password o token di

autenticazione.

Figura C.1: Architettura di un sistema Kubernetes

ISIN Planner

103

Figura C.2: Architettura di un sistema Kubernetes

C.1 Cluster

Un cluster di K8s è composto da una serie di nodi: da un nodo/macchina master e da una

serie di nodi/macchine secondarie.

Il nodo master ha la responsabilità di mantenere lo stato desiderato del cluster stesso. Tutti

i comandi che vengono eseguiti attraverso l’interfaccia kubectl sono indirizzati direttamente

al nodo master.

C.2 Pod

I pod sono l’unità lavoro più piccola di un cluster. Un pod incapsula uno o più container

(per es. Docker) in cui vengono impacchettate le applicazioni e rappresenta un processo in

esecuzione su un cluster.

I container all’interno di un pod condividono un indirizzo ip, un gruppo di porte, namespa-

ce condivisi e porzioni di file-system. I container possono comunicare tra loro utilizzando

comunicazioni inter-processo (per es. POSIX).

K8s è in grado di mantenere più repliche della stessa applicazione e di conseguenza più

pod contemporaneamente. I Pod dunque sono le unità attraverso cui K8s gestisce il ciclo di

vita delle applicazioni.

ISIN Planner

104 Kubernetes

C.3 Nodo

I nodi solitamente sono macchine virtuali o macchine fisiche, a dipendenza del cluster.

Ogni nodo contiene i servizi necessari per eseguire i pod (che a loro volta contengono

l’applicazione) ed è controllato esclusivamente dal master.

A differenza dei pod, un nodo non viene direttamente creato da K8s: esso è creato ester-

namente da fornitori di servizi cloud come Google oppure è direttamente parte del server

fisico di chi vuole utilizzare K8s.

C.4 kubectl

Kubectl è un interfaccia da linea di comando usata per eseguire comandi indirizzati ai cluster

K8s.

Per poter capire a quale cluster deve riferirsi, kubectl ha bisogno di un file soprannominato

config nella cartella $HOME/.kube.

Questo file deve contenere tutte le informazioni necessarie per effettuare la connessione ad

un cluster:

Figura C.3: Contenuto di un file di configurazione per K8s (fonte: [4])

Come si può vedere in Figura C.3, il file è composto da una serie di elementi chiave/valore:

• cluster: usato per descrivere un cluster e l’endpoint attraverso al quale raggiungerlo.

ISIN Planner

105

• user: usato per definire delle credenziali di accesso al cluster.

• context: è definito dalla tupla: cluster, utente e namespace. Attraverso il contesto

è possibile mandare richieste al cluster indicato utilizzando l’utente e il namespace

specificati.

• current-context: indica quale dei contesti elencati nel file è quello di default.

C.5 Oggetti Kubernetes

K8s contiene tutta una serie di astrazioni utili per descrivere lo stato del sistema che si

vuole creare per gestire le proprie applicazioni containerizzate. Questo sistema ha la

responsabilità di manterere attivo il ciclo di vita dei container docker (vedi Figura C.2.

Le astrazioni appena menzionate sono anche chiamate oggetti e servono principalmente

per distinguere i vari attori presenti in un sistema Kubernetes e per facilitarne la configura-

zione. Tra i vari oggetti che Kubernetes mette a disposizione, questo progetto ne sfrutta in

particolare tre:

• Deployment: è una controller di kubernetes che si occupa di gestire i pod e le repliche

dei container. Tutte le volte che viene rilasciata una nuova versione dell’applicazione,

il Deployment reagisce aggiornando o sostituendo i pod esistenti con quelli nuovi.

• Services: Ogni pod solitamente riceve un proprio indirizzo IP e le proprie risorse, il

problema però è che questi pod vengono continuamente aggiunti, modificati o cancel-

lati dal Controller. Questo può causare problemi quando l’applicazione che rilasciamo

è composta da due parti, ad esempio la parte funzionale e il database. Entrambe

le parti vengono assegnate ad un pod e il fatto che questi possano essere modificati

rischia di portare a degli sfasamenti.

Per questo motivo sono stati creati i Services. Essi definiscono un astrazione che de-

scrive in quale modo è possibile accedere ad un determinato gruppo di pod. L’insieme

dei pod indirizzati da un servizio generalmente viene identificato da un selettore. Gra-

zie a questo selettore non è necessario preoccuparsi di perdere il collegamento fra

due pod che devono comunicare poichè questi saranno sempre accessbili attraverso

il selettore.

• PersistentVolume: Rappresenta una parte dell’unità di archiviazione di un cluster.

Gli oggetti K8s vengono descritti in un file con estensione .yaml, il quale indica tutte le

caratteristiche del sistema che si vuole mantenere in vita:

ISIN Planner

106 Kubernetes

Figura C.4: Esempio di un file .yaml

Entrando un po’ più nel dettaglio, all’interno del campo spec è possibile indicare tutte le

specifiche e designazioni legate ai pod.

Il campo selector indica attraverso quale label il Deployment deve trovare i Pod da ge-

stire, questo torna utile quando si vuole verificare lo stato di un Pod specifico attraverso

l’interfaccia kubectl.

Il campo replicas indica al controller Deployment la quantità di repliche dell’applicazione

appName che deve mantenere attive, in questo caso sono 2.

Il campo template invece definisce il nome dei singoli pod attraverso "app: appName" e

descrive le informazioni riguardo al container che esegue all’interno di ogni pod: il nome del

container, (appName), il nome dell’immagine la versione (appName:1.7.9) e le porte che

virtuali che esso espone (vedi Figura B.2).

Per creare un deployment è sufficiente eseguire il seguente comando passando come

parametro il file .yaml :

Figura C.5: Esempio di creazione di un deployment tramite file .yaml

ISIN Planner

107

Appendice D

Vue

ISIN Planner

108 Vue

D.1 L’istanza radice di Vue

Tutte le applicazioni Vue hanno una radice, istanza Vue, contenente i componenti definiti

nel corso dello sviluppo di un progetto. Di fatto tutti i componenti sviluppati con questo

framework sono istanze Vue figli dell’istanza radice.

Per capire più facilmente questo concetto, nella figura sottostante (Figura D.1) viene raffigu-

rata la struttura ad albero di un’interfaccia.

Figura D.1: Interfaccia basata su Vue.js rappresentata in una struttura ad albero

A livello di codice la creazione dell’istanza radice solitamente avviene in un file javascript

chiamato main.js nella seguente maniera:

Figura D.2: Creazione dell’istanza Vue radice

Come si può vedere in Figura D.2, all’elemento che rappresenta l’istanza radice viene as-

segnato il nome #app. Attraverso quest’ultimo l’istanza radice è referenziabile all’interno di

una qualsiasi pagina web in cui viene incluso lo script main.js.

ISIN Planner

109

Per sfruttare le potenzialità di Vue nella piattaforma ISIN Planner è sufficiente inserire

l’istanza radice come un comune elemento HTML. (vedi Figura D.3)

Figura D.3: Esempio di inserimento dell’istanza radice in una qualsiasi pagina dellapiattaforma

All’interno di questo elemento allo stesso modo è possibile inserire i componenti inclusi nel

file main.js.

D.2 Single File Components

Vue.js introduce il principio dei Single File Components in cui ogni componente è definito in

un file con estensione .vue composto da tre elementi:

• <template>: ammette il linguaggio di markup HTML usato nelle pagine web per

formattare e impaginare documenti ipertestuali.

• <script>: ammette il linguaggio Javascript. Questo elemento include tutte le parti

logiche di un componente usate per gestirne i cicli di vita e l’elaborazione dei dati da

visualizzare nel template.

• <style>: ammette i linguaggi usati per descrivere la presentazione di pagine web

quali CSS, SCSS, ecc. . Questo elemento dunque è usato per stilizzare il markup

HTML. Se viene aggiunta la direttiva scoped, le regole definite in questo elemento

ISIN Planner

110 Vue

vengono applicate solo al markup presente nel template del componente invece che

globalmente.

Figura D.4: Esempio di Single File Component in Vue.js

Come si può vedere in Figura D.4, l’interazione fra template, script e style è molto semplice.

In ognuno dei tre elementi l’accesso avviene in maniera diretta. Alla base di Vue.js è pre-

sente una meccanismo di declarative rendering che permette di mappare il dato presente

nello script direttamente nel template del componente per visualizzarne il valore.

Vue.js mette anche a disposizione le props, esse sono un meccanismo per passare dei dati

dall’esterno del componente. Questo è utile per esempio quando un componente padre

esegue una determinata logica sui dati e una volta pronti questi vengono passati al compo-

nente figlio il quale ne visualizza il contenuto.

Per passare i dati dal componente figlio al componente padre Vue sfrutta una funzionali-

tà differente: il metodo $emit. Il figlio ha la possibilità di emettere un evento che è possibile

intercettare nel componente padre attraverso la direttiva v-on. (vedi Figura D.5)

ISIN Planner

111

Figura D.5: Esempio di Single File Component in Vue.js

ISIN Planner

112 Vue

D.3 Direttive, Properties e ciclo di vita di un componente

Direttive:

Uno dei fattori che rende Vue particolarmente interessante dal punto di vista implementativo

è il fatto che esso mette a disposizione delle direttive per manipolare gli elementi del DOM.

Queste direttive sono token speciali inseriti nel markup che dicono alla libreria di manipolare

in una certa maniera uno specifico elemento del DOM.

Per capire con più semplicità lo scopo di queste direttive nell’immagine sotto sono mostrati

una serie di esempi:

Figura D.6: Esempio di utilizzo delle direttive Vue

La prima direttiva permette di iniettare la stringa in v-text direttamente nella pagina.

La seconda direttiva aggiunge la possibilità di renderizzare il contenuto in base a delle

condizioni che si verificano sui dati di un componente, in questo caso quando il valore dentro

ISIN Planner

113

la proprietà "value" è maggiore di 10, la string "Works!" viene renderizzata nella pagina.

La terza direttiva invece renderizza in modo dinamico i valori presenti nella lista items.

La quarta direttiva intercentta l’evento di click sull’elemento div e richiama automaticamente

la funzione increment, la quale va ad incrementare il valore della data property value Que-

ste sono solo quattro delle numerose direttive che mette a disposizione Vue.js, esse danno

l’idea di quanto diventa semplice manipolare il rendering di una pagina web attraverso istru-

zioni ad alto livello come queste.

Properties:

Tutte le istanze Vue offrono una serie di opzioni che facilitano l’implementazione della logica

dei componenti e la gestione dei dati.

Quando un’istanza Vue viene creata, tutte le proprietà presenti nell’oggetto data di un

componente (vedi Figura D.4) sono aggiunte nel sistema di reattività di Vue (trattato più

in basso in questa sezione). Quando i valori di queste proprietà cambiano, l’interfaccia

automaticamente reagisce e aggiorna tutti gli elementi che le utilizzano.

Ciò che accade dietro le quinte è sostanzialmente un re-rendering del componente in que-

stione. Per poter essere reattiva, una proprietà deve essere dichiarata direttamente nel

oggetto data. Tutte le proprietà aggiunte programmaticamente non sono reattive e non sca-

tenano alcun aggiornamento dell’interfaccia.

Insieme alle data properties, Vue espone una serie di altre opzioni/properties molto uti-

li. Esse vengono referenziate tramite il prefisso $, questo per essere differenziate dalle

proprietà definite dall’utente.

Tra queste properties c’è quella chiamata methods. In essa è possibile dichiarare le funzioni

in cui implementare la logica del componente (come gia visto in Figura D.6). Queste funzioni

permettono di accedere alle data properties e di manipolarne il contenuto. Le funzioni defi-

nite in questa proprietà sono inoltre accessibili direttamente nel template di un componente

e sono richiamabili a seguito degli eventi catturati dalla direttiva v-on.

Ciclo di vita di un componente:

Ogni istanza di Vue (quindi ogni componente) passa attraverso una serie di inizializzazioni

quando viene creata.

Questi passaggi consistono per esempio nell’impostare il sistema di reattività in base alle

data properties definite, compilare il template, montare la istanza nel DOM, aggiornare il

DOM al cambiamento dei dati, ecc.

Ad ognuno di questi eventi che caratterizzano il ciclo di vita di un componente, corrispon-

de una funzione che viene automaticamente chiamata quando l’evento accade chiamata

lifecycle hook. Le hooks sono particolarmente utili quando lo sviluppatore ha la necessi-

tà di eseguire delle istruzioni in uno specifico momento della vita di un componente come

ISIN Planner

114 Vue

ad esempio inizializzare le data properties con i valori passati attraverso le props. (vedi

Figura D.4)

Per la piattaforma ISIN Planner è stato pensato di sfruttare la mounted hook, richiamata

da un evento che accade quando i componenti sono stati renderizzati. In particolare la

piattaforma sfrutta questa funzione per richiedere i dati al back-end Spring.

Esistono numerose altre hooks, esse sono rappresentate nel diagramma in Figura D.7.

ISIN Planner

115

Figura D.7: Ciclo di vita di un istanza Vue

ISIN Planner

ISIN Planner - tesi.supsi.ch

Documents

Transcript of ISIN Planner - tesi.supsi.ch