ISIN Planner

Studente/i

Ivan Pavic

Roberto Guidi

Patrick Ceppi

ISIN - Information Systems and

Networking Institute

Ingegneria Informatica

M00009 Progetto di diploma

2019

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

Indice

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.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.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

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-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

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.

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

Capitolo 1

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.

1

Information and Communications Technology: Indica l’insieme delle tecnologie che consentono il trattamento e lo scambio delle informazioni in formato Digitale.

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:

– 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 piattaformaISIN planner, un’applicazione web in grado di semplificare la pianificazione contabile dell’istituto.

3

Commissione per la tecnologia e l’innovazione: organo della Confederazione Svizzera incaricato di promuovere l’innovazione fondata sulla scienza

Capitolo 2

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

1

In ingegneria del software è una tecnica per ristrutturare delle porzioni di codice senza però modificarne il comportamento esterno.

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.

Capitolo 3

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 poscor-sono 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.

• 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 transazioni5effettuate 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.

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 software aggiuntivi

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.

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 colistituziona-legamento è 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 utlizzainferio-re un parametro perchè la cinferio-reazione 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

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 rappresenstruttura-ta 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.

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.

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 misc7previste.

7

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.

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 insericorrettamen-te attraverso la percentuale non vengono converticorrettamen-te in ore, sfasando il risultato.

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.

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.

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)

Capitolo 4

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 principalCo-mente 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.

Il raggiungimento di tale obiettivo risulta però essere relativamente complicato, principal-mente per un motivo.

La prima versione della piattaforma è stata implementata con l’utilizzo dei template (vedi sot-tosezione 3.2.2), questo approccio era ottimo per le esigenze iniziali che quest’ultima aveva, tuttavia l’implementazione via template non ha le caratteristiche adatte per implementare con facilità le nuove necessità dell’istituto.

Per molti anni, lo sviluppo di pagine web si è basato principalmente su tecnologie server-side1e la maggior parte delle pagine web venivano scritte con linguaggi di back-end2. Alla parte di sviluppo front-end3era principalmente delegata l’implementazione di template (mo-delli). Questa architettura però tende ad aumentare l’accoppiamento che c’è tra back-end e front-end riducendo di molto la possibilità di applicare le modifiche ad uno dei due senza doverle applicare anche sull’altro e obbliga lo sviluppatore a restringere il numero di scel-te scel-tecnologiche per implementare l’applicativo. La domanda che ci si pone è la seguenscel-te: come mai nonostante queste limitazioni, si è continuato per molto tempo a sviluppare le pagine web con questo modello di implementazione? La prima risposta è il fatto che l’impie-go dei template è tutt’oggi molto diffuso perché permette di sviluppare applicativi web con funzionalità anche molto complesse.

Un’altra risposta, legata però al passato, risiede nei dispositivi degli utenti e nei browser web di vecchia data: le performance non erano sufficientemente alte per evitare di delegare tutta l’elaborazione al server.

Grazie allo sviluppo tecnologico, i moderni browser web hanno la capacità di effettuare compiti più complessi e questo ha automaticamente spinto il web development verso la tendenza di separare la parte di front-end da quella back-end. ([10])

Questo progetto di diploma ha sicuramente il compito di soddisfare i bisogni esposti dai quadri superiori dell’istituto, ma per poterlo fare è necessario applicare questa transizione di architettura.

4.2.1

Refactoring

Grazie all’aumento delle performance dei web browser, anche le tecnologie di front-end si sono sviluppate permettendo la nascita dei Framework Web.

Il "refactoring" è il processo attraverso il quale vogliamo condurre la piattaforma ISIN Plan-ner. Questo concetto è "una tecnica controllata per migliorare il design di un software esi-stente. La sua essenza è quella di applicare una serie di piccole trasformazioni che preser-vano il comportamento. L’effetto di tutte queste trasformazioni messa assieme è piuttosto significante. Applicandole a piccoli passi si riduce il rischio di introdurre degli errori."([11]).

L’obiettivo è quello di applicare una reimplementazione agli elementi attualmente presenti nella varie pagine, estraendoli e incapsulandoli5in componenti che possano essere riutiliz-zati per necessità future senza il bisogno di re-implementarne il funzionamento, ovviamente il tutto senza alterarne il comportamento.

Uno sviluppo orientato ai componenti permette di ottenere un disaccoppiamento più marca-to fra client e server (in quesmarca-to caso tra front-end e back-end) e una minore probabilità di riscontrare dei bug grazie alla facilità con cui i componenti possono essere testati.

5

In informatica l’incapsulamento è un meccanismo per isolare un elemento limitandone l’accesso e definendone le funzionalità con le quali poter interagire dall’esterno

4.3

Metodologia Agile

Nell’ingegneria del software la metodologia agile rappresenta un metodo alternativo nella gestione di team e progetti in ambito di sviluppo del software.

Sebbene questo sia un progetto individuale, è stato deciso di seguire questo approccio di lavoro sia a scopo didattico, sia a scopo organizzativo. I vantaggi che i progetti posso-no trarre con questo metodo di lavoro soposso-no numerosi e questa sezione ne espone una serie.

La necessità di sviluppare una nuova metodologia di lavoro è nata per molteplici motivi ([12]), motivi che le vecchie metodologie di sviluppo non erano in grado di risolvere:

• Un numero elevato di progetti interrotti dovuti a mancanza di organizzazione del lavo-ro.

• Costi di pianificazione iniziale sproporzionati: la tendenza era quella di incontrare una prima volta il committente all’inizio del progetto e una seconda volta alla fine di quest’ultimo. Questo comporta una grande pianificazione iniziale che richiede molto tempo, tempo che può essere utilizzato per realizzare il software.

• Per via del motivo visto nel punto precedente, la difficoltà nel soddisfare le esigen-ze del committente cresce perché lo sviluppatore con il tempo può farsi un’idea di implementazione differente da quella che aveva il cliente.

• Lo sfasamento tra la visione dello sviluppatore e quella del cliente causa un ritar-do in termini di consegna perché a fine progetto sono necessarie delle modifiche di correzione. Questo porta chiaramente ad un aumento dei costi.

• Difficoltà di manutenzione del software e problemi di qualità.

L’obiettivo di questa metodologia è quello di coinvolgere costantemente il cliente durante tutto il processo di sviluppo.

“L’approccio ‘a staffetta’ allo sviluppo dei prodotti ...può entrare in conflitto con gli obietti-vi di massima velocità e flessibilità. Invece, un approccio olistico o ‘rugbystico’ - in cui un

“It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.” (Charles Darwin)

Uno dei principi su cui si basa la metodologia agile è la continua analisi e revisione dei requisiti grazie alla quale il cliente collabora attivamente con gli sviluppatori. In questa ma-niera il cliente può liberamente proporre modifiche o nuovi requisiti da integrare in iterazioni successive.

Per formalizzare questi principi, i creatori di questa metodologia hanno redatto un documen-to chiamadocumen-toManifesto Agile. (vedi Appendice A)

4.3.1

Scrum

4.3.1.1 Definizione

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

Scrum è l’approccio più popolare per lo sviluppo agile di software. La sua introduzione av-viene all’inizio degli anni novanta per gestire lo sviluppo di prodotti complessi.

"Scrum non è un processo o una tecnica per costruire prodotti ma piuttosto è un framework all’interno del quale è possibile utilizzare vari processi e tecniche. Scrum rende chiara l’ef-ficacia relativa del proprio product management e delle proprie pratiche di sviluppo così da poterle migliorare". ([14])

Ma come funziona l’approccio Scrum?

Durante il primo incontro con il committente, si discute del progetto in questione e si cerca di raccogliere quante più informazioni suirequisiti richiesti per poi suddividerli in elementi separati e ben definiti. Questi elementi finiscono nelproduct backlog che non è altro che

una lista ordinata dei requisiti ricavati nell’incontro con il cliente chiamati ancheuser story. Il Product Owner è la persona incaricata di inserire le user story nel product backlog e di assegnare una priorità ad ognuna di esse.

Ad ogni user story inoltre viene assegnata una stima attraverso degli story points. Que-ste stime vengono definite dal Team di sviluppo usando una successione di Fibonacci6 arrotondata, per indicarne lo sforzo in termini di tempo di sviluppo.

Una volta definite le user story, viene effettuato un primo meeting per definire la durata delle iterazioni di sviluppo. Queste iterazioni in Scrum sono chiamatesprint e hanno una durata fissa durante tutto l’arco di sviluppo del progetto.

All’inizio e fine di ogni Sprint il team di sviluppo si riunisce per discutere delle funzionalità implementate e per decidere quali dei requisiti presenti nel product backlog sono i più idonei per essere sviluppati nel corso dello sprint successivo. A questo proposito le stime accen-nate precedentemente tornano utili. A lungo termine è sempre più facile capire lo sforzo medio di uno sprint e quindi gli sprint vengono pianificati con più precisione. Con il passare del tempo anche le stime delle singole user story diventano più accurate permettendo di svilupparle con maggiore puntualità.

4.3.1.2 Approccio adottato

Sebbene questo sia un progetto individuale, l’utilizzo dell’approccio scrum fornisce grossi vantaggi, sia sotto l’aspetto organizzativo e di pianificazione, sia sotto l’aspetto puramente didattico.

Come visto nella sezione precedente, scrum prevede la suddivisione del progetto in itera-zioni di lavoro chiamatesprint.

All’inizio del progetto, nel corso del colloquio introduttivo con il relatore Roberto Guidi, si è discusso riguardo alla definizioni delle prime user story e della definizione dei cicli di lavoro.

Per questo progetto abbiamo deciso di effettuare degli sprint con una lunghezza di due settimane.

4.3.2

Software di pianificazione

4.3.2.1 Source Code Management Redmine

Redmine è un tool gratuito open-source per la pianificazione e gestione dei progetti tramite interfaccia web. La sua flessibilità lo rende uno dei tool più utilizzati dalla comunità degli sviluppatori.

Redmine, attraverso tutta una serie di plugin di terze parti, è un software che permette di gestire progetti basati sulla metodologia agile/scrum; esso fornisce strumenti per la piani-ficazione degli sprint e permette di effettuare il tracciamento del tempo e il controllo degli accessi basato sui ruoli.

Questo tool standard è adottato a livello istituzionale ed è stato deciso di sfruttarlo anche per organizzare e gestire le iterazioni di questo progetto.

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.

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, building7e 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.

7

In informatica questo processo viene usato per trasformare i file del codice sorgente in un applicazione eseguibile.

8

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 paltera-resente nell’ultima versione del codice paltera-resente sul altera-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è

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, dettiBuild 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.

Figura 4.5: Pagina principale di TeamCity che mostra un processo di build completato con successo per la piattaforma 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 è ottenibileintegrando 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 otpermet-tenere 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.

4.6.1

Docker

Docker è un progetto open-source utilizzato da molti sviluppatori per implementare, rilascia-re ed eseguirilascia-re 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 chiamatacontainer. ([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.

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 richiesfat-to che quest’ultimo venisse sfruttato per rilasciare le nuove funzionalità implementate in questa tesi di bachelor.

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

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 comandonpm 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 comandonpm install.

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 è unmodule 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.

au-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:

4.7.3

Vue.js

Vue.js è unprogressive framework12nato 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-back-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.

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.