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

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.

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

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 al 63.6%

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 al 96.6%

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

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.

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.

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

Appendice A

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.

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

Appendice B

Docker

B.1

Containers

Figura B.1: Struttura di un ambiente Docker

Gli ambienti sandbox in Docker vengono chiamaticontainer, 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

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

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