Università degli Studi di Padova - SIAGAS
←
→
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
D IPARTIMENTO DI M ATEMATICA "T ULLIO L EVI -C IVITA "
C ORSO DI L AUREA IN I NFORMATICA
Servizi web per la registrazione, trascrizione e
interpretazione di uno stand-up meeting
Tesi di laurea triennale
Relatore
Prof. Francesco Ranzato
Laureando
Miki Violetto
A NNO A CCADEMICO 2017-2018
Sommario
La presente relazione descrive il lavoro svolto nel periodo di stage, della durata di
8 settimane lavorative, dal laureando Miki Violetto presso l’azienda Zero12 s.r.l. nel
periodo di febbraio e marzo 2018.
Lo scopo dello stage era apprendere tecniche di sviluppo di soluzioni software su
tecnologie Cloud nel contesto dell’intelligenza artificiale e realizzare un progetto spe-
rimentale in grado di registrare l’audio degli standup giornalieri per poi elaborarli ed
estrarre il contenuto informativo, mostrando in una dashboard se l’andamento del
progetto è in linea con le aspettative oppure si stanno verificando delle problematiche
che rallentano il progetto.
Durante lo stage si dovevano valutare e studiare le tecnologie offerte da Amazon Web
Services e Google Cloud Platform, concentrandosi sui prodotti offerti che riguardano
la trascrizione audio e la comprensione e classificazione automatica di testi.
I primi due capitoli del presente documento descrivono il contesto aziendale in cui ho
svolto lo stage e come esso si colloca all’interno della strategia aziendale.
Il terzo capitolo documenta lo svolgimento dello stage, descrivendone le attività, i
processi produttivi impiegati e le principali scelte progettuali.
Il quarto ed ultimo capitolo contiene una valutazione retrospettiva sul soddisfacimen-
to degli obiettivi, il bilancio delle conoscenze acquisite e una valutazione conclusiva
sullo stage.
L’appendice A contiene alcuni test effettuati sui servizi utilizzati.
L’appendice B contiene alcuni screenshot effettuati durante l’utilizzo dei servizi AWS.
iii
Ringraziamenti
Innanzitutto, vorrei esprimere la mia gratitudine al Prof. Francesco Ranzato, relatore della
mia tesi, per l’aiuto fornitomi durante la stesura del lavoro.
Ringrazio inoltre tutta la Zero12 per l’esperienza di stage che ho vissuto e per l’accogliente
ambiente di lavoro che sono riusciti a creare.
Desidero inoltre ringraziare i miei parenti e la mia ragazza Viviana, per l’infinita pazienza
dimostratami in questi lunghi anni.
Un ultimo ringraziamento ai compagni di corso, senza di loro non sarei riuscito ad apprendere
tutto quello che ho imparato all’università.
Padova, Luglio 2018 Miki Violetto
v
Indice
1 Contesto Aziendale 1
1.1 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Dominio applicativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Mobile app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.2 Data analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.3 Sviluppo software personalizzato . . . . . . . . . . . . . . . . . 3
1.3 Tecnologie aziendali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Processi Aziendali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.1 Framework Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.2 Strumenti a supporto dei processi . . . . . . . . . . . . . . . . . 5
2 Progetto nella strategia aziendale 9
2.1 Rapporto tra azienda e stage universitari . . . . . . . . . . . . . . . . . 9
2.2 Presentazione del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Cos’è una standup . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Pianificazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Aspettative aziendali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Obiettivi del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Vincoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.1 Vincoli metodologici . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.2 Vincoli temporali . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.3 Vincoli tecnologici . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Resoconto del progetto 15
3.1 Analisi dei rischi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Scelta delle tecnologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2 Tecnologie approfondite . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.1 Ajarvis WebApp . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.2 Ajarvis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Verifica e validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5 Prodotti finali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5.1 Ajarvis Webapp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Valutazione retrospettiva 31
4.1 Valutazione degli obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Valutazione personale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
vii
viii INDICE
4.2.1 Gestione di progetto . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.2 Processi di sviluppo e strumenti a loro supporto . . . . . . . . . 32
4.2.3 Linguaggi e tecnologie . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.4 Conclusione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5 Appendice A 35
5.1 Test su Amazon Transcribe e Google Speech . . . . . . . . . . . . . . . . 35
5.1.1 Test dopo le prime standup . . . . . . . . . . . . . . . . . . . . . 35
5.1.2 Test sulla qualità della registrazione . . . . . . . . . . . . . . . . 37
5.1.3 Test sulla lingua . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1.4 Altri test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6 Appendice B 47
6.1 AWS Elastic Compute Cloud . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2 AWS Identity and Access Management . . . . . . . . . . . . . . . . . . 48
6.3 AWS Simple Storage Service . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.4 AWS DynamoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.5 AWS API Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.6 AWS CloudWatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.7 AWS Lambda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Glossario 61
Bibliografia 63
Elenco delle figure
1.1 Logo di Zero12 s.r.l. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Logo di Allos S.p.A. e di Nextep . . . . . . . . . . . . . . . . . . . . . . 2
1.3 I partner di Zero12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Il framework Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 Architettura distribuita di Git . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Funzionalità di Basecamp . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.7 Logo di Atlassian Confluence . . . . . . . . . . . . . . . . . . . . . . . . 7
1.8 Interfaccia di Swagger . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Funzionamento di Amazon Comprehend . . . . . . . . . . . . . . . . . 20
3.2 Schermata di login da browser e da mobile . . . . . . . . . . . . . . . . 26
3.3 Home page da browser e da mobile . . . . . . . . . . . . . . . . . . . . 27
3.4 Schermata di trascrizione standup . . . . . . . . . . . . . . . . . . . . . 28
3.5 Schermata registratore . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6 Schermata dei dettagli di una standup . . . . . . . . . . . . . . . . . . . 30
6.1 Schermata dei dettagli dell’istanza di Amazon EC2 . . . . . . . . . . . 47
6.2 Schermata ricca di grafici sulle statistiche dell’istanza di Amazon EC2 48
6.3 Lista dei ruoli su IAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.4 Lista delle regole su IAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.5 Schermata di un ruolo su IAM . . . . . . . . . . . . . . . . . . . . . . . . 49
6.6 Schermata di una regola su IAM . . . . . . . . . . . . . . . . . . . . . . 49
6.7 Schermata di esempio del bucket . . . . . . . . . . . . . . . . . . . . . . 49
6.8 Schermata delle regole del bucket . . . . . . . . . . . . . . . . . . . . . . 50
6.9 Schermata delle configurazioni CORS del bucket . . . . . . . . . . . . . 50
6.10 Schermate delle tabelle su DynamoDB . . . . . . . . . . . . . . . . . . . 51
6.11 Schermata dell’ Authorizer di Amazon API Gateway . . . . . . . . . . 52
6.12 Schermata d’esempio di un metodo di Amazon API Gateway . . . . . 52
6.13 Schermata di configurazione di una stage di Amazon API Gateway . . 53
6.14 Schermata d’esempio di un modello di Amazon API Gateway . . . . . 53
6.15 Schermata iniziale di Amazon CloudWatch . . . . . . . . . . . . . . . . 54
6.16 Schermate d’esempio dei log di Amazon CloudWatch . . . . . . . . . . 55
6.17 Schermate d’esempio dei grafici di Amazon CloudWatch . . . . . . . . 56
6.18 Altre schermate d’esempio dei grafici di Amazon CloudWatch . . . . . 57
6.19 Schermata d’esempio dell’evento schedulato di Amazon CloudWatch . 57
6.20 Schermate d’esempio degli allarmi di Amazon CloudWatch . . . . . . 58
6.21 Dettaglio della configurazione dei log di Amazon Lambda . . . . . . . 59
6.22 Dettaglio dell’editor e dell’upload della funzione di Amazon Lambda 59
ix
x ELENCO DELLE FIGURE
6.23 Dettaglio della configurazione di Amazon API Gateway su Amazon
Lambda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.24 Dettagli della dashboard di Amazon Lambda . . . . . . . . . . . . . . . 60Elenco delle tabelle
2.1 Piano di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1 Alcuni test dei servizi di trascrizione . . . . . . . . . . . . . . . . . . . . 36
5.2 Alcuni test sull’influenza della qualità audio nella trascrizione . . . . . 37
5.3 Alcuni test sulle registrazioni di madrelingua inglese . . . . . . . . . . 43
5.4 Un test sulla trascrizione in italiano . . . . . . . . . . . . . . . . . . . . . 44
5.5 Alcuni estratti di altri test effettuati . . . . . . . . . . . . . . . . . . . . . 45
xiCapitolo 1
Contesto Aziendale
Questo capitolo intende descrivere l’azienda in cui ha trovato collocazione lo stage.
1.1 L’azienda
Zero12 s.r.l. nasce come startup nel 2012. Si occupa di realizzare soluzioni software
su misura per accompagnare i clienti in un percorso di innovazione incentrato su
soluzioni mobile e orientato ai servizi cloud con processi di miglioramento continuo.
figura 1.1: Logo di Zero12 s.r.l.
Fonte: http://www.zero12.it/
La sede operativa di Zero12, nella quale ho svolto lo stage, si trova presso Villa Spessa
a Carmignano di Brenta (PD). La stessa sede ospita anche le altre due aziende del
Gruppo Allos, di cui Zero12 fa parte: Allos S.p.A. e Nextep. La prima si occupa di
sviluppo del capitale umano, mentre la seconda opera nel campo delle infrastrutture
IT, in particolare sistemistica e web design.
12 CAPITOLO 1. CONTESTO AZIENDALE
figura 1.2: Logo di Allos S.p.A. e di Nextep
Fonte: http://www.allos.it/ e http://www.nextep.it/
1.2 Dominio applicativo
Zero12 offre ai propri clienti soluzioni informatiche innovative e personalizzate, ge-
stendo i progetti partendo dalla fase di onboarding. Ciò permette di collaborare a
stretto contatto con i clienti, conoscere le loro esigenze ed il mercato e creare una rela-
zione professionale basata su obiettivi e strategie condivisi. Nella fase di onboarding,
il team di Zero12 e quello del cliente si incontrano per delineare obiettivi, specifiche di
progetto, metodologie di lavoro, tempi e modi di rilascio del prodotto.
Il dominio applicativo di Zero12 si sviluppa su 3 assi principali:
∗ progettazione e sviluppo di mobile app su piattaforme iOS e Android;
∗ consulenza ad aziende sull’attivazione di processi di data mining al fine di
valorizzare i Big Data a loro disposizione;
∗ sviluppo software personalizzato, sia in ambito B2B che B2C, basato su sistemi
cloud.
1.2.1 Mobile app
L’impiego di dispositivi mobile è sempre più diffuso e la richiesta da parte dell’utente
finale di soluzioni e servizi da usare in mobilità è in costante crescita. Zero12 sviluppa
mobile app su piattaforme Android e iOS destinate sia al supporto dei processi
aziendali sia all’utilizzo da parte dell’utente finale. Per lo sviluppo vengono impiegati
sia linguaggi di programmazione nativi sia linguaggi cross-platform, in base alle
necessità.
Al fine di realizzare soluzioni mobile efficienti e massimizzare la user experience,
l’azienda implementa un’architettura a supporto basata su microservizi in modo da
poter realizzare soluzioni lato server in tempi e costi contenuti.
1.2.2 Data analysis
Zero12 offre servizi di consulenza in campo data analysis, per accompagnare le
aziende nel passaggio da un approccio basato su delle intuizioni imprenditoriali ad
un approccio data-driven. Questo servizio si basa sull’utilizzo dei big data raccolti
negli anni dalle aziende dai quali estrarre valore attivando processi di data mining,
permettendo alle aziende di conoscere meglio i propri consumatori al fine di prendere
le decisioni giuste al momento giusto.1.3. TECNOLOGIE AZIENDALI 3
1.2.3 Sviluppo software personalizzato
L’azienda applica i principi alla base dell’ingegneria del software per realizzare solu-
zioni efficienti, modulabili ed automatizzate. I principi applicati sono l’apprendimento
costante, continuous delivery , innovazione responsabile e agilità. Basandosi su tali
principi, Zero12 progetta e sviluppa soluzioni digitali collaborando con il cliente per
identificare le soluzioni innovative più adatte alle sue esigenze e al suo contesto di
riferimento.
Inoltre Zero12 affianca i clienti nel processo di migrazione, progettazione e realizzazio-
ne di infrastrutture cloud scalabili e serverless basate su tecnologia AWS a supporto di
progetti in qualsiasi ambito digitale che necessiti di un sistema informativo strutturato,
come ad esempio ambiti web, mobile, e-commerce, Internet of Things e Big Data.
1.3 Tecnologie aziendali
Zero12 vanta una estensiva esperienza su una vasta gamma di tecnologie, come ad
esempio Amazon Web Services, MongoDB e Hadoop.
Inoltre, per lo sviluppo utilizza diversi linguaggi di programmazione come Java, Scala,
Python, Node.js, Swift, ecc.
L’azienda però, vista la forte spinta innovativa, punta sempre a valutare le nuove tec-
nologie per poter essere sempre aggiornata e pronta a trasformare la novità in valore
per i clienti. Questo è reso possibile dall’ambiente dinamico e rilassato incentrato sulla
sperimentazione: i membri dei team di Zero12 sono incoraggiati a sperimentare e a
condividere quanto hanno appreso.
In ogni caso, indipendentemente dalla tecnologia impiegata, l’azienda preferisce
utilizzare:
∗ tecnologie open source: permettono di ridurre l’investimento iniziale e di evitare
il vendor lock-in
∗ framework leggeri ed agili: permettono di sviluppare soluzioni verticalizzate
sulla singola necessità (ottica di sviluppo a microservizi), accelerando lo stu-
dio sulla tecnologia e quindi i tempi di sviluppo della soluzione. In quanto
framework leggeri e semplici, garantiscono velocità e tempi di sviluppo rapidi
∗ architetture semplici: le architetture a microservizi, a differenza dei sistemi
monolitici, garantiscono sviluppi agili e veloci, indipendenza delle soluzioni e
la possibilità di scegliere le tecnologie più adeguate alle esigenze
Infine, Zero12 è partner di:
∗ AWS, l’infrastruttura di servizi cloud fondata nel 2012 da amazon.com
∗ MongoDB, un database open source non relazionale che permette di gestire
modelli di dati flessibili, non strutturati ed in grado di evolvere rapidamente
secondo le necessità del software4 CAPITOLO 1. CONTESTO AZIENDALE
figura 1.3: I partner di Zero12
Fonte: https://aws.amazon.com/it/ e https://www.mongodb.com/
1.4 Processi Aziendali
Zero12 adotta una metodologia di sviluppo agile , il framework Scrum. Esso offre il
vantaggio di lavorare a stretto contatto con il cliente, permettendo di avere frequenti
feedback sul lavoro svolto. Questo permette di individuare nuove necessità che non
erano emerse nell’analisi iniziale e identificare, correggere o sopperire a eventuali
mancanze e difetti in modo tempestivo.
1.4.1 Framework Scrum
Scrum è un framework pensato per gestire lo sviluppo di progetti software complessi.
Il metodo prevede la suddivisione del lavoro in blocchi di dimensione contenuta
detti sprint, della durata di 2-4 settimane. Al termine di ognuna di queste iterazioni
vengono rilasciate le nuove funzionalità sviluppate.
Questo consente al cliente di poter sempre visionare lo stato attuale del prodotto e di
testare le nuove funzionalità incremento dopo incremento, fino al raggiungimento del
prodotto finale.
Il cliente può quindi esprimere frequenti feedback sul prodotto ed individuare even-
tuali necessità che non erano, fino a quel momento, ancora emerse.
figura 1.4: Il framework Scrum
Fonte: https://www.htgsoft.com/pf/mobile-applications-development/1.4. PROCESSI AZIENDALI 5
Le componenti principali di questo metodo di sviluppo sono:
∗ product backlog: insieme di tutti i requisiti individuati per lo sviluppo del
prodotto ordinati per priorità, calcolata tenendo in considerazione i rischi ad
essi associati ed il valore aggiunto
∗ sprint backlog: sottoinsieme di requisiti del product backlog che verranno
soddisfatti durante lo svolgimento dello sprint successivo
∗ sprint: fase operativa durante la quale avviene lo sviluppo del prodotto per
soddisfare i requisiti inclusi nello sprint backlog. Le attività vengono suddivise
in piccoli task che possono essere assegnati ad una singola persona
Inoltre, come descritto in precedenza, questo metodo prevede frequenti incontri o
riunioni per discutere lo stato di avanzamento. Possono essere divisi in tre categorie:
∗ precedentemente ad uno sprint: il team di sviluppo si riunisce per pianificare lo
sprint. Seleziona quali attività del product backlog verranno eseguite nel corso
dello sprint e costruisce lo sprint backlog
∗ durante lo sprint: il team esegue uno stand-up meeting giornaliero in cui tutti i
componenti vengono messi al corrente del lavoro svolto il giorno precedente da
ciascun membro e di cosa ognuno pianifica di fare il giorno corrente
∗ al termine di uno sprint: il team esegue lo sprint review in cui rivede e presenta
al cliente il lavoro svolto e lo sprint retrospective in cui riflette sullo sprint ap-
pena terminato ed identifica e discute i miglioramenti da apportare ai processi
produttivi. Inoltre, da queste due riunioni possono emergere eventuali perfe-
zionamenti al product backlog, ai requisiti che esso contiene e alle loro priorità
(backlog grooming)
Per tenere traccia dello stato di avanzamento, del product backlog e dello sprint
backlog viene impiegata la sprint board: un grafico suddiviso in 5 colonne su cui
sono visivamente riportate tutte le attività del progetto (ad esempio usando dei post-it
colorati).
Le 5 colonne sono:
backlog to do doing testing done
La sprint board è molto utile perché permette di avere sempre a disposizione lo stato
del progetto, sia durante lo sviluppo che durante le riunioni.
In Zero12 le sprint board sono disegnate con i pennarelli sulle finestre dell’ufficio e i
requisiti vengono riportati su dei post-it colorati.
Il mio progetto riguarda proprio i standup meeting giornalieri che l’azienda svolge.
1.4.2 Strumenti a supporto dei processi
Versionamento
Per il versionamento del codice Zero12 utilizza git e per i repository remoti si appoggia
ad AWS CodeCommit.6 CAPITOLO 1. CONTESTO AZIENDALE
figura 1.5: Architettura distribuita di Git
Fonte: https://www.edureka.co/blog/what-is-git/
Git è un software di controllo di versione distribuito, cioè mantiene una copia locale
del repository nei dispositivi di ogni collaboratore, rendendo non necessario un server
centrale. Grazie all’architettura distribuita di git, gli sviluppatori possono lavorare
con la copia locale del repository anche se non dispongono di una connessione ad
internet e periodicamente sincronizzare i cambiamenti da loro effettuati con quelli
degli altri membri del team. Inoltre l’esistenza di più copie del repository proteggono
il progetto dai danni causati da un eventuale guasto o malfunzionamento del server
centrale.
Gestione di progetto
Per gestire il progetto e coordinare i membri del team l’azienda usa Basecamp.
Questa piattaforma offre funzionalità di supporto all’organizzazione, alla gestione e
al coordinamento del lavoro.
Le principali funzionalità offerte sono:
∗ servizio di chat (campfire)
∗ sistema di messaggi simile ad un forum (message board)
∗ to-do list
∗ condivisione di file
∗ gestione delle milestone
∗ pianificazione di attività ed eventi (schedule)1.4. PROCESSI AZIENDALI 7
figura 1.6: Funzionalità di Basecamp
Fonte: https://basecamp.com/
Documentazione
La documentazione è una parte fondamentale di ogni progetto. È importante utiliz-
zare strumenti che rendano semplice ed agevole la scrittura e la consultazione dei
documenti. Per garantire ciò Zero12 si affida a due strumenti: Atlassian Confluence e
SwaggerHub.
Confluence viene usato per redigere e consultare la documentazione tecnica del
progetto. Tra le funzionalità offerte presenta un editor che permette la scrittura e la
formattazione dei documenti e la gestione dei permessi in lettura e scrittura dell’intero
documento o delle sue singole parti.
figura 1.7: Logo di Atlassian Confluence
Fonte: https://it.atlassian.com/software/confluence8 CAPITOLO 1. CONTESTO AZIENDALE
SwaggerHub viene usato per la progettazione e la documentazione di API. Que-
sto strumento permette di descrivere e documentare le API seguendo la specifica
OpenAPI Specification (https://swagger.io/specification/) e di visualizzare una
documentazione interattiva creata in modo automatico a partire dalla descrizione
inserita.
figura 1.8: Interfaccia di Swagger
Fonte: https://swagger.io/tools/swagger-editor/Capitolo 2
Progetto nella strategia
aziendale
Questo capitolo tratta della scelta dello stage e delle varie informazioni presenti prima di
iniziare effetivamente lo stage.
2.1 Rapporto tra azienda e stage universitari
Ospitare dei progetti di stage universitario comporta molti vantaggi per Zero12.
Innanzitutto permette di inserire nell’ecosistema aziendale persone provenienti dal-
l’ambiente accademico, con punti di vista ed idee diverse da cui possono scaturire
confronti costruttivi e stimolanti. Gli studenti universitari infatti si ritrovano spesso
ad entrare in contatto con le ultime novità in tema di tecnologie e di strumenti, spe-
cialmente open source, principalmente grazie al progetto didattico previsto dal corso
di Ingegneria del software.
Inoltre i progetti di stage possono diventare un’opportunità per l’azienda per speri-
mentare una nuova tecnologia, studiarne le possibilità e i vantaggi e testarne i limiti.
Impiegare uno stagista universitario in questi progetti sperimentali consente di valu-
tare le potenzialità di una o più tecnologie per capire se sono promettenti e meritevoli
di essere adottate, prima di investire delle significative risorse aziendali su di esse.
Questi fattori aiutano l’azienda a restare sempre al passo con le novità tecnologiche
ed in grado di concepire soluzioni innovative ai problemi dei clienti.
Infine l’esperienza formativa del tirocinio, oltre agli ovvi vantaggi per lo studente
che ha la possibilità di entrare in contatto con le dinamiche e le aspettative del mon-
do del lavoro, permette a Zero12 di conoscere e mettere alla prova le competenze e
l’attitudine degli stagisti al fine di un eventuale successivo inserimento nell’azienda.
2.2 Presentazione del progetto
Ho conosciuto l’azienda Zero12 grazie ad un collega che dopo essersi laureato è stato
assundo dalla stessa. Non riuscendo a completare gli esami necessari per fare lo stage
in tempo però non ho potuto usufruire di stageIT e così ho contattato personalmente
l’azienda per capire se era possibile fare uno stage durante il periodo invernale.
910 CAPITOLO 2. PROGETTO NELLA STRATEGIA AZIENDALE
Per questo il progetto che ho eseguito non è compreso nei progetti di stage pre-
sentati dall’azienda a StageIT ma è stato tratto dai capitolati prosposti per i progetti
del corso di ingegneria del software. Lo scopo del progetto era uno studio sulla fattibi-
lità e la realizzazione di un sistema che, per quanto rudimentale, permettesse in modo
automatico di trascrivere l’audio di un standup meeting in testo e successivamente
analizzarlo per estrarre informazioni sullo stato del progetto e dettagli su eventuali
ritardi o problematiche incontrate.
Inoltre sono stato spinto ad utilizzare maggiormente i servizi offerti da Amazon Web
Services in quanto un mio collega, che aveva svolto lo stage precendetemente, aveva
gia utilizzato Google Cloud Platform fer fare analisi ed estrazione di informazioni dal
testo e l’azienda era interessata ad una valutazione comparativa delle soluzioni offerte
per lo stesso problema.
2.2.1 Cos’è una standup
La standup (o standup meeting o daily Scrum meeting) è una delle attività del fra-
mework Scrum. Si tratta di una riunione giornaliera durante la quale ogni componente
del team in un paio di minuti deve rispondere a tre domande:
∗ Cos’ha raggiunto rispetto all’ultimo meeting?
∗ Cos’ha intenzione di raggiungere entro il meeting successivo?
∗ Ci sono degli impedimenti ancora attivi per raggiungere gli obiettivi prefissati?
Ci sono molteplici modalità per eseguire questi meeting.
In Zero12 ho potuto notare che:
∗ Normalmente non viene svolta individualmente, ma vengono riunite le persone
che lavorano allo stesso progetto.
∗ A volte viene eseguita come monologo personale, a volte come domande-
risposte tra due persone.
∗ La durata è sempre breve, al massimo qualche minuto. Molte volte alcuni
componenti del team si incontrano dopo il meeting per parlare più nello specifico
delle problematiche emerse
∗ Quasi sempre si lascia parlare chi ha preso la parola senza interromperlo.
2.2.2 Pianificazione
Le attività da svolgere nello stage sono state pianificate come indicato:2.3. ASPETTATIVE AZIENDALI 11
Settimana Attività Periodo
1 Introduzione ai servizi Google Cloud Platform e 5 Feb - 9 Feb
Amazon Web Services. Studio del linguaggio di
programmazione Python
2 Analisi e studio dei servizi offerti dalle Natural 12 Feb - 16 Feb
Language API di Google Cloud Platform
3 Sviluppo del sistema di registrazione (web app, 19 Feb - 23 Feb
mobile app o skills su Amazon Echo) standup
4 Sviluppo conversione audio in testo 26 Feb - 2 Ma
5 Sviluppo, interpretazione e classificazione dello 5 Mar - 9 Mar
standup
6 Sviluppo, interpretazione e classificazione dello 12 Mar - 16 Mar
standup
7 Sviluppo, interpretazione e classificazione del- 19 Mar - 23 Mar
lo standup e sviluppo dashboard web per la
visualizzazione dei risultati
8 Sviluppo dashboard web per la visualizzazione 26 Mar - 30 Mar
dei risultati
tabella 2.1: Piano di lavoro
2.3 Aspettative aziendali
L’azienda era interessata ad un confronto tra le tecnologie offerte da Google Cloud
Platform e Amazon Web Services. La Google Cloud Platform era stata utilizzata
dal collega che aveva svolto lo stage in Zero12 prima di me per eseguire un’analisi
del testo delle email, mentre io ho dovuto analizzare le soluzioni software offerte
da Amazon Web Services. In particolare ho dovuto analizzare l’affidabilità della
trascrizione da audio a testo di Amazon Transcribe.
2.4 Obiettivi del progetto
Gli obiettivi per il progetto derivano dal piano di lavoro e dalle riunioni tenute con
il tutor aziendale all’inizio dello stage. Essi sono divisi in obiettivi minimi, obiettivi
massimi e obiettivi formativi.
Obiettivi minimi
∗ realizzazione di un sistema di registrazione per la standup utilizzabile su iOS e
Android e, se possibile, su Amazon Echo
∗ realizzazione di uno o più microservizi per la trascrizione e analisi della standup
∗ realizzazione di una dashboard per la visualizzazione dei dati ricavati nel punto
precedente
∗ documentazione tramite swagger dei microservizi sviluppati
Obiettivi massimi
∗ analisi approfondita delle tecnologie utilizzate e valutazione della loro capacità
a svolgere con successo i lavori richiesti12 CAPITOLO 2. PROGETTO NELLA STRATEGIA AZIENDALE
Obiettivi formativi
Gli obiettivi formativi di questa esperienza di stage sono:
∗ apprendere un nuovo linguaggio di programmazione: Python
∗ apprendere nuove metodologie di sviluppo
∗ avvicinarsi ai servizi cloud offerti da Amazon Web Services e Google Cloud
Platform per capirne le potenzialità, i vantaggi, gli svantaggi e le differenze
∗ studiare e provare i servizi di intelligenza artificiale e NLP di Amazon e Google
∗ entrare in contatto e collaborare con un team di sviluppo esperto
2.5 Vincoli
2.5.1 Vincoli metodologici
Il progetto di stage sì è svolto per la sua intera durata presso la sede dell’azienda a
Carmignano di Brenta.
Questa decisione è stata presa in comune con il tutor aziendale allo scopo di inserirmi
nel contesto dei team di sviluppo dell’azienda. Ho avuto così modo di confrontarmi
con sviluppatori esperti e ho potuto interagire con il tutor aziendale per risolvere pro-
blematiche di natura tecnica e dubbi riguardanti i requisiti o la gestione del progetto.
Inoltre ha reso possibile lo svolgimento degli stand-up meeting giornalieri previsti
dalla metodologia di sviluppo Scrum, che è anche oggetto di questo progetto.
2.5.2 Vincoli temporali
La durata dello stage è stata di otto settimane, per la durata complessiva di 320 ore.
Ho lavorato secondo gli orari che seguono i dipendendi dell’azienda, a tempo pieno,
dal lunedì al venerdì anche se l’azienda lavora anche il sabato mattina, dalle ore 8:30
alle ore 18:00 con pausa pranzo dalle 13:00 alle 14:00.
Inoltre erano presenti due pause obbligatorie di quindici minuti alle 10:45 e alle 15:45.
Come descritto nel piano di lavoro dello stage, per lo svolgimento del progetto il mio
tutor ha deciso di dividere le otto settimane di stage in diverse fasi:
∗ due settimana di studio della tecnologie e del linguaggio di programmazione
che non avevo mai utilizzato;
∗ una settimana per la realizzazione di un sistema di registrazione audio;
∗ una settimata per la realizzazione del microservizio per la conversione audio in
testo;
∗ due settimane e mezza per la realizzazione dei microservizi necessari all’inter-
pretazione e alla classificazione dei testi ottenuti;
∗ l’ultima settimana e mezza per la realizzazione della dashboard per visualizzare
i risultati dei microservizi sopra realizzati.2.5. VINCOLI 13 2.5.3 Vincoli tecnologici In azienda mi è stata data una scrivania con un pc Mac ed era presente anche un dispositivo Amazon Echo; inoltre erano reperibili i progetti dei colleghi che avevano svolto lo stage in Zero12. Per le comunicazioni sono stato invitato in un progetto di Basecamp, dove a fine stage ho caricato i prodotti realizzati e la documentazione delle API esposte dai servizi, utilizzando la specifica OpenAPI Specification e il servizio SwaggerHub.
Capitolo 3
Resoconto del progetto
Questo capitolo parla delle attività che hanno portato alla realizzazione dei prodotti richiesti
del progetto di stage.
3.1 Analisi dei rischi
Nel corso di una delle riunioni effettuate con il tutor aziendale all’inizio dello stage
abbiamo individuato i rischi legati al mio progetto e analizzato quale impatto avreb-
bero potuto avere sul buon esito delle attività.
I rischi individuati possono essere raggruppati in tre categorie:
∗ rischi tecnologici: tutti i rischi associati all’utilizzo delle tecnologie. Questi
rischi sono molteplici perché nel corso del progetto di stage ho avuto modo di
utilizzare tecnologie con cui non avevo alcuna esperienza precedente, trovan-
domi quindi a dover imparare da zero. Oltre a ciò, la natura sperimentale del
progetto ha come conseguenza il fatto che molte delle tecnologie in questione
non sono ancora mature, presentano dei malfunzionamenti o delle imperfezioni,
la loro documentazione è carente o parziale o addirittura sono prodotti anco-
ra in fase di sviluppo. Questa categoria di rischi è stata affrontata prestando
particolare attenzione alle tecnologie a rischio nel corso delle due settimane di
formazione. I rischi derivanti da tecnologie incomplete non hanno potuto essere
risolti;
∗ rischi organizzativi: tutti i rischi associati alla pianificazione delle attività, al-
l’organizzazione del lavoro e ad eventuali impegni lavorativi del tutor aziendale
che gli impediscono di essere disponibili per riunioni e domande. I rischi ap-
partenenti a questa categoria possono impattare i tempi di sviluppo e il rispetto
delle scadenze previste dalla pianificazione. Essi sono stati affrontati adattando
la pianificazione delle attività nel corso degli stand-up meeting giornalieri tenen-
do conto di eventuali ritardi e problematiche nell’attività di sviluppo. I rischi
relativi agli impegni lavorativi del tutor aziendale invece sono stati affrontati
pianificando le riunioni, qualora possibile, in momenti in cui il tutor era libero
da impegni e, nel caso di domande o dubbi urgenti, comunicando tramite posta
elettronica e Basecamp;
∗ rischi sui requisiti: tutti i rischi associati ad una parziale o errata comprensione
dei requisiti e delle funzionalità richieste o del dominio applicativo. Questi rischi
1516 CAPITOLO 3. RESOCONTO DEL PROGETTO
possono impattare sulla buona riuscita del progetto in quanto, se non affrontati
e risolti, possono portare ad un prodotto incompleto o che presenta funzionalità
non richieste. Questa categoria di rischi è stata affrontata tramite riunioni con il
tutor aziendale in cui abbiamo discusso delle funzionalità richieste e tramite gli
stand-up meeting giornalieri.
3.2 Scelta delle tecnologie
3.2.1 Introduzione
All’inizio dello stage ho svolto alcune riunioni con il tutor aziendale per pianificare
le attività da svolgere e le tecnologie più interessanti su cui concentrarsi nelle prime
settimane di studio e analisi.
L’azienda mi ha indirizzato maggiormente verso la scelta delle tecnologie offerte
da Amazon Web Services e invitato ad utilizzare i servizi offerti da Google Cloud
Platform solo a scopo di confronto.
La scelta finale sulle tecnologie da utilizzare è stata lasciata a me, ma il tutor aziendale
mi ha consigliato AWS Transcribe per la trascrizione audio in testo e AWS Comprehend
per l’analisi e la comprensione del linguaggio naturale in modo automatico.
Dal punto di vista dell’infrastruttura mi è stato consigliato il servizio AWS Lambda
per i microservizi da sviluppare, AWS S3 per l’archiviazione dei dati più grandi come
le registrazioni audio e AWS DynamoDB nel caso fosse necessario l’utilizzo di un
database.
3.2.2 Tecnologie approfondite
Innanzitutto ho studiato il linguaggio di programmazione Python utilizzando la
documentazione presente nel sito ufficiale. Oltre al linguaggio ho studiato anche tre
moduli per Python:
∗ Flask
∗ Requests
∗ Boto3
Successivamente ho studiato i servizi offerti da Amazon Web Services e brevemente
alcuni da Google Cloud Platform:
∗ Amazon Alexa per la creazione di una skill che registrasse lo standup meeting e
successivamente Amazon EC2 per l’infrastruttura della webapp;
∗ Amazon Transcribe e l’alternativa Google Cloud Speech, per la trascrizione
dell’audio registrato in testo;
∗ Amazon S3 e DynamoDB per la memorizzazione dei dati;
∗ Amazon Comprehend e l’alternativa Google Cloud Natural Language per
eseguire machine learning sul testo ed estrarre le informazioni volute;
∗ Amazon Lambda, Amazon API Gateway e Amazon IAM per l’infrastruttura dei
microservizi;
∗ Amazon CloudWatch per raccogliere log e statistiche dei vari servizi AWS
utilizzati.3.2. SCELTA DELLE TECNOLOGIE 17
Python
Python è un linguaggio di programmazione ad alto livello orientato agli oggetti ed è
stato scelto perché è un linguaggio di scripting che offre ottime prestazioni se usato
per le funzioni su AWS Lambda e presenta una grande quantità di librerie gratuite.
Nel corso dello stage è stato usato sia come linguaggio per la webapp, sia come lin-
guaggio di script per le funzioni Lambda che compongono i microservizi sviluppati.
Grazie alla sua naturta di linguaggio orientato agli oggetti non è stato difficile impa-
rarlo dopo aver seguito il corso di Programmazione ad oggetti.
Skill per Alexa
Amazon Alexa è un assistente personale intelligente sviluppato da Amazon, utilizzato
per la prima volta nei dispositivi Amazon Echo e Amazon Echo Dot sviluppati dalla
sezione Amazon Lab126. È in grado di interagire con la voce, riprodurre musica,
creare elenchi di cose da fare, impostare allarmi, effettuare streaming di podcast,
riprodurre audiolibri e fornire previsioni meteorologiche, informazioni sul traffico e
altre informazioni in tempo reale, come le notizie.
Alexa può anche controllare diversi dispositivi intelligenti usando se stesso come
sistema di automazione domestica per la gestione della domotica.
La maggior parte dei dispositivi dotati di Alexa consente agli utenti di attivare il
dispositivo usando una sveglia (come Echo); altri dispositivi (come l’app Amazon su
iOS o Android) richiedono all’utente di premere un pulsante per attivare la modalità
di ascolto di Alexa.
Inizialmente il tutor aveva proposto di creare una skill, traducibile con l’idea di
un’applicazione personalizzata per Alexa, per poter così sedersi attorno ad un tavolo
durante la standup, attivare vocalmente la registrazione e poi lasciare che automatica-
mente Alexa si occupasse di inviarla.
Dopo aver studiato come creare una Skill e le varie limitazioni presenti questa idea è
stata scartata in quanto, allo stato attuale, non è disponibile la funzione di registrazio-
ne e invio audio tramite Alexa ma esso viene direttamete analizzato per estrarre dei
comandi e chiamare specifiche funzioni.
Webapp
Eliminata l’opzione di utilizzare Alexa come dispositivo di registrazione, l’azienda ha
richiesto lo sviluppo di una webapp che fosse stata utilizzabile sia su dispositivi iOS
che Android. Ho scelto di scrivere questa webapp in Python visto che è il linguaggio
che avrei dovuto utilizzare anche per il resto del progetto. In questo modo, a mio
avviso, ho potuto sfruttare al meglio il periodo di studio delle tecnologie.
Durante questo periodo ho anche individuato dei moduli per Python che mi sarebbero
serviti:
∗ il modulo Flask: un framework web leggero per la realizzazione di web ap-
plication in modo facilitato ed è basato sullo strumento Werkzeug WSGI che
permette le comunicazioni ed interazioni tra server ed applicazioni e con il
motore template Jinja2 per la creazione di file HTML;
∗ il modulo Requests: una liberia che facilita l’utilizzo del protocollo HTTP per la
comunicatione tra applicativi differenti, da utilizzare per connettersi con l’API
dei servizi che avrei realizzato nella seconda parte dello stage.18 CAPITOLO 3. RESOCONTO DEL PROGETTO Oltre a Python ho dovuto ripassare ed approfondire la mia conoscenza su Angular e Javascript per la parte client della Webapp e individuare delle librerie che mi perme- tessero l’acquisizione audio su vari dispositvi con sistemi operativi così differenti. Inoltre ho scelto di Utilizzare, sotto consiglio del tutor, Amazon EC2 come sistema su cui far eseguire la webapp. Microservizi Lo studio dei servizi offerti da Amazon Web Services e Google Cloud Platform ha occupato gran parte delle due settimane impiegate allo studio delle tecnologie. Inizialmente ho concentrato la mia attenzione ai servizi di trascrizione audio, Amazon Transcribe e Google Speech: entrambi permettono la trascrizione di audio in testo, ma mentre il servizio offerto da Google è disponibile da più tempo e abbastanza affidabile, quello offerto da Amazon è disponibile solo per l’inglese e lo spagnolo ed è disponibile ai sviluppatori in versione Alpha. Successivamente mi sono concentrato a studiare Amazon Comprehend e Google Cloud Natural Language utili per eseguire data mining ed è evidente che i servizi Google sono più avanzati di quelli di Amazon, almeno rispetto all’analisi di audio e testo. Come servizio di salvataggio delle registrazioni ho deciso di studiare ed utilizzare Amazon Simple Storage Service (S3) mentre per il salvataggio delle informazioni raccolte dal testo della standup ho scelto di usare Amazon DynamoDB. Amazon Lambda è stato scelto come ambiente serverless su cui far eseguire le funzioni dei microservizi, mentre Amazon API Gateway viene utilizzato per gestire l’accesso ai microservizi tramite API e AWS Identity and Access Management (IAM) viene utilizzato per la gestione dei permessi e la regolazione degli accessi il vari servizi AWS sia dalle funzioni Lambda che dalla webapp sviluppata. Infine viene scelto di utilizzare Amazon CLoudWatch per il controllo delle varie stati- stiche raccholte dai servizi AWS e per la gestione dei log. Boto3 è un SDK per gli Amazon Web Services per Python; permette l’utilizzo dei ser- vizi Amazon attraverso delle API orientate agli oggetti e quindi facilitare lo sviluppo delle funzioni lambda. 3.3 Progettazione In questa sezione parlo delle scelte progettuali che ho compiuto durante lo stage, suddividendole tra loro in base a quale prodotto fanno parte. 3.3.1 Ajarvis WebApp Ajarvis Webapp è l’applicazione web che ho sviluppato. Per renderla utilizzabile sia da browser desktop che da browser mobile ho scelto di utilizzare Bootstrapt per un layout responsive che si adattasse alla grandezza dello schermo, che varia in base al modello di dispositivo mobile utilizzato. Questo, unito all’utilizzo della libreria recorder (https://github.com/mattdiamond/Recorderjs) per registrare l’audio e convertirlo in un file .wav che permetta di utilizzare l’applicazione in tutti i dispositivi mobile più recenti.
3.3. PROGETTAZIONE 19
La gestione del registratore, dall’inizio della registrazione fino all’invio del file su
Amazon S3 avviene tutta in background su lato client, tramite dei script Javascript
così da rendere l’utilizzo dell’applicazione più piacevole. Ovviamente tutti gli script
Javascript vengono minificati per mantenere la dimensione il minore possibile e velo-
cizzare così il caricamento dell’applicazione.
Inoltre l’applicazione è stata sviluppata pensando ad una possibile estensione e il
codice è stato separato in varie cartelle.
∗ Nella cartella api sono inseriti i file Python necessari alla Webapp per eseguire:
al suo interno contiene lo scrip per minificare, il file app.py dove si definisce
l’applicazione e i collegamenti delle routes e la cartella resources che contiene
i vari files separati per contesto, quali ad esempio detail.py, per la visualiz-
zazione dei dettagli e upload.py per il caricamento del file audio o testo della
standup.
∗ Nella cartella config sono presenti i file di configurazione JSON, tra cui le infor-
mazioni degli account della webapp e le informazioni di accesso all’API, quali
username, password e indirizzo di dove trovarla.
∗ Nella cartella static sono presenti i file CSS dell’applicazione e la catella script
in cui si possono trovare i file Javascript.
∗ Infine nella cartella template sono presenti i template delle varie pagine HTML,
che verrano poi utilizzati dal modulo Jinja2 di Flask per generare dinamicamente
le pagine dell’applicazione.
Amazon EC2
Amazon Elastic Compute Cloud (Amazon EC2) è un servizio Web che fornisce capacità
di elaborazione sicura e scalabile nel cloud. Viene utilizzato come sistema in cui
esegure l’applicazione web. Amazon EC2 permette la gestione e il monitoraggio
tramite una dashboard web, di cui le immagini sottostanti mostrano una panoramica.
Inoltre sono disponibili i grafici sulle varie statistiche rilevate grazie ad Amazon
CloudWatch.
3.3.2 Ajarvis
Ajarvis è l’applicativo dei microservizi creati a cui si connette Ajarvis Webapp. Succes-
sivamente descriverò come sono stati usati i vari servizi Amazon.
Amazon Transcribe
Amazon Transcribe è il servizio di trascrizione audio in testo offerto da Amazon
Web Service ed è disponibile al momento solo per sviluppatori e solo in fase di test,
in quanto non viene assicurato che la trascrizione avvenga in tempo breve (alcune
trascrizioni hanno richiesto più di 300 secondi e una più di 15 minuti) o che abbia
esito favorevole (molte operazioni di trascrizione sono fallite).
La necessità di controllare periodicamente se i lavori di trascrizione avessero termi-
nato ha portato alla creazione di un evento schedulato, che ogni 5 minuti chiamasse
l’esecuizione di una funzione Lambda apposita.
Un lavoro di trascrizione richiede un audio presente su S3 localizzato nella stessa20 CAPITOLO 3. RESOCONTO DEL PROGETTO
regione di Amazon Transcribe, che esssendo disponibile solo in una specifica regione
ha richiesto di localizzare tutti i servizi Amazon su US-EAST(Nord Virginia).
Amazon Comprehend
Amazon Comprehend è un servizio di elaborazione del linguaggio naturale (NLP)
che usa l’apprendimento automatico per trovare informazioni e relazioni in uno o più
testi. Amazon Comprehend identifica il linguaggio del testo, estrae le frasi chiave, i
luoghi, le persone, i marchi o gli eventi; capisce quanto il testo sia positivo o negativo
e organizza automaticamente una raccolta di file di testo per argomento.
Queste funzionalita si sono rivelate ancora poco affidabili ma sono fiducioso, visto
quanto AWS sta investendo in questi servizi, che miglioreranno velocemte.
Amazon Comporehend permette di individuare:
∗ entità
∗ frasi chiave
∗ linguaggio utilizzato
∗ sentimenti
∗ argomenti
Ho potuto notare che al momento il servizio è indirizzato più a tematiche di assistenza
automatica degli utenti o analisi di grandi quantità di dati di carattere generale, ma nel
sito di Amazon Comprehend scrivono chiaramente che sono rivolti anche all’analisi
delle trascrizioni telefoniche.
figura 3.1: Funzionamento di Amazon Comprehend
Fonte: https://aws.amazon.com/it/comprehend/?nc2=h_a1
Amazon IAM
AWS Identity and Access Management (IAM) consente di gestire in sicurezza l’accesso
ai servizi e alle risorse AWS. Grazie a IAM è possibile creare e gestire utenti e gruppi
AWS e utilizzare autorizzazioni per consentire o negare l’accesso alle risorse AWS.3.3. PROGETTAZIONE 21 Per i microservizi ho cercato di creare molte regole e ruoli, in modo di permettere l’esecuzione solo dei servizi che vengono effetivamente utilizzati e più nel dettaglio solo ad alcune operazioni specifiche. IAM lavora con ruoli e regole: i ruoli vengono associati ad entità quali per esempio funzioni lambda, mentre le regole sono permessi di granularità diversa, come per esempio scrivere su un database, controllare i lavori di trascrizione, ecc. In definitiva ho creato 9 ruoli, uno per ogni lambda realizzata e 19 regole. La nomenclatura nel progetto ha seguito la regola utente-progetto-entità RUOLI ∗ violetto-Ajarvis-lambda-authorizer ∗ violetto-Ajarvis-lambda-retrieve ∗ violetto-Ajarvis-lambda-scheduled-manager ∗ violetto-Ajarvis-lambda-transcriber ∗ violetto-Ajarvis-lambda-upload ∗ violetto-Ajarvis-lambda-analyzer ∗ violetto-Ajarvis-lambda-upload-text ∗ violetto-Ajarvis-lambda-project ∗ violetto-Ajarvis-lambda-download-audio REGOLE ∗ violetto-Ajarvis-get-users ∗ violetto-Ajarvis-write-logs ∗ violetto-Ajarvis-s3-write ∗ violetto-Ajarvis-scan-transcription-jobs ∗ violetto-Ajarvis-start-transcription-job ∗ violetto-Ajarvis-get-transcription-job ∗ violetto-Ajarvis-get-audio ∗ violetto-Ajarvis-get-transcription-job-table ∗ violetto-Ajarvis-update-transcription-job ∗ violetto-Ajarvis-put-standup ∗ violetto-Ajarvis-delete-transcription-job ∗ violetto-Ajarvis-scan-standup-table ∗ violetto-Ajarvis-query-standup-table ∗ violetto-Ajarvis-get-standup-table
22 CAPITOLO 3. RESOCONTO DEL PROGETTO
∗ violetto-Ajarvis-put-transcription-job-table
∗ violetto-Ajarvis-comprehend
∗ violetto-Ajarvis-get-transcribe-json
∗ violetto-Ajarvis-update-standups
∗ violetto-Ajarvis-get-comprehend-json
Amazon S3
Amazon S3 è uno storage di oggetti creato per memorizzare e ripristinare qualsiasi vo-
lume di dati da qualsiasi origine, permettendo di momorizzare grandissime quantita
di dati a basso prezzo (https://aws.amazon.com/it/s3/pricing/).
Nel progetto viene utilizzato memorizzare gli audio registrati e i file di trascrizione
creati da Amazon Transcribe; inoltre sono presenti alcuni file di dizionario usati dal-
l’algoritmo di data mining.
La struttura interna del bucket presenta due cartelle: comprehend che contiene i file
di dizionario e upload che contiene i file di registrazione e trascrizione. A sua volta ho
deciso che upload contenga una cartella per ogni singola webapp che utilizza questi
servizi, creando appunto la cartella AjarvisWebApp. Al suo interno sono presenti
i vari file con regole di nomenclatura anno-mese-giornoTore-minuti-secondi (es.
2018-03-21T17-01-41.wav).
Inoltre ho dovuto aggiungere delle politiche particolari al bucket per permettere
la scrittura da parte di servizi esterni come Amazon Transcribe e ad applicazioni
esterne come Ajarvis WebApp.
DynamoDB
Amazon DynamoDB è un servizio di database non relazionale veloce e flessibile
pensato per tutte le applicazioni che richiedono una latenza costante non superiore a
una decina di millisecondi su qualsiasi scala.
Viene utilizzato dai microservizi per immagazzinare le informazioni estratte dall’ana-
lisi della trascrizione.
Nel progetto ho utilizzato 3 tabelle:
∗ violetto-Ajarvis-users: per salvare i dati di accesso delle webapp che si connet-
tono ad Ajarvis, in questo caso solo Ajarvis WebApp;
∗ violetto-Ajarvis-transcription-jobs: per salvare temporaneamente i lavori di
trascrizione in corso, così da non dover recuperare la lista completa di tutti i
lavori eseguiti con Amazon Transcribe;
∗ violetto-Ajarvis-standups: dove salvare tutte le informazioni ricavate dall’ana-
lisi.
Amazon API Gateway
Amazon API Gateway è un servizio completamente gestito che semplifica agli svilup-
patori creazione, pubblicazione, manutenzione, monitoraggio e protezione delle API
su qualsiasi scala. Attraverso di esso è stato possibile creare le API dei microservizi3.3. PROGETTAZIONE 23
sviluppati con Amazon Lambda.
Per accedere alle funzioni è stato configurato un Authorizer utilizzando una funzione
Lambda apposita, ed avendo solo una tipologia di utenti che si connettono ho potuto
non utilizzare le funzioni avanzate di creazione di permessi personalizzati per accede-
re ai vari microservizi.
Inoltre ho utilizzato la funzionalità degli stage per poter continuare ad estendere i
microservizi sullo stage dev mentre l’API era utilizzabile sullo stage prod.
Ho utilizzato i modelli per eseguire un controllo su tutti i dati in ingresso ed in
uscita dalle API.
Amazon CloudWatch
Amazon CloudWatch è un servizio di monitoraggio per le risorse cloud AWS e le
applicazioni in esecuzione su AWS.
Nel progetto è stato utilizzato per monitorare i log delle varie funzioni lambda e le
statistiche dei vari dati raccolti sui servizi AWS quali latenza, chiamate effetuate alle
API, ecc.
Inoltre è stato creato un evento schedulato per chiamare l’esecuzione di una funzione
lambda ogni 5 minuti.
Amazon Lambda
AWS Lambda consente di eseguire codice senza dover effettuare il provisioning né
gestire server; le tariffe sono calcolate in base ai tempi di elaborazione, perciò non
viene addebitato alcun costo quando il codice non è in esecuzione. Le funzioni di
AWS Lambda sono identificate dal metodo def lambda_handler(event, context)
e ritornano un JSON che verrà analizzato e convertito da Amazon API Gateway.
Le funzioni Lambda sviluppate sono:
∗ violetto-Ajarvis-authorizer: metodo che viene chiamato automaticamente ad
ogni richiesta all’API da Amazon API Gateway e decide, controllando l’auten-
ticazione eseguita tramite BasicHTTPAuth se bloccare la richiesta o lasciarla
avvenire; utilizza una tabella su DynamoDB per memorizzare i dati di accesso
validi.
∗ violetto-Ajarvis-upload: metodo accessibile esternamente che permette il cari-
camento di un file audio da Ajarvis Webapp o un’altra applicazione autorizzata;
si occupa di rinominare il file .wav e di salvarlo sul backet di Amazon S3.
∗ violetto-Ajarvis-upload-text: metodo accessibile esternamente che permette il
caricamento di una trascrizione, salvandola sempre sul bucket di Amazon S3.
∗ violetto-Ajarvis-retrieve: metodo accessibile esternamente che analizza la ri-
chiesta di recupero informazioni di una o più standup e prepara una risposta
JSON appropriata con le informazioni richieste.
∗ violetto-Ajarvis-project: metodo accessibile esternamente che recupera infor-
mazioni generali sulle standup e prepara un JSON con le informazioni più
importanti dei progetti di cui sono disponibili una o più standup.
∗ violetto-Ajarvis-transcriber: metodo che viene triggerato automaticamente
ogni volta che un audio viene caricato sul bucket di Amazon S3. Si occupa24 CAPITOLO 3. RESOCONTO DEL PROGETTO
della creazione di un lavoro di trascrizione oppure mette il lavoro in attesa su
una tabella di DynamoDB nel caso ce ne siano troppi attivi allo stesso tempo.
∗ violetto-Ajarvis-scheduled-manager: metodo chiamato automaticamente ogni
5 minuti che controlla se ci sono lavori di trascrizione completati, e nel caso
salva le informazioni ottenute su una tabella di DynamoDB e prende un lavoro
in attesa per mandarlo in esecuzione. Nel caso di errori nella trascrizione
riporta gli errori sulla tabella di DynamoDB, così che possano essere mostrati
all’applicazione nel caso richieda lo stato dell’analisi della standup.
∗ violetto-Ajarvis-download-audio: metodo accessibile esternamente che per-
mette il download di un file audio di una standup. Come per l’upload viene
generato un link prefirmato dalla validità di un’ora che può essere utilizzato
senza la necessità di nessuna autenticazione.
∗ violetto-Ajarvis-analyzer: metodo più importante e complesso del progetto,
utilizza l’algoritmo di data mining; verrà trattato successivamente.
Lambda Analyzer
violetto-Ajarvis-analyzer è la funzione Lambda che si occupa di estrarre informazioni
dalla trascrizione della standup. Per riuscire meglio la funzione utilizza due file di
supporrto presenti nel bucket di Amazon S3.
Il primo file è helper.json e contiene possibili sostituzioni a termini che vengono
trascritti in modo sbagliato da Amazon Transcribe, emersi dai vari test effettuati. Per
esempio il termine "Hub" viene erroneamente trascritto come "ob".
Il secondo file è tokens.json e contiene i dizionari utilizzati per individuare e valutare
le parole e pezzi di frasi che individuano la durata, i problemi, il nome del progetto,
ecc.
Ho suddiviso l’operazione di analisi in più pezzi e in più file:
∗ Il file lambda.py, come in tutte le altre funzioni lambda, contiene il metodo
handler della funzione; esso si preoccupa dei dati che bisognerà utilizzare, oltre
a preparare in modo corretto i dati da ritornare. Utilizza analyzer.py per
eseguire l’algoritmo di data mining.
∗ Il file analyzer.py, il quale contiene vari metodi pulire o formattare il testo, oltre
a metodi specifici per:
– estrarre il nome del progetto
– estrarre il nome dell’utente che si identifica
– ricavare informazioni su cosa era stato fatto precedentemente
– ricavare informazioni su cosa sarà fatto dopo la standup
– individuare se si sono stati presentati vari problemi e se ne è stata data una
durata quantificabile
∗ Il file prepocess.py, il quale contiene metodi usati da analyzer.py per rifinire il
testo, ed eseguire una suddivisione in token che viene usata per facilitare la com-
prensione di frasi troppo lunghe, individuando token che possono suddividere
la frase in sottofrasi.Puoi anche leggere
