Realizzazione di un Sistema di Consuntivazione per una piattaforma di Digital Workplace

Università degli Studi di Padova

Dipartimento di Matematica

Corso di Laurea in Informatica

Realizzazione di un Sistema diConsuntivazione per una piattaforma di

Digital Workplace

Tesi di laurea triennale

Relatore

Prof. Tullio Vardanega

Laureanda

Federica Speggiorin

Anno Accademico 2015-2016

Federica Speggiorin: Realizzazione di un Sistema di Consuntivazione per una piatta-forma di Digital Workplace, Tesi di laurea triennale, c© Set 2016.

Sommario

Il presente documento descrive il lavoro svolto durante il periodo di stage, delladurata di circa otto settimane, dalla laureanda Federica Speggiorin presso l’aziendaWintech S.p.A.

L’attività di stage prevedeva l’analisi, la progettazione e lo sviluppo di un’applica-zione web responsive per la gestione della consuntivazione aziendale. Il sistema dovevapermettere la consuntivazione delle ore lavorative dei dipendenti impegnati nei variprogetti aziendali.

iii

Indice

1 Realtà aziendale 11.1 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Prodotti e servizi offerti . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2.1 Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.2 Prodotti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.3 L’idea di WOW . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Processi interni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.1 Approccio Agile allo sviluppo software . . . . . . . . . . . . . . 7

1.4 Strumenti e tecnologie di supporto . . . . . . . . . . . . . . . . . . . . 91.4.1 Supporto ai processi interni . . . . . . . . . . . . . . . . . . . . 91.4.2 Supporto allo sviluppo . . . . . . . . . . . . . . . . . . . . . . . 9

1.5 Ricerca e Innovazione . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.5.1 Prodotti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.5.2 Personale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.5.3 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Strategia aziendale 132.1 Lo stage visto dall’azienda . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.1 Rapporto con lo stagista . . . . . . . . . . . . . . . . . . . . . . 132.1.2 Prospettive di fine stage . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Il progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.1 L’applicazione attuale: GeCo . . . . . . . . . . . . . . . . . . . 142.2.2 Il nuovo applicativo: Kronos . . . . . . . . . . . . . . . . . . . 162.2.3 Il progetto visto dall’azienda . . . . . . . . . . . . . . . . . . . 16

2.3 Il progetto visto dallo stagista . . . . . . . . . . . . . . . . . . . . . . . 172.4 Vincoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.1 Vincoli temporali . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4.2 Vincoli metodologici . . . . . . . . . . . . . . . . . . . . . . . . 182.4.3 Vincoli tecnologici . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Svolgimento dello stage 213.1 Il Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 Tecnologie adottate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.1 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.2 Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.3 Strumenti e tecnologie di supporto . . . . . . . . . . . . . . . . 27

3.3 Pianificazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4 Analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

v

vi INDICE

3.4.1 Modello utilizzato . . . . . . . . . . . . . . . . . . . . . . . . . 303.4.2 Suddivisione del lavoro tra i membri del team . . . . . . . . . . 33

3.5 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.5.1 Architettura generale del sistema . . . . . . . . . . . . . . . . . 333.5.2 Comunicazione tra back-end e front-end . . . . . . . . . . . . . 343.5.3 Progettazione di dettaglio . . . . . . . . . . . . . . . . . . . . . 36

3.6 Realizzazione delle funzionalità . . . . . . . . . . . . . . . . . . . . . . 413.6.1 Inserimento e modifica di una voce di consuntivazione . . . . . 413.6.2 Feedback all’utente sullo stato di consuntivazione . . . . . . . . 433.6.3 Gestione della sicurezza . . . . . . . . . . . . . . . . . . . . . . 43

3.7 Qualità del prodotto realizzato . . . . . . . . . . . . . . . . . . . . . . 443.7.1 Metriche adottate . . . . . . . . . . . . . . . . . . . . . . . . . 443.7.2 Risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4 Valutazione retrospettiva 474.1 Valutazione dello stage . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.1.1 Resoconto sugli obiettivi dell’azienda . . . . . . . . . . . . . . . 474.1.2 Resoconto sugli obiettivi personali . . . . . . . . . . . . . . . . 49

4.2 Valutazione della distanza tra lo stage e il corso di studi . . . . . . . . 494.2.1 Valore aggiunto dallo stage . . . . . . . . . . . . . . . . . . . . 494.2.2 Competenze mancanti all’inizio dello stage . . . . . . . . . . . 504.2.3 Progetti didattici . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3 Valutazioni personali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Glossario 53

Indice delle fonti 57

Elenco delle figure

1.1 Logo di Wintech S.p.A. . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Offerta prodotti di Wintech . . . . . . . . . . . . . . . . . . . . . . . . 21.3 WOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Scomposizione di WOW in moduli . . . . . . . . . . . . . . . . . . . . 61.5 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.6 Integrazione continua . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1 Vista a calendario di GeCco . . . . . . . . . . . . . . . . . . . . . . . . 142.2 Modale di creazione di una voce di consuntivazione su GeCco . . . . . 152.3 Logo di StageIT 2016 . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4 Vincoli tecnologici a back-end e a front-end . . . . . . . . . . . . . . . 192.5 Diagramma architetturale del pattern Model-View-ViewModel . . . . . 20

3.1 Collocazione tecnologie nell’architettura di Kronos . . . . . . . . . . . 223.2 Architettura delle classi di JPA . . . . . . . . . . . . . . . . . . . . . . 233.3 Dropdown di SemanticUI . . . . . . . . . . . . . . . . . . . . . . . . . 263.4 Datepicker di UI Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 263.5 Timepicker di UI Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . 273.6 Webpack module bundler . . . . . . . . . . . . . . . . . . . . . . . . . 273.7 Metodologia Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.8 Attività previste dalla metodologia Agile . . . . . . . . . . . . . . . . . 293.9 Sezioni che compongono il documento di analisi secondo il Venture Design 313.10 Architettura generale di Kronos . . . . . . . . . . . . . . . . . . . . . . 343.11 Comunicazione tra back-end e front-end . . . . . . . . . . . . . . . . . 353.12 Diagramma del back-end . . . . . . . . . . . . . . . . . . . . . . . . . . 363.13 Database di Kronos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.14 Diagramma del front-end . . . . . . . . . . . . . . . . . . . . . . . . . 403.15 Vista a calendario di Kronos . . . . . . . . . . . . . . . . . . . . . . . 413.16 Modale di inserimento su Kronos . . . . . . . . . . . . . . . . . . . . . 423.17 Form-Based Authentication di J2EE. . . . . . . . . . . . . . . . . . . . 44

vii

Elenco delle tabelle

2.1 Obiettivi personali previsti . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Classi e interfacce in javax.persistence . . . . . . . . . . . . . . . . . . 233.2 Alcune delle annotazioni JAX-RS . . . . . . . . . . . . . . . . . . . . . 243.3 Pianificazione delle attività e delle ore di lavoro . . . . . . . . . . . . . 303.4 Tabella riassuntiva dei pensieri di Tommaso: il tecnico . . . . . . . . . 323.5 Tabella riassuntiva dei pensieri di Pietro: il Project Manager . . . . . 333.6 Risultati dei test di qualità sul back-end . . . . . . . . . . . . . . . . . 453.7 Risultati dei test di qualità sul front-end . . . . . . . . . . . . . . . . . 45

4.1 Funzionalità e risultati raggiunti . . . . . . . . . . . . . . . . . . . . . 474.2 Funzionalità derivate e risultati raggiunti . . . . . . . . . . . . . . . . 474.3 Obiettivi personali previsti e risultati raggiunti . . . . . . . . . . . . . 49

viii

Capitolo 1

Realtà aziendale

Questo capitolo descrive la realtà aziendale e il dominio applicativo in cui ha avutosvolgimanto l’attività di stage.

1.1 L’aziendaWintech S.p.A. è un’azienda che si occupa di system integration. Ha sede a Padova,

con filiali a Milano e Bassano del Grappa, e conta circa 80 dipendenti suddivisi su 6business unit. Essendo nata quasi trent’anni fa, esattamente nel 1987, ha sviluppato neltempo conoscenze e competenze in diversi ambiti del settore ICT e stretto partnershipcon colossi dell’informatica come IBM e Microsoft.

Wintech offre sul mercato prodotti in grado di soddisfare le esigenze di clienti quali:professionisti, aziende di moda, PMI, grandi aziende, pubblica amministrazione, banchee assicurazioni.

I dipendenti lavorano costantemente focalizzati sul cliente. Partendo dalle sueesigenze cercano di produrre soluzioni su misura che soddisfino al meglio i bisogni ele aspettative. Offre anche consulenza personalizzata e soluzioni IT per ottimizzare iprocessi aziendali e assistenza sui suoi prodotti.

figura 1.1: Logo di Wintech S.p.A.

Fonte: http://www.wintech.it/wp-content/uploads/2014/10/imgo.jpeg

1.2 Prodotti e servizi offerti

1.2.1 Servizi

L’azienda offre ai propri clienti servizi quali:

1

http://www.wintech.it/wp-content/uploads/2014/10/imgo.jpeg

2 CAPITOLO 1. REALTÀ AZIENDALE

• analisi e progettazione di soluzioni su misura. Attraverso un dialogo diretto cercadi individuare i bisogni al fine di realizzare prodotti che soddisfino al meglio leattese;

• installazione ed avviamento delle soluzioni, una volta sviluppate;

• formazione per l’uso delle proprie applicazioni;

• consulenza;

• assistenza di tipo sistemistico, help desk o applicativo. Questo ultimo tipo diassistenza può essere effettuato a distanza con software come Team Viewer o coninterventi sul posto.

1.2.2 Prodotti

figura 1.2: Offerta prodotti di Wintech

I prodotti che offre si differenziano in base alla tipologia di cliente.

• Per i Professionisti :

– PROFIS: insieme di applicazioni progettate per soddisfare le esigenzedi Studi Professionali e Associazioni che erogano servizi di consulenzaamministrativa e fiscale. Permette anche di fidelizzare i propri clienticondividendo applicazioni, documenti e dati;

– JOB: è una soluzione multiaziendale e multicontrattuale per gestire consemplicità ed efficienza tutte le diverse attività connesse all’amministrazionedel personale: dalle elaborazioni delle buste paga, al budget e all’analisi deicosti del personale;

1.2. PRODOTTI E SERVIZI OFFERTI 3

– STUDIO: permette di gestire in modo efficiente le attività amministrative,organizzative e di controllo di uno Studio Professionale. Permette di auto-matizzare il processo di fatturazione, organizzare e monitorare i carichi dilavoro, aumentare la produttività avvalendosi di funzionalità avanzate dicontrollo di gestione.

• Per le Aziende di Moda:

– eSOLVER per la Moda: permette di gestire tutte le informazioni tipichedi settore, inserire e raggruppare gli ordini cliente, gestire le spedizioni ela logistica, gestire i punti vendita, interfacciare stampanti di etichette elettori di codici a barre;

– QlikView Business Discovery: piattaforma che permette di monitorarele performance di vendita, avere una visione sintetica degli avanzamenti diproduzione, analizzare le vendite, disporre di report dei punti vendita.

• Per le Piccole e Medie Imprese:

– eSolver: per gestire le attività amministrative, controllare la gestione eautomatizzare i processi aziendali logistici e di produzione;

– Gold Tesoreria: strumento attraverso il quale si ottiene un pieno controllodella pianificazione finanziaria;

– coregain CRM: strumento attraverso il quale è possibile acquisire nuoviclienti (o potenziali), aumentare le relazioni con i clienti più importanti efidelizzarli a lungo termine.

• Per le Grandi Aziende:

– Disaster Recovery: insieme delle misure tecnologiche, logistiche e orga-nizzative atte a ripristinare i sistemi, i dati e a garantire i servizi di business.Ha lo scopo di recuperare le azioni di ciascun collaboratore, ripristinare lanormale operatività e recuperare i dati.

• Per Banche e Assicurazioni : offre sistemi per la firma grafometrica.

Wintech inoltre si occupa della realizzazione di Portali e Social Intranet per aggre-gare applicazioni, dati, contenuti, processi e persone rendendo più semplice ed efficienteil modo di lavorare insieme. Ultimamente, si sta concentrando nella realizzazione diun portale ad uso interno. Esso, come descritto nella sottosezione successiva 1.2.3, sichiamerà WOW ed è finalizzato a migliorare l’organizzazione interna del lavoro deidipendenti dell’azienda. In un futuro potrebbe diventare un prodotto rivendibile, perintero o a moduli, e personalizzabile in base alle necessità del cliente.


1.2.3 L’idea di WOW

figura 1.3: WOW

L’organizzazione del lavoro all’interno di Wintech è, allo stato attuale, supportata daapplicazioni distinte l’una dall’altra. Alcune di esse sono utilizzate da tutti i dipendentidell’azienda indipendentemente dalla mansione svolta, altre invece, sono dedicate allaspecifica business unit. Tra quelle comuni troviamo:

• un client di posta: utilizzato per tutte le comunicazioni formali interne tra idipendenti;

• una chat: integrata nel client di posta, viene utilizzata per comunicazioni velocie informali che non necessitano di una email;

• un sistema di consuntivazione: utilizzato da tutti i dipendenti per consuntivarele ore svolte durante le loro giornate lavorative.

Le diverse business unit utilizzano poi applicazioni specifiche. Ad esempio, la BU Svi-luppo Software utilizza HipChat 1 come chat di gruppo a supporto della comunicazionesu un singolo progetto e Jira 2 come strumento di project management.

Wintech, azienda con 3 sedi, 6 business unit e circa ottanta dipendenti, ha sentitoil bisogno di disporre di un’unica piattaforma che supportasse tutti i dipendenti neltenersi in contatto e nel condividere informazioni di utilità comune. Da qui nascel’idea di realizzare WOW. L’acronimo sta per World Of Wintech e indica un DigitalWorkplace. Si tratta di un’evoluzione della intranet aziendale da semplice portale dicomunicazione ad uno spazio digitale vero e proprio in cui tutte le applicazione e iprocessi chiave (come comunicazione, collaborazione, conoscenza, processi operativi edi business) sono gestiti e integrati.

L’azienda si sta dunque impegnando, tra le altre attività, nella realizzazione diquesto progetto. WOW sarà un portale tutto nuovo in cui ogni dipendente avrà adisposizione ciò che cerca, tutto ciò che vuole sapere sull’azienda, le applicazioni cheusa e molto altro. Il portale sarà personalizzato in funzione dell’utente che vi accede,della sua mansione e della sua appartenenza ad una business unit.

Che cosa comporrà WOW:1https://www.hipchat.com/2https://www.atlassian.com/software/jira

https://www.hipchat.com/

https://www.atlassian.com/software/jira

1.2. PRODOTTI E SERVIZI OFFERTI 5

• un portale in grado di profilare gli utenti in modo rigoroso;

• delle anagrafiche univoche;

• un motore collaborativo veloce e contestuale;

• un motore informativo veloce, puntuale e profilato;

• una grafica ed una user experience capace di avvicinare e non di allontanare gliutenti;

Si ipotizza già da ora la possibilità di aggiungere, in futuro, nuove funzionalità ecomponenti.

Il portale

Il portale consentirà di aggregare funzioni applicative, dati, contenuti e persone,rendendo più efficiente il loro modo di lavorare insieme, in diversi contesti. WOWsarà dotato di un ambiente modulare, flessibile e scalabile. Un’unica user experienceuniformerà l’ambiente aziendale. Criteri di sicurezza rigorosi permetteranno di fornireall’utente corretto le funzioni e i contenuti corretti. Gli utenti potranno così trovarvi lefunzioni applicative di cui hanno bisogno. Sarà il fulcro e il punto di incontro di unapiattaforma collaborativa e secondo logiche di derivazione “social”.

La home page

Ogni utente, all’accesso al portale, potrà visualizzare una home page personalizzata.Principalmente conterrà le news sull’azienda, le cose che deve fare e che deve sapere, isuoi impegni, i contatti, gli strumenti di lavoro e tutto ciò di cui potrebbe aver bisognoper svolgere il proprio lavoro giornaliero.

Il motore collaborativo

Nel portale ogni elemento sarà commentabile, e sarà possibile allegare file, foto ovideo. Nella home di ogni utente saranno visualizzati i commenti che lo riguardano epotrà, a sua volta, rispondere e commentare. Costituirà un nuovo modo di lavorare edi partecipare ma con i rilevanti vantaggi di:

• abbattere la quantità di posta interna;

• “contestualizzazione” della comunicazione, tipica degli ambienti “social”.

La centralità dell’utente

Ogni utente vedrà il portale personalizzato in base alle proprie esigenze. In par-ticolare la gestione del profilo, le applicazioni e i servizi saranno differenziati in baseall’identità dell’utente che accede alla piattaforma.

Le anagrafiche univoche

Wintech dispone già di un applicativo, eSolver, per raccogliere tutte le anagrafichedi clienti, leader, prospect e fornitori. Questo verrà dunque integrato in WOW.


Scomposizione di WOW in moduli

La figura sottostante mostra, ad alto livello, l’insieme di moduli che andranno acomporre WOW.

figura 1.4: Scomposizione di WOW in moduli

I componenti di WOW saranno quindi i seguenti:

• News: saranno sempre disponibili ad ogni utente tutte le ultime news cheriguardano l’azienda;

• eSolver: è l’applicativo che contiene tutte le anagrafiche. Esso sarà integrato nelportale rendendo disponibili ai suoi utenti i contatti di aziende, clienti e fornitoridi cui hanno bisogno;

• Calendario: un calendario permetterà di visualizzare velocemente tutti gliimpegni e la programmazione della settimana di ogni dipendente;

• Messaging: una parte del portale sarà dedicata alle comunicazioni che, sottoqualsiasi forma (ad esempio email, messaggistica istantanea), supportano lepersone di Wintech nel loro lavoro;

• Dashboard Aziendale: dashboard intuitiva in cui si visualizzeranno, sottoforma di grafico, dati sull’azienda che potrebbero interessare l’utente autenticato;

• Project Management: modulo di supporto al Project Manager per la gestionedei progetti;

• Task Manager: conterrà tutte le attività da svolgere. Esse possono proveniredai diversi applicativi utilizzati, sia in forma automatica che assegnata, oppurepossono essere create direttamente dall’utente;

1.3. PROCESSI INTERNI 7

• Consuntivazione: permetterà la consuntivazione delle ore ai dipendenti. Iltema dello stage riguarda proprio la realizzazione di questo modulo;

• Nota Spese e Gestione Presenze: permetteranno ad ogni utente di gestirele proprie presenze e di inserire eventuali note sulle spese sostenute;

• Profilo Utenti: permetterà ad ogni utente di gestire il suo profilo e visualizzarequello dei colleghi;

• Applicazioni: permetterà di accedere velocemente alle applicazioni utilizzatedall’utente;

• Piattaforma Informazione e Social Communities: costituiranno integra-zioni di due strumenti già utilizzati: IMB Connections3 e la piattaforma diinformazione basata su Moodle4.

1.3 Processi interni

1.3.1 Approccio Agile allo sviluppo software

Con l’obiettivo di focalizzarsi sempre sul cliente, comprenderne i bisogni e soddisfarele sue aspettative, Wintech adotta, nell’organizzazione dei propri team, la metodologiaagile. Scrum è un framework utilizzato per gestire lo sviluppo di prodotti complessi.Tale metodologia rivoluziona l’approccio classico di sviluppo software a partire dall’unitàpiù piccola: il team.

Scrum Team

Lo Scrum Team è formato dal Product Owner, dal Developement Team e da unoScrum Master. Presenta la seguenti caratteristiche:

• auto-organizzato: il team ripartisce autonomamente il lavoro da svolgere senzache un responsabile decida a chi assegnare le attività;

• cross-funzionale: il team è, nel suo complesso, competente in tutto ciò che serveper portare a compimento il progetto.

I ruoli classici di un team di sviluppo, quindi, vanno a scomparire e vengono gestitiinteramente e flessibilmente all’interno dell’intero team di sviluppo. In Scrum il teamè composto al massimo da nove persone. Limitando infatti il numero di persone chedevono lavorare assieme, risulta più facile gestire il progetto e si presentano menoproblemi riguardo l’interazione tra i membri e la loro coordinazione.

Developement Team

Il Developement Team è responsabile della consegna del prodotto con incrementi difunzionalità che siano potenzialmente rilasciabili alla fine di ogni Sprint.

3http://www-03.ibm.com/software/products/it/conn4https://moodle.org

http://www-03.ibm.com/software/products/it/conn

https://moodle.org


Scrum Master

Il ruolo dello Scrum Master è quello di fare da “guida” all’interno del team in modotale che la metodologia venga applicata correttamente. Tale ruolo è di fondamentale im-portanza affinché non si verifichino gli effetti negativi derivanti da una sua applicazionescorretta.

Product Owner

Il Product Owner consente al Developement Team di procedere nello sviluppo senzale continue interruzioni che sarebbero dovute al dialogo con gli stakeholders esternial team. Egli è inoltre responsabile del carico di lavoro (detto backlog) e dialogacostantemente con il Developement Team per stabilire le priorità e stimare il costo dasostenere per portare a compimento le attività.

figura 1.5: Scrum

Fonte:http://calvinx.com/wp-content/uploads/2014/05/scrum-overview-mark-hoogveld.jpg

Scrum Overwiew

I task vengono inseriti in cicli di produzione chiamati sprint. Ciascuno sprint puòavere una durata massima di quattro settimane durante le quali vengono sviluppatefunzionalità aggiuntive rispetto allo sprint precedente. Al termine di ogni ciclo dovrebbeessere presentato al cliente un incremento potenzialmente rilasciabile.

All’inizio di ogni sprint, in uno Sprint Planning vengono decisi quali sono itask che il Developement Team deve portare a termine nel tempo stabilito (Sprint

http://calvinx.com/wp-content/uploads/2014/05/scrum-overview-mark-hoogveld.jpg

1.4. STRUMENTI E TECNOLOGIE DI SUPPORTO 9

Backlog). Dialogando con il Product Owner viene decisa la priorità con la qualedevono essere svolti.

Ogni giorno, durante lo sprint, il team si dedica anche al Daily Scrum. Si trattadi un tempo di massimo quindici minuti, a cui partecipano tutti i membri del team.Ciascuno espone cosa ha fatto il giorno precedente, di cosa si occuperà nel giornocorrente e quali problematiche ha incontrato nello svolgere i task assegnati.

Al termine dello sprint si susseguono Sprint Review e Sprint Retrospective.Il primo serve a presentare al cliente l’incremento raggiunto grazie allo sprint. Questiincontri incentivano anche l’interazione e possono emergere altri requisiti. Il secondo,invece, riunisce tutto il team e consente di analizzare lo sprint appena trascorso e leopinioni espresse dal cliente per tenerne conto in futuro nell’ottica del miglioramentocontinuo. Vengono discussi cambiamenti e miglioramenti da apportare per gli sprintsuccessivi in modo da rispondere maggiormente alle esigenze del cliente.

1.4 Strumenti e tecnologie di supporto

1.4.1 Supporto ai processi interni

Gestione di progetto

Come strumento di supporto al project management Wintech utilizza Jira5. Sitratta di un’applicazione web che permette, oltre le classiche funzionalità di unostrumento di gestione di progetto, di visualizzare una Scrum Board in cui si ha unavisibilità immediata sullo stato dello sprint suddividendo tra task ancora nel backlog,in corso e completati. Inoltre è possibile consultare una serie di grafici che mostranol’andamento dell’intero progetto o dei singoli sprint.

1.4.2 Supporto allo sviluppo

Ambiente di sviluppo

Per la maggior parte i computer di Wintech ospitano Windows, in varie versioni,ed in alcuni casi Linux. Per quanto riguarda l’ambiente di sviluppo viene utilizzatoEclipse6, tuttavia, ogni sviluppatore è libero di utilizzare ciò che meglio crede nellosvolgimento del proprio lavoro.

Versionamento

Wintech, per il versionamento del codice, utilizza Subversion7.

Integrazione continua e test

Per l’integrazione continua l’azienda utilizza Jenkins8. È uno strumento open sour-ce ed è dotato di un vasto numero di plugin tramite il quale estenderne le funzionalitàe adattarlo praticamente a qualunque procedura si voglia adottare.

5https://www.atlassian.com/software/jira6https://eclipse.org/7https://subversion.apache.org/8https://jenkins.io/

https://www.atlassian.com/software/jira

https://eclipse.org/

https://subversion.apache.org/

https://jenkins.io/


Per l’esecuzione dei test automatici vengono utilizzati, a backend, JUnit9 eMokito10, a frontend invece, Karma11 e Jasmine12.

Il ciclo di integrazione continua previsto è illustrato nella figura sottostante.

figura 1.6: Integrazione continua

Fonte: https://insights.sei.cmu.edu/assets/content/image%20for%20continuous%20integration%20and%20devops_01262015.jpg

Ad ogni commit da parte di un membro del team parte automaticamente, sul serverdi integrazione, un processo che esegue la build del codice, i test previsti e notifica,tramite HipChat, il fallimento o il successo dell’operazione ai partecipanti al progetto.

1.5 Ricerca e InnovazioneWintech, anche se nata vent’anni fa, ha sempre cercato di mantenersi costantemente

aggiornata in modo da essere competitiva sul mercato.

1.5.1 ProdottiL’azienda cerca di proporsi al cliente nel modo più innovativo possibile utilizzando,

nella realizzazione delle sue soluzioni, tecnologie all’avanguardia e aggiornate. Sviluppasoluzioni anche per aziende in cui sono necessarie l’affidabilità, la robustezza e la stabilitàdell’applicazione. Per questo motivo adotta tecnologie stabili e affermate, come Java eSQL. Nel tempo ha anche stretto delle partnership con colossi dell’informatica comeIBM e Microsoft. Nella realizzazione di applicazioni, a frontend, adotta AngulrJS.

9http://junit.org/junit4/10http://mockito.org/11https://karma-runner.github.io/1.0/index.html12http://jasmine.github.io/

https://insights.sei.cmu.edu/assets/content/image%20for%20continuous%20integration%20and%20devops_01262015.jpg

https://insights.sei.cmu.edu/assets/content/image%20for%20continuous%20integration%20and%20devops_01262015.jpg

http://junit.org/junit4/

http://mockito.org/

https://karma-runner.github.io/1.0/index.html

http://jasmine.github.io/

1.5. RICERCA E INNOVAZIONE 11

Questo framework le permette di creare interfacce responsive, cross-platform e chesiano di facile interazione per l’utente.

1.5.2 PersonaleL’azienda ritiene importante che il proprio personale sia aggiornato e in linea con le

ultime tecnologie. Per questo offre formazione ai dipendenti anche sotto forma di corsionline in una piattaforma apposita, Wintech Informa13. Trova anche nell’assunzionedi stagisti l’occasione di crescere e rinnovarsi. Partecipa infatti, da alcuni anni,all’evento StageIT offrendo possibilità di stage agli studenti universitari. Gli sviluppatoricomprendono persone con molta esperienza e ragazzi giovani, laureandi o neolaureati,che portano una “ventata d’aria fresca”. Wintech, infatti, è sempre pronta ad accoglierenuove idee e soluzioni che provengono dal suo personale.

1.5.3 ScrumUn altro aspetto che evidenzia la propensione di Wintech nei confronti dell’innova-

zione è l’adozione di Scrum nella gestione dei progetti di sviluppo. Essendo un’aziendanata circa vent’anni fa avrebbe potuto continuare ad adottare metodi di sviluppoprecedenti e consolidati, invece, ha deciso di rinnovarsi e progredire adottando questametodologia agile. Tale scelta ha portato ad uno snellimento dei processi e l’azienda èin grado di produrre software di migliore qualità, in meno tempo, andando incontromaggiormente alle esigenze del cliente.

13https://informazione.wintech.it/j/

https://informazione.wintech.it/j/

Capitolo 2

Strategia aziendale

Il seguente capitolo illustra come l’azienda vede l’attività di stage di un laureando ecome lo gestisce.

2.1 Lo stage visto dall’aziendaWintech considera gli stage come un’attività che porta valore aggiunto all’azienda.

Non si tratta, infatti, di ospitare uno studente per due mesi al puro scopo di disporre dimaggiore forza lavoro. L’azienda vede nello stage principalmente due grandi vantaggi,momenti di conoscenza e confronto con l’esterno:

• ospitare studenti universitari comporta la possibilità di avere un confronto conle competenze e le conoscenze erogate dalle università agli studenti;

• l’azienda è sempre propensa a conoscere persone nuove e ad accogliere positi-vamente le loro proposte circa metodologie e tecnologie da adottare. Potrebbeinfatti trovare, attivando stage, occasione di rinnovarsi e di introdurre metodolo-gie più adatte al lavoro che svolge, oppure, scoprire e adottare nuove tecnologieche meglio si adattano ai suoi bisogni.

2.1.1 Rapporto con lo stagistaWintech cerca di instaurare, fin dal primo giorno, un buon rapporto con lo stagista.

Il laureando viene considerato un collega a tutti gli effetti da tutti i dipendentidell’azienda. Ritiene infatti importante che si instauri un rapporto di fiducia, serietàe collaborazione reciproca. Il personale è sempre pronto ad ascoltare, discutere eaccogliere proposte e iniziative da parte dello studente. È apprezzato anche il fattoche, per i due mesi di stage, fornisca un rimborso spese per trasporto e pasti.

2.1.2 Prospettive di fine stageGià a partire dalla selezione, nel mio caso all’evento StageIT, e dai primi colloqui

individuali, Wintech cerca studenti che siano propensi a rimanere in azienda allaconclusione dello stage. Al termine quindi, se le aspettative iniziali si sono concretizzatee si è instaurato un buon rapporto di collaborazione con lo stagista, propone uncontratto di lavoro nella quasi totalità dei casi (salvo che si siano presentate particolari

13

14 CAPITOLO 2. STRATEGIA AZIENDALE

problematiche durante il tirocinio). Tale prospettiva è concreta, infatti, alcuni deglisviluppatori che ho conosciuto sono ragazzi, laureandi o neolaureati, che sono statiassunti dopo uno stage come il mio.

2.2 Il progetto

2.2.1 L’applicazione attuale: GeCo

La gestione della consuntivazione aziendale all’interno di Wintech è, allo statoattuale, affidata a GeCo. GeCo è un applicativo a se stante utilizzato da tutti idipendenti, di qualsiasi ruolo, all’interno dell’azienda.

Ogni dipendente è tenuto a specificare, per ogni giornata lavorativa, su cosa halavorato e quanto tempo ha impiegato. Si tratta di un’attività che deve essere svoltaaccuratamente e nei tempi richiesti perché il risultato delle consuntivazioni porta allagenerazione dei rapportini ai clienti.

figura 2.1: Vista a calendario di GeCco

I passi che ciascuno deve eseguire per ogni operazione di consuntivazione sono:

1. trascinare da un’ora ad un’altra su un giorno specifico del calendario (figura 2.1)in modo tale che compaia il modale (figura 2.2) per l’inserimento dei dati relativialla consuntivazione;

2. inserire tutti i dati richiesti nel modale (figura 2.2), che variano in base al ruolodei dipendenti e in base al tipo di attività da consuntivare;

3. confermare l’operazione.

2.2. IL PROGETTO 15

figura 2.2: Modale di creazione di una voce di consuntivazione su GeCco

Risulta necessario fare una premessa: la consuntivazione è, per sua natura, un’atti-vità che l’utente è tenuto a fare per l’azienda ma che non porta alcun vantaggio nellosvolgimento del proprio lavoro. Talvolta, infatti, risulta un intralcio in quanto occupadel tempo che potrebbe essere impiegato in altre attività.

La procedura esposta sopra sembra apparentemente semplice, tuttavia, essendoutilizzato in azienda da parecchio tempo, gli utenti hanno rilevato una serie di problemie disagi nell’utilizzo di GeCo:

• all’apertura l’applicativo presenta un form di login. Tale form, assieme agli altriper l’accesso a tutte le applicazioni aziendali, non è altro che una ripetizione perl’utente che deve autenticarsi nuovamente;

• il modale di creazione di una voce di consuntivazione contiene un numero moltoalto di campi da completare. Più precisamente, contiene sempre tutti i campianche se quelli necessari variano da dipendente a dipendente e in base all’attivitàche si sta consuntivando. Questo comporta che ciascuno deve ricordarsi qualideve compilare e quali no nei vari casi;

• poiché i campi sono molti, eseguire la loro compilazione per più attività al giorno,tutti i giorni, comporta un’attività frustrante per l’utente che, dopo poco, siinnervosisce e potrebbe sbagliare. Questo non dovrebbe accadere in quantol’attività di consuntivazione necessita di essere molto accurata.

• alcuni utenti, in giornate cariche di lavoro, non hanno il tempo di consuntivare.Accade, quindi, che si trovano a svolgere tale compito dopo alcuni giorni o,nei casi peggiori, anche a distanza di settimane non ricordando esattamente leattività svolte. Anche questo non dovrebbe avvenire in quanto la generazionedei rapportini ai clienti ha delle scadenze e tutte le consuntivazioni dovrebberoessere il più aggiornate possibile.


Wintech ha deciso di risolvere tutti questi problemi, o comunque la maggior parte,proponendo come progetto di stage la creazione di un nuovo applicativo descritto nellasottosezione successiva 2.2.2.

2.2.2 Il nuovo applicativo: KronosCome ho già illustrato in 1.2.3, Wintech si sta impegnando nella realizzazione del

portale WOW. Oltre ai componenti descritti precedentemente ha pensato di creareun’applicazione migliorata rispetto all’attuale GeCo. Kronos è il nome che è statoscelto.

Lo stage prevedeva l’analisi, la progettazione e lo sviluppo di un’applicazioneweb responsive per la gestione della consuntivazione aziendale che in futuro saràcompletamente integrata in WOW. Il sistema doveva permettere la consuntivazionedelle ore lavorative dei dipendenti impiegati nei vari progetti aziendali.

A partire, dunque, da una breve analisi di GeCo, dalle opinioni raccolte e daldialogo con gli utenti che lo usano, l’obiettivo era la realizzazione di un nuovo siste-ma di consuntivazione che andasse a risolvere i problemi dell’applicativo attuale conqualche incremento di funzionalità. Doveva, inoltre, utilizzare la stessa base di datiin modo da rendere ancora disponibile l’uso delle applicazioni che si integrano con GeCo.

2.2.3 Il progetto visto dall’aziendaSulla base della durata massima di 320 ore prevista per lo stage, l’azienda ha

fissato degli obiettivi massimi e minimi che si aspetta di veder raggiunti al termine delrapporto lavorativo.

Obiettivi minimi

• Studio della tecnologia e introduzione agli strumenti di sviluppo:

– studio tecnologie e prodotti utilizzati;

– predisposizione ambienti di sviluppo;

– introduzione ai sistemi di continuous integration;

– introduzione al progetto.

• Analisi della soluzione:

– user discovery, problem scenario, value proposition;

– esperimenti;

– analisi tecnica.

• Progettazione architetturale:

– interfaccia grafica;

– gestione attività;

– ricerca;

– sistemi di notifica.

• Progettazione di dettaglio e implementazione:

2.3. IL PROGETTO VISTO DALLO STAGISTA 17

– interfaccia grafica;

– gestione attività;

– ricerca;

– sistema di notifica;

Obiettivi massimi

• Progettazione architetturale:

– reportistica per team;

– amministrazione.

• Progettazione di dettaglio e implementazione:

– reportistica per team;

– amministrazione.

2.3 Il progetto visto dallo stagista

L’attività di stage è obbligatoria e prevista dal piano di studi del corso di laurea.Nel mio caso tuttavia, non avendo intenzione di procedere con la laurea magistrale, lostage sarebbe stata un’occasione preziosa per conoscere l’azienda e magari trovare unposto di lavoro.

Sono venuta a conoscenza di Wintech e dei progetti proposti a StageIT 2016, eventoorganizzato da Confindustria Padova in collaborazione con l’Università di Padovae Venezia per favorire l’incontro tra gli studenti e il mondo del lavoro nell’ottica diattivare uno stage.

figura 2.3: Logo di StageIT 2016

Fonte: http://informatica.math.unipd.it/img/stageit2016.jpg

L’azienda era presente proponendo tre progetti:

• realizzazione di un sistema di gestione dei task, da integrare in WOW;

• realizzazione di un sistema di consuntivazione, da integrare in WOW;

• realizzazione di un archiviatore, da integrare in WOW.

http://informatica.math.unipd.it/img/stageit2016.jpg


Quelli che mi interessavano maggiormente erano i primi due. Successivamente, dopoil colloquio personale con l’azienda, ho optato per il secondo. Tale scelta è stata inparte guidata dall’azienda la quale riteneva prioritario e maggiormente interessantela realizzazione del sistema di consuntivazione. Trattandosi, inoltre, di un progettopiuttosto lungo e complessivamente non realizzabile in tutte le funzionalità necessariead integrarlo in WOW con sole otto settimane di lavoro, Wintech proponeva di inseriredue studenti nello stesso progetto in modo da procedere più velocemente.

Nell’ottica della realizzazione del progetto richiesto ho individuato alcuni obiettiviminimi e massimi da raggiungere durante lo stage.

Obiettivi minimi Obiettivi massimiConoscenza della metodologia Scrumnello sviluppo software.

Avvicinamento all’idea di portale e diapplicazioni in esso integrate.

Acquisizione delle competenze neces-sarie a sviluppare le funzionalitàrichieste.Conoscenza delle tecnologie necessarieallo svolgimento dello stage.Presa di coscienza di cosa significhisystem integration dovendo sviluppareun’applicazione che si deve integrare conil database di una già esistente.

tabella 2.1: Obiettivi personali previsti

2.4 Vincoli

2.4.1 Vincoli temporali

La durata massima dello stage è prevista di 300, massimo 320, ore. D’accordo conl’azienda ho lavorato a tempo pieno, 8 ore al giorno, per 5 giorni alla settimana, salvoimprevisti o impegni personali, per circa 8 settimane.

Sulla base di questa premessa abbiamo suddiviso il periodo di stage in 4 cicli diScrum, 3 di 2 settimane e 1 di una settimana. Ciascun ciclo prevedeva una giornatadi Sprint Review, Sprint Retrospective e analisi delle funzionalità da includere nellosprint. Ho dedicato i primi tre giorni di stage allo studio delle tecnologie adottate ealla predisposizione degli ambienti di sviluppo.

2.4.2 Vincoli metodologici

Interazione con il tutor aziendale

Durante l’intero periodo di stage le interazioni con il tutor aziendale avvenivano intre occasioni e modalità: analisi, Daily Scrum e chiarimenti.

L’analisi, effettuata il primo giorno di ogni sprint, era volta ad individuare lefunzionalità da includere nel nuovo rilascio e a definire la pianificazione.

Il Daily Scrum consisteva in un momento di confronto quotidiano della duratamassima di 15 minuti con tutti i membri del team.

2.4. VINCOLI 19

Il resto delle interazioni avvenivano ogni qualvolta mi erano necessari dei chiarimentiriguardo alla funzionalità in corso di sviluppo, metodologie da adottare, ricevereinformazioni su variazioni dei requisiti o chiarimenti.

Pianificazione dello sprint

La pianificazione dello sprint avveniva ogni due settimane e serviva per definire piùdettagliatamente gli obiettivi da portare a termine e i vari task da svolgere per il loroconseguimento. Il Product Owner si occupava di attivare lo sprint su Jira, creare i tasknecessari e inserirli nello sprint interessato.

Consegna degli incrementi prodotti dallo sprint

Giornalmente ciascuno sviluppatore del team, in accordo con i principi di conti-nuous integration, era tenuto ad eseguire almeno un commit in una situazione stabiledell’applicazione. In questo modo, a fine sprint, tutti gli incrementi risultavano giàincorporati correttamente nella soluzione finale.

2.4.3 Vincoli tecnologici

Wintech e il tutor aziendale non hanno imposto particolari vincoli tecnologicituttavia avevano già previsto l’uso di Java, a back-end, e AngularJS, a front-end.

figura 2.4: Vincoli tecnologici a back-end e a front-end

Java e J2EE

Per lo sviluppo del back-end ho utilizzato il noto linguaggio di programmazione adoggetti Java. Tale linguaggio presenta le caratteristiche di:

• essere “semplice”, orientato agli oggetti e familiare;

• essere “robusto e sicuro”;

• essere indipendente dalla piattaforma.

In particolare, Wintech opera su piattaforma tecnologica J2EE. La sua specificainclude molte tecnologie che estendono le funzionalità di base della piattaforma Java.Tra tutte, l’azienda utlizza:

• JAX-WS/SOAP: un insieme di API del linguaggio di programmazione Javadedicate allo sviluppo di servizi web;


• Servlet: ovvero la tecnologia che permette di trasmettere pagine HTML al cliente di esporre web services;

• JPA/JDBI: per gestione la persistenza dei dati di un DBMS relazionale;

• JAX-RS: una API Java che fornisce supporto alla creazione di servizi web inaccordo con il pattern architetturale Representational State Transfer (REST).

AngularJS

Come framework per lo sviluppo del front-end ho utilizzato AngularJS. Nato conl’obiettivo di semplificare la codifica e il testing delle applicazioni web, è dotato diun particolare design pattern architetturale molto simile al Model-View-ViewModel(MVVM). Esso è stato simpaticamente ribattezzato dagli sviluppatori di AngularJScon il nome di Model-View-Whatever.

figura 2.5: Diagramma architetturale del pattern Model-View-ViewModel

Fonte: https://i-msdn.sec.s-msft.com/dynimg/IC564167.png

Questo design pattern è composto, come si evince dalla figura, da tre parti:

• Model: componente dedicata alla gestione dei dati dell’applicazione e della loropersistenza;

• View: interfaccia grafica attraverso la quale l’utente interagisce con l’applicazio-ne;

• ViewModel: componente che fa da intermediario tra Model e View. Esso èresponsabile per la gestione della logica della vista. In genere, il ViewModelinteragisce con il modello invocando metodi nelle classi del modello. Il ViewModelfornisce quindi i dati del modello in una forma che la vista può usare facilmente.

Il pattern MVVM dà il vantaggio di facilitare la separazione tra lo sviluppo dell’in-terfaccia grafica e la logica sottostante, detta business logic. A tale scopo è fortementeadottato nella produzione di applicazioni interattive.

https://i-msdn.sec.s-msft.com/dynimg/IC564167.png

Capitolo 3

Svolgimento dello stage

Il seguente capitolo contiene i dettagli relativi allo svolgimento dell’attività di stage.

3.1 Il TeamCome ho accennato in 2.3, l’azienda ha assunto due stagisti da impiegare, assieme ad

altri dipendenti, nella realizzazione del progetto. Ha collaborato, quindi, allo sviluppodi Kronos anche Mattia Varotto (studente di Informatica all’Università di Padova).Più nel dettaglio il team era composto da 5 persone:

• due sviluppatori: Federica Speggiorin e Mattia Varotto;

• un Project Manager ;

• un Architetto del Software;

• un grafico.

Quest’ultimo è un ragazzo che si occupa di grafica ed è in stage lavorativo pressol’azienda. In particolare si è impegnato nell’adattare la grafica dell’applicazione allostile Wintech e nella scelta dei colori. Tutto ciò allo scopo di uniformare le interfaccedi Kronos allo stile dell’azienda e degli altri applicativi già esistenti.

All’inizio di ogni sprint, un’analisi ci permetteva di identificare le funzionalità dasviluppare durante l’incremento. In ogni sprint, quindi, risultava necessario suddividereil carico di sviluppo tra me e Mattia. All’inizio abbiamo pensato a due approccipossibili:

• uno studente avrebbe lavorato sul front-end e l’altro sul back-end ;

• entrambi avremmo lavorato full stack su funzionalità differenti.

Alla fine abbiamo adottato la seconda scelta. In questo modo ci saremmo occupati tuttie due completamente solo di alcune parti conoscendone a fondo i dettagli. Saremmoinoltre venuti a conoscenza di tutte le tecnologie, sia di back-end che di front-end, chel’azienda adotta nella realizzazione delle sue applicazioni, nell’ottica di una possibileassunzione futura. Nella sottosezione 3.4.2, riguardante l’analisi, indico esplicitamentedi quali funzionalità dell’applicazione mi sono occupata nella realizzazione del progetto.

21

22 CAPITOLO 3. SVOLGIMENTO DELLO STAGE

3.2 Tecnologie adottate

La seguente figura illustra la collocazione delle tecnologie che ho adottato nell’ar-chitettura di Kronos e che descrivo nelle sotto-sezioni successive.

figura 3.1: Collocazione tecnologie nell’architettura di Kronos

3.2.1 Backend

Come ho già spiegato in 2.4.3, per la realizzazione del front-end ho utilizzato illinguaggio di programmazione Java su piattaforma tecnologica J2EE. Tra le estensionidi questa piattaforma ho utilizzato, nello specifico, JPA e JAX-RS.

JPA

Le Java Persistence API (JPA)1 sono un framework per il linguaggio di program-mazione Java che si occupa della gestione della persistenza dei dati di un DBMSrelazionale nelle applicazioni che usano le piattaforme Java Platform, Standard Editione Java Enterprise Edition. La persistenza, in questo contesto, copre tre aree:

• le API stesse, definite nel package javax.persistence;

1http://docs.oracle.com/javaee/6/tutorial/doc/bnbpz.html

http://docs.oracle.com/javaee/6/tutorial/doc/bnbpz.html

3.2. TECNOLOGIE ADOTTATE 23

• il linguaggio Java Persistance Query Language (JPQL);

• la mappatura tra lo schema relazionale della base dati e le Entity: classi annotateche rappresentano oggetti della base dati. Tale mappatura viene descritta anchecon il termine di object-relational mapping.

La seguente immagine illustra l’architettura di classi e interfacce nel packagejavax.persistence.

figura 3.2: Architettura delle classi di JPA

Fonte:http://www.tutorialspoint.com/jpa/images/jpa_class_level_architecture.png

Classe DescrizioneEntityManagerFactory Si tratta di una classe factory di EntityManger. Crea e gestisce

istanze multiple di EntityManager.EntityManager Interfaccia che gestisce le operazioni di persistenza sugli oggetti.

Lavora come una factory per l’istanza di Query.Entity Le entità sono oggetti persistiti, salvati come record nel database.EntityTransaction Ha una relazione uno-a-uno con EntityManager. Per ogni

EntityManager, le operazioni sono mantenute dalla classeEntityTransaction.

Persistence Questa classe contiene i metodi statici per ottenere l’istanza diEntityManagerFactory.

Query Questa interfaccia viene implementata per ottenere gli oggettirelazionali che soddisfano i criteri.

tabella 3.1: Classi e interfacce in javax.persistence

http://www.tutorialspoint.com/jpa/images/jpa_class_level_architecture.png


JPQL

Il Java Persistence Query Language (JPQL)2 definisce query per le entità. Per-mette di definire query portabili che funzionano indipendentemente dall’archivio datisottostante. Utilizza un linguaggio SQL-like per selezionare oggetti o valori.

JAX-RS

JAX-RS3 è una API Java disegnata per semplificare lo sviluppo di applicazionibasate sull’architettura Representational State Transfer (REST). Usa annotazioni dellinguaggio Java per facilitare lo sviluppo di servizi web RESLful. Gli sviluppatoriaggiungono tali annotazioni alle proprie classi per definire le risorse e le azioni chepossono essere eseguite su queste risorse. La seguente tabella contiene una lista dialcune delle annotazioni possibili con una breve descrizione.

Annotazione Descrizione@PATH Specifica il path relativo per una risorsa o un metodo.@GET@PUT@POST@DELETE@HEAD

Specificano il tipo di richiesta HTTP di una risorsa.

@Produces Specifica i MIME media types di rappresentazione che una risorsapuò produrre e restituire al client.

@Consumes Specifica i MIME media types di rappresentazione che una risorsapuò consumare in quanto inviati dal client.

@PathParam Esegue il binding tra il parametro del path e quello del metodo.@QueryParam Esegue il binding tra il parametro della query string e quello del

metodo.tabella 3.2: Alcune delle annotazioni JAX-RS

Hibernate

Hibernate4 è una piattaforma open source per lo sviluppo di applicazioni Java chefornisce un servizio di object-relational mapping (ORM). Gestisce, cioè, la persistenzadei dati sul database attraverso la rappresentazione e il mantenimento su databaserelazionale di un sistema di oggetti Java. In aggiunta, fornisce un’implementazioneper la specifica di JPA. In questo modo può essere utilizzato in qualsiasi ambiente chesupporta JPA, come nel caso di Kronos.

Jersey

Jersey5 RESTful Web Services è un framework open source per sviluppare serviziweb RESLful. Fornisce supporto alle API JAX-RS e delle API che estendono quelle diJAX-RS con nuove funzionalità per sviluppare servizi RESTful ancora più facilmente.

2http://docs.oracle.com/javaee/6/tutorial/doc/bnbtg.html3http://docs.oracle.com/javaee/6/tutorial/doc/giepu.html4http://hibernate.org/5https://jersey.java.net/

http://docs.oracle.com/javaee/6/tutorial/doc/bnbtg.html

http://docs.oracle.com/javaee/6/tutorial/doc/giepu.html

http://hibernate.org/

https://jersey.java.net/


Jackson

Jackson è una libreria basata su Java per serializzare oggetti Java in JSON eviceversa.

3.2.2 Frontend

Per il front-end ho utilizzato il framework AngularJS. Di seguito illustro le altretecnologie adottate.

Bootstrap

Bootstrap6 è un framework libero di front-end per uno sviluppo web facile e veloce.Include template HTML e CSS per form, pulsanti, tabelle, modali, e molto altro, cosìcome JavaScript plugins. Bootstrap permette inoltre di creare facilmente un designresponsive.

FullCalendar

FullCalendar7 è un plugin jQuery drag-and-drop per visualizzare eventi in uncalendario; è inoltre personalizzabile e open source. Abbiamo utilizzato FullCalendarper creare l’interfaccia principale di Kronos attraverso la quale ogni utente può inseriree visualizzare le sue voci di consuntivazione.

JQuery

jQuery8 è una libreria JavaScript per la manipolazione di pagine web e la gestionedi eventi. Abbiamo deciso di utilizzarlo anche in seguito all’adozione di FullCalendar.

SemanticUI

SemanticUI9 è un framework di sviluppo che aiuta a creare layout responsiveutilizzando l’HTML.

In Kronos ho deciso di utilizzare questa libreria, in particolare il modulo Dropdown,per la creazione dei menu nel modale di inserimento e dettaglio di una voce di consun-tivazione. Necessitavo, infatti, di creare velocemente un dropdown che contenesse: dueelenchi provenienti dalla chiamata a API di back-end diverse, una barra di ricerca trale voci e che, allo stesso tempo, non fosse editabile. Ho trovato, quindi, in tale librerial’elemento adatto.

6http://getbootstrap.com/7https://fullcalendar.io/8https://jquery.com/9http://semantic-ui.com/

http://getbootstrap.com/

https://fullcalendar.io/

https://jquery.com/

http://semantic-ui.com/


figura 3.3: Dropdown di SemanticUI

Fonte: http://semantic-ui.com/modules/dropdown.html

La figura mostra il dropdown che, dopo qualche personalizzazione, ho incluso nelprogetto.

UI Bootstrap

UI Bootstrap10 è un insieme di componenti Bootstrap scritti in AngularJS purodal team di AngularUI11. Ho avuto necessità di utilizzare questa libreria per la crea-zione di date e time pickers nel modale di inserimento e di dettaglio di una voce diconsuntivazione. In particolare ho utilizzato i moduli Datepicker Popup e Timepicker.

Le figure sottostanti illustarano il datepicker e il timepicker che, dopo le necessariepersonalizzazioni, ho utilizzato in Kronos.

figura 3.4: Datepicker di UI Bootstrap

Fonte: https://angular-ui.github.io/bootstrap/

10https://angular-ui.github.io/bootstrap/11https://angular-ui.github.io/

http://semantic-ui.com/modules/dropdown.html

https://angular-ui.github.io/bootstrap/


https://angular-ui.github.io/


figura 3.5: Timepicker di UI Bootstrap

Fonte: https://angular-ui.github.io/bootstrap/

3.2.3 Strumenti e tecnologie di supporto

Gulp

Gulp12 è uno strumento che ho impiegato per automatizzare alcune operazioni(task) relative alla verifica e alla realizzazione di software.

Webpack

figura 3.6: Webpack module bundler

Fonte: http://webpack.github.io/assets/what-is-webpack.png

Webpack13 è una module bundler. In pratica si occupa di trasformare i moduli conle dipendenze e generare risorse statiche che rappresentano quei moduli.

npm

Per gestire le dipendenze del servizio di front-end, ossia l’insieme delle librerie sucui è basato l’applicativo, ho utilizzato npm14.

12http://gulpjs.com/13https://webpack.github.io/14https://www.npmjs.com/


http://webpack.github.io/assets/what-is-webpack.png

http://gulpjs.com/

https://webpack.github.io/

https://www.npmjs.com/


3.3 Pianificazione

figura 3.7: Metodologia Agile

Fonte: https://leantesting-wp.s3.amazonaws.com/resources/wp-content/uploads/2014/04/agilenewera.png

Come modello per la gestione del progetto ho adottato l’Agile. All’arrivo in aziendaalcuni requisiti risultavano già abbozzati, tuttavia, era necessario scomporli, analizzarliulteriormente e approfondirli. Tale modello mi ha permesso di adottare una certaflessibilità e velocità nel rispondere alle esigenze di Wintech riguardo all’applicazioneKronos.

Il modello Agile prevede iterazioni continue, della durata massima di due settimane,entro le quali si susseguono attività di:

• analisi dei requisiti che emergono dall’interazione con il cliente, in questo casoWintech SpA;

• pianificazione delle funzionalità da includere nello sprint, suddivisione in taske loro assegnazione ai membri del team;

• progettazione delle funzionalità da implementare nell’iterazione corrente;

• codifica e sviluppo delle funzionalità previste;

• rilascio;

• monitoraggio continuo e verifica dello stato dell’applicazione.

Il punto di partenza di ogni ciclo è il risultato raggiunto con il precedente e il feedbackricevuto tramite la presentazione della soluzione raggiunta fin’ora agli stakeholder.

https://leantesting-wp.s3.amazonaws.com/resources/wp-content/uploads/2014/04/agilenewera.png

https://leantesting-wp.s3.amazonaws.com/resources/wp-content/uploads/2014/04/agilenewera.png

3.3. PIANIFICAZIONE 29

figura 3.8: Attività previste dalla metodologia Agile

Fonte:https://d2myx53yhj7u4b.cloudfront.net/sites/default/files/agile-lifecycle.png

All’inizio di ogni ciclo, individuate le attività da svolgere, il Product Owner sioccupava di creare il nuovo sprint su Jira e i task da includervi. A questo punto io el’altro stagista prendevamo in carico i contenuti del backlog, come stabilito con il tutor,in modo tale da portare a termine l’incremento previsto per l’applicazione nel ciclocorrente.

Pianificazione di stage

La tabella seguente illustra la pianificazione iniziale per la realizzazione del progettodi stage.

Attività Descrizione dell’attività Ore previste1 Studio delle tecnologie e introduzione agli

strumenti di sviluppo24

1.1 Studio tecnologie e prodotti utilizzati 51.2 Predisposizione ambienti di sviluppo 81.3 Introduzione ai sistemi di Continuous Integration 81.4 Introduzione al progetto 3

2 Analisi della soluzione 322.1 User discovery, problem scenario, value proposition 102.2 Esperimenti 82.3 Analisi tecnica 14

3 Progettazione architetturale 483.1 Interfaccia grafica 83.2 Gestione attività 103.3 Ricerca 63.4 Sistemi di notifica 7

https://d2myx53yhj7u4b.cloudfront.net/sites/default/files/agile-lifecycle.png


Attività Descrizione dell’attività Ore previste3.5 Reportistica per team 83.6 Amministrazione 9

4 Progettazione di dettaglio e implementazione 1844.1 Interfaccia grafica 344.2 Gestione attività 354.3 Ricerca 204.4 Sistemi di notifica 304.5 Reportistica per team 354.6 Amministrazione 30

5 Coordinamento e tutoraggio 32

Totale 320tabella 3.3: Pianificazione delle attività e delle ore di lavoro

3.4 Analisi

3.4.1 Modello utilizzato

Il template che ho utilizzato per la produzione del documento di analisi è basatosul Venture Design15.

“Venture Design focuses you on the right things at the right time, leve-raging the best of what’s out there in modern practices like design thinking,Lean Startup and agile.”

Il Venture Design aiuta a focalizzarsi sulle cose giuste al momento giusto, sfruttando ilmeglio di Design Thinking, Lean Startup e Agile.

15http://www.alexandercowan.com/venture-design/

http://www.alexandercowan.com/venture-design/

3.4. ANALISI 31

figura 3.9: Sezioni che compongono il documento di analisi secondo il Venture Design

Fonte: http://141nh047iozd1l75s22eer06.wpengine.netdna-cdn.com/wp-content/uploads/2016/09/ProcessDiagramForward.svg

Di tutte le sezioni che comporrebbero il documento ho preso in considerazione, escritto, le seguenti:

• Personas: questa sezione contiene una descrizione degli utenti finali dell’appli-cazione. Si tratta di una fase fondamentale dello sviluppo software in quanto,prima di iniziare a sviluppare, è necessario avere un’idea chiara su chi sono gliutilizzatori finali dell’applicazione e sui loro bisogni;

• Problem scenarios and alternatives: questa sezione specifica i problemi chesiamo andati a risolvere per l’utente, le alternative presenti e le proposte dirisoluzione;

• Customer discovery and experiments: questa sezione contiene le intervistefatte agli utenti, con domande e risposte ricevute;

• User stories and prototypes: questa sezione contiene le user story raccolte ededotte dalle interviste.

Per il momento abbiamo individuato quattro potenziali utilizzatori della nuovaapplicazione Kronos:

• Tommaso: il tecnico;

• Pietro: il Project Manager;

• Barbara: il BU Manager;

http://141nh047iozd1l75s22eer06.wpengine.netdna-cdn.com/wp-content/uploads/2016/09/ProcessDiagramForward.svg

http://141nh047iozd1l75s22eer06.wpengine.netdna-cdn.com/wp-content/uploads/2016/09/ProcessDiagramForward.svg


• Andrea: l’amministratore dei Sistemi Informativi.

Nella realizzazione, ai fini dello stage, abbiamo implementato le funzionalità necessarieai primi due. Riporto di seguito le loro descrizioni.

Tommaso: il tecnico

Si tratta dell’utente base della piattaforma. In azienda si identifica con i dipendential più basso livello della gerarchia che accedono esclusivamente per creare voci diconsuntivazione relative alle attività svolte durante la giornata. La tabella seguenteriassume i pareri raccolti dall’intervista.

Think Tommaso trova utile la visualizzazione a calendario dell’attuale sistema.Pensa invece che il processo di inserimento di un’attività dovrebbe esserepiù semplice, magari integrato nel resto del sistema aziendale e chesia in grado di gestire certi tipi di attività in autonomia, con menointerventi manuali. Pensa che il sistema di ricerca delle attività possaessere migliorato.

Sees Vede che altri sistemi di consuntivazione sono utilizzabili da dispositivimobile e in generale richiedono molti meno input. Traccia le sue attivitàpersonali con Google Calendar.

Feels Tommaso diventa ansioso nel fare la consuntivazione in quanto si sentedi dover giustificare le proprie attività all’azienda, come se il suo operatopassasse inosservato. Inoltre quando è in ritardo sulle giornate questo ècausa di particolare ansia in quanto sa che è un’attività che dovrebbe avergià fatto e il farlo in ritardo lo rende più complesso; questo lo fa sentirein colpa in quanto gli fa perdere più tempo del dovuto. Visivamenteapprezza la visualizzazione a calendario e lo aiuta a vedere la giornata“completata” (tutte le 8 ore coperte).

Does Inserisce circa 20 attività alla settimana, spendendo in media due orenel sistema. Ogni attività mediamente richiede l’immissione del 50% deicampi disponibili.tabella 3.4: Tabella riassuntiva dei pensieri di Tommaso: il tecnico

Pietro: il Project Manager

L’utente Project Manager è colui che di fatto si occupa della gesione di progetto inazienda e accede all’applicazione, oltre che per consuntivare le proprie attività, ancheper visualizzare la situazione dei progetti che segue, generare i report e controllare lostato di consuntivazione dei membri dei team. La tabella seguente riassume i pareriraccolti dalle interviste.

Think Pietro pensa che la reportistica dovrebbe essere disponibile in qualsiasimomento al più alto livello di dettaglio possibile (singole attività, sotto-attività, milestone e obiettivi). Dovrebbe inoltre essere possibile estrarrei dati a diversi livelli di dettaglio in base al soggetto a cui devono esserepresentati.

Sees Ha visto che in altre realtà, suoi ex colleghi, avevano a disposizione delleliste di feedback aggiornate in modo da avere sempre una visione globale.

3.5. PROGETTAZIONE 33

Feels E’ infastidito dal tempo che impiega nel sistema di consuntivazione eteme di fare errori perché il processo è totalmente manuale.

Does Pietro dedica 1 ora per ogni progetto ogni 2 settimane e si vede costrettoad aspettare anche più di un’intera giornata per le estrazioni che richiedeal BU Manager.

tabella 3.5: Tabella riassuntiva dei pensieri di Pietro: il Project Manager

Una volta individuati i possibili utilizzatori di Kronos e le problematiche da lororilevate, abbiamo scritto le user story e le abbiamo inserite su Jira con una numerazionecosì composta: KRON-X dove KRON è l’abbreviazione del nome del progetto e X èun numero crescente. Ad eccezione dell’individuazione degli utenti che abbiamo svoltosolo all’inizio, la fase di definizione delle problematiche e quindi delle user story siripeteva all’inizio di ogni sprint.

3.4.2 Suddivisione del lavoro tra i membri del team

All’inizio di ogni sprint, dopo una fase preliminare di analisi in cui emergevano leuser story, il tutor aziendale assegnava a me e Mattia le funzionalità che dovevamoimplementare. Io mi sono occupata principalmente delle seguenti:

• inserimento di una nuova voce di consuntivazione in Kronos;

• modifica di una voce già esistente;

• notifica agli utenti sullo stato di consuntivazione della settimana;

• sicurezza all’accesso dell’applicazione.

Nell’eseguire i task ho dovuto prestare particolare attenzione all’integrazione con ildatabase già esistente dell’applicazione GeCo.

3.5 Progettazione

3.5.1 Architettura generale del sistema

L’architettura generale di Kronos è molto semplice: è costituita da un front-end eda un back-end. Quest’ultimo fornisce una serie di API REST per l’accesso alle risorsedell’applicazione che il primo consuma attraverso le richieste HTTP di AngularJs.

Due database separati, poi, si occupano di mantenere la persistenza dei dati. Unol’ho creato appositamente per Kronos e viene utilizzato per salvare dati che servonoa funzionalità che non erano previste in GeCo. L’altro database, invece, è proprio diGeCo e abbiamo dovuto integrare Kronos con esso.

La figura che segue costituisce uno schema generale ad alto livello dell’architetturadell’applicazione.


figura 3.10: Architettura generale di Kronos

3.5.2 Comunicazione tra back-end e front-end

La comunicazione tra il back-end e il front-end avviene tramite un insieme di API cheil primo mette a disposizione del secondo seguendo i principi REST (REpresentationalState Transfer). Questi principi prescrivono che lo stato in un’applicazione e le suefunzionalità siano interpretati come risorse web univoche e accessibili tramite un URLe, di solito, un protocollo HTTP.

L’approccio architetturale REST è definito dai seguenti vincoli applicati ad un’ar-chitettura:

• Client-server: un insieme di interfacce uniformi separa il client dal server inmodo da ridurre l’accoppiamento tra le componenti del sistema. In questo modo,ad esempio, il client non deve occuparsi della persistenza dei dati e il serverdell’interfaccia grafica;

• Stateless: la comunicazione client–server è ulteriormente vincolata in modoche nessun contesto client venga memorizzato sul server tra le richieste. Ognirichiesta da ogni client contiene tutte le informazioni necessarie per richiedere ilservizio, e lo stato della sessione è contenuto sul client;

• Cacheable: i client possono fare caching delle risposte. Le risposte devono inogni modo definirsi implicitamente o esplicitamente cacheable o no, in modo daprevenire che i client possano riusare stati vecchi o dati errati;

• Layered system: i client non sono tenuti a conoscere quale livello del sistemaserver stanno interrogando;


figura 3.11: Comunicazione tra back-end e front-end

Ho scelto questa architettura nella realizzazione di Kronos in quanto, oltre ad esseremolto diffusa nelle applicazioni web, è semplice e riduce notevolmente l’accoppiamentotra client e server. Non è escluso che un giorno, in un’ottica di rivendibilità del prodotto,Wintech utilizzi lo stesso back-end e vi applichi un nuovo front-end per rispondere alleesigenze del cliente o che altre applicazioni vogliano utilizzare servizi di back-end diKronos.

Gestione delle risorse

Innanzitutto ho individuato le risorse e le azioni che si possono eseguire su di esse.Basando le API REST sul protocollo HTTP ho identificato le seguenti categorie diazioni possibili:

• GET: ottiene une risorsa specifica;

• POST: crea una nuova risorsa a partire dai dati inviati assieme alla richiesta;

• PUT: modifica una risorsa già esistente tramite i dati allegati alla richiesta.

Gli altri tipi di operazioni, come DELETE, per gli scopi del progetto non erano necessari.Allo stesso tempo si sono verificati casi in cui non tutte le operazioni sono previste pertutti i tipi di risorse.

Le risposte alle richieste sono codificate secondo il formato JSON. Tale scelta èdovuta alla semplicità di decodifica e risulta meno prolisso rispetto a XML.

Gestione degli errori

In ottica REST è importante fornire messaggi semplici e comprensibili in caso dierrore. Ho adottato quindi i codici di errore del protocollo HTTP e la loro semantica.In particolare, quelli utilizzati su Kronos sono i seguenti:

• 400 - Bad Request: la richiesta non può essere soddisfatta a causa di sintassierrata;

• 401 - Unauthorized: l’utente non autenticato sta cercando di accedere ad unarisorsa riservata ai soli utenti autenticati;

• 403 - Forbidden: l’utente autenticato sta tentando di accedere ad una risorsasenza i permessi necessari;


• 404 - Not found: l’utente sta richiedendo una risorsa inesistente;

• 500 - Internal Server Error: errore generico lanciato dal server.

Nel caso invece in cui la richiesta vada a buon fine il codice utilizzato è 200 - OK e201 - Created in caso di creazione di una nuova risorsa.

3.5.3 Progettazione di dettaglio

In questa sezione riporto i diagrammi dei componenti che ho individuato per ilback-end e il front-end durante lo sviluppo di Kronos. È da notare che, avendo adottatoil modello di sviluppo Agile, la struttura ha subito parecchie variazioni durante larealizzazione delle funzionalità necessarie. I diagrammi in questa sezione riportanol’architettura finale.

Backend

Il back-end presenta la struttura dei package schematizzata nella figura sottostante.

figura 3.12: Diagramma del back-end

model

Il package model contiene tutte le classi java che modellano le entità persistite neidatabase.

Per la gestione degli eventi, corrispondenti a voci di consuntivazione, il databaseGeCo utilizza due entità: CalEvent e GecoActivity. Quando Kronos salva unanuova voce di consuntivazione, o una sua modifica, deve manipolare entrambe le tabelle.

Per gestire l’inserimento di nuovi eventi, Kronos deve sapere quale id assegnargli.Ho notato che il database GeCo contiene in GecoId l’ultimo Id salvato su ogni tabella.Kronos quindi va a leggere tale tabella, incrementa di un’unità l’Id, lo assegna al nuovoevento, e aggiorna GecoId.


La classe User rappresenta l’entità relativa all’utente salvata sul database di GeCo.Attualmente quindi, gli utenti abilitati ad accedere alla piattaforma sono gli stessi cheutilizzano GeCo.

Le classi GecoCalendar, GecoCustomer, GecoProject, GecoWbs, GecoU-serGruppo e GecoTipoOperazione sono anch’esse classi che rappresentano entitàdi GeCo e vengono utilizzate da Kronos, per il momento, a solo scopo di lettura.

Infine le classi UserSelectProject e UserSelectCustomer rappresentano entitàpersistite nel database Kronos e vengono utilizzate per salvare le selezioni recenti diun utente su progetti e clienti. Maggiori dettagli su queste classi si trovano in 3.5.3.

rest::api

Il package rest::api contiene l’insieme di API che il back-end mette a disposizionedel front-end.

Le due API di maggiore importanza all’interno dell’applicazione sono le seguenti:

• Inserimento di un nuovo evento

– URI: /events

– Metodo: POST

– Content-Type: application/json

– Descrizione: inserimento di un nuovo evento (voce di consuntivazione)

– Input: come parametro deve essere passato un JSON avente la seguenteforma:{“eventType”: eventType,“title”: title,“sede”: sede,“state”: state,“start”: start,“end”: end,“hours”: hours,“customerID”: customerId,“projectId”: projectId,“activityId”: activityId,“functionString”: functionString}

– Output: una risposta HTTP contenente lo stato dell’operazione

• Recupero degli eventi di un utente

– URI: /events

– Metodo: GET

– Content-Type: application/json

– Descrizione: recupero di tutte le voci di consuntivazione associate ad unutente

– Output: viene ritornato un JSON contenente tutte le consuntivazioniassociate ad un utente


rest::data

Il package rest::data contiene le classi Java che rappresentano il concetto di evento evoce di WBS all’interno di Kronos. Contengono tutti i campi necessari alla persistenzanel database delle voci di consuntivazione e di WBS associate ad un progetto.

dao

Il package dao contiene tutte le classi necessarie a separare l’accesso ai dati persistitinel database dalle operazioni di alto livello. Per ogni classe del package model èpresente:

• un’interfaccia DAO, che definisce le operazioni standard da eseguire su undeterminato oggetto;

• un’implementazione di tale interfaccia che è responsabile di eseguire operazionisui dati persistiti nel database.

service

Il package service contiene le classi di servizio i cui metodi vengono richiamati dalleAPI per eseguire operazioni sui database. Contiene un’interfaccia sevice, che definiscele operazioni possibili, e una sua implementazione per ogni classe presente nel packagemodel.

Database GeCo

Come ho già detto precedentemente l’azienda utilizza, ad oggi, GeCo come sistemadi consuntivazione. Esso ha un proprio database sul quale salva i dati e che è accessibilead altre applicazioni. Era dunque necessario che anche Kronos si integrasse con questodatabase. In un futuro infatti, se GeCo venisse completamente rimpiazzato da Kronos,i suoi dati sarebbero ancora accessibili e tutte le altre applicazioni ad esso collegatefunzionerebbero ancora correttamente.

Per il momento Kronos lo utilizza per svolgere operazioni di inserimento e modificadi consuntivazioni, lettura di tutte le consuntivazioni di un utente per visualizzarlenel suo calendario, recupero degli elenchi di clienti, progetti e voci di WBS su cuiconsuntivare.

Database Kronos

A Kronos, per adempiere ai suoi obiettivi, non e sufficiente l’integrazione con ildatabase GeCo. Esso infatti offre, e ne offrirà ancora di più in futuro, funzionalitànuove che l’applicazione precedente non possedeva. In particolare, per facilitare laconsuntivazione, vengono presentati agli utenti i 5 progetti e clienti selezionati piùrecentemente in modo tale che non debba cercarli ogni volta nell’elenco totale. A talfine ho creato un nuovo database SQL Kronos predisposto a raccogliere le informazioninecessarie a realizzare queste funzionalità.

La figura sottostante mostra la struttura del database di Kronos.


figura 3.13: Database di Kronos

Come si può evincere dalla figura il database di Kronos è costituito da due tabelle:

• UserSelectProject: tiene traccia delle selezioni di un utente su un progettosalvando userId e projectId, che sono gli Id di utente e progetto sul database diGeco, e la data di selezione;

• UserSelectCustomer: tiene traccia delle selezioni di un utente su un clientesalvando userId e customerId, che sono gli Id di utente e cliente sul database diGeco, e la data di selezione.


Frontend

figura 3.14: Diagramma del front-end

Il front-end di Kronos contiene i seguenti componenti:

• Main: è la classe che contiene la configurazione dell’applicazione. Utilizza ilservizio $route-Provider per associare ad ogni route un controller e una view.Viene utilizzata per associare un URL alle varie view dell’applicazione;

• Index: è la view generale dell’applicazione. Contiene gli elementi che sarannopresenti in ogni pagina dell’applicazione;

• Controller: package contenente i controllers front-end dell’applicazione;

• Directive: package contenente le direttive front-end dell’applicazione;

• ViewModel: package contenente le classi che saranno presenti nella variabiled’ambiente $scope di Angular che permettono il Two-Way Data-Binding tra leviews e i controllers;

3.6. REALIZZAZIONE DELLE FUNZIONALITÀ 41

• Service: package contenente i services front-end dell’applicazione;

• View: package contenente le views front-end dell’applicazione.

3.6 Realizzazione delle funzionalità

Di seguito riporto alcuni dettagli riguardanti lo sviluppo delle funzionalità di cuimi sono occupata.

L’immagine mostra la schermata principale di Kronos, il calendario. A partireda questa vista si articolano le funzionalità che ho realizzato e che descrivo nellesotto-sezioni successive.

figura 3.15: Vista a calendario di Kronos

3.6.1 Inserimento e modifica di una voce di consuntivazione

Inserimento

L’utente utilizza l’applicativo Kronos per consuntivare le ore lavorative che sarannopoi utilizzate per generare i rapportini ai clienti. Il calendario, quindi, offre la possibilitàdi trascinare con il cursore del mouse da un’ora ad un’altra in modo da stabilire ladurata dell’evento da inserire. Per realizzare questa funzionalità ho creato una direttivaevent con un template che viene visualizzato al trascinamento sul calendario. Taledirettiva fa comparire un modale che permette all’utente di inserire tutti i campinecessari alla creazione di una voce di consuntivazione. La figura sottostante mostral’interfaccia del modale.


figura 3.16: Modale di inserimento su Kronos

Alcuni campi presentano dei valori di default per facilitare l’utente nell’inserimento,inoltre, il campo cliente viene auto-calcolato una volta scelto il progetto di interesse.

Per quanto riguarda la parte di back-end ho definito una API apposita, già descrittain 3.5.3, che si occupa di effettuare l’inserimento nel database GeCo.

Tutti i campi del form sono opportunamente validati in modo tale che a back-endvengano passati solo dati nel formato corretto.

Modifica

Vi è inoltre la possibilità che un utente voglia modificare una voce già inserita.Per fare questo è possibile cliccare su un evento del calendario per aprire il modale didettaglio.

In questo caso ho riutilizzato la direttiva event popolando però i campi con i datidell’evento. L’utente può quindi effettuare le modifiche e salvare.

A back-end ho realizzato un’opportuna API che si occupa di fare l’update dell’evento.Segue la sua descrizione:

• URI: /events

• Metodo: PUT

• Content-Type: application/json

• Descrizione: modifica di un evento (voce di consuntivazione)

• Input: come parametro deve essere passato un JSON avente la seguente forma:{“id”: id,“eventType”: eventType,“title”: title,“sede”: sede,“state”: state,

3.6. REALIZZAZIONE DELLE FUNZIONALITÀ 43

“start”: start,“end”: end,“hours”: hours,“customerID”: customerId,“projectId”: projectId,“activityId”: activityId,“functionString”: functionString}

• Output: una risposta HTTP contenente lo stato dell’operazione

Anche qui tutti i campi sono opportunamente validati in modo tale da passare alback-end solo dati in formato corretto.

3.6.2 Feedback all’utente sullo stato di consuntivazione

GeCo non mostra alcun feedback all’utente sullo stato di consuntivazione dellasettimana. Un dipendente, per controllare se ha consuntivato correttamente la giornatainserendo tutte le 8 ore lavorative, deve aprire i dettagli di ogni evento e fare la sommadelle ore inserite manualmente. Come team abbiamo pensato che sarebbe stato utileche Kronos avvisasse in qualche modo l’utente sullo stato della giornata.

A tale scopo ho pensato di inserire, per ogni giornata nel calendario, un bordocolorato che desse il feedback necessario. Come si vede in figura 3.15 il bordo diventa:

• giallo se il numero di ore consuntivate supera le 8;

• rosso se l’utente non ha ancora consuntivato tutte le ore della giornata;

• rimane invece blu se la giornata è consuntivata correttamente.

Per fare questo ho realizzato a back-end una API così formata:

• URI: /events/{startWeek}/{endWeek}

• Metodo: GET

• Content-Type: application/json

• Descrizione: restituisce, per ogni giorno della settimana passata come parame-tro, il numero di ore consuntivate da un particolare utente

• Input: come parametro devono essere passate la data di inizio e fine dellasettimana visualizzata sul calendario

• Output: viene restituito un JSON contenente, per ogni giorno della settimanapassata come parametro, il numero di ore consuntivate dall’utente

A front-end invece ho realizzato un servizio (WeekStateService) che si occupadi colorare il bordo del calendario di ogni giornata a seconda dello stato dellaconsuntivazione.

3.6.3 Gestione della sicurezza

Per implementare la sicurezza all’accesso delle risorse dell’applicazione ho utilizzatola Form-Based Authentication di J2EE.


figura 3.17: Form-Based Authentication di J2EE.

Fonte: http://docs.oracle.com/javaee/6/tutorial/doc/figures/security-formBasedLogin.gif

Quando un client richiede una risorsa protetta, il server lo redirige alla pagina dilogin. Un form, dopo che l’utente ha inserito le sue credenziali, fa una chiamata http aj_security_check la quale, in caso di successo, permette l’accesso alla risorsa.

Ho inserito quindi nel file web.xml tutte le configurazioni necessarie a questo tipodi autenticazione e nella configurazione del server gli utenti e i ruoli ad essi associati.

Gli accessi alle risorse sono controllati attraverso apposite annotazioni che indicanoa quali ruoli è consentito l’accesso. All’interno delle API le informazioni sull’utenteautenticato sono accessibili attraverso il SecurityContext 16.

3.7 Qualità del prodotto realizzato

Il poco tempo a disposizione e la metodologia Agile adottata per lo svolgimentodel progetto, purtroppo, non hanno influito positivamente sulla qualità del prodottosviluppato. D’accordo con il tutor aziendale, e come team, abbiamo deciso di darepriorità alla realizzazione delle funzionalità. Nonostante ciò abbiamo cercato di mante-ner una buona qualità generale del prodotto. Per quanto riguarda il codice prodottoho adottato delle metriche specifiche.

3.7.1 Metriche adottate

Totale linee di codice

Al fine di dare un’idea delle dimensioni finali del progetto, riporto il numero totaledi righe di codice.

16https://docs.oracle.com/javaee/7/api/javax/ws/rs/core/SecurityContext.html

http://docs.oracle.com/javaee/6/tutorial/doc/figures/security-formBasedLogin.gif

http://docs.oracle.com/javaee/6/tutorial/doc/figures/security-formBasedLogin.gif

https://docs.oracle.com/javaee/7/api/javax/ws/rs/core/SecurityContext.html

3.7. QUALITÀ DEL PRODOTTO REALIZZATO 45

Numero medio di linee di codice per file

Media delle SLOC (source lines of code, linee di codice sorgente in inglese), unametrica che influisce nella complessità e nel mantenimento del software. Il valoremassimo entro il quale ho stabilito di rimanere è 120.

Indice di manutenibilità

Si tratta di un valore da 0 a 100 calcolato a partire dal numero di linee di codice,complessità ciclomatica e numero medio di operatori e operandi nelle funzioni. Riescea valutare bene la complessità del codice sorgente, fornendo indicazioni sulla suamanutenibilità. Il valore minimo entro il quale ho stabilito di rimanere è 70.

Copertura dei test

Numero percentuale che indica la porzione del codice sorgente per il quale ho scrittotest. Il valore minimo entro il quale ho stabilito di rimanere è 75%.

A causa del tempo limitato ho deciso di produrre test di unità e integrazione soloper il back-end , in quanto considerato il più importante e complesso. In questo modo,mi è stato possibile aumentare il numero di iterazioni di sviluppo e portare a terminelo sviluppo di un maggior numero di funzionalità.

3.7.2 RisultatiBackend

Metrica ValoreTotale SLOC 5739Media SLOC 106Manutenibilità 72,52Copertura dei test 80,16 %

tabella 3.6: Risultati dei test di qualità sul back-end

Fronted

Metrica ValoreTotale SLOC 3376Media SLOC 93Manutenibilità 74,03Copertura dei test N.D.

tabella 3.7: Risultati dei test di qualità sul front-end

Capitolo 4

Valutazione retrospettiva

Questo capitolo riporta una valutazione retrospettiva sull’attività di stage e sulla di-stanza tra il corso di studi e il mondo del lavoro.

4.1 Valutazione dello stage

4.1.1 Resoconto sugli obiettivi dell’aziendaL’attività di stage aveva come obiettivo la realizzazione di Kronos, un’applicazione

per la gestione della consuntivazione aziendale.Di seguito, in tabella, riporto le funzionalità che ho preso in carico e il risultato

ottenuto. Ho raggiunto gli obiettivi minimi indicati in 2.2.3 per ogni funzionalitàrealizzata.

Funzionalità RisultatoInserimento di una nuova voce di consuntivazione. RealizzataSegnalazione all’utente sullo stato di completamento dellaconsuntivazione della settimana.

Realizzata

Funzionalità di modifica di una voce di consuntivazione giàesistente.

Realizzata

Funzionalità di visualizzazione dei dettagli di una voce diconsuntivazione.

Realizzata

Sicurezza all’accesso dell’applicazione. Realizzatatabella 4.1: Funzionalità e risultati raggiunti

Di seguito ho riportato delle sotto-funzionalità che fanno parte delle funzionalità diinserimento e modifica di una voce di consuntivazione.

Funzionalità RisultatoNon tutti i campi devono essere inseriti manualmente ma alcunivengono preimpostati o determinati automaticamente dal sistema.

Realizzata

Presentazione delle soluzioni più recenti di progetto e cliente inmodo da velocizzare l’inserimento.

Realizzata

tabella 4.2: Funzionalità derivate e risultati raggiunti

47

48 CAPITOLO 4. VALUTAZIONE RETROSPETTIVA

Come ho esposto in 2.2, abbiamo realizzato Kronos a partire da una breve analisidi GeCo e delle problematiche rilevate dagli utenti nel suo utilizzo. Avrebbe dovutoinoltre includere delle funzionalità aggiuntive. Di seguito illustro se e come sono statirisolti i problemi di GeCo, esposti in 2.2.1, e le nuove funzionalità messe in pista.

Risoluzione delle problematiche di GeCo

• Form di Login: all’apertura l’applicazione attuale presenta un form di loginche va a costituire un’ulteriore autenticazione assieme alle altre per l’accessoalle applicazioni aziendali. Al momento tale problema risulta irrisolto e Kronosdispone, allo stesso modo, di un form di login. Verrà risolta la situazione quandola nuova applicazione sarà integrata nel portale e la login sarà unica per tutte leapplicazioni aziendali.

• Numero elevato di campi da completare: il numero di campi da completaresu GeCo per l’inserimento di una voce di consuntivazione è elevato. Ho risoltoparzialmente tale problema in questi modi:

– inserendo campi con valori di default;

– inserendo campi il cui valore viene calcolato automaticamente dall’applica-zione sulla base di altri inseriti precedentemente;

– presentando le selezioni più recenti all’utente che, in questo modo, non perdetempo a cercare progetti e clienti su cui ha lavorato recentemente e su cuista ancora lavorando.

Gli altri problemi di geco sono tutti legati alla natura della consuntivazione, un’at-tività che il dipendente è obbligato a fare ma da cui non trae alcun vantaggio. Questo,purtroppo, non si può cambiare tuttavia abbiamo cercato, come team, di costruireun’interfaccia utente il più semplice e intuitiva possibile. I campi a compilazioneautomatica aiutano a risparmiare tempo e a rendere la consuntivazione meno pesante.

Nuove funzionalità

Abbiamo deciso, inoltre, di aggiungere alcune funzionalità aggiuntive che non sonopresenti in GeCo attuale. Personalmente mi sono occupata delle seguenti:

• ho fatto in modo di visualizzare un feedback all’utente sullo stato della consun-tivazione di settimana in settimana. Questo gli permette di avere una visione im-mediata su dove è arrivato a consuntivare senza dover ricontrollare manualmente,giornata per giornata e attività per attività, il numero di ore inserite;

• alcuni campi non devono più essere inseriti manualmente in quanto l’applicazionepresenta già un valore di default che potrebbe essere non necessario cambiare.Altri, invece, sono determinati automaticamente sulla base di valori giàinseriti;

• le selezioni recenti sono di grande aiuto all’utente. Capita molto spesso chedebba consuntivare più volte sullo stesso progetto in quanto ci lavora per unperiodo di tempo più o meno breve. Tale funzionalità gli permette di recuperareil nome del progetto e del cliente velocemente, senza doverli cercare nell’elencocompleto.

4.2. VALUTAZIONE DELLA DISTANZA TRA LO STAGE E IL CORSO DI STUDI49

Risultati raggiunti complessivamente nel team

Complessivamente, considerando anche gli altri membri del team, abbiamo realizzatotutte le funzionalità previste dalle user story che abbiamo definito. Siamo riusciti,in questo modo, a costruire un’applicazione completa e pronta per essere utilizzatadai dipendenti della business unit Sviluppo Software in Wintech. Il prossimo passo,infatti, sarà la messa in produzione del software e il raccoglimento delle opinioni degliutenti. Infine, quando avrà raggiunto un buono stato di maturazione sarà integratacompletamente in WOW.

4.1.2 Resoconto sugli obiettivi personaliDi seguito riporto i risultati relativi agli obiettivi personali.

Obiettivo previsto RisultatoConoscenza della metodologia Scrum nello sviluppo software. RealizzatoAcquisizione delle competenze necessarie a sviluppare lefunzionalità richieste.

Realizzato

Conoscenza delle tecnologie necessarie allo svolgimento dello stage. RealizzatoPresa di coscienza di cosa significhi system integration dovendosviluppare un’applicazione che si deve integrare con il database diuna già esistente.

Realizzato

Avvicinamento all’idea di portale e di applicazioni in esso integrate. Parzialmenterealizzato

tabella 4.3: Obiettivi personali previsti e risultati raggiunti

Ho parzialmente realizzato l’obiettivo riguardante l’avvicinamento all’idea di portalein quanto pensavo che, durante lo stage, avrei visto il portale vero e proprio e avremmogià iniziato ad integrare Kronos in WOW. Tuttavia, il tutor aziendale mi ha guidatanel realizzare le funzionalità pensando sempre in ottica di un’applicazione che faràparte di qualcosa di più grande come il portale WOW e che si integrerà con altreapplicazioni che recupereranno dati da essa.

4.2 Valutazione della distanza tra lo stage e il corsodi studi

4.2.1 Valore aggiunto dallo stage

L’attività di stage è obbligatoria per il corso di laurea triennale. Trovo che l’ese-cuzione di uno stage prima della laurea porti un sensibile valore aggiunto al corso distudi e favorisca l’inserimento dello studente nel mondo del lavoro.

Per quanto mi riguarda, ho avuto modo di approfondire e comprendere meglio lametodologia Agile imparando come ci si organizza nel team secondo i suoi principi perla realizzazione di un progetto. Ho approfondito anche i principi guida di REST percreare e realizzare API in modo semplice e intuitivo.

Il corso impartisce tutte le conoscenze necessarie a capire questi concetti, tutta-via, solo dopo l’attività di stage, sono in grado di padroneggiarli completamente ecomprenderli fino in fondo.

50 CAPITOLO 4. VALUTAZIONE RETROSPETTIVA

Qualsiasi direzione voglia prendere lo studente dopo la laurea triennale, trovo che lostage sia una tappa importante se non addirittura essenziale. Nel caso voglia procederecon la laurea magistrale, il tirocinio permette di approfondire meglio concetti appresidurante il corso, conoscere a fondo alcune tra le tecnologie più diffuse e incontrareargomenti che verranno trattati poi nel corso magistrale. Se scelto bene fin da subito,costituisce un’occasione anche per lo studente che decide di non proseguire con gli studi.L’azienda, infatti, esprime già dai colloqui iniziali l’intenzione o meno di assumere unostudente al termine dello stage.

4.2.2 Competenze mancanti all’inizio dello stageMolte delle tecnologie che ho utilizzato mi erano sconosciute prima dell’inizio dello

stage. Sebbene il percorso universitario dia le nozioni di base per apprendere qualsiasitecnologia, ho dovuto impiegare del tempo per studiarle il modo tale da essere in gradodi utilizzarle come richiesto dal progetto svolto.

Di seguito riporto quelle che, secondo il mio punto di vista, sono le maggiori lacunedel corso di laurea in Informatica non solo in riferimento allo stage, ma anche a quelloche ho visto essere richiesto, in generale, nel mondo del lavoro in questo ambito:

• Linguaggi funzionali: durante la laurea triennale i linguaggi funzionali nonvengono nemmeno nominati. Vengono invece insegnati prevalentemente il lin-guaggio C++ e, solo al terzo anno, Java. Sarebbe interessante insegnare aglistudenti almeno uno dei linguaggi funzionali;

• Database: in ambito universitario vengono trattati solamente i database di tiporelazionale, ignorando totalmente i database NOSQL. Vista la loro diffusione e illoro utilizzo sempre maggiore, trovo utile che durante il corso vengano date lebasi anche per i database NOSQL;

• Web-application: nessun insegnamento della laurea triennale prevede lo svi-luppo di una web-application tramite l’utilizzo di un framework web. Inoltre illinguaggio JavaScript viene solamente nominato durante il corso di TecnologieWeb. Troverei utile che venisse trattato molto più approfonditamente Javascripte che venissero date le basi per AngularJs, sempre più utilizzato e diffuso;

• Design Pattern: a mio avviso lo studio dei design pattern non dovrebbe esseretutto concentrato nella seconda metà del terzo anno. Trovo che sarebbe utileintrodurne alcuni già durante il corso di Programmazione ad Oggetti in modo dasemplificare l’attività di progettazione richiesta dal progetto di Ingegneria delSoftware;

• Programmazione Mobile: ritengo che sarebbe interessante per gli studentiseguire, già alla triennale, un corso che dia le basi per la programmazione mobile;

• Attività di laboratorio: durante la triennale sono pochi i corsi che prevedonoattività di laboratorio. Sarebbe utile se la quantità di ore in laboratorio venissenon solo aumentata, ma anche gestita in modo migliore. Magari con lezioniguidate e con lo svolgimento di progetti che comprendano non solo i temi trattatinel corso di riferimento, ma che siano trasversali e che colleghino più insegnamenti.

Nonostante le lacune del corso, esso fornisce delle basi solide e metodologie peressere in grado di apprendere velocemente e facilmente qualsiasi tecnologia. Non mi èstato infatti difficile apprendere le tecnologie che ho utilizzato per realizzare il progetto

4.3. VALUTAZIONI PERSONALI 51

però, con qualche nozione in più o avendole già viste anche solo superficialmente, avreirisparmiato tempo procedendo più velocemente.

4.2.3 Progetti didatticiPer quanto riguarda la realizzazione di progetti trovo che il corso possa migliorare

principalmente per due motivazioni:

• solo il progetto di Ingegneria del Software permette agli studenti di lavorare conun gruppo consistente di persone;

• alcuni progetti sono per lo più di tipo one-off e forniscono una serie di cono-scenze che rischiano di rimanere isolate e non sono integrate con il resto degliinsegnamenti.

Ritengo, dunque, che ci dovrebbero essere più occasioni per gli studenti di collaborare agruppi e, allo stesso modo, che la realizzazione dei progetti proposti non siano finalizzatiad apprendere conoscenze solamente relative al corso ma dovrebbero dare la possibilitàdi integrare queste conoscenze con quelle di altri insegnamenti.

4.3 Valutazioni personaliPer concludere, sono stata in grado di realizzare tutte le funzionalità previste e,

considerando il team nel complesso, abbiamo sviluppato un’applicazione miglioratarispetto a quella che Wintech utilizza attualmente. Mi sono trovata molto benecon il gruppo e sono fiera del lavoro che abbiamo svolto. L’azienda mi ha propostoun contratto di stage al termine del tirocinio universitario e ho deciso di coglierel’occasione e di rimanere. Questo mi porterà a collaborare ancora nello sviluppo diKronos. Il prossimo grande passo consisterà nel portarlo in produzione e farlo utilizzareai dipendenti, inoltre, sono ancora molte le funzionalità che andremo a definire e asviluppare. Mi sento soddisfatta dell’esperienza, mi ha dato l’opportunità di entrarenel mondo del lavoro e confrontarmi con esso costituendo un’importante opportunitàdi crescita personale.

Glossario

API (Application Programming Interface) Con questo termine si indicano una o piùcomponenti software che offrono delle funzionalità, specificandone operazioni,input, output e tipi di queste. In questo modo, è più semplice realizzare unprodotto software facendo uso di questo insieme di strumenti di utilità. 19, 20,22, 24, 25, 33–35, 37, 38, 42–44, 49

Business Unit Le unità strategiche di business, aree strategiche d’affari, sono com-parti di un’impresa con mercati e strategie autonomi. Si tratta di segmentiprodotto-mercato fondamentali per l’impresa non solo a livello di marketing maanche a livello strategico (business). 1, 4, 49

Design Pattern Soluzione progettuale generale a un problema ricorrente. Una de-scrizione o un modello da applicare per risolvere un problema che può presentarsiin diverse situazioni durante la progettazione e lo sviluppo del software. 20

Design Thinking Si tratta di un moderno modello manageriale di gestione azienda-le, particolarmente adatto a trattare problemi complessi dall’esito incerto checomportano rischi decisionali. Adottandolo, i manager ampliano la gamma dirisorse culturali e metodologiche a loro disposizione, favorendo la possibilità dianalizzare i problemi anche con la visione creativa, tipica del design strategicoe introducendo preziosi strumenti di verifica delle soluzioni, prima che sianoimplementate. 30

Drag-and-drop Il drag-and-drop indica una successione di tre azioni, consistenti nelcliccare su un oggetto virtuale (quale una finestra o un’icona) per trascinarlo (ininglese: drag) in un’altra posizione, dove viene rilasciato (in inglese: drop). 25

Framework Un framework, in informatica e specificatamente nello sviluppo software,è un’architettura logica di supporto su cui un software può essere progettato erealizzato, spesso facilitandone lo sviluppo da parte del programmatore. 7, 11,20, 22, 24, 25, 50

Help Desk Servizio aziendale che fornisce informazioni ed assistenza a clienti e utenti,interni o esterni, che hanno problemi nella gestione di un prodotto o servizio. 2

JSON (JavaScript Object Notation) Standard usato per trasmettere dati tramite loscambio di oggetti nei quali le informazioni sono salvate in coppie chiave-valore.25, 35, 37, 42, 43

53

54 Glossario

Lean Startup Si tratta di un approccio radicale per il lancio di idee e attivitàinnovative (siano imprese esordienti o progetti nuovi all’interno di grandi impreseconsolidate) che aiuta ad individuare un percorso verso un business sostenibile,riducendo drasticamente tempi e costi, e, di conseguenza, la possibilità di fallire.30

Metodologia Agile L’espressione metodologia agile si riferisce a un insieme di metodidi sviluppo del software fondati su un insieme di principi comuni, direttamenteo indirettamente derivati dai princìpi del "Manifesto per lo sviluppo agile delsoftware". I metodi agili si contrappongono al modello a cascata e altri processisoftware tradizionali, proponendo un approccio meno strutturato e focalizzatosull’obiettivo di consegnare al cliente, in tempi brevi e frequentemente softwarefunzionante e di qualità. 7, 11

PMI (Piccola e Media Impresa) Le piccole e medie imprese o PMI sono aziende le cuidimensioni rientrano entro certi limiti occupazionali e finanziari prefissati. 1

Project Management Insieme delle attività svolte tipicamente da una figura de-dicata e specializzata detta project manager, volte all’analisi, progettazione,pianificazione e realizzazione degli obiettivi di un progetto, gestendolo in tutte lesue caratteristiche e fasi evolutive, nel rispetto di precisi vincoli (tempi, costi,risorse, scopi, qualità). 4, 9

Representational State Transfer (REST) Si tratta di un tipo di architettura soft-ware per i sistemi di ipertesto distribuiti come il World Wide Web. Un concettoimportante in REST è l’esistenza di risorse (fonti di informazioni), a cui si puòaccedere tramite un identificatore globale (un URI). Per utilizzare le risorse, lecomponenti di una rete (componenti client e server) comunicano attraverso unainterfaccia standard (ad es. HTTP) e si scambiano rappresentazioni di questerisorse. 20, 24

Stakeholder L’insieme di persone a vario titolo coinvolte nel ciclo di vita del softwarecon influenza sul prodotto. 28

System Integration In informatica, system integration è il processo che collegaassieme differenti sistemi informatici e applicazioni software, fisicamente o fun-zionalmente, allo scopo di creare un unico sistema con funzionalità superiori allecomponenti singole di partenza. 1, 18, 49

Team Viewer Applicazione con la quale è possibile controllare remotamente un altrocomputer. 2

User Experience (UX) Per esperienza d’uso si intende ciò che una persona provaquando utilizza un prodotto, un sistema o un servizio. L’esperienza d’uso concernegli aspetti esperienziali, affettivi, l’attribuzione di senso e di valore collegati alpossesso di un prodotto e all’interazione con esso, ma include anche le percezionipersonali su aspetti quali l’utilità, la semplicità d’utilizzo e l’efficienza del sistema.5

Glossario 55

User Story Una user story consiste in una descrizione ad alto livello di una funziona-lità utile al raggiungimento di un obiettivo di business. Con “storia” definiamo inmaniera non dettagliata una funzionalità che un software deve avere e che dàvalore al prodotto finale consegnato al cliente/utente. 31, 33, 49

Indice delle fonti

Riferimenti bibliograficiLerner, Ari. ng-book: The Complete Book on AngularJS. Lightning Source Inc, 2010.

Rubin, Kenneth S. Essential Scrum: A Practical Guide to the Most Popular AgileProcess. Addison-Wesley Professional, 2012.

Sommerville, Ian. Software Engineering. Pearson Education | Addison-Wesley, 2010.

Siti Web consultatiAngularJS. url: https://angularjs.org/.

Ingegneria del Software – Modulo A. url: http://www.math.unipd.it/~tullio/IS-1/2015/.

Ingegneria del Software – Modulo B. url: http://www.math.unipd.it/~rcardin/sweb.html.

Manifesto Agile. url: http://agilemanifesto.org/.

Scrum Guide. url: http://www.scrumguides.org/scrum-guide.html.

Scrum Methodology. url: http://scrummethodology.com/.

Stack Overflow. url: http://stackoverflow.com/.

The Java EE 6 Tutorial. url: http://docs.oracle.com/javaee/6/tutorial/doc/.

Wintech. url: http://www.wintech.it/.

57

https://angularjs.org/

http://www.math.unipd.it/~tullio/IS-1/2015/

http://www.math.unipd.it/~tullio/IS-1/2015/

http://www.math.unipd.it/~rcardin/sweb.html

http://www.math.unipd.it/~rcardin/sweb.html

http://agilemanifesto.org/

http://www.scrumguides.org/scrum-guide.html

http://scrummethodology.com/

http://stackoverflow.com/

http://docs.oracle.com/javaee/6/tutorial/doc/

http://www.wintech.it/

Realizzazione di un Sistema di Consuntivazione per una piattaforma di Digital Workplace

Documents

Transcript of Realizzazione di un Sistema di Consuntivazione per una piattaforma di Digital Workplace