Università degli Studi di Padova
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Università degli Studi di Padova
Dipartimento di Matematica "Tullio Levi-Civita"
Corso di Laurea in Informatica
Integrazione fra liste contatti e anagrafiche
gestionali in un DB aziendale
Tesi di laurea triennale
Relatore
Prof.Tullio Vardanega
Laureando
Isacco Maculan
Anno Accademico 2018-2019
Isacco Maculan: Integrazione fra liste contatti e anagrafiche gestionali in un DB aziendale, Tesi di laurea triennale, c Luglio 2019.
Indice
1 L’azienda 1
1.1 Contesto aziendale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Prodotti e Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Organizzazione dell’azienda . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Struttura dei processi in azienda . . . . . . . . . . . . . . . . . 4
1.2 Strumenti organizzativi . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 TdB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Job/Risorse e GeCo . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.3 Office365 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.4 Intellij IDEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Approccio al mercato . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Lo stage 9
2.1 Lo stage visto dall’azienda . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 La proposta di stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 La scelta dello stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Il progetto di stage 13
3.1 Pianificazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Analisi requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Tecnologie utilizzate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1 ActiveCampaign . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.2 DevExtreme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.3 Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5 Sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.6 Verifica e Validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.7 Risultato finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Valutazione retrospettiva 27
4.1 Bilancio degli obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Bilancio formativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Gap tra università e lavoro . . . . . . . . . . . . . . . . . . . . . . . . 29
iii
Elenco delle figure
1.1 Prodotti e servizi suddivisi nelle macro-famiglie . . . . . . . . . . . . . 2
1.2 Struttura dell’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Skype for Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 Intellij IDEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Processo di creazione di una campagna su ActiveCampaign . . . . . . 14
3.2 Suddivisione dei requisiti individuati . . . . . . . . . . . . . . . . . . . 15
3.3 Esempio del componente DataGrid . . . . . . . . . . . . . . . . . . . . 16
3.4 Esempio di conversione tra oggetti e tabelle operata da Hibernate . . . 16
3.5 Schema delle tecnologie impiegate . . . . . . . . . . . . . . . . . . . . . 17
3.6 Schema architettura MVC per applicazioni web . . . . . . . . . . . . . 18
3.7 Rappresentazione del builder pattern . . . . . . . . . . . . . . . . . . . 18
3.8 Diagramma dei package . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.9 Diagramma del package Controllers . . . . . . . . . . . . . . . . . . . . 19
3.10 Diagramma del package Models . . . . . . . . . . . . . . . . . . . . . . 19
3.11 Diagramma del package UpdateData . . . . . . . . . . . . . . . . . . . 20
3.12 Esempio della struttura dei package per connesione a database multipli 20
3.13 Esempio di definizione di un EntityManager . . . . . . . . . . . . . . . 21
3.14 Esempio di definizione di un id composto e relazione molti ad uno . . 22
3.15 Esempio di definizione di una relazione uno a molti tra entities . . . . 22
3.16 Esempio di utilizzo di annotazioni all’interno di una classe controller . 23
3.17 Avvio dell’applicazione con Spring Boot . . . . . . . . . . . . . . . . . 23
3.18 Schermata di SonarLint in Intellij . . . . . . . . . . . . . . . . . . . . . 24
iv
ELENCO DELLE TABELLE v Elenco delle tabelle 4.1 Obiettivi obbligatori . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.2 Obiettivi desiderabili . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3 Obiettivi facoltativi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Capitolo 1
L’azienda
1.1 Contesto aziendale
Wintech S.p.A. è un’azienda fondata a Padova nel 1987 dall’attuale CEO, Massimo
Gallotta. Da oltre 30 anni l’azienda è presente nel mercato come System Integrator.
I System Integrator rappresentano gli specialisti che si occupano di mettere in
relazione gli uomini con le macchine, i dispositivi, i software ed i servizi che impiegano.
In un processo industriale, le macchine, i dispositivi e i software di automazione sono
tutti fattori essenziali per l’efficienza delle linee di produzione, ma è il System Integrator
a farli comunicare tra loro in maniera efficace. Obiettivo principale dell’integrazione
è l’ottenimento di uno scambio di informazioni tra sistemi informativi eterogenei ed
autonomi, con la finalità di:
• Sviluppare le attività aziendali e mantenere certe risorse e certe applicazioni
già presenti in azienda. Il processo di integrazione permette di ampliare le
informazioni in possesso dando vita a nuove informazioni che sono il frutto
dell’interazione fra quelle esistenti;
• Efficientamento dei servizi;
• Promozione di prodotti propri o di terzi, scelti tra i leader di mercato;
• Erogare tutti i servizi con modalità e processi in base ai sistemi di qualità adottati;
• Commercializzare i prodotti;
• Miglioramento della qualità legata alla riduzione degli errori o dei tratti di filiera
che causano “colli di bottiglia”;
• Possibilità di implementare nuove soluzioni di business in modo più veloce ed
economico per consentire una sempre più facile modifica dei processi aziendali.
1
2 CAPITOLO 1. L’AZIENDA
1.1.1 Prodotti e Servizi
Negli anni Wintech ha cercato, nell’ambito del proprio settore, di diversificare il proprio
fatturato commercializzando prodotti Software, Hardware ed erogando servizi.
Il mercato a cui si rivolge è composto da grandi aziende, banche, compagnie di
assicurazione e P.M.I. in aree geografiche identificate nell’operatività di Wintech.
L’evoluzione e il successo conseguiti hanno determinato l’esigenza di una strutturazione
organizzativa della società finalizzata all’implementazione dei segmenti di mercato con
un’offerta altamente specializzata derivante dagli investimenti operati negli ultimi anni
nello sviluppo delle partnership con i più qualificati operatori del settore IT di cui
Wintech rivende e personalizza prodotti.
Le attività svolte da Wintech presentano esigenze di pianificazione e competenze
diverse, pertanto i servizi offerti dalla società sono raggruppati in tre macro-famiglie
con base operativa in diverse sedi dell’azienda:
• Applicazioni: prodotti per gestione interna delle aziende (gestionali, soluzioni
dipartimentali, amministrazione presenze, amministrazione personale...), presso
le sedi di Padova e Bassano;
• Soluzioni: prodotti per attività produttive (e-commerce, social collaboration,
software cycle management. . . ), presso le sedi di Padova e Milano;
• Tecnologie: gestione delle architetture di rete e sicurezza, presso la sede di Padova.
Figura 1.1: Prodotti e servizi suddivisi nelle macro-famiglie1.1. CONTESTO AZIENDALE 3
All’interno di queste macro-famiglie i principali servizi e prodotti offerti da Wintech
sono:
• analisi e progettazione di prodotti su misura;
• personalizzazioni di prodotti di aziende partner;
• rivendita di prodotti di aziende partner;
• installazione e configurazione delle soluzioni sviluppate;
• corsi di formazione per l’utilizzo delle soluzioni vendute;
• consulenze;
• assistenza in loco e remota.
1.1.2 Organizzazione dell’azienda
La società conta circa 90 dipendenti che svolgono la propria attività nella Sede di
Padova, nelle filiali di Milano e Bassano del Grappa, e nella sede staccata di Pordenone
(utilizzata come ufficio commerciale).
Figura 1.2: Struttura dell’azienda
I dipendenti sono divisi in diversi reparti:
• Direzione: definisce gli obiettivi aziendali e approva le risorse, ogni altro reparto
deve farvi riferimento;
• Divisione Commerciale: gestisce la promozione presso i clienti e le trattative
iniziali;
• Risorse Umane: gestisce la struttura organizzativa interna e, tra gli altri, ha
anche il compito di selezionare ed inserire nuove risorse, quali professionisti e
stagisti, all’interno del contesto aziendale;
• Help Desk: fornisce assistenza ai clienti rispondendo ai quesiti posti e guidandoli
nella risoluzione dei problemi riscontrati;
• Sistemisti: è responsabile della gestione e manutenzione dei Server e dell’infra-
struttura di rete sia per i clienti che per Wintech;4 CAPITOLO 1. L’AZIENDA
• Project Managers: ha il compito di realizzare i progetti, allocando e coordinando
le risorse per realizzarli. Si relaziona con il reparto Ricerca e Sviluppo per la
valutazione di nuove soluzioni da applicare ai progetti;
• Sviluppatori: segue le direttive di Project Manager per la realizzazione dei
progetti assegnati;
• Ricerca e Sviluppo: studia nuove soluzioni ed applicazioni, con lo scopo di
integrarle ai prodotti offerti dall’azienda per garantire ai propri clienti tecnologie
all’avanguardia.
Esistono degli strumenti organizzativi comuni ai vari reparti, dopodiché all’interno di
ogni reparto ne vengono usati altri in base ai differenti ambiti e modalità di lavoro.
1.1.3 Struttura dei processi in azienda
Da qualche anno Wintech ha ottenuto le certificazioni UNI CEI ISO/IEC 27001 e UNI
EN ISO 9001.
L’azienda ha allocato delle risorse per la definizione, manutenzione e miglioramento
del sistema di gestione per la qualità, e del sistema per la sicurezza delle informazioni.
Questi due sistemi si concretizzano nella definizione di:
• istruzioni e regole per lo svolgimento dei processi svolti all’interno dell’azienda;
• un sistema di controllo per assicurare lo svolgimento efficace dei processi;
• un sistema di verifica, tramite sondaggi ed analisi a campione.
I documenti che descrivono i processi sono catalogati all’interno del CRM, a dispo-
sizione dei dipendenti.
Il personale responsabile della qualità e della sicurezza si occupa, inoltre, di diffondere
tramite gli strumenti organizzativi interni le comunicazioni riguardanti nuovi processi
ed aggiornamenti e della pianificazione di audit per verificare l’efficacia delle procedure
impartite.1.2. STRUMENTI ORGANIZZATIVI 5 1.2 Strumenti organizzativi 1.2.1 TdB È l’attuale sistema di Customer Relationship Management aziendale (CRM). Sviluppato da Wintech, è integrato come applicazione nell’ambiente IBM Notes. Con- tiene tutto lo storico documentale dei rapporti avuti e di tutta la corrispondenza, inclusi gli allegati. L’integrazione è operata tramite controllo periodico del software Gestionale e conseguente aggiunta dei nuovi contenuti. 1.2.2 Job/Risorse e GeCo Job/Risorse e GeCo sono entrambi prodotti personalizzati da Wintech utilizzando come base applicazioni dell’azienda partner, Sistemi. Job/Risorse viene utilizzato per l’amministrazione del personale, quindi ad esempio richiesta permessi, ferie, rimborsi. GeCo invece è il software utilizzato da dipendenti e stagisti per la consuntivazione del lavoro svolto, offre inoltre funzionalità per la compilazione automatica di report sulle commissioni svolte, da restituire ai clienti. Entrambi questi strumenti sono integrati a TdB, dove i dipendenti hanno a disposizione calendari condivisi per poter verificare impegni e disponibilità delle altre risorse. 1.2.3 Office365 Office365 è la suite di Microsoft per la creazione, modifica e condivisione di documenti. È utilizzabile dal web, da applicazioni desktop, da mobile. Oltre alla gestione di documenti comprende il software Outlook che consiste in un calendario, un’agenda, note, contatti e posta elettronica. Il pacchetto Office offre quindi strumenti sia per la comunicazione e organizzazione di incontri ed eventi, che per la creazione e gestione di file utilizzabili in presentazioni interne e come documentale ad uso esterno. Per la stesura della documentazione relativa al prodotto sviluppato durante lo stage ho utilizzato Word per le spiegazioni più dettagliate e discorsive, mentre ho utilizzato PowerPoint per le spiegazioni più concise che necessitavano maggiormente di video e immagini per illustrare il funzionamento dell’applicazione e le modalità di utilizzo. Teams Teams è un’applicazione, contenuta nella suite Office365, che permette di creare chat singole e gruppi. Permette la gestione di gruppi di lavoro al cui interno si possono definire diversi canali di comunicazione, suddividendoli per ambiti e scopi. Teams permette di integrare nei diversi canali molte applicazioni tra cui app di ticketing, versionamento, condivisione ed editing di documenti, gestione di calendari. Come la maggior parte di app di messaggistica Teams permette di taggare i membri del gruppo, per richiamare la loro attenzione, e di avviare discussioni sotto altri messaggi. Per l’organizzazione dello stage, il tutor aziendale ha creato un gruppo con canali dedicati al monitoraggio dei progressi, per organizzare riunioni ed allineamenti e per tenere traccia di quanto discusso nelle riunioni.
6 CAPITOLO 1. L’AZIENDA
Figura 1.3: Teams
Skype for Business
Skype for Business è un’altra applicazione della suite Office 365. Oltre ad un servizio di
messaggistica istantanea offre la possibilità di organizzare riunioni e conferenze online
tramite streaming live e condivisione di schermo.
Questo strumento viene utilizzato internamente dai team di lavoro, i cui componenti
sono suddivisi tra più sedi dell’azienda, per consulenze e riunioni.
Figura 1.4: Skype for Business1.2. STRUMENTI ORGANIZZATIVI 7
1.2.4 Intellij IDEA
Intellij è un IDE per lo sviluppo in Java da JetBrains. Essa integra un sistema di
linting automatico che fornisce suggerimenti e correzioni in tempo reale, un terminale,
impostazioni per il version control e funzionalità di completamento automatico del
codice.
Figura 1.5: Intellij IDEA8 CAPITOLO 1. L’AZIENDA
1.3 Approccio al mercato
Wintech ha un approccio volto all’innovazione continua, offre prodotti customizzati
per rispondere al meglio alle esigenze dei propri clienti e quindi deve essere aggiornata
sulle ultime evoluzioni in campo tecnologico.
Per garantire queste caratteristiche l’azienda investe sulla formazione del personale e si
impegna a definire per ogni dipendente un piano di miglioramento individuale.
Per realizzare tale piano vengono fissati obiettivi precisi in termini di capacità e com-
petenze da acquisire e vengono individuate le modalità per raggiungere l’obiettivo che
si concretizzano in corsi di formazione interni, certificazioni e partecipazione a convegni.
Oltre alla formazione dei suoi dipendenti, per integrare nei suoi prodotti le tecnologie
più recenti, Wintech ha deciso di investire in un reparto dedicato che prende il nome
di R&D (Research&Developement).
All’interno di questo reparto vengono avviati progetti con l’obiettivo di testare nuovi
linguaggi, servizi e librerie, integrazioni con applicazioni già in uso oppure di produrre
prototipi di nuove applicazioni con relativa documentazione.
Al termine di ogni progetto sviluppato nel reparto R&D segue una presentazione dei
risultati ottenuti con i Project Managers e il Direttivo, così da valutare l’avvio di nuovi
progetti o l’adozione di queste tecnologie nei prodotti in produzione.Capitolo 2
Lo stage
2.1 Lo stage visto dall’azienda
Nello stage l’obiettivo principale dell’azienda è la valutazione dello stagista per decidere
se proporre un contratto, negli ultimi anni questa offerta si è concretizzata nell’as-
sunzione di almeno uno stagista ogni anno. Durante lo stage universitario l’azienda
valuta le capacità degli studenti, sia in termini di competenze tecniche, sia in termini
di capacità comunicativa, di relazionarsi, di esporre, di valutare alternative e compiere
scelte.
Wintech seleziona stagisti dalle università nonostante gli studenti non abbiano una
preparazione tecnica approfondita perché cerca di valorizzare la loro capacità di studia-
re: non conoscendo le tecnologie normalmente impiegate in azienda possono valutare
e studiare tecnologie alternative senza lasciarsi influenzare da esperienze pregresse,
questa capacità può essere impiegata al meglio all’interno del reparto R&D.
Da una decina d’anni Wintech partecipa a Stage-IT, evento organizzato da Con-
findustria per creare un punto di contatto tra studenti di informatica ed aziende che
offrono stage in ambito IT.
Durante la giornata in cui si svolge l’evento, ogni azienda ha la possibilità di presentare
le proprie offerte di stage agli studenti interessati ed organizzare un primo colloquio
conoscitivo. Eventualmente, in un successivo momento, si procede con un colloquio
formale.
Questo evento funziona talmente bene da essere diventato l’unica fonte di stagisti per
l’azienda: da quando Wintech partecipa a Stage-IT sono stati selezionati 3-4 stagisti
ogni anno.
Gli stagisti selezionati vengono inseriti nel reparto R&D, in progetti accuratamente
scelti tali da offrire allo studente un discreto livello di responsabilità nella scelta delle
tecnologie da utilizzare e che abbiano una durata limitata nel tempo, in genere due mesi,
così da permettere allo stagista di vedere risultati concreti al termine dell’esperienza di
stage.
Generalmente lo studente lavora al progetto da solo o in coppia con un altro stagista,
oltre al tutor aziendale, che rimane punto di riferimento per l’attività svolta, vengono
identificate delle risorse con cui può confrontarsi in caso di difficoltà riguardo agli
strumenti e alle tecnologie utilizzate.
Al pari degli altri progetti sviluppati all’interno del reparto R&D, al termine
910 CAPITOLO 2. LO STAGE dello stage lo studente è tenuto a presentare i risultati del proprio lavoro ai project managers, al direttivo aziendale ed agli altri componenti del reparto R&D. Durante la presentazione si evidenziano le criticità incontrate nello sviluppo del prodotto e si discutono le scelte effetuate e le tecnologie impiegate. In seguito alla presentazione il direttivo, i project managers ed il responsabile del reparto R&D sceglieranno se sviluppare un nuovo prodotto sulla base del prototipo sviluppato o se integrare solo alcune delle librerie o funzioni implementate durante lo stage in altri prodotti. Nel caso in cui il prodotto sviluppato non soddisfi le aspettive iniziali, verrà valutato se riassegnare il progetto ad altri dipendenti del reparto R&D per svilupparlo ulteriormente oppure chiudere il progetto. 2.2 La proposta di stage L’idea di questo stage è nata dall’utilizzo da parte del reparto Marketing aziendale dell’applicazione ActiveCampaign per la gestione di campagne in forma di pubblicità o inviti ad eventi organizzati dall’azienda. Questa applicazione risulta molto efficace per l’analisi dei risultati di una campagna, in quanto permette di verificare il pubblico raggiunto e le interazioni con la mail inviata. Non è altrettanto efficace quando invece è necessario scegliere i destinatari per le campagne successive, in quanto non mostra in modo chiaro ed organizzato i dati relativi all’attività dei contatti destinatari. Inoltre non esiste una vista che unisca i dati delle attività dei contatti con i dati commerciali delle loro aziende, rendendo poco efficiente il processo di selezione dei destinatari da parte dei commerciali. Infine ActiveCampaign gestisce i dati della propria lista di contatti, i quali vengono utilizzati da diverse applicazioni all’interno dell’azienda. Per poterli utilizzare è necessario caricarli manualmente su ActiveCampaign, introducendo il rischio di inconsistenza dei dati nel caso vengano modificati all’interno dell’applicazione. Si è quindi deciso di avviare un progetto per sviluppare una piattaforma che vi- sualizzi i dati commerciali dei contatti aziendali unendoli alle informazioni sulle attività dei contatti coinvolti in campagne ActiveCampaign. Nelle viste devono quindi essere implementate funzioni di filtro e ricerca secondo i vari attributi dei contatti, per permettere ai commerciali di selezionare liste di destinatari per le campagne avviate dal reparto Marketing. Inizialmente lo stage è stato pensato per due studenti. Purtroppo ho dovuto rimandare la data d’inizio stage e quindi il progetto è stato suddiviso in due parti. Nella prima parte il mio predecessore ha sviluppato un prototipo in cui ha implementato delle funzioni che fanno uso di endpoint dell’API di ActiveCampaign per ottenere i dati relativi a contatti, liste e campagne caricate su ActiveCampaign, ed un interfaccia grafica in cui visualizzare i dati ottenuti. A termine dello stage del mio predecessore è stato valutato il prototipo sviluppato e si è deciso di mantenere l’interfaccia grafica e solo alcune delle funzioni, in quanto prima della data di inizio del mio stage è stata pubblicata una nuova versione dell’API ActiveCampaign e si è deciso di utilizzare alcuni degli endpoint dell’ultima versione rilasciata. Tra gli obiettivi definiti dall’azienda vi sono il completamento dell’interfaccia grafica di partenza, la progettazione della base dati da utilizzare per memorizzare lo storico delle attività dei contatti utilizzati in ActiveCampaign e l’integrazione del sistema di gestione contatti utilizzato in azienda.
2.3. LA SCELTA DELLO STAGE 11
Nel prodotto finale ci si aspettano funzioni per:
• visualizzare i contatti aziendali;
• visualizzare per i contatti già coinvolti in campagne i dati raccolti da ActiveCam-
paign;
• ordinare e filtrare i contatti utilizzando indici calcolati sui dati di ActiveCampaign;
• creare una lista di contatti ed importarla su ActiveCampaign;
• visualizzare le liste presenti su ActiveCampaign;
• visualizzare i risultati delle campagne svolte su ActiveCampaign;
• l’allineamento tra i dati presenti su ActiveCampaign, il DB creato durante lo
stage e il sistema di gestione contatti aziendale.
2.3 La scelta dello stage
Per aiutare gli studenti nella scelta dello stage Confindustria organizza ogni anno un
evento in collaborazione con l’università di Padova e Venezia.
Questo evento, denominato Stage-IT, si svolge in fiera a Padova. Viene assegnato
un tavolo ad ogni azienda iscritta e gli studenti possono scegliere alcune aziende
con cui tenere dei colloqui conoscitivi durante i quali si presentano, vengono presen-
tati gli stage proposti ed in caso si fissa un secondo colloquio nelle relative sedi aziendali.
Ho partecipato a questo evento ed ho sostenuto colloqui conoscitivi con una decina
di aziende che avevo selezionato. Al termine dell’evento sono stato richiamato da alcune
di queste e da altre con cui non avevo parlato, ma che avevano visto il curriculum
condiviso tramite Stage-IT. Wintech era tra queste ultime.
Nelle settimane successive ho sostenuto colloqui in diverse aziende le quali proponeva-
no stage in vari ambiti quali ricerca operativa, gestionali, automazione, applicazioni web.
A differenza di altre aziende, con le quali ho sostenuto un colloquio e mi hanno
presentato semplicemente i requisiti e gli obiettivi del progetto, Wintech mi ha con-
tattato invitandomi ad un open-day in azienda insieme ad altri studenti. Durante
questa giornata ci è stata presentata l’azienda, i suoi principali prodotti e sono stati
contestualizzati diversi progetti per i quali avevano intenzione di attivare degli stage.
Nella scelta finale ho tenuto conto dell’impressione avuta durante i colloqui, della
tipologia di progetto proposto e delle esperienze di altri studenti che avevano già svolto
lo stage nelle aziende tra cui dovevo scegliere.Capitolo 3
Il progetto di stage
3.1 Pianificazione
Durante la stesura del piano di lavoro in collaborazione con il tutor aziendale abbiamo
suddiviso il periodo di stage in 3 fasi:
fase 1: dal 25/03/2019 al 5/04/2019
In questa prima fase del percorso formativo ho dedicato due settimane allo studio del
funzionamento dell’attuale sistema di gestione contatti aziendale e degli strumenti di
terze parti integrate in esso. Inoltre ho riservato parte di questo periodo per prendere
confidenza con le funzionalità e l’architettura del nuovo prodotto da adottare:
• studio della struttura generale di gestione contatti adottato in Wintech;
• primo approccio con API REST Active Campaign e la visione delle librerie
DevExtreme per JavaScript per la costruzione delle tabelle utilizzate per la
rappresentazione delle liste contatti delle campagne marketing.
fase 2: dal 8/04/2019 al 10/05/2019
La seconda fase è durata complessivamente 4 settimane. Ho dedicato la prima settimana
all’analisi della struttura da applicare ai dati da raccogliere e le necessità di tracciamento
di Marketing. Nelle tre settimane successive, che concludono tale fase, ho utilizzato
API REST di Active Campaign, Java e database per realizzare la soluzione progettata:
• costruzione di un modello logico che permetta di compiere ricerche e confronti
sui comportamenti dei contatti;
• aggiornamento dati di contatto;
• recupero risultati delle campagne effettuate;
• predisposizione aggiunta dati registrati da altri sistemi e allineamento.
fase 3: dal 13/05/2019 al 24/05/2019
In questa ultima fase, della durata di due settimane, ho realizzato gli obiettivi de-
siderabili. Inoltre ho realizzato la documentazione relativa al progetto, nella forma
di:
1314 CAPITOLO 3. IL PROGETTO DI STAGE
• manuale sviluppatore;
• manuale utente utilizzatore;
• manuale addetto marketing.
3.2 Analisi requisiti
Ho individuato requisiti da tre fonti principali: gli utenti (dipendenti dei reparti
commerciali e marketing), i vincoli imposti dall’API di Activecampaign e i vincoli
imposti dal prototipo di partenza utilizzato per questo stage.
Per raffinare ulteriormente i requisiti ho modellato il processo di selezione contatti
ed invio di una campagna su ActiveCampaign di cui si può vedere lo schema in figura
3.1.
Figura 3.1: Processo di creazione di una campagna su ActiveCampaign
Oltre ai requisiti identificati nella stesura del piano di stage ed altri aggiunti a seguito
della modellazione del processo sopracitato, sono stati aggiunti diversi requisiti in corso
d’opera, in seguito allo studio delle funzionalità offerte dalla nuova versione dell’API
di ActiveCampaign. Tutti i requisiti aggiunti dopo la stesura del piano di stage sono
stati catalogati come desiderabili o facoltativi a seconda della loro importanza. Ho
identificato ogni requisito in base alla sua importanza suddividendoli in:
• Obbligatori: requisiti irrinunciabili;
• Desiderabili: requisiti non necessari ma dal valore aggiunto riconoscibile;
• Facoltativi: requisiti che portano un piccolo valore aggiunto al prodotto.
A seguito dell’analisi requisiti ho individuato 34 requisiti di cui 14 obbligatori, 9
desiderabili e 11 facoltativi.
3.3 Tecnologie utilizzate
Ho dedicato il primo periodo di stage allo studio e alla scelta delle tecnologie da
impiegare per lo sviluppo della soluzione progettata. Alcune delle applicazioni sono
state definite come requisiti di vincolo al progetto, ActiveCampaign, DevExtreme ed
Hibernate, mentre sono stato libero di scegliere l’API da utilizzare ed altre applicazioni,
ad esempio per il versionamento del codice ed il tracciamento dei requisiti.3.3. TECNOLOGIE UTILIZZATE 15
Figura 3.2: Suddivisione dei requisiti individuati
3.3.1 ActiveCampaign
ActiveCampaign è il software attualmente utilizzato dal reparto Marketing per gestire
le campagne di Email Marketing Automation. Mette a disposizione degli sviluppatori
delle API. Da poco meno di un anno ActiveCampaign ha rilasciato l’API v3, ma ad
oggi la documentazione non è ancora completa. Durante lo stage ho incontrato alcuni
bug nell’utilizzo di alcuni endopoint dell’API v3, dopo aver consultato il supporto
di ActiveCampaign sono stati identificati in issue non ancora risolte. Quindi, previa
consultazione con il tutor aziendale, ho deciso di aggiornare solo alcuni endpoint alla
versione 3 e mantenere il resto alla versione 1 dell’API.
3.3.2 DevExtreme
DevExtreme è una libreria JavaScript che offre numerosi widgets già pronti per l’uso,
personalizzabili in base alle proprie esigenze. Di tutti i widgets offerti da DevExpress
ho usato: DataGrid, Charts, Forms e Dialogs.
Questo strumento è il componente principale dell’interfaccia grafica sviluppata nel
prototipo che ho utilizzato come base di partenza per il mio stage. Viene impiegato
per la visualizzazione dei dati di contatti, liste e campagne, ho deciso di studiarne la
documentazione per poter ampliarlo mantenendo lo stesso stile grafico.
La libreria è risultata facile da usare poiché è ben documentata, sono presenti molti
esempi, la community è molto ampia, ed anche i topic più datati vengono aggiornati a
seguito delle modifiche apportate dalle nuove versioni di DevExtreme. Inoltre, quando
non ho trovato soluzioni tra la documentazione o i topic della community, il supporto
sul sito di DevExpress è risultato efficiente, fornendo riferimenti alla documentazione e
risposte dettagliate in poche decine di minuti dall’apertura dei ticket.
3.3.3 Hibernate
Hibernate è un framework che fornisce un servizio di ORM (Object-Relational Mapping),
ovvero gestisce la persistenza dei dati sul database attraverso la rappresentazione e il
mantenimento su database relazionale di un sistema di oggetti Java. Ciò può avvenire
sia tramite un mapping con file XML che con le annotazioni. Nel progetto di stage
ho utilizzato le Java Persistence Annotations (JPA), che appartengono al package
javax.persistence.*.
Ho quindi creato oggetti java che descrivessero i dati che sarei andato poi a salvare sul16 CAPITOLO 3. IL PROGETTO DI STAGE
Figura 3.3: Esempio del componente DataGrid
Figura 3.4: Esempio di conversione tra oggetti e tabelle operata da Hibernate
database di supporto. Ogni oggetto ha associato un’interfaccia repository la quale può
essere considerata come una astrazione di una collezione di quegli oggetti.3.4. PROGETTAZIONE 17
3.4 Progettazione
Dovendo completare un prodotto già parzialmente sviluppato diverse scelte architettu-
rali erano già state valutate.
Figura 3.5: Schema delle tecnologie impiegate
L’architettura di partenza è una web application nella quale il front-end è sviluppato in
HTML, CSS e JavaScript con l’aiuto delle librerie DevExtreme e jQuery. Il back-end è
scritto in Java, con l’uso di:
• Maven per gestire le dipendenze;
• Spring usato per far funzionare il servlet;
• Hibernate per gestire i dati salvati sul server.
L’architettura principale è una MVC, così come definito da Spring secondo il modello
che si può osservare in figura 3.6
Per favorire l’allineamento con il sistema di gestione contatti aziendale ho deciso
di utilizzare, per la persistenza dei dati, un database Microsoft SQL Server rispetto
alla scelta di utilizzare un database MySQL, adottata nello sviluppo del prototipo di
partenza.18 CAPITOLO 3. IL PROGETTO DI STAGE
Figura 3.6: Schema architettura MVC per applicazioni web
I dati dei contatti utilizzati non sono memorizzati in un unico database. I dati
commerciali sono memorizzati nel sistema di gestione contatti aziendale, mentre i
dati relativi alle attività registrate da ActiveCampaign sono memorizzati nel database
progettato ed istanziato durante lo stage.
Poiché non sempre vengono richiesti tutti gli attributi di un contatto, ho definito la
classe Contact che espone diversi costruttori implementati secondo la logica del builder
pattern (figura 3.7) a cui viene delegata la costruzione dell’oggetto nel formato richiesto.
Figura 3.7: Rappresentazione del builder pattern
Di seguito descriverò i package principali mostrati in figura 3.8.
Figura 3.8: Diagramma dei package3.4. PROGETTAZIONE 19
Controllers
Il package Controllers contiene le componenti responsabili della logica di controllo, nello
specifico esse si occupano di mappare le richieste ai models e di gestire le informazioni
da essi tornate. Ogni classe all’interno di questo package non è altro che un controller
di Spring.
Figura 3.9: Diagramma del package Controllers
Models
Il package Models contiene le componenti responsabili della logica di business, que-
st’ultime si occupano di separare la rappresentazione interna dei dati nel database dal
loro uso e manipolazione. Contiene i package Repository, Service, Entity.
Figura 3.10: Diagramma del package Models
UpdateData
Questo package si occupa dell’aggiornamento dei dati salvati sul db persistendo alcune
modifiche effettuate su ActiveCampaign sfruttando uno scheduler. Lo scheduler si attiva
ad una frequenza temporale tarata in base al carico dati presente su ActiveCampaign
e controlla con chiamate alle API se sono state effettuate modifiche ai dati relativi a
Contatti, Liste, Campagne e Tag.
A differenza del comportamento del prototipo di partenza, che manteneva semplicemente
l’allineamento tra il db utilizzato e ActiveCampaign, nel prodotto sviluppato questo
package ha il compito di gestire l’allineamento tra ActiveCampaign, il db progettato
durante lo stage e il db aziendale in cui sono salvati i dati commerciali dei contatti.
Definendo quindi delle priorità per mantenere la versione corretta dei dati ridondanti e
le chiavi di collegamento tra le tabelle dei vari database.20 CAPITOLO 3. IL PROGETTO DI STAGE
Figura 3.11: Diagramma del package UpdateData
3.5 Sviluppo
L’attività di codifica è stata quella che ha richiesto più tempo principalmente a causa
della mia inesperienza nell’uso delle tecnologie impiegate nel progetto.
Durante le due settimane dedicate alla formazione il tutor aziendale ed i colleghi del
reparto R&D mi hanno assistito aiutandomi nello studio delle tecnologie e rispondendo
ai miei dubbi per comprendere appieno le scelte fatte nello sviluppo del prototipo di
partenza. Per sviluppare la maggior parte delle componenti richieste ho utilizzato il
framework Spring e l’ORM Hibernate, di seguito presenterò qualche esempio di alcune
classi sviluppate.
Hibernate
Uno dei requisiti principali del progetto richiedeva l’integrazione del sistema di gestione
contatti aziendale nell’applicazione, così da poter mettere in relazione i dati sulle attività
dei contatti coinvolti nelle campagne con i dati commerciali gestiti dal sistema aziendale.
Per fare ciò ho dovuto configurare Hibernate per la connessione contemporanea a più
di un database e la gestione delle operazioni di lettura e scrittura dati. È stato
necessario suddividere in due package distinti le classi model e repository riferite ai
diversi database seguendo lo schema in figura 3.12, e creare una classe di configurazione
per ciascun database all’interno di ciascun package.
Figura 3.12: Esempio della struttura dei package per connesione a database multipli3.5. SVILUPPO 21
All’interno della classe di configurazione ho definito tre bean:
• DataSource: legge da application.properties i dati (indirizzo ip, credenziali,
tipologia di database) per la connessione al database;
• EntityManager: indica il package in cui sono contenute le classi che mappano le
tabelle del database;
• TransactionManager: gestisce le operazioni su ciascun database.
Figura 3.13: Esempio di definizione di un EntityManager
Ho usato Hibernate per mappare le classi Java con le tabelle del database usando le
seguenti annotazioni JPA (Java Persistence API):
• @Entity: indica che la classe in questione rappresenta un’entità;
• @Table: indica la tabella del database in cui si vuole mappare l’entità;
• @Id: marca un attributo come chiave primaria della tabella;
• @EmbeddedId: si può usare in alternativa a @Id per marcare un attributo come
chiave primaria composta della tabella;
• @Column: marca un attributo come campo della tabela;
• @ManytoOne: utilizzato per mappare una relazione "molti ad uno" tra entities;
• @OneToOne: utilizzato per mappare una relazione "uno ad uno" tra entities;
• @OneToMany: utilizzato per mappare una relazione "uno a molti" tra entities.
Introducendo la mappatura delle relazioni tra le diverse entities ho potuto implementare
join tra entities nelle classi repository ed eliminare i campi ridontanti utilizzati nel
prototipo di partenza. Nelle immagini successive viene mostrato come viene mappato
in un oggetto un id composto della relativa tabella e successivamente come sia possibile
mappare una relazione uno a molti tra due entities utilizzando questo id.
L’utilizzo di queste annotazioni per una mappatura accurata di entità, di tutti i
loro campi e le relazioni tra entities, mi ha permesso di configurare l’istanziazione
di un nuovo database. Se nel file di configurazione indico un database vuoto, per la
persistenza dei dati, al primo avvio dell’applicazione vengono create tutte le tabelle e
le relazioni mappate tramite le annotazioni di Hibernate.22 CAPITOLO 3. IL PROGETTO DI STAGE
Figura 3.14: Esempio di definizione di un id composto e relazione molti ad uno
Figura 3.15: Esempio di definizione di una relazione uno a molti tra entities
Spring
Nel progetto ho sfruttato il principio di inversion of control con il pattern dependency
injection. Tramite l’uso dell’annotazione @Autowired, fornita da Spring, ho potuto
limitarmi alla dichiarazione delle dipendenze fra classi, ad esempio nel caso delle
classi controller, che fanno uso delle classi service che a loro volta utilizzano le classi
repository. Sarà poi l’iniettore di Spring a provvedere all’istanziazione degli oggetti
necessari secondo le annotazioni utilizzate.
Nella figura 3.16 ho riportato un esempio in cui sono state usate alcune annotazioni,
tra cui @RestController e @PostMapping, che hanno permesso un’implementazione
semplice e pulita delle classi controller.
Ho utilizzato la classe SpringApplication, di Spring Boot, come mostrato in figura
3.17, per l’avvio dell’applicazione.3.6. VERIFICA E VALIDAZIONE 23
Figura 3.16: Esempio di utilizzo di annotazioni all’interno di una classe controller
Figura 3.17: Avvio dell’applicazione con Spring Boot
3.6 Verifica e Validazione
Per la verifica della documentazione prodotta ho utilizzato i tool di controllo ortografico
di Microsoft Word per individuare errori ortografici e grammaticali ed ho riletto ogni
paragrafo al termine della stesura, per verificare la presenza di errori residui.
Per la verifica statica del codice ho impiegato un plug-in di Intellij IDEA denominato
SonarLint. Questo plug-in individua ed evidenzia errori o istruzioni che possono essere
ottimizzate, suggerendo delle modifiche e fornendo la relativa documentazione così che
l’utente possa approfondire l’analisi (figura 3.18).
Le principali funzionalità di SonarLint che ho utilizzato sono state:
• controllo delle classi importate e non utilizzate;
• controllo delle variabili dichiarate e non usate o metodi privati mai utilizzati;
• controllo dell’uso di caratteri sconsigliati nella nomenclatura (caratteri speciali);
• controllo di presenza di codice ridondante;
• controllo della chiusura dei tag HTML e delle parentesi in JavaScript.
Oltre a queste, ho utilizzato i seguenti strumenti per l’analisi statica del codice:
• inspection e walkthrough manuale;
• linting di Intellij IDEA sul codice prodotto;
• validatore W3C per il codice HTML e CSS.24 CAPITOLO 3. IL PROGETTO DI STAGE
Figura 3.18: Schermata di SonarLint in Intellij
L’obiettivo del reparto R&D è la realizzazione di software funzionante da esporre in
dimostrazioni pratiche o fornire agli sviluppatori. In queste occasioni agli stagisti e
programmatori è richiesto di produrre proof of concept in tempi limitatissimi e con
requisti che si modificano in base a quanto imparato studiando le nuove tecnologie e le
riunioni svolte con gli altri comparti. Per questi motivi i prodotti di R&D non sono
sottoposti a revisione del codice e non prevedono l’implementazione di test automatici.
Non è stato richiesto il calcolo di metriche Gli unici test automatici che ho sviluppato
sono stati test prestazionali per calcolare i tempi impiegati da singole funzioni. Ho
utilizzato i risultati ottenuti per valutare miglioramenti apportati da modifiche effettuate
ed il soddisfacimento di requisiti prestazionali. Ad ogni riunione di allineamento con il
tutor aziendale abbiamo effettuato test di sistema manuali per verificare le funzionalità
sviluppate e poi documentarne i risultati su Azure.
3.7 Risultato finale
A termine dello stage ho presentato il prodotto finale al board del direttivo, al mio
tutor e ai project managers. Dopo aver riassunto i motivi per cui si è deciso di avviare
questo progetto, riportati nella sezione 2.2, ho esposto le funzionalità implementate:
• visualizzazione di tutti i contatti presenti nel sistema di gestione contatti aziendale;
• visualizzazione dei dati commerciali relativi all’azienda di ciascun contatto;
• visualizzazione delle attività (apertura email, click link...) associate ad ogni
contatto;
• visualizzazione di marcatori grafici per distinguere i contatti in base a degli indici
di attività definiti;
• visualizzazione dei risultati delle campagne concluse;
• sistema di allineamento tra i database contatti, che gantisce di lavorare sempre
con la versione corretta dei dati;
• gestione e salvataggio di selezioni di contatti;3.7. RISULTATO FINALE 25
• creazione di una nuova lista su ActiveCampaign e caricamento dei dati dei contatti
selezionati.
Assieme al codice sorgente ho consegnato all’azienda 4 documenti:
• manuale sviluppatore: descrive la struttura e le classi dell’applicazione, ho
documentato le scelte progettuali descrivendo anche le funzioni implementate e
successivamente scartate o alterate, motivando le scelte fatte;
• manuale utente: descrive all’utente l’utilizzo delle diverse funzionalità dell’appli-
cazione ed il significato dei possibili messaggi d’errore;
• manuale addetto marketing: definisce per gli addetti del reparto marketing
best-practice da seguire nel processo di creazione di una campagna, stabilendo
delle regole per la nomenclatura delle campagne e dei nuovi tag inseriti per poter
indicizzare al meglio i risultati visualizzati nell’applicazione.
• documento descrittivo sviluppato nelle ultime settimane di stage che descrive
lo studio di una possibile integrazione di un’applicazione per la gesione degli
eventi nel prodotto sviluppato. Questo prodotto non era previsto nella piani-
ficazione iniziale, è stato introdotto in seguito allo studio della nuova API di
ActiveCampaign.
Dopo aver verificato i risultati ottenuti, il progetto è stato valutato positivamente.
L’azienda ha deciso di sviluppare l’applicazione per utilizzo interno. Come definito
inizialmente l’applicazione verrà utilizzata dai commerciali per la selezione dei contatti
destinatari delle campagne e dagli addetti del reparto marketing per verificare gli esiti
delle campagne concluse.Capitolo 4
Valutazione retrospettiva
4.1 Bilancio degli obiettivi
Durante le 320 ore di stage ho soddisfatto tutti gli obiettivi obbligatori, desiderabili e
facoltativi. Nelle seguenti tabelle sono elencati i diversi obiettivi fissati ad inizio stage,
come definito dagli obiettivi ho sviluppato un applicazione che integra ActiveCampaign
e il sistema di gestione contatti aziendale progettando un database in cui persistere i
dati relativi alle attività dei contatti aziendali coinvolti in campagne di Email Marketing
Automation. Ho sviluppato un sistema di allineamento tra il database progettato e gli
altri due componenti, per evitare la presenza di inconsistenze nei dati condivisi dai
tre sistemi. Ho consegnato il manuale sviluppatore ed il manuale utente sviluppati
al tutor aziendale al termine dello stage. A seguito dello studio dell’applicazione
ActiveCampaign ho redatto un documento contenente best-practice destinate agli
addetti marketing per rendere più leggibili i dati raccolti ed utilizzati nel prodotto
sviluppato. Infine nelle ultime settimane di stage ho prodotto un documento in cui
descrivo come sia possibile integrare altre applicazioni nel prodotto sviluppato, più nel
dettaglio ho approfondito il caso di un applicazione per la gestione di eventi.
Obiettivi obbligatori Soddisfatto
Studio delle applicazioni da integrare nel prodotto finale si
Studio del prototipo di partenza si
Progettazione di un database per contenere i dati di attività contatti si
sviluppo di un sistema di allineamento tra le applicazioni integrate si
Analisi funzionale ed architetturale della soluzione proposta si
Tabella 4.1: Obiettivi obbligatori
4.2 Bilancio formativo
Conoscenze
Ho scelto questo stage perché mi interessava il progetto proposto dall’azienda e l’ambito
in cui si collocava nonostante la mia quasi nula esperienza pratica in merito. Infatti
2728 CAPITOLO 4. VALUTAZIONE RETROSPETTIVA
Obiettivi desiderabili Soddisfatto
Studio delle differenti possibilità di sviluppo e relative tecnologie si
Produzione di un manuale sviluppatore si
Produzione di un manuale utente si
Tabella 4.2: Obiettivi desiderabili
Obiettivi facoltativi Soddisfatto
predisposizione della manutenibilità della piattaforma in modo efficace si
Descrizione delle metodologie per l’integrazione di nuove funzionalità si
Tabella 4.3: Obiettivi facoltativi
non avevo esperienze precedenti nello sviluppo di applicazioni web in java e nemmeno
nell’utilizzo delle tecnologie richieste. Per questo durante la prima metà dello stage
sono stato affiancato da un membro del reparto R&D che mi ha seguito nel periodo di
formazione, rispondendo a dubbi e domande sulle diverse tecnologie studiate, mentre
per i dubbi per lo sviluppo dell’architettura ho potuto confrontarmi con il tutor
aziendale. Le principali tecnologie studiate durante lo stage sono:
• Spring: ho studiato l’utilizzo di questo framework come servlet ed ho imparato
ad utilizzare le principali annotazioni necessarie allo sviluppo di un’applicazione
web. Ho trovato numerose guide ben strutturate e una documentazione completa.
• Hibernate: dovendo gestire la connessione con più database non ho potuto
utilizzare le funzioni di configurazione automatica ed ho dovuto definire i file di
configurazione per ogni db utilizzato. Nonostante le difficoltà iniziali ho trovato
interessante il funzionamento di questo strumento.
• REST API: è stato il mio primo approccio alle REST API e ho trovato molto
interessante la modalità di interazione con il database tramite comandi GET,
POST, PUT, DELETE. Purtroppo le API di ActiveCampaign non sono ben
documentate, spesso la documentazione definisce solo parte dei parametri delle
chiamate o dei dati di ritorno. Ho addirittura rilevato alcuni errori nella docu-
mentazione per cui ho aperto dei ticket al supporto di ActiveCampaign. A causa
della differenza di fuso orario con la sede del supporto, localizzata negli Stati
Uniti, gli scambi di mail per con il supporto sono stati molto lenti ed inefficienti.
Abilità
Durante lo stage ho potuto ampliare le seguenti abilità:
• Problem solving: dovendo produrre un applicazione partendo da un prototipo
e dovendo integrarvi delle applicazioni utilizzate in azienda ho dovuto spesso
sviluppare soluzioni alternative per rispettare i vincoli da loro imposti.
• Coordinamento aziendale: le mie esperienze di stage, precedenti a questa,
si sono svolte in aziende di piccole dimensioni (< 15 dipendenti). È stato4.3. GAP TRA UNIVERSITÀ E LAVORO 29
molto interessante apprendere e seguire alcune procedure standardizzate a livello
aziendale. Come le norme da seguire per il controllo delle presenze, per la
consuntivazione delle attività svolte, per la segnalazione di ticket interni e per
organizzare incontri e riunioni con il tutor ed i colleghi di R&D.
• Analisi processi: prima di procedere alla progettazione ho dedicato qualche gior-
no all’analisi dei processi di selezione dei contatti e di creazione di una campagna
da parte di commerciali e addetti al marketing. È stata un esperienza interessante
per poter comprendere meglio il contesto e gli obiettivi dell’applicazione che ho
sviluppato.
• Comunicative: durante lo stage sono state fatte riunioni di allineamento con il
tutor aziendale con frequenza settimanale per verificare lo stadio di avanzamento
del progetto e valutare proposte o modifiche. Ho quindi dovuto imparare a
descrivere lo stato del progetto utilizzando il giusto livello di astrazione perché le
funzionalità sviluppate risultino comprensibili anche a chi non ha partecipato
alla codifica dell’applicazione.
4.3 Gap tra università e lavoro
All’inizio di questo stage non conoscevo nessuna delle tecnologie utilizzate nè avevo
mai sviluppato applicazioni simili a questa. Ho appositamente scelto questo stage in
quanto richiede tecnologie, per me, nuove, così da poter ampliare il mio curriculum
formativo. Nonostante questi presupposti in due mesi di stage sono riuscito a prendere
confidenza con queste tecnologie e a padroneggiarle a sufficienza per permettermi di
soddisfare i requisiti imposti dall’azienda. Il corso di laurea in Informatica mi ha
preparato adeguatamente per questo stage, non mi ha fornito le conoscenze tecniche
necessarie ma, attraverso diversi progetti durante i 3 anni di corso, mi ha permesso di
consolidare delle base teoriche, dei modelli di ragionamento e un metodo di studio per
permettermi di apprendere autonomamente le tecnologie necessarie. Ritengo quindi
che sia compito dell’azienda colmare questo gap fornendo formazione tecnica ai nuovi
dipendenti. Avendo dovuto lavorare ad un prototipo sviluppato qualche mese prima
del mio arrivo risultavano già disponibili nuove versioni di quasi tutti gli strumenti
utilizzati a riprova dell’importanza della formazione continua e dell’importanza del
metodo di studio che l’università cerca di trasmettere agli studenti.Glossario
API
in informatica con il termine Application Programming Interface API (ing. interfaccia
di programmazione di un’applicazione) si indica ogni insieme di procedure disponibili
al programmatore, di solito raggruppate a formare un set di strumenti specifici per
l’espletamento di un determinato compito all’interno di un certo programma. La
finalità è ottenere un’astrazione, di solito tra l’hardware e il programmatore o tra
software a basso e quello ad alto livello semplificando così il lavoro di programmazione.
REST
è un tipo di architettura software che rappresenta un sistema di trasmissione di dati su
HTTP senza ulteriori livelli. Il funzionamento prevede una struttura degli URL ben
definita e l’utilizzo dei verbi HTTP specifici.
Servlet
oggetti scritti in Java che operano all’interno di un server web, permettono di gestire
quale pagina visualizzare o quale parte dell’applicazione invocare in base alle richieste
ricevute.
Walkthrough
una forma di revisione del materiale statica, cioè che non richiede l’esecuzione dello
stesso, al fine di rilevare la presenza di difetti ed eseguire una lettura critica del prodotto
in esame. La strategia è percorrere il codice simulandone l’esecuzione
31Puoi anche leggere
